Re: killing dead cdrecord processes

2001-07-24 Thread Drew Parsons
Joost Kooij wrote: >> The state is "D", which means uninterruptible: the processes do not >> respond to kill -9. > >They will, once they can be interrupted again. Is that realistic? Will the process actually drop back to an interruptible state? How long would be a reasonable amount of time to ex

Re: killing dead cdrecord processes

2001-07-22 Thread Ari Pollak
Blech. What kernel version are you using? My USB CompactFlash reader (also usb-storage) would constantly stop responding and screw up the processes that were using it - forcing me to reboot my machine. I think it finally got fixed either around kernel version 2.4.6, or because I got a new motherboa

Re: killing dead cdrecord processes

2001-07-22 Thread Joost Kooij
On Sun, Jul 22, 2001 at 02:46:55PM +1000, Drew Parsons wrote: > I've been trying to burn a CD using gcombust. > > For some reason the burn got stuck halfway through (the output of > cdrecord, which gcombust calls, said that all of a sudden one of the > SCSI commands couldn't be understood. It's

killing dead cdrecord processes

2001-07-22 Thread Drew Parsons
I've been trying to burn a CD using gcombust. For some reason the burn got stuck halfway through (the output of cdrecord, which gcombust calls, said that all of a sudden one of the SCSI commands couldn't be understood. It's a HP USB CDWriter using the usb-storage module, which uses a series of