Hi, On Wed, Jun 21, 2006 at 12:15:08PM -0400, Alan Stern wrote: > On Wed, 21 Jun 2006, Andreas Mohr wrote: > > - TEST_UNIT_READY > > - TEST_UNIT_READY > > - READ_TOC (failure?) > > I don't know why this failed. Maybe the disc didn't have a valid Table of > Contents.
Ah, silly me, I should have stated that this was a simulation burn on an otherwise rather blank disc ;) > > - 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!). > > It sure does look like the ALLOW_MEDIUM_REMOVAL is the cause of the > problem. Yup, already was quite sure of that after having written the previous mail. I'll try to verify this by simply removing all ALLOW_MEDIUM_REMOVAL calls ;) > > 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. > > Yep. The ALLOW_MEDIUM_REMOVAL occurs as part of handling the close(). > And you can understand a CD drive not wanting to carry out a long write > when the door is unlocked. > > The real problem seems to be that the device is reachable in two different > ways, and they don't implement proper mutual exclusion. HAL (or your test > program) is undoubtedly using /dev/sr0 or something similar, whereas > cdrecord uses /dev/sg0. Going through two different drivers, it's no > surprise they wind up interfering with each other. HAL is /dev/host0/.../cd cdrecord is -dev=0,0,0 (whatever Linux device file this translates into) or a similar device ID as returned by -scanbus. Probably (stating the obvious here, I'm afraid) we should only send non-ALLOW_MEDIUM_REMOVAL for the *very first* device open, and then send ALLOW_MEDIUM_REMOVAL after the *very last* device close only. So you think that with sr and sg drivers both talking to the device, proper inter-driver device tracking is not doable or quite difficult to implement? > Unfortunately I can't debug this without seeing the start of the oops > message. [OOPS output of a *different* issue] Right, it's a rather incomplete OOPS. Let me try to get one with a nice long-line VGA mode soon... 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
