Bug #331952 “[P4M900] [HP 2133 MiniNote laptop] Unexpected and u...” : Bugs : xserver-xorg-video-openchrome package : Ubuntu

Revision history for this message

Charlie Kravetz (cjkgeek) wrote on 2009-02-21: Re: [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver

#1

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.

Please include the following additional information, if you have not already done so (pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please run the command "dmesg > dmesg.log" after a fresh boot and attach the resulting file "dmesg.log" to this bug report.

This file should be attached to the bug report (not pasted into comments, as it makes things harder to read, and formatting is completely broken).

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-02-22:

#2

Outpuy of lspci -vv Edit (18.2 KiB, text/plain)

As requested...

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-02-22:

#3

dmesg output from boot to wireless disconnect Edit (39.6 KiB, text/plain)

and...

Revision history for this message

Charlie Kravetz (cjkgeek) wrote on 2009-02-22:

#4

Thanks for the added logs. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-03-05:

#5

This problem still exists in Alpha 5 or, at least, the latest packages as of 3/4/09 around noon GMT.

Can we get someone assigned to this bug? Its not going to make much progress while assigned to 'nobody'.

Thanks,
Ben McCann

Charlie Kravetz (cjkgeek) on 2009-03-05

description:

updated

Steve Beattie (sbeattie) on 2009-03-06

Changed in linux:
assignee:	nobody → canonical-kernel-team

Revision history for this message

nonre (antareus-deactivatedaccount) wrote on 2009-03-08:

#6

Hi,
I am using Debian Squeeze with hybrid-postsrc-x86_32-v5_10_79_10.tar.gz driver, but I tried b43 as well. In both Debian and Kubuntu Intrepid, the behaviour is always the same as described above - it works and then, after few minutes, it disconnects forever. I think it is a hardware problem - try to switch off the power management.

iwconfig wlan0 essid ".." power off

It works for me so far.

Bests
Antareus

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-03-09:

#7

I tried the work-around suggested by Antareus and it did not help. The wireless still lost connectivity. It did seem like it took longer to disconnect with power management disabled but that's only one data point.

I'm actually encouraged by this result because my HP-2133's BCM4312 wireless runs flawlessly under Ubuntu Intrepid. That makes me think Antareus has some other issue with his wireless on Intrepid that is distinct from the one reported in this bug. This bug documents a regression that occurs due to the upgrade from Intrepid to Jaunty.

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-03-13:

#8

Problem still exists in Jaunty Alpha 6. (Note, I upgraded packages; I did not do a fresh install).

Revision history for this message

nonre (antareus-deactivatedaccount) wrote on 2009-03-15:

#9

My point was that I have tried both Intrepid and Jaunty Alpha 6 - and finally Debian squeeze (I like KDE3.5). The problem was all the time the same, I even replaced the wireless (in fact, the whole motherboard) due to complete break down and with completely new hardware, it behaves the same. I think that the power management issue may not be only in the wireless driver but may be somewhere else too.
However, using "power off" command 100% works - even when continuously connected for more than 20 hours. Hope this will help you somehow.

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-03-16:

#10

I retried the 'power off' work-around and it still failed to prevent my laptop's wireless from dropping after 5 or 10 minutes. I also figured out why the work-around was ineffective. The wireless power management was already OFF *before* I did the 'iwconfig .... power off' command. (I ran 'iwconfig' to get the essid and noticed power management was OFF). I ran the 'iwconfig .... power off' command anyway and, as you'd expect, it was ineffective because power management is off by default on my laptop.

FWIW, I tried enabling power management (iwconfig ... power on) and that did not help either.

Revision history for this message

Andrew Aylett (andrew-aylett) wrote on 2009-03-21:

#11

I'm also encountering this issue, with an upgrade to Jaunty that I ran yesterday. On my machine, the wireless seems to die if I shut the lid.

When I open the lid again, I get these messages in /var/log/messages:
Mar 21 15:57:58 artemis kernel: [ 2366.000081] b43-phy0: Radio hardware status changed to DISABLED
Mar 21 15:58:03 artemis kernel: [ 2370.940071] b43-phy0: Radio turned on by software
Mar 21 15:58:03 artemis kernel: [ 2370.940086] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on.

This seems to be the same issue, but manifesting slightly differently. I've got the UK variant of the HP2133.

Everything worked fine in Intrepid.

Revision history for this message

Andrew Aylett (andrew-aylett) wrote on 2009-03-24:

#12

I'm no longer quite so sure it's a kernel issue -- I tried experimenting with different kernels to see if I could work out where the breakage occurred, but couldn't find a kernel that would make it work.

First, I tried building a vanilla 2.6.28.8 with a config file from the ubuntu package. The issue was still there, meaning that it's not a problem with the ubuntu patches. Next, I was about to try building a 2.6.27 kernel when I realised I could just install the Intrepid deb, then further realised that the kernel was actually still on my system... Booting with that kernel and the Intrepid userspace worked, but with the Jaunty userspace it fails. While I don't know enough to say that there's definitely no kernel issue, it does look like it's a userspace change which has triggered the issue.

Any hints as to what I should try next?

Revision history for this message

Andrew Aylett (andrew-aylett) wrote on 2009-03-24:

#13

I (think I) have a workaround -- the problem seemed to hit me when unblanking the screen, so I disabled screen blanking and now I can at least shut the laptop lid without losing wireless. It's not ideal, but it helps... Ben, looking again at your report, I'm not sure this will help you -- it seems that we have the same output in the logs, and the same result, but that the trigger for the wireless going down is different?

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-03-24:

#14

Mine goes down w/o blanking the screen. It happens when the laptop is idle (but not blanking) and I had it happen while downloading data from the Web. I'm up for running experiments but I'm at a loss as to what I should be trying.

What would it take to install the Intrepid NetworkManager on Jaunty? Maybe we revert that and see what happens?

Revision history for this message

Andrew Aylett (andrew-aylett) wrote on 2009-03-26:

#15

I've found another way I can trigger the issue -- if I play a video through xine using the xvideo extension:

axa@artemis:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
10:59:51.351: computer_logicaldev_input_5 condition ButtonPressed = wlan
10:59:51.557: ssb__null__rfkill_b43_phy0_wlan property killswitch.state = 0 (0x0)

The physical button also controls Bluethooth, but Bluetooth is still working (and the button still switches it on and off).

Revision history for this message

Superball (shufflevideo) wrote on 2009-03-28:

#16

I run a HP 2133 MiniNote, Ubuntu 8.10, and I am experiencing the same problem as you. ACPI? Something must be shutting it down.. I'll attach dmesg/lspci in the next post.

Revision history for this message

Superball (shufflevideo) wrote on 2009-03-28:

#17

dmesg.log - ubuntu 8.10 on HP 2133 MiniNote Edit (34.0 KiB, text/plain)

Revision history for this message

Superball (shufflevideo) wrote on 2009-03-28:

#18

lshw - ubuntu 8.10 on HP 2133 MiniNote Edit (13.5 KiB, text/plain)

Revision history for this message

Superball (shufflevideo) wrote on 2009-03-28:

#19

lsmod - ubuntu 8.10 on HP 2133 MiniNote (if it will do you any good!) Edit (4.0 KiB, text/plain)

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-03-28:

#20

Upgraded all Jaunty packages to latest (Beta) version. Problem still occurs.

It does seem like something like ACPI or some other power management subsystem is shutting down the radio unexpectedly (and differently from Intrepid). This is reported in dmesg at the time of the failure:

[ 1016.000206] b43-phy0: Radio hardware status changed to DISABLED
[ 1020.049187] wlan0: No ProbeResp from current AP 00:1f:90:e0:19:75 - assume out of range
[ 1020.196141] b43-phy0: Radio turned on by software
[ 1020.196154] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on.
[ 1021.697906] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 1
[ 1021.698028] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 1
[ 1021.898144] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 2
[ 1022.096054] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 3
[ 1022.296627] wlan0: direct probe to AP 00:1f:90:e0:19:75 timed out

Canonical Kernel Team: I'm sure you're busy trying to close out the release, and this bug appears to only affect one platform (so far), but can you please make some suggestions about experiments we could try to help narrow down the root cause of this problem?

Thanks.

Revision history for this message

nonre (antareus-deactivatedaccount) wrote on 2009-03-29:

#21

Hi,
I was mistaken, turning off the power management did not solve the bug - it still freezes. However, I found that turning off the "acpi wakeup capable device" solves the problem. In Kubuntu Intrepid, Jaunty, and even in Debian (running now), the wireless behaves the same - it works, than it randomly fades out and it is impossible to wake it.

So, as a solution, try disabling acpi wakeup capable devices. Install acpitool, run "acpitool -w" to display all devices wakeup capable and then run "acpitool -W" + number of device (shown before) to disable wakin'up.

I don't use my hp mini often, so let me know if this works for you or not. Also, try it with power managment turned off as well (my earlier post).

Bests from Prague.
Antareus

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-03-29:

#22

Still locks up with the acpitool disabling wakeup. I tried without explicitly disabling iwconfig power management and with explicitly setting power management off with iwconfig. (Note that on my config power management in iwconfig is off by default so the latter experiment was really pretty futile).

FWIW, the "acpitool -w" command under Intrepid and Jaunty shows exactly the same thing, two devices, BLAN and SLPB, whose 'status' is disabled and '*enabled', respectively. I 'disabled' wakeup on SLPB under Jaunty and it still locked up after 5 minutes. Since this works fine in Intrepid but fails in Jaunty (at least on my model of the HP 2133), the ACPI wakeup doesn't appear to be related to the failure.

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-03-31:

#23

Following up on Andrew Aylett's posting, I too see the HAL layer incorrectly deciding the radio has been turned off:

Start monitoring devicelist:
-------------------------------------------------
06:49:15.023: computer_power_supply_battery_BAT1 property battery.voltage.current = 12512 (0x30e0)
06:53:08.928: platform_i8042_i8042_KBD_port_logicaldev_input added
06:58:42.785: computer_logicaldev_input_3 condition ButtonPressed = wlan
06:58:42.832: ssb__null__rfkill_b43_phy0_wlan property killswitch.state = 0 (0x0)
06:58:45.260: computer_logicaldev_input_3 removed
06:58:45.311: ssb__null__rfkill_b43_phy0_wlan removed
06:58:45.352: leds_b43_phy0_tx removed
06:58:45.360: computer_rfkill__null__unknown added
06:58:45.418: leds_b43_phy0_rx removed
06:58:45.442: leds_b43_phy0_radio removed
06:58:52.014: ssb__null__rfkill_b43_phy0_wlan added
06:58:52.430: computer_logicaldev_input_3 added
06:58:54.018: computer_logicaldev_input_3 removed
06:58:54.132: ssb__null__rfkill_b43_phy0_wlan removed
06:58:54.189: computer_rfkill__null__unknown_0 added
06:59:08.011: computer_power_supply_battery_BAT1 property battery.voltage.current = 12510 (0x30de)

I wonder if the platform 'quirks' that are embedded in the HAL subsystem have changed between Intrepid and Jaunty.

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-04-09:

#24

I tweaked /etc/apt/sources.list and added the intrepid package repository so I could force a downgrade of the HAL packages. I downgraded hal, libhal1, and libhal-storage from version 0.5.12-rc1+git20090403 to version 0.5.11-4ubuntu4 (i.e. intrepid's version). I hoped to show that this bug was introduced in the HAL subsystem.

Unfortunately, downgrading these packages prevents X from starting. The screen comes up but then the laptop freezes so I can't say whether the wireless networking disconnects have improved.

I reverted that change, apt-get updated and upgraded this morning (4/9/09), and restored Jaunty to working order. Unfortunately, the wireless disconnect problem is still (as you would expect) present. Wireless goes down 5 or so minutes after rebooting.

I'm trying here folks but I'm not sufficiently familiar with HAL to see where to go next to demonstrate whether this is a HAL bug or some other user space application. Andrew Aylett has already shown that reverting back to the Intrepid kernel doesn't fix the problem. I verified weeks ago that the B43 firmware hasn't changed.

So, what can I do to help troubleshoot this bug? It's not going away by itself.

Revision history for this message

Superball (shufflevideo) wrote on 2009-04-09: Re: [Bug 331952] Re: [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver

#25

Download full text (12.6 KiB)

I think we should make a very short list of what does/doesnt resolv
and / or get us more close to the solution, (so 30 people with the
same S/W-spec don't have to try out the same thing).

I have noticed that sometimes, when I'm very active on the computer
(browsing the web) the WLAN seems to stay up. This after I disabled
all the power-saving features - that is, System->Preferences->Power
Management (Uncheck "Dim When Idle"). I am not saying that this is the
solution - The WLAN still goes down - but it actually doesn't go down
on the same short notice as it did before. It also seems that if there
are many connections (e.g. rTorrent or similar), the NIC goes down. I
also noticed something interresting a couple of days ago. I was
browsing the web with FireFox and hit 'ping google.com' in bash. the
nic suddenly started to go down to 0b/s(i measure traffic with
netspeed). By this time, 'ping google.com' was dead quiet, unitil I
quickly closed firefox. The wlan suddenly seemed to work again, since
'ping google.com' started to ping, and the netspee-applet suddenly
started showing traffic flow again. This same thing did not only
happen with Firefox, but also with RTorrent (I tried it later). My
thought is: could this have something to do with some kind of virtual
lockfile? I am (as I may have stated before) absolutely no
ubuntu-expert, but I'd really like to help solving this problem, not
only for my own sake, but for the ubuntu community. :-)

On, and I am running the BCM STA-driver.

Joakim

On Thu, Apr 9, 2009 at 11:53 AM, Ben McCann <email address hidden> wrote:
>
> I tweaked /etc/apt/sources.list and added the intrepid package repository so I could force a downgrade of the HAL packages. I downgraded hal, libhal1, and libhal-storage from version 0.5.12-rc1+git20090403 to version 0.5.11-4ubuntu4 (i.e. intrepid's version). I hoped to show that this bug was introduced in the HAL subsystem.
>
> Unfortunately, downgrading these packages prevents X from starting. The
> screen comes up but then the laptop freezes so I can't say whether the
> wireless networking disconnects have improved.
>
> I reverted that change, apt-get updated and upgraded this morning
> (4/9/09), and restored Jaunty to working order. Unfortunately, the
> wireless disconnect problem is still (as you would expect) present.
> Wireless goes down 5 or so minutes after rebooting.
>
> I'm trying here folks but I'm not sufficiently familiar with HAL to see
> where to go next to demonstrate whether this is a HAL bug or some other
> user space application. Andrew Aylett has already shown that reverting
> back to the Intrepid kernel doesn't fix the problem. I verified weeks
> ago that the B43 firmware hasn't changed.
>
> So, what can I do to help troubleshoot this bug? It's not going away by
> itself.
>
> --
> [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver
> https://bugs.launchpad.net/bugs/331952
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “linux” source package in Ubuntu: Triaged
>
> Bug description:
> Wireless with the BCM4312 adapter connects, runs several minutes, and disconnects unexpec...

I think we should make a very short list of what does/doesnt resolv
and / or get us more close to the solution, (so 30 people with the
same S/W-spec don't have to try out the same thing).

I have noticed that sometimes, when I'm very active on the computer
(browsing the web) the WLAN seems to stay up. This after I disabled
all the power-saving features - that is, System->Preferences->Power
Management (Uncheck "Dim When Idle"). I am not saying that this is the
solution - The WLAN still goes down - but it actually doesn't go down
on the same short notice as it did before. It also seems that if there
are many connections (e.g. rTorrent or similar), the NIC goes down. I
also noticed something interresting a couple of days ago. I was
browsing the web with FireFox and hit 'ping google.com' in bash. the
nic suddenly started to go down to 0b/s(i measure traffic with
netspeed). By this time, 'ping google.com' was dead quiet, unitil I
quickly closed firefox. The wlan suddenly seemed to work again, since
'ping google.com' started to ping, and the netspee-applet suddenly
started showing traffic flow again. This same thing did not only
happen with Firefox, but also with RTorrent (I tried it later). My
thought is: could this have something to do with some kind of virtual
lockfile? I am (as I may have stated before) absolutely no
ubuntu-expert, but I'd really like to help solving this problem, not
only for my own sake, but for the ubuntu community. :-)

On, and I am running the BCM STA-driver.

Joakim

On Thu, Apr 9, 2009 at 11:53 AM, Ben McCann <bn.mccann@gmail.com> wrote:
>
> I tweaked /etc/apt/sources.list and added the intrepid package repository so I could force a downgrade of the HAL packages. I downgraded hal, libhal1, and libhal-storage from version 0.5.12-rc1+git20090403 to version 0.5.11-4ubuntu4 (i.e. intrepid's version). I hoped to show that this bug was introduced in the HAL subsystem.
>
> Unfortunately, downgrading these packages prevents X from starting. The
> screen comes up but then the laptop freezes so I can't say whether the
> wireless networking disconnects have improved.
>
> I reverted that change, apt-get updated and upgraded this morning
> (4/9/09), and restored Jaunty to working order. Unfortunately, the
> wireless disconnect problem is still (as you would expect) present.
> Wireless goes down 5 or so minutes after rebooting.
>
> I'm trying here folks but I'm not sufficiently familiar with HAL to see
> where to go next to demonstrate whether this is a HAL bug or some other
> user space application. Andrew Aylett has already shown that reverting
> back to the Intrepid kernel doesn't fix the problem. I verified weeks
> ago that the B43 firmware hasn't changed.
>
> So, what can I do to help troubleshoot this bug? It's not going away by
> itself.
>
> --
> [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver
> https://bugs.launchpad.net/bugs/331952
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “linux” source package in Ubuntu: Triaged
>
> Bug description:
> Wireless with the BCM4312 adapter connects, runs several minutes, and disconnects unexpectedly with Ubuntu Jaunty (9.04) Alpha 4 on an HP 2133 MiniNote laptop.  The same laptop runs wireless flawlessly under Ubuntu Intrepid (8.10). I only have wireless issues under Jaunty. Once it has disconnected, I'm unable to reestablish a connection w/o rebooting.
>
> Note that the laptop is configured to dual boot between Intrepid and Jaunty so its easy to run A/B experiments between the two releases.
>
> All this takes to reproduce is to boot Jaunty with the B43 driver, bring up wireless, and then wait 5 or 10 minutes. I've hit this at home, with WEP encryption, and at work on an open guest network so its not the AP. The wireless works fine for several minutes, disconnects, and then won't reconnect
>
> I'm running the latest Jaunty (Xubuntu) packages as of this morning (2/20/09) and the problem still occurs. I don't know if this is a network-manager issue or a driver problem. Here are some chunks of data to start the triage
>
> Uname:
>
> Linux version 2.6.28-7-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-3ubuntu2) ) #20-Ubuntu SMP Mon Feb 9 15:43:21 UTC 2009 (Ubuntu 2.6.28-7.20-generic)
>
>
> lspci on the BCM4312:
>
> 02:00.0 0280: 14e4:4312 (rev 02)
>    Subsystem: 103c:1370
>    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 at fdffc000 (64-bit, non-prefetchable) [size=16K]
>    Capabilities: <access denied>
>    Kernel driver in use: b43-pci-bridge
>    Kernel modules: wl, ssb
>
>
> kern.log:
>
> Feb 17 08:18:23 Polaris kernel: [ 2233.000045] b43-phy0: Radio hardware status changed to DISABLED
> Feb 17 08:18:27 Polaris kernel: [ 2237.756070] wlan0: No ProbeResp from current AP 00:1f:90:e0:19:75 - assume out of range
> Feb 17 08:18:27 Polaris kernel: [ 2237.904035] b43-phy0: Radio turned on by software
> Feb 17 08:18:27 Polaris kernel: [ 2237.904047] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on.
> Feb 17 08:18:28 Polaris kernel: [ 2238.677784] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 1
> Feb 17 08:18:28 Polaris kernel: [ 2238.677879] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 1
> Feb 17 08:18:28 Polaris kernel: [ 2238.876059] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 2
> Feb 17 08:18:28 Polaris kernel: [ 2239.076064] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 3
> Feb 17 08:18:29 Polaris kernel: [ 2239.276063] wlan0: direct probe to AP 00:1f:90:e0:19:75 timed out
> Feb 17 08:22:56 Polaris kernel: [ 2507.004202] b43-phy0 ERROR: DMA RX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.164055] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.324077] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.484076] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.644225] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.804079] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.804776] ssb: Failed to switch to core 0
> Feb 17 08:23:08 Polaris kernel: [ 2518.277353] input: b43-phy0 as /devices/virtual/input/input13
> Feb 17 08:23:08 Polaris kernel: [ 2518.328060] ssb: Backplane Revision 0xF0000000
> Feb 17 08:23:08 Polaris kernel: [ 2518.328127] ------------[ cut here ]------------
> Feb 17 08:23:08 Polaris kernel: [ 2518.328139] WARNING: at /build/buildd/linux-2.6.28/drivers/ssb/main.c:1042 ssb_tmslow_reject_bitmask+0x59/0x90 [ssb]()
> Feb 17 08:23:08 Polaris kernel: [ 2518.328152] Modules linked in: usbhid rfkill_input via drm bridge stp bnep e_powersaver ppdev parport_pc lp parport joydev snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse pcspkr snd_timer snd_seq_device serio_raw snd i2c_viapro soundcore snd_page_alloc uvcvideo compat_ioctl32 videodev v4l1_compat arc4 ecb leds_hp_disk video output b43 lis3lv02d mac80211 cfg80211 led_class input_polldev shpchp via_agp agpgart tg3 ehci_hcd uhci_hcd ssb fbcon tileblit font bitblit softcursor fuse
> Feb 17 08:23:08 Polaris kernel: [ 2518.328314] Pid: 3227, comm: NetworkManager Not tainted 2.6.28-7-generic #20-Ubuntu
> Feb 17 08:23:08 Polaris kernel: [ 2518.328324] Call Trace:
> Feb 17 08:23:08 Polaris kernel: [ 2518.328346]  [<c04e2911>] ? printk+0x18/0x1f
> Feb 17 08:23:08 Polaris kernel: [ 2518.328363]  [<c0133a64>] warn_on_slowpath+0x54/0x80
> Feb 17 08:23:08 Polaris kernel: [ 2518.328399]  [<f7cafef9>] ssb_tmslow_reject_bitmask+0x59/0x90 [ssb]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328431]  [<f7caff44>] ssb_device_is_enabled+0x14/0x40 [ssb]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328475]  [<f7ffd387>] b43_wireless_core_init+0x37/0x520 [b43]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328520]  [<f800e9a2>] ? b43_rfkill_init+0x142/0x1d0 [b43]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328559]  [<f7ffea17>] b43_op_start+0x147/0x1a0 [b43]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328630]  [<f7e3f10a>] ieee80211_open+0x32a/0x830 [mac80211]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328651]  [<c014c88a>] ? hrtimer_try_to_cancel+0x3a/0x90
> Feb 17 08:23:08 Polaris kernel: [ 2518.328669]  [<c04e3c99>] ? schedule_hrtimeout_range+0xe9/0x150
> Feb 17 08:23:08 Polaris kernel: [ 2518.328687]  [<c0417312>] dev_open+0xa2/0xe0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328702]  [<c04e4d31>] ? _spin_unlock_bh+0x11/0x20
> Feb 17 08:23:08 Polaris kernel: [ 2518.328716]  [<c041674a>] ? dev_set_rx_mode+0x2a/0x40
> Feb 17 08:23:08 Polaris kernel: [ 2518.328730]  [<c04169c1>] dev_change_flags+0x131/0x1c0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328749]  [<c041f80d>] do_setlink+0x1ed/0x3a0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328766]  [<c0431103>] ? nla_reserve+0x43/0x60
> Feb 17 08:23:08 Polaris kernel: [ 2518.328781]  [<c041f10f>] ? rtnl_fill_ifinfo+0x2cf/0x3b0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328797]  [<c041faa1>] rtnl_setlink+0xe1/0x120
> Feb 17 08:23:08 Polaris kernel: [ 2518.328813]  [<c0430270>] ? netlink_dump_start+0x130/0x170
> Feb 17 08:23:08 Polaris kernel: [ 2518.328828]  [<c041f9c0>] ? rtnl_setlink+0x0/0x120
> Feb 17 08:23:08 Polaris kernel: [ 2518.328843]  [<c041ebf5>] rtnetlink_rcv_msg+0x165/0x200
> Feb 17 08:23:08 Polaris kernel: [ 2518.328858]  [<c041f1f0>] ? rtnl_dump_ifinfo+0x0/0xa0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328874]  [<c041ea90>] ? rtnetlink_rcv_msg+0x0/0x200
> Feb 17 08:23:08 Polaris kernel: [ 2518.328888]  [<c0430116>] netlink_rcv_skb+0x76/0xa0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328903]  [<c041ea7c>] rtnetlink_rcv+0x1c/0x30
> Feb 17 08:23:08 Polaris kernel: [ 2518.328916]  [<c042f89d>] netlink_unicast+0x25d/0x290
> Feb 17 08:23:08 Polaris kernel: [ 2518.328931]  [<c043091b>] netlink_sendmsg+0x1cb/0x2b0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328946]  [<c040921a>] sock_sendmsg+0xea/0x110
> Feb 17 08:23:08 Polaris kernel: [ 2518.328964]  [<c0298b40>] ? apparmor_socket_recvmsg+0x10/0x20
> Feb 17 08:23:08 Polaris kernel: [ 2518.328981]  [<c0148bf0>] ? autoremove_wake_function+0x0/0x50
> Feb 17 08:23:08 Polaris kernel: [ 2518.328996]  [<c0148bf0>] ? autoremove_wake_function+0x0/0x50
> Feb 17 08:23:08 Polaris kernel: [ 2518.329013]  [<c02bdb65>] ? copy_from_user+0x35/0x130
> Feb 17 08:23:08 Polaris kernel: [ 2518.329031]  [<c04106f0>] ? verify_iovec+0x30/0xb0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329044]  [<c0409351>] sys_sendmsg+0x111/0x230
> Feb 17 08:23:08 Polaris kernel: [ 2518.329057]  [<c0409574>] ? sys_sendto+0xb4/0xd0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329070]  [<c041518d>] ? __dev_get_by_name+0x7d/0xa0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329084]  [<c02bdc96>] ? copy_to_user+0x36/0x120
> Feb 17 08:23:08 Polaris kernel: [ 2518.329103]  [<c0407410>] ? sock_destroy_inode+0x10/0x20
> Feb 17 08:23:08 Polaris kernel: [ 2518.329122]  [<c01c985a>] ? destroy_inode+0x2a/0x50
> Feb 17 08:23:08 Polaris kernel: [ 2518.329137]  [<c01ca192>] ? generic_forget_inode+0x152/0x170
> Feb 17 08:23:08 Polaris kernel: [ 2518.329152]  [<c0409b05>] sys_socketcall+0xd5/0x2b0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329173]  [<c01b50a9>] ? filp_close+0x49/0x70
> Feb 17 08:23:08 Polaris kernel: [ 2518.329188]  [<c01b514a>] ? sys_close+0x7a/0xc0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329203]  [<c0103f6b>] sysenter_do_call+0x12/0x2f
> Feb 17 08:23:08 Polaris kernel: [ 2518.329214] ---[ end trace 81079ab9ec490f87 ]---
> Feb 17 08:23:09 Polaris kernel: [ 2519.508098] b43-phy0 ERROR: Microcode not responding
> Feb 17 08:23:09 Polaris kernel: [ 2519.508117] b43-phy0 ERROR: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4).
>
> I considered loading a different version of the B43 firmware as suggested but the firmware stored under /lib/firmware/b43 is identical between Ubuntu Intrepid and Jaunty. (I binary compared all the files and verified each uses the same firmware version (broadcom-wl-4.150.10.5.tar.bz2). The install_bcm43xx_firmware.sh scripts in Intrepid and Jaunty are also identical.
>
> So, I don't think this is a firmware issue despite the fact the driver wants new firmware. This firmware is fine in Intrepid. I think something else in the b43, wl, or ssb driver has regressed. Or, perhaps there's been a regression in network-manager.
>
>
> I'm happy to help any way necessary to find this bug.
>
> -Ben McCann
>
> == Regression details ==
> Discovered in version: Jaunty Alpha 4
> Last known good version: Intrepid 8.10
>

Revision history for this message

Juhana Karihuhta (juhana-karihuhta) wrote on 2009-04-11: Re: [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver

#26

I noticed that when i play video with xine, the conection will drop. It works when i start xine, but immediately when i hit "F" for fullscreen, the connection drops. I'ts directly linked to the fullscreen video when using xv. So could it be in openchrome drivers? Could there be some conflict with the overlay thingy and the broadcom wireless?. When i did system update, and left the computer on for while, the screen blanked, but the connection managed to hold. so traffic seems to affect it. On this machine i needed to add that "'PanelSize 1024X600", so there seems to be some problem with display handling. Does the system do somekind of display reset when blanking or going fullscreen with xv?

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-04-12:

#27

[NOTE: WORK-AROUND AVAILABLE]

I can reproduce ezgumol's observation with the added twist that the wireless network goes down *immediately* upon starting 'xine'. I don't have to go to full screen at all. It it takes is playing a movie in xine. I ran a 'ping' in one window and xine in another and as soon as xine started the movie the 'ping' stopped and shortly later the wireless was reported down. Further, 'dmesg' shows the 'Radio hardware status changed to DISABLED' message coincident with starting 'xine'.

So, there apparently *is* an interaction between the Jaunty "openchrome" video driver and the B43 wireless driver. (The HP2133 uses a CN896 Chome 9 video chip that, by default, runs with the 'openchome' driver).

I replaced the openchrome driver with the basic 'vesa' driver by adding 'Driver "vesa"' to the device section in the file /etc/X11/xorg.conf. This forces X to use 'vesa' instead of automatically loading 'openchrome'. For example:

Section "Device"
Identifier "Configured Video Device"
Driver "vesa" <<<< Add this line
EndSection

(You will need to reboot for this to take affect).

Once the 2133 is running under the 'vesa' driver, the problem goes away. I ran multiple trials with the vesa driver versus the default openchrome driver and 'xine' always killed the wireless with 'openchrome'. 'Xine' with the 'vesa' driver *never* killed the wireless. I can run xine in a window, or full screen (albeit slowly), without any ill effect on wireless. You can solve the wireless issue if you're willing to live without openchrome video acceleration.

This is a significant point. I filed this bug because wireless started failing when I was testing Jaunty on a machine that normally runs Intrepid without issue. This is significant because I don't run 'openchrome' under Intrepid! That driver was pretty immature under Intrepid so, instead, I use the VIA proprietary driver for the Chrome 9 video chip under Intrepid. This driver works well, and provides the best acceleration, but its not yet available for Jaunty.

Given this data, it would probably be productive to get the OpenChrome folks involved in trouble shooting this problem.

[NOTE: WORK-AROUND AVAILABLE]

I can reproduce ezgumol's observation with the added twist that the wireless network goes down *immediately* upon starting 'xine'. I don't have to go to full screen at all. It it takes is playing a movie in xine. I ran a 'ping' in one window and xine in another and as soon as xine started the movie the 'ping' stopped and shortly later the wireless was reported down. Further, 'dmesg' shows the 'Radio hardware status changed to DISABLED' message coincident with starting 'xine'.

So, there apparently *is* an interaction between the Jaunty "openchrome" video driver and the B43 wireless driver. (The HP2133 uses a CN896 Chome 9 video chip that, by default, runs with the 'openchome' driver).

I replaced the openchrome driver with the basic 'vesa' driver by adding 'Driver "vesa"' to the device section in the file /etc/X11/xorg.conf. This forces X to use 'vesa' instead of automatically loading 'openchrome'. For example:

Section "Device"
             Identifier      "Configured Video Device"
             Driver          "vesa"                                             <<<< Add this line
EndSection

(You will need to reboot for this to take affect).

Once the 2133 is running under the 'vesa' driver, the problem goes away. I ran multiple trials with the vesa driver versus the default openchrome driver and 'xine' always killed the wireless with 'openchrome'. 'Xine' with the 'vesa' driver *never* killed the wireless. I can run xine in a window, or full screen (albeit slowly), without any ill effect on wireless. You can solve the wireless issue if you're willing to live without openchrome video acceleration.

This is a significant point. I filed this bug because wireless started failing when I was testing Jaunty on a machine that normally runs Intrepid without issue. This is significant because I don't run 'openchrome' under Intrepid! That driver was pretty immature under Intrepid so, instead, I use the VIA proprietary driver for the Chrome 9 video chip under Intrepid. This driver works well, and provides the best acceleration, but its not yet available for Jaunty.

Given this data, it would probably be productive to get the OpenChrome folks involved in trouble shooting this problem.

Revision history for this message

damianChapman (cosmoschapman) wrote on 2009-04-25:

#28

Ben,

I am having the same wireless issue as you with my HP2133.
I tried putting in your fix to the X11.conf file and when I rebooted I got a blank screen with a flashing _ cursor in the top left hand side of the screen.

Regards,
Damian.

Revision history for this message

Steve Lilley (steve-lilley-nohp) wrote on 2009-04-26:

#29

Ben

I have had exactly the same experience as you. I am new to Linux but am happy to run any commands that might help along the way but as I have BCM94312MCG it looks like my h/w is the same.

I was using Intrepid with xforcevesa as I couldn't get any other drivers to work. Video poor but wifi was perfect, even after sleeping.

Updated to 9.04 to see if the video had improved and was really impressed, until the wifi issues were spotted soon after doing the full installation. I would be keen to know if there is anything I can do to change drivers ? Can anyone point me in the right direction? Thanks.

Steve

Revision history for this message

Ben McCann (ben-mccann) wrote on 2009-04-27:

#30

X11 Xorg.conf for VESA driver Edit (894 bytes, text/plain)

Damian,

I'm very surprised that selecting the VESA X11 driver breaks your X windows. This is the "lowest common denominator" driver that doesn't rely on any hardware specific acceleration features. It should *always* work.

I'm attaching my xorg.conf file for your reference.

This will be my last message on this bug because I'm putting my 2133 up for sale on EBay. I just replaced it with the new high-res HP 2140 which has an Intel graphics chip instead of the VIA OpenChrome chip. The Intel chip works well in Intrepid and totally *blows* under Jaunty due to the introduction of brand new and buggy Intel drivers.

Revision history for this message

Michal Ganzarcik (michal-annun) wrote on 2009-04-28:

#31

I also have this problem. Wireless keeps disconnecting, seemingly at random - once it disconnects, it is unable to reconnect again (although the panel icon suggests that it is trying). The only way for me to connect again is to disable wireless in NM and enable it again.

I've tried the vesa driver fix and it didn't help at all, the behavior is completely the same. Running the vesa driver right now and was just disconnected.

I've also tried downgrading the NM, currently running at version 0.7~~svn20081018t105859-0ubuntu2, again, to no avail.

This behavior started after upgrading to Jaunty.

Some info (if you need anything else, I will be more than happy to provide it, but please, explain how to get to it first - I am still a Linux newbie)

uname -a:
Linux rex 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

lspci -v (audio, video and network only):

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
Subsystem: Hewlett-Packard Company Device 099c
Flags: fast devsel, IRQ 11
Memory at d0400000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 7000 [size=8]
Memory at c0000000 (32-bit, prefetchable) [size=256M]
Memory at d0480000 (32-bit, non-prefetchable) [size=256K]
Capabilities: <access denied>
Kernel modules: intelfb

00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
Subsystem: Hewlett-Packard Company Device 099c
Flags: bus master, fast devsel, latency 0
Memory at d0500000 (32-bit, non-prefetchable) [size=512K]
Capabilities: <access denied>

00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
Subsystem: Hewlett-Packard Company Device 099c
Flags: bus master, medium devsel, latency 0, IRQ 21
I/O ports at 2100 [size=256]
I/O ports at 2200 [size=64]
Memory at d0581000 (32-bit, non-prefetchable) [size=512]
Memory at d0582000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: Intel ICH
Kernel modules: snd-intel8x0

00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03)
Subsystem: Hewlett-Packard Company Device 099c
Flags: medium devsel, IRQ 22
I/O ports at 2400 [size=256]
I/O ports at 2500 [size=128]
Capabilities: <access denied>
Kernel modules: snd-intel8x0m

02:04.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
Subsystem: Hewlett-Packard Company Device 1356
Flags: bus master, fast devsel, latency 64, IRQ 21
Memory at d0000000 (32-bit, non-prefetchable) [size=8K]
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb

02:0e.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
Subsystem: Hewlett-Packard Company Device 099c
Flags: bus master, fast devsel, latency 64, IRQ 16
Memory at d000e000 (32-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: b44
Kernel modules: b44

I also have this problem. Wireless keeps disconnecting, seemingly at random - once it disconnects, it is unable to reconnect again (although the panel icon suggests that it is trying). The only way for me to connect again is to disable wireless in NM and enable it again.

I've tried the vesa driver fix and it didn't help at all, the behavior is completely the same. Running the vesa driver right now and was just disconnected.

I've also tried downgrading the NM, currently running at version 0.7~~svn20081018t105859-0ubuntu2, again, to no avail.

This behavior started after upgrading to Jaunty.

Some info (if you need anything else, I will be more than happy to provide it, but please, explain how to get to it first - I am still a Linux newbie)

uname -a:
Linux rex 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

lspci -v (audio, video and network only):

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
	Subsystem: Hewlett-Packard Company Device 099c
	Flags: fast devsel, IRQ 11
	Memory at d0400000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at 7000 [size=8]
	Memory at c0000000 (32-bit, prefetchable) [size=256M]
	Memory at d0480000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: <access denied>
	Kernel modules: intelfb

00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
	Subsystem: Hewlett-Packard Company Device 099c
	Flags: bus master, fast devsel, latency 0
	Memory at d0500000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: <access denied>

00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
	Subsystem: Hewlett-Packard Company Device 099c
	Flags: bus master, medium devsel, latency 0, IRQ 21
	I/O ports at 2100 [size=256]
	I/O ports at 2200 [size=64]
	Memory at d0581000 (32-bit, non-prefetchable) [size=512]
	Memory at d0582000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <access denied>
	Kernel driver in use: Intel ICH
	Kernel modules: snd-intel8x0

00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03)
	Subsystem: Hewlett-Packard Company Device 099c
	Flags: medium devsel, IRQ 22
	I/O ports at 2400 [size=256]
	I/O ports at 2500 [size=128]
	Capabilities: <access denied>
	Kernel modules: snd-intel8x0m

02:04.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
	Subsystem: Hewlett-Packard Company Device 1356
	Flags: bus master, fast devsel, latency 64, IRQ 21
	Memory at d0000000 (32-bit, non-prefetchable) [size=8K]
	Kernel driver in use: b43-pci-bridge
	Kernel modules: ssb

02:0e.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
	Subsystem: Hewlett-Packard Company Device 099c
	Flags: bus master, fast devsel, latency 64, IRQ 16
	Memory at d000e000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: b44
	Kernel modules: b44

Revision history for this message

Michal Ganzarcik (michal-annun) wrote on 2009-04-28:

#32

daemon.log and kern.log Edit (21.7 KiB, text/plain)

Sorry for the double post, but I've just been disconnected again and luckily, I was running the System Log Viewer and was able to get all of the output from NM while it was disconnected, and tried to connect again. What it did after a while is ask for my WEP information (even though it has it already) - after I provided it, it just silently failed to reconnect.

I had to disable / enable wireless to get connected again.

I had a Youtube tab opened in Firefox, and Krusader, Evolution, Open Office Writer and the Log Viewer running at the time.

I closed the Youtube tab and still got disconnected like a minute later again. This makes me suspect it's either not video-related, or I have a different problem.

Attaching the logs from daemon.log and kern.log, hope it is useful.

Revision history for this message

byzkarl (byzkarl) wrote on 2009-04-28:

#33

I haven't had network problems when I run in console mode with the frame buffer. I've used cnetworkmanager to connect, and run videos with mplayer -vo fbdev, and haven't lost the network. When I'm running X, all I need to do to make it disconnect is play a video via mplayer.

I've got an HP2133 running Jaunty.

Revision history for this message

wildtiger23 (tony-marquis-gmail) wrote on 2009-04-28:

#34

wlan.txt Edit (47.0 KiB, text/plain)

I have the same problem. I tried with the new applet and with wicd and the same problem occur. I'm giving some information I found in my log file, maybe it will help you fooind what's going on.

Steve Beattie (sbeattie) on 2009-04-28

tags:

added: regression-release
removed: regression-potential

Revision history for this message

Oleg Kalnichevski (olegk) wrote on 2009-04-29:

#35

The video driver theory seems very plausible. I am also having similar issues with Broadcom STA driver and ndiswrapper. The connection can be successfully established and stays up as long as there is some activity. The connection goes down after a certain period of inactivity regardless of the driver (b43, wl, ndiswrapper). Downgrading to 8.10 seems the only option as the moment. Both b43 and wl worked flawlessly for me in 8.10.

Revision history for this message

asg (adam-garside) wrote on 2009-04-29:

#36

I've been tracking this bug for a while hoping for a fix. Yesterday, I was looking at bug reports in OpenChrome and noticed this:

http://www.openchrome.org/trac/ticket/288

Near the end is a mention of a patch

http://www.openchrome.org/trac/attachment/ticket/288/openchrome_741_hp_2133.patch

I applied this to the SVN openchrome code (revision 747), compiled and installed it and voila, I haven't had an issue with wireless disconnects using either the b43 driver or the STA driver. I was able to watch videos in vlc without seeing any wireless disconnects.

I'm currently running a fully up-to-date Jaunty on the XSVGA (1024x600) model.

Revision history for this message

wildtiger23 (tony-marquis-gmail) wrote on 2009-04-29:

#37

I tried your solution and it worked for me so far.

Revision history for this message

Michal Ganzarcik (michal-annun) wrote on 2009-04-29:

#38

I think this won't help me: as I have an Intel graphics card (the "mighty" 915GM), I am probably not even using openchrome (please correct me if I am wrong here), yet the connection still drops.

Revision history for this message

Juhana Karihuhta (juhana-karihuhta) wrote on 2009-04-30:

#39

I can verify asg:s fix. Dowloaded svn source and patched&compiled it. I noticed that part of that patch is already in the svn code. So i tried to compile it first with no patch, but the problem was still there. Then added the patch and everything works flawlessly. I wonder why they haven't added that "//ViaLVDSDFPPower(pScrn, on);" part to the svn code. But anyway, now i can watch films on xine and wireless holds its connection. Hopefully they soon release update for the ubuntu version of the openchrome driver...:)

-- Juhana Karihuhta

Revision history for this message

Michal Ganzarcik (michal-annun) wrote on 2009-05-01:

#40

Well. I've done some more testing and I think that in my case, the disconnecting is related to the strength of signal - I don't really get disconnected when sitting right next to the AP (will test this some more), but if I move to a different room, I can get quite frequent disconnects (even several per minute).

However, this is not the AP's problem - we have three computers connected to the Wifi in our household and none have this kind of problems. Even this laptop, if booted into Windows, works perfectly fine. It only started disconnecting after upgrade to Jaunty.

I am not sure what to do. I have tried to downgrade kernel to version 2.6.27 from Intrepid but that also didn't help. I keep getting disconnected under both kernel versions.

It wouldn't be so bad if it managed to connect after some time - but instead, it tries to connect for a while and then just gives up completely and deactivates the device (if I understand the line "(wlan0): deactivating device (reason: 0). " from daemon.log correctly).

Should I file a new bug for this (as it is probably not really connected with graphic drivers)? Is there even anything that can be done about it, or should I just give up and learn to live with it?

Revision history for this message

Ole Eskildsen (ole.eskildsen) wrote on 2009-05-04:

#41

Michael,

I'm another user who has this problem.

My hardware: HP 2133

When I first installed 8.04 I could NEVER get wifi to work.

After I upgraded to 8.10, wifi was now working PROVIDED I installed the recommended proprietary driver: Broadcom STA Wireless Driver.

Then I upgraded to 9.04 by doing a FRESH INSTALL with the recommended Broadcom STA driver, stock standard 9.04 installation, but now wireless crashes randomly as described by all the above.

Wireless was working fine on 8.10 now under 9.04 it doesn't work properly.
It seems to me, as some have reported above, that it disconnects when I leave the machine. Even if I leave Evolution email running which connects to the mail server on the Net once every minute, wifi still disconnects. When I am at the machine and doing things like browsing the net, it seems to stay up most, if not all, of the time.

I think this is of GRAVE CONCERN. This bug report was raised as early as 2009-02-20 by Ben McCann, and now we have May 4 and the problem still exists.

I have noticed there are literally 100s of bug reports with a similar theme for all kinds of hardware, not just the HP 2133.

This leads me to conclude there is a MAJOR PROBLEM with wifi under 9.04!!!

How can we get the developers to give this a high priority?
The ideal solution would be that the problem gets found very quickly and fixed and updated software (whether kernel or something else) is made available via synaptic or apt-get, etc.

Those of us who have been using Ubuntu for some time and like it will probably do what you wrote: "should I just give up and learn to live with it?".
BUT what about new users, people who switch to Ubuntu from MS or just try it out?
If they keep having this problem, then they will NOT be impressed and probably not stay with Ubuntu, but rather speak negatively about it.

Cheers from Brisbane, Australia

Ole

Revision history for this message

JerryW. (jerry-jerrywroblewski) wrote on 2009-05-04:

#42

I also have this problem on my HP 2133 and it looks to me that the openchrome patch linked by ASG would work for me. Unfortunately, I'm much to much a newbie on Linux to attempt this patch. Is it possible for someone to compile this change for me so I can substitute the file on my 2133? I know someone locally that seems to know enough to lead me through the terminal to update the driver if I had a driver with the patch applied.

I would hope that Ubuntu would end up with an update to 9.04 at some time but I'm trying to set up this mini for my elderly sister-in-law in Australia (Perth) so she can email my wife on a regular basis in the U.S. As you can image, having the wireless go down for her periodically might end the project.
Thanks,
Jerry W.

Revision history for this message

Ole Eskildsen (ole.eskildsen) wrote on 2009-05-04:

#43

G'day Jerry,

I just saw your post and thought I would share the latest development for me because it looks like my connection is staying up. (I will reserve my final judgment till tomorrow after I have slept all night and the connection hopefully has stayed up.)

I noticed that Ben McCann in one of his posts above was speculating that the graphics "chrome" driver seemed to make the connection go down in certain situations (why the video driver should interfere with the wireless driver is beyond my understanding.). He then suggested to use another graphics driver "vesa" which he seems to think is inferior to the "chrome" driver but that the connections stays up.

So, I decided to try it. This is what I have now:
1. Ubuntu 9.04
2. Broadcom STA Wireless Driver (I think this may be important).
3. "vesa" video driver by modifying the /etc/X11/xorg.conf file (a bit tricky if you don't know how, be sure to take a backup before you mess with it.)
For now it seems to stay up and I have no complaints about the "vesa" driver's graphics.

If you don't know how to do these things, then perhaps I could talk you through it on the phone, but not now, I need to go to bed. If you like, we can try it tomorrow.

Ubuntu is a fabulous operating system and I don't want to switch to something else just because of this problem, but I do wish the clever systems programmers could fix the problem and issue updated software we could install and everything works thereafter.

Cheers,

Ole

Revision history for this message

Andy Venables (axme20) wrote on 2009-05-05:

#44

I noticed this:

Ubuntu 9.04

With 2133 on AC power

System -> Preferences -> Power Management -> On AC Power -> When Laptop Lid is Closed = Blank Screen

Closing the lid drops wireless connection permanently, and display can be seen to blank

With 2133 on AC power

System -> Preferences -> Power Management -> On AC Power -> When Laptop Lid is Closed = Do Nothing

Closing the lid has no effect on wireless connection, but display can be seen to blank anyway

Andy

Revision history for this message

Ole Eskildsen (ole.eskildsen) wrote on 2009-05-06:

#45

Download full text (3.5 KiB)

Hi all,

After reading about all these woes and experiencing it myself, I have done some further experimenting in order to isolate the problem and as a result I have found a very EASY WORKAROUND which in no way impacts on your computer.

MY SETUP:
Hardware: HP 2133 Mini-note netbook computer
Fresh install of Ubuntu 9.04
Using internal wireless modem with Broadcom STA driver for wifi access

PROBLEM:
After booting up and providing relevant information and password I can connect wirelessly.
If I leave the PC for a while and return then I find that the wireless connection is down and there is no way I can get it up again except rebooting, very inconvenient.
This problem did NOT exist in Ubuntu 8.10.

ACTIONS:
I searched the Ubuntu Forum and discovered that many, many others reported a similar or identical problem on many differenct hardware platforms.
Some had discovered that if they closed their laptop computer which switched off the screen, then they were immediately disconnected from the network and needed to reboot to get back on again.
Some therefore were pointing to the openchrome graphics driver (I find it amazing that a graphics driver should somehow interfere with the wireless driver).
So, the general consensus was developing that it had to do with the openchrome video driver and suggestions were to fall back to the vesa driver. I tried that and it did indeed prevent the problem form occuring, so further pointed a finger at openchrome.

I rebooted with openchrome again and then experimented this way:
I opened
System/Preferences/Screensaver/Power Management
and set it as follows:
"Put display to sleep when inactive for" and set it to "2 minutes".
I waited 2 minutes, the screen blanked without closing the laptop lid.
I woke it up by moving the mouse and tried if I still had a wireless connection up - NO - wireless connection was DOWN.

WORKAROUND:
I rebooted and again opened
System/Preferences/Screensaver/Power Management
and set it as follows:
"Put display to sleep when inactive for" and set it to "never".
Now the wifi connection stays UP, it has not gone down even once!!!

But when I leave the machine I would like it to blank the screen after, say, 5 minutes.
So I simply set the "Screensaver theme" to "Blank screen" after 5 minutes, and the screen blanks but when I move the mouse and check my wireless connection the it is still UP and running!!!

Andrew Aylett sent me this link (thanks, Andy):
http://www.openchrome.org/trac/ticket/288
If you go there you will see there is a patch made available for the openchrome driver and at least one HP2133 user has tested it and reports that it has fixed the problem.
My problem is, I don't know how to apply such a patch and since my computer now stays connected, I am not very keen to experiment with it.
What I am hoping is that one of the clever Ubuntu system guys will make the patch available for all of us to download and install the usual way via synaptic or one of the other update managers after rigorous testing.

This is the kind of problem I find extremely frustrating and if newbies have this problem, then it might likely turn them off Ubuntu and perhaps Linux in general. This problem was r...

Hi all,

After reading about all these woes and experiencing it myself, I have done some further experimenting in order to isolate the problem and as a result I have found a very EASY WORKAROUND which in no way impacts on your computer.

MY SETUP:
Hardware:  HP 2133 Mini-note netbook computer
Fresh install of Ubuntu 9.04
Using internal wireless modem with Broadcom STA driver for wifi access

PROBLEM:
After booting up and providing relevant information and password I can connect wirelessly.
If I leave the PC for a while and return then I find that the wireless connection is down and there is no way I can get it up again except rebooting, very inconvenient.
This problem did NOT exist in Ubuntu 8.10.

ACTIONS:
I searched the Ubuntu Forum and discovered that many, many others reported a similar or identical problem on many differenct hardware platforms.
Some had discovered that if they closed their laptop computer which switched off the screen, then they were immediately disconnected from the network and needed to reboot to get back on again.
Some therefore were pointing to the openchrome graphics driver (I find it amazing that a graphics driver should somehow interfere with the wireless driver).
So, the general consensus was developing that it had to do with the openchrome video driver and suggestions were to fall back to the vesa driver. I tried that and it did indeed prevent the problem form occuring, so further pointed a finger at openchrome.

I rebooted with openchrome again and then experimented this way:
I opened 
System/Preferences/Screensaver/Power Management
 and set it as follows:
"Put display to sleep when inactive for" and set it to "2 minutes".
I waited 2 minutes, the screen blanked without closing the laptop lid.
I woke it up by moving the mouse and tried if I still had a wireless connection up - NO - wireless connection was DOWN.

WORKAROUND:
I rebooted and again opened
System/Preferences/Screensaver/Power Management
 and set it as follows:
"Put display to sleep when inactive for" and set it to "never".
Now the wifi connection stays UP, it has not gone down even once!!!

But when I leave the machine I would like it to blank the screen after, say, 5 minutes.
So I simply set the "Screensaver theme" to "Blank screen" after 5 minutes, and the screen blanks but when I move the mouse and check my wireless connection the it is still UP and running!!!

Andrew Aylett sent me this link (thanks, Andy):
http://www.openchrome.org/trac/ticket/288
If you go there you will see there is a patch made available for the openchrome driver and at least one HP2133 user has tested it and reports that it has fixed the problem.
My problem is, I don't know how to apply such a patch and since my computer now stays connected, I am not very keen to experiment with it.
What I am hoping is that one of the clever Ubuntu system guys will make the patch available for all of us to download and install the usual way via synaptic or one of the other update managers after rigorous testing.

This is the kind of problem I find extremely frustrating and if newbies have this problem, then it might likely turn them off Ubuntu and perhaps Linux in general. This problem was reported by Ben McCann in February and perhaps by others too that early and here we are now in May and the problem has not been fixed. Is that good enough? Well, I have been a applications project manager for about 25 year and I would not have accepted this situation. Anyway, now we know where the problem lies, so please let us have a fix for it.

Bug Watch Updater (bug-watch-updater) on 2009-05-06

Changed in openchrome:
status:	Unknown → Confirmed

Revision history for this message

JerryW. (jerry-jerrywroblewski) wrote on 2009-05-06:

#46

All,
Just a follow up to the power management solution for the wireless down problem. In addition to the setting recommended by Ole, I had to set my "When laptop lid is closed:" to "Do Nothing" otherwise if you close the lid and open it again, I would lose the wireless. Let's hope a 9.04 update will fix this openchrome driver with the purported patch.
Jerry W.

Revision history for this message

Andrew Aylett (andrew-aylett) wrote on 2009-05-07:

#47

Debdiff including the patch from Openchrome Trac 288 Edit (2.5 KiB, text/plain)

I found that, while disabling screen blanking did stop the bug being triggered in certain circumstances, wireless would still be disabled whenever I used the XVideo extension. As most of what I use the laptop for involves a mix of WiFi and XVideo, I reverted to Intrepid for a while...

I've patched the Openchrome package from Jaunty to include the patch from Trac and tested it briefly on my Jaunty install, and I can verify that it fixed the issues I've seen, both with screen blanking and XV and also with suspend/resume. It's in my PPA, for anyone who feels up to trying it -- version 1:0.2.903+svn713-1ubuntu2~ppa3 is identical to 1:0.2.903+svn713-1ubuntu1 (which is the current Jaunty package) apart from the two-line patch. I'm in the process of upgrading to Jaunty again :).

I'll attach the debdiff, for reference.

Revision history for this message

Ole Eskildsen (ole.eskildsen) wrote on 2009-05-07:

#48

WOW! Thank you so much Andrew for that.

I downloaded and installed your patch, rebooted and tested the patch by both closing the lid (and thereby blanking the screen) and opening it again and I was still online.

Then I set my screensaver to blank the screen after a certain time, I waited till that happened, woke up the computer and bingo I was still online.

Thank you for your work, Andrew, I don't understand why the Ubuntu team hadn't done this before release of Ubuntu 9.04 and saved so many of us from grief.

For those of you who don't know where to find the patch to download (neither did I so I had to find out first), this is where Andrew's patches are:

https://launchpad.net/~andrew-aylett/+archive/ppa/+sourcepub/608672/+listing-archive-extra

NOTICE: You must select the right one for your computer. For my HP 2133, I of course chose:
xserver-xorg-video-openchrome_0.2.903+svn713-1ubuntu2~ppa3_i386.deb (181.7 KiB)

The download program asked if I wanted the patch installed to which I answered yes. I also saved a copy in case I need it again in the future.

After installation you need to reboot for the patch to take effect.

Cheers from an even happier Ubuntu 9.04 user.

Ole

Revision history for this message

Andrew Aylett (andrew-aylett) wrote on 2009-05-07:

#49

Glad you liked it :).

