On Tue, 1 Apr 2008, Hans de Goede wrote:
Reverting the patch is easy, edit drivers/usb/storage/scsiglue.c and remove the following line:
" sdev->last_sector_bug = 1;"
Which should be close to line 193 (it is 193 in my source tree, but thats a bit stale).
The old way was not necessarily correct for this type of device bug. OnlyIf the splitting of the request is the cause, yes then it looks like that.
that it had a very high chance of not appearing.
When discussing the last bug, it was said to enable it by default for USB
instead of using blacklists. It looks like this bug, or the other, needs a
blacklist.
But to me it looks like this is a 4k thing. I think Windows will alwaysI'm pretty sure the last sector must only be read by itself bug (for lack of a better name) is present under windows too, but won't be triggered as windows normally doesn't access the last sector, where as various pieces of Linux routinely probe the end of the disk, for detection of exotic partition types/ disklabes.etc.
use 4k for FAT, though never triggering either of the bugs.
The one submitting the last sector patch was, I think, Hans de Goede (CCed)Correct I wrote the split up requests which touch the last sector changes to the scsi disk handling, and a seperate patch to always set the flag which enables the splitting for usb disks.
Hans ?
If I read last 8 sectors (4k) on a device that exhibits the "last sector bug"I just tried and I'm afraid not, an 8 sector read which includes at the last sector completely kills the device, no other transfers to / from the device will work until the sdcard is removed and reinserted (the troublesome device is a card reader build into a multi function printer, one gets what one pays for).
Does it work? (Is 8 a magic number here)
It sounds like the last_sector_bug setting should be conditional on a blacklist entry. As far as I know it affects only a small proportion of devices; most are fine with multi-sector reads at the end.