On Thu, Aug 02, 2012 at 03:44:10PM +0200, Hauke Mehrtens wrote: > 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? Yes, I'm sure. I'm booting essentially Linus' latest git tree. Now, during a bisect I was doing yesterday it's quite possible I booted something that did not have that commit, but the last 3 kernels I have tried definitely had it and all were from cold boots. The newest kernel as of this morning is at 1a9b4993b70fb1884716902774dc9025b457760d. The BCM4313 is in a Dell XPS 8300 box. josh -- 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
