Hi, On Tue, Jun 20, 2006 at 10:22:57AM -0400, Alan Stern wrote: > 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.
OK, at http://lisas.de/~andi/temp_usb/ there are logs: debug.log.gz: burning, then running my open() test app: test app started at 22:43:49, disrupted burning process. only_device_open.log.gz: device open() *only* (plus close()!), no other USB activity such as burning happening (for comparison purposes, to see what a usual open()/close() is like) only_device_open.log.gz (and close()!) contains: - TEST_UNIT_READY (failure?) - TEST_UNIT_READY - TEST_UNIT_READY - READ_TOC (failure?) - ALLOW_MEDIUM_REMOVAL - (unknown command) !!!!!!! - TEST_UNIT_READY - READ_TOC (failure?) - READ_TOC (failure?) - READ_CAPACITY - ALLOW_MEDIUM_REMOVAL Hmm, multiple failures in there: might be cable issues?? debug.log.gz contains: *** ongoing burning: *** - lots of WRITE_10 (NO failure!) - READ BUFFER CAPACITY - lots of WRITE_10 (NO failure!) - READ BUFFER CAPACITY - a couple WRITE_10 (NO failure!) *** [22:43:49] device open(): *** - TEST_UNIT_READY (ok!) - WRITE_10 (ok!!) - TEST_UNIT_READY (ok!) - WRITE_10 (ok!) - READ_TOC (*** ERROR!! ***) - WRITE_10 (ok!) - ALLOW_MEDIUM_REMOVAL (ok!) - WRITE_10 (*** FAILURE! ***) - going downhill from here... So what could be the problem here? READ_TOC might be it, but then it might be fully ok to have it fail (after all it's non-valid data content), so ALLOW_MEDIUM_REMOVAL would be the problem then? (next WRITE_10 FAILS!). I could be totally wrong, though, since I don't have much storage debugging experience. A good idea would be to further check whether it's the open() or the close() which disrupts burning for me. > I can't tell what's going on with the USB HDD since you haven't provided > any information. I'd like to, but can't since I don't have device access any more. Oh, and that burner_switchoff_oops.jpg in the same directory is an OOPS that happened when I tried to blank a CDRW, then cancelled the operation (2x Ctrl-C on cdrecord), but then had HAL device polling daemon and my test app block on I/O wait on the device that continued blanking the CDRW. Since I then didn't want to wait for the blanking to finish I had to switch off the device: immediate OOPS, possibly due to mis-handling the two processes still waiting on a busy device which then got switched off completely. Kernel 2.6.17-rc6-mm2. Thanks! Andreas Mohr _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
