[CCing linux-usb as I had started another thread there already] On Thu, 02 Apr 2009 11:43:59 +0200, Peter Zijlstra wrote: > On Tue, 2009-03-31 at 18:52 +0200, Tilman Schmidt wrote: >>> A user of the Gigaset base driver (drivers/isdn/gigaset/bas-gigaset.c) >>> reports his connection being dropped exactly every 30 seconds. >>> Analysis of his dmesg indicates that when the error occurs, both the >>> tasklets read_iso_tasklet and write_iso_tasklet handling the B channel >>> data stream (125 USB isochronous packets per second in each direction) >>> are at the same time not executed for an entire inter-packet interval, >>> ie. 8 msecs. >> The user did a bit of ellimination work, and it turned out that if >> he disconnected his Logitech Laser Mouse from its USB port and >> connected it to the PS2 port instead, the regular blockages ceased. > > Looks like the USB driver holds off interrupts for a long-long time. Well, not quite. The sequence of events is this: - two isochronous read URBs are queued - completion handler is called for the first one - schedules tasklet for bottom half processing of received data - submits another URB so that there are again two URBs queued - 8 ms later, completion handler is called again for the next URB - notices previous URB hasn't been processed (ie. tasklet hasn't run) - bitches And the same, mutatis mutandis, for the sending direction. So interrupts seem to be delivered fine, it's just the tasklets that are held off. > Another possible source might be SMIs -- and there's nothing much you > can do about those except bitch to Gigabyte. > > But really, relying on <10ms execution latency on mainline is almost > asking for it -- in general we do better, but there are a few sore > spots. Interestingly, I never encountered that sort of problem while developing the driver, on a lowly 700 MHz P3 with kernels around 2.6.11, and the only problem report I ever received in that area until now was from a user who ran an IDE disk in PIO mode, and whose problems vanished once he switched that to DMA mode. So what do you propose? Queue more URBs, so that I can tolerate waiting longer for bottom half processing to kick in? How much time will I have to be able to tolerate? Thanks, Tilman -- Tilman Schmidt E-Mail: tilman@xxxxxxx Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Attachment:
signature.asc
Description: OpenPGP digital signature
