On Thu, 18 Mar 2010, Jeff Garzik wrote: > On 03/18/2010 06:23 PM, Alan Stern wrote: > > On Thu, 18 Mar 2010, Jeff Garzik wrote: > > > >> Removing 61-option-modem-modeswitch.rules completely yields substantial > >> progress. A large number of SCSI commands are successfully processed, > >> eventually proceeding to a loop: > >> > >> [non-looping initial bit] > >>> hub 4-0:1.0: over-current change on port 7 > >>> usb 3-2: new full speed USB device using uhci_hcd and address 2 > >>> usb 3-2: New USB device found, idVendor=04e8, idProduct=6640 > >>> usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > >>> usb 3-2: Product: SAMSUNG CDMA Technologies > >>> usb 3-2: Manufacturer: SAMSUNG Electronics Bo.,Ltd. > >>> cdc_acm 3-2:1.0: ttyACM0: USB ACM device > >>> usbcore: registered new interface driver cdc_acm > >>> cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters > >>> usb 3-2: USB disconnect, address 2 > >>> usb 3-2: new full speed USB device using uhci_hcd and address 3 > >>> usb 3-2: New USB device found, idVendor=05c6, idProduct=1000 > >>> usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > >>> usb 3-2: Product: USB MMC Storage > >>> usb 3-2: Manufacturer: Qualcomm, Incorporated > >>> usb 3-2: SerialNumber: 000000000002 > >>> Initializing USB Mass Storage driver... > >>> scsi6 : usb-storage 3-2:1.0 > >>> usbcore: registered new interface driver usb-storage > >>> USB Mass Storage support registered. > >>> scsi 6:0:0:0: Direct-Access Qualcomm MMC Storrage 2.31 PQ: 0 ANSI: 2 > >>> sd 6:0:0:0: Attached scsi generic sg4 type 0 > >>> sd 6:0:0:0: [sdd] 3932161 512-byte logical blocks: (2.01 GB/1.87 GiB) > >>> sd 6:0:0:0: [sdd] Write Protect is off > >>> sd 6:0:0:0: [sdd] Assuming drive cache: write through > >>> sd 6:0:0:0: [sdd] Assuming drive cache: write through > >>> sdd: sdd1 > >>> sd 6:0:0:0: [sdd] Assuming drive cache: write through > >>> sd 6:0:0:0: [sdd] Attached SCSI removable disk > >> > >> [endless loop bit] > >>> sd 6:0:0:0: [sdd] Media Changed > >>> sd 6:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > >>> sd 6:0:0:0: [sdd] Sense Key : Unit Attention [current] > >>> sd 6:0:0:0: [sdd] Add. Sense: No additional sense information > >>> sd 6:0:0:0: [sdd] CDB: Read(10): 28 00 00 3c 00 00 00 00 01 00 > >>> end_request: I/O error, dev sdd, sector 3932160 > >>> Buffer I/O error on device sdd, logical block 3932160 > >>> sd 6:0:0:0: [sdd] Assuming drive cache: write through > >>> sd 6:0:0:0: [sdd] Assuming drive cache: write through > >>> sdd: sdd1 > > > > This looks like a familiar firmware bug. Notice the sector number; > > it's the very last one. Most likely this device reports that the > > medium has one more sector than it really does have. > > > > You didn't say which kernel produced this output; I kind of hope the > > most recent 2.6.34 version would do a better job of error recovery. > > The latest 2.6.34-rc1-git kernel, as of a couple hours ago, produced > that output. Sorry for the omission. Can you provide a usbmon trace showing a few iterations of that I/O error loop? Maybe I'll be able to figure out a way to handle it automatically without any need for quirk entries. > > Regardless, you can work around the last-sector problem by loading > > usb-storage with the module parameter "quirks=5c6:1000:f". Whoops! That should have been "quirks=5c6:1000:c", not ":f". I misread my own code. :-( Sorry about that. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
