On Thu, Jun 20, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote: > Ok, I'm completely stumped on a problem and thought I'd see if anyone > has seen this or might have an idea why it's happening. > > I (unfortunately) have to use an older kernel (2.4.2-2, i.e. Redhat > 7.1) and on both UHCI drivers (uhci.o and usb-uhci.o) I'm seeing what > looks like the HCD is "losing" data at certain points. It happens > for both uhci.o and usb-uhci.o; I see this happen on the kernel.org > kernels up to 2.4.9 (usb-uhci) and 2.4.12 (uhci) - after that things > work.
Well, 2.4.2 is known buggy. Why do you have to use that? Can you just use the driver from a more recent kernel? > I have a device (Retail receipt printer) which sends back status on an > interrupt-in pipe. I have a bus tracer hooked up. I run a certain > test case which at one point waits for the printer to send status (on > the interrupt pipe). The test case hangs, so I bus traced it, and the > tracer shows the data successfully coming over the wire - but the HCD > never gets it. I put debugging into the interrupt handler of uhci.o, > and the TD never gets any of its data (urbp->transfer_buffer) or > control bits (td->status) changed. There is one hardware interrupt > where I expect the interrupt data (i.e. after the control data > completes) but none of the interrupt TDs are changed - all have > 0x00 data and the same control bits. And, an interesting addition is, > this only happens when there are URBs queued (this is using BULK URB > on interrupt pipes) - if there is only 1 URB it doesn't happen (but of > course there is a sizable gap where no polling is done between the > completion of one URB and the submission of the next - usually about > 30ms). Bulk queuing is very broken in uhci.c in 2.4.2. What you are seeing is most likely a data toggle problem. > Has anyone seen anything like this or have any ideas why this would > happen? I looked at USB diffs from 2.4.9->2.4.10 (and 2.4.12->2.4.13) > but couldn't see anything that looked like it would be causing this. There are a couple of bulk queueing fixes for uhci.c up through those kernels. > It seems to be hardware independent, it happens on USB controllers > from VIA and Intel (systems are ThinkPad T21 and SurePOS 730 and > 750 which are custom Retail systems). That wouldn't surprise me, it's a driver bug, not a hardware problem. > Below is a short section of the debugging log that may help show the > problem. The last hardware interrupt section should (according to bus > trace) show the TD as containing data and with different status bits. > No more hardware interrupts are generated (since no more data flows) > in this case but I can create more bus traffic which does show up, > meaning the single interrupt-in packet is completely lost. [snip] I'm not sure exactly what you're looking for? The newer drivers work fine, why not just use those? JE ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
