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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
