Hello,
Unfortunately this is a very hard problem to recreate and I've had to
give this one a lower priority. However, I did add the code change you
mentioned as I'm waiting for it to happen again. Below are the values
of the status and command registers during normal operation when the
issue has not occurred. I'll send a response when it does happen with
the register values. Also, moving to a new kernel won't be possible due
to restrictions from other SW items on the system I'm working on.
Thank you for the response.
Daniel P Graves
Status Register
---------------
Swaps between the following two values:
1100 0000 0000 1001 (Asynchronous Schedule Status,Periodic Schedule
Status,Frame List Rollover,USB Interrupt)
A 0 0 9
1100 0000 0010 1000 (Asynchronous Schedule Status,Periodic Schedule
Status,Interrupt on Async Advance,Frame List Rollover)
A 0 2 8
Cmd Register
------------
Always the following value:
0001 0000 0000 0010 0001 (Interrupt Threshold Control,Asynchronous
Schedule Enable,Run/Stop)
1 0 0 2 1
-----Original Message-----
From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx]
Sent: Monday, July 23, 2012 1:50 PM
To: Graves, Daniel (GE Healthcare)
Cc: linux-usb@xxxxxxxxxxxxxxx
Subject: RE: Help with EHCI Missing Bulk In Callbacks
On Sat, 16 Jun 2012, Graves, Daniel (GE Healthcare) wrote:
> Hello,
>
> wMaxPacketSize if 512. The transfer_buffer_length the problematic
> message is 8. And yes I meant scan_async doesn't run until 4 seconds
> later.
>
> Yes the debug messages I gave were just to show the time discrepancy
> between each message. The first line of each time interval is
> printed inside of scan_async to prove that scan_async is delayed by 4
> seconds.
>
> Thanks for mentioning the patch. I will look into it.
Was this ever resolved?
It may be that your problem was fixed by a change to ehci-hcd made about
a year ago. Have you tried using a more recent kernel (3.1 or later)?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
