linux-kernel - Re: Help: tasklet blocked for >8msec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 02 Apr 2009 17:32:22 +0200
From:	Tilman Schmidt <tilman@...p.cc>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...x.de>,
	linux-usb@...r.kernel.org
Subject: Re: Help: tasklet blocked for >8msec - USB mouse related

[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@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


Download attachment "signature.asc" of type "application/pgp-signature" (255 bytes)