computer frozen

Bug #194523 reported by moa3333 on 2008-02-22
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Undecided
Unassigned

Bug Description

package: linux-image-2.6-amd64-generic

Linux ubuntu 2.6.24-11-generic #1 SMP Fri Feb 29 21:26:31 UTC 2008 x86_64 GNU/Linux

From time to time (every 10 to 100 minutes) the computer is frozen with no reason. It dosen't matter what i do when it freezes. With no reason, the image is frozen, the mouse is not responding, and i can't switch to any terminals either. It hapends since after updating to the latest alpha a few months ago.

hints: the kernel, a module of the kernel (other than nvidia, ssb or b43), other reasons?

moa3333 (moa3333) wrote :
Download full text (3.4 KiB)

ifconfig:

wlan0_rename Link encap:Ethernet HWaddr 00:14:a5:f9:95:53
          inet adr:192.168.1.20 Bcast:192.168.1.255 Masque:255.255.255.0
          adr inet6: fe80::214:a5ff:fef9:9553/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          Packets reçus:9605 erreurs:0 :0 overruns:0 frame:0
          TX packets:7878 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:11857825 (11.3 MB) Octets transmis:1087010 (1.0 MB)

iwconfig:

wlan0_rename IEEE 802.11g ESSID:"net22"
          Mode:Managed Frequency:2.412 GHz Access Point: 00:16:B6:D9:01:86
          Bit Rate=1 Mb/s Tx-Power=27 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2346 B
          Encryption key:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx [3]
          Link Quality=75/100 Signal level=-57 dBm Noise level=-63 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

# dmesg | grep b43
[ 77.604665] b43-phy0: Broadcom 4311 WLAN found
[ 136.030067] input: b43-phy0 as /devices/virtual/input/input12
[ 137.446689] Registered led device: b43-phy0:tx
[ 137.446707] Registered led device: b43-phy0:rx
[ 137.446724] Registered led device: b43-phy0:radio

# lsmod | grep b43
b43 126760 0
rfkill 10128 3 rfkill_input,b43
mac80211 192532 1 b43
led_class 7176 1 b43
input_polldev 6928 1 b43
ssb 37252 2 b43,ohci_hcd

