Please specify more information. Try attaching your xorg.conf and Xorg.0.log
files. Also, any other relevant information would be useful - Linux
distribution, installation method, compiler version (if you compiled from source)...

All the information you requested is already on the launchpad.net link (Xorg log
files, radeon register dumps, config files, everything).

I used the Ubuntu versions of X. I've had this bug for over a year now.

Latest versions I've had the problem with:

- Xorg 7.1.1
- 'ati' driver 6.6.2. both with and without the patch from #5473

All compiled on the latest Ubuntu (Edgy):
gcc version 4.1.2 20060903 (prerelease) (Ubuntu 4.1.1-13ubuntu1)

Created attachment 6834 [details] [review]
Xorg.0.log for X 6.8.2 + ati experiencing this

Created attachment 6835 [details]
Same log, but using fglrx (which does not experience the bug)

Created attachment 6836 [details]
Register dump (made with radeontool) of broken situation

Created attachment 6837 [details]
Register dump (made with radeontool) of working situation (fglrx driver)

Created attachment 6838 [details]
Xorg.conf (broken edition; working only replaces ati with fglrx)

Created attachment 6839 [details]
Xorg.log using current 'ati' driver (broken/wobbly)

Created attachment 6840 [details]
Xorg.log using current 'fglrx' driver (working)

The 'current ati' is actually 6.6.1 + the first patch from #5473
(https://bugs.freedesktop.org/attachment.cgi?id=5950)

Can you send me a copy of your BIOS from that card?

we appear to have trouble processing the BIOS in your card in the same way as
fglrx does... 

if you have a newish kernel you can probably just go 
cd /sys/bus/pci/devices/<device:id>/
echo 1 > rom
cat rom > /tmp/fglrom

and mail it to me airlied@gmail.com

Mail sent.

Did you get the mail?

I have the same laptop than Martijn (HP nw8240) and the same bug and effects.
Tested today on version 6.6.3 and today git.

Notice that it's not a simple mobility x700 but a firegl mobility v5000 based on the same core.

fglrx works very well.

With Ubuntu 7.04 Live-CD, it fails completely for me.  The screen generates bizarre effects (sort of like a b/w screensaver with fading effects) and you do not see the desktop.  My system reports "ATI Technologies Inc Radeon Mobility X700 (PCIE)".

Both drivers "ati" and "radeon" have the above symptoms.  "vesa" just fails with an error message telling that no matching mode can be found.  There is no way for me to get any desktop screen up on this laptop.

According to:

http://h10010.www1.hp.com/wwpc/aa/en/sm/WF06a/7498257-7498765-7498765-7498765-12434670-12115736.html

and

http://avkrok.net/nw8240/

The graphic card is indeed a ATI Mobility FireGL V5000 with discrete PCI Express, as reported by Samuel Bernard previously.

Created attachment 10150 [details]
The requested BIOS of my broken ATI

Created attachment 10151 [details]
The video bios of a laptop with the same card, but working video

Too bad there doesn't seem to be a way to upgrade the video bios -- the HP website doesn't list any video bioses, just system bioses.

Created attachment 10409 [details]
radeondump-dump, using fglrx driver

Created attachment 10410 [details]
radeondump dump, made using the radeon driver, after using fglrx

Created attachment 10411 [details]
radeondump, using the radeon driver, cold boot

For some reason, running the "radeondump" utility, fixes the problem instantly. The screen stopps wobbling around and becomes usable.

Created attachment 10412 [details]
radeondump dump, after first radeondump fixed things

Created attachment 10417 [details]
radeontool regmatch \* output, after fixing using radeondump

I've run radeondump with breakpoints now, to see when it happens.

The function radeon_in_pll in radeontool.c in the radeondump source does the magic. Specifically, this call does:

radeon_set(radeon, RADEON_CLOCK_CNTL_INDEX, offset & 0x3f);

I've tried the three errata bits (CHIP_ERRATA_R300_CG, CHIP_ERRATA_R300_CG, CHIP_ERRATA_R300_CG), both alone and in all possible combinations, and none of them resolve the problem.

Breakpoint 1, radeon_in_pll (radeon=0xbff1b600, offset=0) at radeontool.c:215
215             radeon_set(radeon, RADEON_CLOCK_CNTL_INDEX, offset & 0x3f);
(gdb) s
radeon_set (radeon=0xbff1b600, offset=8, value=0) at radeontool.c:142
142             if (radeon->mmio_mem == NULL) {
(gdb) s
153             *(unsigned int * volatile)(radeon->mmio_mem + offset) = value;  
(gdb) s
155     }

(In reply to comment #26)
> I've tried the three errata bits (CHIP_ERRATA_R300_CG, CHIP_ERRATA_R300_CG,
> CHIP_ERRATA_R300_CG), both alone and in all possible combinations, and none of
> them resolve the problem.
> 

I mean CHIP_ERRATA_R300_CG, CHIP_ERRATA_PLL_DUMMYREADS and CHIP_ERRATA_PLL_DELAY, of course

try adding:

INPLL(pScrn, 0x00);

to the end of RADEONRestorePLLRegisters() and RADEONRestorePLL2Registers() in radeon_driver.c and let me know if that helps.

No difference

(In reply to comment #30)
> No difference
> 

how about adding:

usleep(5000);
INPLL(pScrn, RADEON_VCLK_ECP_CNTL);

to the end of RADEONRestorePLLRegisters() and 

usleep(5000);
INPLL(pScrn, RADEON_PIXCLKS_CNTL);

to the end of RADEONRestorePLL2Registers()

That doesn't fix it either..

Several options to try:

See if you can isolate what PLL radeondump is reading that fixes things. It starts out by looping through the PLL index starting from 0x00 (line 139 of radeon_dump.c).  Maybe step through it and see which PLL reg fixes it.

Can you test the randr-1.2 branch of the radeon driver and see if it works better for you?

The very first radeon_in_pll call fixes it.

I'll try the randr-1.2 branch

Switching to randr-1.2 doesn't fix the problem either.

try adding:

usleep(5000);
INPLL(pScrn, 0x00);

to the end of RADEONModeInit() before the return (ati master branch), both with and without the usleep().

Still no lock (maybe the usleep has to be even longer?)

uhr, luck of course

Does switching modes after starting X fix it?  If you switch modes after running radeondump, do you have to run radeondump again to fix the problem?

On every mode switch (like some games do), the breakage re-appears.
Switching back to text mode doesn't break -- text mode looks normal.
Mode-switching before running radeondump doesn't help.
Running radeondump always fixes it.

try increasing the delay or try adding:

usleep(5000);
INPLL(pScrn, 0x00);

right before the returns in RADEONScreenInit() and RADEONSwitchMode() and RADEONEnterVT().

one more thing to try.  loop through the whole set of PLLs at the end of RADEONModeInit(), e.g.:

usleep(10000);
for (i = 0x00; i < 0x3F; i += 4)
    INPLL(pScrn, i);

(In reply to comment #41)
> try increasing the delay or try adding:
> 
> usleep(5000);
> INPLL(pScrn, 0x00);
> 
> right before the returns in RADEONScreenInit() and RADEONSwitchMode() and
> RADEONEnterVT().

I've added this, it didn't work, with delays from 5000-50000 in 5000 increments.

(In reply to comment #42)
> one more thing to try.  loop through the whole set of PLLs at the end of
> RADEONModeInit(), e.g.:
> 
> usleep(10000);
> for (i = 0x00; i < 0x3F; i += 4)
>     INPLL(pScrn, i);
> 

This doesn't do it either.

I think we should punt this to using randr 1.2 driver and we can attempt to fix it in master, it's not showing up as an easy fix for 6.7.

Any update on this? Apparently it's still an issue with the latest ati.

(In reply to comment #46)
> Any update on this? Apparently it's still an issue with the latest ati.
> 

It's hard to sort out this kind of problem unless you have hardware that exhibits it.  When we add full atom support to the radeon driver that might fix the issue, but I don't really have an ETA on when that will happen.

Created attachment 13100 [details] [review]
possible fix

I think I may have found the fix.  Looks like newer cards may prefer using a full 32 bit R/W for RADEON_CLOCK_CNTL_INDEX.

(In reply to comment #48)
> Created an attachment (id=13100) [details]
> possible fix
> 
> I think I may have found the fix.  Looks like newer cards may prefer using a
> full 32 bit R/W for RADEON_CLOCK_CNTL_INDEX.

I LOVE YOU!!


(it works :))

fixed:
a84d446fd301d456bcea8f7abdc52e5a30776412