Re: USB serial regression 2.6.31.1 -> 2.6.31.2

[Ondrej Zary]

On Saturday 10 October 2009 19:05:22 Alan Stern wrote:
> On Sat, 10 Oct 2009, Josua Dietze wrote:
> > Benjamin Herrenschmidt schrieb:
> > > The symptom is that the USB modem just disconnects/reconnects in a
> > > loop. The log looks like what I pasted below when plugging the device
> > > (and leaving it in, the disconnects don't correspond to the device
> > > being removed).
> >
> > This is one of the mode switching devices. It is switched to modem
> > mode by "usb_stor_huawei_e220_init".
> >
> > Something keeps resetting it to initial mode. It might be a
> > powersave/suspend issue.
>
> It's not related to powersave or suspend.  (Although both trace files
> show that the device's remote-wakeup feature did get enabled; I have no
> idea what code was responsible for doing that.  AFAIK it shouldn't
> happen unless the device is about to be suspended.)
>
> No, the problem is related to the mode-switching.  In particular, the
> 2.6.31.3 log shows that the mass-storage interface got into trouble
> because of a couple of bugs in the device.  These bugs caused
> usb-storage to issue a device reset, but after the reset the same thing
> happened again and we entered an endless loop.
>
> The reason this doesn't happen under 2.6.31.1 is explained by commit
> b7c8b54df8c2a82757d8aab48aaac198a49e2ff9 (which in the upstream kernel
> is commit d0defb855c8504c49b92bdc0203689ce9b4cf7ba).  It allows
> usb-storage to bind to the Huawei Datacard device, whereas before the
> mode switch would occur with no binding.
>
> Regardless, we have to figure out some way to work around the device's
> bugs.  In some detail, here's what happened:
>
> 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.
>
> Further REQUEST SENSE commands therefore requested 96 bytes of data
> instead of the standard 18 bytes.  With LUN 0 this worked okay.  But
> with LUN 1 it didn't; the device reported a failure of the REQUEST
> SENSE.  This is what caused usb-storage to issue the device reset.
>
> After the reset usb-storage continued to ask for 96 bytes of sense
> data, and LUN 1 continued to fail the commands.  Hence the repeated
> resets.
>
> 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.

No, this is not a good idea. Some of the devices have a MicroSD slot - like 
Huawei E176. The bad thing is that E176 uses the same device ID as Huawei 
E220 (and possibly some other devices too).

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/