Summary: | Zapping 1.15.0 RC3 hangs system on Radeon | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | octoploid <octoploid> | ||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||
Status: | RESOLVED WONTFIX | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | medium | ||||||||
Version: | unspecified | ||||||||
Hardware: | Other | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
octoploid
2013-11-29 16:13:35 UTC
(In reply to comment #1) > When I zap xorg-server 1.15.0 RC3 with alt-ctrl-backspace > my monitor switches off and I can't switch to another virtual console. Can you still log in via ssh at that point? Please attach the Xorg.0.log file and the output of dmesg. Preferably from after the problem occurred, or if that's not possible, from before. Created attachment 90084 [details]
Xorg log
Created attachment 90085 [details]
kernel log
(In reply to comment #1) > (In reply to comment #1) > > When I zap xorg-server 1.15.0 RC3 with alt-ctrl-backspace > > my monitor switches off and I can't switch to another virtual console. > > Can you still log in via ssh at that point? Yes. SysRq still works, too. Looks like the X server may not shut down cleanly. Is there something interesting in its stderr output? You may find it in the display manager log file(s). (In reply to comment #4) > > Can you still log in via ssh at that point? > > Yes. What happens if you try starting X again or switching VTs using chvt from ssh? (In reply to comment #5) > Looks like the X server may not shut down cleanly. Is there something > interesting in its stderr output? You may find it in the display manager log > file(s). I redirected the output of startx to a log file, but there's nothing interesting in there AFAICS. > (In reply to comment #4) > > > Can you still log in via ssh at that point? > > > > Yes. > > What happens if you try starting X again or switching VTs using chvt from > ssh? Sorry, I just assumed that ssh would work because the machine still responds to SysRq input. I cannot test this ATM. (In reply to comment #6) > I redirected the output of startx to a log file, but there's nothing > interesting in there AFAICS. I don't think the stderr output of startx captures the stderr output of the X server. Please manually start just the X server itself and redirect its stderr output instead. When I run "sudo Xorg -configure" I get: X.Org X Server 1.14.99.903 (1.15.0 RC 3) Release Date: 2013-11-23 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.13.0-rc2-dirty x86_64 Gentoo Current Operating System: Linux x4 3.13.0-rc2-00122-gdea4f48a0a30-dirty #36 SMP Tue Dec 3 10:21:14 CET 2013 x86_64 Kernel command line: BOOT_IMAGE=/bzImage root=PARTUUID=3ce070b6-a2b4-4127-9478-6ea8ceb69db7 init=/sbin/minit fbcon=rotate:3 radeon.dpm=1 drm_kms_helper.poll=0 quiet Build Date: 30 November 2013 02:14:17PM Current version of pixman: 0.32.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 3 11:07:50 2013 List of video drivers: ati radeon (++) Using config file: "/root/xorg.conf.new" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (II) [KMS] Kernel modesetting enabled. (EE) (EE) Backtrace: (EE) 0: Xorg (OsSigHandler+0x29) [0x4fc889] (EE) 1: /lib/libpthread.so.0 (__restore_rt+0x0) [0x7fe660bcc8ef] (EE) 2: /usr/lib64/xorg/modules/drivers/radeon_drv.so (RADEONPreInit_KMS+0x10f) [0x7fe660457b2f] (EE) 3: Xorg (DoConfigure+0xc78) [0x5734f8] (EE) 4: Xorg (InitOutput+0x1c9b) [0x44315b] (EE) 5: Xorg (main+0x18d) [0x426b2d] (EE) 6: /lib/libc.so.6 (__libc_start_main+0xf0) [0x7fe6605d7f90] (EE) 7: Xorg (_start+0x29) [0x4274f7] (EE) 8: ? (?+0x29) [0x29] (EE) (EE) Segmentation fault at address 0x18 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. (In reply to comment #7) > (In reply to comment #6) > > I redirected the output of startx to a log file, but there's nothing > > interesting in there AFAICS. > > I don't think the stderr output of startx captures the stderr output of the > X server. Please manually start just the X server itself and redirect its > stderr output instead. waiting for X server to shut down (II) evdev: Logitech Unifying Device. Wireless PID:4026: Close (II) UnloadModule: "evdev" (II) evdev: HID 046a:0011: Close (II) UnloadModule: "evdev" (II) RADEON(0): RADEONCloseScreen (II) Server zapped. Shutting down. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 25 requests (25 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 649 requests (649 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 11 requests (11 known processed) with 0 events remaining. xinit: connection to X server lost waiting for X server to shut down (II) evdev: Logitech Unifying Device. Wireless PID:4026: Close (II) UnloadModule: "evdev" (II) evdev: HID 046a:0011: Close (II) UnloadModule: "evdev" (II) RADEON(0): RADEONCloseScreen (In reply to comment #8) > When I run "sudo Xorg -configure" I get: Why -configure? You want to run the X server, not configure it. :) What I'm looking for, but not seeing, is this line at the end of the X server shutdown: (EE) Server terminated successfully (0). Closing log file. So it seems like the X server either dies uncleanly for you, or hangs during shutdown. In the former case, there should be more information in the X server's stderr output. The latter case will be hard to debug without ssh access I'm afraid. I don't have the time and the resources to debug this further. Closed. |
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.