System freezes with 2.6.33

System freezes with 2.6.33

[yhager at yhager.com]

Hi,

After upgrading my system to 2.6.33
(http://www.archlinux.org/packages/core/i686/kernel26/) I am
experiencing complete system lockups.

I confirmed that this happens when the b43 drives is on ahd I try to
connect to the network. When I remove the module, the system works fine
for hours. When it is on, I have a few minutes, till a complete freeze.

There is nothing in the kernel logs, or dmesg, or anywhere I could
find. I tried reinstalling the firmware, but it didn't change anything.

The hardware is HP-2133 (mini note).

[yuval at happy ~]$ uname -a
Linux happy 2.6.33-ARCH #1 SMP PREEMPT Mon Apr 5 05:57:38 UTC 2010 i686 VIA C7-M Processor 1600MHz CentaurHauls GNU/Linux
[yuval at happy ~]$ lspci -vvn|grep 43 -A7
00:00.4 0600: 1106:4364
  Subsystem: 103c:3030
  Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
  Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
  Latency: 0

00:00.5 0800: 1106:5364 (prog-if 20 [IO(X)-APIC])
  Subsystem: 103c:3030
--
02:00.0 0280: 14e4:4312 (rev 02)
  Subsystem: 103c:1371
  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: 32 bytes
  Interrupt: pin A routed to IRQ 24
  Region 0: Memory@fdffc000 (64-bit, non-prefetchable) [size=16K]
  Capabilities: <access denied>
  Kernel driver in use: b43-pci-bridge

07:03.0 0200: 14e4:169c (rev 03)
  Subsystem: 103c:3030
  Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
  Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
  Latency: 64 (16000ns min), Cache Line Size: 32 bytes
  Interrupt: pin A routed to IRQ 16

System freezes with 2.6.33

[Larry Finger]

On 04/18/2010 02:19 AM, yhager at yhager.com wrote:
> Hi,
> 
> After upgrading my system to 2.6.33
> (http://www.archlinux.org/packages/core/i686/kernel26/) I am
> experiencing complete system lockups.
> 
> I confirmed that this happens when the b43 drives is on ahd I try to
> connect to the network. When I remove the module, the system works fine
> for hours. When it is on, I have a few minutes, till a complete freeze.
> 
> There is nothing in the kernel logs, or dmesg, or anywhere I could
> find. I tried reinstalling the firmware, but it didn't change anything.
> 
> The hardware is HP-2133 (mini note).

Yours is the first report of such freezes. As there is a possibility of
info being logged, but not being written and saved on disk, I would like
you to switch to the logging console (Ctrl+Alt+F10) immediately after
bringing the system up and starting the connection. Does anything show
there? I do not have access to a card like yours, but I have tested with
a 14e4:4311, which is similar.

Larry

System freezes with 2.6.33

[yhager at yhager.com]

On 11:16 Sun 18 Apr     , Larry Finger wrote:
> On 04/18/2010 02:19 AM, yhager at yhager.com wrote:
> > Hi,
> > 
> > After upgrading my system to 2.6.33
> > (http://www.archlinux.org/packages/core/i686/kernel26/) I am
> > experiencing complete system lockups.
> > 
> > I confirmed that this happens when the b43 drives is on ahd I try to
> > connect to the network. When I remove the module, the system works fine
> > for hours. When it is on, I have a few minutes, till a complete freeze.
> > 
> > There is nothing in the kernel logs, or dmesg, or anywhere I could
> > find. I tried reinstalling the firmware, but it didn't change anything.
> > 
> > The hardware is HP-2133 (mini note).
> 
> Yours is the first report of such freezes. As there is a possibility of
> info being logged, but not being written and saved on disk, I would like
> you to switch to the logging console (Ctrl+Alt+F10) immediately after
> bringing the system up and starting the connection. Does anything show
> there? I do not have access to a card like yours, but I have tested with
> a 14e4:4311, which is similar.
> 
> Larry

(sorry, my responses are a bit delayed, I am on the road, so not a lot
of time for testing)

I just see these lines, which I figured are normal:

Apr 20 07:23:08 happy kernel: b43 ssb0:0: firmware: requesting b43/ucode13.fw
Apr 20 07:23:08 happy kernel: b43 ssb0:0: firmware: requesting b43/b0g0initvals13.fw
Apr 20 07:23:09 happy kernel: b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
Apr 20 07:23:09 happy kernel: b43-pci-bridge 0000:02:00.0: PCI: Disallowing DAC for device
Apr 20 07:23:09 happy kernel: b43-phy0: DMA mask fallback from 64-bit to 32-bit
Apr 20 07:23:09 happy kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready

And then it freezes.

I have also tried disabling the radio using the switch, and then there
is no freeze. When I enable the radio back, it freezes again.

--y

System freezes with 2.6.33

[Peter Stuge]

yhager at yhager.com wrote:
> I have also tried disabling the radio using the switch, and then
> there is no freeze. When I enable the radio back, it freezes again.

Could b43 experts please outline what happens w.r.t. the PCIe bus
when radio is disabled using the switch as described above?


//Peter

System freezes with 2.6.33

[Daniel Kuehn]

On Tue, 20 Apr 2010 17:51:40 +0200
Peter Stuge <peter@stuge.se> wrote:

> yhager at yhager.com wrote:
> > I have also tried disabling the radio using the switch, and then
> > there is no freeze. When I enable the radio back, it freezes again.
> 
> Could b43 experts please outline what happens w.r.t. the PCIe bus
> when radio is disabled using the switch as described above?
> 
> 
> //Peter
> 
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev

Doesnt the switch "just" turn it off hardware wise? As in that the OS doesnt
even know it exists then because more or less the power is cut to it.

-- 
Mvh
Daniel

System freezes with 2.6.33

[Peter Stuge]

Daniel Kuehn wrote:
> > > I have also tried disabling the radio using the switch, and then
> > > there is no freeze. When I enable the radio back, it freezes again.
> > 
> > Could b43 experts please outline what happens w.r.t. the PCIe bus
> > when radio is disabled using the switch as described above?
> 
> Doesnt the switch "just" turn it off hardware wise?

I doubt that. PCIe can do hotplug but it's only used in high-end
systems, not a mini-note.


> As in that the OS doesnt even know it exists then because more or
> less the power is cut to it.

Usually the switch generates an electrical signal which goes through
the system board over to the wifi card, and there it will have
control over the RF part, and yes disable radio communication, but
no, not the entire wifi card. As I have understood the b43 hardware
can also read this electrical signal and report it's status to the
driver, but it is impossible to override the hardwired "kill" switch
from the driver.

This is why I ask for advice from the b43 experts, since maybe my
description above is too simplistic, and the kill signal will
actually cause more things to happen on the wifi card.

Anything related to the host bus is of particular interest.

What happens in the firmware w.r.t. the kill switch?

What does openfwwf do?


//Peter

System freezes with 2.6.33

[Larry Finger]

On 04/20/2010 11:27 AM, Peter Stuge wrote:
> Daniel Kuehn wrote:
>>>> I have also tried disabling the radio using the switch, and then
>>>> there is no freeze. When I enable the radio back, it freezes again.
>>>
>>> Could b43 experts please outline what happens w.r.t. the PCIe bus
>>> when radio is disabled using the switch as described above?
>>
>> Doesnt the switch "just" turn it off hardware wise?

No, the hardware is still powered. I think the signal from the switch
disables the radio, but I'm not sure of that.

> I doubt that. PCIe can do hotplug but it's only used in high-end
> systems, not a mini-note.
> 
> 
>> As in that the OS doesnt even know it exists then because more or
>> less the power is cut to it.
> 
> Usually the switch generates an electrical signal which goes through
> the system board over to the wifi card, and there it will have
> control over the RF part, and yes disable radio communication, but
> no, not the entire wifi card. As I have understood the b43 hardware
> can also read this electrical signal and report it's status to the
> driver, but it is impossible to override the hardwired "kill" switch
> from the driver.
> 
> This is why I ask for advice from the b43 experts, since maybe my
> description above is too simplistic, and the kill signal will
> actually cause more things to happen on the wifi card.
> 
> Anything related to the host bus is of particular interest.

See below.

> What happens in the firmware w.r.t. the kill switch?

I do not think the firmware knows anything about it other than possible
interaction with the driver through the contents of shared memory.

> What does openfwwf do?

Do you mean with respect to the freeze? The openfwwf is only for
Revision 5 802.11 cores - this one is Rev 13.

There are a number of code paths that are not used when the radio switch
is off. For instance, the device will not do DMA, which might be a clue.

Yuval: If you are willing to generate your own kernel, please set
'CONFIG_B43_FORCE_PIO=y' in your configuration. That will skip DMA
completely.

Larry

System freezes with 2.6.33

[yhager at yhager.com]

On 12:07 Tue 20 Apr     , Larry Finger wrote:
> Yuval: If you are willing to generate your own kernel, please set
> 'CONFIG_B43_FORCE_PIO=y' in your configuration. That will skip DMA
> completely.
> 
> Larry
> 

I have tested the same kernel, with CONFIG_B43_FORCE_PIO=y. The
results are mostly the same. Full system freeze. Turning the radio off
avoids the freeze. Turning the radio on would not immediately freeze -
only when I tried to connect to a wireless network it did. 
I also enabled CONFIG_B43_DEBUG, but no messages on the console that
would testify a problem.

--yuval

System freezes with 2.6.33

[Larry Finger]

On 04/22/2010 11:12 AM, yhager at yhager.com wrote:
> I have tested the same kernel, with CONFIG_B43_FORCE_PIO=y. The
> results are mostly the same. Full system freeze. Turning the radio off
> avoids the freeze. Turning the radio on would not immediately freeze -
> only when I tried to connect to a wireless network it did. 
> I also enabled CONFIG_B43_DEBUG, but no messages on the console that
> would testify a problem.

Is it possible for you to test with another mac80211-based wireless
device? I cannot think of any possibility for the system to lock up when
b43 is using PIO.

When the freeze occurs, how long do you leave it? There are some CPU
lockups that take as many as 2 minutes to be recognized by the kernel.

In Archlinux, how difficult is it to incorporate source from an external
tree and build the kernel?

Larry

System freezes with 2.6.33

[yhager at yhager.com]

On 12:21 Thu 22 Apr     , Larry Finger wrote:
> On 04/22/2010 11:12 AM, yhager at yhager.com wrote:
> > I have tested the same kernel, with CONFIG_B43_FORCE_PIO=y. The
> > results are mostly the same. Full system freeze. Turning the radio off
> > avoids the freeze. Turning the radio on would not immediately freeze -
> > only when I tried to connect to a wireless network it did. 
> > I also enabled CONFIG_B43_DEBUG, but no messages on the console that
> > would testify a problem.
> 
> Is it possible for you to test with another mac80211-based wireless
> device? I cannot think of any possibility for the system to lock up when
> b43 is using PIO.

No, sorry, I don't have another device.

> 
> When the freeze occurs, how long do you leave it? There are some CPU
> lockups that take as many as 2 minutes to be recognized by the kernel.
> 

I haven't waited that long. I will test again when I have the chance.

> In Archlinux, how difficult is it to incorporate source from an external
> tree and build the kernel?
> 

Not difficult at all.

--y

System freezes with 2.6.33

[Yuval Hager]

On Thursday 22 April 2010 20:21:17 Larry Finger wrote:
> On 04/22/2010 11:12 AM, yhager at yhager.com wrote:
> > I have tested the same kernel, with CONFIG_B43_FORCE_PIO=y. The
> > results are mostly the same. Full system freeze. Turning the radio off
> > avoids the freeze. Turning the radio on would not immediately freeze -
> > only when I tried to connect to a wireless network it did.
> > I also enabled CONFIG_B43_DEBUG, but no messages on the console that
> > would testify a problem.
> 
> Is it possible for you to test with another mac80211-based wireless
> device? I cannot think of any possibility for the system to lock up when
> b43 is using PIO.
> 
> When the freeze occurs, how long do you leave it? There are some CPU
> lockups that take as many as 2 minutes to be recognized by the kernel.
> 
> In Archlinux, how difficult is it to incorporate source from an external
> tree and build the kernel?
> 
> Larry

I cannot recreate it with latest 2.6.33.3-1.

--yuval

System freezes with 2.6.33

[Peter Stuge]

yhager at yhager.com wrote:
> After upgrading my system to 2.6.33
> (http://www.archlinux.org/packages/core/i686/kernel26/) I am
> experiencing complete system lockups.
..
> The hardware is HP-2133 (mini note).

I can't help but think that this may also be related to how PCIe pins
are multiplexed on this chipset.

Does that kernel happen to have a kernel graphics driver enabled?
Try disabling it in that case, and see what happens.

Difficult issue this. I think you will need to bisect to find a
commit. I hope that commit will be directly related to the problem.


//Peter