System freezes during boot, unless I hold a key down

I noticed tonight that plugging in or unplugging a USB device also allows the system to momentarily resume booting. I've attached a video of what it's doing.

Thank you for your bug report. In order to know if this bug is really caused by usplash, can you try to boot your computer with usplash disabled? You can do this by following the steps described here :

https://wiki.ubuntu.com/DebuggingUsplash#Debugging%20procedure

I disabled usplash, and the problem still happened.

Thanks for your confirmation! Then, that means that this bug is not caused by usplash but most probably linux kernel, so I'm marking this bug as a linux kernel bug.

BTW, what a strange bug!

Can you boot your computer normally, reproduce the problem, and then type these commands in a terminal?

uname -a > uname-a.log
cat /proc/version_signature > version.log
dmesg > dmesg.log
sudo lspci -vvnn > lspci-vvnn.log

This should create 4 log files that you can attach to this bug report.

Thank you very much for these debugging informations. The report now contains sufficient informations for ubuntu linux kernel team. If you can verify it, there would be still one information that can be useful : Can you reproduce this bug on older kernel (ex. on Hardy?) or does it only happens with current intrepid?

This only happens with Intrepid. I've tried installing Intrepid from scratch, and upgrading from a working Hardy installation, both show this behavior.

Just to clarify my last comment, the Hardy installation that I upgraded from booted fine, only after upgrading to Intrepid did the problem occur. Also, when I first tried Intrepid (Around Alpha 3 or 4), this problem was occurring then also.

I have the same exact problem with Mandriva 2009 RC2 using the 2.6.27 Kernel and Ubuntu Intrepid Alphas..

EmigrantMTChris : Thanks! Added linux-2.6.27 flag and updated description.

Perpetual : Thanks for your comment. If you know a bug report on mandriva that describes this problems, can you link this bug to the launchpad bug? Also if you can provide the same files as EmigrantMTChris :

uname -a > uname-a.log
cat /proc/version_signature > version.log
dmesg > dmesg.log
sudo lspci -vvnn > lspci-vvnn.log

It might be useful to have your logs as well.

Saïvann Carignan

Well, I tried but now I have an issue with xserver not being able to start. Once I figure out how to get beyond this issue, I will get the requested logs.

I could not find a bug on Mandrivas bug tracker. I discussed in #mandriva-cooker and did not find anyone else who had seen or reported it. I am having various issues with distributions using the 2.6.27 kernel. Fedora 10 Alpha drops to busy box on boot. I can boot stable distributions (Ubuntu 8.04, Mandriva 2008, Fedora 9) that use older kernels without problems.

Perpetual : Note that you can do it from the console if you have a Fat32 USB key :

sudo mkdir /media/USB
sudo mount -t vfat /dev/sdb1 /media/USB
uname -a > /media/USB/uname-a.log
cat /proc/version_signature > /media/USB/version.log
dmesg > /media/USB/dmesg.log
sudo lspci -vvnn > /media/USB/lspci-vvnn.log
sudo umount /media/USB

Hi,

i have the exact same symptoms. intrepid wont boot unless i have a key held down, and then when it starts up, it drops me down to low graphics mode due to "(EE) No devices found". Hardy worked PERFECTLY on this laptop with the exception of my wireless, and now it just craps out, lol

anyway, i did the log commands you requested, here they are:

So far, all lspci logs report almost exactly the same configuration! Nvidia MCP67

Could bug 263059 be a dupe of this?
I'm seeing this issue too; I've kept the 2.6.24-21 kernel from Hardy for now. I'll try to boot by holding some keys down and post debugging logs if I'm successfull.

it does not seem to be, as the boot doesnt hang as long as you hold the key down, adn it works fine for me....if you don't mind not having X.

also, is this bug tagged for intrepid? i dont see any mention of that anywhere on the bug status on the top of the page and i would realllly like to get this fixed so i can actually use intrepid for a future beta >.<

Setting milestone to 8.10 so this bug gets considered for intrepid Final Release.
Since this problem is related to a specific hardware, the most useful information that you could give to help fixing this bug is the linux kernel revision number that caused this regression by doing a git bisect. However, if you don't use to play with a revision system, you might find this extremely complicate, and that requires a lot of testing and time! If any of you want to give a try : http://www.kernel.org/doc/local/git-quick.html#bisect

