> It happens on anything after 2.6.24 (cfr. > http://bugzilla.kernel.org/show_bug.cgi?id=10974). > E.g. mainline 2.6.27-rc8. Ah. 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. Monty -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
