Created attachment 17762 [details] [review] The X server log of the crashed session If I start it attached with a second screen on my VGA output, the X server locks up and the built-in screen of my notebook keeps black. I can shutdown my notebook by pressing the power button, but can't use the keyboard. If I attach the second screen after X has started, everything works fine. Even suspend-2-ram works without problems. FGLRX had similar problems (suspend-2-ram failed, if a second head was attached). I'm using the latest GIT-Version of the driver and xorg-server-1.4.99.905 from the Gentoo x11 overlay.
Created attachment 17763 [details] Xorg.conf
Okay, I figured out, that there are also freezes of the entire system when removing or attaching an external monitor to a running X-session. Unfortunately I can't get any logging information because the system freezes immediate. Sometimes there are also freezes some seconds after resuming from suspend-2-ram (but this could be related to another problem). Also the mouse pointer is flickering near the right edge of the second screen (and sometimes randomly anywhere on the screen). This problem disappears in single-screen mode.
I have the same problem on my mobility X1400 (aka M54). Like the OP, I can attach a VGA after X is running and use xrandr to enable it, but if I restart X, by logout or reboot, with the VGA attached, then I get a black screen on the laptop and VGA. The same happens with the S-video out (see comment #4 on bug 16178). I can attach it after X is running and use xrandr with it, but logout or reboot results in a black screen on both. One difference than the OP, I can use Cntl-Alt-Del to reboot. However the consoles do not work (i.e. Cntl-Alt-F1). Another difference is that I have not had any freeze when connecting or disconnecting a VGA or S-video. Another difference is that I do not have any resume problems. I'm running ubuntu hardy with git packages from the tormod xorg-pushers repository (xserver 1.4.99.906, mesa, libdrm, and ati from git) and I also upgraded libxrandr to 1.2.3. By the way, I enabled S-video by undoing your disabling patch, so I could test it.
Today I played a little bit with my configuration and using the recent GIT release. Still, starting with a second head attached won't work. However after starting, the X server fails and all screens will be black, but I can use my keyboard and I'm able to execute commands from the shell. Running dmesg doesn't lead to any informations - it just looks like a normal startup, but the X-Server fails somewhere without any failure message (the Xorg.0.log is still the same as the one attached to the bug). Today I tried this additional configuration, without success: Option "DisplayPriority" "High" Option "DefaultTMDSPLL" "on" Option "DefaultConnectorTable" "on"
Okay, today I took some look inside the drivers source code and tried to debug it. Unfortunately I have no other machine to use SSH and GDB, so I tried to debug it by xf86DrvMsg() statements. (I know, it is a ugly way to do that...) And I think I found the place where the driver crashes: Call trace: [...] radeon_crtc_dpms atombios_crtc_dpms atombios_blank_crtc RHDAtomBiosFunc req_func => rhdAtomExec rhdAtomExec ParseTableWrapper ParseTable In ParseTable (Decoder.c, line 223, latest git) there is the following loop: if (!CD_ERROR(ParserTempData.Status)) { ParserTempData.Status = CD_SUCCESS; while(!CD_ERROR_OR_COMPLETED(ParserTempData.Status)) { ... } // while } // if The program executes the loop one time and leaves it, because the condition is false. However I extended the loop by the following tracing code: if (!CD_ERROR(ParserTempData.Status)) { xf86DrvMsg(0, X_ERROR, "[E5-1]\n"); ParserTempData.Status = CD_SUCCESS; while(!CD_ERROR_OR_COMPLETED(ParserTempData.Status)) { ... xf86DrvMsg(0, X_ERROR, "[E5-1-2]\n"); xf86DrvMsg(0, X_ERROR, "[E5-1-2 %i > %i]\n", ParserTempData.Status, CD_SUCCESS); } // while xf86DrvMsg(0, X_ERROR, "[E5-1-3]\n"); } // if The last output of the X-Server to Xorg.0.log is "E5-1-2 0 > 0". The output "E5-1-3" never appears on the log file. It looks like that the program never leaves the queue and the X-Server got stuck in some kind of an endless loop. This explains why I can still shutdown the system by CTRL+ALT+DEL, but have no other access to the terminal. I just don't know enough about AtomBIOS to fix the bug by myself. Could you give me some hints, where I can do some further investigations?
Okay, I did some further investigations by myself. It seems to be a bug in the AtomBIOS code, that will be executed when unblanking the screen. It could be also a bug in the interpreter. I put some trace-code into the AtomBIOS byte code interpreter which tells me, what the AtomBIOS is doing. I found out, that it hangs in an endless loop, executing the following instructions: 0xEE9335BC Op-Code 0x4A | Test 0x9, AtiReg(0x1827+0x200) 0xEE9335C1 Op-Code 0x44 | Jump [Equal] These two instructions are executed in the endless loop. The Value of AtiReg(0x1827+0x200) = 0x2. I try to figure out now whether it is a bug of the firmware or a bug in the processing of the jump-instruction by ProcessJump. (It's a little bit time-intensive, because I've to reboot my computer during each test)
Okay, for me, it looks like to be an issue with the AtomBIOS. The faulty code is: 0xEE9335BC Op-Code 0x4A | Test 0x9, AtiReg(0x1827+0x200) 0xEE9335C1 Op-Code 0x44 | Jump [Equal] EE9335BC Where as "AtiReg(0x1827+0x200) = 0x2". As long as "TEST" has the same semantics as on x86, the problem is that 0x9 & 0x2 = 0 => Equal And as a consequence the jump will run into the endless loop. Perhaps the code of AtomBIOS reads from the wrong register or some steps of the initialization are wrong? It is strange that the same code works if Xorg has already started completely. I have a lot of similar problems with my Mobility x1400. The system sometimes freezes partially (the mouse pointer is moveable and ssh is still working) or completely. Esp. when resuming from disk or ram, sometimes the system hangs in a similar way (I had another bug report on this).
Can you attach the problematic vbios images? (as root): cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom
Created attachment 21693 [details] vbios.rom
Created attachment 21695 [details] Video BIOS image
Created attachment 23044 [details] [review] Make sure crtc is enabled before attempting to blank/unblank Does this patch help?
Created attachment 23048 [details] [review] Xorg logfile Sorry, with this patch I still have the same problem. I patched it against the Ubuntu 8.10 sources of the radeon driver, which is "xserver-xorg-video-ati-6.9.0+git20081003.f9826a56"... One problem I have with the secondary head is, that the XRandR utility tells me that any connected display supports a resolution of 1600x1024. Normally it wants to select this resolution, which is just not supported by the display - perhaps this is related to the bug?
(In reply to comment #12) > One problem I have with the secondary head is, that the XRandR utility tells me > that any connected display supports a resolution of 1600x1024. Normally it > wants to select this resolution, which is just not supported by the display - > perhaps this is related to the bug? > No that's an xserver issue. It adds default server modes of which 1600x1024 is one.
I also tested it on ubuntu 9.04 with latest video-ati and a second time with today's git video-ati. It fails here also.
Created attachment 23052 [details] [review] don't unblank until crtc is initialized Does this patch help?
*** Bug 18104 has been marked as a duplicate of this bug. ***
Yes, this solves this problem for me. Thank you, that's great (the first time I can even use user switching...)!
Not here. It does not work for me.
(In reply to comment #15) > Created an attachment (id=23052) [details] > don't unblank until crtc is initialized > > Does this patch help? Works fine here :) Thanks!
(In reply to comment #18) > Not here. It does not work for me. > Can you attach your xorg log with the patch applied?
fix pushed: 9a108f0a0b7203458673ce6221e747a166d39617
Created attachment 23054 [details] [review] Xorg.log for logout test This is the hang that occured when I tried to logout with the vga attached. It failed and I had to reboot.
Created attachment 23055 [details] Xorg.log for boot up test This is the xorg.log from the successful boot up with the vga attached.
I got a black screen hang when I logged out and had to reboot. Attached is the Xorg.0.log.old that was still there after I rebooted with no vga attached. Next, I shutdown, connected my vga, and booted. Great, it works. I also attach the Xorg.0.log from this successful boot. I guess I need to test the logout some more and get back if I have any more problems. I've also had hangs when my S-video is connected in the past. Does this patch fix that situation also? Should I test it again with this patch? thanks,
I just repeated the same experience. Logout with my vga attached results in black screen(s) hang, and necessity to reboot (Alt-SysRq-REISUB then Cntl-Alt-Del), but then bootup with vga attached works. So, there's still a logout problem here.
Some more feedback. There is definitely still a problem with logout with the vga attached. I've tested it two more times with the same result. However, the following tests succeeded with the vga attached: 1. switch user 2. switch to console (C-A-F1) and stop / start kdm 3. bootup. Is there any more info I can provide?
(In reply to comment #26) > Some more feedback. There is definitely still a problem with logout with the > vga attached. I've tested it two more times with the same result. However, > the following tests succeeded with the vga attached: 1. switch user 2. switch > to console (C-A-F1) and stop / start kdm 3. bootup. > > Is there any more info I can provide? > Is the hang at log out something new introduced by the patch, or was this the previous behavior that is still not fixed with the patch? Also as you using the patch I committed to git or the one on the bug? Finally is the box and or xserver hung or is the console just not restored properly?
Created attachment 23081 [details] [review] set initialized to false on closescreen() Paul, does this patch help (on top of git master)?
Great job, that fixed it!
fix pushed: 1a237a40958c006c56b80850bd77b2ac6c17e030
It doesn't work for me. I attached xorg log file in the wrong bug report, sorry. Here's the link to the attachment: http://bugs.freedesktop.org/attachment.cgi?id=23084 I still get black screens when X starts while my external monitor is plugged in the DVI-0 output. As usual, X uses 95-100% CPU when locked.
(In reply to comment #31) > It doesn't work for me. I attached xorg log file in the wrong bug report, > sorry. Here's the link to the attachment: > > http://bugs.freedesktop.org/attachment.cgi?id=23084 > > I still get black screens when X > starts while my external monitor is plugged in the DVI-0 output. As usual, X > uses 95-100% CPU when locked. It works fine on my DVI-0 and VGA.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.