On Wed, Apr 14, 2010 at 08:21:08PM +0530, Ramya Desai wrote:
quoted text
> On Tue, Apr 13, 2010 at 11:54 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> 
> > If your host controller is at fault, it may be necessary for the xHCI
> > driver to limit the number of sglist entries so your buggy host
> > controller doesn't crash.  Can you experiment with changing this line in
> > xhci-pci.c:
> >
> >        hcd->self.sg_tablesize = TRBS_PER_SEGMENT - 1;
> >
> > Try leaving TRBS_PER_SEGMENT set to 64, and then modifying this line to
> > limit the sglist to something small, like 10 or 25.  Run the default USB
> > mass storage driver and see if this resolves the HC died issue for you.
> > If it does, try to find the maximum size that makes the host not die.
> 
> Dear Sarah,
> 
> Thank you very much for the information.
> 
> Today, I tried with the following scenario with default mass storage
> driver in 2.6.34-rc2 (xhci-large-tx branch).
> 
> The TRBS_EPR_SGEMENT is set to 64 and SEGMENT_SHIFT is set to 10 in
> xhci.h file.  Also, I tested with the hcd->self.sg_tablesize by
> setting it to 10 and 25. Unfortunately, the data transfer failed
> again. The value of the max_sectors is set to 960 in both the cases. I
> saw “HW died” in both the cases. However the root cause still remains
> the same. The host just stops working, after submitting data and
> remains waiting for an interrupt which doesn’t occur. After a time
> out, command_abort is called, followed by a print statement which says
> “HW died”
> 
> The other thing is, the same host controller is working under Windows
> for larger transfers without any issues.

You're running the Windows driver from NEC, correct?  It's possible they
are working around some hardware bug in their device in the driver, and
the Linux xHCI driver is triggering it.  Who knows what it is, since
their driver isn't open source.

quoted text
> We have tested the host under Windows up to 2 MB transfer buffers and
> it works fine without any issues. So, I am doubting that it could be a
> hardware issue. Also, it seems to work fine with USB2.0 cable.

You mean the drive works fine under an xHCI host controller when you
connect it to the device?  The xHCI driver will set up the same length
transfers exactly the same whether the USB device is running at high
speed or at SuperSpeed.  So I don't know why the device speed would
matter.  The only difference is in how the host controller sends that
buffer over the wire.

At this point, I'm really running out of ideas.  The only thing I can
think of that might be effecting it is that the Linux xHCI driver
doesn't reset a USB 3.0 device during the enumeration process, since the
link has already been trained by the time we get a port status
connection change.  I suppose that could have an effect on the link
training sequence, and perhaps the host and device go out of sync in the
middle of a transfer?  I'll send you a patch that you can test.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html