lkml.org 
[lkml]   [2006]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: CD-blanking leads to machine freeze with current -git
    * 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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-02-11 16:28    [W:2.755 / U:0.260 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site