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-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
