USB serial regression 2.6.31.1 -> 2.6.31.2
in [Kernel]
|
From: Ben Efros on 10 Oct 2009 20:40 ----- "Alan Stern" <stern(a)rowland.harvard.edu> wrote: > The device presented two LUNs on the mass-storage interface. LUN 0 > was > the emulated CDROM (named "Mass Storage") and LUN 1 was direct-access > > (named "SD Storage"). LUN 0 appeared to work normally, although it > reported Not Ready, No Medium Present errors. LUN 1 did the same > thing, but in its response to the REQUEST SENSE command it set the > additional-sense-length byte to 0x12 instead of 0x0a, for no apparent > reason. This caused usb-storage to assume the device supported SANE > SENSE, which presumably it doesn't. > <SNIP> > > Thus the two bugs in the Huawei device are: Incorrect > additional-sense-length byte for LUN 1, and incorrect CSW for a > 96-byte > REQUEST SENSE on LUN 1. > > I can see two approaches for working around this. The first is to > make > the SENSE SENSE test more discriminating. For example, test for > additional-sense-length values larger than 0x12 instead of larger > than > 0x0a. Ben Efros, would this be acceptable? > > The second approach is to add a SINGLE_LUN flag to all the Huawei > entries in unusual_devs.h. It's not clear that this is a good idea; if > one of those devices really does have an SD card then people might want > to be able to use it. Most SAT devices will never set an additional sense length value higher than 0x0e on the Descriptor Format Sense Data when returning an ATA Return Descriptor. I'd prefer not to arbitrarily set the range check to be > 0x12 for SANE_SENSE to kick in. If that is the ultimate solution, then I'd rather see the whole SANE_SENSE detection if-block removed in its entirely. I really don't think that will be necessary. Both proposed solutions seem to have their drawbacks. Maybe its time to start noting buggy devices that are known to be "insane" in regards to sense data. If the device has usb flag "INSANE_SENSE" then we'll never ever set SANE_SENSE. Ben Herrenschmidt's patch[1] to retry without SANE_SENSE might be combined be able to be used to detect this 'INSANE_SENSE' scenario, but not in its current form. Devices lying about the "additional sense length" doesn't seem all that common, so it might be better to just flag the device as insane and not worry about reworking Ben Herrenschmidt's patch. [1] http://lkml.org/lkml/2009/10/10/211 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 11 Oct 2009 18:53 On Sun, 11 Oct 2009, Benjamin Herrenschmidt wrote: > On Sun, 2009-10-11 at 08:20 +1100, Benjamin Herrenschmidt wrote: > > > Yes, that works, you can see the ttyUSBx ports showing up. It looks like > > it may just be the resets coming from usb-storage that are breaking > > things. > > Ok so I did a quick hack to usb-storage, basically put the block that > tests for the response size and sets USB_FL_SANE_SENSE into an #if 0 : > Now, the result in the dmesg log is : > > Oct 11 09:04:05 pasglop kernel: [ 52.916100] usb 4-1: new full speed USB device using uhci_hcd and address 2 > Oct 11 09:04:05 pasglop kernel: [ 53.076402] usb 4-1: configuration #1 chosen from 1 choice > Oct 11 09:04:06 pasglop kernel: [ 53.104090] Initializing USB Mass Storage driver... > Oct 11 09:04:06 pasglop kernel: [ 53.105405] scsi2 : SCSI emulation for USB Mass Storage devices > Oct 11 09:04:06 pasglop kernel: [ 53.105585] usbcore: registered new interface driver usb-storage > Oct 11 09:04:06 pasglop kernel: [ 53.105589] USB Mass Storage support registered. > Oct 11 09:04:06 pasglop kernel: [ 53.107164] usb-storage: device found at 2 > Oct 11 09:04:06 pasglop kernel: [ 53.107167] usb-storage: waiting for device to settle before scanning > Oct 11 09:04:06 pasglop kernel: [ 53.224104] usb 4-1: USB disconnect, address 2 > Oct 11 09:04:06 pasglop kernel: [ 53.960100] usb 4-1: new full speed USB device using uhci_hcd and address 3 > Oct 11 09:04:11 pasglop kernel: [ 54.121941] usb 4-1: configuration #1 chosen from 1 choice > Oct 11 09:04:11 pasglop kernel: [ 54.140861] scsi6 : SCSI emulation for USB Mass Storage devices > Oct 11 09:04:11 pasglop kernel: [ 54.143007] usb-storage: device found at 3 > Oct 11 09:04:11 pasglop kernel: [ 54.143010] usb-storage: waiting for device to settle before scanning > Oct 11 09:04:11 pasglop kernel: [ 59.141422] usb-storage: device scan complete > Oct 11 09:04:11 pasglop kernel: [ 59.144370] scsi 6:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2 > Oct 11 09:04:11 pasglop kernel: [ 59.147379] scsi 6:0:0:1: Direct-Access HUAWEI SD Storage 2.31 PQ: 0 ANSI: 2 > Oct 11 09:04:11 pasglop kernel: [ 59.169383] sr1: scsi-1 drive > > At which point nothing happens for a while (and no serial stuff shows up). > > If I yank the device, I then see: > > Oct 11 09:05:28 pasglop kernel: [ 59.169494] sr 6:0:0:0: Attached scsi CD-ROM sr1 > Oct 11 09:05:28 pasglop kernel: [ 59.169563] sr 6:0:0:0: Attached scsi generic sg2 type 5 > Oct 11 09:05:28 pasglop kernel: [ 59.169668] sd 6:0:0:1: Attached scsi generic sg3 type 0 > Oct 11 09:05:28 pasglop kernel: [ 59.227809] sd 6:0:0:1: [sdb] Attached SCSI removable disk > Oct 11 09:05:28 pasglop kernel: [ 71.048322] ISO 9660 Extensions: Microsoft Joliet Level 1 > Oct 11 09:05:28 pasglop kernel: [ 71.057316] ISOFS: changing to secondary root > Oct 11 09:05:28 pasglop kernel: [ 128.369159] usb 4-1: USB disconnect, address 3 > Oct 11 09:05:28 pasglop kernel: [ 128.429675] scsi 6:0:0:0: rejecting I/O to dead device The printk timestamps indicate that the first four lines above happened before you unplugged the device. Maybe the first six. But evidently the syslogd process was blocked. > > However, if I put it back in later on ... it works. The storage shows up > and the modem too. > > Weird. I'll have to reboot to try to reproduce with usbmon logging. You might have to get a stack trace (Alt-SysRq-T) as well. It sounds like something important got hung up somewhere. Perhaps the usb-serial modules couldn't be loaded for that reason. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 11 Oct 2009 18:54 On Sat, 2009-10-10 at 17:21 -0700, Ben Efros wrote: > > Ben Herrenschmidt's patch[1] to retry without SANE_SENSE might be > combined be able to be used to detect this 'INSANE_SENSE' scenario, > but not in its current form. > > Devices lying about the "additional sense length" doesn't seem all > that common, so it might be better to just flag the device as insane > and not worry about reworking Ben Herrenschmidt's patch. I don't like flagging devices ... though we already somewhat do it for the mode switch so it would be possible to stick the flag there. Another option is to set the insane flag from a retry path similar to what I posted so that it doesn't ping pong. In any case, a decision should be made soon as current -stable is broken and these devices are very common. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Pages: 1 2 3 4 Prev: Linux IO service time - a perfect source of randomness ? Next: NOHZ: local_softirq_pending 08 |