Bug Description

Binary package hint: ubuntu-base

Applies both to Ubuntu 8.04.1, Kernel 2.6.24-19 server and Ubuntu 8.04.1 Kernel 2.6.24-19 generic (desktop).
Both in the server and generic desktop versions of the OS installed on the same machine, an Intel D945GCLF MB w/ Atom CPU. Makes no difference if hyperthreading is enabled or disabled except that when it is disabled, I can't do anything more after the CPU is locked up. In both versions of the OS, I thought that the problem might be CPU temp related, but now I am sure that it is not. Rather, it seems like it is CPU activity related -- even if the CPU is cool, the problem is correlated with a lot of CPU activity. It is not related to a particular application that I'm running. When using the system monitor in the desktop version, I can see CPU #1 going into the lock-up mode, but apparently CPU #0 does the update of the system monitor. No process is shown with high CPU activity. For both versions of the OS, it is impossible to shut down the computer using the OS. The busy CPU prevents all of the processes from terminating. Under the desktop version, once CPU #1 gets locked up, it is possible to undertake one more step in Gnome, at which point it locks up. The locked/busy CPU never becomes unlocked/unbusy.

No problems running Win2k on this computer.

From my Google searches, I have noted that quite a number of different CPU's, motherboards, and versions of Linux (not only Debian derivatives) are suffering from this problem, and it manifests itself under a wide range of circumstances. Smells to me like a kernel problem.

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description does not yet have enough information. The message you describe is a very generic message as the result of many possible different problems.

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 include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" after a fresh boot and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "sudo lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.
4. Please attach your /var/log/kern.log and /var/log/kern.log.0 files to this bug report.

Sorry for not getting back to you on this sooner. I previously run memtest on this computer without errors, but thought it valuable to repeat the test over a longer period. Unfortunately, yesterday I got sidetracked looking at the Olympic games, so I'm only getting back to you with the memtest results. After 36 hours, 52 minutes of clock time and 26.4 passes on 2GB of RAM (and thunderstorms all day yesterday), there are zero errors.

Let me know what else I can do to help.

Chris Coulson wrote:
> Could you please try running memtest on this computer? To do this, press
> [ESC] when Grub loads. This will bring up the Grub menu, and you can use
> the arrow keys to select memtest.
>
> Thanks
>

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Thanks Guillaume for testing with the Intrepid kernel. Dr. John - it would be great if you could test the Intrepid kernel too, to see if you get similar results. You should be able to test just by booting the live CD.

hefaeche - I'm not sure if you have the same issue as described here. There is nothing in your logs to suggest that.

Using the slightly older kernel I booted all the way but there are lots of pauses during the graphical boot (I started with -server but added the rest of ubuntu-desktop). I used "noacpi acpi=no" because that seemed to help with Hardy but I'm starting to think that is superstition on my part.
Linux pink 2.6.24-19-server #1 SMP Wed Aug 20 18:43:06 UTC 2008 x86_64 GNU/Linux

I currently running Debian Lenny on my D945GCLF with last kernel, but the problem seems to be the same.

So, my conclusion => bug with kacpid, due to r8101 or r8169 modules.

In fact, with my Netgear GA3131 card (r8169), or with the onboard r8101 chip, the system freezes when become idle.
If something is running, like "ping www", no freeze. When nothing is running, the system freezes in 1 or 2 minutes.

Last weekend, I turned off the onboard chip, and only use another PCI card with Marvell chip.
Result : no freeze at all in 4 days (24/24 7/7) ... unbelievable !

i plugged out the PCI-Soundcard...
restart...
sudo apt-get update, then upgrade, after that dist-upgrade... (huge update... 80-90 MB to download)
shut down
plug pci-soundcard in again
start... no problem...
restart... no problem... thats the magic... everything still works...
testing.... restarting 10 times, no problem starting up again...
testing.... shutdown... plug power cord off, after 10 seconds again on, starting up... still no problems...

maybe after that everything is working? there was a new kernel revision, and also somthing called pcidev......

2.6.27.1 on Gentoo. The board is D945GCLF2. Works fine if no PCI card is plugged, hangs that way in 1-2 minutes specially not under load. I've tried both a rtl8139 and a rtl8169 pci card. I seriously need the extra NIC, so if any workaround were to be found, that'd help.

I know that it may sound very strange, but could you try to disable automatic fan throttling in BIOS Setup? I have had the same issue and after turning off this option in BIOS it started to work just fine even if temperature is sometimes higher than with automatic fan throttling.

Hi Chris. You're right, in my logs is not the mistake. But I had when my laptop hibernate. Now i have discovery is due to a cooler laptop (ZA-NP80) connected to one of the usb ports. When they signed off, hibernate without problems. Thanks

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

I have the same Problem as Guillaume LAURENT. Since I installed the Realtek r8101 module (r8169 blacklisted) I cannot shutdown anymore:
soft lockup - CPU #0 stuck for 61s
Sadly I had to install the Realtek driver, because the r8169 does not work anymore since the 2.6.27-11-generic Kernel.
This is most unfortunate.

This might have nothing to do with the problems you reported. But here it is anyway:

Some seconds after running /usr/sbin/NetworkManager my system most times freezed (If it didn't freeze now then everything works fine after that including wireless networking) and after one minute started printing:
BUG: soft lock - CPU #0 stuck for 61s! [ntdriver:2807]

On my setup this usually happened during start up. The call to NetworkManager returned and the freeze happened during starting X when the screen was blank and I could not see any messages and could not return to console. -> I have been trying to fix my X setup for days, installing and compiling different drivers and patches and reconfiguring xorg.conf endlessly. Please don't do that if the problem is elsewhere ;) I will try to live with dhclient for now.

Hey, have the same note after installing UBUNTU 10.4. Before I had no graphical surface after installation. The same with opensuse 11.2. Research gave me the hint that my combination of a NVidia Mainboard with an ATI Graph card causes this bug. As a solution I found proposals to switch off acpi, or start ubuntu with "nomodeset" I tried all that stuff, but had no positive effect...

I have the same issue here
10.04.1
BUG: soft lockup - CPU#1 stuck for 61s!

When I boot the computer from a fresh install I get this. Sometimes if I let go it will go through but sometimes it won't???
When it goes through I can use Ubuntu like if there was no problem.
I can hear sort of a noise coming from the HD but the activity led does not flash.

Dr. John, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this 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 please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

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

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested and remove the tag:
needs-upstream-testing

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 text:
needs-upstream-testing

If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER