On Saturday 18 November 2006 20:02, Larry Finger wrote:
> Ray Lee wrote:
> > Larry Finger wrote:
> >> Johannes Berg wrote:
> >>> 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.
> >
> > When it happens, I can't. The keyboard is entirely dead (I'm in X, perhaps at
> > a console it would be okay). The only thing that works is magic SysRq. even
> > ctrl-alt-f1 to get to a console doesn't work.
> >
> > That said, /proc/interrupts doesn't show MSI routed things on my AMD64 laptop.
> >
> >>> 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.
> >
> > Okay, I can buy that.
> >
> >> I agree that drain tx status should not cause the problem.
> >>
> >> Ray, does -rc6 solve your problem as it did for Joseph?
> >
> > I can't get it to repeat other than the first two times. However, I
> > accidentally stopped NetworkManager from handling my wireless a few days ago,
> > and haven't restarted it, so that may play into this.
> >
> > Humor me one last time, I beg. Did you look at the messages file I posted? (Or
> > maybe I didn't include this second bit... Damn, I need to be more careful with
> > cutting and pasting...)
>
> The locking stuff wasn't in any of the messages that I received.
>
> > The second sysrq-t shows locking stuff going on, can you tell me if it looks
> > reasonable? It still seems to me that something acquiring and not releasing
> > rtnl_lock explains what I was seeing (rtnl lock is implicated in both sysrq-t
> > backtraces). I don't know if that thing is bcm43xx, though.
> >
> > Is this part reasonable?:
> > 1 lock held by events/0/4:
> > #0: (&bcm->mutex){--..}, at: [mutex_lock+9/16] mutex_lock+0x9/0x10
> > 2 locks held by NetworkManager/4837:
> > #0: (rtnl_mutex){--..}, at: [mutex_lock+9/16] mutex_lock+0x9/0x10
> > #1: (&bcm->mutex){--..}, at: [mutex_lock+9/16] mutex_lock+0x9/0x10
> > 1 lock held by wpa_supplicant/5953:
> > #0: (rtnl_mutex){--..}, at: [mutex_lock+9/16] mutex_lock+0x9/0x10
>
> I'm not an expert on locking, but it certainly looks as if bcm43xx and wpa_supplicant are OK by
> themselves, but that NetworkManager interferes. This behavior matches what I see - I don't have
> NetworkManager on my system, but I do use wpa_supplicant, with no lockups. Of course, I have i386
> architecture.
>
> Although NetworkManager may be the catalyst to trigger the bug, I doubt that it is the cause.
> Strictly as a guess, I would suspect that the locking problem is in SoftMAC, where we know there can
> be locking difficulties, but no one is fixing them because EOL is near for that component.
Well, this is different. The (known) locking problems are of type "missing locking".
But this seems to be a deadlock or something, so clearly a bug that
must be fixed. Even in softmac.
I don't know yet how this can happen, though.
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
