[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb-devel
Subject:    Re: [linux-usb-devel] [Bugme-new] [Bug 8690] New: Bulk IN transfers
From:       Andrew Morton <akpm () linux-foundation ! org>
Date:       2007-06-29 21:22:17
Message-ID: 20070629142217.1e1c0031.akpm () linux-foundation ! org
[Download RAW message or body]

On Fri, 29 Jun 2007 14:09:23 -0700 (PDT)
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8690
> 
>            Summary: Bulk IN transfers hanging randomly on Intel ICHx USB
>                     EHCI HCD
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.22-rc6
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: USB
>         AssignedTo: greg@kroah.com
>         ReportedBy: drab@kepler.fjfi.cvut.cz
> 
> 
> Most recent kernel where this bug did not occur: none (??)
> Distribution: FC7
> Hardware Environment:
> 
> 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub
> Interface (rev 02)
> 00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev
> 02)
> 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> Controller #1 (rev 02)
> 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> Controller #2 (rev 02)
> 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> Controller #3 (rev 02)
> 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> Controller #4 (rev 02)
> 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
> Controller (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
> 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface
> Bridge (rev 02)
> 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
> (rev 02)
> 00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev
> 02)
> 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev
> 02)
> 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R)
> AC'97 Audio Controller (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP
> 8x] (rev a2)
> 02:04.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 61)
> 02:04.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 61)
> 02:04.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
> 02:04.3 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller
> (rev 46)
> 02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 
> Software Environment:
> Problem Description:
> 
> When I'm doing a continuous High-Speed bulk IN transfers from a device (the
> device has a Philips/NXP ISP1581 USB device controller) and this device is
> connected to an Intel ICHx (tried with ICH5 and ICH7 and both had the problem)
> (EHCI) HCD, the transfer starts, works for some while, which is not really
> predictable, sometimes it is a second (few tenths of MB transferred), sometimes
> it is few minutes (few GB transferred) (but usually not more) and then all of a
> sudden, the transfer stops. Without any warning, error, anything, it just
> stops.
> 
> The driver for the device (that I'm writing) keeps about 10 to 40 buffers of 32
> KB size permanently linked/submitted for the Bulk IN transfers from the device
> (resp. its particular Bulk IN endpoint) and the number of linked/submitted
> buffers at a time never falls below 10 during the transfer. When one buffer
> transfer completes, another is immediately linked/submitted from within the URB
> completion handler.
> 
> But while the bulk IN transfers on ICHx HCD do have this problem, isochronous
> IN transfers from the same device (only different endpoint) on the same HCDs do
> not have any problem, they work correctly for any period of time.
> 
> So at first I thought it might be a problem either in the device USB controller
> ISP1581 or somewhere in my driver. But then I tried on different computers with
> non Intel chipset and CPU (though I'm not sure whether CPU is relevant in this
> case), like AMD on VIA and AMD on nVidia, and there everything works great,
> i.e. the transfer doesn't stop. I also tried to insert a USB HCD add-on card
> based on VIA HCD chip into the computer where it failed on the ICH5 chipset
> (otherwise everything else remained the same, both other HW and kernel), ant
> connected the device through this card and then it also worked without a
> problem.
> 
> That makes me think, that the problem would probably not be in the ISP1581 or
> my driver, but rather in the HCD driver in handling the bulk transfers for the
> ICHx HCD. Unless all the ICHx HCDs are buggy in hardware, which of course I do
> not know either. But is it? Or can there be any other explanation? Please help.
> 
> So, does any USB HCD guru around here have any idea where the problem might
> possibly be? I can help with debugging or even fixing, but someone more
> familiar with the HCD core might have a better luck or at least some hints as
> to where to look, at least.
> 
> Steps to reproduce: Described above.
> 
> 
> -- 
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[prev in list] [next in list] [prev in thread] [next in thread]