On (Fri) 01 Apr 2011 [17:43:27], Tejun Heo wrote: > Hello, > > On Thu, Mar 31, 2011 at 11:50:04PM +0530, Amit Shah wrote: > > After the first GET_EVENT_STATUS_NOTIFICATION command, any new media > > notification is reset by the device. The following is then noticed: > > > > 1. insert a CD of a particular size > > 2. mount it > > 3. note /sys/block/sr0/size > > 4. unmount cd > > 5. replace cd with a size greater than previous one > > 6. mount it > > 7. /sys/block/sr0/size isn't updated > > 8. copy all files from cd to somewhere; IO errors will pop up where the > > files lie beyond previous CD's geometry > > > > The cause is: > > > > cdrom_open() > > open_for_data() > > cdo->drive_status() = sr_drive_status() > > cdrom_get_media_event() > > --> GPCMD_GET_EVENT_STATUS_NOTIFICATION > > --> med.media_present is true, return CDS_DISK_OK > > (success) > > check_disk_change() > > ... -> 2nd call to GPCMD_GET_EVENT_STATUS_NOTIFICATION > > > > at this point the device has already reset the new media event and the > > call to revalidate_disk() in check_disk_change() is never made. > > Hmm... I see. That's something I didn't expect. ... > But I don't think this is the correct place to do it. The problem > happens because block layer consumes the event but doesn't remember it > when the time for revalidation comes. It should be done by block > layer, not sr. Hm, only the open call at the start of the call sequence is involved from the block layer. How to pass on such a pending event back? Some kind of an event array with helpers to modify it? Amit -- 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
