Michael,
I have some good news. The Netbook that came from John is suddenly
developing DMA errors for the BCM4312, even though it does not have a
Phoenix BIOS. I have no idea why it did not fail this way earlier, but at
least I have a machine to debug that failure.
My first discovery is that if PIO mode is to be used, it is not sufficient
to load the module with the "pio=1" option, but that both "qos=0" and
"nohwcrypt=1" options must also be used, at least for WPA/WPA2 networks.
No other combination works. In addition, the automatic failover to PIO
mode does not work unless those two options were used when the module was
loaded. Thus both of the following work:
modprobe b43 pio=1 qos=0 nohwcrypt=1
modprobe b43 qos=0 hwcrypt=1
The second example gets a fatal DMA error and resets the controller before
the network comes up. I tried setting the latter two options before the
controller reset call in the failover, but that did not work.
If you have suggestions on changes in the switch from DMA to PIO mode,
please send them to me. In the meantime, I will be looking at differences
in the MMIO traces between wl and b43 to try to fix the DMA problem at the
source of the trouble.
Larry
On 06/23/2010 07:42 AM, Michael B?sch wrote:
> Please note that there were some rewrites recently in the kernel
> DMA subsystem. b43 does now use the generic DMA interface, which
> should work on all busses. I would not rule out an error in
> that area, though it's unlikely.
I don't think that is a problem. None of my other 3 systems developed an
error with that change. In addition, the Netbook started working as
mysteriously as it had failed earlier. I just love intermittent cases. ;-)
Larry
On Tue, Jun 22, 2010 at 5:36 PM, Larry Finger <[email protected]> wrote:
> Michael,
>
> I have some good news. The Netbook that came from John is suddenly
> developing DMA errors for the BCM4312, even though it does not have a
> Phoenix BIOS. I have no idea why it did not fail this way earlier, but at
> least I have a machine to debug that failure.
Suddenly developing DMA errors? Hmm... maybe it's a hardware issue
with the card, from which wl can silently recover?
>
> My first discovery is that if PIO mode is to be used, it is not sufficient
> to load the module with the "pio=1" option, but that both "qos=0" and
> "nohwcrypt=1" options must also be used, at least for WPA/WPA2 networks.
> No other combination works. In addition, the automatic failover to PIO
> mode does not work unless those two options were used when the module was
> loaded. Thus both of the following work:
>
> modprobe b43 pio=1 qos=0 nohwcrypt=1
> modprobe b43 qos=0 hwcrypt=1
>
> The second example gets a fatal DMA error and resets the controller before
> the network comes up. I tried setting the latter two options before the
> controller reset call in the failover, but that did not work.
>
> If you have suggestions on changes in the switch from DMA to PIO mode,
> please send them to me. In the meantime, I will be looking at differences
> in the MMIO traces between wl and b43 to try to fix the DMA problem at the
> source of the trouble.
>
> Larry
>
> _______________________________________________
> b43-dev mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/b43-dev
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On 06/22/2010 05:36 PM, Larry Finger wrote:
> My first discovery is that if PIO mode is to be used, it is not sufficient
> to load the module with the "pio=1" option, but that both "qos=0" and
> "nohwcrypt=1" options must also be used, at least for WPA/WPA2 networks.
That is known. I posted it once or twice. It is b43 making bad
assumptions about mac80211 behavior. And mac80211 behavior changed...
b43 does modify the number of queues in the data structure after it
registered things to mac80211. That used to work properly in the past.
But it breaks now. The init does have to be re-ordered and implementation
of async firmware loading is required to fix that.
> No other combination works. In addition, the automatic failover to PIO
> mode does not work unless those two options were used when the module was
> loaded. Thus both of the following work:
It only works by accident anyway. But I already said that several times.
--
Greetings Michael.
Please note that there were some rewrites recently in the kernel
DMA subsystem. b43 does now use the generic DMA interface, which
should work on all busses. I would not rule out an error in
that area, though it's unlikely.
--
Greetings Michael.