Re: CD-blanking leads to machine freeze with current -git

[Marc Koschewski <marc@osknowledge.org>]

* Jan Engelhardt <jengelh@linux01.gwdg.de> [2006-02-11 16:16:58 +0100]:

> >
> > If that is what is going on, there is nothing linux can do about it; it's a
> > limitation of the hardware.  The IDE controller can only accept one command at
> > a time, so if that command takes a while to complete, the other drive on the
> > same channel can not be accessed until the first command completes. 
> 
> CD blanking only takes "one" command for the whole operation, as 
> e.g. compared to CD writing where you always have to push out data packets.

The cdrecord man page says this:

	Setting the -immed flag will request the command to return immediately while
	the operation proceeds in background, making the bus usable for the other
	devices and avoiding the system freeze.  This is an experimental feature which
	may work or not, depending on the model of the CD/DVD writer.  A correct 
	solution would be to set up a correct cabling but there seem to be notebooks
	around that have been set up the wrong way by the manufacturer.  As it is
	impossible to fix this problem in notebooks, the -immed option has been added.

It how can the bus run the command sent on the device 'in the background' when
it can only process _one_ request at a time?

To me it sound like the foreground process (cdrecord) fork()s a process to blank
the CD-RW. Clear. But you said the bus is not able to do so... I'm not getting
this.

> 
> Why I think it's just one (note the quotes): You can interrupt/kill 
> cdrecord in the midst of blanking a CD, and blanking will continue to the 
> 'end' (either fast blank or full blank, whichever was sent)
> 
> As mentioned some time earlier, I had similar, but not the same issues. I 
> could continue accessing the harddrive - otherwise mplayer would have 
> stopped immediately, but it played at least until EOF.
> 
> > If the system doesn't come back though after sufficient time has gone by for
> > the burn to complete, then this is probably not what is happening.  I'd suggest
> > using magic-sysreq to force an unmount and reboot, then see if there's anything
> > in the logs. 
> 
> 
> Jan Engelhardt
> -- 
> 

Marc