| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Jul 2009 19:21:59 +1000 From: Dave Airlie <airlied@...il.com> To: Andreas Mohr <andi@...as.de> Cc: Dave Airlie <airlied@...ux.ie>, Andrew Morton <akpm@...ux-foundation.org>, Roberto Oppedisano <roppedisano@...racomspa.it>, LKML <linux-kernel@...r.kernel.org>, dri-devel@...ts.sourceforge.net Subject: Re: drm:radeon_cp_idle/reset error storm, console lockup (-rc4 git) > > encountered this problem myself, was able to regain access only via > remote login, then saw tons of (ratelimited) > > [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner dc6513c0 > dc6513c0 > [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, > held 0 owner dc6513c0 dc6513c0 > [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, > held 0 owner dc6513c0 dc6513c0 > [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, > held 0 owner dc6513c0 dc6513c0 > > dmesg output. > > Did Alt-SysRq-T, related result part is: > > Xorg D 00000001 0 3867 3864 0x00400000 > dc686cb8 00003082 dfabeb70 00000001 00000003 dc66bbb0 dc66be28 00003282 > dfba0e40 dc537520 00003282 00003246 01ca5259 dfba0e00 dfba0e40 dc686ce8 > c115c4a5 00000000 dfba0e50 00000000 dc66bbb0 c1040b90 dfba0e40 dfba0e40 > Call Trace: > [<c115c4a5>] log_wait_commit+0x75/0xd0 > [<c1040b90>] ? autoremove_wake_function+0x0/0x50 > [<c115c618>] journal_force_commit_nested+0x38/0x60 > [<c110dc81>] ext3_should_retry_alloc+0x51/0x60 > [<c1114810>] ext3_write_begin+0x190/0x240 > [<c1112eb0>] ? ext3_get_block+0x0/0xf0 > [<c1079c16>] generic_file_buffered_write+0xe6/0x2a0 > [<c107a23b>] __generic_file_aio_write_nolock+0x22b/0x4e0 > [<c129d1f6>] ? radeon_cp_reset+0x76/0xf0 > [<c1283dda>] ? drm_ioctl+0x1da/0x370 > [<c107ae5b>] generic_file_aio_write+0x5b/0xd0 > [<c110f89d>] ext3_file_write+0x2d/0xc0 > [<c10a08f1>] do_sync_write+0xd1/0x110 > [<c1040b90>] ? autoremove_wake_function+0x0/0x50 > [<c10acd8a>] ? do_vfs_ioctl+0x6a/0x590 > [<c1024eaf>] ? set_next_entity+0x11f/0x1a0 > [<c10a13cc>] vfs_write+0x9c/0x160 > [<c1397f36>] ? schedule+0x376/0x4c0 > [<c10a0820>] ? do_sync_write+0x0/0x110 > [<c10a154d>] sys_write+0x3d/0x70 > [<c1002d35>] syscall_call+0x7/0xb > > > System: Debian testing, Athlon XP, new update to xserver-xorg-core to 2:1.6.2.901-1 from 1.6.2 > (but I had desktop lockups slightly earlier already, and I'm pretty sure that was this). > ii xserver-xorg-video-radeon 1:6.12.2-3 X.Org X server -- ATI Radeon display driver > > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01) > > So, is there some userspace waiting to be fixed here? > > And is there any way to implement damage control? It's not overly nice to have joe random > userspace app being able to FUBAR an entire desktop, by forgetting an "important" lock. :) > > > Xorg.0.log parts: > > (II) ImPS/2 Generic Wheel Mouse: Configuring as mouse > (**) ImPS/2 Generic Wheel Mouse: YAxisMapping: buttons 4 and 5 > (**) ImPS/2 Generic Wheel Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 > (II) XINPUT: Adding extended input device "ImPS/2 Generic Wheel Mouse" (type: MOUSE) > (**) ImPS/2 Generic Wheel Mouse: (accel) keeping acceleration scheme 1 > (**) ImPS/2 Generic Wheel Mouse: (accel) filter chain progression: 2.00 > (**) ImPS/2 Generic Wheel Mouse: (accel) filter stage 0: 20.00 ms > (**) ImPS/2 Generic Wheel Mouse: (accel) set acceleration profile 0 > (II) ImPS/2 Generic Wheel Mouse: Device reopened after 8 attempts. > (II) config/hal: Adding input device ImPS/2 Generic Wheel Mouse > (**) ImPS/2 Generic Wheel Mouse: always reports core events > (**) ImPS/2 Generic Wheel Mouse: Device: "/dev/input/event4" > (WW) ImPS/2 Generic Wheel Mouse: device file already in use. Ignoring. > (II) UnloadModule: "evdev" > (EE) PreInit returned NULL for "ImPS/2 Generic Wheel Mouse" > (EE) config/hal: NewInputDeviceRequest failed (8) > (II) config/hal: removing device ImPS/2 Generic Wheel Mouse > (II) ImPS/2 Generic Wheel Mouse: Close > (II) UnloadModule: "evdev" > > Backtrace: > 0: /usr/bin/X(xorg_backtrace+0x3b) [0x813141b] > 1: /usr/bin/X(xf86SigHandler+0x51) [0x80c55d1] > 2: [0xffffe400] > 3: /usr/bin/X(BlockHandler+0x94) [0x8090244] > 4: /usr/bin/X(WaitForSomething+0x124) [0x812edc4] > 5: /usr/bin/X(Dispatch+0x7e) [0x808c4de] > 6: /usr/bin/X(main+0x3aa) [0x8071ada] > 7: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7c45775] > 8: /usr/bin/X [0x8070fa1] > > Fatal server error: > Caught signal 11. Server aborting > > > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > Please also check the log file at "/var/log/Xorg.0.log" for additional information. > > (II) AT Translated Set 2 keyboard: Close > (II) UnloadModule: "evdev" > (II) AIGLX: Suspending AIGLX clients for VT switch > (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22 > (EE) RADEON(0): Idle timed out, resetting engine... > (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -22 > (EE) RADEON(0): RADEONWaitForIdleCP: CP start -22 > (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22 > (EE) RADEON(0): Idle timed out, resetting engine... > (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -22 > (EE) RADEON(0): RADEONWaitForIdleCP: CP start -22 > (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22 > (EE) RADEON(0): Idle timed out, resetting engine... > (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -22 > (EE) RADEON(0): RADEONWaitForIdleCP: CP start -22 > (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22 > (EE) RADEON(0): Idle timed out, resetting engine... > (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -22 > (EE) RADEON(0): RADEONWaitForIdleCP: CP start -22 > (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -22 > > > [etc.etc. ad nauseam] > > I'm throwing an uneducated guess that this log means that there's some locking-up drm inconsistency > during server crash shutdown (subsystem shutdown order violation?) > which is rendering my entire machine useless, including blocking tty access. Pretty much X dies, tries to get the GPU driver to go back to text mode, this re-enters somewhere holding the drm lock and the GPU dies. Pretty much sums up the whole problem with graphics card drivers on Linux, I can't say how we can fix that apart from if you could gdb the X server and we can fix the actual crash so we can avoid the issue. The real fix for this sort of issues is called kernel modesetting. Dave. > > Thanks a lot, > > Andreas Mohr > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists