On 2013-01-04 Stefan Richter wrote: > As yo may have seen in the mailinglist archive, when Wakko and I tested > with sr_mutex removed without any replacement, we were not able to trigger > any race condition. However, we certainly did not attempt this very > particular test (two drives on the same PATA cable, one locked and one > unlocked, and "eject" called on both of them at the same time). I wonder > if this is a PATA idiosyncrasy.
Reading from two devices connected to different PATA cables or controllers via ioctl is working quite fine with the patch, so that seems to be in line with your and Wakko's findings. Running the eject test on the same device combination seems to be mostly fine. I'm saying "mostly" because sometimes drives stay locked when I expect them to be unlocked, but I haven't been able to reproduce that reliably. A few times drives even stayed locked with the tray ejected(!), i.e. I couldn't close the drive via its eject button and had to run eject -t. As dev.cdrom.lock=0 seems to be ignored even without the patch, I'm not sure whether the locking issue is caused or just amplified by the patch. Another note regarding the eject test with two devices connected to the same PATA cable: If both drives are unlocked, they eject fine, but sequentially. Something seems to be trying to prevent interference between the two drives, but it's not working properly once unlocking is involved. -- Otto Meta -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
