Date:	Sat, 10 Oct 2009 13:05:22 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Josua Dietze <digidietze@...isberghof.de>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ben Efros <ben@...doctor.com>,
	fangxiaozhi <huananhu@...wei.com>, Greg KH <greg@...ah.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	Hugh Blemings <hugh@...mings.org>
Subject: Re: USB serial regression 2.6.31.1 -> 2.6.31.2

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.

Alan Stern

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

Powered by blists - more mailing lists