From: Larry Finger <Larry.Finger@lwfinger.net>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Joseph Fannin <jhf@columbus.rr.com>,
Andrew Morton <akpm@osdl.org>, Ray Lee <ray-lk@madrabbit.org>,
netdev@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
John Linville <linville@tuxdriver.com>,
Michael Buesch <mb@bu3sch.de>,
Bcm43xx-dev@lists.berlios.de
Subject: Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
Date: Sat, 18 Nov 2006 11:05:08 -0600 [thread overview]
Message-ID: <455F3D44.4010502@lwfinger.net> (raw)
In-Reply-To: <1163868955.27188.2.camel@johannes.berg>
Johannes Berg wrote:
> On Sat, 2006-11-18 at 06:24 -0500, Joseph Fannin wrote:
>
>> This sounds like what my laptop was doing in -rc5, though mine
>> didn't take hours to start acting up.
>>
>> I *think* it was the MSI troubles, causing interrupts to get
>> lost forever. Anyway, it went away in -rc6.
>
> Hah, that's a lot more plausible than bcm43xx's drain patch actually
> causing this. So maybe somehow interrupts for bcm43xx aren't routed
> properly or something...
>
> Ray, please check /proc/interrupts when this happens.
>
> I am convinced that the patch in question (drain tx status) is not
> causing this -- the patch should be a no-op in most cases anyway, and in
> those cases where it isn't a no-op it'll run only once at card init and
> remove some things from a hardware-internal FIFO.
I agree that drain tx status should not cause the problem.
Ray, does -rc6 solve your problem as it did for Joseph?
Larry
WARNING: multiple messages have this Message-ID (diff)
From: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: Andrew Morton <akpm-3NddpPZAyC0@public.gmane.org>,
Ray Lee <ray-lk-0Cg02Ec9UG4BXFe83j6qeQ@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Joseph Fannin <jhf-rN3PHIWzTs1Jm/Hvfsr4+Q@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
John Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>,
Bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Subject: Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
Date: Sat, 18 Nov 2006 11:05:08 -0600 [thread overview]
Message-ID: <455F3D44.4010502@lwfinger.net> (raw)
In-Reply-To: <1163868955.27188.2.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
Johannes Berg wrote:
> On Sat, 2006-11-18 at 06:24 -0500, Joseph Fannin wrote:
>
>> This sounds like what my laptop was doing in -rc5, though mine
>> didn't take hours to start acting up.
>>
>> I *think* it was the MSI troubles, causing interrupts to get
>> lost forever. Anyway, it went away in -rc6.
>
> Hah, that's a lot more plausible than bcm43xx's drain patch actually
> causing this. So maybe somehow interrupts for bcm43xx aren't routed
> properly or something...
>
> Ray, please check /proc/interrupts when this happens.
>
> I am convinced that the patch in question (drain tx status) is not
> causing this -- the patch should be a no-op in most cases anyway, and in
> those cases where it isn't a no-op it'll run only once at card init and
> remove some things from a hardware-internal FIFO.
I agree that drain tx status should not cause the problem.
Ray, does -rc6 solve your problem as it did for Joseph?
Larry
next prev parent reply other threads:[~2006-11-18 17:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-15 19:01 bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble? Ray Lee
2006-11-15 19:15 ` Michael Buesch
2006-11-15 19:15 ` Michael Buesch
2006-11-15 19:41 ` Ray Lee
2006-11-16 2:51 ` Larry Finger
2006-11-16 2:51 ` Larry Finger
2006-11-16 5:51 ` Ray Lee
2006-11-16 18:17 ` Larry Finger
[not found] ` <455CAB2F.1060709-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-11-16 19:16 ` Michael Buesch
2006-11-16 19:36 ` Ray Lee
[not found] ` <455CBDD7.6000507-0Cg02Ec9UG4BXFe83j6qeQ@public.gmane.org>
2006-11-16 22:40 ` Larry Finger
2006-11-16 23:26 ` Ray Lee
[not found] ` <ae017dc00611161526v6bcbddc2ve2c7e10963d25c3b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2006-11-17 1:13 ` Larry Finger
2006-11-18 11:24 ` Joseph Fannin
2006-11-18 16:55 ` Johannes Berg
2006-11-18 16:55 ` Johannes Berg
2006-11-18 17:05 ` Larry Finger [this message]
2006-11-18 17:05 ` Larry Finger
2006-11-18 17:27 ` Ray Lee
2006-11-18 18:30 ` Adrian Bunk
2006-11-21 6:21 ` Ray Lee
2006-11-18 19:02 ` Larry Finger
2006-11-19 16:01 ` Michael Buesch
2006-12-12 4:06 ` ieee80211 sleeping in invalid context Ray Lee
2006-12-12 9:14 ` Michael Buesch
2006-12-12 17:51 ` Ray Lee
2006-12-12 18:31 ` Larry Finger
2006-12-12 18:31 ` Larry Finger
2006-11-19 6:15 ` Problem with DMA on x86_64 with 3 GB RAM Larry Finger
2006-11-21 4:38 ` Ray Lee
2006-11-21 11:28 ` Alan
2006-11-21 16:34 ` Larry Finger
2006-11-21 10:30 ` Andi Kleen
2006-11-21 16:37 ` Larry Finger
2006-11-21 16:46 ` Andi Kleen
2006-11-21 18:27 ` Alan
2006-11-21 18:31 ` Andi Kleen
2006-11-21 20:04 ` Alan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=455F3D44.4010502@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=Bcm43xx-dev@lists.berlios.de \
--cc=akpm@osdl.org \
--cc=jhf@columbus.rr.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
--cc=netdev@vger.kernel.org \
--cc=ray-lk@madrabbit.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.