Bug 10399
Summary: | b43: PHY transmission error | ||
---|---|---|---|
Product: | Networking | Reporter: | Patrick Matthäi (patrick) |
Component: | Wireless | Assignee: | networking_wireless (networking_wireless) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | linville, nick.steeves, oakad, wolfmoon |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.25.1 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Patrick Matthäi
2008-04-05 10:39:31 UTC
Anyway since an earlier commit which should reduce this problem/messages they realy doesn't appear so often again. Exactly the same message with 2.6.26 on my hp nx7400 laptop. Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) 14e4:4311 Firmware version 410.2160 (2007-05-26 15:32:10) Distribution: Debian unstable Arch: i386 As I understand it, this message may occur once in a while. It is only a problem if it occurs continuously. Its occurs continuously in my case. Often, it's like: Aug 14 07:40:40 opos kernel: [ 494.188871] b43-phy0 ERROR: PHY transmission error Aug 14 07:40:40 opos kernel: [ 494.196805] b43-phy0 ERROR: PHY transmission error Aug 14 07:40:40 opos kernel: [ 494.199315] b43-phy0 ERROR: PHY transmission error Aug 14 07:40:48 opos kernel: [ 502.500434] __ratelimit: 10 messages suppressed Aug 14 07:40:48 opos kernel: [ 502.500448] b43-phy0 ERROR: PHY transmission error Aug 14 07:40:55 opos kernel: [ 509.298786] __ratelimit: 13 messages suppressed It makes connection practically unusable, so think bug should be reopened. Should I send more information about my system than in my last comment? Michael Buesch is aware of the problem and is working to fix it. Still there on 2.6.29: b43-phy0 ERROR: PHY transmission error ------------[ cut here ]------------ WARNING: at net/mac80211/rx.c:2234 ieee80211_tasklet_handler+0x65/0xf3 [mac80211]() Hardware name: Ferrari 4000 Modules linked in: btusb bfusb hci_vhci bluetooth ehci_hcd aes_x86_64 aes_generic rfkill_input snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device fuse snd_atiixp snd_atiixp_modem arc4 snd_ac97_codec ecb ac97_bus snd_pcm b43 snd_timer mac80211 ohci1394 yenta_socket cfg80211 ppdev snd rsrc_nonstatic nsc_ircc ieee1394 soundcore pcmcia_core k8temp ohci_hcd tifm_7xx1 snd_page_alloc hwmon pcspkr serio_raw tifm_core input_polldev i2c_piix4 usbcore parport_pc irda fglrx(P) serial_core parport crc_ccitt tg3 libphy rfkill joydev led_class [last unloaded: uhci_hcd] Pid: 14721, comm: firefox Tainted: P W 2.6.29 #1 Call Trace: <IRQ> [<ffffffff8023c53a>] warn_slowpath+0xd8/0xf5 [<ffffffffa038018e>] ieee80211_rx_irqsafe+0x42/0x64 [mac80211] [<ffffffffa03ae6d4>] b43_rx+0x415/0x431 [b43] [<ffffffffa03b294e>] op32_fill_descriptor+0x37/0xae [b43] [<ffffffff802300fa>] ia32_setup_frame+0xea/0x17c [<ffffffffa03b3071>] b43_dma_rx+0x3a3/0x3b9 [b43] [<ffffffffa0372b1f>] ieee80211_tasklet_handler+0x65/0xf3 [mac80211] [<ffffffff8024158d>] tasklet_action+0x65/0xaf [<ffffffff802412bc>] __do_softirq+0x7f/0x138 [<ffffffff8020d03c>] call_softirq+0x1c/0x28 [<ffffffff8020e699>] do_softirq+0x2c/0x6c [<ffffffff80241200>] irq_exit+0x3f/0x7c [<ffffffff8020e804>] do_IRQ+0x12b/0x14f [<ffffffff8020c913>] ret_from_intr+0x0/0xa <EOI> <4>---[ end trace f7ce3d44350dc6fd ]--- b43-phy0 ERROR: PHY transmission error b43-phy0 ERROR: PHY transmission error b43-phy0 ERROR: PHY transmission error b43-phy0 ERROR: PHY transmission error b43-phy0 ERROR: PHY transmission error I'd like to confirm that 2.6.30-rc1 fixes this bug, while introducing what looks like a radio initialisation timeout bug. By 2.6.30.4 these are -- without a doubt -- resolved, and I'm guessing that b43 worked great in 2.6.30. Ubuntu uses a 2.6.28-series kernel in their latest stable release. Here are links to the two associated bug reports in their system: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/405712 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263106 Could you please work with or advise the Ubuntu kernel team to backport the 2.6.30-series b43 driver to their 2.6.28-series one, if a backport is possible without undue disruption to the other wireless drivers? Thanks! P.S. I tested 2.6.28 through 2.6.30.4 using a strategy similar to git bisect. I also could confirm, that this bug could be closed. |