linux-kernel - Re: PROBLEM: brcm80211 hangs on 2.6.36-0.34.rc6.git3.fc15.x86

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:	Tue, 12 Oct 2010 04:03:43 -0400
From:	Jon Masters <jonathan@...masters.org>
To:	linux-wireless@...r.kernel.org
Cc:	Brett Rudley <brudley@...adcom.com>,
	Henry Ptasinski <henryp@...adcom.com>,
	Nohee Ko <noheek@...adcom.com>,
	Jon Masters <jcm@...masters.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: PROBLEM: brcm80211 hangs on 2.6.36-0.34.rc6.git3.fc15.x86_64

On Tue, 2010-10-12 at 03:47 -0400, Jon Masters wrote:
> On Fri, 2010-10-08 at 07:44 -0400, Jon Masters wrote:
> > On Fri, 2010-10-08 at 02:58 -0400, Jon Masters wrote:
> > 
> > > I tried building the new brcm80211 driver from staging-next on Fedora rawhide
> > > kernel 2.6.36-0.34.rc6.git3.fc15.x86_64. Now, of course, it's not the
> > > staging-next kernel (I'll try that now this doesn't work) but perhaps this
> > > report will still be of use to the Broadcom/other wireless folks.
> > 
> > I pulled the latest staging-next onto Linus' latest git tree and still
> > experience problems with the driver. It seems that the first attempt to
> > actually transmit results in the system locking hard. Once again, I am
> > attaching the output from running a netconsole (due to the box I'm on,
> > it's an attachment this time, sorry about that - don't trust evolution)
> > where the trace is basically the same as the original trace I posted.
> > 
> > NOTE: in both cases, the driver is loaded with "msglevel=2
> > phymsglevel=2" which (although not documented) suggests to enable
> > tracing, and does certainly yield more debugging output.
> 
> The problem may be that the driver doesn't correctly handle its logic in
> wl_up in the case that the call to wlc_up doesn't result in the value of
> wl->pub->up being TRUE. This can happen, for example if radio_disabled
> is true, but I'm sure there are other problems, too. This result is not
> properly checked in wl_up, so we can get a situation where we will later
> try to call the ops->tx function with wl down. You also don't check
> wl_up return codes in general, for example in wlc_radio_enable.

You need to change the following lines in wlc_up:

        if (wlc->pub->radio_disabled) {
                wlc_radio_monitor_start(wlc);
                return 0;
        }

This should be returning BCME_RADIOOFF. That's a start. Now the driver
doesn't explode and does what you intended with the background worker
looking to see if the radio gets turned on. At least no hard hang.

> This might all be related to the rfkill and other soft switch stuff I'm
> not really super up to date on. This laptop doesn't have a hardware
> switch that I'm aware of, but I assume the state is somehow recorded in
> software (by the BIOS?) and perhaps this is how rfkill is supposed to
> work (I'll go look this up). Anyway, if I can figure out how to get the
> radio to work and hack up the driver to start with the device down,
> perhaps it'll not try to transmit and not fall over :)

Looks like you don't do rfkill. I'm not sure what I'm supposed to do to
turn the radio on on the ASUS EeePC 1015PEM but I will poke at a few
things. If you have advice, it would be welcome.

Let me know if you need a patch for the above, and I'll send it along
with anything else I think of - perhaps some more error handling :)

Jon.


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