[lkml]   [2008]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [regression] CD-DA delay needed after insertion (
    > It happens on anything after 2.6.24 (cfr.
    > E.g. mainline 2.6.27-rc8.


    Geert, I'm sorry this has come up and thanks for bringing it to my attention.

    I'm relying on 15 year old behavior. It has always been the case that
    the packet pass-through interfaces treat O_NONBLOCK as 'don't wait for
    commands' (ie, classic async communication or, in the case of SGIO,
    don't block on mandatory locks) not 'change how you mediate the
    communication'. The whole point of the passthrough interface is
    'please don't fuck with the packet stream. My userspace application
    knows better than the kernel in this case'. If the kernel has
    suddenly changed that, it is responsible for the loss of
    functionality, not cdparanoia.

    It is also the case that the kernel randomly interspersing its own
    packets, commands and setup would be yanking setup state out from
    under cdparanoia. What am I supposed to do if I set density and
    completely change the data mode of a cdrom drive (persistent across
    disc changes), or change the block descriptor caching extents, only to
    have the kernel decide to change them back without warning? If you
    eject media with one of these new kernels, do I still get any
    meaningful sense state, or is the sense key and all subsequent
    commands merely intercepted and refused? What happens on a timeout?
    A media error? A bus reset? Does any 'CHECK CONDITION' status
    completely yank the rug out from under the passthrough?

    The kernel must not interfere with the pass-through or cdparanoia is
    castrated. Or... I'm back to the era of enacting workarounds based on
    kernel dot-version. Regardless, this is a change to a longstanding
    behavior. Is it on purpose, unintentional or 'intentional but without
    realizing it was actually important'? Would be interesting to know.

    > In this case, sg means scatter/gather, and it's a purely internal
    > interface. It does not start/stop the drive, nor the scsi interface.

    Ah, I confused it with a much older utility that would up/down an SG
    device entirely.


     \ /
      Last update: 2008-09-30 20:13    [W:0.040 / U:10.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site