Le dimanche 20 janvier 2008 à 15:03 -0600, James Bottomley a écrit : > On Sun, 2008-01-20 at 12:56 -0800, Greg KH wrote: > > On Sun, Jan 20, 2008 at 11:27:29AM +0100, Hans de Goede wrote: > > > Hi all, > > > > > > This patch sets the last_sector_bug flag to 1 for all USB disks. This is > > > needed to makes the cardreader on various HP multifunction printers work. > > > > > > Since the performance impact is negible we set this flag for all USB disks > > > to avoid an unusual_devs.h nightmare. > > > > Oh great, now my "working just fine" USB devices, which happen to have > > data in the last sector, suddenly stop working. > > > > That's not acceptable :( > > I don't see how this will happen, might you not be confusing this change > (which allows access to the last sector, just insists that it be > accessed by a single sector read) with US_FL_FIX_CAPACITY which is for > devices that report having one more sectors than they actually have and > therefore adjusts the access limits down by one? Well, i was the one suggesting more than 2 devices might be impacted (i'm absolutely not sure about this, but it could be). It seems caused by a common error when using 0 as a base index. I don't like loosing performance for broken devices, but i'm not against keeping that patch for all devices. 1) As the last sectors are read when the card is inserted, it results in not working at all devices : Users may think they are just not supported, and won't report any bug. See how Hans worked hard to find 3 other cases in fedora, ubuntu, etc forums ! 2) It should not break in the other cases, IIUC, it just splits the read in two. 3) It's just about the last sector, so any issue should only be greater timing when using realtime perhaps ? Whatever, this patch, or an other form of it, is needed (because of 1) ). If it is a default, an option or dedicated to a limited set of devices must be chosen. I hope you will soon find this solution. Best regards, Guillaume B. - 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