Regarding why we didn't get an official release, I'd imagine it's because the Openchrome driver is needed by more than just the HP2133; while the patch might fix things for us, we've no way to tell that it doesn't break things horribly for everyone else. I'd think it would be more likely to be released to Jaunty once the patch has been accepted in some form by the Openchrome devs -- as far as I can see, none of the upstream devs have commented on it.

Revision history for this message

Andrew Aylett (andrew-aylett) wrote on 2009-05-07:

#50

I think we've worked out that this is an issue with the Openchrome driver, rather than the kernel. Hopefully making the appropriate changes :).

affects:	linux (Ubuntu) → xserver-xorg-video-openchrome (Ubuntu)
Changed in xserver-xorg-video-openchrome (Ubuntu):
assignee:	Canonical Kernel Team (canonical-kernel-team) → Ubuntu Development Team (ubuntu-dev)

Revision history for this message

Andrew Aylett (andrew-aylett) wrote on 2009-05-07:

#51

Ubuntu Developers Team appears not to be correct -- launchpad tells me that no other bugs are assigned there (was picked on the basis that this team is listed in the maintainers field for the package). Apologies for the spam :(.

Changed in xserver-xorg-video-openchrome (Ubuntu):
assignee:	Ubuntu Development Team (ubuntu-dev) → nobody

Revision history for this message

Ole Eskildsen (ole.eskildsen) wrote on 2009-05-08:

#52

Not your fault, Andrew. It should be a straigh-forward matter to file a bug report in Launchpad to SOMEBODY not NOBODY. I see something lacking here in Launchpad bug tracking system.

SOMEBODY in the Ubuntu team, please, please take responsibility for this!

You wrote earlier:
"Regarding why we didn't get an official release, I'd imagine it's because the Openchrome driver is needed by more than just the HP2133; while the patch might fix things for us, we've no way to tell that it doesn't break things horribly for everyone else. I'd think it would be more likely to be released to Jaunty once the patch has been accepted in some form by the Openchrome devs -- as far as I can see, none of the upstream devs have commented on it."

I appreciate what you are saying, however, let us take a little look at the simple FACTS:

1. This bug was first reported by Ben McCann as early as 2009-02-20! - Not a recent bug.
2. This problem did NOT exist in Ubuntu 8.10. - Therefore very frustrating to experience when you install the latest version of Ubuntu.
3. Searching the Ubuntu Forum for help or a solution I discovered that many people are reporting identical or similar problems which didn't exist in U8.10 on all sorts of hardware, not just the HP2133 we own. - Should be of serious concern to the developers!
4. Ubuntu is aspiring to be a mainstream operating system, appealing to the average user in the street. However, the average user cannot be expected to handle problems like this, he would likely leave Ubuntu behind and return to his previous OS. I think I speak for most, if not all, of us in this forum when I say that we want Ubuntu to become THE premier OS! Therefore, issues, like the one at hand, need to be dealt with promptly and professionally otherwise I fear that Ubuntu cannot switch from the perception of being a "nerdy" OS to a mainstream OS.

Just my 2 bits worth. Again, thank you for your assistance, Andrew, very much appreciated.

Ole

Revision history for this message

Bartosz Kosiorek (gang65) wrote on 2009-05-08:

#53

Hi.
Please build/install according to:
https://help.ubuntu.com/community/OpenChrome

and please also delete line:
ViaLVDSDFPPower(pScrn, on);

in "src/via_lvds.c" file.
Please see for details:
http://www.openchrome.org/trac/attachment/ticket/288/openchrome_741_hp_2133.patch

This should resolve this problem

Revision history for this message

Martin Olsson (mnemo) wrote on 2009-05-08:

#54

Patches are more or less never included in Ubuntu if they have not been commited upstream. This is, as you point out, because we need to make sure it doesn't mess up things for other graphics cards etc.

Once a patch is merged officially by the openchrome devs for your bug, then please take that patch and create a debdiff out of it (follow the instructions here: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff). The debdiff should have a single changelog entry and should not contain commented out code. Finally request sponsorship for karmic (steps described here: https://wiki.ubuntu.com/SponsorshipProcess). Assigning to a team is usually not the way it works. I think the best way forward for this bug would be to talk to the upstream dev about getting a fix merged there. When I had quick look at the upstream code I noticed that the first part of your patch (moving the F in the bitmask leftward) was actually merged in the middle of April: http://www.openchrome.org/trac/changeset/746
Is that change _alone_ sufficient to fix your issue you do you really need upstream to drop that call to close as well?

Stable release updates (SRU) are also possible in some cases but those require extensive testing to ensure that regressions have a very very low probability. You can read about this process: https://wiki.ubuntu.com/StableReleaseUpdates

In general if you're interested in learning how to package, bugfix and test X.org stuff properly, join us at #ubuntu-x on FreeNode IRC (we could definitely use some more OpenChrome people to help out).

Revision history for this message

Juhana Karihuhta (juhana-karihuhta) wrote on 2009-05-10:

#55

It also needed that "//ViaLVDSDFPPower(pScrn, on);" part. I compiled first with plain 747 revision, that one which has that patch which Martin described, but it did not fix the problem. ViaLVDSDFPPower(pScrn,on); in via_lvds.c needs to be commented out, and then it works.

Bryce Harrington (bryce) on 2009-05-17

description:

updated

Revision history for this message

Arjen Raateland (arjen-raateland) wrote on 2009-05-23:

#56

I have experienced all the problems with the wireless connection on my HP2133 as described in this thread since installing 9.04 (from scratch).

Following the advice in this thread, I have installed the patch (xserver-xorg-video-openchrome_0.2.903+svn713-1ubuntu2~ppa3_i386.deb), but I cannot find the src/via_lvds.c file. I've searched for via_lvds.c using sudo nautilus, I never installed openchrome as a screen driver, and adding the line driver "vesa" to xorg.conf causes malfunctioning of the display even before logon. (I booted from a Live-USB stick to put this right again.)

My HP2133 runs Vista Home Basic & 9.04, it has 2GB of RAM, a 160 GB disk with several partitions, 1024x600 screen resolution and the wireless card has the Broadcom 4312 chip. WLAN used to be ok on 8.04 and it also works in Vista (came with the machine, now dual-booting).

Since a while the screen has developed a new feature, viz. upon minimizing a window, it 'zooms' to the edge displaying black wire-frames diminishing in size. I didn't set this, it just started doing it. Maybe this gives away which screen driver is actually in use.

If output from particular commands is needed to describe the situation, I think I can manage that. I just don't know what information is needed.

So, is it normal that I don't have the via_lvds.c file?
Do I need to install openchrome to have this file?
(The patch ran fine, though, as far as I know. No experience with installing patches here, though. Hey presto, it just ran and seemed to do what it is supposed to!)

Revision history for this message

Martin Olsson (mnemo) wrote on 2009-05-23:

#57

@Arjen, patches are "descriptions of changes to source code" and they are not meant to be installed by end users. Normally, users do not have any source code installed and even if you change the source code itself nothing happens because it the binary version of the driver that is being used (this is because the driver is written in C and not in for example Python where the code is executed directly sort of). The idea is that developers patch the driver and then an proper binary update is issued (usually you get the new version in the next version of Ubuntu except for really nasty bugs).

Anyway, you can install the source code yourself and then apply the patch to the make the required changes and then compile the driver to create an installable DEB. For example if you want to install the source code for a package called PACKAGE_NAME, you'd need to:

mkdir my_dir
cd my_dir
apt-get source PACKAGE_NAME
cd some_dir_which_was_created
patch -p0 < ~/path/to/changes.patch
debuild -us -uc -b
cd ..
sudo dpkg -i some_binary_installable.deb

It's the patch command that modifies the code and it's the debuild command that converts the code into an installable DEB update. However, you can't run these commands blindly you need to change them a little bit to suite whatever patch you want to try (some patches requires "patch -p1" instead of "patch -p0" for example). Also, once you do this you will be running an unsupported version of Ubuntu and you might experience new bugs etc.

The Ubuntu wiki has lots of good links of how to compile code, build DEB packages, work with patches etc but it's a lot to learn. This stuff is meant for developers who want to contribute to Ubuntu.

Revision history for this message

Ole Eskildsen (ole.eskildsen) wrote on 2009-05-23:

#58

@ Arjen

You do not need to fiddle with the source code, as Martin is trying to tell you, that is for the developers.

This is what you need to do:

Go to this location to find the compited patch just ready to install:

https://launchpad.net/~andrew-aylett/+archive/ppa/+sourcepub/608672/+listing-archive-extra

Select the right one for your computer under the heading "Package Files". For my HP 2133, I of course chose:
xserver-xorg-video-openchrome_0.2.903+svn713-1ubuntu2~ppa3_i386.deb (181.7 KiB)

The download program asked if I wanted the patch installed to which I answered yes.

After installation you need to reboot for the patch to take effect.

That should hopefully work, it certainly did on my HP2133.

Haelsninger fraan down-under,

Ole

Revision history for this message

Arjen Raateland (arjen-raateland) wrote on 2009-05-24:

#59

There is a new STA driver on a Broadcom page: http://www.broadcom.com/support/802.11/linux_sta.php
It would be nice to try that one. Maybe it solves everything ...

The version I have installed (through the hardware driver widget on the menu) is 5.10.79.10.
There are instructions for making? (=compiling?) a new driver that can be installed, but it is way over my head, unfortunately. I might break the whole installation.

Like I wrote earlier, I have installed the patched driver, from the deb file, the same as Ole used. I just called it by the wrong name, a patch.

It just didn't help. The connection problem still there. The wireless connection only stays up if I don't allow the machine to 'save power', e.g. by blanking the screen or going to sleep.

If somebody is interested to see diagnostic output from my machine, I'm sure I can manage to post it as long as I know which command and which switches to use.

Revision history for this message

Arjen Raateland (arjen-raateland) wrote on 2009-05-24:

#60

BTW, I also installed the new firmware for the wireless network card with b43.fw-cutter as indicated in the Hardware drivers item on the same menu as where the STA driver can be found after temporarily deactivating STA. I didn't notice any problems with updating the firmware, but it didn't do away with the problem of the wireless connection being dropped, either. I can't remember seeing any information as to what the firmware update is supposed to correct.

Revision history for this message

Ole Eskildsen (ole.eskildsen) wrote on 2009-05-24:

#61

@ Arjen

I must confess I don't understand why you keep having problems if you have carefully followed the instructions further up.

The problem seems to be that the hardware drivers for the monitor and the wireless networking, somehow interfere with one another and also that the wireless driver doesn't work when first installed. Therefore what has to be done is:

1. Install and activate proprietary STA wireless driver, then reboot.
2. Apply the patch to the chrome screen driver, then reboot.

If this doesn't work then I don't know what to suggest, as this has worked for the rest of us. If somebody else can come up with some suggestions for you to try, then that would be good. If you switch from the chrome screen driver to the vesa then you should also be able to get it to work. Alternatively, simply change your screen saver and power setting to not blank the screen, that should also keep it from disconnecting the wireless network.

AS it also is a possibility that there is something in the instructions above which you don't quite understand and therefore they don't get carried out correctly. If you have a friend who has experience with Linux who is willing to help you, then it is possible tthat he understand the instructions and can carry them out. Hmmm!

Good luck with it,

Ole

Revision history for this message

Arjen Raateland (arjen-raateland) wrote on 2009-05-24:

#62

1. I'm unsure of what video driver my installation uses.

2. Today I figured I'd reinstall the patched driver, and then from the Firefox download screen I noticed that yesterday I had downloaded (& installed) http://launchpadlibrarian.net/26403054/xserver-xorg-video-via_0.2.903%2Bsvn713-1ubuntu2%7Eppa3_i386.deb
Judging from the name (VIA) it is not an openchrome driver.

3. Nevertheless, Synaptic showed that I already had an openchrome driver installed.

4. So next I downloaded & installed http://launchpadlibrarian.net/26403053/xserver-xorg-video-openchrome_0.2.903%2Bsvn713-1ubuntu2%7Eppa3_i386.deb.

5. Changed power save settings and Rebooted.

6. Closed the lid and reopened. Screen comes back on and Hey Presto! The WLAN connection is still up!

THANKS!

Two questions left:
a. How to check which video driver is actually in use?

b. Any guess when we could expect the latest Broadcom driver for the 4312 chip to become available for installation through 'get-apt'?

Revision history for this message

Martin Olsson (mnemo) wrote on 2009-05-25:

#63

A long long time ago, there used to be an old driver for VIA cards in the package xserver-xorg-video-via but that driver was really bad so the OpenChrome project was started to replace it sort of. There is no driver at all in the xserver-xorg-video-via package... that package is just used to make sure that old users are transitioned from the -via driver to the -openchrome driver when upgrading.

You can tell which driver you are using by looking at the file /var/log/Xorg.0.log (which usually contains both the driver name and a version number but note that if you apply a patch it will still show the same version number of course unless the patch actually changed the version number which is very rarely the case). If the -openchrome driver is in use you will see many lines prefixed with "CHROME(0): " in this log file, and for example if the vesa driver is used you will see many lines prefixed with "VESA(0):" or something like that.

I have no idea when the new wireless driver will ship but I assume it's a kernel driver so you should ask the Ubuntu kernel team about it. If the driver update is necessary to fix the bug then I suggest you open a bug against the kernel (package "linux") because otherwise there is a good chance that the kernel team will not see this bug at all.

Revision history for this message

Ole Eskildsen (ole.eskildsen) wrote on 2009-05-25:

#64

Hi Martin,

Thank you for your reply. Unfortunately, I, who am not a systems programmer, gets a bit confused when I display a log file like /var/log/Xorg.0.log!
What exactly do I look for when trying to determine which verson of openchrome I have installed?

The situation is, of course, that when I installed Ubuntu 9.04 I installed the current openchrome video driver, whichever one that is. It worked except there was a problem which someone the published a patch for. As you indicate, a patch is not a new driver incl. driver version number, but merely a few instructions in the existing installed driver which get changed. That also introduces some real risks in that, the changed driver may fix one problem but it could potentially create new problems which nobody have yet discovered. But I (and others) trusted the programmer and applied the patch and it did work.

Great so far, but what happens when we get the next version of Linux? We non-tech guys haven't got a clue whether the driver we patched is part of the new Linux version. If it is and has not been fixed, then we are back to the same situation again.

Therefore you make a good suggestion, that we report a bug to the kernel team! BUT we don't even know whether the driver is part of the kernel or how to find out and, if it is, how to address the bug to the kernel team!

So, I have got down on my knees now and I beg you to help us find the answers to those questions and help us to report it to the kernel team if that is what should be done.

Thank you in advance for your help, and thank you for your help so far.

Cheers,

Ole down-under

Revision history for this message

Martin Olsson (mnemo) wrote on 2009-05-25:

#65

I've marked this bug as affecting the Ubuntu kernel as well since you need that updated wireless driver for the bug to go away.

As for the log reading question... This is an example of a xorg.log where the -openchrome driver is in use, you can tell because it contains "CHROME(0):" several times:
http://launchpadlibrarian.net/26002104/Xorg.0.log
On the other hand, this (below) is an example of a xorg.log where the VESA driver is in use, you can tell because it contains "VESA(0):" several times:
http://launchpadlibrarian.net/24858284/Xorg.0.log.old

Revision history for this message

Arjen Raateland (arjen-raateland) wrote on 2009-05-25:

#66

Martin,
Didn't you mean to write 'you need that updated VIDEO driver for the bug to go away'?

I only mentioned the wireless driver, because Broadcom has a new version available. It is not generally available as an installation package for Ubuntu and it may not affect the bug of this thread at all, or then perhaps it does. Who would know? It would be nice to try, though. Broadcom wouldn't make a new version, if there weren't anything to improve or correct, would they?

Bartosz Kosiorek (gang65) on 2009-05-28

Changed in linux (Ubuntu):
assignee:	nobody → Ubuntu Kernel Network Team (ubuntu-kernel-network)

Revision history for this message

Alexander Fomichev (alfonder) wrote on 2009-05-28:

#67

When will the correct OpenChrome driver be added to the official Ubuntu repositories? Should we wait till next release? Or will it be available in jaunty-updates soon?

Revision history for this message

Bartosz Kosiorek (gang65) wrote on 2009-05-29:

#68

We don't know, if this bug exist in Openchrome. This patch is some kind of the workaround. We don't know why after change graphic registers, the wireless stops working.

We suppose for example PCI bus corruption.
Please see:
http://wiki.openchrome.org/pipermail/openchrome-devel/2008-November/000135.html

or

http://lists.berlios.de/pipermail/bcm43xx-dev/2008-November/008319.html

Bartosz Kosiorek (gang65) on 2009-06-01

Changed in linux (Ubuntu):
status:	New → Confirmed
summary:	- [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless + [P4M900] [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver

Revision history for this message

Bartosz Kosiorek (gang65) wrote on 2009-06-07:

#69

I think this is not openchrome bug.
Please submit this bug to linux kernel, at webpage:
http://bugzilla.kernel.org

After submit this bug please type the URL to this bug.

Revision history for this message

Rafał Miłecki (zajec5) wrote on 2009-07-07:

#70

To make it clear:
1) This was bug in openChrome driver
2) We were touching reserved bits of 0x2A register (bug)
3) Bug didn't exist in last release 0.2.903 and we belive it doesn't exist in current trunk (actually from revision 746 == 25.04.2009)

Great explaination was provided in openChrome's ticket's comment: http://www.openchrome.org/trac/ticket/288#comment:24

Revision history for this message

Bartosz Kosiorek (gang65) wrote on 2009-07-09:

#71

openchrome-switch-on-lvds-pads-only-for-active-channels.patch Edit (716 bytes, text/plain)

Please apply this patch.
Does it help?

Revision history for this message

Leann Ogasawara (leannogasawara) wrote on 2009-07-10:

#72

Closing linux task per https://edge.launchpad.net/ubuntu/+source/linux/+bug/331952/comments/70

Changed in linux (Ubuntu):
status:	Confirmed → Invalid

Revision history for this message

Bartosz Kosiorek (gang65) wrote on 2009-07-17:

#73

Hi.
Please check the latest openchrome revision.
The problem can be resolved at openchrome 758 revision.

The detail build instruction is available at:
https://help.ubuntu.com/community/OpenChrome

Revision history for this message

damianChapman (cosmoschapman) wrote on 2009-07-17: Re: [Bug 331952] Re: [P4M900] [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver

#74

Download full text (10.6 KiB)

Thank you. I will.

On Fri, Jul 17, 2009 at 5:51 AM, Bartosz<email address hidden> wrote:
> Hi.
> Please check the latest openchrome revision.
> The problem can be resolved at openchrome 758 revision.
>
> The detail build instruction is available at:
> https://help.ubuntu.com/community/OpenChrome
>
> --
> [P4M900] [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver
> https://bugs.launchpad.net/bugs/331952
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in openchrome: Confirmed
> Status in “linux” package in Ubuntu: Invalid
> Status in “xserver-xorg-video-openchrome” package in Ubuntu: Triaged
>
> Bug description:
> Wireless with the BCM4312 adapter connects, runs several minutes, and disconnects unexpectedly with Ubuntu Jaunty (9.04) Alpha 4 on an HP 2133 MiniNote laptop. The same laptop runs wireless flawlessly under Ubuntu Intrepid (8.10). I only have wireless issues under Jaunty. Once it has disconnected, I'm unable to reestablish a connection w/o rebooting.
>
> Note that the laptop is configured to dual boot between Intrepid and Jaunty so its easy to run A/B experiments between the two releases.
>
> All this takes to reproduce is to boot Jaunty with the B43 driver, bring up wireless, and then wait 5 or 10 minutes. I've hit this at home, with WEP encryption, and at work on an open guest network so its not the AP. The wireless works fine for several minutes, disconnects, and then won't reconnect
>
> I'm running the latest Jaunty (Xubuntu) packages as of this morning (2/20/09) and the problem still occurs. I don't know if this is a network-manager issue or a driver problem. Here are some chunks of data to start the triage
>
> Uname:
>
> Linux version 2.6.28-7-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-3ubuntu2) ) #20-Ubuntu SMP Mon Feb 9 15:43:21 UTC 2009 (Ubuntu 2.6.28-7.20-generic)
>
>
> lspci on the BCM4312:
>
> 02:00.0 0280: 14e4:4312 (rev 02)
> Subsystem: 103c:1370
> 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 at fdffc000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: <access denied>
> Kernel driver in use: b43-pci-bridge
> Kernel modules: wl, ssb
>
>
> kern.log:
>
> Feb 17 08:18:23 Polaris kernel: [ 2233.000045] b43-phy0: Radio hardware status changed to DISABLED
> Feb 17 08:18:27 Polaris kernel: [ 2237.756070] wlan0: No ProbeResp from current AP 00:1f:90:e0:19:75 - assume out of range
> Feb 17 08:18:27 Polaris kernel: [ 2237.904035] b43-phy0: Radio turned on by software
> Feb 17 08:18:27 Polaris kernel: [ 2237.904047] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on.
> Feb 17 08:18:28 Polaris kernel: [ 2238.677784] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 1
> Feb 17 08:18:28 Polaris kernel: [ 2238.677879] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 1
> Feb 17 08:18:28 Polaris ker...

Thank you. I will.

On Fri, Jul 17, 2009 at 5:51 AM, Bartosz<gang65@poczta.onet.pl> wrote:
> Hi.
> Please check the latest openchrome revision.
> The problem can be resolved at openchrome 758 revision.
>
> The detail build instruction is available at:
> https://help.ubuntu.com/community/OpenChrome
>
> --
> [P4M900] [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver
> https://bugs.launchpad.net/bugs/331952
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in openchrome: Confirmed
> Status in “linux” package in Ubuntu: Invalid
> Status in “xserver-xorg-video-openchrome” package in Ubuntu: Triaged
>
> Bug description:
> Wireless with the BCM4312 adapter connects, runs several minutes, and disconnects unexpectedly with Ubuntu Jaunty (9.04) Alpha 4 on an HP 2133 MiniNote laptop.  The same laptop runs wireless flawlessly under Ubuntu Intrepid (8.10). I only have wireless issues under Jaunty. Once it has disconnected, I'm unable to reestablish a connection w/o rebooting.
>
> Note that the laptop is configured to dual boot between Intrepid and Jaunty so its easy to run A/B experiments between the two releases.
>
> All this takes to reproduce is to boot Jaunty with the B43 driver, bring up wireless, and then wait 5 or 10 minutes. I've hit this at home, with WEP encryption, and at work on an open guest network so its not the AP. The wireless works fine for several minutes, disconnects, and then won't reconnect
>
> I'm running the latest Jaunty (Xubuntu) packages as of this morning (2/20/09) and the problem still occurs. I don't know if this is a network-manager issue or a driver problem. Here are some chunks of data to start the triage
>
> Uname:
>
> Linux version 2.6.28-7-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-3ubuntu2) ) #20-Ubuntu SMP Mon Feb 9 15:43:21 UTC 2009 (Ubuntu 2.6.28-7.20-generic)
>
>
> lspci on the BCM4312:
>
> 02:00.0 0280: 14e4:4312 (rev 02)
>    Subsystem: 103c:1370
>    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 at fdffc000 (64-bit, non-prefetchable) [size=16K]
>    Capabilities: <access denied>
>    Kernel driver in use: b43-pci-bridge
>    Kernel modules: wl, ssb
>
>
> kern.log:
>
> Feb 17 08:18:23 Polaris kernel: [ 2233.000045] b43-phy0: Radio hardware status changed to DISABLED
> Feb 17 08:18:27 Polaris kernel: [ 2237.756070] wlan0: No ProbeResp from current AP 00:1f:90:e0:19:75 - assume out of range
> Feb 17 08:18:27 Polaris kernel: [ 2237.904035] b43-phy0: Radio turned on by software
> Feb 17 08:18:27 Polaris kernel: [ 2237.904047] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on.
> Feb 17 08:18:28 Polaris kernel: [ 2238.677784] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 1
> Feb 17 08:18:28 Polaris kernel: [ 2238.677879] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 1
> Feb 17 08:18:28 Polaris kernel: [ 2238.876059] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 2
> Feb 17 08:18:28 Polaris kernel: [ 2239.076064] wlan0: direct probe to AP 00:1f:90:e0:19:75 try 3
> Feb 17 08:18:29 Polaris kernel: [ 2239.276063] wlan0: direct probe to AP 00:1f:90:e0:19:75 timed out
> Feb 17 08:22:56 Polaris kernel: [ 2507.004202] b43-phy0 ERROR: DMA RX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.164055] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.324077] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.484076] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.644225] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.804079] b43-phy0 ERROR: DMA TX reset timed out
> Feb 17 08:22:57 Polaris kernel: [ 2507.804776] ssb: Failed to switch to core 0
> Feb 17 08:23:08 Polaris kernel: [ 2518.277353] input: b43-phy0 as /devices/virtual/input/input13
> Feb 17 08:23:08 Polaris kernel: [ 2518.328060] ssb: Backplane Revision 0xF0000000
> Feb 17 08:23:08 Polaris kernel: [ 2518.328127] ------------[ cut here ]------------
> Feb 17 08:23:08 Polaris kernel: [ 2518.328139] WARNING: at /build/buildd/linux-2.6.28/drivers/ssb/main.c:1042 ssb_tmslow_reject_bitmask+0x59/0x90 [ssb]()
> Feb 17 08:23:08 Polaris kernel: [ 2518.328152] Modules linked in: usbhid rfkill_input via drm bridge stp bnep e_powersaver ppdev parport_pc lp parport joydev snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse pcspkr snd_timer snd_seq_device serio_raw snd i2c_viapro soundcore snd_page_alloc uvcvideo compat_ioctl32 videodev v4l1_compat arc4 ecb leds_hp_disk video output b43 lis3lv02d mac80211 cfg80211 led_class input_polldev shpchp via_agp agpgart tg3 ehci_hcd uhci_hcd ssb fbcon tileblit font bitblit softcursor fuse
> Feb 17 08:23:08 Polaris kernel: [ 2518.328314] Pid: 3227, comm: NetworkManager Not tainted 2.6.28-7-generic #20-Ubuntu
> Feb 17 08:23:08 Polaris kernel: [ 2518.328324] Call Trace:
> Feb 17 08:23:08 Polaris kernel: [ 2518.328346]  [<c04e2911>] ? printk+0x18/0x1f
> Feb 17 08:23:08 Polaris kernel: [ 2518.328363]  [<c0133a64>] warn_on_slowpath+0x54/0x80
> Feb 17 08:23:08 Polaris kernel: [ 2518.328399]  [<f7cafef9>] ssb_tmslow_reject_bitmask+0x59/0x90 [ssb]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328431]  [<f7caff44>] ssb_device_is_enabled+0x14/0x40 [ssb]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328475]  [<f7ffd387>] b43_wireless_core_init+0x37/0x520 [b43]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328520]  [<f800e9a2>] ? b43_rfkill_init+0x142/0x1d0 [b43]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328559]  [<f7ffea17>] b43_op_start+0x147/0x1a0 [b43]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328630]  [<f7e3f10a>] ieee80211_open+0x32a/0x830 [mac80211]
> Feb 17 08:23:08 Polaris kernel: [ 2518.328651]  [<c014c88a>] ? hrtimer_try_to_cancel+0x3a/0x90
> Feb 17 08:23:08 Polaris kernel: [ 2518.328669]  [<c04e3c99>] ? schedule_hrtimeout_range+0xe9/0x150
> Feb 17 08:23:08 Polaris kernel: [ 2518.328687]  [<c0417312>] dev_open+0xa2/0xe0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328702]  [<c04e4d31>] ? _spin_unlock_bh+0x11/0x20
> Feb 17 08:23:08 Polaris kernel: [ 2518.328716]  [<c041674a>] ? dev_set_rx_mode+0x2a/0x40
> Feb 17 08:23:08 Polaris kernel: [ 2518.328730]  [<c04169c1>] dev_change_flags+0x131/0x1c0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328749]  [<c041f80d>] do_setlink+0x1ed/0x3a0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328766]  [<c0431103>] ? nla_reserve+0x43/0x60
> Feb 17 08:23:08 Polaris kernel: [ 2518.328781]  [<c041f10f>] ? rtnl_fill_ifinfo+0x2cf/0x3b0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328797]  [<c041faa1>] rtnl_setlink+0xe1/0x120
> Feb 17 08:23:08 Polaris kernel: [ 2518.328813]  [<c0430270>] ? netlink_dump_start+0x130/0x170
> Feb 17 08:23:08 Polaris kernel: [ 2518.328828]  [<c041f9c0>] ? rtnl_setlink+0x0/0x120
> Feb 17 08:23:08 Polaris kernel: [ 2518.328843]  [<c041ebf5>] rtnetlink_rcv_msg+0x165/0x200
> Feb 17 08:23:08 Polaris kernel: [ 2518.328858]  [<c041f1f0>] ? rtnl_dump_ifinfo+0x0/0xa0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328874]  [<c041ea90>] ? rtnetlink_rcv_msg+0x0/0x200
> Feb 17 08:23:08 Polaris kernel: [ 2518.328888]  [<c0430116>] netlink_rcv_skb+0x76/0xa0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328903]  [<c041ea7c>] rtnetlink_rcv+0x1c/0x30
> Feb 17 08:23:08 Polaris kernel: [ 2518.328916]  [<c042f89d>] netlink_unicast+0x25d/0x290
> Feb 17 08:23:08 Polaris kernel: [ 2518.328931]  [<c043091b>] netlink_sendmsg+0x1cb/0x2b0
> Feb 17 08:23:08 Polaris kernel: [ 2518.328946]  [<c040921a>] sock_sendmsg+0xea/0x110
> Feb 17 08:23:08 Polaris kernel: [ 2518.328964]  [<c0298b40>] ? apparmor_socket_recvmsg+0x10/0x20
> Feb 17 08:23:08 Polaris kernel: [ 2518.328981]  [<c0148bf0>] ? autoremove_wake_function+0x0/0x50
> Feb 17 08:23:08 Polaris kernel: [ 2518.328996]  [<c0148bf0>] ? autoremove_wake_function+0x0/0x50
> Feb 17 08:23:08 Polaris kernel: [ 2518.329013]  [<c02bdb65>] ? copy_from_user+0x35/0x130
> Feb 17 08:23:08 Polaris kernel: [ 2518.329031]  [<c04106f0>] ? verify_iovec+0x30/0xb0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329044]  [<c0409351>] sys_sendmsg+0x111/0x230
> Feb 17 08:23:08 Polaris kernel: [ 2518.329057]  [<c0409574>] ? sys_sendto+0xb4/0xd0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329070]  [<c041518d>] ? __dev_get_by_name+0x7d/0xa0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329084]  [<c02bdc96>] ? copy_to_user+0x36/0x120
> Feb 17 08:23:08 Polaris kernel: [ 2518.329103]  [<c0407410>] ? sock_destroy_inode+0x10/0x20
> Feb 17 08:23:08 Polaris kernel: [ 2518.329122]  [<c01c985a>] ? destroy_inode+0x2a/0x50
> Feb 17 08:23:08 Polaris kernel: [ 2518.329137]  [<c01ca192>] ? generic_forget_inode+0x152/0x170
> Feb 17 08:23:08 Polaris kernel: [ 2518.329152]  [<c0409b05>] sys_socketcall+0xd5/0x2b0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329173]  [<c01b50a9>] ? filp_close+0x49/0x70
> Feb 17 08:23:08 Polaris kernel: [ 2518.329188]  [<c01b514a>] ? sys_close+0x7a/0xc0
> Feb 17 08:23:08 Polaris kernel: [ 2518.329203]  [<c0103f6b>] sysenter_do_call+0x12/0x2f
> Feb 17 08:23:08 Polaris kernel: [ 2518.329214] ---[ end trace 81079ab9ec490f87 ]---
> Feb 17 08:23:09 Polaris kernel: [ 2519.508098] b43-phy0 ERROR: Microcode not responding
> Feb 17 08:23:09 Polaris kernel: [ 2519.508117] b43-phy0 ERROR: You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the latest firmware (version 4).
>
> I considered loading a different version of the B43 firmware as suggested but the firmware stored under /lib/firmware/b43 is identical between Ubuntu Intrepid and Jaunty. (I binary compared all the files and verified each uses the same firmware version (broadcom-wl-4.150.10.5.tar.bz2). The install_bcm43xx_firmware.sh scripts in Intrepid and Jaunty are also identical.
>
> So, I don't think this is a firmware issue despite the fact the driver wants new firmware. This firmware is fine in Intrepid. I think something else in the b43, wl, or ssb driver has regressed. Or, perhaps there's been a regression in network-manager.
>
>
> I'm happy to help any way necessary to find this bug.
>
> -Ben McCann
>
> == Regression details ==
> Discovered in version: Jaunty Alpha 4
> Last known good version: Intrepid 8.10
>
> [lspci]
> 00:00.0 Host bridge: VIA Technologies, Inc. CN896/VN896/P4M900 Host Bridge
>        Subsystem: Hewlett-Packard Company Device 3030
> 01:00.0 VGA compatible controller: VIA Technologies, Inc. CN896/VN896/P4M900 [Chrome 9 HC] (rev 01)
>        Subsystem: Hewlett-Packard Company Device 3030
>
>

Revision history for this message

Vikram Dhillon (dhillon-v10) wrote on 2009-07-17: Re: [Bug 331952] Re: [P4M900] [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver

#75

Bartosz ਨੇ ਲਿਖਿਆ:
> Hi.
> Please check the latest openchrome revision.
> The problem can be resolved at openchrome 758 revision.
>
> The detail build instruction is available at:
> https://help.ubuntu.com/community/OpenChrome
>
>
Thanks for the info...

Bug Watch Updater (bug-watch-updater) on 2009-07-18

Changed in openchrome:
status:	Confirmed → Fix Released

Revision history for this message

Rafał Miłecki (zajec5) wrote on 2009-07-18:

#76

We were wrong first about resolving this bug.
Rev 746 fixed some obvious mistake in code, but it still didn't fix problem.
Rev 758 contains real fix for that (like Bartosz mentioned).
Sorry for my previous incorrect info.

Revision history for this message

Bartosz Kosiorek (gang65) wrote on 2009-08-13:

#77

Fixed in Karmic Koala in openchrome 1:0.2.903+svn758-0ubuntu1

Changed in xserver-xorg-video-openchrome (Ubuntu):
assignee:	nobody → Bartosz (gang65)
status:	Triaged → Fix Released

Affects		Status	Importance	Assigned to
	openchrome	Fix Released	Unknown	openchrome-trac #288
	linux (Ubuntu)	Invalid	Undecided	Ubuntu Kernel Network Team
Nominated for Jaunty by Andrew Aylett
Nominated for Karmic by Andrew Aylett
	xserver-xorg-video-openchrome (Ubuntu)	Fix Released	Medium	Bartosz Kosiorek
Nominated for Jaunty by Andrew Aylett
Nominated for Karmic by Andrew Aylett

Ubuntu
xserver-xorg-video-openchrome package

[P4M900] [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver

Bug Description

Duplicates of this bug

Other bug subscribers

Patches

Bug attachments

Remote bug watches

Ubuntuxserver-xorg-video-openchrome package

[P4M900] [HP 2133 MiniNote laptop] Unexpected and unrecoverable wireless disconnect with B43 driver

Bug Description

Duplicates of this bug

Other bug subscribers

Patches

Bug attachments

Remote bug watches

Ubuntu
xserver-xorg-video-openchrome package