Could it be that your radeonhd driver is too old?
Can you post the full log file please?

I forgot : I tried radeonhd-1.2.0 and 1.2.1.

I already joined some log files. Wich one(s) should I join ?

Vista and xp works.

The fact is that is bought that laptop to have a laptop running on 100% FOSS... how frustrating.

I don't even need hardware acceleration.

I tried setting several resolutions and modelines.

It's quite complicated : 
- using kernel vesa driver for the console causes black screen but I can ssh the box. (no specific graphic output in dmesg), uvesa fails too.
- xorg vesa driver fails : the screen displays some ugly output with stripes and the box hangs
- xorg vga driver fails.
- xorg radeon driver fails.
- xorg radeonhd fails too (see Xorg.log.0)

I tried the latest git head from xf86-video-radeonhd and it fails too to recognize the card. 
It seems that this card needs to be added.

here's lspci -vv output for that card :

01:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 95c4 (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Unknown device 19d3
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M]
        Region 1: I/O ports at a000 [size=256]
        Region 2: Memory at fdff0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fdfc0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000

the git head rhd_conntest output :

rhd_conntest: v1.2.1, git branch master, commit 1f65f354
Unknown device: 0x1002:0x95C4 (01:00.00).


Don't know what else to add... just ask.

Created attachment 17250 [details]
Xorg.0.log 

Log file using logverbose 7 and adding "ChipID 0x95c0" to my xorg.conf (radeonHD 3470 ChipID).
Didn't worked, crashed the same way.

Hi! I have the same problem on the same laptop.

I don't know what are the relations of the radeonhd driver and the framebuffer but, as it was pointed to, if one boots the M51Se with framebuffer (vga=nnn) the screen remains black (e.g. it's impossible to use the last OpenSuse livecd).

Does the radeonhd driver use the framebuffer? Is it possible to disable it's use?

Yannick

(In reply to comment #5)
> Created an attachment (id=17250) [details]
> Xorg.0.log 
> 
> Log file using logverbose 7 and adding "ChipID 0x95c0" to my xorg.conf
> (radeonHD 3470 ChipID).
> Didn't worked, crashed the same way.
> 

According to this log the Xserver at least didn't lock up. 
Also the chip ID you need has been added so no need for an override any more.
According to the log you also have an external DVI connected.
Can you describe what you see on the laptop panel and the external screen?
From the log there seems to be a problem with the laptop panel, to look into this I would need a dump of your video BIOS.
You can use 'rhd_conntest 1:0.0 -d' to obtain this. You'd have to get the latest one from git though as the PCI Ids have just been added.

Assigning to reporter for feedback. Please assign back to me when done. Thanks!

> According to this log the Xserver at least didn't lock up.

Okay, but why does the system freezes when launching xorg ?

> Also the chip ID you need has been added so no need for an override any more.

great :)

> According to the log you also have an external DVI connected.

That's strange because the laptop is actually naked : I've only connected ethernet and power supply.

> Can you describe what you see on the laptop panel and the external screen?

The screen just becomes black, and nothing else.

> From the log there seems to be a problem with the laptop panel, to look into
> this I would need a dump of your video BIOS.
> You can use 'rhd_conntest 1:0.0 -d' to obtain this. You'd have to get the
> latest one from git though as the PCI Ids have just been added.

rhd_conntest worked, I'm attaching the bios.

> 
> Assigning to reporter for feedback. Please assign back to me when done. Thanks!
> 

Created attachment 17289 [details]
rhd_conntest bios dump using latest git.

(In reply to comment #8)
> > According to this log the Xserver at least didn't lock up.
> 
> Okay, but why does the system freezes when launching xorg ?
> 
Does this also happen with the latest version?
The log ends where the server startup is complete.

Do you get a hard freeze so that you cannot even log in from remote or does
X just 'hang' and you cannot kill it with ctrl-alt-backspace?
If you get a hard hang it could be that it hangs after a little while which
could point towards 2d acceleration. Have you tried with 
Option "AccelMethod" "None" already?

> > Also the chip ID you need has been added so no need for an override any more.
> 
> great :)
> 
> > According to the log you also have an external DVI connected.
> 
> That's strange because the laptop is actually naked : I've only connected
> ethernet and power supply.

