Current rawhide - kernel 2.6.27-0.186.rc0.git15.fc10 At gdm startup, something goes wrong on my system. gdb gets started - presumably to trace the problem - and then the kernel emits an oops in get_utrace_lock_attached. The system is then soft-locked. 60s later I get a BUG: soft lockup from gdm-binary. Unfortunately, since the system is locked, it's hard to get full oops logs. Here's a summary of the soft lockup trace: __delay _raw_spin_lock _spin_lock finish_callback ? ptrace_report_signal utrace_get_signal ? check_object ? ptrace_report_signal get_signal_to_deliver ? trace_hardirqs_on do_notify_resume ? remove_wait_queue ? trace_hardirqs_on_caller ? trace_hardirqs_on ? do_wait ? default_wake_function ? path_put work_notifysig I'll try to get info on the original Oops, but it's tricky, since I only get 60 seconds to copy info down before the soft lockup BUG is triggered.
Here's what I could copy down in those 60s: utrace_control ptrace_detach_utrace ptrace_attach sys_ptrace syscall_call __mutex_unlock_slowpath EIP: [<c045fa72>] get_utrace_lock_attached+0x5e/0x91 SS:ESP 0068:f2b89f44
kernel 2.6.27-0.166.rc0.git8.fc10 (the kernel currently tagged for F10Alpha) does not have this bug. The gdm crash that triggers this seems to have been brought on by an SELinux denial. Booting with 'enforcing=0' works fine.
So can this be closed, or is it still happening?
Well, the kernel bug that was triggering this is fixed, so it's hard to tell if the gdb + utrace lockup is still around. Still, I tried killing Xorg off while gdm was up (killall -SEGV Xorg) and nothing bad happens, and there have been plenty of other X crashes that didn't cause anything like this. So unless someone came up with a better way to reproduce the old trigger, I'd consider it fixed.