chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger <Larry.Finger@lwfinger.net>]

On 06/07/2012 11:03 AM, Michael B?sch wrote:
>
> b43 messes with the queue count at runtime. I guess that's the reason.
> I don't know if this can be fixed now, though. The problem is that we
> first need to load the firmware before we know the queue count.
> There seem to have been some firmware loading changes, but I didn't
> track those too closely. So I don't know whether they allow fixing the
> situation or not...

The only change in firmware loading is that the probe routine places a initiates 
an item on a work queue with the firmware loading routine as the callback. 
Previously, the fw load routines were called directly from the probe routine.

There is a bug in the new implementation that I am fixing. It results in the 
inability to load firmware whenever b43 is built in; however, as long as b43 is 
a module, it works fine.

I do not understand what is different about your system than mine. I have a 
Cardbus version of the BCM4318 running kernel 3.5-rc1 from mainline. The host 
computer is a PowerBook G4 Titanium (PPC). The chip has four hardware queues and 
never had the problem that was fixed with a9d3c05. When I had trouble, it was 
with a BCM4301, which does only have a single queue.

Is it possible that Nintendo uses a special version of the BCM4318 that only 
contains a single transmit queue?

I'm building 3.5-rc1 from wireless-testing, but that will take a while. That Mac 
is not very fast.

Larry