Bug 287868 – Huawei E169 doesn't work as mass storage anymore

• Status: RESOLVED UPSTREAM
• Product: Gentoo Linux

[Description justXi 2009-10-06 08:54:44 UTC]

The Huawei UMTS USB Stick does not work as a mass storage device.

Reproducible: Always

Steps to Reproduce:
1. The kernel does not support the storage device
2. remove the patch
3. storage device is supporte again

[Comment 1 Justin Lecher (RETIRED) 2009-10-09 19:47:21 UTC]

Please tell us which kernel sources you use and which are affected.

[Comment 2 justXi 2009-10-10 12:00:59 UTC]

I use gentoo-sources and vanilla-sources.

I testet these sources since 2.6.29 and had to patch all versions I want to be able to use the sd card feature of the huawei stick.

Latest version that I patched was gentoo-sources-2.6.31-r1.

[Comment 3 Justin Lecher (RETIRED) 2009-10-10 12:05:09 UTC]

Thanks for the info, assigning to maintainer

[Comment 4 Mike Pagano 2009-10-27 23:54:26 UTC]

Can you clarify what you're doing to get it working?

Do you remove the patch? Or patch the kernel?

[Comment 5 justXi 2009-10-29 16:55:29 UTC]

An already applied patch or change removes some code:

{
        int result;

-       us->iobuf[0] = 0x1;
        result = usb_stor_control_msg(us, us->send_ctrl_pipe,
                                      USB_REQ_SET_FEATURE,
                                      USB_TYPE_STANDARD | USB_RECIP_DEVICE,
-                                     0x01, 0x0, us->iobuf, 0x1, 1000);
+                                     0x01, 0x0, NULL, 0x0, 1000);
        US_DEBUGP("usb_control_msg performing result is %d\n", result);
        return (result ? 0 : -1);
 }

I reverse this by hand, so the working version is:

{
        int result;

        us->iobuf[0] = 0x1;
        result = usb_stor_control_msg(us, us->send_ctrl_pipe,
                                      USB_REQ_SET_FEATURE,
                                      USB_TYPE_STANDARD | USB_RECIP_DEVICE,
                                      0x01, 0x0, us->iobuf, 0x1, 1000);
        US_DEBUGP("usb_control_msg performing result is %d\n", result);
        return (result ? 0 : -1);
 }

[Comment 6 justXi 2009-10-29 16:57:01 UTC]

btw: It is not an official patch file, I use a diff from working to not working revision or write it by hand.

[Comment 7 Mike Pagano 2009-11-13 01:28:53 UTC]

(In reply to comment #5)
> An already applied patch or change removes some code:
> 
> {
>         int result;
> 

What file are you patching?

[Comment 8 justXi 2009-11-13 08:27:24 UTC]

/drivers/usb/storage/initializers.c

[Comment 9 Samuli Suominen (RETIRED) 2010-01-07 11:32:58 UTC]

I've got E169 as well, and I can confirm this is still a problem with Linux 2.6.32.1.

Feel free to poke me at Freenode if you need something tested

[Comment 10 George Kadianakis (RETIRED) 2010-01-12 13:34:59 UTC]

Have you gentlemen tried this patch: 
http://launchpadlibrarian.net/33442788/patch0 which is supposed to be included in the 2.6.31.1 release?

(In reply to comment #9)
> I've got E169 as well, and I can confirm this is still a problem with Linux
> 2.6.32.1.
> 

Weird, I thought that the problem was solved in the 2.6.31 series with the patch above.

Check if the above patch fails, and I'll research thoroughly.

[Comment 11 Mike Pagano 2010-02-04 17:37:15 UTC]

Greg reports this as being from a buggy firmware:
http://lkml.indiana.edu/hypermail/linux/kernel/0902.2/03459.html

The old upstream bug has been closed as invalid relating to this:
http://bugzilla.kernel.org/show_bug.cgi?id=12559

Unless a fix comes from them, not sure what else we can do here.

[Comment 12 Mike Pagano 2010-02-16 16:33:02 UTC]

My suggestions is too take this upstream to the manufacturer.