Re: PROBLEM: brcm80211 hangs on 2.6.36-0.34.rc6.git3.fc15.x86_64

[Jon Masters]

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.

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 :)

Keep you posted.

Jon.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/