Hi,
(please cc me on replies)
We have a user that tried out b43, but got this in the logs:
--- cut ---
65858:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
support DMA on your system. Please use PIO instead. 65859:Feb 9
22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO must
be set in your kernel configuration.
65860:Feb 9 22:05:16 elmo kernel: b43-phy2 debug: Adding Interface type 2
65861:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: Fatal DMA error:
0x00000400, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
65862:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
support DMA on your system. Please use PIO instead.
65863:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO
must be set in your kernel configuration.
--- cut ---
But reading the Kconfig help, it states:
--- cut ---
config B43_FORCE_PIO
bool "Force usage of PIO instead of DMA"
depends on B43 && B43_DEBUG
---help---
This will disable DMA and always enable PIO instead.
Say N!
This is only for debugging the PIO engine code. You do
_NOT_ want to enable this.
--- cut ---
So,
wich one is it ?
Do I belive the dmesg output, or the Kconfig ?
Note,
the b43 works for the user if he enable the CONFIG_B43_FORCE_PIO.
But I'm thinking of this problem from a distro point of view.
Will it break for others if I enable it ?
--
Thomas
2010/2/14 Thomas Backlund <[email protected]>:
> G?bor Stefanik skrev 14.2.2010 20:59:
>>
>> On Sun, Feb 14, 2010 at 7:44 PM, Thomas Backlund<[email protected]> ?wrote:
>>>
>>> Larry Finger skrev 14.2.2010 18:36:
>>>>
>>>> On 02/14/2010 03:53 AM, Thomas Backlund wrote:
>>>>>
>>>>> Hi,
>>>>> (please cc me on replies)
>>>>>
>>>>> We have a user that tried out b43, but got this in the logs:
>>>>>
>>>>> --- cut ---
>>>>> 65858:Feb ?9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
>>>>> support DMA on your system. Please use PIO instead. 65859:Feb ?9
>>>>> 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO must
>>>>> be set in your kernel configuration.
>>>>> 65860:Feb ?9 22:05:16 elmo kernel: b43-phy2 debug: Adding Interface
>>>>> type
>>>>> 2
>>>>> 65861:Feb ?9 22:05:16 elmo kernel: b43-phy2 ERROR: Fatal DMA error:
>>>>> 0x00000400, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
>>>>>
>>>>> 65862:Feb ?9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
>>>>> support DMA on your system. Please use PIO instead.
>>>>> 65863:Feb ?9 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO
>>>>> must be set in your kernel configuration.
>>>>> --- cut ---
>>>>>
>>>>>
>>>>>
>>>>> But reading the Kconfig help, it states:
>>>>> --- cut ---
>>>>> config B43_FORCE_PIO
>>>>> ? ? ? ? bool "Force usage of PIO instead of DMA"
>>>>> ? ? ? ? depends on B43&& ? ?B43_DEBUG
>>>>> ? ? ? ? ---help---
>>>>> ? ? ? ? ? This will disable DMA and always enable PIO instead.
>>>>>
>>>>> ? ? ? ? ? Say N!
>>>>> ? ? ? ? ? This is only for debugging the PIO engine code. You do
>>>>> ? ? ? ? ? _NOT_ want to enable this.
>>>>> --- cut ---
>>>>>
>>>>>
>>>>> So,
>>>>> wich one is it ?
>>>>>
>>>>> Do I belive the dmesg output, or the Kconfig ?
>>>>>
>>>>> Note,
>>>>> the b43 works for the user if he enable the CONFIG_B43_FORCE_PIO.
>>>>>
>>>>> But I'm thinking of this problem from a distro point of view.
>>>>> Will it break for others if I enable it ?
>>>>
>>>>> ?From a distro point of view, you would not want to set FORCE_PIO as
>>>>> the
>>>>
>>>> performance penalty would be very large.
>>>>
>>>
>>> As I suspected.
>>> Thanks for confirming it.
>>>
>>>> You do not give the specific details on the problem system; however, it
>>>> is
>>>> probably a BCM4312 802.11 b/g device with PCI ID 14e4:4315 being used
>>>> with
>>>> an
>>>> Atom processor in a netbook. We have no fix.
>>>>
>>>
>>> Sorry about the missing info...
>>> I asked a few times from the user, and got no reponse until today a few
>>> hours after your response...
>>>
>>> It is indeed a BCM4312 802.11 b/g device with PCI ID 14e4:4315 on a Dell
>>> laptop with a Intel ICH9M series chipset and a Intel Core(TM)2 Duo CPU
>>> T7250
>>> @ 2.00GHz.
>>
>> Weird... that's not an Intel Atom, but a Core 2 Duo, standard-voltage.
>> Mind posting any more details on this system?
>>
>
> It's a Dell Latitude E5500, Bios A13.
>
> It's a 64bit kernel/userspace.
>
> The b43 firmware is: 478.104
>
> lspci -vvvnnn states:
> ?0c:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g
> [14e4:4315] (rev 01)
> ? ? ? ? Subsystem: Dell Wireless 1397 WLAN Mini-Card [1028:000c]
> ? ? ? ? Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
> ? ? ? ? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> ? ? ? ? Latency: 0, Cache Line Size: 64 bytes
> ? ? ? ? Interrupt: pin A routed to IRQ 17
> ? ? ? ? Region 0: Memory at f69fc000 (64-bit, non-prefetchable) [size=16K]
> ? ? ? ? Capabilities: <access denied>
> ? ? ? ? Kernel driver in use: b43-pci-bridge
> ? ? ? ? Kernel modules: wl, ssb
>
>
> Anything else you need ?
>
> --
> Thomas
>
Looks like the trigger is not Intel Atom, but PhoenixBIOS after all -
a quick analysis of bios v. A15 for this machine shows it to be a
highly cloaked/rebranded PhoenixBIOS.
Core 2 T7250 is a regular Merom/Santa Rosa CPU, almost the same as my
T7100 (only the clock multiplier is different), and is not a ULV CPU,
the trigger we previously suspected.
PhoenixBIOS (and its rebrands) appears to be the common trigger.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Larry Finger skrev 14.2.2010 18:36:
> On 02/14/2010 03:53 AM, Thomas Backlund wrote:
>> Hi,
>> (please cc me on replies)
>>
>> We have a user that tried out b43, but got this in the logs:
>>
>> --- cut ---
>> 65858:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
>> support DMA on your system. Please use PIO instead. 65859:Feb 9
>> 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO must
>> be set in your kernel configuration.
>> 65860:Feb 9 22:05:16 elmo kernel: b43-phy2 debug: Adding Interface type 2
>> 65861:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: Fatal DMA error:
>> 0x00000400, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
>>
>> 65862:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
>> support DMA on your system. Please use PIO instead.
>> 65863:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO
>> must be set in your kernel configuration.
>> --- cut ---
>>
>>
>>
>> But reading the Kconfig help, it states:
>> --- cut ---
>> config B43_FORCE_PIO
>> bool "Force usage of PIO instead of DMA"
>> depends on B43&& B43_DEBUG
>> ---help---
>> This will disable DMA and always enable PIO instead.
>>
>> Say N!
>> This is only for debugging the PIO engine code. You do
>> _NOT_ want to enable this.
>> --- cut ---
>>
>>
>> So,
>> wich one is it ?
>>
>> Do I belive the dmesg output, or the Kconfig ?
>>
>> Note,
>> the b43 works for the user if he enable the CONFIG_B43_FORCE_PIO.
>>
>> But I'm thinking of this problem from a distro point of view.
>> Will it break for others if I enable it ?
>
>> From a distro point of view, you would not want to set FORCE_PIO as the
> performance penalty would be very large.
>
As I suspected.
Thanks for confirming it.
> You do not give the specific details on the problem system; however, it is
> probably a BCM4312 802.11 b/g device with PCI ID 14e4:4315 being used with an
> Atom processor in a netbook. We have no fix.
>
Sorry about the missing info...
I asked a few times from the user, and got no reponse until today a few
hours after your response...
It is indeed a BCM4312 802.11 b/g device with PCI ID 14e4:4315 on a Dell
laptop with a Intel ICH9M series chipset and a Intel Core(TM)2 Duo CPU
T7250 @ 2.00GHz.
> In the 2.6.34 code, b43 will be changed to allow the selection of PIO mode at
> run time rather than compile time. For a distro, this method is clearly
> superior. Those users that need PIO can select it without forcing the
> performance penalty on everyone. The patch was too late for the 2.6.33 merge,
> and too intrusive to be applied to 2.6.33-rcX. It has been present in the
> wireless-testing code base for 2 months with no trouble reported, thus it should
> be safe for inclusion in your kernels. The relevant patch is attached.
>
Nice solution.
What about making it autodetected ?
Or is it only a "last resort" with the hopes of getting the issue fixed?
Anyway, thanks for the patch.
--
Thomas
On 02/14/2010 03:53 PM, G?bor Stefanik wrote:
>
> Looks like the trigger is not Intel Atom, but PhoenixBIOS after all -
> a quick analysis of bios v. A15 for this machine shows it to be a
> highly cloaked/rebranded PhoenixBIOS.
>
> Core 2 T7250 is a regular Merom/Santa Rosa CPU, almost the same as my
> T7100 (only the clock multiplier is different), and is not a ULV CPU,
> the trigger we previously suspected.
>
> PhoenixBIOS (and its rebrands) appears to be the common trigger.
It also requires an Intel CPU. My AMD is fine with a Phoenix BIOS.
Larry
On Sun, Feb 14, 2010 at 7:44 PM, Thomas Backlund <[email protected]> wrote:
> Larry Finger skrev 14.2.2010 18:36:
>>
>> On 02/14/2010 03:53 AM, Thomas Backlund wrote:
>>>
>>> Hi,
>>> (please cc me on replies)
>>>
>>> We have a user that tried out b43, but got this in the logs:
>>>
>>> --- cut ---
>>> 65858:Feb ?9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
>>> support DMA on your system. Please use PIO instead. 65859:Feb ?9
>>> 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO must
>>> be set in your kernel configuration.
>>> 65860:Feb ?9 22:05:16 elmo kernel: b43-phy2 debug: Adding Interface type
>>> 2
>>> 65861:Feb ?9 22:05:16 elmo kernel: b43-phy2 ERROR: Fatal DMA error:
>>> 0x00000400, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
>>>
>>> 65862:Feb ?9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
>>> support DMA on your system. Please use PIO instead.
>>> 65863:Feb ?9 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO
>>> must be set in your kernel configuration.
>>> --- cut ---
>>>
>>>
>>>
>>> But reading the Kconfig help, it states:
>>> --- cut ---
>>> config B43_FORCE_PIO
>>> ? ? ? ? bool "Force usage of PIO instead of DMA"
>>> ? ? ? ? depends on B43&& ?B43_DEBUG
>>> ? ? ? ? ---help---
>>> ? ? ? ? ? This will disable DMA and always enable PIO instead.
>>>
>>> ? ? ? ? ? Say N!
>>> ? ? ? ? ? This is only for debugging the PIO engine code. You do
>>> ? ? ? ? ? _NOT_ want to enable this.
>>> --- cut ---
>>>
>>>
>>> So,
>>> wich one is it ?
>>>
>>> Do I belive the dmesg output, or the Kconfig ?
>>>
>>> Note,
>>> the b43 works for the user if he enable the CONFIG_B43_FORCE_PIO.
>>>
>>> But I'm thinking of this problem from a distro point of view.
>>> Will it break for others if I enable it ?
>>
>>> From a distro point of view, you would not want to set FORCE_PIO as the
>>
>> performance penalty would be very large.
>>
>
> As I suspected.
> Thanks for confirming it.
>
>> You do not give the specific details on the problem system; however, it is
>> probably a BCM4312 802.11 b/g device with PCI ID 14e4:4315 being used with
>> an
>> Atom processor in a netbook. We have no fix.
>>
>
> Sorry about the missing info...
> I asked a few times from the user, and got no reponse until today a few
> hours after your response...
>
> It is indeed a BCM4312 802.11 b/g device with PCI ID 14e4:4315 on a Dell
> laptop with a Intel ICH9M series chipset and a Intel Core(TM)2 Duo CPU T7250
> @ 2.00GHz.
Weird... that's not an Intel Atom, but a Core 2 Duo, standard-voltage.
Mind posting any more details on this system?
>
>> In the 2.6.34 code, b43 will be changed to allow the selection of PIO mode
>> at
>> run time rather than compile time. For a distro, this method is clearly
>> superior. Those users that need PIO can select it without forcing the
>> performance penalty on everyone. The patch was too late for the 2.6.33
>> merge,
>> and too intrusive to be applied to 2.6.33-rcX. It has been present in the
>> wireless-testing code base for 2 months with no trouble reported, thus it
>> should
>> be safe for inclusion in your kernels. The relevant patch is attached.
>>
>
> Nice solution.
>
> What about making it autodetected ?
> Or is it only a "last resort" with the hopes of getting the issue fixed?
>
> Anyway, thanks for the patch.
>
> --
> Thomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On 02/14/2010 12:44 PM, Thomas Backlund wrote:
>
> Nice solution.
>
> What about making it autodetected ?
> Or is it only a "last resort" with the hopes of getting the issue fixed?
When we detect the problem, we are too far past the initialization to switch
from DMA to PIO.
We certainly hope to fix the issue. We do know that the failure occurs when b43
is loaded after a cold boot, but if one warm boots after using wl, then it works
OK. There is some kind of initialization problem that only shows on Atom and
some Intel Core Duo CPUs.
Larry
G?bor Stefanik skrev 14.2.2010 20:59:
> On Sun, Feb 14, 2010 at 7:44 PM, Thomas Backlund<[email protected]> wrote:
>> Larry Finger skrev 14.2.2010 18:36:
>>>
>>> On 02/14/2010 03:53 AM, Thomas Backlund wrote:
>>>>
>>>> Hi,
>>>> (please cc me on replies)
>>>>
>>>> We have a user that tried out b43, but got this in the logs:
>>>>
>>>> --- cut ---
>>>> 65858:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
>>>> support DMA on your system. Please use PIO instead. 65859:Feb 9
>>>> 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO must
>>>> be set in your kernel configuration.
>>>> 65860:Feb 9 22:05:16 elmo kernel: b43-phy2 debug: Adding Interface type
>>>> 2
>>>> 65861:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: Fatal DMA error:
>>>> 0x00000400, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
>>>>
>>>> 65862:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
>>>> support DMA on your system. Please use PIO instead.
>>>> 65863:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO
>>>> must be set in your kernel configuration.
>>>> --- cut ---
>>>>
>>>>
>>>>
>>>> But reading the Kconfig help, it states:
>>>> --- cut ---
>>>> config B43_FORCE_PIO
>>>> bool "Force usage of PIO instead of DMA"
>>>> depends on B43&& B43_DEBUG
>>>> ---help---
>>>> This will disable DMA and always enable PIO instead.
>>>>
>>>> Say N!
>>>> This is only for debugging the PIO engine code. You do
>>>> _NOT_ want to enable this.
>>>> --- cut ---
>>>>
>>>>
>>>> So,
>>>> wich one is it ?
>>>>
>>>> Do I belive the dmesg output, or the Kconfig ?
>>>>
>>>> Note,
>>>> the b43 works for the user if he enable the CONFIG_B43_FORCE_PIO.
>>>>
>>>> But I'm thinking of this problem from a distro point of view.
>>>> Will it break for others if I enable it ?
>>>
>>>> From a distro point of view, you would not want to set FORCE_PIO as the
>>>
>>> performance penalty would be very large.
>>>
>>
>> As I suspected.
>> Thanks for confirming it.
>>
>>> You do not give the specific details on the problem system; however, it is
>>> probably a BCM4312 802.11 b/g device with PCI ID 14e4:4315 being used with
>>> an
>>> Atom processor in a netbook. We have no fix.
>>>
>>
>> Sorry about the missing info...
>> I asked a few times from the user, and got no reponse until today a few
>> hours after your response...
>>
>> It is indeed a BCM4312 802.11 b/g device with PCI ID 14e4:4315 on a Dell
>> laptop with a Intel ICH9M series chipset and a Intel Core(TM)2 Duo CPU T7250
>> @ 2.00GHz.
>
> Weird... that's not an Intel Atom, but a Core 2 Duo, standard-voltage.
> Mind posting any more details on this system?
>
It's a Dell Latitude E5500, Bios A13.
It's a 64bit kernel/userspace.
The b43 firmware is: 478.104
lspci -vvvnnn states:
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4312
802.11b/g [14e4:4315] (rev 01)
Subsystem: Dell Wireless 1397 WLAN Mini-Card [1028:000c]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f69fc000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: b43-pci-bridge
Kernel modules: wl, ssb
Anything else you need ?
--
Thomas
On 02/14/2010 03:53 AM, Thomas Backlund wrote:
> Hi,
> (please cc me on replies)
>
> We have a user that tried out b43, but got this in the logs:
>
> --- cut ---
> 65858:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
> support DMA on your system. Please use PIO instead. 65859:Feb 9
> 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO must
> be set in your kernel configuration.
> 65860:Feb 9 22:05:16 elmo kernel: b43-phy2 debug: Adding Interface type 2
> 65861:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: Fatal DMA error:
> 0x00000400, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
>
> 65862:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: This device does not
> support DMA on your system. Please use PIO instead.
> 65863:Feb 9 22:05:16 elmo kernel: b43-phy2 ERROR: CONFIG_B43_FORCE_PIO
> must be set in your kernel configuration.
> --- cut ---
>
>
>
> But reading the Kconfig help, it states:
> --- cut ---
> config B43_FORCE_PIO
> bool "Force usage of PIO instead of DMA"
> depends on B43 && B43_DEBUG
> ---help---
> This will disable DMA and always enable PIO instead.
>
> Say N!
> This is only for debugging the PIO engine code. You do
> _NOT_ want to enable this.
> --- cut ---
>
>
> So,
> wich one is it ?
>
> Do I belive the dmesg output, or the Kconfig ?
>
> Note,
> the b43 works for the user if he enable the CONFIG_B43_FORCE_PIO.
>
> But I'm thinking of this problem from a distro point of view.
> Will it break for others if I enable it ?
>From a distro point of view, you would not want to set FORCE_PIO as the
performance penalty would be very large.
You do not give the specific details on the problem system; however, it is
probably a BCM4312 802.11 b/g device with PCI ID 14e4:4315 being used with an
Atom processor in a netbook. We have no fix.
In the 2.6.34 code, b43 will be changed to allow the selection of PIO mode at
run time rather than compile time. For a distro, this method is clearly
superior. Those users that need PIO can select it without forcing the
performance penalty on everyone. The patch was too late for the 2.6.33 merge,
and too intrusive to be applied to 2.6.33-rcX. It has been present in the
wireless-testing code base for 2 months with no trouble reported, thus it should
be safe for inclusion in your kernels. The relevant patch is attached.
Larry