Bug 9562 - USB subsystem confuses serial devices with ehci controller
USB subsystem confuses serial devices with ehci controller
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: USB
All Linux
: P1 normal
Assigned To: David Brownell
:
Depends on:
Blocks: USB
  Show dependency treegraph
 
Reported: 2007-12-14 10:37 UTC by Bruno Redondi
Modified: 2008-09-26 07:12 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.23
Tree: Mainline
Regression: ---


Attachments
patch to disable ehci support for the Philips ISP1561 usb hub (510 bytes, patch)
2007-12-14 10:39 UTC, Bruno Redondi
Details | Diff
dmesg output with original ehci-pci (19.99 KB, text/plain)
2008-01-11 12:21 UTC, Bruno Redondi
Details
dmesg output with modified ehci-pci (20.10 KB, text/plain)
2008-01-11 12:22 UTC, Bruno Redondi
Details
lspci -vv output (11.66 KB, text/plain)
2008-01-11 12:22 UTC, Bruno Redondi
Details
lsusb -v output (4.62 KB, text/plain)
2008-01-11 12:23 UTC, Bruno Redondi
Details

Description Bruno Redondi 2007-12-14 10:37:29 UTC
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:
Comment 1 Bruno Redondi 2007-12-14 10:39:49 UTC
Created attachment 14040 [details]
patch to disable ehci support for the Philips ISP1561 usb hub
Comment 2 Greg Kroah-Hartman 2007-12-14 11:45:29 UTC
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.
Comment 3 Anonymous Emailer 2007-12-21 22:09:52 UTC
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?

Comment 4 Anonymous Emailer 2007-12-21 22:41:57 UTC
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.

Comment 5 Bruno Redondi 2008-01-11 12:20:43 UTC
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
Comment 6 Bruno Redondi 2008-01-11 12:21:46 UTC
Created attachment 14417 [details]
dmesg output with original ehci-pci
Comment 7 Bruno Redondi 2008-01-11 12:22:15 UTC
Created attachment 14418 [details]
dmesg output with modified ehci-pci
Comment 8 Bruno Redondi 2008-01-11 12:22:54 UTC
Created attachment 14419 [details]
lspci -vv output
Comment 9 Bruno Redondi 2008-01-11 12:23:32 UTC
Created attachment 14420 [details]
lsusb -v output
Comment 10 David Brownell 2008-05-29 14:36:27 UTC
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.
Comment 11 Bruno Redondi 2008-07-24 03:09:58 UTC
The card is now working with 2.6.25-gentoo-r7 (based on 2.6.25.11)
Comment 12 David Brownell 2008-07-24 03:27:39 UTC
Still need to know if the standard kernel.org tree behaves.  I have no idea what patches are applied to a Gentoo kernel.
Comment 13 Bruno Redondi 2008-07-28 05:18:35 UTC
It is working with kernel 2.6.25.12

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