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] [thread-next>] [day] [month] [year] [list]

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

On Tue, 2009-03-31 at 18:52 +0200, Tilman Schmidt wrote:
> /me 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.
> 
> So we have a workaround, but no explanation.
> 
> This is on Debian Lenny with a 2.6.26 kernel. The user claims newer
> kernels don't boot on his machine. Btw, he also reports that the
> ISDN connection breaks each time he hotplugs any USB device, but
> so far has failed to produce a syslog excerpt for that. (sigh)
> The Motherboard is a Gigabyte GA-EP45T-EXTREME, advertised as
> "Designed for overclocking enthusiasts with overwhelming
> overclocking experience", which lets me fear the worst ...

Looks like the USB driver holds off interrupts for a long-long time. But
afaik that's not the only troublesome spot in mainline.

One way to test this would be using the threaded interrupt patches
Thomas posted, along with the USB driver conversion.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/