Bug 253096 - Huawei E220 USB 3G modem does not work correctly
Summary: Huawei E220 USB 3G modem does not work correctly
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-08-16 22:03 UTC by Dave Russell
Modified: 2008-10-12 11:29 UTC (History)
8 users (show)

Fixed In Version: 2.6.23.9-85.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-15 13:22:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
output from /var/log/messages when the Huawei E220 3G modem is connected (7.66 KB, text/plain)
2007-11-08 20:50 UTC, Dave Russell
no flags Details
Candidate patch 1 - same function in option (1.57 KB, patch)
2007-11-28 23:38 UTC, Pete Zaitcev
no flags Details | Diff
Candidate patch 2 - Tell option only attach to non-storage interface (1.93 KB, patch)
2007-12-05 16:44 UTC, Pete Zaitcev
no flags Details | Diff
Log referenced in post #38 (15.14 KB, text/plain)
2008-02-13 10:04 UTC, Philip Trickett
no flags Details
usbmon output when the E220 is connected and a user is logged into gnome (182.84 KB, application/octet-stream)
2008-02-14 10:19 UTC, Dave Russell
no flags Details
dmesg output that goes along with the usbmon trace (46.16 KB, text/plain)
2008-02-14 10:20 UTC, Dave Russell
no flags Details
Log showing e220 cycling (comment #61) (2.60 KB, text/plain)
2008-04-19 13:36 UTC, Niall Sheridan
no flags Details
Log showing e220 not cycling (comment #61) (2.40 KB, text/plain)
2008-04-19 13:37 UTC, Niall Sheridan
no flags Details
output of log file when netwok manager crashes (6.79 KB, text/plain)
2008-05-24 08:49 UTC, Burhan Khalid
no flags Details

Description Dave Russell 2007-08-16 22:03:52 UTC
Description of problem:

The Huawei E220 USB 3G modem is not correctly recognised by the linux kernel.

When plugged in only 1 ttyUSB is created instead of 3

Version-Release number of selected component (if applicable):

Kernel 2.6.22.1-41.fc7

How reproducible:
Every time.

Steps to Reproduce:
1. Plug in usb 3G modem and check /var/log/messages
  
Actual results:

usb 3-1: new full speed USB device using uhci_hcd and address 8
usb 3-1: configuration #1 chosen from 1 choice
option 3-1:1.0: GSM modem (1-port) converter detected
usb 3-1: GSM modem (1-port) converter now attached to ttyUSB0

Expected results:

usb 3-1: new full speed USB device using uhci_hcd and address 9
usb 3-1: configuration #1 chosen from 1 choice
option 3-1:1.0: GSM modem (1-port) converter detected
usb 3-1: GSM modem (1-port) converter now attached to ttyUSB0
option 3-1:1.1: GSM modem (1-port) converter detected
usb 3-1: GSM modem (1-port) converter now attached to ttyUSB1
option 3-1:1.2: GSM modem (1-port) converter detected
usb 3-1: GSM modem (1-port) converter now attached to ttyUSB2


Additional info:

I have a slightly ugly workaround which is as follows:

1. Plug in the modem, let the usb subsystem settle down.
2. Run the following script:

sudo rmmod ehci_hcd
sudo modprobe ehci_hcd
echo "Press any key to continue, or wait 30 seconds"
read -n1 -t30 any_key
sudo wvdial umts

This is obviously very invasive and hacky, causing things like usb mass storage
devices to be kicked out as well, but it does work.... there must be a better way?

Comment 1 Philip Trickett 2007-09-06 22:50:48 UTC
I have the same problem, different workaround though.
Before I plug in the modem, I modprobe usbserial as follows:

modprobe usbserial vendor=0x12d1 product=0x1003

Then I plug in the modem. I get 3 ttyUSB ports crested from this.

It just seems to be the vendor and product ID's missing.

Apparently 2.6.20 onwards should support it ok:
http://oozie.fm.interia.pl/pro/huawei-e220/

This is on x86_64

Comment 2 Pete Zaitcev 2007-09-11 02:53:37 UTC
Here's Dave Russel's /proc/bus/usb/devices so I don't have to ask him:
http://marc.info/?l=linux-usb-devel&m=118781376613749&w=2

Johann resubmitted this patch in a clean enough way:
http://marc.info/?l=linux-usb-devel&m=118899485612774&w=2

It still remains a mystery to me just why some enumeration schemes make
devices to switch modes. I have an MCT serial adapter which can come up
as a HID device (supposedly for a serial mouse). It's completely random,
just like here.

One way or the other, the reliable fix is to apply the patch above
which teaches usb-storage to enable extra serial ports.

Comment 3 Dave Russell 2007-09-11 17:55:55 UTC
Great stuff!

Is/has this gone upstream? BZ or some other way to track it's progress?

Comment 4 Pete Zaitcev 2007-09-11 18:16:12 UTC
The patch is in Greg's tree currently, to go in when 2.6.24 opens. I refetched
it a minute ago to verify. Fedora Rawhide is likely to get an -rc at that time.
FC7 though... is up to Chuck.

Comment 5 Chuck Ebbert 2007-09-14 19:01:38 UTC
Fix in kernel-2.6.22.6-81.fc7, submitted for testing.


Comment 6 Chuck Ebbert 2007-09-26 20:21:32 UTC
Still not fixed in rawhide/F8...

Comment 7 Dave Russell 2007-11-08 20:47:51 UTC
Re-opening and updated the bug to F8.

Also uploading new /var/log/messages output

Comment 8 Dave Russell 2007-11-08 20:50:23 UTC
Created attachment 252141 [details]
output from /var/log/messages when the Huawei E220 3G modem is connected

Note that 2 of the 3 channels appear, but the modem keeps cycling between
connected and disconnected... very unstable.

Comment 9 Jon Fautley 2007-11-09 09:20:01 UTC
Pete (or whoever at Red Hat):

I have access to an E220 modem and can throw it onto a system here in FAB. Let
me know if this would be useful and I can dig out a system and throw Fedora 8 on
it for you.

Cheers,

/j

Comment 10 Björn Sund 2007-11-11 11:22:40 UTC
this broke again in 2.6.23.1-49.fc8, -42 was fine.

the workaround named earlier fixes it though

Comment 11 Björn Sund 2007-11-11 13:41:27 UTC
Ok, some clarification and a nice new finding.

I couldn't connect "out of the box" with -49, wvdial sometimes connected and
then state it lost connection a few seconds after, even though modem had the
"connected" light on, and there were some other strange behavior, for instance
modem (/dev/ttyUSB*) was totally inaccessable at times and so on.. 

used workaround package from http://oozie.fm.interia.pl/pro/huawei-e220/ and now
it's up and running ace :)

not only that now it also correctly init the dialup at boot!
this didn't work with -42 either, it would state some generic error and question
user/pass (which doesnt matter)

so apparently there is something in that package that does stuff right.

i do a generic install in that package but use the wvdial config that
system-config-network generates..

Comment 13 Göran Uddeborg 2007-11-24 13:20:48 UTC
FWIW I use a laptop still having 2.6.22.7-85.fc7.  That one works fine.

(Seems I should be a bit careful to upgrade.)

Comment 14 Pete Zaitcev 2007-11-28 23:38:58 UTC
Created attachment 271941 [details]
Candidate patch 1 - same function in option

Comment 15 Pete Zaitcev 2007-11-28 23:43:35 UTC
Dave Russell attached the modem to a remotely accessible system for me and
I was able to test the patch in comment #14. I didn't dial out, but the
ATZ worked.

Comment 16 Pete Zaitcev 2007-11-28 23:49:09 UTC
The root problem is that our modutils (invoked by udev upon a hotplug or
discovery) load all modules that match the alias. The usb-storage matches
the class, the option matches the VID/PID, so they both are loaded. It is
random which one gets the device. The usb-storage has the code to initialize
the modem into the modem mode. If it gets the control, it initializes the
modem, and automatically unbinds due to a disconnect. At new round of binding
there's no storage class interface anymore, so the serial driver binds to
the working modem. However, if serial gets the control first, it binds to
a non-functional modem in storage mode.

The solution is to use the same initialization in option driver. It may
be possible to have some kind of a macro or a library function for this.
Maybe a common header of some kind.


Comment 18 Chuck Ebbert 2007-11-29 00:26:50 UTC
New fix in F7 and F8 CVS

Comment 20 Callum Wilson 2007-12-03 11:52:34 UTC
I've been using the e220 huawei modem on a daily basis since early Fedora 7, I
have a stable working e220 with fedora 8 (NB: later kernel than in original bug
report), note that:
1. I always connect the e220 before starting the system
2. I performed the modprobe once (as mentioned by Philip above) - before doing
this, all sorts of looping, failures and so on occurred before the kernel
upgrade and the modprobe.

uname -a:
Linux c4111m 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 2007 i686 i686 i386
GNU/Linux

bit of dmesg showing the way it connects as a CD mass storage device:
usb-storage: device scan complete
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 17
usb 3-1: reset full speed USB device using uhci_hcd and address 2
scsi 4:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
scsi 4:0:0:0: Attached scsi generic sg1 type 5
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sr 4:0:0:0: Attached scsi CD-ROM sr0

/var/log/messages:
Dec  3 07:57:49 c4111m kernel: usbcore: registered new interface driver usbserial
Dec  3 07:57:49 c4111m kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for generic
Dec  3 07:57:49 c4111m kernel: usbcore: registered new interface driver
usbserial_generic
Dec  3 07:57:49 c4111m kernel: drivers/usb/serial/usb-serial.c: USB Serial
Driver core
Dec  3 07:57:49 c4111m kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for GSM modem (1-port)
Dec  3 07:57:49 c4111m kernel: option 3-1:1.0: GSM modem (1-port) converter detected
Dec  3 07:57:49 c4111m kernel: usb 3-1: GSM modem (1-port) converter now
attached to ttyUSB0
Dec  3 07:57:49 c4111m kernel: option 3-1:1.1: GSM modem (1-port) converter detected
Dec  3 07:57:49 c4111m kernel: usb 3-1: GSM modem (1-port) converter now
attached to ttyUSB1
Dec  3 07:57:49 c4111m kernel: usbcore: registered new interface driver option
Dec  3 07:57:49 c4111m kernel: drivers/usb/serial/option.c: USB Driver for GSM
modems: v0.7.1

and a little proof it works (I use kppp, dialling with ):
Dec  3 08:00:45 c4111m pppd[3242]: pppd 2.4.4 started by root, uid 0
Dec  3 08:00:45 c4111m pppd[3242]: Using interface ppp0
Dec  3 08:00:45 c4111m pppd[3242]: Connect: ppp0 <--> /dev/ttyUSB0
Dec  3 08:00:45 c4111m pppd[3242]: CHAP authentication succeeded


bits of kppprc:
[Modem0]
BusyWait=0
Device=/dev/ttyUSB0
Enter=CR
FlowControl=Hardware [CRTSCTS]
Name=e220
Speed=921600
Timeout=60
UseLockFile=1
Volume=1
WaitForDialTone=1

Phonenumber=*99***1#

hope this helps.





Comment 21 Pete Zaitcev 2007-12-05 16:44:46 UTC
Created attachment 278531 [details]
Candidate patch 2 - Tell option only attach to non-storage interface

Comment 22 Pete Zaitcev 2007-12-05 16:47:26 UTC
Patch in comment #21 is the upstream solution. It's more elegant than mine
and allows to use the storage after the initialization. In some countries
the ISP stores dialing information into that image (not sure how though,
the CD image is not writeable through the usb-storage interface).

I have tested it remotely by using David Russell's modem.

Comment 23 Fedora Update System 2007-12-12 20:00:13 UTC
kernel-2.6.23.9-85.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'

Comment 24 Peter Robinson 2007-12-20 09:49:04 UTC
I've just got one of these little devices running on Three in the UK and it
looks like I'm having the same issues seen here on Fedora 8 with
kernel-2.6.23.9-85.fc8. Let me know if I can provide any more information.

usb 3-2: new full speed USB device using uhci_hcd and address 4
usb 3-2: configuration #1 chosen from 1 choice
scsi10 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
usb 3-2: USB disconnect, address 4
usb 3-2: new full speed USB device using uhci_hcd and address 5
usb 3-2: configuration #1 chosen from 1 choice
usb-storage: probe of 3-2:1.0 failed with error -5
option 3-2:1.0: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
usb 3-2: GSM modem (1-port) converter now attached to ttyUSB0
usb-storage: probe of 3-2:1.1 failed with error -5
option 3-2:1.1: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
usb 3-2: GSM modem (1-port) converter now attached to ttyUSB1
scsi13 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 13:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 13:0:0:0: Attached scsi CD-ROM sr1
sr 13:0:0:0: Attached scsi generic sg2 type 5
usb 3-2: reset full speed USB device using uhci_hcd and address 5
sr1: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00 20 00
sr: Sense Key : No Sense [current] 
sr: Add. Sense: No additional sense information
sr1: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00 20 00
sr: Sense Key : No Sense [current] 
sr: Add. Sense: No additional sense information
sr1: CDROM (ioctl) error, command: Get configuration 46 00 00 28 00 00 00 00 10 00
sr: Sense Key : No Sense [current] 
sr: Add. Sense: No additional sense information
sr1: CDROM (ioctl) error, command: Get configuration 46 00 00 20 00 00 00 00 18 00
sr: Sense Key : No Sense [current] 
sr: Add. Sense: No additional sense information
sr1: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00 20 00
sr: Sense Key : No Sense [current] 
sr: Add. Sense: No additional sense information
ISO 9660 Extensions: Microsoft Joliet Level 3
ISOFS: changing to secondary root
SELinux: initialized (dev sr1, type iso9660), uses genfs_contexts


Comment 25 Peter Robinson 2007-12-20 10:19:30 UTC
As an additional note if I add a blacklist-e220 with the line "blacklist
usb_storage 12d1:1003" I plug it in and I get the expected below.

usb 3-2: new full speed USB device using uhci_hcd and address 8
usb 3-2: configuration #1 chosen from 1 choice
usbserial_generic 3-2:1.0: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
usb 3-2: GSM modem (1-port) converter now attached to ttyUSB0
usbserial_generic 3-2:1.1: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
usb 3-2: GSM modem (1-port) converter now attached to ttyUSB1
usbserial_generic 3-2:1.2: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
usb 3-2: GSM modem (1-port) converter now attached to ttyUSB2
[root@euuklonw7300b1n ~]# cat /etc/modprobe.d/blacklist-e220 


Comment 26 Fedora Update System 2007-12-20 19:56:13 UTC
kernel-2.6.23.9-85.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 27 Peter Robinson 2007-12-21 08:15:17 UTC
as from comment #24 that is the kernel I am running

[perobinson@euuklonw7300b1n ~]$ uname -a
Linux euuklonw7300b1n 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64
x86_64 x86_64 GNU/Linux


Comment 28 Chuck Ebbert 2007-12-22 00:05:01 UTC
The official upstream patch is in 2.6.23.12-100

Comment 29 Dave Russell 2008-01-07 17:38:05 UTC
When might we see the 2.6.23.12-100 kernel in Fedora?

All is still broken using the kernel-2.6.23.9-85.fc8

Comment 30 Christopher Brown 2008-01-23 23:15:41 UTC
(In reply to comment #29)
> When might we see the 2.6.23.12-100 kernel in Fedora?
> 
> All is still broken using the kernel-2.6.23.9-85.fc8

You can pull one from updates-testing. 


Comment 31 Dave Russell 2008-01-25 03:15:23 UTC
Not looking good for me, still as broken as ever.

Linux <hostname removed> 2.6.24-0.167.rc8.git4.fc9 #1 SMP Tue Jan 22 23:19:19
EST 2008 i686 i686 i386 GNU/Linux


Jan 25 03:10:31 swires kernel: usb 5-1: new full speed USB device using uhci_hcd
and address 2
Jan 25 03:10:31 swires kernel: usb 5-1: configuration #1 chosen from 1 choice
Jan 25 03:10:31 swires kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Jan 25 03:10:31 swires kernel: usb 5-1: USB disconnect, address 2
Jan 25 03:10:32 swires kernel: usb 5-1: new full speed USB device using uhci_hcd
and address 3
Jan 25 03:10:32 swires kernel: usb 5-1: configuration #1 chosen from 1 choice
Jan 25 03:10:32 swires kernel: usb-storage: probe of 5-1:1.0 failed with error -5
Jan 25 03:10:32 swires kernel: usb-storage: probe of 5-1:1.1 failed with error -5
Jan 25 03:10:32 swires kernel: scsi5 : SCSI emulation for USB Mass Storage devices
Jan 25 03:10:32 swires kernel: usbcore: registered new interface driver usbserial
Jan 25 03:10:32 swires kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for generic
Jan 25 03:10:32 swires kernel: usbcore: registered new interface driver
usbserial_generic
Jan 25 03:10:32 swires kernel: drivers/usb/serial/usb-serial.c: USB Serial
Driver core
Jan 25 03:10:32 swires kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for GSM modem (1-port)
Jan 25 03:10:32 swires kernel: option 5-1:1.0: GSM modem (1-port) converter detected
Jan 25 03:10:32 swires kernel: usb 5-1: GSM modem (1-port) converter now
attached to ttyUSB0
Jan 25 03:10:32 swires kernel: option 5-1:1.1: GSM modem (1-port) converter detected
Jan 25 03:10:32 swires kernel: usb 5-1: GSM modem (1-port) converter now
attached to ttyUSB1
Jan 25 03:10:32 swires kernel: usbcore: registered new interface driver option
Jan 25 03:10:32 swires kernel: drivers/usb/serial/option.c: USB Driver for GSM
modems: v0.7.1
Jan 25 03:10:37 swires kernel: scsi 5:0:0:0: CD-ROM            HUAWEI   Mass
Storage     2.31 PQ: 0 ANSI: 2
Jan 25 03:10:37 swires kernel: scsi 5:0:0:0: Attached scsi generic sg1 type 5
Jan 25 03:10:37 swires kernel: Driver 'sr' needs updating - please use bus_type
methods
Jan 25 03:10:37 swires kernel: sr0: scsi-1 drive
Jan 25 03:10:37 swires kernel: Uniform CD-ROM driver Revision: 3.20
Jan 25 03:10:46 swires kernel: usb 5-1: reset full speed USB device using
uhci_hcd and address 3
Jan 25 03:10:46 swires kernel: usb 5-1: reset full speed USB device using
uhci_hcd and address 3
Jan 25 03:10:46 swires kernel: usb 5-1: device descriptor read/64, error -71
Jan 25 03:10:47 swires kernel: usb 5-1: device descriptor read/64, error -71
Jan 25 03:10:47 swires kernel: usb 5-1: reset full speed USB device using
uhci_hcd and address 3
Jan 25 03:10:47 swires kernel: usb 5-1: device descriptor read/64, error -71
Jan 25 03:10:47 swires kernel: usb 5-1: device descriptor read/64, error -71
Jan 25 03:10:47 swires kernel: usb 5-1: reset full speed USB device using
uhci_hcd and address 3
Jan 25 03:10:48 swires kernel: usb 5-1: device not accepting address 3, error -71
Jan 25 03:10:48 swires kernel: usb 5-1: reset full speed USB device using
uhci_hcd and address 3
Jan 25 03:10:48 swires kernel: usb 5-1: device not accepting address 3, error -71
Jan 25 03:10:48 swires kernel: usb 5-1: USB disconnect, address 3
Jan 25 03:10:48 swires kernel: option1 ttyUSB0: GSM modem (1-port) converter now
disconnected from ttyUSB0
Jan 25 03:10:48 swires kernel: option 5-1:1.0: device disconnected
Jan 25 03:10:48 swires kernel: option1 ttyUSB1: GSM modem (1-port) converter now
disconnected from ttyUSB1
Jan 25 03:10:48 swires kernel: option 5-1:1.1: device disconnected
Jan 25 03:10:48 swires kernel: usb 5-1: new full speed USB device using uhci_hcd
and address 4
Jan 25 03:10:49 swires kernel: usb 5-1: device descriptor read/64, error -71
Jan 25 03:10:49 swires kernel: usb 5-1: device descriptor read/64, error -71
Jan 25 03:10:49 swires kernel: usb 5-1: new full speed USB device using uhci_hcd
and address 5
Jan 25 03:10:49 swires kernel: usb 5-1: device descriptor read/64, error -71
Jan 25 03:10:49 swires kernel: usb 5-1: device descriptor read/64, error -71
Jan 25 03:10:49 swires kernel: usb 5-1: new full speed USB device using uhci_hcd
and address 6
Jan 25 03:10:50 swires kernel: usb 5-1: device not accepting address 6, error -71
Jan 25 03:10:50 swires kernel: usb 5-1: new full speed USB device using uhci_hcd
and address 7
Jan 25 03:10:50 swires kernel: usb 5-1: device not accepting address 7, error -71


Comment 32 Pete Zaitcev 2008-01-25 04:12:35 UTC
This is weird. Remember how you hooked it for me to a box remotely, and
everything worked peachy when I was done with it. Hmm... *confused*

I'm going to look at the exact tree you have (2.6.24-0.167.rc8.git4.fc9),
maybe a patch fell on the floor somewhere.

Comment 33 Dave Russell 2008-01-25 11:34:49 UTC
Yup, all very *very* strange.

Assuming it all looks ok, give me a shout via email and I'll give you access to
this box (can only do it over weekends tho).



Comment 34 Neil Viglieno 2008-01-30 09:22:27 UTC
The latest update is still broken for me, just cycling between connected /
disconnected.

Linux <hostname removed> 2.6.23.14-107.fc8 #1 SMP Mon Jan 14 21:37:30 EST 2008
i686 i686 i386 GNU/Linux

usb 4-1: new full speed USB device using uhci_hcd and address 2
usb 4-1: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi6 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb 4-1: USB disconnect, address 2
usb 4-1: new full speed USB device using uhci_hcd and address 3
usb 4-1: configuration #1 chosen from 1 choice
usb-storage: probe of 4-1:1.0 failed with error -5
usb-storage: probe of 4-1:1.1 failed with error -5
scsi9 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for GSM modem
(1-port)
option 4-1:1.0: GSM modem (1-port) converter detected
usb 4-1: GSM modem (1-port) converter now attached to ttyUSB0
option 4-1:1.1: GSM modem (1-port) converter detected
usb 4-1: GSM modem (1-port) converter now attached to ttyUSB1
usbcore: registered new interface driver option
drivers/usb/serial/option.c: USB Driver for GSM modems: v0.7.1
usb-storage: device scan complete
scsi 9:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 9:0:0:0: Attached scsi CD-ROM sr1
sr 9:0:0:0: Attached scsi generic sg2 type 5
usb 4-1: reset full speed USB device using uhci_hcd and address 3
usb 4-1: reset full speed USB device using uhci_hcd and address 3
usb 4-1: device descriptor read/64, error -71
usb 4-1: USB disconnect, address 3
option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
option 4-1:1.0: device disconnected
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
option 4-1:1.1: device disconnected
scsi 9:0:0:0: rejecting I/O to dead device
scsi 9:0:0:0: rejecting I/O to dead device
scsi 9:0:0:0: rejecting I/O to dead device
usb 4-1: new full speed USB device using uhci_hcd and address 4
usb 4-1: configuration #1 chosen from 1 choice
usb-storage: probe of 4-1:1.0 failed with error -5
option 4-1:1.0: GSM modem (1-port) converter detected
usb 4-1: GSM modem (1-port) converter now attached to ttyUSB0
usb-storage: probe of 4-1:1.1 failed with error -5
option 4-1:1.1: GSM modem (1-port) converter detected
usb 4-1: GSM modem (1-port) converter now attached to ttyUSB1
scsi12 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 12:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 12:0:0:0: Attached scsi CD-ROM sr1
sr 12:0:0:0: Attached scsi generic sg2 type 5
usb 4-1: reset full speed USB device using uhci_hcd and address 4
usb 4-1: USB disconnect, address 4
option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
option 4-1:1.0: device disconnected
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
option 4-1:1.1: device disconnected
usb 4-1: new full speed USB device using uhci_hcd and address 5
usb 4-1: configuration #1 chosen from 1 choice
usb-storage: probe of 4-1:1.0 failed with error -5
option 4-1:1.0: GSM modem (1-port) converter detected
usb 4-1: GSM modem (1-port) converter now attached to ttyUSB0
usb-storage: probe of 4-1:1.1 failed with error -5
option 4-1:1.1: GSM modem (1-port) converter detected
usb 4-1: GSM modem (1-port) converter now attached to ttyUSB1
scsi15 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 15:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 15:0:0:0: Attached scsi CD-ROM sr1
sr 15:0:0:0: Attached scsi generic sg2 type 5
usb 4-1: reset full speed USB device using uhci_hcd and address 5
usb 4-1: reset full speed USB device using uhci_hcd and address 5
usb 4-1: device descriptor read/64, error -71
usb 4-1: USB disconnect, address 5
option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
option 4-1:1.0: device disconnected
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
option 4-1:1.1: device disconnected



Comment 35 Dominik Sandjaja 2008-02-08 06:43:01 UTC
Still not working in 2.6.23.14-115.fc8.

Comment 36 Dominik Sandjaja 2008-02-08 08:44:48 UTC
For the record: The kernel bugzilla entries, which are or might be related to
that, are:
http://bugzilla.kernel.org/show_bug.cgi?id=8792
http://bugzilla.kernel.org/show_bug.cgi?id=8746

Can anyone here confirm that it works/worked with some Fedora kernel 2.6.21?

Comment 37 Dave Russell 2008-02-08 08:59:49 UTC
It has never worked for me on any of the kernels without some additional bit of
c code that pokes and prods the modem to "activate" it.



Comment 38 Philip Trickett 2008-02-13 10:04:07 UTC
Just as an update to this:

[phil@maki ~]$ uname -a
Linux maki 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64
x86_64 GNU/Linux

I plug the device in, and it is recognised correctly, however, after about 15
seconds, it gets disabled, then re-enabled, and it perpetually stays in this
loop.  This is using:
[phil@maki ~]$ rpm -q kernel
kernel-2.6.23.15-137.fc8

Log is attached as separate file.


Comment 39 Philip Trickett 2008-02-13 10:04:59 UTC
Created attachment 294762 [details]
Log referenced in post #38

Comment 40 Pete Zaitcev 2008-02-13 17:34:09 UTC
I think Phillip's case is new. The usb-storage resets the device and
for some reason this causes a disconnect, reconnect and the whole dance.
Tellingly though, the device is reported as 1-port, yet we see two.
Something is still not being detected right. I'll keep this case
in mind.

Comment 41 Pete Zaitcev 2008-02-14 01:10:37 UTC
I looked into getting one, but apparently it's pretty pricy: ~$360.
Also, online availability is not what I'd call pervasive... E2 has it,
and that's about it. I think I'm going to parasite on Dave Russel's
unit for the time being.

Comment 42 Pete Zaitcev 2008-02-14 02:30:38 UTC
And I am taking back what I said about "new" in comment #40, actually
it's the same thing that Dave's modem does. I just misremembered what
I read in comment #31.

I have verified that 2.6.24-0.338.rc1.git2 has the necessary code.

Maybe I did not wait long enough when I tested Dave's modem remotely,
or he has some desktop component (like Nautilus) which insists on
accessing all storage attached and thus causes sr to issues the reset.
I did not verify storage operation, I admit.

Dave, I'll need another usbmon trace of this, only now it will be with
the storage. Can you get it for me? There's a note in kernel-doc RPM,
/usr/share/doc/kernel-doc-2.6.24/Documentation/usb/usbmon.txt

Comment 43 Dave Russell 2008-02-14 10:19:32 UTC
Created attachment 294903 [details]
usbmon output when the E220 is connected and a user is logged into gnome

Comment 44 Dave Russell 2008-02-14 10:20:02 UTC
Created attachment 294904 [details]
dmesg output that goes along with the usbmon trace

Comment 45 Dave Russell 2008-02-14 10:20:51 UTC
OK I did this using the F9-Alpha Live CD

Linux localhost.localdomain 2.6.24-2.fc9 #1 SMP Fri Jan 25 13:14:54 EST 2008
i686 i686 i386 GNU/Linux

usbmon and dmesg output attached

Let me know if you need anything else!

Comment 46 Pete Zaitcev 2008-02-14 19:11:36 UTC
Perfect, this is exactly what I needed. Thanks, Dave.

Comment 47 Pete Zaitcev 2008-02-14 21:57:20 UTC
Trouble happens here:

f6e816e0 907746075 S Bo:1:045:4 -115 31 = 55534243 89000000 0c000000 80000a5a
082a0000 0000000c 00000000 000000
f6e816e0 907746916 C Bo:1:045:4 0 31 >
c2e1d840 907746944 S Bi:1:045:3 -115 12 <
c2e1d840 907747916 C Bi:1:045:3 -75 12 = 0e000000 00000800 0000ffff
f6e816e0 907747942 S Bi:1:045:3 -115 13 <
f6e816e0 907748914 C Bi:1:045:3 -75 13 = 0e000000 00000800 0000ffff 00

Command with code 0x5A above is MODE SENSE(10), DBD, page 0x2A.
We issue it with allocation length 12, and expect 12 bytes of data.
Then the deivice babbles on us and everything unravels, because
the device stuffs the babble content into the Command Status Block.

SCSI layer itself might have been able to deal with this, but
the Bulk transport at USB level cannot.

Page 2a is GPMODE_CAPABILITIES_PAGE. Obviously it is longer than 12
bytes in Huawei. It is equally obvious that Huawei is badly in the
wrong here by not respecting the allocation length. Still, it may
be sensible to ask the user to supply a longer length.

As far as I was able to ascertain, the only user of page 2a in
kernel is pktcddvd, but it issues it with much greater lengths.
Therefore, I suspect that a userland component issues it directly.
Someone should find it... I cannot guess what it might be. Maybe
Grip, or perhaps Nautilus itself through a library.

Comment 48 Dave Russell 2008-02-18 18:28:21 UTC
OK, so what now? Is there anything else we can do to work out what's causing
this interaction?

Comment 49 Pete Zaitcev 2008-02-18 19:03:14 UTC
The right thing to do now, I think, is to follow the command back through
its cmd->done etc. until we find the specific application doing it.

Comment 50 Pete Zaitcev 2008-02-18 21:22:27 UTC
Following the plan in the previous comment is made difficult by the
fact that my desktop does not issue this command when I test with
USB CD writer and CD-ROMs. An instrumented kernel has to be run
in the context of Dave's desktop.

Comment 51 Neil Viglieno 2008-02-25 13:06:26 UTC
My e220 is now working :)

With the last update ( kernel-2.6.23.15-137.fc8 ) it was still just cycling
between connected and disconnected. 

After updating the firmware on the e220 to version 11.117.07.00.67, the problem
has gone away.

When the e220 is connected /dev/ttyUSB0 and /dev/ttyUSB1 are created as expected
and the CD-ROM is mounted as /media/Mobile_Connect. 

$ uname -a
Linux localhost.localdomain 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST
2008 i686 i686 i386 GNU/Linux


Comment 52 Peter Robinson 2008-02-25 15:03:21 UTC
Interesting on the firmware note. Can you remember what the version of the
previous firmware was? Can you tell this from Linux? 

Comment 53 Pete Zaitcev 2008-02-25 18:51:26 UTC
I suppose "ati" or "at&i" should work. Of course you'd need to kill HAL
first to interrupt the cycling.

Comment 54 Neil Viglieno 2008-02-26 08:58:36 UTC
The previous version of the firmware was 11.110.05.00.67

Here's the output from "ATI":

Manufacturer: huawei 
Model: E220 
Revision: 11.117.07.00.67 



Comment 55 Niall Sheridan 2008-02-26 23:37:55 UTC
I was having a similar problem until I added the following to
/usr/share/hal/fdi/preprobe/10osvendor/20-broken-usb-sticks.fdi
     <match key="@storage.originating_device:usb.vendor_id" int="0x12d1">
       <match key="@storage.originating_device:usb.product_id" int="0x1003">
         <merge key="info.ignore" type="bool">true</merge>
       </match>
     </match>

I've not tried upgrading the firmware:

OK                                                   
ATI                                                  
Manufacturer: huawei
Model: E220
Revision: 11.116.04.03.25
IMEI: 358191015923043
+GCAP: +CGSM,+DS,+ES


Comment 56 Dave Russell 2008-02-28 09:16:28 UTC
Interesting, so I've tried that modification and it does indeed seem to prevent
the cycling of connected/disconnected on F8.

However I also tried an F9 Alpha installation, fully updated against rawhide,
first with and then without the hal rules and that seemed to work both ways.

Of course without it still mounts the driver cd image, and whinges, but it
doesn't seem to cycle between connected and disconnected.

I'll try testing again on F8/F9A both with and without the rules, rebooting in
between to ensure nothing's left over.

Comment 57 Pete Zaitcev 2008-02-28 20:00:16 UTC
We know that it's some kind of desktop component causing the reconnect
cycle, see the usbmon results parsed in comment #47. So it's possible
that F9 fixes the issue by updating that component. Unfortunately I do
not know what program it was. So many people insist on sending SCSI
commands through bypass APIs, I just have no idea... It is possible
that the bad code is still there, only your fresh desktop does not
trip it. Let's see what others say about F9.

Comment 58 Dave Russell 2008-03-06 08:56:34 UTC
I've done some more testing this morning, so a fresh install of F8 fully updated
but without any modifications still shows the cycling connect/disconnect problems.

Adding the hal rule in comment #55 to that same F8 install (with a reboot in
between just to be sure) does not exhibit the problem, it's as stable as it
should be.

I will retry with a fully updated F9 a bit later today. 

Comment 59 Peter Robinson 2008-03-22 18:36:22 UTC
It seems the firmware has a reasonable impact of the behaviour of the modem.
I've tested with two different modems (same modem different providers, but as it
doesn't get to that point I don't see that as an issue).

The first one (firmware 11.117) works fine (well NetworkManager detects the link
but I haven't got it working yet), the second one doesn't and keeps recycling
like others have seen. Do we have a minimum known working version?

ATI1 - Manufacturer: huawei
       Model: E220
       Revision: 11.117.06.00.100
       +GCAP: +CGSM,+DS,+ES

ATI1 - Manufacturer: huawei
       Model: E220
       Revision: 11.110.05.00.00
       +GCAP: +CGSM,+DS,+ES


Comment 60 Christian Paratschek 2008-03-27 08:22:26 UTC
Firmware Update is crucial here.

I tried FC9 with Updates through 27.03. applied today (Austria, drei-Network).
Had the connect/disconnect behaviour until I applied the firmware update to
version 11.17.something. After that, it connected flawlessly.  

Comment 61 Niall Sheridan 2008-04-19 13:35:12 UTC
Tried this on a fully-updated F9, with and without the hal rule. The device does
the cycling connect/disconnect without the rule, and appears fine with it. I've
not updated the firmware (nor am I about to :) ) from the version I posted in
comment #55. I'll attach the logs.

Comment 62 Niall Sheridan 2008-04-19 13:36:15 UTC
Created attachment 303000 [details]
Log showing e220 cycling (comment #61)

Comment 63 Niall Sheridan 2008-04-19 13:37:01 UTC
Created attachment 303001 [details]
Log showing e220 not cycling (comment #61)

Comment 64 Burhan Khalid 2008-05-24 08:49:15 UTC
Created attachment 306563 [details]
output of log file when netwok manager crashes

Comment 65 Burhan Khalid 2008-05-24 08:50:00 UTC
In Fedora 9, with the rule and the latest available firmware, I am still getting
cycling issues and after the second connect attempt, NetworkManager crashes
completely (no icon in gnome) and there appears to be no way to bring it back
unless you restart the machine.

The modem does connect briefly and is able to receive IP address and DNS from my
provider; but then it just as quickly disconnects. At the next connect attempt,
NetworkManager quits.

[burhan@burhan-laptop ~]$ uname -a
Linux burhan-laptop 2.6.25.3-18.fc9.i686 #1 SMP Tue May 13 05:38:53 EDT 2008
i686 i686 i386 GNU/Linux

Comment 66 Dave Russell 2008-09-12 14:01:02 UTC
I have applied updated firmware to my E220, and while it didn't make any difference under F8, with F9 it all (now) works perfectly. I can't tell whether it was the updated firmware that fixed it, or the newer F9 errata but for me it's all working now with F9.

Unless anyone complains otherwise, I think this bug can now be closed... anyone else?

Comment 67 Peter Robinson 2008-09-15 10:09:08 UTC
I saw very similar things with my E220 and its been working fine for quite some time. I think its a combination of both the newer firmware and newer NM. But I agree this can be closed.

Comment 68 Pete Zaitcev 2008-09-15 13:22:29 UTC
So I guess Burhan is the only one who still has issues.

Comment 69 Dominik 'Rathann' Mierzejewski 2008-10-12 11:29:47 UTC
(In reply to comment #68)
> So I guess Burhan is the only one who still has issues.

Unfortunately, no. ;) I have a friend with F-9 who has the same connected/disconnected cycling issue. Oddly enough, the modem works on my laptop (FS Amilo Pro v3505), but doesn't work on hers (also FS, but I don't remember the exact model right now). I'll post some logs when she brings the laptop next time.


Note You need to log in before you can comment on or make changes to this bug.