Re: xhci driver fails and corrupt memory

[Igor K. <pa...@xi...>]

OK, so, with for-usb-linus kernel current results with different
controllers are:
NEC - works
Fresco Logic - fails with "ERROR Transfer event TRB DMA ptr not part of
current TD"
Ivy Bridge - works, but there's another issue:
usb 4-2: new SuperSpeed USB device number 3 using xhci_hcd
usb 4-2: skipped 1 descriptor after endpoint
usb 4-2: skipped 1 descriptor after endpoint
usb 4-2: skipped 1 descriptor after endpoint
usb 4-2: skipped 1 descriptor after endpoint
usb 4-2: default language 0x0409
usb 4-2: udev 3, busnum 4, minor = 386
usb 4-2: New USB device found, idVendor=20f7, idProduct=3001
usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 4-2: Product: XIMEA
usb 4-2: Manufacturer: XIMEA
usb 4-2: usb_probe_device
usb 4-2: configuration #1 chosen from 1 choice
usb 4-2: Successful Endpoint Configure command
usb 4-2: Successful evaluate context command
usb 4-2: Set SEL for device-initiated U1 failed.
usb 4-2: Successful evaluate context command
usb 4-2: adding 4-2:1.0 (config #1, interface 0)
hub 4-0:1.0: state 7 ports 4 chg 0000 evt 0004
hub 4-0:1.0: warm reset change on port 2
usb 4-2: Successful evaluate context command
usb 4-2: Successful evaluate context command
usb 4-2: xiSample timed out on ep0out len=0/0
usb 4-2: Enable of device-initiated U1 failed.
usb 4-2: Successful evaluate context command
usb 4-2: Successful evaluate context command
usb 4-2: Successful evaluate context command
usb 4-2: Successful evaluate context command
usb 4-2: Successful evaluate context command
usb 4-2: Successful evaluate context command
usb 4-2: xiSample timed out on ep0out len=0/0
usb 4-2: Enable of device-initiated U1 failed.
usb 4-2: Successful evaluate context command
xhci_hcd 0000:00:14.0: WARN Event TRB for slot 2 ep 2 with no TDs
queued?

The problem represents itself as hangs for a second or two during
certain operations. I haven't seen it before, with other kernels.

On Tue, 26 Jun 2012 12:51:51 +0400
Igor Kuzmin <pa...@xi...> wrote:

> Sorry, forgot to CC to mail lists.
> Also, I tried reproducing the fail on your for-usb-linus branch with
> NEC controller, but it works fine now (with the described change to
> libusb). Fresco Logic on the other hand still fails every couple of
> times. Will check Ivy Bridge too.
> 
> On Tue, 26 Jun 2012 11:47:57 +0400
> Igor Kuzmin <pa...@xi...> wrote:
> 
> > On Mon, 25 Jun 2012 13:26:45 -0700
> > Sarah Sharp <sar...@li...> wrote:
> > 
> > > On Fri, Jun 22, 2012 at 03:36:53PM +0400, Igor Kuzmin wrote:
> > > > Hello!
> > > > 
> > > > I'm software engineer at XIMEA (www.ximea.com) responsible for Linux
> > > > support for our products. We're using libusb-1.0 to handle our USB
> > > > cameras, everything works very stable with USB2 controllers, not so
> > > > good with XHCI (both with USB2 and USB3 devices).
> > > 
> > > Does your libusb driver submit very large transfers?  We ran into an
> > > issue with libusb making assumptions about the short packet behavior
> > > that just isn't true under xHCI.
> > > 
> > > libusb breaks large transfers into smaller buffers because older kernels
> > > had a limit on how large each buffer could be.  Newer kernels now have a
> > > limit on the total size of all mapped usbfs buffers.  So libusb would
> > > break larger transfers into a couple of usbfs URB submissions, and usbfs
> > > would assume that a short packet would stop the queue long enough for it
> > > to cancel any URBs that were part of that transfer.  But that's not true
> > > under xHCI, so your application would see a short transfer completion
> > > followed by a canceled URB completion.
> > > 
> > > Basically, libusb just needs to be fixed to not break transfers into
> > > smaller chunks.  Hans de Geode volunteered to work on this.
> > 
> > Yes, I stumbled into this issue, for the time being we patched libusb,
> > so that MAX_BULK_BUFFER_LENGTH is 1MB (that's exactly how big is the
> > transfers we submit, so no splitting). Without this change it just
> > doesn't work at all (there are some short transfers). Good to hear that
> > somebody is working on it, I submitted my patch to libusb's trac, but
> > had no response yet.
> > 
> > > 
> > > Also, you may need to increase the usbfs total buffer size by reloading
> > > the usbcore:
> > > 
> > > sudo modprobe usbcore usbfs_memory_mb=1000
> > > 
> > > That will increase the usbfs total buffer limit to 1GB.
> > 
> > Is this connected to "No room on EP Ring" messages? I had to limit
> > maximum number of submitted transfers to 3 (so 3 MB in total) to get
> > rid of this message. Bigger values work though on kernels >=3.4, there
> > has been done some dynamic expansion if I understand correctly.
> > 
> > > > xhci driver sometimes
> > > > corrupt memory (probably DMA is to blame), some transfers fail with
> > > > messages like these in kernel log:
> > > > 
> > > > ERROR Transfer event TRB DMA ptr not part of current TD
> > > > WARN Successful completion on short TX
> > > 
> > > Were you running under a Fresco Logic host controller when you got those
> > > messages?  We recently added a quirk for Fresco Logic for successful
> > > completions on short packets.
> > 
> > I think the quirk was enabled, because I even tried adding different
> > quirks myself, made no to little difference.
> > 
> > > 
> > > > WARN: TRB error on endpoint
> > > > WARN waiting for error on ep to be cleared
> > > > 
> > > > I've tried several controllers (Ivy Bridge, Fresco Logic, NEC) and
> > > > different kernels (3.3.3, 3.4.3, 3.5-rc3, xhci git tree), problems
> > > > remain. Last time I tried to enable XHCI verbose debug in kernel it
> > > > hanged the machine after the transfer started. Syslog daemon though was
> > > > able to store at least some of it. So my question is how better to
> > > > proceed with bug reports? What information to provide, running which
> > > > kernel (and controller maybe?..)?
> > > 
> > > Let's try with the NEC host controller, since that's a bit more stable
> > > than the Fresco Logic host.
> > > 
> > > Can you try running with my for-usb-linus branch?  I just fixed a bug
> > > related to successive stalls corrupting the software ring state.
> > > 
> > > Send me the dmesg with xHCI debugging turned off, and then try to use
> > > netconsole to capture the hang with debugging turned on.
> > > 
> > > Sarah Sharp
> > 
> > OK, will do. Maybe usbmon output will be helpful too? Or even better we
> > have USB3 analyzer here, though software seems to be Windows only, so
> > I'm not sure about dump format.