linux-kernel - Re: [ath9k-devel] ath9k: massive unexplained latency in 2.6.27 (rc5, rc6, probably others)

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]

Message-ID: <alpine.LNX.2.00.0809190925250.22158@alcarin.uplinklabs.net>
Date:	Fri, 19 Sep 2008 09:27:48 -0700 (PDT)
From:	Steven Noonan <steven@...inklabs.net>
To:	Robert Hancock <hancockr@...w.ca>
cc:	"Luis R. Rodriguez" <lrodriguez@...eros.com>,
	Luis Rodriguez <Luis.Rodriguez@...eros.com>,
	Ingo Molnar <mingo@...e.hu>,
	"ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ts.ath9k.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [ath9k-devel] ath9k: massive unexplained latency in 2.6.27 (rc5,
 rc6, probably others)



On Fri, 19 Sep 2008, Robert Hancock wrote:

> Steven Noonan wrote:
> > Second of all, I'm looking at the ath9k interrupt handler right now,
> > and there are a few cases where it returns IRQ_NONE. And here's where
> > I'm a bit fuzzy. Since there could be any number of things using IRQ
> > 17 (though in my case, ath9k is on its own dedicated IRQ), it seems
> > odd that you check the value of sc->sc_invalid, since the cookie
> > passed to the handler might not actually be ath9k's cookie if multiple
> > drivers have registered IRQ handlers for that particular IRQ. Who
> > knows if what you're reading is even valid? Heck, what if some driver
> > uses a NULL for their cookie (however unlikely)? You'd get a
> > segmentation fault on the second line of the interrupt handler. Of
> > course, I could be completely wrong: does parent interrupt handler
> > check to see which device driver owns the particular device signaling
> > an IRQ and then call the appropriate handler?
> 
> All the IRQ handlers registered on that interrupt will get called. The cookie
> will always be the right one for that handler however.

Thank you! I appreciate the explanation.

> The bug is presumably that it returns IRQ_NONE in some cases where the device
> is actually generating an interrupt. The advice to turn on irqpoll is rather
> useless in this case - that's mainly useful where the IRQ routing is messed up
> and the device can't receive any interrupts at all.

Strange, though, that irqpoll solved the connectivity issues (but of 
course created the ridiculous latency that this thread's all about).

--
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/