* Re: brcm80211 hangs when disabling wireless
From: Greg KH @ 2010-12-13 19:42 UTC (permalink / raw)
To: Henry Ptasinski
Cc: Dave Hansen, devel@driverdev.osuosl.org, Jason Cooper,
netdev@vger.kernel.org, Greg KH, linux-wireless@vger.kernel.org,
John W. Linville, linux-kernel@vger.kernel.org, Mike Rapoport,
Andy Shevchenko, Johannes Berg
In-Reply-To: <20101213193111.GK2576@broadcom.com>
On Mon, Dec 13, 2010 at 11:31:11AM -0800, Henry Ptasinski wrote:
> On Thu, Dec 09, 2010 at 01:54:38PM -0800, Dave Hansen wrote:
> > On Thu, 2010-12-09 at 13:43 -0800, Greg KH wrote:
> > > On Thu, Dec 09, 2010 at 01:26:50PM -0800, Dave Hansen wrote:
> > > > I've been getting hard hangs when I toggle the wireless on a Lenovo
> > > > S10-3. It happens both with the physical switch and the Fn-F5 key
> > > > combo. It's quite repeatable. The system is quite stable when I'm not
> > > > trying to disable the wireless, though.
> > >
> > > What kernel version is this?
> > >
> > > Linus's latest tree has a known bug when the wireless is suspended and
> > > then resumed. Broadcom is working on it but no patch is forthcoming
> > > yet. Perhaps this is the same issue.
> >
> > Yeah, it's 2.6.37-rc5 plus a pull from:
> >
> > http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=summary
> >
> > That could easily be it. Thanks, Greg.
>
> Actually, I think it's the rfkill support (or lack thereof) that's causing you
> trouble. But we're looking at that as well.
>
> The outstanding reported issues that I'm aware of are:
> - 43224 crashes
> - missing rfkill support
> - suspend/resume problems
> - 4313 infinite loop in some cases
>
> In terms of process, should these all get filed in bugzilla.kernel.org (or
> somewhere else), or just track them via email and our TODO list?
Where ever you feel comfortable putting them, some like email, some like
bugzilla.kernel.org. The TODO list might be a bit tougher as it doesn't
always propagate to Linus fast enough (look at the differences between
it already in Linus's tree and linux-next, right?)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] compat-wireless: Rename config option to CONFIG_B43_PHY_N
From: Dave Vasilevsky @ 2010-12-13 19:39 UTC (permalink / raw)
To: lrodriguez, linux-wireless; +Cc: Dave Vasilevsky
Option CONFIG_B43_NPHY has been changed to COPNFIG_B43_PHY_N since linux-next
692d2c0fb36c02ad07d54641c26f48e644b27fbd.
Signed-off-by: Dave Vasilevsky <dave@vasilevsky.ca>
---
config.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config.mk b/config.mk
index 015f400..3261aa3 100644
--- a/config.mk
+++ b/config.mk
@@ -245,7 +245,7 @@ CONFIG_B43_PCMCIA=y
endif #CONFIG_PCMCIA
CONFIG_B43_LEDS=y
CONFIG_B43_PHY_LP=y
-CONFIG_B43_NPHY=y
+CONFIG_B43_PHY_N=y
# CONFIG_B43_FORCE_PIO=y
# CONFIG_B43_DEBUG=y
--
1.7.1
^ permalink raw reply related
* RE: brcm80211 locking up
From: Brett Rudley @ 2010-12-13 19:32 UTC (permalink / raw)
To: Sean Paul, Larry Finger; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTikYRuLi_8iXFnisH6g+-TmKPvvz2ERobq8Bjab9@mail.gmail.com>
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Sean Paul
> Sent: Monday, December 13, 2010 10:39 AM
> To: Larry Finger
> Cc: Brett Rudley; linux-wireless@vger.kernel.org
> Subject: Re: brcm80211 locking up
>
> Hi Larry,
> Thanks for the insight. It's very difficult to debug this since the
> loop is hosing my system, so it's unclear whether an unload/reload
> would fix the issue.
>
> Brett: Do you know the cause of the loop?
> Two issues:
- Something on your machine is forcing the radio off.
- The driver isn't handling the radio off condition during load.
The latter is on our todo list and I just haven't had time to deal with yet.
The former is odd... I haven't seen this before (except for when my RF switch was actually off).
What machine is this and have you seen the problem on any other type of machines? Does it happen all the time, some of the time?
Brett
^ permalink raw reply
* Re: brcm80211 hangs when disabling wireless
From: Henry Ptasinski @ 2010-12-13 19:31 UTC (permalink / raw)
To: Dave Hansen
Cc: Greg KH, John W. Linville, Johannes Berg, Brett Rudley,
Jason Cooper, Mike Rapoport, Andy Shevchenko,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
Henry Ptasinski, arend, rvossen
In-Reply-To: <1291931678.7960.32.camel@nimitz>
On Thu, Dec 09, 2010 at 01:54:38PM -0800, Dave Hansen wrote:
> On Thu, 2010-12-09 at 13:43 -0800, Greg KH wrote:
> > On Thu, Dec 09, 2010 at 01:26:50PM -0800, Dave Hansen wrote:
> > > I've been getting hard hangs when I toggle the wireless on a Lenovo
> > > S10-3. It happens both with the physical switch and the Fn-F5 key
> > > combo. It's quite repeatable. The system is quite stable when I'm not
> > > trying to disable the wireless, though.
> >
> > What kernel version is this?
> >
> > Linus's latest tree has a known bug when the wireless is suspended and
> > then resumed. Broadcom is working on it but no patch is forthcoming
> > yet. Perhaps this is the same issue.
>
> Yeah, it's 2.6.37-rc5 plus a pull from:
>
> http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=summary
>
> That could easily be it. Thanks, Greg.
Actually, I think it's the rfkill support (or lack thereof) that's causing you
trouble. But we're looking at that as well.
The outstanding reported issues that I'm aware of are:
- 43224 crashes
- missing rfkill support
- suspend/resume problems
- 4313 infinite loop in some cases
In terms of process, should these all get filed in bugzilla.kernel.org (or
somewhere else), or just track them via email and our TODO list?
Thanks,
- Henry
^ permalink raw reply
* Re: brcm80211 locking up
From: Sean Paul @ 2010-12-13 18:38 UTC (permalink / raw)
To: Larry Finger; +Cc: Brett Rudley, linux-wireless@vger.kernel.org
In-Reply-To: <4D06670B.90200@lwfinger.net>
Hi Larry,
Thanks for the insight. It's very difficult to debug this since the
loop is hosing my system, so it's unclear whether an unload/reload
would fix the issue.
Brett: Do you know the cause of the loop?
Thanks guys,
Sean
On Mon, Dec 13, 2010 at 10:33 AM, Larry Finger
<Larry.Finger@lwfinger.net> wrote:
> On 12/13/2010 12:22 PM, Sean Paul wrote:
>> Hey Brett,
>> I've checked the switch, it's enabled. I've also tried the code on a
>> different machine (same model) with the same result.
>>
>> Sean
>>
>> On Mon, Dec 13, 2010 at 10:21 AM, Brett Rudley <brudley@broadcom.com> wrote:
>>> Check the RF disable switch on your laptop (also known as airline switch, wireless disable switch, etc).
>>> It probably got bumped to the 'disabled' position.
>
> I have noticed some instances where a new kernel will come up with rfkill hard
> blocked even when the switch is in the on position, and in one case where the
> box does not even have a switch. These have been with b43, thus no hang.
> Unloading/reloading the driver fixes the issue, which I think is caused by an
> uninitialized variable in rfkill. Thus far, I have not found a cause, and have
> not previously reported it.
>
> In any case, booting the computer with the rf switch off should not cause an
> infinite loop.
>
> Larry
>
>
^ permalink raw reply
* Re: brcm80211 locking up
From: Larry Finger @ 2010-12-13 18:33 UTC (permalink / raw)
To: Sean Paul; +Cc: Brett Rudley, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTikL8M-nbCuhj4UmYVYEX-5ba2rRthTMFqbYqmwp@mail.gmail.com>
On 12/13/2010 12:22 PM, Sean Paul wrote:
> Hey Brett,
> I've checked the switch, it's enabled. I've also tried the code on a
> different machine (same model) with the same result.
>
> Sean
>
> On Mon, Dec 13, 2010 at 10:21 AM, Brett Rudley <brudley@broadcom.com> wrote:
>> Check the RF disable switch on your laptop (also known as airline switch, wireless disable switch, etc).
>> It probably got bumped to the 'disabled' position.
I have noticed some instances where a new kernel will come up with rfkill hard
blocked even when the switch is in the on position, and in one case where the
box does not even have a switch. These have been with b43, thus no hang.
Unloading/reloading the driver fixes the issue, which I think is caused by an
uninitialized variable in rfkill. Thus far, I have not found a cause, and have
not previously reported it.
In any case, booting the computer with the rf switch off should not cause an
infinite loop.
Larry
^ permalink raw reply
* Stable extra versions on linux-next.git
From: Luis R. Rodriguez @ 2010-12-13 18:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-kernel, linux-wireless, Greg KH
Stephen,
I'm using linux-next.git to suck out pending stable patches for some
releases for 802.11 using compat-wireless. This works great for the
first stable release of a kernel, so for example 2.6.36 was released
but there were a few stable patches I wanted to suck in for a release
for compat-wireless-2.6.36 so I used linux-next.git and used this:
git format-patch --grep=stable@kernel.org -o pending-stable/ v2.6.36..
net/wireless/
net/wireless/
net/mac80211/
net/rfkill/
drivers/net/wireless/
net/bluetooth/
drivers/bluetooth/
drivers/net/atl1c/
drivers/net/atl1e/
drivers/net/atlx/
include/linux/nl80211.h
include/linux/rfkill.h
include/net/cfg80211.h
include/net/mac80211.h
include/net/regulatory.h
include/net/cfg80211.h
To suck out pending-stable patches so I can apply to my local tarball.
I just noticed linux-next.git doesn't suck in the stable extra
versions though. The extra version stable updates are available
through hpa's linux-2.6-allstable.git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
Now, I have three trees:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
My wireless-testing.git tree is the original fresh clonse, all others
are cloned with --reference pointing to the wireless-testing/.git
directory. This lets me removes the need to suck in objects which all
trees have in common. What it seems I want is to generate a
format-patch from one old stable-extra-version to a new linux-next
tag.
git format-patch --grep=stable@kernel.org -o pending-stable/
v2.6.36.2..next-20101213
I tried this from my wireless-testing directory but with no luck, it
doesn't know about the linux-2.6-allstable.git tags and linux-next.git
tags, and my linux-next tree tree is unaware of the extra version
stable updates. Any ideas if I can get this working somehow?
Luis
^ permalink raw reply
* Re: brcm80211 locking up
From: Sean Paul @ 2010-12-13 18:22 UTC (permalink / raw)
To: Brett Rudley; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <7A94256FD72B884D9E7C55586C3CBCEE13856A173D@SJEXCHCCR01.corp.ad.broadcom.com>
Hey Brett,
I've checked the switch, it's enabled. I've also tried the code on a
different machine (same model) with the same result.
Sean
On Mon, Dec 13, 2010 at 10:21 AM, Brett Rudley <brudley@broadcom.com> wrote:
> Check the RF disable switch on your laptop (also known as airline switch, wireless disable switch, etc).
> It probably got bumped to the 'disabled' position.
>
> Brett
>
>> -----Original Message-----
>> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] On Behalf Of Sean Paul
>> Sent: Monday, December 13, 2010 10:02 AM
>> To: linux-wireless@vger.kernel.org
>> Subject: brcm80211 locking up
>>
>> Hello,
>> I've recently started encountering issues with the brcm80211 driver
>> and my 4313 wireless chipset (with kernel 2.6.35). It was working for
>> me a couple of weeks ago, but is now locking up my machine on boot.
>>
>> I'm using the following kernel config values:
>> CONFIG_BRCM80211=m
>> CONFIG_BRCM80211_PCI=y
>> # CONFIG_BRCMFMAC is not set
>>
>> I've tracked the issue down to the following line (in
>> brcm80211/sys/wlc_bmac.c, function wlc_bmac_radio_read_hwdisabled):
>> v = ((R_REG(wlc_hw->osh, &wlc_hw->regs->phydebug) & PDBG_RFD) != 0);
>>
>> If v equates to true here the driver seems to get stuck in a loop and
>> brings everything down with it. If I hardcode v to false, the driver
>> works, I can connect to my wireless network and browse the Internet.
>>
>> I've pasted the dmesg output in this email below, I've added breaks to
>> show where the driver goes off the rails. The "ops->tx called while
>> down" message followed by the "tx refused but queue active" warning
>> repeats until the device becomes unresponsive.
>>
>> Is this a known issue?
>>
>> Thanks,
>>
>> Sean
>>
>> dmesg output (slightly augmented with my own debug messages):
>>
>> # modprobe brcm80211
>> 2010-12-10T11:44:46.590263-08:00 localhost kernel: [ 389.590062]
>> brcm80211: module is from the staging directory, the quality is
>> unknown, you have been warned.
>> 2010-12-10T11:44:46.606997-08:00 localhost kernel: [ 389.606782]
>> wl_pci_probe: bus 7 slot 0 func 0 irq 11
>> 2010-12-10T11:44:46.607045-08:00 localhost kernel: [ 389.606828]
>> brcm80211 0000:07:00.0: enabling device (0104 -> 0106)
>> 2010-12-10T11:44:46.607068-08:00 localhost kernel: [ 389.606850]
>> brcm80211 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
>> 2010-12-10T11:44:46.607090-08:00 localhost kernel: [ 389.606871]
>> brcm80211 0000:07:00.0: setting latency timer to 64
>> 2010-12-10T11:44:46.607108-08:00 localhost kernel: [ 389.606907] PCI/DMA
>> 2010-12-10T11:44:47.016728-08:00 localhost kernel: [ 390.015542]
>> wlc_protection_upd: idx 2, val -1
>> 2010-12-10T11:44:47.016796-08:00 localhost kernel: [ 390.015551]
>> wlc_protection_upd: idx 1, val 0
>> 2010-12-10T11:44:47.016852-08:00 localhost kernel: [ 390.015558]
>> wlc_protection_upd: idx 12, val -1
>> 2010-12-10T11:44:47.016994-08:00 localhost kernel: [ 390.015563]
>> wlc_protection_upd: idx 11, val 0
>> 2010-12-10T11:44:47.017049-08:00 localhost kernel: [ 390.015568]
>> wlc_protection_upd: idx 14, val -1
>> 2010-12-10T11:44:47.017103-08:00 localhost kernel: [ 390.015573]
>> wlc_protection_upd: idx 13, val 0
>> 2010-12-10T11:44:47.017156-08:00 localhost kernel: [ 390.015578]
>> wlc_protection_upd: idx 15, val -1
>> 2010-12-10T11:44:47.017181-08:00 localhost kernel: [ 390.015584]
>> wlc_protection_upd: idx 4, val 2
>> 2010-12-10T11:44:47.017228-08:00 localhost kernel: [ 390.015594] wl0:
>> wlc_bmac_attach: vendor 0x14e4 device 0x4727
>> 2010-12-10T11:44:47.017282-08:00 localhost kernel: [ 390.015673]
>> Found chip type AI (0x13814313)
>> 2010-12-10T11:44:47.022196-08:00 localhost kernel: [ 390.021343]
>> Changing max_res_mask to 0xffff
>> 2010-12-10T11:44:47.022237-08:00 localhost kernel: [ 390.021350]
>> Changing min_res_mask to 0x200d
>> 2010-12-10T11:44:47.028223-08:00 localhost kernel: [ 390.027513]
>> Applying 4313 WARs
>> 2010-12-10T11:44:47.028263-08:00 localhost kernel: [ 390.027591] wl0:
>> wlc_bmac_corereset
>> 2010-12-10T11:44:47.028281-08:00 localhost kernel: [ 390.028142] wl0:
>> wlc_bmac_phy_reset
>> 2010-12-10T11:44:47.028297-08:00 localhost kernel: [ 390.028146] wl0:
>> wlc_bmac_core_phypll_ctl
>> 2010-12-10T11:44:47.028316-08:00 localhost kernel: [ 390.028165] wl0:
>> validate_chip_access
>> 2010-12-10T11:44:47.028342-08:00 localhost kernel: [ 390.028240] wl0:
>> wlc_setxband: bandunit 0
>> 2010-12-10T11:44:47.028371-08:00 localhost kernel: [ 390.028295] wl0:
>> wlc_bmac_corereset
>> 2010-12-10T11:44:47.028421-08:00 localhost kernel: [ 390.028427] wl0:
>> wlc_bmac_phy_reset
>> 2010-12-10T11:44:47.028446-08:00 localhost kernel: [ 390.028435] wl0:
>> wlc_bmac_core_phypll_ctl
>> 2010-12-10T11:44:47.029280-08:00 localhost kernel: [ 390.028867] wl0:
>> wlc_coredisable
>> 2010-12-10T11:44:47.029303-08:00 localhost kernel: [ 390.028941] wl0:
>> wlc_bmac_core_phypll_ctl
>> 2010-12-10T11:44:47.029322-08:00 localhost kernel: [ 390.029013] wl0:
>> wlc_bmac_xtal: want 0
>> 2010-12-10T11:44:47.029342-08:00 localhost kernel: [ 390.029033]
>> wlc_bmac_attach:: deviceid 0x4727 nbands 1 board 0x510 macaddr:
>> 00:26:82:b6:f8:81
>> 2010-12-10T11:44:47.029363-08:00 localhost kernel: [ 390.029041]
>> wlc_protection_upd: idx 15, val 115
>> 2010-12-10T11:44:47.029382-08:00 localhost kernel: [ 390.029048]
>> wlc_bmac_copyfrom_vars, nvram vars totlen=2299
>> 2010-12-10T11:44:47.029404-08:00 localhost kernel: [ 390.029093] wl0:
>> wlc_stf_spatial_policy_set: val 0
>> 2010-12-10T11:44:47.029429-08:00 localhost kernel: [ 390.029099] wl0:
>> wlc_stf_txcore_set: Nsts 1 core_mask 1
>> 2010-12-10T11:44:47.029451-08:00 localhost kernel: [ 390.029105] wl0:
>> wlc_stf_txcore_set: Nsts 2 core_mask 3
>> 2010-12-10T11:44:47.029470-08:00 localhost kernel: [ 390.029111] wl0:
>> wlc_stf_txcore_set: Nsts 3 core_mask 7
>> 2010-12-10T11:44:47.029491-08:00 localhost kernel: [ 390.029118] wl0:
>> wlc_stf_txcore_set: Nsts 4 core_mask f
>> 2010-12-10T11:44:47.029509-08:00 localhost kernel: [ 390.029127]
>> wlc_protection_upd: idx 3, val 1
>> 2010-12-10T11:44:47.029528-08:00 localhost kernel: [ 390.029132]
>> wlc_protection_upd: idx 10, val 1
>> 2010-12-10T11:44:47.029549-08:00 localhost kernel: [ 390.029157] wl0:
>> wlc_channel_mgr_attach
>> 2010-12-10T11:44:47.029567-08:00 localhost kernel: [ 390.029173]
>> wlc_protection_upd: idx 3, val 1
>> 2010-12-10T11:44:47.030110-08:00 localhost kernel: [ 390.029788] wl0:
>> wlc_doiovar
>> 2010-12-10T11:44:47.030133-08:00 localhost kernel: [ 390.029799] wl0:
>> wlc_doiovar: id 1
>> 2010-12-10T11:44:47.044182-08:00 localhost flimflamd[1046]: wlan0
>> {create} index 6 type 1 <ETHER>
>> 2010-12-10T11:44:47.044212-08:00 localhost kernel: [ 390.041847]
>> phy0: Selected rate control algorithm 'minstrel'
>> 2010-12-10T11:44:47.045776-08:00 localhost kernel: [ 390.044371]
>> wl_set_hint: Sending country code US to MAC80211
>> 2010-12-10T11:44:47.045812-08:00 localhost kernel: [ 390.044394] wl0:
>> Broadcom BCM43xx 802.11 MAC80211 Driver 5.75.11 (1.82.8.0) (Compiled
>> in . at 14:11:26 on Dec 10 2010)
>> 2010-12-10T11:44:47.045835-08:00 localhost kernel: [ 390.044418]
>> cfg80211: Calling CRDA for country: US
>> 2010-12-10T11:44:47.069896-08:00 localhost udevd[974]: unknown key
>> 'HOTPLUG' in /etc/udev/rules.d/99-monitor-hotplug.rules:2
>> 2010-12-10T11:44:47.077280-08:00 localhost kernel: [ 390.076803] wl0:
>> wlc_up:
>> 2010-12-10T11:44:47.077327-08:00 localhost kernel: [ 390.076824] wl0:
>> wlc_up: radio is up
>> 2010-12-10T11:44:47.077349-08:00 localhost kernel: [ 390.076830] wl0:
>> wlc_up: hw not up
>> 2010-12-10T11:44:47.077364-08:00 localhost kernel: [ 390.076836] wl0:
>> wlc_bmac_hw_up:
>> 2010-12-10T11:44:47.077379-08:00 localhost kernel: [ 390.076842] wl0:
>> wlc_bmac_xtal: want 1
>> 2010-12-10T11:44:47.077394-08:00 localhost kernel: [ 390.076928] wl0:
>> wlc_up: radio_disabled=0
>> 2010-12-10T11:44:47.077415-08:00 localhost kernel: [ 390.076935] wl0:
>> wlc_bmac_up_prep:
>> 2010-12-10T11:44:47.077431-08:00 localhost kernel: [ 390.076940] wl0:
>> wlc_bmac_xtal: want 1
>> 2010-12-10T11:44:47.077447-08:00 localhost kernel: [ 390.076947] wl0:
>> wlc_bmac_up_prep: Bus type is PCI
>> 2010-12-10T11:44:47.077465-08:00 localhost kernel: [ 390.076959]
>> wlc_bmac_radio_read_hwdisabled: enter
>> 2010-12-10T11:44:47.077480-08:00 localhost kernel: [ 390.076965]
>> wlc_bmac_radio_read_hwdisabled: !clk
>> 2010-12-10T11:44:47.077495-08:00 localhost kernel: [ 390.076999]
>> wlc_bmac_radio_read_hwdisabled: v=true
>> 2010-12-10T11:44:47.077511-08:00 localhost kernel: [ 390.077004]
>> wlc_bmac_radio_read_hwdisabled: !clk, disable core
>> 2010-12-10T11:44:47.077526-08:00 localhost kernel: [ 390.077062] wl0:
>> wlc_bmac_xtal: want 0
>> 2010-12-10T11:44:47.077541-08:00 localhost kernel: [ 390.077069] wl0:
>> wlc_up: radio off
>> 2010-12-10T11:44:47.077560-08:00 localhost kernel: [ 390.077075] wl0:
>> wlc_up: radio_disabled(2)=2
>> 2010-12-10T11:44:47.077576-08:00 localhost kernel: [ 390.077086] wl0:
>> wlc_up: exiting early :(
>>
>>
>> At this point, wlc_up exits early, which causes the "wl0:
>> wlc_wme_setparams : no-clock" errors below.
>>
>>
>> 2010-12-10T11:44:47.082288-08:00 localhost kernel: [ 390.081513] wl0:
>> wlc_doiovar
>> 2010-12-10T11:44:47.082357-08:00 localhost kernel: [ 390.081523] wl0:
>> wlc_doiovar: id 3
>> 2010-12-10T11:44:47.082375-08:00 localhost kernel: [ 390.081528] wl0:
>> wlc_doiovar
>> 2010-12-10T11:44:47.082396-08:00 localhost kernel: [ 390.081552] wl0:
>> wlc_doiovar: id 3
>> 2010-12-10T11:44:47.082415-08:00 localhost kernel: [ 390.081557] wl0:
>> wlc_doiovar
>> 2010-12-10T11:44:47.082431-08:00 localhost kernel: [ 390.081562] wl0:
>> wlc_doiovar: id 2
>> 2010-12-10T11:44:47.082449-08:00 localhost kernel: [ 390.081568] wl0:
>> wlc_doiovar
>> 2010-12-10T11:44:47.082465-08:00 localhost kernel: [ 390.081573] wl0:
>> wlc_doiovar: id 2
>> 2010-12-10T11:44:47.082481-08:00 localhost kernel: [ 390.081615] wl0:
>> wlc_wme_setparams : no-clock
>> 2010-12-10T11:44:47.082501-08:00 localhost kernel: [ 390.081621] wl0:
>> wlc_wme_setparams : no-clock
>> 2010-12-10T11:44:47.082521-08:00 localhost kernel: [ 390.081627] wl0:
>> wlc_wme_setparams : no-clock
>> 2010-12-10T11:44:47.082536-08:00 localhost kernel: [ 390.081633] wl0:
>> wlc_wme_setparams : no-clock
>> 2010-12-10T11:44:47.082561-08:00 localhost kernel: [ 390.082204]
>> ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> 2010-12-10T11:44:47.097526-08:00 localhost udevd[974]: unknown key
>> 'HOTPLUG' in /etc/udev/rules.d/99-monitor-hotplug.rules:2
>> 2010-12-10T11:44:47.268948-08:00 localhost kernel: [ 390.268195]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269008-08:00 localhost kernel: [ 390.268207]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269035-08:00 localhost kernel: [ 390.268214]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269063-08:00 localhost kernel: [ 390.268220]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269090-08:00 localhost kernel: [ 390.268226]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269117-08:00 localhost kernel: [ 390.268232]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269143-08:00 localhost kernel: [ 390.268238]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269171-08:00 localhost kernel: [ 390.268244]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269197-08:00 localhost kernel: [ 390.268290]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269225-08:00 localhost kernel: [ 390.268298]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269256-08:00 localhost kernel: [ 390.268306]
>> ops->tx called while down
>> 2010-12-10T11:44:47.269285-08:00 localhost kernel: [ 390.268314]
>> ------------[ cut here ]------------
>> 2010-12-10T11:44:47.269318-08:00 localhost kernel: [ 390.268353]
>> WARNING: at net/mac80211/tx.c:1438 ieee80211_pspoll_get+0x1405/0x1569
>> [mac80211]()
>> 2010-12-10T11:44:47.269348-08:00 localhost kernel: [ 390.268365]
>> Hardware name: 20040M18
>> 2010-12-10T11:44:47.269377-08:00 localhost kernel: [ 390.268373] tx
>> refused but queue active
>> 2010-12-10T11:44:47.269427-08:00 localhost kernel: [ 390.268381]
>> Modules linked in: brcm80211(C) uvcvideo videodev hid_cando tsl2563(C)
>> industrialio(C) snd_hda_codec_conexant snd_hda_intel mac80211 rtc_cmos
>> snd_hda_codec serio_raw snd_hwdep tpm_tis tpm snd_pcm cfg80211
>> tpm_bios pcspkr xt_mark tg3 wmi i2c_i801 snd_timer nm10_gpio
>> snd_page_alloc i2c_dev [last unloaded: tpm_bios]
>> 2010-12-10T11:44:47.269465-08:00 localhost kernel: [ 390.268485] Pid:
>> 4123, comm: phy0 Tainted: G WC 2.6.35 #1
>> 2010-12-10T11:44:47.269495-08:00 localhost kernel: [ 390.268494] Call
>> Trace:
>> 2010-12-10T11:44:47.269532-08:00 localhost kernel: [ 390.268517]
>> [<7902d7da>] warn_slowpath_common+0x6a/0x7f
>> 2010-12-10T11:44:47.269568-08:00 localhost kernel: [ 390.268547]
>> [<b86b38c1>] ? ieee80211_pspoll_get+0x1405/0x1569 [mac80211]
>> 2010-12-10T11:44:47.269601-08:00 localhost kernel: [ 390.268566]
>> [<7902d862>] warn_slowpath_fmt+0x2b/0x2f
>> 2010-12-10T11:44:47.269632-08:00 localhost kernel: [ 390.268595]
>> [<b86b38c1>] ieee80211_pspoll_get+0x1405/0x1569 [mac80211]
>> 2010-12-10T11:44:47.269666-08:00 localhost kernel: [ 390.268628]
>> [<b86b3a1d>] ieee80211_pspoll_get+0x1561/0x1569 [mac80211]
>> 2010-12-10T11:44:47.269702-08:00 localhost kernel: [ 390.268657]
>> [<b86b23f0>] ? ieee80211_probereq_get+0xdd/0xf1 [mac80211]
>> 2010-12-10T11:44:47.269737-08:00 localhost kernel: [ 390.268686]
>> [<b86b3a67>] ieee80211_tx_skb+0x42/0x49 [mac80211]
>> 2010-12-10T11:44:47.269771-08:00 localhost kernel: [ 390.268714]
>> [<b86b69e8>] ieee80211_send_probe_req+0xb1/0xc1 [mac80211]
>> 2010-12-10T11:44:47.269806-08:00 localhost kernel: [ 390.268743]
>> [<b86a50e9>] ieee80211_scan_work+0x309/0x3b4 [mac80211]
>> 2010-12-10T11:44:47.269837-08:00 localhost kernel: [ 390.268764]
>> [<7903ee77>] worker_thread+0x140/0x1b3
>> 2010-12-10T11:44:47.269865-08:00 localhost kernel: [ 390.268792]
>> [<b86a4de0>] ? ieee80211_scan_work+0x0/0x3b4 [mac80211]
>> 2010-12-10T11:44:47.269955-08:00 localhost kernel: [ 390.268810]
>> [<7904211f>] ? autoremove_wake_function+0x0/0x34
>> 2010-12-10T11:44:47.269989-08:00 localhost kernel: [ 390.268827]
>> [<7903ed37>] ? worker_thread+0x0/0x1b3
>> 2010-12-10T11:44:47.270021-08:00 localhost kernel: [ 390.268841]
>> [<79041dc9>] kthread+0x64/0x69
>> 2010-12-10T11:44:47.270051-08:00 localhost kernel: [ 390.268856]
>> [<79041d65>] ? kthread+0x0/0x69
>> 2010-12-10T11:44:47.270086-08:00 localhost kernel: [ 390.268872]
>> [<79002d56>] kernel_thread_helper+0x6/0x10
>> 2010-12-10T11:44:47.270116-08:00 localhost kernel: [ 390.268883] ---[
>> end trace 6d450e935ee1897e ]---
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* RE: brcm80211 locking up
From: Brett Rudley @ 2010-12-13 18:21 UTC (permalink / raw)
To: Sean Paul, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimqTaTJYinS-AyyjwR2hD+zLYuzjC6W0jDXMyB9@mail.gmail.com>
Check the RF disable switch on your laptop (also known as airline switch, wireless disable switch, etc).
It probably got bumped to the 'disabled' position.
Brett
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Sean Paul
> Sent: Monday, December 13, 2010 10:02 AM
> To: linux-wireless@vger.kernel.org
> Subject: brcm80211 locking up
>
> Hello,
> I've recently started encountering issues with the brcm80211 driver
> and my 4313 wireless chipset (with kernel 2.6.35). It was working for
> me a couple of weeks ago, but is now locking up my machine on boot.
>
> I'm using the following kernel config values:
> CONFIG_BRCM80211=m
> CONFIG_BRCM80211_PCI=y
> # CONFIG_BRCMFMAC is not set
>
> I've tracked the issue down to the following line (in
> brcm80211/sys/wlc_bmac.c, function wlc_bmac_radio_read_hwdisabled):
> v = ((R_REG(wlc_hw->osh, &wlc_hw->regs->phydebug) & PDBG_RFD) != 0);
>
> If v equates to true here the driver seems to get stuck in a loop and
> brings everything down with it. If I hardcode v to false, the driver
> works, I can connect to my wireless network and browse the Internet.
>
> I've pasted the dmesg output in this email below, I've added breaks to
> show where the driver goes off the rails. The "ops->tx called while
> down" message followed by the "tx refused but queue active" warning
> repeats until the device becomes unresponsive.
>
> Is this a known issue?
>
> Thanks,
>
> Sean
>
> dmesg output (slightly augmented with my own debug messages):
>
> # modprobe brcm80211
> 2010-12-10T11:44:46.590263-08:00 localhost kernel: [ 389.590062]
> brcm80211: module is from the staging directory, the quality is
> unknown, you have been warned.
> 2010-12-10T11:44:46.606997-08:00 localhost kernel: [ 389.606782]
> wl_pci_probe: bus 7 slot 0 func 0 irq 11
> 2010-12-10T11:44:46.607045-08:00 localhost kernel: [ 389.606828]
> brcm80211 0000:07:00.0: enabling device (0104 -> 0106)
> 2010-12-10T11:44:46.607068-08:00 localhost kernel: [ 389.606850]
> brcm80211 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> 2010-12-10T11:44:46.607090-08:00 localhost kernel: [ 389.606871]
> brcm80211 0000:07:00.0: setting latency timer to 64
> 2010-12-10T11:44:46.607108-08:00 localhost kernel: [ 389.606907] PCI/DMA
> 2010-12-10T11:44:47.016728-08:00 localhost kernel: [ 390.015542]
> wlc_protection_upd: idx 2, val -1
> 2010-12-10T11:44:47.016796-08:00 localhost kernel: [ 390.015551]
> wlc_protection_upd: idx 1, val 0
> 2010-12-10T11:44:47.016852-08:00 localhost kernel: [ 390.015558]
> wlc_protection_upd: idx 12, val -1
> 2010-12-10T11:44:47.016994-08:00 localhost kernel: [ 390.015563]
> wlc_protection_upd: idx 11, val 0
> 2010-12-10T11:44:47.017049-08:00 localhost kernel: [ 390.015568]
> wlc_protection_upd: idx 14, val -1
> 2010-12-10T11:44:47.017103-08:00 localhost kernel: [ 390.015573]
> wlc_protection_upd: idx 13, val 0
> 2010-12-10T11:44:47.017156-08:00 localhost kernel: [ 390.015578]
> wlc_protection_upd: idx 15, val -1
> 2010-12-10T11:44:47.017181-08:00 localhost kernel: [ 390.015584]
> wlc_protection_upd: idx 4, val 2
> 2010-12-10T11:44:47.017228-08:00 localhost kernel: [ 390.015594] wl0:
> wlc_bmac_attach: vendor 0x14e4 device 0x4727
> 2010-12-10T11:44:47.017282-08:00 localhost kernel: [ 390.015673]
> Found chip type AI (0x13814313)
> 2010-12-10T11:44:47.022196-08:00 localhost kernel: [ 390.021343]
> Changing max_res_mask to 0xffff
> 2010-12-10T11:44:47.022237-08:00 localhost kernel: [ 390.021350]
> Changing min_res_mask to 0x200d
> 2010-12-10T11:44:47.028223-08:00 localhost kernel: [ 390.027513]
> Applying 4313 WARs
> 2010-12-10T11:44:47.028263-08:00 localhost kernel: [ 390.027591] wl0:
> wlc_bmac_corereset
> 2010-12-10T11:44:47.028281-08:00 localhost kernel: [ 390.028142] wl0:
> wlc_bmac_phy_reset
> 2010-12-10T11:44:47.028297-08:00 localhost kernel: [ 390.028146] wl0:
> wlc_bmac_core_phypll_ctl
> 2010-12-10T11:44:47.028316-08:00 localhost kernel: [ 390.028165] wl0:
> validate_chip_access
> 2010-12-10T11:44:47.028342-08:00 localhost kernel: [ 390.028240] wl0:
> wlc_setxband: bandunit 0
> 2010-12-10T11:44:47.028371-08:00 localhost kernel: [ 390.028295] wl0:
> wlc_bmac_corereset
> 2010-12-10T11:44:47.028421-08:00 localhost kernel: [ 390.028427] wl0:
> wlc_bmac_phy_reset
> 2010-12-10T11:44:47.028446-08:00 localhost kernel: [ 390.028435] wl0:
> wlc_bmac_core_phypll_ctl
> 2010-12-10T11:44:47.029280-08:00 localhost kernel: [ 390.028867] wl0:
> wlc_coredisable
> 2010-12-10T11:44:47.029303-08:00 localhost kernel: [ 390.028941] wl0:
> wlc_bmac_core_phypll_ctl
> 2010-12-10T11:44:47.029322-08:00 localhost kernel: [ 390.029013] wl0:
> wlc_bmac_xtal: want 0
> 2010-12-10T11:44:47.029342-08:00 localhost kernel: [ 390.029033]
> wlc_bmac_attach:: deviceid 0x4727 nbands 1 board 0x510 macaddr:
> 00:26:82:b6:f8:81
> 2010-12-10T11:44:47.029363-08:00 localhost kernel: [ 390.029041]
> wlc_protection_upd: idx 15, val 115
> 2010-12-10T11:44:47.029382-08:00 localhost kernel: [ 390.029048]
> wlc_bmac_copyfrom_vars, nvram vars totlen=2299
> 2010-12-10T11:44:47.029404-08:00 localhost kernel: [ 390.029093] wl0:
> wlc_stf_spatial_policy_set: val 0
> 2010-12-10T11:44:47.029429-08:00 localhost kernel: [ 390.029099] wl0:
> wlc_stf_txcore_set: Nsts 1 core_mask 1
> 2010-12-10T11:44:47.029451-08:00 localhost kernel: [ 390.029105] wl0:
> wlc_stf_txcore_set: Nsts 2 core_mask 3
> 2010-12-10T11:44:47.029470-08:00 localhost kernel: [ 390.029111] wl0:
> wlc_stf_txcore_set: Nsts 3 core_mask 7
> 2010-12-10T11:44:47.029491-08:00 localhost kernel: [ 390.029118] wl0:
> wlc_stf_txcore_set: Nsts 4 core_mask f
> 2010-12-10T11:44:47.029509-08:00 localhost kernel: [ 390.029127]
> wlc_protection_upd: idx 3, val 1
> 2010-12-10T11:44:47.029528-08:00 localhost kernel: [ 390.029132]
> wlc_protection_upd: idx 10, val 1
> 2010-12-10T11:44:47.029549-08:00 localhost kernel: [ 390.029157] wl0:
> wlc_channel_mgr_attach
> 2010-12-10T11:44:47.029567-08:00 localhost kernel: [ 390.029173]
> wlc_protection_upd: idx 3, val 1
> 2010-12-10T11:44:47.030110-08:00 localhost kernel: [ 390.029788] wl0:
> wlc_doiovar
> 2010-12-10T11:44:47.030133-08:00 localhost kernel: [ 390.029799] wl0:
> wlc_doiovar: id 1
> 2010-12-10T11:44:47.044182-08:00 localhost flimflamd[1046]: wlan0
> {create} index 6 type 1 <ETHER>
> 2010-12-10T11:44:47.044212-08:00 localhost kernel: [ 390.041847]
> phy0: Selected rate control algorithm 'minstrel'
> 2010-12-10T11:44:47.045776-08:00 localhost kernel: [ 390.044371]
> wl_set_hint: Sending country code US to MAC80211
> 2010-12-10T11:44:47.045812-08:00 localhost kernel: [ 390.044394] wl0:
> Broadcom BCM43xx 802.11 MAC80211 Driver 5.75.11 (1.82.8.0) (Compiled
> in . at 14:11:26 on Dec 10 2010)
> 2010-12-10T11:44:47.045835-08:00 localhost kernel: [ 390.044418]
> cfg80211: Calling CRDA for country: US
> 2010-12-10T11:44:47.069896-08:00 localhost udevd[974]: unknown key
> 'HOTPLUG' in /etc/udev/rules.d/99-monitor-hotplug.rules:2
> 2010-12-10T11:44:47.077280-08:00 localhost kernel: [ 390.076803] wl0:
> wlc_up:
> 2010-12-10T11:44:47.077327-08:00 localhost kernel: [ 390.076824] wl0:
> wlc_up: radio is up
> 2010-12-10T11:44:47.077349-08:00 localhost kernel: [ 390.076830] wl0:
> wlc_up: hw not up
> 2010-12-10T11:44:47.077364-08:00 localhost kernel: [ 390.076836] wl0:
> wlc_bmac_hw_up:
> 2010-12-10T11:44:47.077379-08:00 localhost kernel: [ 390.076842] wl0:
> wlc_bmac_xtal: want 1
> 2010-12-10T11:44:47.077394-08:00 localhost kernel: [ 390.076928] wl0:
> wlc_up: radio_disabled=0
> 2010-12-10T11:44:47.077415-08:00 localhost kernel: [ 390.076935] wl0:
> wlc_bmac_up_prep:
> 2010-12-10T11:44:47.077431-08:00 localhost kernel: [ 390.076940] wl0:
> wlc_bmac_xtal: want 1
> 2010-12-10T11:44:47.077447-08:00 localhost kernel: [ 390.076947] wl0:
> wlc_bmac_up_prep: Bus type is PCI
> 2010-12-10T11:44:47.077465-08:00 localhost kernel: [ 390.076959]
> wlc_bmac_radio_read_hwdisabled: enter
> 2010-12-10T11:44:47.077480-08:00 localhost kernel: [ 390.076965]
> wlc_bmac_radio_read_hwdisabled: !clk
> 2010-12-10T11:44:47.077495-08:00 localhost kernel: [ 390.076999]
> wlc_bmac_radio_read_hwdisabled: v=true
> 2010-12-10T11:44:47.077511-08:00 localhost kernel: [ 390.077004]
> wlc_bmac_radio_read_hwdisabled: !clk, disable core
> 2010-12-10T11:44:47.077526-08:00 localhost kernel: [ 390.077062] wl0:
> wlc_bmac_xtal: want 0
> 2010-12-10T11:44:47.077541-08:00 localhost kernel: [ 390.077069] wl0:
> wlc_up: radio off
> 2010-12-10T11:44:47.077560-08:00 localhost kernel: [ 390.077075] wl0:
> wlc_up: radio_disabled(2)=2
> 2010-12-10T11:44:47.077576-08:00 localhost kernel: [ 390.077086] wl0:
> wlc_up: exiting early :(
>
>
> At this point, wlc_up exits early, which causes the "wl0:
> wlc_wme_setparams : no-clock" errors below.
>
>
> 2010-12-10T11:44:47.082288-08:00 localhost kernel: [ 390.081513] wl0:
> wlc_doiovar
> 2010-12-10T11:44:47.082357-08:00 localhost kernel: [ 390.081523] wl0:
> wlc_doiovar: id 3
> 2010-12-10T11:44:47.082375-08:00 localhost kernel: [ 390.081528] wl0:
> wlc_doiovar
> 2010-12-10T11:44:47.082396-08:00 localhost kernel: [ 390.081552] wl0:
> wlc_doiovar: id 3
> 2010-12-10T11:44:47.082415-08:00 localhost kernel: [ 390.081557] wl0:
> wlc_doiovar
> 2010-12-10T11:44:47.082431-08:00 localhost kernel: [ 390.081562] wl0:
> wlc_doiovar: id 2
> 2010-12-10T11:44:47.082449-08:00 localhost kernel: [ 390.081568] wl0:
> wlc_doiovar
> 2010-12-10T11:44:47.082465-08:00 localhost kernel: [ 390.081573] wl0:
> wlc_doiovar: id 2
> 2010-12-10T11:44:47.082481-08:00 localhost kernel: [ 390.081615] wl0:
> wlc_wme_setparams : no-clock
> 2010-12-10T11:44:47.082501-08:00 localhost kernel: [ 390.081621] wl0:
> wlc_wme_setparams : no-clock
> 2010-12-10T11:44:47.082521-08:00 localhost kernel: [ 390.081627] wl0:
> wlc_wme_setparams : no-clock
> 2010-12-10T11:44:47.082536-08:00 localhost kernel: [ 390.081633] wl0:
> wlc_wme_setparams : no-clock
> 2010-12-10T11:44:47.082561-08:00 localhost kernel: [ 390.082204]
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
> 2010-12-10T11:44:47.097526-08:00 localhost udevd[974]: unknown key
> 'HOTPLUG' in /etc/udev/rules.d/99-monitor-hotplug.rules:2
> 2010-12-10T11:44:47.268948-08:00 localhost kernel: [ 390.268195]
> ops->tx called while down
> 2010-12-10T11:44:47.269008-08:00 localhost kernel: [ 390.268207]
> ops->tx called while down
> 2010-12-10T11:44:47.269035-08:00 localhost kernel: [ 390.268214]
> ops->tx called while down
> 2010-12-10T11:44:47.269063-08:00 localhost kernel: [ 390.268220]
> ops->tx called while down
> 2010-12-10T11:44:47.269090-08:00 localhost kernel: [ 390.268226]
> ops->tx called while down
> 2010-12-10T11:44:47.269117-08:00 localhost kernel: [ 390.268232]
> ops->tx called while down
> 2010-12-10T11:44:47.269143-08:00 localhost kernel: [ 390.268238]
> ops->tx called while down
> 2010-12-10T11:44:47.269171-08:00 localhost kernel: [ 390.268244]
> ops->tx called while down
> 2010-12-10T11:44:47.269197-08:00 localhost kernel: [ 390.268290]
> ops->tx called while down
> 2010-12-10T11:44:47.269225-08:00 localhost kernel: [ 390.268298]
> ops->tx called while down
> 2010-12-10T11:44:47.269256-08:00 localhost kernel: [ 390.268306]
> ops->tx called while down
> 2010-12-10T11:44:47.269285-08:00 localhost kernel: [ 390.268314]
> ------------[ cut here ]------------
> 2010-12-10T11:44:47.269318-08:00 localhost kernel: [ 390.268353]
> WARNING: at net/mac80211/tx.c:1438 ieee80211_pspoll_get+0x1405/0x1569
> [mac80211]()
> 2010-12-10T11:44:47.269348-08:00 localhost kernel: [ 390.268365]
> Hardware name: 20040M18
> 2010-12-10T11:44:47.269377-08:00 localhost kernel: [ 390.268373] tx
> refused but queue active
> 2010-12-10T11:44:47.269427-08:00 localhost kernel: [ 390.268381]
> Modules linked in: brcm80211(C) uvcvideo videodev hid_cando tsl2563(C)
> industrialio(C) snd_hda_codec_conexant snd_hda_intel mac80211 rtc_cmos
> snd_hda_codec serio_raw snd_hwdep tpm_tis tpm snd_pcm cfg80211
> tpm_bios pcspkr xt_mark tg3 wmi i2c_i801 snd_timer nm10_gpio
> snd_page_alloc i2c_dev [last unloaded: tpm_bios]
> 2010-12-10T11:44:47.269465-08:00 localhost kernel: [ 390.268485] Pid:
> 4123, comm: phy0 Tainted: G WC 2.6.35 #1
> 2010-12-10T11:44:47.269495-08:00 localhost kernel: [ 390.268494] Call
> Trace:
> 2010-12-10T11:44:47.269532-08:00 localhost kernel: [ 390.268517]
> [<7902d7da>] warn_slowpath_common+0x6a/0x7f
> 2010-12-10T11:44:47.269568-08:00 localhost kernel: [ 390.268547]
> [<b86b38c1>] ? ieee80211_pspoll_get+0x1405/0x1569 [mac80211]
> 2010-12-10T11:44:47.269601-08:00 localhost kernel: [ 390.268566]
> [<7902d862>] warn_slowpath_fmt+0x2b/0x2f
> 2010-12-10T11:44:47.269632-08:00 localhost kernel: [ 390.268595]
> [<b86b38c1>] ieee80211_pspoll_get+0x1405/0x1569 [mac80211]
> 2010-12-10T11:44:47.269666-08:00 localhost kernel: [ 390.268628]
> [<b86b3a1d>] ieee80211_pspoll_get+0x1561/0x1569 [mac80211]
> 2010-12-10T11:44:47.269702-08:00 localhost kernel: [ 390.268657]
> [<b86b23f0>] ? ieee80211_probereq_get+0xdd/0xf1 [mac80211]
> 2010-12-10T11:44:47.269737-08:00 localhost kernel: [ 390.268686]
> [<b86b3a67>] ieee80211_tx_skb+0x42/0x49 [mac80211]
> 2010-12-10T11:44:47.269771-08:00 localhost kernel: [ 390.268714]
> [<b86b69e8>] ieee80211_send_probe_req+0xb1/0xc1 [mac80211]
> 2010-12-10T11:44:47.269806-08:00 localhost kernel: [ 390.268743]
> [<b86a50e9>] ieee80211_scan_work+0x309/0x3b4 [mac80211]
> 2010-12-10T11:44:47.269837-08:00 localhost kernel: [ 390.268764]
> [<7903ee77>] worker_thread+0x140/0x1b3
> 2010-12-10T11:44:47.269865-08:00 localhost kernel: [ 390.268792]
> [<b86a4de0>] ? ieee80211_scan_work+0x0/0x3b4 [mac80211]
> 2010-12-10T11:44:47.269955-08:00 localhost kernel: [ 390.268810]
> [<7904211f>] ? autoremove_wake_function+0x0/0x34
> 2010-12-10T11:44:47.269989-08:00 localhost kernel: [ 390.268827]
> [<7903ed37>] ? worker_thread+0x0/0x1b3
> 2010-12-10T11:44:47.270021-08:00 localhost kernel: [ 390.268841]
> [<79041dc9>] kthread+0x64/0x69
> 2010-12-10T11:44:47.270051-08:00 localhost kernel: [ 390.268856]
> [<79041d65>] ? kthread+0x0/0x69
> 2010-12-10T11:44:47.270086-08:00 localhost kernel: [ 390.268872]
> [<79002d56>] kernel_thread_helper+0x6/0x10
> 2010-12-10T11:44:47.270116-08:00 localhost kernel: [ 390.268883] ---[
> end trace 6d450e935ee1897e ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: compat-wireless-2.6: out of date b43 config option in config.mk
From: Luis R. Rodriguez @ 2010-12-13 18:19 UTC (permalink / raw)
To: Larry Finger; +Cc: Dave Vasilevsky, Luis R. Rodriguez, linux-wireless
In-Reply-To: <4D0661CF.7010905@lwfinger.net>
On Mon, Dec 13, 2010 at 10:11 AM, Larry Finger
<Larry.Finger@lwfinger.net> wrote:
> On 12/13/2010 11:43 AM, Luis R. Rodriguez wrote:
>> On Fri, Dec 10, 2010 at 07:46:16PM -0800, Dave Vasilevsky wrote:
>>> Hi Luis,
>>>
>>> Thanks for your work on compat-wireless, you are officially awesome :)
>>> I just noticed that recent changes in the b43 driver have renamed
>>> CONFIG_B43_NPHY to CONFIG_B43_PHY_N, but config.mk in
>>> compat-wireless-2.6 is still using the old config option name. Thought
>>> I should let you know.
>>
>> CONFIG_B43_NPHY is still used, and we have CONFIG_B43_PHY_LP=y as well.
>> I don't see any CONFIG_B43_PHY_N on upstream.
>
> It is in wireless-testing since commit 692d2c0fb36c02ad07d54641c26f48e644b27fbd,
> dated December 7.
Anyone care to send me a respective patch for compat-wireless?
Luis
^ permalink raw reply
* Re: compat-wireless-2.6: out of date b43 config option in config.mk
From: Larry Finger @ 2010-12-13 18:11 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Dave Vasilevsky, Luis R. Rodriguez, linux-wireless
In-Reply-To: <20101213174321.GB637@tux>
On 12/13/2010 11:43 AM, Luis R. Rodriguez wrote:
> On Fri, Dec 10, 2010 at 07:46:16PM -0800, Dave Vasilevsky wrote:
>> Hi Luis,
>>
>> Thanks for your work on compat-wireless, you are officially awesome :)
>> I just noticed that recent changes in the b43 driver have renamed
>> CONFIG_B43_NPHY to CONFIG_B43_PHY_N, but config.mk in
>> compat-wireless-2.6 is still using the old config option name. Thought
>> I should let you know.
>
> CONFIG_B43_NPHY is still used, and we have CONFIG_B43_PHY_LP=y as well.
> I don't see any CONFIG_B43_PHY_N on upstream.
It is in wireless-testing since commit 692d2c0fb36c02ad07d54641c26f48e644b27fbd,
dated December 7.
Larry
^ permalink raw reply
* brcm80211 locking up
From: Sean Paul @ 2010-12-13 18:02 UTC (permalink / raw)
To: linux-wireless
Hello,
I've recently started encountering issues with the brcm80211 driver
and my 4313 wireless chipset (with kernel 2.6.35). It was working for
me a couple of weeks ago, but is now locking up my machine on boot.
I'm using the following kernel config values:
CONFIG_BRCM80211=m
CONFIG_BRCM80211_PCI=y
# CONFIG_BRCMFMAC is not set
I've tracked the issue down to the following line (in
brcm80211/sys/wlc_bmac.c, function wlc_bmac_radio_read_hwdisabled):
v = ((R_REG(wlc_hw->osh, &wlc_hw->regs->phydebug) & PDBG_RFD) != 0);
If v equates to true here the driver seems to get stuck in a loop and
brings everything down with it. If I hardcode v to false, the driver
works, I can connect to my wireless network and browse the Internet.
I've pasted the dmesg output in this email below, I've added breaks to
show where the driver goes off the rails. The "ops->tx called while
down" message followed by the "tx refused but queue active" warning
repeats until the device becomes unresponsive.
Is this a known issue?
Thanks,
Sean
dmesg output (slightly augmented with my own debug messages):
# modprobe brcm80211
2010-12-10T11:44:46.590263-08:00 localhost kernel: [ 389.590062]
brcm80211: module is from the staging directory, the quality is
unknown, you have been warned.
2010-12-10T11:44:46.606997-08:00 localhost kernel: [ 389.606782]
wl_pci_probe: bus 7 slot 0 func 0 irq 11
2010-12-10T11:44:46.607045-08:00 localhost kernel: [ 389.606828]
brcm80211 0000:07:00.0: enabling device (0104 -> 0106)
2010-12-10T11:44:46.607068-08:00 localhost kernel: [ 389.606850]
brcm80211 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
2010-12-10T11:44:46.607090-08:00 localhost kernel: [ 389.606871]
brcm80211 0000:07:00.0: setting latency timer to 64
2010-12-10T11:44:46.607108-08:00 localhost kernel: [ 389.606907] PCI/DMA
2010-12-10T11:44:47.016728-08:00 localhost kernel: [ 390.015542]
wlc_protection_upd: idx 2, val -1
2010-12-10T11:44:47.016796-08:00 localhost kernel: [ 390.015551]
wlc_protection_upd: idx 1, val 0
2010-12-10T11:44:47.016852-08:00 localhost kernel: [ 390.015558]
wlc_protection_upd: idx 12, val -1
2010-12-10T11:44:47.016994-08:00 localhost kernel: [ 390.015563]
wlc_protection_upd: idx 11, val 0
2010-12-10T11:44:47.017049-08:00 localhost kernel: [ 390.015568]
wlc_protection_upd: idx 14, val -1
2010-12-10T11:44:47.017103-08:00 localhost kernel: [ 390.015573]
wlc_protection_upd: idx 13, val 0
2010-12-10T11:44:47.017156-08:00 localhost kernel: [ 390.015578]
wlc_protection_upd: idx 15, val -1
2010-12-10T11:44:47.017181-08:00 localhost kernel: [ 390.015584]
wlc_protection_upd: idx 4, val 2
2010-12-10T11:44:47.017228-08:00 localhost kernel: [ 390.015594] wl0:
wlc_bmac_attach: vendor 0x14e4 device 0x4727
2010-12-10T11:44:47.017282-08:00 localhost kernel: [ 390.015673]
Found chip type AI (0x13814313)
2010-12-10T11:44:47.022196-08:00 localhost kernel: [ 390.021343]
Changing max_res_mask to 0xffff
2010-12-10T11:44:47.022237-08:00 localhost kernel: [ 390.021350]
Changing min_res_mask to 0x200d
2010-12-10T11:44:47.028223-08:00 localhost kernel: [ 390.027513]
Applying 4313 WARs
2010-12-10T11:44:47.028263-08:00 localhost kernel: [ 390.027591] wl0:
wlc_bmac_corereset
2010-12-10T11:44:47.028281-08:00 localhost kernel: [ 390.028142] wl0:
wlc_bmac_phy_reset
2010-12-10T11:44:47.028297-08:00 localhost kernel: [ 390.028146] wl0:
wlc_bmac_core_phypll_ctl
2010-12-10T11:44:47.028316-08:00 localhost kernel: [ 390.028165] wl0:
validate_chip_access
2010-12-10T11:44:47.028342-08:00 localhost kernel: [ 390.028240] wl0:
wlc_setxband: bandunit 0
2010-12-10T11:44:47.028371-08:00 localhost kernel: [ 390.028295] wl0:
wlc_bmac_corereset
2010-12-10T11:44:47.028421-08:00 localhost kernel: [ 390.028427] wl0:
wlc_bmac_phy_reset
2010-12-10T11:44:47.028446-08:00 localhost kernel: [ 390.028435] wl0:
wlc_bmac_core_phypll_ctl
2010-12-10T11:44:47.029280-08:00 localhost kernel: [ 390.028867] wl0:
wlc_coredisable
2010-12-10T11:44:47.029303-08:00 localhost kernel: [ 390.028941] wl0:
wlc_bmac_core_phypll_ctl
2010-12-10T11:44:47.029322-08:00 localhost kernel: [ 390.029013] wl0:
wlc_bmac_xtal: want 0
2010-12-10T11:44:47.029342-08:00 localhost kernel: [ 390.029033]
wlc_bmac_attach:: deviceid 0x4727 nbands 1 board 0x510 macaddr:
00:26:82:b6:f8:81
2010-12-10T11:44:47.029363-08:00 localhost kernel: [ 390.029041]
wlc_protection_upd: idx 15, val 115
2010-12-10T11:44:47.029382-08:00 localhost kernel: [ 390.029048]
wlc_bmac_copyfrom_vars, nvram vars totlen=2299
2010-12-10T11:44:47.029404-08:00 localhost kernel: [ 390.029093] wl0:
wlc_stf_spatial_policy_set: val 0
2010-12-10T11:44:47.029429-08:00 localhost kernel: [ 390.029099] wl0:
wlc_stf_txcore_set: Nsts 1 core_mask 1
2010-12-10T11:44:47.029451-08:00 localhost kernel: [ 390.029105] wl0:
wlc_stf_txcore_set: Nsts 2 core_mask 3
2010-12-10T11:44:47.029470-08:00 localhost kernel: [ 390.029111] wl0:
wlc_stf_txcore_set: Nsts 3 core_mask 7
2010-12-10T11:44:47.029491-08:00 localhost kernel: [ 390.029118] wl0:
wlc_stf_txcore_set: Nsts 4 core_mask f
2010-12-10T11:44:47.029509-08:00 localhost kernel: [ 390.029127]
wlc_protection_upd: idx 3, val 1
2010-12-10T11:44:47.029528-08:00 localhost kernel: [ 390.029132]
wlc_protection_upd: idx 10, val 1
2010-12-10T11:44:47.029549-08:00 localhost kernel: [ 390.029157] wl0:
wlc_channel_mgr_attach
2010-12-10T11:44:47.029567-08:00 localhost kernel: [ 390.029173]
wlc_protection_upd: idx 3, val 1
2010-12-10T11:44:47.030110-08:00 localhost kernel: [ 390.029788] wl0:
wlc_doiovar
2010-12-10T11:44:47.030133-08:00 localhost kernel: [ 390.029799] wl0:
wlc_doiovar: id 1
2010-12-10T11:44:47.044182-08:00 localhost flimflamd[1046]: wlan0
{create} index 6 type 1 <ETHER>
2010-12-10T11:44:47.044212-08:00 localhost kernel: [ 390.041847]
phy0: Selected rate control algorithm 'minstrel'
2010-12-10T11:44:47.045776-08:00 localhost kernel: [ 390.044371]
wl_set_hint: Sending country code US to MAC80211
2010-12-10T11:44:47.045812-08:00 localhost kernel: [ 390.044394] wl0:
Broadcom BCM43xx 802.11 MAC80211 Driver 5.75.11 (1.82.8.0) (Compiled
in . at 14:11:26 on Dec 10 2010)
2010-12-10T11:44:47.045835-08:00 localhost kernel: [ 390.044418]
cfg80211: Calling CRDA for country: US
2010-12-10T11:44:47.069896-08:00 localhost udevd[974]: unknown key
'HOTPLUG' in /etc/udev/rules.d/99-monitor-hotplug.rules:2
2010-12-10T11:44:47.077280-08:00 localhost kernel: [ 390.076803] wl0: wlc_up:
2010-12-10T11:44:47.077327-08:00 localhost kernel: [ 390.076824] wl0:
wlc_up: radio is up
2010-12-10T11:44:47.077349-08:00 localhost kernel: [ 390.076830] wl0:
wlc_up: hw not up
2010-12-10T11:44:47.077364-08:00 localhost kernel: [ 390.076836] wl0:
wlc_bmac_hw_up:
2010-12-10T11:44:47.077379-08:00 localhost kernel: [ 390.076842] wl0:
wlc_bmac_xtal: want 1
2010-12-10T11:44:47.077394-08:00 localhost kernel: [ 390.076928] wl0:
wlc_up: radio_disabled=0
2010-12-10T11:44:47.077415-08:00 localhost kernel: [ 390.076935] wl0:
wlc_bmac_up_prep:
2010-12-10T11:44:47.077431-08:00 localhost kernel: [ 390.076940] wl0:
wlc_bmac_xtal: want 1
2010-12-10T11:44:47.077447-08:00 localhost kernel: [ 390.076947] wl0:
wlc_bmac_up_prep: Bus type is PCI
2010-12-10T11:44:47.077465-08:00 localhost kernel: [ 390.076959]
wlc_bmac_radio_read_hwdisabled: enter
2010-12-10T11:44:47.077480-08:00 localhost kernel: [ 390.076965]
wlc_bmac_radio_read_hwdisabled: !clk
2010-12-10T11:44:47.077495-08:00 localhost kernel: [ 390.076999]
wlc_bmac_radio_read_hwdisabled: v=true
2010-12-10T11:44:47.077511-08:00 localhost kernel: [ 390.077004]
wlc_bmac_radio_read_hwdisabled: !clk, disable core
2010-12-10T11:44:47.077526-08:00 localhost kernel: [ 390.077062] wl0:
wlc_bmac_xtal: want 0
2010-12-10T11:44:47.077541-08:00 localhost kernel: [ 390.077069] wl0:
wlc_up: radio off
2010-12-10T11:44:47.077560-08:00 localhost kernel: [ 390.077075] wl0:
wlc_up: radio_disabled(2)=2
2010-12-10T11:44:47.077576-08:00 localhost kernel: [ 390.077086] wl0:
wlc_up: exiting early :(
At this point, wlc_up exits early, which causes the "wl0:
wlc_wme_setparams : no-clock" errors below.
2010-12-10T11:44:47.082288-08:00 localhost kernel: [ 390.081513] wl0:
wlc_doiovar
2010-12-10T11:44:47.082357-08:00 localhost kernel: [ 390.081523] wl0:
wlc_doiovar: id 3
2010-12-10T11:44:47.082375-08:00 localhost kernel: [ 390.081528] wl0:
wlc_doiovar
2010-12-10T11:44:47.082396-08:00 localhost kernel: [ 390.081552] wl0:
wlc_doiovar: id 3
2010-12-10T11:44:47.082415-08:00 localhost kernel: [ 390.081557] wl0:
wlc_doiovar
2010-12-10T11:44:47.082431-08:00 localhost kernel: [ 390.081562] wl0:
wlc_doiovar: id 2
2010-12-10T11:44:47.082449-08:00 localhost kernel: [ 390.081568] wl0:
wlc_doiovar
2010-12-10T11:44:47.082465-08:00 localhost kernel: [ 390.081573] wl0:
wlc_doiovar: id 2
2010-12-10T11:44:47.082481-08:00 localhost kernel: [ 390.081615] wl0:
wlc_wme_setparams : no-clock
2010-12-10T11:44:47.082501-08:00 localhost kernel: [ 390.081621] wl0:
wlc_wme_setparams : no-clock
2010-12-10T11:44:47.082521-08:00 localhost kernel: [ 390.081627] wl0:
wlc_wme_setparams : no-clock
2010-12-10T11:44:47.082536-08:00 localhost kernel: [ 390.081633] wl0:
wlc_wme_setparams : no-clock
2010-12-10T11:44:47.082561-08:00 localhost kernel: [ 390.082204]
ADDRCONF(NETDEV_UP): wlan0: link is not ready
2010-12-10T11:44:47.097526-08:00 localhost udevd[974]: unknown key
'HOTPLUG' in /etc/udev/rules.d/99-monitor-hotplug.rules:2
2010-12-10T11:44:47.268948-08:00 localhost kernel: [ 390.268195]
ops->tx called while down
2010-12-10T11:44:47.269008-08:00 localhost kernel: [ 390.268207]
ops->tx called while down
2010-12-10T11:44:47.269035-08:00 localhost kernel: [ 390.268214]
ops->tx called while down
2010-12-10T11:44:47.269063-08:00 localhost kernel: [ 390.268220]
ops->tx called while down
2010-12-10T11:44:47.269090-08:00 localhost kernel: [ 390.268226]
ops->tx called while down
2010-12-10T11:44:47.269117-08:00 localhost kernel: [ 390.268232]
ops->tx called while down
2010-12-10T11:44:47.269143-08:00 localhost kernel: [ 390.268238]
ops->tx called while down
2010-12-10T11:44:47.269171-08:00 localhost kernel: [ 390.268244]
ops->tx called while down
2010-12-10T11:44:47.269197-08:00 localhost kernel: [ 390.268290]
ops->tx called while down
2010-12-10T11:44:47.269225-08:00 localhost kernel: [ 390.268298]
ops->tx called while down
2010-12-10T11:44:47.269256-08:00 localhost kernel: [ 390.268306]
ops->tx called while down
2010-12-10T11:44:47.269285-08:00 localhost kernel: [ 390.268314]
------------[ cut here ]------------
2010-12-10T11:44:47.269318-08:00 localhost kernel: [ 390.268353]
WARNING: at net/mac80211/tx.c:1438 ieee80211_pspoll_get+0x1405/0x1569
[mac80211]()
2010-12-10T11:44:47.269348-08:00 localhost kernel: [ 390.268365]
Hardware name: 20040M18
2010-12-10T11:44:47.269377-08:00 localhost kernel: [ 390.268373] tx
refused but queue active
2010-12-10T11:44:47.269427-08:00 localhost kernel: [ 390.268381]
Modules linked in: brcm80211(C) uvcvideo videodev hid_cando tsl2563(C)
industrialio(C) snd_hda_codec_conexant snd_hda_intel mac80211 rtc_cmos
snd_hda_codec serio_raw snd_hwdep tpm_tis tpm snd_pcm cfg80211
tpm_bios pcspkr xt_mark tg3 wmi i2c_i801 snd_timer nm10_gpio
snd_page_alloc i2c_dev [last unloaded: tpm_bios]
2010-12-10T11:44:47.269465-08:00 localhost kernel: [ 390.268485] Pid:
4123, comm: phy0 Tainted: G WC 2.6.35 #1
2010-12-10T11:44:47.269495-08:00 localhost kernel: [ 390.268494] Call Trace:
2010-12-10T11:44:47.269532-08:00 localhost kernel: [ 390.268517]
[<7902d7da>] warn_slowpath_common+0x6a/0x7f
2010-12-10T11:44:47.269568-08:00 localhost kernel: [ 390.268547]
[<b86b38c1>] ? ieee80211_pspoll_get+0x1405/0x1569 [mac80211]
2010-12-10T11:44:47.269601-08:00 localhost kernel: [ 390.268566]
[<7902d862>] warn_slowpath_fmt+0x2b/0x2f
2010-12-10T11:44:47.269632-08:00 localhost kernel: [ 390.268595]
[<b86b38c1>] ieee80211_pspoll_get+0x1405/0x1569 [mac80211]
2010-12-10T11:44:47.269666-08:00 localhost kernel: [ 390.268628]
[<b86b3a1d>] ieee80211_pspoll_get+0x1561/0x1569 [mac80211]
2010-12-10T11:44:47.269702-08:00 localhost kernel: [ 390.268657]
[<b86b23f0>] ? ieee80211_probereq_get+0xdd/0xf1 [mac80211]
2010-12-10T11:44:47.269737-08:00 localhost kernel: [ 390.268686]
[<b86b3a67>] ieee80211_tx_skb+0x42/0x49 [mac80211]
2010-12-10T11:44:47.269771-08:00 localhost kernel: [ 390.268714]
[<b86b69e8>] ieee80211_send_probe_req+0xb1/0xc1 [mac80211]
2010-12-10T11:44:47.269806-08:00 localhost kernel: [ 390.268743]
[<b86a50e9>] ieee80211_scan_work+0x309/0x3b4 [mac80211]
2010-12-10T11:44:47.269837-08:00 localhost kernel: [ 390.268764]
[<7903ee77>] worker_thread+0x140/0x1b3
2010-12-10T11:44:47.269865-08:00 localhost kernel: [ 390.268792]
[<b86a4de0>] ? ieee80211_scan_work+0x0/0x3b4 [mac80211]
2010-12-10T11:44:47.269955-08:00 localhost kernel: [ 390.268810]
[<7904211f>] ? autoremove_wake_function+0x0/0x34
2010-12-10T11:44:47.269989-08:00 localhost kernel: [ 390.268827]
[<7903ed37>] ? worker_thread+0x0/0x1b3
2010-12-10T11:44:47.270021-08:00 localhost kernel: [ 390.268841]
[<79041dc9>] kthread+0x64/0x69
2010-12-10T11:44:47.270051-08:00 localhost kernel: [ 390.268856]
[<79041d65>] ? kthread+0x0/0x69
2010-12-10T11:44:47.270086-08:00 localhost kernel: [ 390.268872]
[<79002d56>] kernel_thread_helper+0x6/0x10
2010-12-10T11:44:47.270116-08:00 localhost kernel: [ 390.268883] ---[
end trace 6d450e935ee1897e ]---
^ permalink raw reply
* Re: compat-wireless-2.6: out of date b43 config option in config.mk
From: Luis R. Rodriguez @ 2010-12-13 17:43 UTC (permalink / raw)
To: Dave Vasilevsky; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <AANLkTin-JwhK_SRhSPrzWJM6fJ9p_rEWVeTLGKk1pyUw@mail.gmail.com>
On Fri, Dec 10, 2010 at 07:46:16PM -0800, Dave Vasilevsky wrote:
> Hi Luis,
>
> Thanks for your work on compat-wireless, you are officially awesome :)
> I just noticed that recent changes in the b43 driver have renamed
> CONFIG_B43_NPHY to CONFIG_B43_PHY_N, but config.mk in
> compat-wireless-2.6 is still using the old config option name. Thought
> I should let you know.
CONFIG_B43_NPHY is still used, and we have CONFIG_B43_PHY_LP=y as well.
I don't see any CONFIG_B43_PHY_N on upstream.
Luis
^ permalink raw reply
* pull request: bluetooth-2.6 2010-12-13
From: Gustavo F. Padovan @ 2010-12-13 17:43 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth
Hi John,
The latest Bluetooth patches to linux 2.6.37. First is very critical fix a
break in the DUN profile connection setup. Second patch is also critical and
adds a NULL pointer protection in HCI code.
Please pull or let me know any problems! Thanks.
The following changes since commit 0a54917c3fc295cb61f3fb52373c173fd3b69f48:
orinoco: fix TKIP countermeasure behaviour (2010-12-08 15:24:06 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Johan Hedberg (1):
Bluetooth: Fix initial RFCOMM DLC security level
Jun Nie (1):
Bluetooth: add NULL pointer check in HCI
drivers/bluetooth/hci_ldisc.c | 6 ++++--
net/bluetooth/rfcomm/core.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] mac80211: avoid calling ieee80211_work_work unconditionally
From: Luis R. Rodriguez @ 2010-12-13 17:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: Herton Ronaldo Krzesinski, linux-wireless, John W Linville
In-Reply-To: <1292261649.3539.38.camel@jlt3.sipsolutions.net>
On Mon, Dec 13, 2010 at 9:34 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2010-12-13 at 09:29 -0800, Luis R. Rodriguez wrote:
>> On Mon, Dec 13, 2010 at 5:43 AM, Herton Ronaldo Krzesinski
>> <herton@mandriva.com.br> wrote:
>> > On suspend, there might be usb wireless drivers which wrongly trigger
>> > the warning in ieee80211_work_work. If an usb driver doesn't have a
>> > suspend hook, the usb stack will disconnect the device. On disconnect,
>> > a mac80211 driver calls ieee80211_unregister_hw, which calls dev_close,
>> > which calls ieee80211_stop, and in the end calls ieee80211_work_purge->
>> > ieee80211_work_work.
>> >
>> > The problem is that this call to ieee80211_work_purge comes after
>> > mac80211 is suspended, triggering the warning even when we don't have
>> > work queued in work_list (the expected case when already suspended),
>> > because it always calls ieee80211_work_work.
>> >
>> > So, just call ieee80211_work_work in ieee80211_work_purge if we really
>> > have to abort work. This addresses the warning reported at
>> > https://bugzilla.kernel.org/show_bug.cgi?id=24402
>> >
>> > Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
>>
>> Cc: stable@kernel.org ?
>
> It's just a warning, do we really want to bother?
Why not, it pollutes logs.
Luis
^ permalink raw reply
* Re: iwlcore not in update
From: Luis R. Rodriguez @ 2010-12-13 17:38 UTC (permalink / raw)
To: Bringfried Stecklum; +Cc: reinette chatre, linux-wireless
In-Reply-To: <AANLkTinak1g2w1WA44hDb5c=qaDu41SM=b5od-_+_iMu@mail.gmail.com>
Including linux-wireless
On Mon, Dec 13, 2010 at 9:38 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Sun, Dec 12, 2010 at 8:11 AM, Bringfried Stecklum
> <stecklum@tls-tautenburg.de> wrote:
>> Dear Luis,
>>
>> I tried to install compat-wireless-2010-12-07 a few days ago but failed. The
>> reason is that iwlcore does not get build and installed in the update
>> modules folder which, of course, leads unresolved symbols
>>
>> stecklum@extragalactix:~/System/src/compat-wireless-2.6.37-rc5-2-s$ sudo
>> modprobe -v iwlagn
>> insmod /lib/modules/2.6.36-1-generic/updates/compat/compat.ko
>> insmod /lib/modules/2.6.36-1-generic/updates/net/wireless/cfg80211.ko
>> insmod /lib/modules/2.6.36-1-generic/updates/net/mac80211/mac80211.ko
>> insmod
>> /lib/modules/2.6.36-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko
>> WARNING: Error inserting iwlcore
>> (/lib/modules/2.6.36-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko):
>> Invalid argument
>> insmod
>> /lib/modules/2.6.36-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko
>> FATAL: Error inserting iwlagn
>> (/lib/modules/2.6.36-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko):
>> Unknown symbol in module, or unknown parameter (see
>> dmesg)
>>
>> It seems I missed a change. In the past (e.g. compat-wireless-2010-05-22
>> and kernel 2.6.31), iwlcore.ko was build and installed
>>
>> stecklum@extragalactix:~/System$ locate iwlcore.ko
>> /lib/modules/2.6.31-22-generic/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko
>> /lib/modules/2.6.31-22-generic/updates/drivers/net/wireless/iwlwifi/iwlcore.ko
>> /lib/modules/2.6.36-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko
>
> Instead of CONFIG_IWLWIFI we use CONFIG_COMPAT_IWLWIFI, and we changed
> that the Makefile and config.mk
>
> mcgrof@tux ~/devel/compat-wireless-2.6 (git::linux-2.6.36.y)$ grep
> _IWLWIFI drivers/net/wireless/iwlwifi/Makefile
> obj-$(CONFIG_COMPAT_IWLWIFI) += iwlcore.o
> iwlcore-$(CONFIG_IWLWIFI_DEBUGFS) += iwl-debugfs.o
> iwlcore-$(CONFIG_IWLWIFI_DEVICE_TRACING) += iwl-devtrace.o
> iwlagn-$(CONFIG_IWLWIFI_DEBUGFS) += iwl-agn-debugfs.o
> iwl3945-$(CONFIG_IWLWIFI_DEBUGFS) += iwl-3945-debugfs.o
>
> mcgrof@tux ~/devel/compat-wireless-2.6 (git::linux-2.6.36.y)$ grep
> CONFIG_COMPAT_IWLWIFI config.mk
> CONFIG_COMPAT_IWLWIFI=m
>
> Can grep like this:
>
> mcgrof@tux ~/tmp/compat-wireless-2.6.37-rc5-4-sn $ grep
> CONFIG_COMPAT_IWLWIFI include/linux/compat_autoconf.h
> #ifndef CONFIG_COMPAT_IWLWIFI
> #define CONFIG_COMPAT_IWLWIFI 1
> #endif /* CONFIG_COMPAT_IWLWIFI *
>
> Luis
>
^ permalink raw reply
* Re: [PATCH] mac80211: avoid calling ieee80211_work_work unconditionally
From: Johannes Berg @ 2010-12-13 17:34 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Herton Ronaldo Krzesinski, linux-wireless, John W Linville
In-Reply-To: <AANLkTinnhSj=50agjC3mVDKF1Z7-rMdZ4oqZvwmitmmE@mail.gmail.com>
On Mon, 2010-12-13 at 09:29 -0800, Luis R. Rodriguez wrote:
> On Mon, Dec 13, 2010 at 5:43 AM, Herton Ronaldo Krzesinski
> <herton@mandriva.com.br> wrote:
> > On suspend, there might be usb wireless drivers which wrongly trigger
> > the warning in ieee80211_work_work. If an usb driver doesn't have a
> > suspend hook, the usb stack will disconnect the device. On disconnect,
> > a mac80211 driver calls ieee80211_unregister_hw, which calls dev_close,
> > which calls ieee80211_stop, and in the end calls ieee80211_work_purge->
> > ieee80211_work_work.
> >
> > The problem is that this call to ieee80211_work_purge comes after
> > mac80211 is suspended, triggering the warning even when we don't have
> > work queued in work_list (the expected case when already suspended),
> > because it always calls ieee80211_work_work.
> >
> > So, just call ieee80211_work_work in ieee80211_work_purge if we really
> > have to abort work. This addresses the warning reported at
> > https://bugzilla.kernel.org/show_bug.cgi?id=24402
> >
> > Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
>
> Cc: stable@kernel.org ?
It's just a warning, do we really want to bother?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: avoid calling ieee80211_work_work unconditionally
From: Luis R. Rodriguez @ 2010-12-13 17:29 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: linux-wireless, Johannes Berg, John W Linville
In-Reply-To: <20101213114351.47df9333@gotham.conectiva>
On Mon, Dec 13, 2010 at 5:43 AM, Herton Ronaldo Krzesinski
<herton@mandriva.com.br> wrote:
> On suspend, there might be usb wireless drivers which wrongly trigger
> the warning in ieee80211_work_work. If an usb driver doesn't have a
> suspend hook, the usb stack will disconnect the device. On disconnect,
> a mac80211 driver calls ieee80211_unregister_hw, which calls dev_close,
> which calls ieee80211_stop, and in the end calls ieee80211_work_purge->
> ieee80211_work_work.
>
> The problem is that this call to ieee80211_work_purge comes after
> mac80211 is suspended, triggering the warning even when we don't have
> work queued in work_list (the expected case when already suspended),
> because it always calls ieee80211_work_work.
>
> So, just call ieee80211_work_work in ieee80211_work_purge if we really
> have to abort work. This addresses the warning reported at
> https://bugzilla.kernel.org/show_bug.cgi?id=24402
>
> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: stable@kernel.org ?
Luis
^ permalink raw reply
* Re: Cannot set regdomain
From: Luis R. Rodriguez @ 2010-12-13 17:27 UTC (permalink / raw)
To: Dennis Borgmann; +Cc: linux-wireless
In-Reply-To: <4D05F37E.4080806@googlemail.com>
On Mon, Dec 13, 2010 at 2:20 AM, Dennis Borgmann
<dennis.borgmann@googlemail.com> wrote:
> Sorry folks! Absolutely my fault, since I did not install crda. I must
> have forgotten it.
That would do it ;)
Luis
^ permalink raw reply
* Re: Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Luis R. Rodriguez @ 2010-12-13 17:26 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, linux-kernel, linux-bluetooth
In-Reply-To: <201012130846.16522.holgerschurig@gmail.com>
On Sun, Dec 12, 2010 at 11:46 PM, Holger Schurig
<holgerschurig@gmail.com> wrote:
> Please, if the burden is not too much, keep it for the benefit of
> embedded people.
>
> If you have some embedded device (e.g. ARM based), it's usually not so
> easy to hieve this device to newest 2.6.3[5-7] kernel. However, it's
> easy to use your adapted kernel, and compile compat-wireless against it.
>
> I'm in such a situation with libertas_cs.
You use libertas_cs on an embedded device with compat-wireless, OK,
thanks for the feedback. If you can help with patches when PCMCIA crap
is advanced that would help too.
Luis
^ permalink raw reply
* Re: carl9170 802.11n-AP
From: Thomas @ 2010-12-13 17:24 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTimiNLZ8EFPEwbKW3UA7FMSxmJOV-B9pWY4h9c34@mail.gmail.com>
Today I tried a different wifi card on the client side, instead of the Intel
5100, but the problem remains the same. The carl9170 driver on my server
crashes at some point randomly (only in 802.11n mode). The traceback shows
the error at tx.c but everytime in a different line. So I guess there must
be a race condition somewhere.
Here you can find the error report of some crashes:
http://www.mikrocontroller.net/attachment/95144/bugreport.txt
Server hardware is a Seagate Dockstar with OpenWrt running on it. I heard
from another user with Debian, who has the same problem.
Regards,
Thomas
^ permalink raw reply
* Re: [RFC v2 0/2] implementation of scheduled scan
From: Luciano Coelho @ 2010-12-13 16:13 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1292012223.3531.32.camel@jlt3.sipsolutions.net>
On Fri, 2010-12-10 at 21:17 +0100, ext Johannes Berg wrote:
> On Fri, 2010-12-10 at 20:53 +0100, Johannes Berg wrote:
> > On Fri, 2010-12-10 at 17:07 +0200, luciano.coelho@nokia.com wrote:
> >
> > > * I kept the return value in the sched_scan_stop chain, because, at least with
> > > wl12xx, the call can fail (due to OOM for instance). I think it's cleaner
> > > this way.
> >
> > What's going to happen then though? Would it make sense to pre-allocate
> > this at start() time, so it can cleanly stop regardless of what's going
> > on? I can see start() failing, but stop() failing seems a bit hard to
> > work with in wpa_supplicant?
>
> Actually so the nl80211 interface has to be able to return something
> like "no such operation in progress" or whatever, but I'm not sure about
> the driver interface -- -ENOMEM seems like a stupid failure for stopping
> something, and then the above applies ...
Indeed returning -ENOMEM sounds stupid when trying to clean up
something...
In wl12xx there are two other ways the operation can fail: the stop
command can fail, and in this case we start a hw recovery, so there's no
problem; the stop command can time out, which is not handled. Maybe the
timeout should also trigger a hw recovery, but that's a different story.
So, the only thing remaining is the OOM. I guess I'll just have to deal
with it in the driver. We don't pre-alloc any commands at the moment,
but maybe it will have to be done in this case... Let's see.
I'll change the code so that the driver sched_scan stop interface
returns void.
Regarding the "no such operation in progress", I actually handle that by
simply returning with no error. Do you think I should return an error
in that case instead?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v3 1/8] ath9k_hw: only use the PCIe disable register write sequence for AR5416
From: Sujith @ 2010-12-13 16:03 UTC (permalink / raw)
To: Rajkumar Manoharan
Cc: Felix Fietkau, Felix Fietkau, linux-wireless@vger.kernel.org,
linville@tuxdriver.com, Luis Rodriguez, Sujith.Manoharan
In-Reply-To: <20101213134638.GA4622@vmraj-lnx.users.atheros.com>
Rajkumar Manoharan wrote:
> > Because it is only relevant for USB based devices.
> >
> True. This part is also applicable for HTC device like UB91.
Not really, this is not required for USB devices.
ath9k_hw_disablepcie() should probably not be called for USB devices.
We should also remove the useless calls to ath9k_hw_configpcipowersave()
in htc_start() and htc_stop().
Sujith
^ permalink raw reply
* Re: [RFC v2 1/2] cfg80211/nl80211: add support for scheduled scans
From: Luciano Coelho @ 2010-12-13 15:30 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1292011514.3531.19.camel@jlt3.sipsolutions.net>
On Fri, 2010-12-10 at 21:05 +0100, ext Johannes Berg wrote:
> On Fri, 2010-12-10 at 17:07 +0200, luciano.coelho@nokia.com wrote:
>
> > Add NL80211_CMD_START_SCHED_SCAN and NL80211_CMD_STOP_SCHED_SCAN
> > commands to the nl80211 interface. When results are available they are
> > reported by NL80211_CMD_SCHED_SCAN_RESULTS events.
>
> Oh, also, I think you should check the wiphy flag in the commands,
> because otherwise somebody will invariably end up writing a driver that
> doesn't set the flag, but still expect it to be working :-)
Done. It's a good idea to be extra-careful with driver implementations.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC v2 1/2] cfg80211/nl80211: add support for scheduled scans
From: Luciano Coelho @ 2010-12-13 14:04 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1292011406.3531.17.camel@jlt3.sipsolutions.net>
On Fri, 2010-12-10 at 21:03 +0100, ext Johannes Berg wrote:
> On Fri, 2010-12-10 at 17:07 +0200, luciano.coelho@nokia.com wrote:
> > With this feature we
> > can scan automatically for specific SSIDs (or any if not specified) at
> > certain intervals.
>
> I'd hope that "if not specified" actually means a passive scan like in
> normal scanning, and you need to specify the wildcard if you want to
> scan for it?
Good point. Actually, from the cfg/mac80211 point of view, this doesn't
really matter. It's just a matter of documenting it so that all the
drivers do it properly and in the same way.
I removed that part of the comment in the commit log and clarified this
in the NL80211 documentation.
For the wl12xx I need to check how exactly this works. As I understand
it, you can either filter on the specified SSIDs or send directed
probe_reqs (ie. with SSID IEs).
Would it make sense to make passive scans (with no SSID specified) and
still filter per SSID? If yes, we should add a new nested attribute to
NL80211 where we can pass the SSID filters.
Actually, I think having a separate NL80211 attribute for SSID filters
is a good idea. What if I remove this whole filtering thingy for now
and add it with a separate patch later?
> > + u8 max_sched_scan_ssids;
>
> shouldn't this be advertised in nl80211 as well?
I think this should be the same as for normal scans. What I have been
using it for was for the filtering SSIDs. I need to rethink the
filtering concept.
> > @@ -647,6 +648,11 @@ static void wdev_cleanup_work(struct work_struct *work)
> > ___cfg80211_scan_done(rdev, true);
> > }
> >
> > + if (rdev->sched_scan_req &&
> > + rdev->sched_scan_req->dev == wdev->netdev) {
> > + nl80211_sched_scan_stopped(rdev, wdev->netdev);
> > + }
>
> Hmm, are you sure that shouldn't be a warning like the scan case? If the
> driver didn't stop -- maybe this is still going on? I think instead the
> netdev down notifier should actually ask the device to stop the sched
> scan (core.c).
Yes, good point. This should work more like "disconnect", which is an
long term process. I have created __cfg80211_stop_sched_scan() and now
I call that from core.c at netdev down and from
nl80211_stop_sched_scan(). Looks cleaner, thanks!
> > + if (!rdev->ops->sched_scan_start) {
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + if (rdev->sched_scan_req) {
> > + return -EINPROGRESS;
> > + }
>
> bit too many braces for my taste :)
Heh, I was probably in an embracing mood when I wrote this. Removed.
> > + if (ie_len > wiphy->max_scan_ie_len)
> > + return -EINVAL;
>
> So # SSIDs is different, but IE len is the same? Isn't that a bad
> assumption to make?
Yes, you're right. As I wrote above, this was about SSID *filters* not
about SSIDs per scan. I'll remove the wiphy->max_sched_scan_ssids for
now and use max_scan_ssids instead.
> > + request->dev = dev;
> > + request->wiphy = &rdev->wiphy;
> > +
> > + rdev->sched_scan_req = request;
> > +
> > + err = rdev->ops->sched_scan_start(&rdev->wiphy, dev, request);
> > + if (!err) {
> > + nl80211_send_sched_scan(rdev, dev,
> > + NL80211_CMD_START_SCHED_SCAN);
> > + dev_hold(dev);
>
> I don't think you want the dev_hold here. That's a trick I used to warn
> about scans that didn't finish when the interface went down. Here,
> instead, since it's a longer-running process, you should do what I said
> above -- stop the sched scan when the interface is going down.
Right, it's not needed. I've removed it now.
> > + err = rdev->ops->sched_scan_stop(&rdev->wiphy, dev);
> > + if (err)
> > + goto out;
>
> return err; instead? There's no cleanup code at the out label :)
Yes, I'm just used to return at the end of the function whenever
possible. We agreed on using this as a coding style for the wl12xx
driver. And if you look at its code, you can see that we sometimes even
goto out from an if even when there's no code between the if block and
the label. Duh!
Fixed.
> > + nl80211_send_sched_scan(rdev, dev, NL80211_CMD_STOP_SCHED_SCAN);
> > +
> > + nl80211_sched_scan_stopped(rdev, dev);
>
> Shouldn't the former be part of the latter function? And actually,
> you'll want to roll it all into a helper function that you can call from
> the netdev down notifier :)
Sure, done as part of the change I described above.
--
Cheers,
Luca.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox