Most recent kernel where this bug did not occur: Distribution: Gentoo Hardware Environment: Software Environment: Problem Description: I am trying to use a PCMCIA PC-CARD GPRS/UMTS/HSDPA MODEM PC-CARD is branded as ONDA H600 and is extremely popular in Italy since it is the "default" UMTS PC-CARD by a provider in the country. PC-CARD is actually a re-branded ZTE MF330 so it should be quite popular in other countries as well. Apparently, also the older ONDA NH501HS is again a ZTE MF330, so the following should apply also to that card. When the card is inserted into the PCMCIA slot, the following should happen: - kernel should recognize an OHCI Host Controller - kernel should recognize an ONDA CDMA Technologies MSM (Manufacturer: Qualcomm, Incorporated) attached to it - kernel should configure 3 ttyUSB devices provided by the 3 serial interfaces of the ONDA MSM Unfortunately, with the linux kernel this does not happen Rather, the kernel gets confused, detects an EHCI Controller, loads the kernel module for it and no serial interfaces appear. As an hack, the correct behaviour can be obtained by blacklisting the ehci_hcd for instance in /etc/modprobe.d/blacklist-modem. When the ehci_hcd is blacklisted everything works correctly and the ONDA Wireless UMTS PC-CARD gets perfectly usable. lspci reports the datacard as a Philips ISP1561 EHCI USB 2.0 (1131:1562), so I excluded this device from ehci-pci and i can use the datacard without blacklisting the module. Steps to reproduce:
Created attachment 14040 [details] patch to disable ehci support for the Philips ISP1561 usb hub
Can you send me this patch in email form, with the needed information as documented in Documentation/SubmittingPatches, and CC: the linux-usb mailing list so that I can apply it properly? thanks.
Reply-To: akpm@linux-foundation.org (added bugzilla to cc) On Fri, 21 Dec 2007 22:02:28 -0800 David Brownell <david-b@pacbell.net> wrote: > > > --- > a/drivers/usb/host/ehci-pci.c~ehci-disable-the-philips-isp1561-usb-hub > > > +++ a/drivers/usb/host/ehci-pci.c > > > @@ -141,6 +141,14 @@ static int ehci_pci_setup(struct usb_hcd > > > goto done; > > > } > > > break; > > > + case PCI_VENDOR_ID_PHILIPS: > > > + /* ISP1561 EHCI USB 2.0 doesn't work. */ > > > + if (pdev->device == 0x1562) { > > > + ehci_info(ehci, "ignoring ISP1561\n"); > > > + retval = -EIO; > > > + goto done; > > > + } > > > + break; > > > case PCI_VENDOR_ID_NVIDIA: > > > switch (pdev->device) { > > > /* Some NForce2 chips have problems with selective suspend; > > > > Is this really an appropriate approach? > > Almost certainly not. NAK on that patch. > > > > That is, is it definitely > > known that there are no working devices of this type? Or is it > > possible that other people have ISP1561 EHCI controllers that they > > actually do use? If there are, blacklisting their devices like this > > would be a very bad idea. > > I'll have to search through some boxes to be sure, but I'm all but > certain it was an ISP1561, sent to me by Philips from Taiwan, that > I used for a bunch of early EHCI work. They have newer EHCI silicon, > like the 1562, 1563, and 1564, and don't seem to have obsoleted any > chip called the 1560, so it's hard to say what else it'd have been. > > Whichever chip it was, it worked quite nicely ... it did help shake > loose a couple low level races in the driver, since its timings > were a bit different from the other chips I had, but after those > got fixed it was rock solid. > > Unfortunately I have a shortage of available PCI slots lately, so I > can no longer to keep a dozen vendors' worth of EHCI controllers > sitting in machines ready to test. In fact I have no PCI slots > available for such purposes at all. :( > so... what can we do about Bruno's bug?
Reply-To: david-b@pacbell.net > > > > --- > a/drivers/usb/host/ehci-pci.c~ehci-disable-the-philips-isp1561-usb-hub > > > > +++ a/drivers/usb/host/ehci-pci.c > > > > @@ -141,6 +141,14 @@ static int ehci_pci_setup(struct usb_hcd > > > > goto done; > > > > } > > > > break; > > > > + case PCI_VENDOR_ID_PHILIPS: > > > > + /* ISP1561 EHCI USB 2.0 doesn't work. */ > > > > + if (pdev->device == 0x1562) { > > > > + ehci_info(ehci, "ignoring ISP1561\n"); > > > > + retval = -EIO; > > > > + goto done; > > > > + } > > > > + break; > > > > case PCI_VENDOR_ID_NVIDIA: > > > > switch (pdev->device) { > > > > /* Some NForce2 chips have problems with selective > suspend; > > > > > > Is this really an appropriate approach? > > > > Almost certainly not. NAK on that patch. > > so... what can we do about Bruno's bug? Start by providing a usable bug description! Bug 9562 is little more than a description of the above hack ... it doesn't say anything about just what went wrong. There's a FAQ somewhere saying what we need in bug reports... That includes kernel logs of the startup when CONFIG_USB_DEBUG is enabled. Start by loading both EHCI and OHCI driver modules loaded, then insert that CardBus card. Include all the output until the USB subsystem has finished enumerating and hotplugging. It should also include "lspci -vvx" output for that CardBus device.
Adding dmesg output with USB_DEBUG enabled both with the original driver and with the modified ehci-pci.c. Also adding output from lspci -vv and lsusb -v
Created attachment 14417 [details] dmesg output with original ehci-pci
Created attachment 14418 [details] dmesg output with modified ehci-pci
Created attachment 14419 [details] lspci -vv output
Created attachment 14420 [details] lsusb -v output
Looks like the problem I noticed a while back where some patches broke OHCI. I believe that's now fixed ... does 2.6.26-rc4 behave? The handoff to the companion controller is not working here, and when I saw this with some other devices (with an almost-vanilla 2.6.25 kernel) the problem was that something was leaving the OHCI controller in the "reset" state ... you could see this by looking in the /sys/kernel/debug/ohci/.../registers file. A 2.6.23 kernel is unfortunately not something I can try to debug.
The card is now working with 2.6.25-gentoo-r7 (based on 2.6.25.11)
Still need to know if the standard kernel.org tree behaves. I have no idea what patches are applied to a Gentoo kernel.
It is working with kernel 2.6.25.12