+++ This bug was initially created as a clone of Bug #521512 +++ However, the VT switch seems still have problem that it needs to relogin every time after VT switch. --- Additional comment from awilliam on 2009-10-26 20:57:28 EDT --- kernel 96 has been tagged into F12 final, so can we close this one now? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers --- Additional comment from caiqian on 2009-10-26 23:12:30 EDT --- Can you use the BZ to track the annoying problem mentioned in comment #22 -- the VT switch seems still have problem that it needs to relogin every time after VT switch? or you would like a new BZ? I'll open a new BZ for the problem mentioned in comment #15. --- Additional comment from jglisse on 2009-10-27 13:01:37 EDT --- I think it's better to open a separate bug for VT switch issue. Just to make sure i understand it properly. You boot with KMS and with no vga= cmd appended to your kernel boot parameter ? Then when you are on X if you switch away to some console, when you switch back to X you did loose your session and you back to gdm ? Does process of your previous session still runs ? --- Additional comment from caiqian on 2009-10-27 19:42:54 EDT --- (In reply to comment #25) > I think it's better to open a separate bug for VT switch issue. Just to make > sure i understand it properly. You boot with KMS and with no vga= cmd appended > to your kernel boot parameter ? Yes. > Then when you are on X if you switch away to > some console, when you switch back to X you did loose your session and you back > to gdm ? Yes. > Does process of your previous session still runs ? No.
Can you test xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.i686 it shoudl have been tagged into rawhide.
Same problem.
can we get a the /var/log/Xorg.0.log.old? or /var/log/gdm/:0.log.1 from that -10 driver? after its crashed?
Created attachment 366519 [details] Xorg.0.log.old
Created attachment 366520 [details] :0.log.1
Discussed in today's blocker bug review meeting. Several others with similar hardware do not see this problem. There is another tester on test-list who posted intent to test F12 on an Xpress 200m, I will follow up with him to check on his experience of this bug. Status as a blocker is uncertain for now, will be reviewed soon. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Will test in a minute. Just needs to reboot first (this box). Chipset: AMD RS482 aka Radeon XPress 200M
fedora-test-list reporter Robert Day, on another Xpress 200m system, reports: "based on a nightly compose from a couple days ago, if i switch to a VT, then back to my desktop, i have to log in again. i'm guessing that's not what you wanted to hear, unless that issue was fixed in a newer nightly compose." don't have an exact date for his nightly compose, but kernel -96 has been in for rather longer than 'a couple of days' ago. trying to confirm he has -96, but doesn't sound good. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Sorry.. appears this is an XPress 200, not 200M. Seriously thought this was a 200M. Anyway, it's now running a fresh liveusb desktop from today with kms. Even enabled desktop effects. Can switch VT without problems and back to X without loosing any sessions. Xorg chipset report: (--) PCI:*(0:1:5:0) 1002:5974:1462:7141 ATI Technologies Inc RS482 [Radeon Xpress 200] rev 0, Mem @ 0xd0000000/268435456, 0xfe9f0000/65536, I/O @ 0x0000b800/256, BIOS @ 0x????????/131072 Not sure it helps..
CAI i tested on my x200 and can switch without problem : xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.i686 kernel-PAE-2.6.31.5-105.fc12.i686 Also works with a 64bits kernel & userspace.
Henrik, can you please confirm whether or not you *ever* saw this problem? i.e. were you seeing it at the time of comment #7 but it's fixed now, or did you just happen to have similar hardware and thought you'd help us test, but had never seen this bug before? Cai, can you please test with kernel -112 and confirm whether you still see this issue? Thanks. http://koji.fedoraproject.org/koji/buildinfo?buildID=139511 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I mainly thought I had the reported hardware and wanted to test if i could reproduce the issue. But my hardware is slightly different so my test is not valid. As this graphics has never been really stable for me I try to test new things from time to time. This said sometimes X do crash on VT change with F11, and have always been like that since I have had this box (ca 2006) long before kernel mode setting. Still have to use nomodesetting with F11 to use the box due to other issues (lockups and graphics corruption with kernel mode setting enabled) so can't really say if this problem is also seen with kernel mode setting. But it seemed stable in the tests I threw at it yesterday. But that's most probably irrelevant to the easily reproduced issue in this bug report.
Same problem using the latest rawhide bits, kernel-2.6.31.5-115.fc12.x86_64 xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.x86_64
CAI i will need you to debug this, here is a step by step procedure, you will need another computer to ssh into your X200M computer. Log through ssh as root on your X200M from another computer (while Xorg is running after a cold boot with KMS enabled) Do the following (you should be logged as root), on the X200M computer log in as usual. (comment about what happen start with //) sudo debuginfo-install xorg-x11-server-Xorg xorg-x11-drv-ati gdb Xorg `pidof Xorg` // In gdb type: set logging on // gdb should print a bunch of things maybe ask you to install more debuginfo // it should be fine without them for the moment, you will get a lot of sigpipe // which halt Xorg, each time you get a sigpipe type c and press enter // So now the Xorg process should be stoped, type c then enter // now on the X200M computer switch to a VT which is what is log in you out // if i understand the bug, gdb should stop with sigusr or somethings like that // press c and enter, at one point their will likely be a segfault this is where // the bug is happening when you see that in gdb instead of pressing c and enter // type : bt full // There should be a lot of line and gdb might ask you press enter to see all of // them, press enter until the end, then press q, and y to quit gdb, in the // their should be a gdb.txt in the directory please attach it here to the bug
CIA i am on irc (jglisse or glisse on #desktop and others chanel if you got trouble following my instruction don't hesitate to ask their).
Since I'll need to install the debuginfo, I have installed xorg-x11-server-Xorg-1.7.0-5.fc12.x86_64. Then, VT switch is broken for some other reasons. After VT switch, then the X screen is a black screen with only a cursor. Then, the switch back to VTs, but there are all black screens. At this point, the system is totally unusable. Here is the debug information. Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00000031664d9c07 in ioctl () from /lib64/libc.so.6 Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00000031664da693 in __select_nocancel () from /lib64/libc.so.6 Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00000031664d9c07 in ioctl () from /lib64/libc.so.6 Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00000031664da693 in __select_nocancel () from /lib64/libc.so.6 Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00000031664d9c07 in ioctl () from /lib64/libc.so.6 Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00000031664da693 in __select_nocancel () from /lib64/libc.so.6 #0 0x00000031664da693 in __select_nocancel () from /lib64/libc.so.6 #1 0x000000000045bd5a in WaitForSomething () #2 0x000000000042c322 in ?? () #3 0x0000000000421c9a in _start () #0 0x00000031664da693 in __select_nocancel () from /lib64/libc.so.6 #1 0x000000000045bd5a in WaitForSomething () #2 0x000000000042c322 in ?? () #3 0x0000000000421c9a in _start () #0 0x00000031664da693 in __select_nocancel () from /lib64/libc.so.6 #1 0x000000000045bd5a in WaitForSomething () #2 0x000000000042c322 in ?? () #3 0x0000000000421c9a in _start () #0 0x00000031664da693 in __select_nocancel () from /lib64/libc.so.6 No symbol table info available. #1 0x000000000045bd5a in WaitForSomething () No symbol table info available. #2 0x000000000042c322 in ?? () No symbol table info available. #3 0x0000000000421c9a in _start () No symbol table info available. A debugging session is active. Inferior 1 [process 1916] will be detached. Quit anyway? (y or n) LND: Sending signal 10 to Thread 0x7f38b68967e0 (LWP 1916) Detaching from program: /usr/bin/Xorg, process 1916
Created attachment 367629 [details] GDB debug log In addtion, after login the GDM, the Xorg sometimes SIGSEGV. I have attached the log following the instruction you mentioned.
CAI i will full dmesg with KMS, and please install : http://people.freedesktop.org/~glisse/xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.x86_64.rpm sudo rpm -ivh --force Then restart gdm/X and trigger the bug and attach the Xorg log (new informations should show their with this package). Note that this package might fix the bug too but it's work around a deeper bug i believe.
cai: what version of gdm are you on? is the system in general updated to latest rawhide? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
cai: i notice you now have bugs open for VT switch crashes in *both* UMS and KMS cases - 522955 is the UMS case. jerome, do these look like being actually the same bug? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
we'd more or less already decided not to treat this as a blocker, dropping. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #20) > cai: i notice you now have bugs open for VT switch crashes in *both* UMS and > KMS cases - 522955 is the UMS case. jerome, do these look like being actually > the same bug? Those are not the same. In KMS case, I can still do VT switch. In non-KMS case, the screen is total blank or scratched, and seems not response to VT switch or anything else at all.
CAI did you had time to test the xorg-x11-drv-ati at : http://people.freedesktop.org/~glisse/xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.x86_64.rpm If so please attach corresponding Xorg.log. I really need this to debug further your need to relogin bug, thanks.
Created attachment 367914 [details] Xorg.0.log After using the new package above, switching from X to a VT, and then switching back (Alt-F1) leads a freeze screen and the system does not response to keyboard/touchpad anymore. Luckily, it can still be sshed. The following logs were captured using another machine after the above happened..
Created attachment 367915 [details] Xorg.0.log.old
(In reply to comment #19) > cai: what version of gdm are you on? is the system in general updated to latest > rawhide? I have just updated to the latest rawhide, and the same problem. gdm-2.28.0-9.fc12.i686
Retested after updating all packages to the latest and the official xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12 version. The reminding problems are, * re-login problem in the comment #17. * VT 1 (Ctrl-Alt-F1) is a blank screen with a flicking cursor (expecting some messages there?) VT 7 (Ctrl-Alt-F7) becomes the X (in another Intel-based VGA laptop, VT 1 is the X).
As you know, another problem is suspend/resume is not working there. When press the power button to resume, it remain black screen and idle.
Please attach a full dmesg, also suspend/resume should work with recent enough kernel -117 for instance. Issue here is that for some reason S-VIDEO report there is one video mode but in fact there is none.
Created attachment 368195 [details] dmesg Here it is.
Cai can you try with adding following to your kernel boot parameter : radeon.tv=0 drm.debug=15 and attach dmesg of such run. Also please can you confirm that there is nothing connected to the tv-out of your laptop ? Thanks.
With radeon.tv=0 in place, the system is unable to boot. Looks like there is no KMS. The plain splash screen is taking forever to complete. I am not sure how to get the dmesg there. The network is not up, there is no VT and X yet.
Created attachment 368419 [details] dmesg with drm.debug=15 This is without radeon.tv=0
Created attachment 368423 [details] screenshot with radeon.tv=0 This is screenshot of the very early in the boot process when boothing with radeon.tv=0 drm.debug=15. It stops there for a long time. Sorry for the use of the flash when taking the screenshot.
Created attachment 368424 [details] another screenshot with radeon.tv=0 This is another screenshot of the very early in the boot process when boothing with radeon.tv=0 drm.debug=15. It stops there for a long time. Sorry for the use of the flash when taking the screenshot.
Created attachment 368426 [details] yet another screenshot with radeon.tv=0 This is screenshot of the very late in the boot process when boothing with radeon.tv=0 drm.debug=15. It stops there seems forever. Sorry for the use of the flash when taking the screenshot.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Please try if lastest kernel -134 helps : http://koji.fedoraproject.org/koji/buildinfo?buildID=141560
Awesome! Seems Fixed. I can switch to VT 1 to see the boot log as well. Thanks guys!
I said this too early. The new kernel -134 will deadlock the system after browsing firefox for a while
-127 kernel will consistently deadlock the system too; -122 kernel is fine.
-122 kernel has the problem too. Maybe this is related to the userspace as well, since have just upgraded the whole system today.
Same thing even without KMS. Fall back to VESA ...
Completely deadlocked, or just the X screen? I.e. does a remote SSH into the box still work? Does the box respond to ping? Can you get /var/log/messages and /var/log/Xorg.0.log from the failure?
I have no another system to do that yet, but I said deadlock because it does not response to either keyboard, touchpad, and screen is frozen. VESA driver is working fine so far though
Now you are experiencing hangs which is a different bug, you can track progress on that through : https://bugzilla.redhat.com/show_bug.cgi?id=532308 I am closing this bug as the original issue is now fixed.