[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1163980315.2881.30.camel@localhost.localdomain>
Date: Sun, 19 Nov 2006 18:51:54 -0500
From: Dan Williams <dcbw@...hat.com>
To: Larry Finger <Larry.Finger@...inger.net>
Cc: Chris Wright <chrisw@...s-sol.org>, linux-kernel@...r.kernel.org,
stable@...nel.org, Justin Forbes <jmforbes@...uxtx.org>,
Zwane Mwaikambo <zwane@....linux.org.uk>,
"Theodore Ts'o" <tytso@....edu>,
Randy Dunlap <rdunlap@...otime.net>,
Dave Jones <davej@...hat.com>,
Chuck Wolber <chuckw@...ntumlinux.com>,
Chris Wedgwood <reviews@...cw.f00f.org>,
Michael Krufky <mkrufky@...uxtv.org>, torvalds@...l.org,
akpm@...l.org, alan@...rguk.ukuu.org.uk, netdev@...r.kernel.org,
mb@...sch.de, greg@...ah.com,
"John W. Linville" <linville@...driver.com>
Subject: Re: [patch 07/30] bcm43xx: Drain TX status before starting IRQs
On Sat, 2006-11-18 at 13:06 -0600, Larry Finger wrote:
> Chris Wright wrote:
> > -stable review patch. If anyone has any objections, please let us know.
> > ------------------
> >
> > From: Michael Buesch <mb@...sch.de>
> >
> > Drain the Microcode TX-status-FIFO before we enable IRQs.
> > This is required, because the FIFO may still have entries left
> > from a previous run. Those would immediately fire after enabling
> > IRQs and would lead to an oops in the DMA TXstatus handling code.
> >
> > Cc: "John W. Linville" <linville@...driver.com>
> > Signed-off-by: Michael Buesch <mb@...sch.de>
> > Signed-off-by: Larry Finger <Larry.Finger@...inger.net>
> > Signed-off-by: Chris Wright <chrisw@...s-sol.org>
> > ---
>
> Chris,
>
> The regression turns out to be a locking problem involving bcm43xx, wpa_supplicant, and
> NetworkManager. The exact cause is unknown; however, this patch is clearly not the problem. Please
> reinstate it for inclusion in -stable.
NM should be using wpa_supplicant underneath. But depending on the NM
version, NM may be issuing any one of SIWENCODE (only to clear keys),
[S|G]IWSCAN, GIWRANGE, GIWAP, [S|G]IWMODE, [S|G]IWFREQ. Mainly, NM
cleans up after wpa_supplicant, gets information about the current
connection, and does scans. All other connection setup and handling is
done by wpa_supplicant. But note that NM will do any of the above
operations at any time, no matter what wpa_supplicant is doing at that
time. So the locking in the driver needs to be right, but it should be
right anyway regardless of whether either one or both of NM and
wpa_supplicant is in the picture...
Dan
> Thanks,
>
> Larry
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
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/
Powered by blists - more mailing lists