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