Hrm, ok. I see what your problem is: there is not HPD information in the connector table. I need to check this with the BIOS you've supplied.
> 
> > Can you describe what you see on the laptop panel and the external screen?
> 
> The screen just becomes black, and nothing else.
OK.
> 
> > From the log there seems to be a problem with the laptop panel, to look into
> > this I would need a dump of your video BIOS.
> > You can use 'rhd_conntest 1:0.0 -d' to obtain this. You'd have to get the
> > latest one from git though as the PCI Ids have just been added.
> 
> rhd_conntest worked, I'm attaching the bios.

Thanks!
> 
> > 
> > Assigning to reporter for feedback. Please assign back to me when done. Thanks!

Assigning to me. 

> Does this also happen with the latest version?

I built the latest xorg-server and radeonhd from git and it keeps failing exactly the same way.

> Do you get a hard freeze so that you cannot even log in from remote or does
> X just 'hang' and you cannot kill it with ctrl-alt-backspace?
> If you get a hard hang it could be that it hangs after a little while which
> could point towards 2d acceleration. Have you tried with 
> Option "AccelMethod" "None" already?


And yes it looks like a hard freeze :
- the AccelMethod option didn't worked.
- ctrl-alt-backspace does nothing
- no ssh (---->No route to host)
- waited some hours and nothing changed.

The logs are a little different :

(II) RADEONHD(0): Unknown card detected: 0x95C4:0x1043:0x19D3.
        If - and only if - your card does not work or does not work optimally
        please contact radeonhd@opensuse.org to help rectify this.
        Use the subject: 0x95C4:0x1043:0x19D3: <name of board>
        and *please* describe the problems you are seeing
        in your message.

Should I contact opensuse like it's written ?

I'm joining the latest logfile.

Created attachment 17349 [details]
Xorg logfile from xorg-server(git) & radeonhd(git)

It's strange but in my case it's a little different. The X server starts and launch the desktop manager. I can kill it (CTRL+ALT+DEL) or switch to a text console (CTRL+ALT+Fn).
The screen is not black but full of colored lines (sorry, I don't have a word even in French to describe it). I'll attach a picture of it (no very good as it was taken with a camera phone).
Note that's this is with the latest (yesterday) git source. With the 1.2.1 version (the one packaged in Debian), I I have a colorful fog of changing colors. ;-)
I'll attach the X log too.

Yannick

Created attachment 17350 [details]
Picture of the Xorg display (git 10d5a41d)

Created attachment 17351 [details]
Xorg log file (for git 10d5a41d)

I forgot to write that at the very beginning of the machine boot, I have this error:

[    0.293834] PCI: Cannot allocate resource region 9 of bridge 0000:00:01.0
[    0.293905] PCI: Cannot allocate resource region 0 of device 0000:01:00.0

I think the device 0000:01:00.0 is the graphic card.

Is it possible that the fact that the VESA Xorg driver doesn't work is related to the fact that the radeonhd driver does not work? I've tested BSDanywhere and Freesbie livecds and on BSD systems, the VESA driver (at least partly) works.

If you think that the radeonhd driver should work, maybe when the "HPD information in the connector table" is solved, I can take time to install Freebsd to see if the driver works on it. Maybe the problem is elsewhere (kernel?).

Created attachment 17476 [details]
Xorg.log (git radeonhd)

I'm having the same problem: black screen after startX

Hardware: ASUS M51SE-AS023C laptop with ATI Mobility Radeon HD3470
OS: Ubuntu (Hardy)

Follow the installation as described in
http://www.phoronix.com/scan.php?page=article&item=843&num=1

Some log info:
RADEONHD: version 1.2.1, built from git branch master, commit c2139d8c
...
(II) RADEONHD(0): Unknown card detected: 0x95C4:0x1043:0x19D3.
...
(EE) RADEONHD(0): rhdAtomLvdsDDC: unknown record type: 48

I´m attaching the full log for details.

I tested other drivers (vesa, ati, fglrx) without sucess. This driver has the log with more load information.

I've been testing the radeonhd driver on Debian Lenny i386 and I have the same results as Pierre: blank screen et freezed machine.

FYI:

Debian Lenny i386:
  - Xorg: 1.4.1~git20080517
  - kernel: 2.6.24
---> blank screen, machine freezes


Debian Sid amd64:
  - Xorg: 1.4.2
  - kernel: 2.6.25
---> colourful lines, Xorg "killable"

I can try to upgrade one part or another to find the culprit.

Yannick

In fact the difference seems to come from the architecture. The freeze occurs running Linux on i386 and the "colourful lines" occurs on amd64.

@Yannick: 
a. Your log file in attachment #17351 [details] was generated on a 64 bit system.
You had an external display attached. Did X come up on both the internal and external screen?
b. When did the lockup on i386 happen? On startup or shutdown?
@Yannick+born.into.silence:
Locating a freeze is difficult as the log file doesn't get written fully. Could you please run with the -logverbose 7 option so that we can try to get a little closer to the point where it locks up?
@Joao: could you also please provide a -logverbose 7 log file?
Thanks!

Hi Egbert,

Thank you for the answer.

I think you can forget the lockup problem. There's another problem on this machine, a memory related problem. Using only one memory module makes the machine work with vesa or catalyst driver ; for the radeonhd driver, it leads to the "colorful" problem both on amd64 and i386.

For your (a) question, I didn't have and external display attached.

I still have "Unknown card detected: 0x95C4:0x1043:0x19D3" in the log. What should I change to make the HD3470 correctly detected? Note also that it's not a _real_ HD3470: it uses DDR2 RAM where real HD3470 use DDR3 (I don"t know if it's important for the driver).

