Problems with ASMedia ASM1042 SuperSpeed USB Host

Discussion:

Ingo Rohloff

2012-07-16 10:02:03 UTC

Hello,

I have some problems with an ASM1042 SuperSpeed Host Controller.
(IvyBridge + PantherPoint Motherboard).
I also read some comments that this particular Host Controller might have some problems, but I could
not find any details.

I am running Ubuntu 12.04, 64 bit, with a 3.4 kernel provided by Ubuntu.
"cat /proc/version" :
Linux version 3.4.0-030400-generic ...

I also tried the stock 3.2.0-26-generic kernel usually provided by Ubuntu 12.04, but the problem is
the same.

Output of "lspci -v"
----------------------------------------------------------------------------
04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host
Controller (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Device 8488
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at f7d00000 (64-bit, non-prefetchable) [size=32K]
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [68] MSI-X: Enable+ Count=8 Masked-
Capabilities: [78] Power Management version 3
Capabilities: [80] Express Legacy Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Kernel driver in use: xhci_hcd
----------------------------------------------------------------------------

I try to read from a USB 3.0 device running at SuperSpeed.
The USB device is an evaluation board for a USB peripheral device
( http://www.plxtech.com/products/usbcontrollers/usb3380 )

I programmed the USB device to send data to the host in 0x2FFE == 12286 byte blocks.

My understanding is that this should result in 12 USB SuperSpeed packets to the host, where the last
packet only contains 0x3FE (==1022) bytes. So the last of these 12 packets should be a short packet
(<1024 bytes).

Now I try to read from this device with the following code:
--------------------------------------------
/*
* fd : file handle to USB device after "claimInterface"
* rdEp : Endpoint to read from
*
*/
static int usbBulkReadSpeed(int fd, unsigned int rdEp)
{
# define SPEED_URB_SIZE (4096*4)
# define SPEED_URBS 16
# define SPEED_URBS_TOTAL (8192*4)

static struct usbdevfs_urb readUrbs[SPEED_URBS];
int loop,totalLength;
unsigned char *speedBuf,*speedBufOrig;
struct usbdevfs_urb *urb;
struct timeval start,stop;
struct pollfd pollArray[1];

speedBuf=malloc(SPEED_URBS*SPEED_URB_SIZE+0x1000);
speedBufOrig=speedBuf;
loop=(int)(((intptr_t)speedBuf)&0xFFF);
if (loop) {
/* align to 4KB page */
loop=0x1000-loop;
speedBuf+=loop;
loop=(intptr_t)speedBuf;
printf("aligned transmit buffer to 4KB page, new pointer 0x%08x\n",loop);
}
pollArray[0].fd=fd;
pollArray[0].events = POLLOUT;
pollArray[0].revents = 0;
totalLength=0;

printf("Starting transfer\n");
gettimeofday(&start,NULL);
memset(&readUrbs,0,sizeof(readUrbs));
for (loop=0;loop<SPEED_URBS;loop++) {
readUrbs[loop].type = USBDEVFS_URB_TYPE_BULK;
readUrbs[loop].endpoint = rdEp;
readUrbs[loop].buffer = speedBuf+(SPEED_URB_SIZE*loop);
readUrbs[loop].buffer_length = SPEED_URB_SIZE;
if (ioctl(fd,USBDEVFS_SUBMITURB,&(readUrbs[loop]))<0)
{
printf("bulk_read_urb, USBDEVFS_SUBMITURB error %d\n",errno);
goto error;
}
}

loop=0;
while(loop<SPEED_URBS_TOTAL) {
poll(pollArray,1,-1);
if (ioctl(fd,USBDEVFS_REAPURB,&urb) < 0)
{
usbLastErrno = errno;
printf("bulk_read_urb, USBDEVFS_REAPURB error %d %s\n",usbLastErrno,strerror(usbLastErrno));
goto error;
}
if (urb->endpoint == rdEp)
{
totalLength+=urb->actual_length;
// usbCheckReadData((uint32_t *)(urb->buffer),urb->actual_length);

if (loop < SPEED_URBS_TOTAL-SPEED_URBS) {
if (ioctl(fd,USBDEVFS_SUBMITURB,urb)<0)
{
printf("bulk_read_urb, USBDEVFS_SUBMITURB error %d\n",errno);
goto error;
}
}
loop++;
}
}
gettimeofday(&stop,NULL);
printf("Transferred %d bytes\n",totalLength);
stop.tv_sec-=1;
stop.tv_usec+=1000000;
loop=(stop.tv_sec-start.tv_sec);
loop*=1000;
loop+=(stop.tv_usec - start.tv_usec)/1000;
printf("Finished in %d ms\n",loop);
error:
free(speedBufOrig);
return -1;
}
-----------------------------------------------------------------

The sense of this code is to achieve maximum speed by overlapping URBs.
Basically 16 URBs are outstanding before the 1st URB is "reaped".

Each URB tries to read up to 0x4000 bytes from Endpoint 0x85.
The device should send 0x2FFE bytes.
My assumption was, that every 12th packet only contains 0x3FE bytes and thus stops the currently
active URB.

It seems the ASM1042 sometimes does not stop the transfer after receiving a short packet, or at
least the URB continues (stopping after 16KByte).

QUESTION: Is this a known problem or am I doing something wrong ?

The same code DOES work if I connect my USB device to the Panther Point USB 3.0 port. "lspci -v":

00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host
Controller (rev 04) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Device 84ca
Flags: bus master, medium devsel, latency 0, IRQ 45
Memory at f7e00000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Kernel driver in use: xhci_hcd

It also works on a NEC USB 3.0 HostController PCI Express card I tried before.

Any hints what is wrong ?

with best regards
Ingo

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

Alan Stern

2012-07-16 14:56:05 UTC

Permalink

Post by Ingo Rohloff
Hello,
I have some problems with an ASM1042 SuperSpeed Host Controller.
(IvyBridge + PantherPoint Motherboard).
I also read some comments that this particular Host Controller might have some problems, but I could
not find any details.
Each URB tries to read up to 0x4000 bytes from Endpoint 0x85.
The device should send 0x2FFE bytes.
My assumption was, that every 12th packet only contains 0x3FE bytes and thus stops the currently
active URB.
It seems the ASM1042 sometimes does not stop the transfer after receiving a short packet, or at
least the URB continues (stopping after 16KByte).
QUESTION: Is this a known problem or am I doing something wrong ?

See

http://marc.info/?l=linux-usb&m=134236551409964&w=2

Apparently the ASM1042 reports that a transfer completed normally even
when it was short (or when it was cancelled).

xHCI controllers in general do not stop transfers after receiving a
short packet. Apparently there's no way to tell them to stop under
those circumstances.

Alan Stern

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

Sarah Sharp

2012-07-17 19:24:51 UTC

Permalink

Post by Alan Stern

See
http://marc.info/?l=linux-usb&m=134236551409964&w=2
Apparently the ASM1042 reports that a transfer completed normally even
when it was short (or when it was cancelled).

When an URB is canceled, the xHCI driver asks the endpoint ring to be
stopped. However, the transfer may be completed before the ring stops,
so we can have a canceled transfer where the full buffer really was
transferred. I don't see that as a bug, it's just a race condition that
drivers need to deal with.

Post by Alan Stern
xHCI controllers in general do not stop transfers after receiving a
short packet. Apparently there's no way to tell them to stop under
those circumstances.

Yes, this really sounds like it's related to the libusb
BULK_CONTINUATION flag issue.

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

Alan Stern

2012-07-17 20:22:34 UTC

Permalink

Post by Sarah Sharp

Post by Alan Stern
See
http://marc.info/?l=linux-usb&m=134236551409964&w=2
Apparently the ASM1042 reports that a transfer completed normally even
when it was short (or when it was cancelled).

The events in the email message mentioned above did not involve a race.
It's clear that no data got transferred at all, and yet usbmon reported
actual_length equal to transfer_buffer_length when the tranfer was
cancelled.

Alan Stern

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

Ingo Rohloff

2012-07-18 13:16:26 UTC

Permalink

Hello Sarah, Hello Alan,

just to describe what I experienced on the ASM1402

Post by Alan Stern
The events in the email message mentioned above did not involve a race.
It's clear that no data got transferred at all, and yet usbmon reported
actual_length equal to transfer_buffer_length when the tranfer was
cancelled.

That sounds similar to what I see with the ASM1042:

What I did was this:
- I committed an URB (IN transfer) asking for 0x4000 bytes
- Device sends 0x2FFE bytes (last packet contains 1022 byte == short packet)
- Somtimes I cannot reap the URB, because it seems the URB never gets completed.

So there is no race in this case; the URB should be just completed normally by the short packet, but
sometimes this does not seem to happen.

I wanted to use an USB3.0 Super Speed analyzer to see what actually is happening on the wires, but
unfortunately my SuperSpeed Tranceivers in my device seem to have burned out :-(.

So it will take me at least until next week to get a new device to check this.

so long
Ingo

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