# modinfo ssb && modinfo b43
filename: /lib/modules/2.6.24-8-generic/kernel/drivers/ssb/ssb.ko
license: GPL
description: Sonics Silicon Backplane driver
srcversion: 296CB75C03596C72291230A
alias: pci:v000014E4d00004325sv*sd*bc*sc*i*
alias: pci:v000014E4d00004324sv*sd*bc*sc*i*
alias: pci:v000014E4d00004321sv*sd*bc*sc*i*
alias: pci:v000014E4d00004320sv*sd*bc*sc*i*
alias: pci:v000014E4d00004319sv*sd*bc*sc*i*
alias: pci:v000014E4d00004318sv*sd*bc*sc*i*
alias: pci:v000014E4d00004312sv*sd*bc*sc*i*
alias: pci:v000014E4d00004311sv*sd*bc*sc*i*
alias: pci:v000014E4d00004307sv*sd*bc*sc*i*
alias: pci:v000014E4d00004301sv*sd*bc*sc*i*
depends:
vermagic: 2.6.24-8-generic SMP mod_unload
filename: /lib/modules/2.6.24-8-generic/kernel/drivers/net/wireless/b43/b43.ko
license: GPL
author: Michael Buesch
author: Stefano Brivio
author: Martin Langer
description: Broadcom B43 wireless driver
srcversion: D291278BDAFD171BF373380
alias: ssb:v4243id0812rev0A*
alias: ssb:v4243id0812rev09*
alias: ssb:v4243id0812rev07*
alias: ssb:v4243id0812rev06*
alias: ssb:v4243id0812rev05*
depends: mac80211,ssb,input-polldev,led-class,rfkill
vermagic: 2.6.24-8-generic SMP mod_unload
parm: pio:enable(1) / disable(0) PIO mode (int)
parm: bad_frames_preempt:enable(1) / disable(0) Bad Frames Preemption (int)
parm: short_retry:Short-Retry-Limit (...

Read more...

Gert Kulyk (gkulyk) wrote :

>Other changes i made is installing the b43 proprietary driver for my
>wifi card (instead of the old ndiswrapper driver) - i do'nt know if it is because of this driver or not.
>http://linuxwireless.org/en/users/Drivers/b43

What did you exactly do? Did you try to compile the driver for yourself (what I expect since you have the wlan0_rename device) or are you using the one provided by the new hardy kernel? A driver from upstream git compat-linux-wireless-2.6 may cause issues. To get b43 driver to work in hardy you simply need to install b43-fwcutter which should pull in the needed firmware.

moa3333 (moa3333) wrote :

Yes, i compiled the latest version for myself. I'll install the b43-fwcutter package now to see the diference.

I've put noacpi noapic to the kernel and it still frozes. I've installed the latest kernel update and recent updates and it still do the same but with a diference: i think it is less offten now. My CPU and all temprature mesures show a temprature between 50 and 60 degrees C all the time. So i supose it is not an overheat.

moa3333 (moa3333) wrote :

I have reinstalled b43-fwcutter and still have the wlan0_rename. Should i reinstall the b43 driver also?

Gert Kulyk (gkulyk) wrote :

You should _uninstall_ the compat-linux-wireless drivers, not reinstall them. Please get rid of these drivers before you do anything else.

Hardy kernel already includes the b43 and b43legacy drivers, there is no need for recompiling them from the package prepared by linuxwireless.org. The sources on the linuxwireless.org-site are meant for people who are running a pre-2.4.24 kernel and/or are driver-developers, they are updated frequently so one version may work, another not. If you are not a driver-developer (and I'm rather sure you are not;-)), you should not use them on hardy-kernel.
The Versions in 2.6.24 are needing other firmware-version than the ones upstream, so b43-fwcutter from hardy cannot help you in getting to work the compat-linux-wireless drivers, only the ones included in hardy default kernel.
b43-fwcutter package is only for installing the needed firmware, it should call /usr/share/b43-fwcutter/install_bcm43xx_firmware.sh on installation, which results in two new directories in /lib/firmware: b43 and b43legacy. If you've installed the package but there are no such directories in the given place, you'll need to run the script as root manually.

moa3333 (moa3333) wrote :

Actually i have installed the version 011 of b43-fwcutter, not the driver. I don't remember having installed any compat-linux-wireless driver. Now i have erased all firmware files from /var/firmware/b43* Then i have installed b43-fwcutter official package (version 008 it says) and extracted the correct firmware. Before extracting this firmware the wifi card was not working at all. After installing it it works again, but its name has the "_rename". Right now it seems i have the good firmware. What do you mean exactly by "_uninstall_ the compat-linux-wireless driver"?

# iwconfig
lo no wireless extensions.

eth1 no wireless extensions.

eth0 no wireless extensions.

wlan0_rename IEEE 802.11g ESSID:"net22"
          Mode:Managed Frequency:2.412 GHz Access Point: 00:16:B6:D9:01:86
          Bit Rate=1 Mb/s Tx-Power=27 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2346 B
          Encryption key:XXXXXXXXXXXXXXXXXXXXXXXX [3]
          Link Quality=70/100 Signal level=-62 dBm Noise level=-61 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Gert Kulyk (gkulyk) wrote :

>Actually i have installed the version 011 of b43-fwcutter [...]
>What do you mean exactly by "_uninstall_ the compat-linux-wireless driver"?

Ok, in that case it's a misunderstanding. When I asked you if you did install the driver from linuxwireless.org I thought about the kernel-driver (that is linux-wireless-compat and that is not really not recommended), not about the b43-fwcutter-tool.

Does your card work right now? The wlan0_rename issue is of minor importance, though this should no longer happen in hardy. You did a dist-upgrade, right? Maybe there are some left-over config-files from an earlier install, which may cause something like that. If your card works right now, you should not care about it.

moa3333 (moa3333) wrote :

Yes, my card works now as well as it was working with the firmwares b43-fwcutter version 11 from the web site.... despite the "_rename".

On the other hand, i observed that this "system freeze" happends more offten when i play the game openttd (using 2D acceletation) than whe just using firefox under 3D acceletated compiz.

I wonder if there is an nvidia problem (with gutsy i had a memory leak, it seems that now there is no more memory leek but also i was not able to keep the computer on more than a few howers to see).

I really have no clue on the real cause of this problem and i don't know how to find because i have difficulties finding the cause of a kernel bug that leaves no trace as far as i know....

moa3333 (moa3333) wrote :

I have an intuition it might be related to the buggy nvidia-glx-new drivers. I'll try to investigate this in the next days for confirmation...

Same bug as???

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/176589

nvidia-glc-new 169.12 for Linux x86/x86-64 released (not yet in ubuntu)!

------>> Worked around a problem that caused function key presses on some Toshiba notebooks to result in system crashes.

http://www.nvnews.net/vbulletin/showthread.php?s=065f90c4449552f276d6e93928ce6bac&t=108879

moa3333 (moa3333) wrote :

I've installed the latest nvidia driver and it did NOT solved the problem. Now i am back to nvidia-glx-new from ubuntu....

moa3333 (moa3333) wrote :

UPDATE:

I've noticed in the last few weeks that some times when the computer was frozen, when pressing the power off button for about 5 secconds, right one second before hard shuting down the system responded.

Since i've tried not to shut it down and i noticed that rarely the system gets back to normal after a few seconds, but not all the time it hapends in a resonable time. I've noticed also that if i let the computer open most of the times it is still working, but not always...

This is in my opinion a good sugestion that it is not a "real" kernel panic but only "like" a kernel panic to the end user. It is actually like the kernel is "busy" for a few secconds or some times for a few minutes and maybe more (i never waited more than a few minutes to see if it gets unblocked then).

A VERY strage thing happend after the last upgrades and my numerous changes to xorg and other... After getting back to the official packages from ubuntu (nvidia-glx-new), compiz was using 100% of the CPU and increased memory usage. It worked ok, but from time to time the mouse stopped responding a few seconds exactly like the in the bug we are investigating here. I've manged to resolve compiz CPU by changing a bit the settings and killing compiz.real a few times (i'll have to reboot now to see what happens then).

I have a feeing this bug is actually related to compiz and nvidia (maybe only on AMD64). And it is not a real kernel bug or panic. I saw other poeple experiencing complete blocking of the mouse and of the computer for a few secconds in compiz. In my case, the bug blocked the computer and the mouse for a VERY long time most of the times and some times for only a few seconds.

I wonder if this is a compiz / nvidia busy-bug instead of a kernel freeze-bug? God, i hate compiz and this buggy nvidia drivers...

moa3333 (moa3333) wrote :

I've done a one pass memory test, no errors.

I've uninstalled yesterday nvidia and used nv driver with metacity and without compiz since. It behaved ok yesterday but today i had a freeze right a few minutes after i started my laptop.

I had also a problem with the wifi card: it was working only 20% of the time, the rest of the time network was unreachable! I have disabled encryption and now it seems to work fine. If there is no more crash in the next days it means the WPA Parsonal encryption in the b43 firmware or driver was causing the system freeze, l'll keep you up to date.

moa3333 (moa3333) wrote :

Using no encription and the nv driver i got a system freeze....

moa3333 (moa3333) wrote :

I have installed ndiswrapper instead of b43 and ssb... My computer still freezes.

Conclusion: it is not a problem of b43 or of nvidia. Since i have done no other change, it is surely a problem caused by the upgrade from Feisty to Hardy, most probably the kernel itself or a new module in the kernel.

description: updated
moa3333 (moa3333) wrote :

I have observed a few facts:
* the freeze happends "more offten" when i use compiz play a game or watch a video (this is true even when using nvidia driver without compiz)
* when the freeze hapeneds, if i reboot my computer, some times it will continue to hapend after only a few minutes
* once my computer restarted itself right after i restarted it manually but before entering the linux kernel!

Then i remember the history of this laptop: my video card was broken after i bough it and they replaced it with a new one for free 9 months ago. It is possible that this manual operation could have resulted in a badly mounted video card causing some times overheat to the graphical GPU not to the main CPU.

I have two "feelings":
* first of all, my feeling that this is related to nvidia driver or compiz is true in some way......
* seccond, nvidia or compiz seem to be not the cause but only what trigers the problem to occur more offten...

I have a HP Pavilion DV6000 laptop, for whoever plan to buy HP crap in the future....

If no one else is experiencing this in ubuntu, then i feel i should set this bug's state to invalid.

Changed in linux-meta:
status: New → Invalid
jyks (jyks) wrote :

Hardy Beta (with all latest updates) on my Compaq v3000 seems to have this problem. So you are not alone!
The laptop randomly freezes mostly resulting in a hard reboot. But recently i just switched off the wireless antenaa and after a few minutes it starts responding! I have been able to reproduce this behaviour atleast twice.

Driver Versions:
nvidia-glx-new: 169.12+2.6.24.11-12.31
b43 with broadcom-wl-4.80.53.0 firware

dmesg after/before the freeze [ freezetime stamp around 356] :
[ 103.365306] NET: Registered protocol family 17
[ 104.169003] wlan0_rename: Initial auth_alg=0
[ 104.169009] wlan0_rename: authenticate with AP 00:1b:2f:0c:0e:be
[ 104.169629] wlan0_rename: RX authentication from 00:1b:2f:0c:0e:be (alg=0 transaction=2 status=0)
[ 104.169632] wlan0_rename: authenticated
[ 104.169635] wlan0_rename: associate with AP 00:1b:2f:0c:0e:be
[ 104.170619] wlan0_rename: RX AssocResp from 00:1b:2f:0c:0e:be (capab=0x411 status=0 aid=1)
[ 104.170623] wlan0_rename: associated
[ 104.170626] wlan0_rename: switched to short barker preamble (BSSID=00:1b:2f:0c:0e:be)
[ 356.186857] b43-phy0: Radio hardware status changed to DISABLED
[ 356.286688] b43-phy0: Radio turned on by software
[ 356.286694] b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on.
[ 357.181144] psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 4 bytes away.
[ 358.125085] wlan0_rename: No ProbeResp from current AP 00:1b:2f:0c:0e:be - assume out of range
[ 358.481711] wlan0_rename: Initial auth_alg=0

moa3333 (moa3333) wrote :

Ok, that's good.

Actually i have noticed after a few days of using kernel 2.6.22 i was not able to reproduce the freeze.

Comming back to the last kernel 2.6.24 is causing the problem to come back.

I am using ndiswrapper, and don't know if it's related to it or not, but one think is sure: kernel 2.6.24 does this.

What is your kernel? Does the error occour also with ndiswrapper?

jyks (jyks) wrote :

kernel version: 2.6.24-12-generic.
I'm not using ndiswrapper, rather using the b43 driver.
I'll check if this occurs with ndiswrapper & kernel 2.6.22.

Onkar Shinde (onkarshinde) wrote :

I can confirm the bug. It is caused by some combination of modules b43, rfkill, rfkill_input. I have observed the problem in 2.6.25 kernel image available in repositories as well as unofficial 2.6.27 kernel image created by Michael Casadevall (NCommander/sonicmctails). I remember seeing this problem on some kernel image on hardy (probably 2.6.24). But since my ibook was not in working state for last few months prior to seeing the problem for first time and since I was eager to update to intrepid I didn't bother to debug it.

Following are my observations on my ibook powerpc with broadcom 4306 chipset based wireless NIC.
1. The UI freezes randomly. At no point it returns to normal state. Most of the time the computer reboots automatically after some time.
2. If I am using console (Ctrl + Alt + F1), at the time of panic I see some messages related to either rfkill_input or b43_interrupt_handler. After that most of the time I get message that computer will reboot in 180 seconds and it actually does.
3. Yesterday I unloaded all the modules I have mentioned (modprobe -r) and I didn't get any UI freeze for more than four hours. I was connected to internet via wired NIC, watched movie using a DVD, had chats with friends, upgraded the machine with latest updates. No problems at all.

I plan to blacklist the modules one by one so that I can identify which actually causes problem. Also If I get the kernel panic message, I will take a photo and attach to this bug.

Hope this helps.

Changed in linux-meta:
status: Invalid → Confirmed
moa3333 (moa3333) wrote :

In my case, the problem was also present when not using b43. since then i only use ndiswrapper with the windows driver working much better than the free driver. I never tried to look at rfkill* modules....

However, in my case, this is a probem occuring in all operating systems (knoppix, debian, gentoo, etc) with kernel 2.6.24!

In the meantime i used kernel 2.6.23 then 2.6.25 on Sidux (debian Sid) and then kernel .6.26 on a few systems, and now i am usgin kernel 2.6.27. I NEVER had any problem with this kernel (using ndiswrapper or wifi) but if i boot in knoppix or any other live cd like Systel Rescur CD using kernel 2.6.24 the problem is confirmed over and over again at random imtervals.

since this problem NEVER occured on any other kernel, older or newer than 2.6.24, i just suppose it was caused by a regression in 2.6.24, regression that was fixed in 2.6.25 and later kernels.

If you have this problem in other kernels than 2.6.24 then it might not be the same problem. I'm so satisfied with newer kernles for fixing this annoying problem in my case.

Greetings.

Onkar Shinde (onkarshinde) wrote :

@moa3333,

Do you have any powerpc machine around where you can check if the problem is present on 2.5.25 or greater kernel versions. It is possible that it is fixed for 386 but not for powerpc.

moa3333 (moa3333) wrote :

Actually i think the problem is not even present on i386...

I only had this problem on my AMD64 Turion PC, not on my i386 one.

Maybe the problem on AMD64 was fixed and it is now present on powerPC?

Andy Whitcroft (apw) wrote :

This is not a bug in the linux-meta package, moving to the linux package.

affects: linux-meta (Ubuntu) → linux (Ubuntu)

moa3333, thank you for reporting this and helping make Ubuntu better. Hardy desktop reached EOL on May 12, 2011.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue on a supported release? If so, can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in a supported release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

tags: added: amd64 hardy needs-upstream-testing
tags: added: regression-release
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers