Bug 253096
|
Description
Dave Russell
2007-08-16 22:03:52 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 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. Great stuff! Is/has this gone upstream? BZ or some other way to track it's progress? 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. Fix in kernel-2.6.22.6-81.fc7, submitted for testing. Still not fixed in rawhide/F8... Re-opening and updated the bug to F8. Also uploading new /var/log/messages output 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.
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 this broke again in 2.6.23.1-49.fc8, -42 was fine. the workaround named earlier fixes it though 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.. 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.) Created attachment 271941 [details]
Candidate patch 1 - same function in option
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. 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. New fix in F7 and F8 CVS 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. Created attachment 278531 [details]
Candidate patch 2 - Tell option only attach to non-storage interface
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. 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' 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 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 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. 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 The official upstream patch is in 2.6.23.12-100 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 (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. 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 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. 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). 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 Still not working in 2.6.23.14-115.fc8. 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? 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. 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. Created attachment 294762 [details]
Log referenced in post #38
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. 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. 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 Created attachment 294903 [details]
usbmon output when the E220 is connected and a user is logged into gnome
Created attachment 294904 [details]
dmesg output that goes along with the usbmon trace
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! Perfect, this is exactly what I needed. Thanks, Dave. 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. OK, so what now? Is there anything else we can do to work out what's causing this interaction? 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. 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. 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 Interesting on the firmware note. Can you remember what the version of the previous firmware was? Can you tell this from Linux? I suppose "ati" or "at&i" should work. Of course you'd need to kill HAL first to interrupt the cycling. 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 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
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. 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. 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. 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
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. 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. Created attachment 303000 [details] Log showing e220 cycling (comment #61) Created attachment 303001 [details] Log showing e220 not cycling (comment #61) Created attachment 306563 [details]
output of log file when netwok manager crashes
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 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? 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. So I guess Burhan is the only one who still has issues. (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. |