I'm seeing one anomaly with PR2, resulting in an unkillable process that is
*not* in Device Wait.
1. The cdrom device:
brw-rw---- 1 alane disk 11, 0 Dec 31 1969
/dev/scsi/host0/bus0/target3/lun0/cd
2. I am a member of the "disk" group.
If cdda2wav is not setuid root, which I really don't want it to be, it
seems, about 90% of the time, to get locked in "R" state, *not* reading the
cdrom drive, using as much CPU as it can, and immune to kill -9. It's also
immune to tracing ... any attempt to trace it results in strace locking up,
and becoming a member of the undead also. That's pretty neat ... so not only
can't you kill cdda2wav, you can't kill the strace, either.
How can a process, running as a regular user, in the R state, actively
spinning its wheels, be immune to a kill -9? And now can it pass that
immunity on? This is *weird*.
After a few seconds of cdda2wav spinning like this, the keyboard and mouse
both lock up. No ctl-atl-backspace.... no nothing.
Only way to clear the condition is to kill the process by the only way
possible: /sbin/shutdown. Note that it does not die as part of the shutdown
killall, either, but hey, a reboot is a reboot.
The machine is not locked up, though, just the local input devices. I can
shut it down (and this is the only way) by ssh'ing in over the LAN to issue
the shutdown.
OK, now for the punchline: the SCSI controller is .... an Adaptec 2930CU.
Yup, it's on the aic7xxx driver. The CDRW, also on the Adaptec (at target
4), is blissfully unaffected by the hubub going on around it.
It would seem that no diagnostics are possible. How can you debug an
uninterruptible, non-waiting process that hangs anything trying to attach to
it?
This behavior does not occur on PR1, which is presumably the same except for
the XFS code, right? However, this behavior is quite reproducible, for all
the good that does me.
--
Alan Eldridge
"Smart Tags? We don't need no steenking Smart Tags!"
|