Bug 531383 - KMS:RS480:X200M VT Switch kill the Xserver (false positive on video connector)
KMS:RS480:X200M VT Switch kill the Xserver (false positive on video connector)
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
12
All Linux
high Severity high
: ---
: ---
Assigned To: Jerome Glisse
Fedora Extras Quality Assurance
card_IGP300/miI
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-27 19:54 EDT by CAI Qian
Modified: 2013-01-10 00:32 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 521512
Environment:
Last Closed: 2009-11-26 10:34:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg.0.log.old (63.48 KB, text/plain)
2009-10-28 20:29 EDT, CAI Qian
no flags Details
:0.log.1 (58.76 KB, text/plain)
2009-10-28 20:30 EDT, CAI Qian
no flags Details
GDB debug log (1.87 KB, text/plain)
2009-11-05 09:47 EST, CAI Qian
no flags Details
Xorg.0.log (57.56 KB, text/plain)
2009-11-06 19:42 EST, CAI Qian
no flags Details
Xorg.0.log.old (65.58 KB, text/plain)
2009-11-06 19:43 EST, CAI Qian
no flags Details
dmesg (33.83 KB, text/plain)
2009-11-09 07:30 EST, CAI Qian
no flags Details
dmesg with drm.debug=15 (59.68 KB, text/plain)
2009-11-10 10:41 EST, CAI Qian
no flags Details
screenshot with radeon.tv=0 (436.43 KB, image/jpeg)
2009-11-10 10:49 EST, CAI Qian
no flags Details
another screenshot with radeon.tv=0 (376.30 KB, image/jpeg)
2009-11-10 10:50 EST, CAI Qian
no flags Details
yet another screenshot with radeon.tv=0 (305.65 KB, image/jpeg)
2009-11-10 10:52 EST, CAI Qian
no flags Details

  None (edit)
Description CAI Qian 2009-10-27 19:54:08 EDT
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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.
Comment 1 Dave Airlie 2009-10-28 02:03:09 EDT
Can you test xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.i686

it shoudl  have been tagged into rawhide.
Comment 2 CAI Qian 2009-10-28 10:00:54 EDT
Same problem.
Comment 3 Dave Airlie 2009-10-28 19:29:36 EDT
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?
Comment 4 CAI Qian 2009-10-28 20:29:50 EDT
Created attachment 366519 [details]
Xorg.0.log.old
Comment 5 CAI Qian 2009-10-28 20:30:46 EDT
Created attachment 366520 [details]
:0.log.1
Comment 6 Adam Williamson 2009-10-30 17:05:22 EDT
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
Comment 7 Henrik Nordström 2009-11-02 19:16:33 EST
Will test in a minute. Just needs to reboot first (this box).

Chipset:
AMD RS482 aka Radeon XPress 200M
Comment 8 Adam Williamson 2009-11-02 19:33:46 EST
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
Comment 9 Henrik Nordström 2009-11-02 19:47:09 EST
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..
Comment 10 Jerome Glisse 2009-11-03 10:32:19 EST
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.
Comment 11 Adam Williamson 2009-11-03 11:24:02 EST
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
Comment 12 Henrik Nordström 2009-11-03 12:23:26 EST
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.
Comment 13 CAI Qian 2009-11-04 10:03:27 EST
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
Comment 14 Jerome Glisse 2009-11-04 11:37:52 EST
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
Comment 15 Jerome Glisse 2009-11-04 11:43:46 EST
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).
Comment 16 CAI Qian 2009-11-05 09:29:48 EST
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
Comment 17 CAI Qian 2009-11-05 09:47:40 EST
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.
Comment 18 Jerome Glisse 2009-11-05 12:42:42 EST
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.
Comment 19 Adam Williamson 2009-11-05 14:02:04 EST
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
Comment 20 Adam Williamson 2009-11-05 16:40:26 EST
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
Comment 21 Adam Williamson 2009-11-06 00:38:59 EST
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
Comment 22 CAI Qian 2009-11-06 10:06:25 EST
(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.
Comment 23 Jerome Glisse 2009-11-06 10:23:30 EST
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.
Comment 24 CAI Qian 2009-11-06 19:42:23 EST
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..
Comment 25 CAI Qian 2009-11-06 19:43:19 EST
Created attachment 367915 [details]
Xorg.0.log.old
Comment 26 CAI Qian 2009-11-06 19:46:56 EST
(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
Comment 27 CAI Qian 2009-11-06 20:05:43 EST
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).
Comment 28 CAI Qian 2009-11-06 20:23:26 EST
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.
Comment 29 Jerome Glisse 2009-11-09 03:29:51 EST
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.
Comment 30 CAI Qian 2009-11-09 07:30:49 EST
Created attachment 368195 [details]
dmesg

Here it is.
Comment 31 Jerome Glisse 2009-11-10 04:00:00 EST
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.
Comment 32 CAI Qian 2009-11-10 08:44:06 EST
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.
Comment 33 CAI Qian 2009-11-10 10:41:51 EST
Created attachment 368419 [details]
dmesg with drm.debug=15

This is without radeon.tv=0
Comment 34 CAI Qian 2009-11-10 10:49:23 EST
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.
Comment 35 CAI Qian 2009-11-10 10:50:49 EST
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.
Comment 36 CAI Qian 2009-11-10 10:52:14 EST
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.
Comment 37 Bug Zapper 2009-11-16 09:28:09 EST
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
Comment 38 Jerome Glisse 2009-11-17 13:05:12 EST
Please try if lastest kernel -134 helps :
http://koji.fedoraproject.org/koji/buildinfo?buildID=141560
Comment 39 CAI Qian 2009-11-18 08:44:18 EST
Awesome! Seems Fixed. I can switch to VT 1 to see the boot log as well. Thanks guys!
Comment 40 CAI Qian 2009-11-18 10:01:32 EST
I said this too early. The new kernel -134 will deadlock the system after browsing firefox for a while
Comment 41 CAI Qian 2009-11-18 10:05:46 EST
-127 kernel will consistently deadlock the system too; -122 kernel is fine.
Comment 42 CAI Qian 2009-11-18 10:14:28 EST
-122 kernel has the problem too. Maybe this is related to the userspace as well, since have just upgraded the whole system today.
Comment 43 CAI Qian 2009-11-18 10:21:01 EST
Same thing even without KMS. Fall back to VESA ...
Comment 44 Henrik Nordström 2009-11-18 10:27:47 EST
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?
Comment 45 CAI Qian 2009-11-19 08:57:14 EST
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
Comment 46 Jerome Glisse 2009-11-26 10:34:27 EST
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.

Note You need to log in before you can comment on or make changes to this bug.