Re: [PATCH 0/2] Fix lockdep warning in brcmsmac

[Hauke Mehrtens <hauke@hauke-m.de>]

On 08/02/2012 02:51 PM, Josh Boyer wrote:
> On Thu, Aug 02, 2012 at 08:02:30AM -0400, Josh Boyer wrote:
>> On Wed, Aug 01, 2012 at 08:53:20PM -0500, Seth Forshee wrote:
>>> On Wed, Aug 01, 2012 at 08:23:54PM -0400, Josh Boyer wrote:
>>>> On Wed, Aug 01, 2012 at 03:58:41PM -0500, Seth Forshee wrote:
>>>>> As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
>>>>> calling freq_reg_info() without holding cfg80211_lock. Currently
>>>>> freq_reg_info() is the only way for a wireless driver to tell whether
>>>>> OFDM is allowed on the current channel, but cfg80211_lock is outside the
>>>>> scope of the wireless drivers.
>>>>>
>>>>> Since other regulatory restrictions are communicated in the channel
>>>>> definition, it makes sense to do the same for OFDM. These patches add a
>>>>> new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
>>>>> indicated OFDM operation is prohibited. brcmsmac is modifified to use
>>>>> this flag instead of consuming the regulatory data directly.
>>>>>
>>>>> Thanks,
>>>>> Seth
>>>>>
>>>>>
>>>>> Seth Forshee (2):
>>>>>   cfg80211: add channel flag to restrict OFDM
>>>>>   brcmsmac: use channel flags to restrict OFDM
>>>>
>>>> I would love to test these, but at the moment I can't.  Oddly, the very
>>>> same machine I hit the problem with originally is no longer presenting
>>>> any devices on the bcma bus.  The driver is loaded, brcmsmac is loaded,
>>>> but neither output the devices that showed up in my original email.
>>>> This is with both the kernel I originally reported the problem with, and
>>>> other kernels.  Nothing shows up for the BCM4313 in lspci either.
>>>>
>>>> I did power it off and then back on today after I hit the original
>>>> problem, but I'd expect the hardware in the box to still show up on a
>>>> power on...  Is there some specific module load order, or something
>>>> else I can do to try and get the device to show up?
>>>>
>>>> I did build a kernel with your patches applied, so at least I know they
>>>> build.  If I can get this machine to probe the chip again, I'll be happy
>>>> to test.
>>>>
>>>> At the moment, I'm just very confused and slightly afraid it's going to
>>>> just refuse to work at all.
>>>
>>> Do you have 1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819? That fixed a bug
>>> that had caused some very odd behavior, like changing PCI device ids.
>>> Recovering after booting a bad kernel required a cold boot to a kernel
>>> with the fix; a warm reboot wasn't enough.
>>
>> The kernel I'm testing should have that commit in it.  I'll try a cold
>> boot to it to make sure.
> 
> That didn't help.  I've tried multiple module load orderings without
> anything being shown on the bcma bus.  The modules all load, but no
> devices are created.  It's as if the hardware was removed or something.
> Puzzling.
> 
> josh

Are you sure you have the commit
1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819 in your tree, this commit is
*not* in wireless-testing it is just in wireless-next-2.6 and linus tree
for 3.6-rc1. If lspci does not show the device, it has nothing to do
with some modules being loaded or not, at least when non of then is
controlling your PCIe bus. It could also be that a cold boot is not
enough to reset your device, what device are you using the BCM4313 in?

Hauke