i am free this weekend with no work so i will do that this weekend.

however, do i have to have intrepid installed for that to work? Or can i do it using the live cd.

if i do have to have it installed, how exactly do i install it if i cant get access to the GUI? use the alternate cd?

Polygon : I never did a kernel bisect myself but this requires a lot of time. You'll probably need to build and boot the linux kernel a huge amount of times. You can use the alternate CD to install intrepid on your computer, however since you get another bug which prevent you to use Xorg, that sounds like this will be specifically difficult. If you're still unable to proceed and that you need more information or help, there is Google and/or ubuntu developers in #ubuntu-devel that might be able to give you what you need. Keep in mind that doing a git bisect is far from being a easy thing, so don't discourage yourself if you don't succeed in identifying the right revision number ;-)

I wish you good luck. If you are able to identify the specific revision number of linux kernel that caused this issue, the next step is to forward this information to upstream kernel developers. I'll keep listening to this bug report.

I can't make any promises because I've got a lot going on right now, but I will also try to do this some time this weekend.

also, i need a link or a guide on how to compile the kernel exactly like it gets compiled for the ubuntu repos, so i can test it correctly. I also need it because i have never compiled a kernel before (never needed to), but im sure i can figure it out

Polygon, I've found another thread that has useful information about doing the kernel bisect using git, hopefully this will help us out with this.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/269248

Also, does anyone happen to know the current kernel version in Hardy, so I can use that as the last known good version, since I've seen this bug in every version of Ibex that I've tried?

Hardy has 2.6.24.19.18 in main, 2.6.24.19.21 in security and updates and
2.6.24.19.23 in proposed.
See here: https://launchpad.net/ubuntu/hardy/+source/linux-meta
I can confirm that everything is fine with .21

On Fri, 2008-10-10 at 21:16 +0000, EmigrantMTChris wrote:
> Polygon, I've found another thread that has useful information about
> doing the kernel bisect using git, hopefully this will help us out with
> this.
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/269248
>
> Also, does anyone happen to know the current kernel version in Hardy, so
> I can use that as the last known good version, since I've seen this bug
> in every version of Ibex that I've tried?
>

Saïvann Carignan, sorry for the delay. As of October 12, 2008 daily build 32 bit, the problem still exists. Logs attached.

So I worked on doing a kernel bisect some this weekend, and ran into a few problems. First, I couldn't figure out how to specify the exact versions of the kernel that I knew were good and bad. Instead of being able to specify that the known good/bad kernels are 2.6.26-rc9 and 2.6.27-3, I could only specify that they were 2.6.26 and 2.6.27, which led to nearly 18,000 revisions to check.

1st question is, how can I specify the exact kernel versions that I know are good and bad? When I try, I get the following errors:
chris@chris-laptop:~/Temp/ubuntu-intrepid-git$ git bisect bad 2.6.27-3
fatal: Needed a single revision
Bad rev input: 2.6.27-3

2nd question:
After getting the revisions to check down to a few hundred, I started getting odd errors, and I'm pretty sure I messed up somewhere, so I decided to start over. I tried the git bisect reset command, but get the following error when I tried that.

chris@chris-laptop:~/Temp/ubuntu-intrepid-git$ git bisect reset
error: Untracked working tree file 'debian/changelog' would be overwritten by merge.

How can I get around this, and restart the bisect?

3rd question:
After not being able to use the git bisect reset command, I deleted the entire directory, and checked it out again in a clean directory, then tried the bisect again. It seems to go ok, until I try to build the kernel. Then I get this error:

chris@chris-laptop:~/Temp/ubuntu-intrepid-git$ CONCURRENCY_LEVEL=2 fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers
exec debian/rules DEBIAN_REVISION=2.6.26-custom-10.00.Custom APPEND_TO_VERSION=-custom INITRD=YES kernel_image kernel_headers
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 3: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 4: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator
[: 1: 2: unexpected operator

====== making target CONFIG-common [new prereqs: testdir]======

====== making target CONFIG-common [new prereqs: stamp-conf]======
This is kernel package version 11.001-0.1.
====== making stamp-arch-conf because of ======

====== making target CONFIG-arch [new prereqs: stamp-arch-conf]======
====== making target conf.vars [new prereqs: Makefile .config]======

Makefile:510: /home/chris/Temp/ubuntu-intrepid-git/arch/xen/Makefile: No such file or directory
make[1]: *** No rule to make target `/home/chris/Temp/ubuntu-intrepid-git/arch/xen/Makefile'. Stop.
make: *** [conf.vars] Error 2

What would be causing this error? I'm getting it every time I try to compile the kernel since I deleted the old directory and checked it out again.

The only thing that I can see here is that you typed kernel versions number instead of revision number (which is a "pure" number without dot, like 100644) :

git bisect bad 2.6.27-3
fatal: Needed a single revision
Bad rev input: 2.6.27-3

Actually, we know that the bug was already there with 2.6.26 and 2.6.27 kernels, however 2.6.24 kernel does not have this bug, so you should test kernel revisions between 2.6.24 and 2.6.26. Since there are thousands revisions between each release, there is probably a way to "jump" between revisions easily so you can quickly identify which one is the faulty one.

I'm experiencing this issue also with an HP Pavilion dv6700 laptop that works fine with Hardy. If you need some additional data from a different hardware set, I'd be glad to run any tests and capture any logs you would like.

Same issue here on a Compaq Presario F700

Added links to the Mandriva and upstream reports for this issue.

The upstream bugzilla is for a different type of systems, please do not mix those as they have different root causes. Please open a separate bug on kernel.org for this problem, which affects AMD C1E machines.

Thanks to 67GTA, here is a correct dsdt.aml file for the HP dv6667se. It's been running for a few weeks with no problems. Laptop is running considerably cooler, and it boots and shuts down correctly on AC and battery power.

I have the same problem on ubuntu karmic i386, i attach 4 files

Sorry, i use a HP pavilon dv6809wm with nVidia MCP67 motherboard.

Okay, I've tested this for a while, I'm ready to say this is working great!

For the Compaq F761US. Thanks to 67GTA.

Ing. Forigua: Follow my how to to get your dsdt.dsl file and post it here. I will fix it for you. You can then follow the rest of the how to to get it going. http://ubuntuforums.org/showthread.php?t=1036051&highlight=dsdt

Works fine for me, now, on Compaq F750US.

Thank You!

It's working for me on HP Pavillion dv6921la. Here are my dsdt.* file.

Thank You...

This bug is fixed for me on ubuntu karmic koala i386 hp pavilon dv6809wm with MCP67 motherboard

@Ing. Forigua

So you are saying it is fixed without touching the DSDT file? Did you try booting on battery power? Thanks!

I've been playing with Karmic for a while now, and so far for me it's boot
on and off battery without requiring a key to be pressed down. However, I
have noticed it occasionally overheats.. but so far it only seems to
overheat if I leave firefox open and close the lid. When I come back after a
few hours it's hot and the fan is blowing in it like mad.

On Wed, Jun 17, 2009 at 10:27 AM, Perpetual <email address hidden> wrote:

> @Ing. Forigua
>
> So you are saying it is fixed without touching the DSDT file? Did you
> try booting on battery power? Thanks!
>
> --
> System freezes during boot, unless I hold a key down
> https://bugs.launchpad.net/bugs/272247
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Confirmed
> Status in Ubuntu Release Notes: Confirmed
> Status in “linux” source package in Ubuntu: Confirmed
> Status in “usplash” source package in Ubuntu: Invalid
> Status in linux in Ubuntu Intrepid: Triaged
> Status in usplash in Ubuntu Intrepid: Invalid
> Status in “linux” source package in Mandriva: Invalid
>
> Bug description:
> Once the Ubuntu splash screen loads with the progress bar that moves back
> and forth, it freezes. Holding down any key unfreezes the system, and it
> continues
> loading normally, until I release the key, at which point it freezes again.
> Holding a key down again unfreezes the system again.
>
> Pressing Alt+F1 to show the output also freezes, so I know it isn't just
> the splash screen freezing, but the entire system.
>
> Once X loads, it works perfectly fine though, and I don't have to keep
> holding a key down.
>
> Update : This bug happens with 2.6.26 and 2.6.27 kernels with a computer
> that has Nvidia MCP67 motherboard. A known workaround that sometimes works
> is to add nolapic to GRUB boot kernel options. acpi=noirq is also known to
> work.
>
> ProblemType: Bug
> Architecture: amd64
> DistroRelease: Ubuntu 8.10
> NonfreeKernelModules: wl nvidia
> Package: usplash 0.5.23
> ProcEnviron:
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: usplash
> Uname: Linux 2.6.27-3-generic x86_64
>
> ----------
> Possible systems affected include:
> Nvidia MCP67 Chipset
> Compaq Presario F700
> Compaq Presario F763NR
> Sony Vaio PCG-GRT-815E - from the Mandriva errata
> HP Pavilion DV6545eg Notebook - from duplicate
> HP Pavilion DV6736nr
> HP Pavilion DV6745us - from a duplicate
> HP Pavilion DV6620es
> HP Pavilion DV9610us
> HP Pavilion DV9700z
> HP Pavilion DV6915nr
> HP Pavilion DV9645ed
> HP G6062ea
>

could it be related to default grub2 in karmic?

sorry for my bad english...

2009/6/17 SRElysian <email address hidden>:
> I've been playing with Karmic for a while now, and so far for me it's boot
> on and off battery without requiring a key to be pressed down. However, I
> have noticed it occasionally overheats.. but so far it only seems to
> overheat if I leave firefox open and close the lid. When I come back after a
> few hours it's hot and the fan is blowing in it like mad.
>
> On Wed, Jun 17, 2009 at 10:27 AM, Perpetual <email address hidden> wrote:
>
>> @Ing. Forigua
>>
>> So you are saying it is fixed without touching the DSDT file?  Did you
>> try booting on battery power?  Thanks!
>>
>> --
>> System freezes during boot, unless I hold a key down
>> https://bugs.launchpad.net/bugs/272247
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>> Status in The Linux Kernel: Confirmed
>> Status in Ubuntu Release Notes: Confirmed
>> Status in “linux” source package in Ubuntu: Confirmed
>> Status in “usplash” source package in Ubuntu: Invalid
>> Status in linux in Ubuntu Intrepid: Triaged
>> Status in usplash in Ubuntu Intrepid: Invalid
>> Status in “linux” source package in Mandriva: Invalid
>>
>> Bug description:
>> Once the Ubuntu splash screen loads with the progress bar that moves back
>> and forth, it freezes. Holding down any key unfreezes the system, and it
>> continues
>> loading normally, until I release the key, at which point it freezes again.
>> Holding a key down again unfreezes the system again.
>>
>> Pressing Alt+F1 to show the output also freezes, so I know it isn't just
>> the splash screen freezing, but the entire system.
>>
>> Once X loads, it works perfectly fine though, and I don't have to keep
>> holding a key down.
>>
>> Update : This bug happens with 2.6.26 and 2.6.27 kernels with a computer
>> that has Nvidia MCP67 motherboard. A known workaround that sometimes works
>> is to add nolapic to GRUB boot kernel options. acpi=noirq is also known to
>> work.
>>
>> ProblemType: Bug
>> Architecture: amd64
>> DistroRelease: Ubuntu 8.10
>> NonfreeKernelModules: wl nvidia
>> Package: usplash 0.5.23
>> ProcEnviron:
>>
>>  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
>>  LANG=en_US.UTF-8
>>  SHELL=/bin/bash
>> SourcePackage: usplash
>> Uname: Linux 2.6.27-3-generic x86_64
>>
>> ----------
>> Possible systems affected include:
>> Nvidia MCP67 Chipset
>> Compaq Presario F700
>> Compaq Presario F763NR
>> Sony Vaio PCG-GRT-815E - from the Mandriva errata
>> HP Pavilion DV6545eg Notebook - from duplicate
>> HP Pavilion DV6736nr
>> HP Pavilion DV6745us - from a duplicate
>> HP Pavilion DV6620es
>> HP Pavilion DV9610us
>> HP Pavilion DV9700z
>> HP Pavilion DV6915nr
>> HP Pavilion DV9645ed
>> HP G6062ea
>>
>
> --
> System freezes during boot, unless I hold a key down
> https://bugs.launchpad.net/bugs/272247
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The Linux Kernel: Confirmed
> Status in Ubuntu Release Notes: Confirmed
> Status in “linux” source package in Ubuntu: Confirmed
> Status in “usplash” source ...

Some small change in the Karmic kernel has made the hanging at boot go away. The other problems still persist such as overheating and failure to resume from sleep. A custom DSDT is still needed. Check your dmesg output.

The suggested fix of adding "acpi=noirq" worked on jaunty 64bit. HP dv6000 (model 6910us)

Please ! Include the HP PAVILION 6725US, I've same BUG.
Ubuntu 9.04 32Bits

This won't get fixed in Intrepid. The question is how to proceed here. Having passed the 300 comments mark unfortunately does not help either. What would people think of closing this one and open a new, fresh one for those having that problem still in Karmic (and specifically test whether acpi_skip_timer_override helps? Very likely we will have to open a new upstream bug report as well in that case.

This bug report was marked as Confirmed a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

It's actually hard to say at this point. The freezing has disappeared quite a while ago, but there is another problem which I still experience, which seems directly related to what caused the freezes in the first place. This seems to be an issue on certain chipsets not handling IRQ's properly. I think the reason there's been no posts on this as of late is because, while the halting issue is gone, the overheating persists without a custom DSDT file which 67GTA was quite helpful in assisting quite a few of us with. I don't think people are aware that the overheating is from the same issue. Perhaps at this point a new bug should be started or this one renamed? I wouldn't consider the custom DSDT files to be a "triage" because the are not readily available through updates and aren't something an average user can conjure up themselves very easily.

I have been using the custom DSDT file 67GTA assisted me with creating since the Intrepid release, and still use it now in Lucid Alpha 3 (10.04). And without it, yes, my laptop still overheats, sometimes to the point where it slows down so much I have to force a shutdown. Good thing I've been keeping my custom file on a thumb-drive.

I thought the whole point as Stefan pointed out above (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/272247/comments/375) that we should open up a new bug report because this is a very broad issue, and it seems to be effect by everyone using a laptop with a buggy DSDT. I'm not sure how best to go about this though.

Right and because the title here says freezes, so its hard to get the relation
to overheating. Just to note one thing I recently read in a patch description:
apparently there are (at least two hp models iirc) some laptops which claim
working c-states (power saving states of the cpu) than they have working. The
older driver for that had a "bug" (or feature) that it would stop using not
working states (unfortunately the patch description did not exactly say how you
see the brokennes in powertop).
So one thing to try (without a customized DSDT) is to set
"processor.max_cstate=" to either 2 or 1 and see whether that has effect on the
temperature.

I feel like a bit of an idiot atm, I left firefox open last night and this morning my laptop was overheating. After I gave it a reboot and checked my email someone had messaged me stating that sometime in Karmic the custom DSDT option was removed, I checked my logs and found that it seems to be true. How ironic :/ At this poing I am going to try what Stefan suggests, starting with 2 and going back to 1 if need be.

I guess this teaches me a lesson on not being so lazy, I've had my laptop occasionally overheat (randomly) after Karmic and thought something was just working to hard or firefox was being a hog again. I never thought to check wether or not my DSDT was still active, if I had I might have commented on this thread earlier, sorry guys. There are a few bugs I need to look into and report today as well, seeing as how it's my day off from work I think I will do so.. no more lazy.

I will comment back when I get an actual result, whenever that will be.

AFAIK, the newer kernels lack the feature of loading custom DSDTs from initrd. Now you have to put your DSDT in kernel at compile time. It means you'll have to recompile your kernel whenever there's an update to it. Currently that's what I do, but on my laptop I use Arch Linux, and I don't have any experience in recompiling kernel in Ubuntu, so I can't provide any specific instructions on how to do that. The basics are here though: http://www.lesswatts.org/projects/acpi/overridingDSDT.php

I believe that for an average user this would be too much of a trouble, and the recompilation takes some time too, so unfortunately for most users it's not a solution.

Too bad custom DSDT support has been dropped.
Thats why I cannot move on from JJ.

67GTA confirmed that OpenSUSE has support for it. And as a KDE user, I am considering moving to Archlinux, since Kubuntu is being treatead as 2nd class.

@Rad3k: does Arch have custom DSDT support?

Thanks guys.

sergiom99,

Arch Linux does NOT have custom DSDT support, because the kernel itself dropped support for the patch upstream as it was very 'hackish', and breaks every two releases or something, and as a result Arch Linux dropped support for it as well. So, that means that Ubuntu and Arch Linux and most other distros will not have custom DSDT support , unless the explicitly add it themselves (you mentioned OpenSUSE did....)

I read that the kernel developers would much rather have people submit kernel.org bug reports saying that their DSDT is faulty and have fixes/workarounds for buggy DSDTs rather then have support for actually loading custom DSDT files, as that way, the fix effects a wider number of people, rather then the very small number who are even aware of the whole 'buddy DSDT ' problem.

You can add Opensuse to the list of those NOT supporting custom dsdt's. After the patch was committed, one of the Novell kernel devs removed it again citing Linus's decision to remove all custom dsdt support. If you only update to 2.6.31-8, you will have dsdt support. This bug has reappeared in Opensuse 11.3 as well. I have to hold down any key at random to get it to boot. On the bright side, Opensuse 11.3 has a patch that fixes the "ACPI Exception: AE_OK, No or invalid critical threshold" thermal error that was causing my overheating problem. Now my CPU temps are read correctly.

FYI the start up freezing is still present on a Toshiba Satellite A30 under Jaunty, I'm currently working around it using the nosmp parameter. Before Jaunty I was also able to work around this with a custom DSDT, although as per the above posts this is now not an option.

The start up freezing is no longer present on my compaq presario f764NR laptop, just putting that out there.

Ok, so they have the bug reports and all.
Let's see how them kernel developers get all them fixed, as the decided when dropping custom DSDT support.

First post here is from Sep/2008.

Cheers!

Hi folks; I'm marking this release notes task as incomplete because this bug log has records of way too many different issues, some of which have apparently also been resolved (I see mentions of many different systems, of freezes versus overheating problems, and of many kernel cmdline parameters which may or may not help either of these).

I'd highly recommend you split the remaining issues in separate bug reports and only merge them when they are confirmed to be the same issue. Please do reopen release notes tasks if that's still release notes worthy; thanks!

Same problem on Lenovo Ideapad S12 on clean install of 10.10
Booting with acpi_skip_timer_override solved the problem.

In /etc/default/grub I added
GRUB_CMDLINE_LINUX="acpi_skip_timer_override"

-BIOS-
Date : 05/13/2009
Vendor : LENOVO
Version : 19CN16WW
-Board-
Name : MoutCook
Vendor : LENOVO

-Processors-
Intel(R) Atom(TM) CPU N270 @ 1.60GHz : 800.00MHz
Intel(R) Atom(TM) CPU N270 @ 1.60GHz : 800.00MHz

-Version-
Kernel : Linux 2.6.35-22-generic (i686)
Compiled : #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010
C Library : GNU C Library version 2.12.1 (stable)
Default C Compiler : GNU C Compiler version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
Distribution : Ubuntu 10.10
Desktop Environment : GNOME 2.32.0

Thanks to Magnus Helander, setting acpi_skip_timer_override fixed it.
Also running on Lenovo Ideapad S12.

On 11/19/2010 10:26 PM, eisbaw wrote:
> Thanks to Magnus Helander, setting acpi_skip_timer_override fixed it.
> Also running on Lenovo Ideapad S12.
>
Just out of curiosity: would pci=nomsi help in your case too?

>> Thanks to Magnus Helander, setting acpi_skip_timer_override fixed it.
>> Also running on Lenovo Ideapad S12.
>>
>Just out of curiosity: would pci=nomsi help in your case too?

Yes, pci=nomsi works just as fine as acpi_skip_timer_override.

FYI:
$ uname -a
Linux leno 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:48 UTC 2011 i686 GNU/Linux

I am also affected by this. Disabling C1E in BIOS, nolapic_timer or acpi_skip_timer_override fixes it. I think that acpi_skip_timer_override has the least negative impact on my system so I am using this.

AMD Phenom(tm) II X6 1090T Processor
Asus M4A88TD-V EVO/USB3
Ubuntu 11.04 Natty 64 Bit

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.