Sincerely,

Yannick

Created attachment 17691 [details]
Xorg Verbose log

I added the verbose log for my situation.
I noticed that it stops on function rhdMapFB, which I suppose is Map Frame Buffer.
I have found some other similar error reports (for fglrx driver) where the problem seems to be the memory and some issue on the mtrr table.
In my case the mtrr table has:
	reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
	reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1

which seems to be ok...

Please notice that my machine - ASUS M51S series - has 2 MB DDR + 1 MB Intel turbo memory, and the Radeon board has 256 MB but shares some of the PC memory 
(I think it is dynamic memory assignment, because there is no place on the BIOS to change that parameter).

regards

Joao

Alex has recently identified a source of a lockup. This has been fixed in the latest git versions. Also the ID for the M82 should finnaly be printed correctly. Could you guys please retry with the latest driver from git?
Thanks!

Hi Egbert,

For me, the card is now correctly recognized but it still does not work (colorful "moiré effect").

I'll attach the log.

Yannick

PS: I have a warning in the log:
    (WW) RADEONHD(0): LVTMATransmitterSet: cannot get golden settings

Created attachment 17771 [details]
Xorg log for git 435320d

(In reply to comment #27)

Hi Yannick,

> 
> For me, the card is now correctly recognized but it still does not work
> (colorful "moiré effect").
> 
> I'll attach the log.

Do you get a lockup? At startup or when shutting down the server?

> PS: I have a warning in the log:
>     (WW) RADEONHD(0): LVTMATransmitterSet: cannot get golden settings
> 

Can you dump me your video BIOS and attach it here, please?
rhd_conntest <pci_id> -d

Hi Egbert,

The M82 is now written, although the card is still 'unknown'.
But it hangs up in the same place, in FUNCTION: rhdMapFB.
I´ll atach the log.

Joao

Created attachment 17777 [details]
Xorg Verbose log (2)

(In reply to comment #30)
> Hi Egbert,
> 
> The M82 is now written, although the card is still 'unknown'.
> But it hangs up in the same place, in FUNCTION: rhdMapFB.
> I´ll atach the log.

The 'unknown' is irrelevant, it simply means there is not workaround flagged in a blacklist.
The problem with the log file is that when the machine hangs there may still be data in the write buffer so that we don't get to see where it hangs exactly.

The lockup is really worrisome. The only way to debug this which I can see is:
- to rebuild the driver with: 
        make clean; make CFLAGS="-O0 -g"
- to log in from remote as root and run gdb on the Xserver:
   gdb /usr/bin/Xorg
   >> break rhdMapFB
   >> run
   and then single step thru it until it hangs.

Apart from this I'm really running out if ideas.

Hi Egbert,

There's no lockup in my case. Xorg starts and I can switch back and forth to the console (which may be flickering sometimes). But I only see a moiré image of colorful lines.

Joao, can you try to boot with only one memory module? As I said earlier, on my machine, if I have more than one module I can't use neither the kernel framebuffer nor Xorg (the vesa driver and the catalyst one doesn't work).
I've made a bug report on the linux kernel bugzilla about that:

http://bugzilla.kernel.org/show_bug.cgi?id=11103

Egbert, I'll post the VGA Bios dump. It's been made using the catalyst driver, I hope that did not trouble the result. If it's the case, just re-ask.

Yannick

Created attachment 17788 [details]
VGA ROM dump (using 435320d git)

Created attachment 17790 [details] [review]
Proposed fix.

Yannick, thanks for your info and the BIOS. Looks like I need to extend my logic slightly.
I've made a modification to my code which you can find in the attachment. 
Would you please test this for me? 
If it doesn't work, please provide a verbose 7 log file.
Thanks for your help!

Egbert, I've got only one word: YES!!!

Your patch makes the radeonhd driver work here. The only difference with the catalyst driver (except for the DRI) is that radeonhd does not manage to guest the correct monitor size and thus falls back to the default 96 dpi.

A big thank for your work.

Yannick

Yannick, thanks for testing!

I've pushed the fix just now.

This means that according to your comments #17 and #20 below you can run the driver: 
- with 2GB RAM on i386 Linux.
- with more than 2GB RAM on x86-64 Linux
- with more than 2GB RAM on different flavors of BSD.

According to what you've reported in comment #33 it could be a kernel problem which prevents running this driver on Linux i386 with more than 2G of RAM.
You have already reported the problem to the kernel bugzilla under:

http://bugzilla.kernel.org/show_bug.cgi?id=11103

There are other reports of hangs but I'm not sure if they are really related to our driver.
There is still the issue open that DVI_1 is seen as connected. To debug this I need to see the I2C status values.

@Yannick: could you please generate a -logverbose 8 (!!!) log file of the Xserver running on your laptop with no external display connected?

Thanks!!!

With the latest commits: 8b1d3323854 and d65b67b05 the erroneous detection of devices on the digital outputs should be fixed, too.

For the memory problem, I think it's more a question of modules than a question of the amount of memory. I don't have a memory module of more than 2Go but I may find a 1Go to test with 2x1Go.

With only one 2Go, it's OK.

With 2 modules (2x2Go or 2Go+1Go), Freesbee FreeBSD livecd works with the Vesa driver but only sees 3Go as its 32bits.

With 2 modules and Linux i686, Vesa driver doesn't work and the old radeonhd locks up the machine. I'm not 100% sure of the lock up but at least the panel remained black. I did not test the new radeonhd because I no longer have a Linux i686 on this machine, but if you think it may help I can reinstall one on the "test partition" I left.

With 2 modules and Linux amd64, the Vesa driver does not work and the new radeonhd neither. But it's different than previously: the screen is "scrambled" and I can see a red text cursor.


I'll "pull" and compile the latest git and post the verbose log here.

Yannick

Created attachment 17809 [details]
Xorg log with verbosity 8 for git 31e4638

Egbert,

When making the log file, I noticed that sometime when Xorg end the console starts flickering.

I also experienced problem waking up from suspend to RAM: the computer rebooted (but that's beyond the scope of this bug).

Yannick

(In reply to comment #39)
> With 2 modules (2x2Go or 2Go+1Go), Freesbee FreeBSD livecd works with the Vesa
> driver but only sees 3Go as its 32bits.

Would be interesting to know if this is due to the fact that you are using more than 2G of RAM. In this case 1G + 1G should work.
> 
> With 2 modules and Linux i686, Vesa driver doesn't work and the old radeonhd
> locks up the machine. I'm not 100% sure of the lock up but at least the panel
> remained black. I did not test the new radeonhd because I no longer have a
> Linux i686 on this machine, but if you think it may help I can reinstall one on
> the "test partition" I left.

Right. Let's see if others can report some results.

> 
> With 2 modules and Linux amd64, the Vesa driver does not work and the new
> radeonhd neither. But it's different than previously: the screen is "scrambled"
> and I can see a red text cursor.

The original report even mentioned a lockup.
I may leave this ticket open for a while to see if further reports come in.
Lockups seem to happen at different places. Joao seems to get them as soon as the FB is mapped. According to his log file he's using a 32bit OS.

(In reply to comment #41)
> Egbert,
> 
> When making the log file, I noticed that sometime when Xorg end the console
> starts flickering.

This smells very much like spread spectrum. We've seen the same effect on another mobile chipset (M56 I seem to recall, libv should know the details).
We may just leave it disabled when restoring text mode.

I think it's time to demystify spread spectrum (including the parameter space of the AtomBIOS call table EnableSpreadSpectrumOnPPLL).

Alex, would you be able to help us here?

> 
> I also experienced problem waking up from suspend to RAM: the computer rebooted
> (but that's beyond the scope of this bug).

Yeah, hopefully this is not graphics driver related.

>> I also experienced problem waking up from suspend to RAM: the computer rebooted
>> (but that's beyond the scope of this bug).

>Yeah, hopefully this is not graphics driver related.

I think it is. With catalyst driver, suspending to RAM works (not 100% but mostly). I didn't test with vesa driver.

For the memory problem, I don't have any other 1Go module that fits my notebook, so the question remains opened. Maybe Joao can make the test... ;-)

(In reply to comment #43)
> 
> I think it's time to demystify spread spectrum (including the parameter space
> of the AtomBIOS call table EnableSpreadSpectrumOnPPLL).
> 
> Alex, would you be able to help us here?

I'll see what I can dig up.

(In reply to comment #43)
> (In reply to comment #41)

> > When making the log file, I noticed that sometime when Xorg end the console
> > starts flickering.
> 
> This smells very much like spread spectrum. We've seen the same effect on
> another mobile chipset (M56 I seem to recall, libv should know the details).
> We may just leave it disabled when restoring text mode.

My mobile X1400 (M54) sometimes has the flickering VGA text console after running radeonhd, but never with radeon.

(In reply to comment #46)
> (In reply to comment #43)
> > (In reply to comment #41)
> > > When making the log file, I noticed that sometime when Xorg end the console
> > > starts flickering.
> > 
> > This smells very much like spread spectrum. We've seen the same effect on
> > another mobile chipset (M56 I seem to recall, libv should know the details).
> > We may just leave it disabled when restoring text mode.
> My mobile X1400 (M54) sometimes has the flickering VGA text console after
> running radeonhd, but never with radeon.

Have seen this on my Radeon Mobile 3470(M82) also.

(In reply to comment #39)
> For the memory problem, I think it's more a question of modules than a question
> of the amount of memory. I don't have a memory module of more than 2Go but I
> may find a 1Go to test with 2x1Go.
> With only one 2Go, it's OK.
> With 2 modules (2x2Go or 2Go+1Go), Freesbee FreeBSD livecd works with the Vesa
> driver but only sees 3Go as its 32bits.
> With 2 modules and Linux i686, Vesa driver doesn't work and the old radeonhd
> locks up the machine. I'm not 100% sure of the lock up but at least the panel
> remained black. I did not test the new radeonhd because I no longer have a
> Linux i686 on this machine, but if you think it may help I can reinstall one on
> the "test partition" I left.
> With 2 modules and Linux amd64, the Vesa driver does not work and the new
> radeonhd neither. But it's different than previously: the screen is "scrambled"
> and I can see a red text cursor.
> I'll "pull" and compile the latest git and post the verbose log here.
> Yannick

The same happens with OpenSuse 11 x64, it's a total lockup, have to reboot the machine with recycling the power. 

Hello

It's been a while (Lot of work ...)

Following Yannick's advice, I remove one of the memory sticks from my laptop and ... it works now like a charm !

- had display issues with systematic lockup ... now gone 
- had acpi issues with lock on booting when not putting acpi=off ... acpi works perfectly now.

I would advice anybody who experiences those lockups to check the memory.

I had 1 Gb + 2 Gb sticks, from different manufacturers and running at different frequencies.

With radeonhd-1.2.1, xorg works but uses the wrong video output (lcd shows nothing, and xorg uses vga auxiliary output). This bug seems to be fixed in latest git head : it works now on the right display.

born.into.silence: thanks for your follow up!
So could be a memory issue. The solution doesn't seem to be satisfactory as one module needs to be removed. Since the M82 isn't an IGP system I don't see how this is related to the hardware directly. I have the impression that it has more to do with the way the kernel maps this memory.
Although the solution isn't really satisfactory I don't know how to address this issue from the driver side any further.
I would like to close this bug for now.
Thanks to all the people involved in helping me to fix the various issues which surfaced around this ticket :)