On Tue, 20 Jun 2006, Andreas Mohr wrote: > But how would HAL safely determine whether a (IDE/USB) drive is busy? > As my test app demonstrates (without HAL running), the *very first* open() > happening during an ongoing burning operation will kill it instantly, in the > USB case. > Are there any options left for HAL at all? Still seems to strongly point > towards a kernel issue so far. > > One (rather less desireable) way I can make up might be to have HAL > keep the device open permanently and do an ioctl query on whether it's "busy" > and then quickly close the device again before the newly started > burning process gets disrupted (if this even properly works at all).
The open() call is not in itself the problem. I would guess that the problem is sparked by the TEST UNIT READY command automatically sent when the device file is opened. Although a drive should have no difficulty handling this command while carrying out a burn, apparently yours aborts. In other words, this is likely to be a firmware problem in the CD drive. I can't tell what's going on with the USB HDD since you haven't provided any information. If you want to find out what's actually happening instead of just guessing, turn on CONFIG_USB_STORAGE_DEBUG and see what the kernel log has to say for the time when the underrun/reset occurs. Alan Stern _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
