I think I found the problem (or atleast a problem). The code path for the eject
-s is also in block/scsi_ioctl.c. In sg_io, it pretty much does the same thing
we do for CDROMEJECT (but uses the data passed by the user to fill in the req).
However, there is one big difference. The sg_io code path will set the req to
READ for the eject -s req's, while CDROMEJECT sets it to WRITE. Bug? I think so,
because the ll_rw_blk.c stuff will eventually error because of the
data_len==0/type=WRITE combination.
Not sure why this only affects some devices, but it surely isn't correct.
Ok, new kernel, same location (.3 this time).
I think I found the problem (or atleast a problem). The code path for the eject =0/type= WRITE combination.
-s is also in block/scsi_ioctl.c. In sg_io, it pretty much does the same thing
we do for CDROMEJECT (but uses the data passed by the user to fill in the req).
However, there is one big difference. The sg_io code path will set the req to
READ for the eject -s req's, while CDROMEJECT sets it to WRITE. Bug? I think so,
because the ll_rw_blk.c stuff will eventually error because of the
data_len=
Not sure why this only affects some devices, but it surely isn't correct.
Please test and let me know.