System freezes during boot, unless I hold a key down

Bug #272247 reported by EmigrantMTChris on 2008-09-19
248
This bug affects 36 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
High
Release Notes for Ubuntu
Undecided
Unassigned
linux (Mandriva)
Invalid
Undecided
Unassigned
linux (Ubuntu)
High
Stefan Bader
Declined for Jaunty by Leann Ogasawara
Intrepid
High
Stefan Bader
usplash (Ubuntu)
Undecided
Unassigned
Declined for Jaunty by Leann Ogasawara
Intrepid
Undecided
Unassigned

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 2009/08/31:

The problem behind this seems not limited to a certain controller chip, but related to ACPI BIOS definitions. The IRQ0 override defines to which interrupt number the timer interrupt is supposed to be routed. Most BIOS define a route to IRQ2, so the timer source (hpet in most cases) has to deliver an IRQ2 whenever a timer expires. The problem is, that this is not always correct (either hpet does not use IRQ2 or IRQ2 is not enabled on the chipset). So as soon as all CPUs go into sleep there is no timer irq to wake them up. To solve this automatically one would need documentation about the chipsets pci config space which is often secret.

Workaround for affected systems: Use of "acpi_skip_timer_override" as kernel command line option. Sometimes "nohpet" or "acpi=noirq" have been reported to work, too.

---

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

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.

Saivann Carignan (oxmosys) wrote :

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

Changed in usplash:
status: New → Incomplete

I disabled usplash, and the problem still happened.

Saivann Carignan (oxmosys) wrote :

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.

Saivann Carignan (oxmosys) wrote :

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?

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged

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.

Perpetual (landonab) wrote :

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

Saivann Carignan (oxmosys) wrote :

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.

description: updated
Perpetual (landonab) wrote :

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.

Saivann Carignan (oxmosys) wrote :

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

Mark Grandi (markgrandi) wrote :

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:

Saivann Carignan (oxmosys) wrote :

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

SK (stephantom) wrote :

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.

Mark Grandi (markgrandi) wrote :

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 >.<

Saivann Carignan (oxmosys) wrote :

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

Changed in linux:
milestone: none → ubuntu-8.10
Mark Grandi (markgrandi) wrote :

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?

Saivann Carignan (oxmosys) wrote :

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.

Mark Grandi (markgrandi) wrote :

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?
>

Perpetual (landonab) wrote :

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

Perpetual (landonab) wrote :
Perpetual (landonab) wrote :
Perpetual (landonab) wrote :
description: updated

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.

Saivann Carignan (oxmosys) wrote :

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.

Cesar Arguinzones (ceap80) wrote :

Same issue here on a Compaq Presario F700

Cesar Arguinzones (ceap80) wrote :
Cesar Arguinzones (ceap80) wrote :
Cesar Arguinzones (ceap80) wrote :
Adam Williamson (awilliamson) wrote :

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

Changed in linux:
status: Unknown → Confirmed
status: Unknown → In Progress
tglx (tglx) wrote :

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.

Changed in linux:
importance: Unknown → Undecided
status: Confirmed → New
importance: Unknown → Undecided
status: In Progress → New
Saivann Carignan (oxmosys) wrote :

Removed upstream and mandriva bug because they were not about the same hardware, therefore not the same bug. However if you find appropriate upstream bug report, don't hesitate to link them again! Thanks.

Changed in linux:
status: New → Invalid
Justin Nelson (plattypus1) wrote :

Similar behaviour here on a Compaq Presario F700 (AMD Athlon 64, nVidia mobile graphics).
uname:
Linux yuroncrack-laptop 2.6.27-7-generic #1 SMP Fri Oct 17 22:24:21 UTC 2008 i686 GNU/Linux
version:
Ubuntu 2.6.27-7.12-generic

lspci attached.

Trond Thorbjørnsen (tthorb) wrote :

My X works fine, so the boot problem are probably not related to that issue.

Here are my logs.

Trond Thorbjørnsen (tthorb) wrote :
Trond Thorbjørnsen (tthorb) wrote :
Trond Thorbjørnsen (tthorb) wrote :
Trond Thorbjørnsen (tthorb) wrote :
Cesar Arguinzones (ceap80) wrote :

I just want to add in case it help at all, that i also need to hold a key down for a properly shutdown....

Mine has also been doing that recently, but I don't think it has been
doing that since the first time I noticed this bug. It's only started
happening recently, unless I'm remembering wrong.

> I just want to add in case it help at all, that i also need to hold a
> key down for a properly shutdown....
>
> --
> 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.
>

Trond Thorbjørnsen (tthorb) wrote :

Maybe I have located the bug:

When I boot with "nolapic", the booting goes fine!

I attach dmesg.log for this boot.

Perpetual (landonab) wrote :

I don't know the difference between 'noalpic' or 'nosmp' but I can boot the livecd when I add 'nosmp' to the boot options. Not sure if it will boot after install though. Have not installed Intrepid.

Saivann Carignan (oxmosys) wrote :

Can someone else try to boot with noalpic to confirm if this bug is still happening?

Morten Minke (morten-amagi) wrote :

I have upgraded 8.04 to 8.10beta last week and since then I have the boot problem. I have had one or two occasions where I did not have to use the keys to continue boot. But I can not find any consistency in when.

I have a HP Pavilion dv9000 laptop and I use a logitec cordless usb mouse a dual monitor setup (most of the times) and a wired network (my wireless network got also broken but that is a different thing)

I have also tried without the external monitor and network cable and usb mouse and again, almost always do I have the boot problem.

To answer Saïvann, I tried the noalpic boot option and for me it did not work, I still have to press a key to continue the boot process.

Trond Thorbjørnsen (tthorb) wrote :

The parameter is "nolapic", maybe you copied Saïvann's misspelling?

Morten Minke (morten-amagi) wrote :

I have done a lot of reboots now to see if I can find what configuration triggers the problem but up until now without any success. I have had a couple of boots in a row which succeeded without a problem and suddenly without changing anything the problem occured again.
All boots were done without the quiet and splash options.

One boot I took the time to wait for every keypress and see what this resulted in in the log files.
See attached messages file, I have put ************** characters where you can see that the timing jumped (i.e. I waited to press a key at that exact moment).

However, after another boot I noticed that the stops were not on the always at the same location, though one location is 100% (up until now at least) constant and that is the USB initialisations with the lines:

hub 1-0:1.0: 10 ports detected

Sometimes it is the 2-0 hub, but it always stops after that location.

Hope that helps

I booted with the nolapic boot option. The system did not freeze, although it booted into BusyBox. Not sure why it did that....

Morten Minke (morten-amagi) wrote :

I tried it a couple of times both with and without the nolapic boot option and indeed only with the nolapic option set, the system consistently boots correctly.

What bothers me though is that yesterday when I tried just a lot of reboots, sometimes the system (also without the nolapic) booted correctly. How could this be possible?

That's odd that it is occasionally booting correctly for you. I haven't had a single boot without this problem since upgrading to 8.10.

Cesar Arguinzones (ceap80) wrote :

Booted with nolapic...
Same results as EmigrantMTChris (BusyBox)

Mark Grandi (markgrandi) wrote :

I booted with the nolapic option and it booted successfully without me having to hold a key down.

description: updated
Changed in usplash:
status: New → Invalid
Changed in linux:
milestone: ubuntu-8.10 → none
Perpetual (landonab) wrote :

Booting with nolapic works for me. Boots directly to a desktop.

ubuntusky (ubuntuskyx) wrote :

I can get through with "acpi=noirq"

This also worked for me. The computer booted normally into an X session
without any key presses from me.

ubuntusky wrote:
> I can get through with "acpi=noirq"
>
>

ubuntusky (ubuntuskyx) wrote :

I can go through with "acpi=noirq", but shut down computer with black screen

volume up and volume down work badly when the relative button being pressed on my laptop.

while in ubuntu 8.04 it worked perfectly

ArangeL (softwarej) wrote :

I have the same issue, I have a HP Pavilion DV6620es. I need to hold a key down to run Kernel 2.6.27; with 2.6.24 (Hardy), the PC boot without problems.

I think that this bug will be in the Final Relase of Ubuntu Intrepid :-(
Please, fix it or add kernel 2.6.24 to Intrepid.

I am going to post the attachments.
With the option "acpi=noirq" i can boot the PC normally in 2.6.27.

ArangeL (softwarej) wrote :
ArangeL (softwarej) wrote :
ArangeL (softwarej) wrote :
ArangeL (softwarej) wrote :
ArangeL (softwarej) wrote :
ArangeL (softwarej) wrote :
ArangeL (softwarej) wrote :
ArangeL (softwarej) wrote :
Perpetual (landonab) wrote :

Maybe I don't understand the Importance rating but I'm very confused by this being marked 'Medium'. I would suspect a whole lot of HP users will be coming to Ubuntu or upgrading to 8.10 to find that they can not use it do to an unresolved regression. Has there been anything upstream about this? I can not find where it appears to be a concern to anyone.

Sorry, I love Ubuntu but I am frustrated at this point.

Thanks for all of the hard work!

Chris Coulson (chrisccoulson) wrote :

Perpetual - Please see these guidelines for setting the importance of a bug: https://wiki.ubuntu.com/Bugs/Importance.

I appreciate that sometimes you may get frustrated when you do not agree with the importance of a bug, but the importance has to be set based on the severity of a bug and the impact to the Ubuntu user base. A bug will always seem to be high importance from the perspective of the people that are experiencing the bug, but we can't just set all bugs to high importance.

However, in this case it should probably be increased to high because of the number of people experiencing it now, and although there is a workaround (pressing a key) - this will not be obvious to most users, who will probably think that their computer fails to boot.

It might warrant a release note entry too.

Changed in linux:
importance: Medium → High
Saivann Carignan (oxmosys) wrote :

Mmh, potential duplicate of bug 254668 ?

Perpetual (landonab) wrote :

Chris, thanks for the response. I responded once but must not have saved the comment. Point was that I had read the link, which lead to my confusion initially.

High: A bug which fulfills one of the following criteria:

    * Has a severe impact on a small portion of Ubuntu users (estimated)
    * Makes a default Ubuntu installation generally unusable for some users
          o For example, if the system fails to boot, or X fails to start, on a certain make and model of computer
    * A problem with an essential hardware component (disk controller, laptop built-in wireless, video card, keyboard, mouse)
    * Has a moderate impact on a large portion of Ubuntu users (estimated)

Seems to me that at least bullet points 1 & 3 fit this bug. Mandriva 2009 Errata notes that this is a known bug so doing the same in the Ubuntu release notes would be a good thing.

I do appreciate Ubuntu and hate to see something that could potentially turn people away from the distribution or Linux in some cases.

Thanks all!

description: updated
Dave Morley (davmor2) wrote :

For me adding both noapic and nolapic seems to of done the job.

ArangeL (softwarej) wrote :

#davmor2; but if you have a laptop... with nolapic and noapic; the "Power Manager" don't run correctly (and this is very important to a laptop). With "acpi=noirq" you can boot kernel 2.6.27 (Ubuntu Intrepid) correctly.
Ubuntu Intrepid Final have the same bug (same kernel, same bug).

Opr8iVe (shutterjockey) wrote :

Same bug here.. Exactly as stated above.. Hangs on boot, unless key is pressed (I've been pressing Capslock)

Intrepid, 2.6.27-7-generic.

lspci results attached.

Hardware: HP Pavilion dv9920us (dv9000 series)

Hope a fix can be found.. This is a really odd bug :)

Thanks Ubuntu team, for all the hard work!
-Jason

Sean Seaman (sean-seaman) wrote :

Same bug here: Compaq Presario F700. The problem occurred when I upgraded to the Ubuntu 8.10 release candidate last week. I then did a total re-installation today from CD, and it occurred while booting from CD, and after it's been installed.

I want to note a few additional times this behavior arises:

1. When shutting down. Occasionally I need to hold a key down to shut-down.
2. In terminal mode. I booted to "safe mode" today to install NVidia drivers - I believe Run Level 1? - and the behavior occurred there. While using the NVidia installer, I often had to press a key to get the installer to proceed to the next step.

I don't think this problem has anything to do with booting, per se, but with either kernel run-level or graphical mode. If I knew how to boot Ubuntu into a higher run-level that stayed in text mode, I'd try it out to see which is the likely culprit.

Has this problem only been seen in Mandriva and Ubuntu? Until it is resolved, I might migrate to Fedora OpenSUSE for a while, as I really want to use the new kernel (it should be able to support my wireless via athk5 without manually installing madwifi).

I saw this same behavior last week with the Fedora 10 Beta Live DVD, so
it isn't just Mandriva & Ubuntu with this problem.

Sean Seaman wrote:
> Has this problem only been seen in Mandriva and Ubuntu? Until it is
> resolved, I might migrate to Fedora OpenSUSE for a while, as I really
> want to use the new kernel (it should be able to support my wireless via
> athk5 without manually installing madwifi).
>
>

Paul H (slipaway172) wrote :

I too am also expierencing this problem. The problem also existed when i initally booted from the boot cd to install ubuntu.

Trinh Thanh Trung (tntonlyvn) wrote :

I have encountered similar problem

My system spec is:

HP Pavilion dv6810us
- AMD Turion 64 X2 mobile technology TL-60 / 2 GHz
- NVIDIA GeForce 7150M Shared video memory (UMA)

And only Ubuntu 8.10 is affected. Hope there'll soon be an update that solve the problem

I just would like to report that I am experiencing the same bug on Intrepid 64 bit.

I was running Hardy previously, this issue was not present. I did a clean install of Intrepid, at which point the issue started happening.

My hardware:

HP Pavilion dv6810u
- Processor: 64-bit 2.0 GHz AMD Turion 64 X2 TL-60 dual-core
- Video Card: Nvidia GeForce Go 7150

I was able to work around the issue by adding "acpi=noirq" at the end of the following line

kernel /boot/vmlinuz-2.6.27-7-generic root=UUID=c877e76e-7e7f-4b47-aec7-6ae28d1ab767 ro quiet splash

on /boot/grub/menu.lst

Trinh Thanh Trung (tntonlyvn) wrote :

Thanks all, option "acpi=noirq" worked fine with me, since nolapic and noapic didn't

Looking forward to a new updates. Thanks Ubuntu for all the hard work.

Paul H (slipaway172) wrote :

as trinh said, adding "acpi=noirq" to the kernel boot parameters will resolve the issue. but this is still a problem and needs to be resolved. Im also verifying that the boot parameter does fix the issue on my hp laptop too.

Makoto (makotothedragon) wrote :

Confirming bug on my machine after a "fresh" install.

Machine: Compaq Presario F761US: 1.9GHz Athlon X2, nVidia 7000M graphics card

uname -a: Linux LATLON-Callisto 2.6.27-7-generic #1 SMP Thu Oct 30 04:18:38 UTC 2008 i686 GNU/Linux
version_signature: Ubuntu 2.6.27-7.15-generic

Attachments to follow.

Makoto (makotothedragon) wrote :
Mark Grandi (markgrandi) wrote :

this happens all the way back in the 2.6.26 kernel, as i just tried installing sidux which uses the linux-image-2.6.26-3.slh.1-sidux-686"
 kernel, and i still have to hold a button down to boot/shutdown

description: updated
description: updated
ls (schildm) wrote :

I have the same problem on my HP dv6545 with Nforce/Geforce 7150 with intrepid.

SRElysian (srelysian) wrote :

I noticed this seems to be a plague on HP Pavilion laptops. I've been experiencing the same problem on my dv9610us since the install of 8.10 beta (now official). I tested it with acpi=off to find that it booted just fine but no power management with that option (which is no good for a laptop you intend on actually using portably). I will try the acpi=noirq option and wait out a fix.

apostledeets (apostledeets) wrote :

This problem effects the HP Pavilion dv9727cl as well. The acpi=noirq option does work though.

Hi Everyone,

I'd like to specifically point out comment https://bugs.launchpad.net/ubuntu/+bug/272247/comments/40 from tglx, who is an upstream kernel developer:

"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."

@EmigrantMTChris, since you are the original bug reporter, would you be willing to open the usptream bug report? I myself do not have the hardware to reproduce this so would not be able to provide the necessary debugging information. Additionally before creating the upstream bug report, it would be great if you could confirm that this still exists with the latest upstream kernel. You can use the following wiki to help with building and testing the upstream kernel https://wiki.ubuntu.com/KernelTeam/GitKernelBuild . Assuming the bug also exists after testing the upstream kernel, if you could then please post the link to the upstream bug report here for others to track that would be great. We can also set up an upstream bug watch as well. Thanks in advance.

Mark Grandi (markgrandi) wrote :

if i get a free moment before or during the weekend i will open an upstream bug report.

Spike (spikenick) wrote :

I would like to confirm this bug on my AMD dv6700 hope we can get a fix for this soon, it effects a large part of the community.

Trogdorn (basser08) wrote :

I also have this bug on an HP dv6700. The startup will complete if I push the computer power on button just once. I suspect it has something to do with power management since the problem is way worse when on battery.

SRElysian (srelysian) wrote :

I can confirm that "acpi=noirq" fixes the problem on the "HP Pavilion dv9610us". I am starting to notice a trend, heh. I am actually curious to know how many of these plagued pavilion laptops originally had "vista" on them :P I know mine did, and I was proud to be rid of it.

rafaeljcg (rafael-jcg) wrote :

same problem on my HP dv6000 (after upgrade and fresh install)
workaround: add "acpi=noirq" apparently solves the problem

Spike (spikenick) wrote :

another boot parameter that might kick it in the pants temporarily and that the dev might want to know about here is hpet=disable I really do hate the idea of a boot parameter being required I hate regression like that

I have the same problem on HP dv9820us laptop, but adding the parameter worked.

Cesar Arguinzones (ceap80) wrote :

Maybe this in not the right place to ask... in that case please forgive me.
But can anybody explain or point to some place where acpi=noirq is explained.
I just don't want to exchange a problem for another
From http://www.kernel.org/doc/Documentation/kernel-parameters.txt
acpi=noirq -- do not use ACPI for IRQ routing
but what this really mean?

I'm not sure what exactly it does. Although as noted above, it affected
other things on my system like the volume control buttons becoming
erratic. I removed the noirq parameter, and am just living with the boot
freezing for now.

> Maybe this in not the right place to ask... in that case please forgive
> me.
> But can anybody explain or point to some place where acpi=noirq is
> explained.
> I just don't want to exchange a problem for another
>>From http://www.kernel.org/doc/Documentation/kernel-parameters.txt
> acpi=noirq -- do not use ACPI for IRQ routing
> but what this really mean?
>
> --
> 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.
>

Spike (spikenick) wrote :

Just wanted to reiterate that if you use hpet=disable that it disables a certain cpu process clocking timer that allows it to get past the freeze, and unlike noirq it does NOT affect the volume buttons and other things.

ArangeL (softwarej) wrote :

Thanks Spike, "hpet=disable" work too. :-)
Could be "hpet=disable" better than "acpi=noirq"?

I think I would see this as better, I do not get any resulting NOTICABLE
hardware bugs such as bios integrated features like the quickbuttons.

On Thu, Nov 6, 2008 at 4:22 PM, ArangeL <email address hidden> wrote:

> Thanks Spike, "hpet=disable" work too. :-)
> Could be "hpet=disable" better than "acpi=noirq"?
>
> --
> 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: New
> Status in Ubuntu Release Notes: New
> Status in "linux" source package in Ubuntu: Triaged
> Status in "usplash" source package in Ubuntu: Invalid
> Status in "linux" source package in Mandriva: Invalid
>
> Bug description:
> Binary package hint: usplash
>
> 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 sometime works is
> to add nolapic to GRUB boot kernel options.
>
> 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
> HP Pavilion DV6620es
> Compaq Presario F700
> Sony Vaio PCG-GRT-815E - from the Mandriva errata
> HP DV6745us - from a duplicate
> HP DV6545eg Notebook - from duplicate
>
>
>

--

    ~Nicholas Bischof~

I upgraded my hp pavilion dv9000 last night from hardy to intrepid with the same issues. Attached are relevant files

I've filed a bug report at bugzilla.kernel.org

http://bugzilla.kernel.org/show_bug.cgi?id=11973

Saivann Carignan (oxmosys) wrote :

EmigrantMTChris : You forgot to attach your version.log, uname-a.log, dmesg.log and lspci-nnvv.log on the upstream bug report, can you attach these files? Thanks for forwarding the bug upstream.

Changed in linux:
importance: Undecided → Unknown
status: New → Unknown
Rad3k (trueradzian) wrote :

I have the same here on HP Pavilion dv6840ew (amd64, nvidia).

I wouldn't recommend using "acpi=noirq" - it "solved" the issue, but I haven't been able to start X using proprietary Nvidia driver. Then I tried using nv instead and started X, but strange things happened - e.g. when I connected to wireless network (using proprietary broadcom driver), the mouse cursor stopped responding, then keyboard, and soon I was left with only one option - hard reset. I've tried it again then and got the same results.

I've also tried other mentioned options - "nolapic", "nosmp" and "hpet=disable" - at this point I can say that each worked and I haven't noticed any side effects, but I really can't say for sure that there aren't any. For now I'll stick to "hpet=disable" and if I notice some strange behavior I'll post about it here.

I have the same issue with HP dv9608 laptop. It seems like usb problem on 2.6.27 kernel. Here is the link to solved Mandriva bug https://qa.mandriva.com/show_bug.cgi?id=45552
I hope this'll help Ubuntu teem to fix it soon.

Changed in linux:
status: Unknown → Confirmed
Debian God!! (debianlife) wrote :

HP dv6602 au affected by this bug. I downgraded to hardy!!!

ubuntusky (ubuntuskyx) wrote :

I think something is wrong with system clock during the boot process.

with "vga=791" ,shutdown can also go through without black screen issue

wribeiro (wribeiro) wrote :

I found a side effect for "hpet=disable":
In my HP Pavilion dv6000 (6646US) the remote control stoped working
- AMD Turion 64x2
- nvidia graphics
- Broadcom wireless
- Ubuntu 8.10 (i386)

Scott Minster (sminster) wrote :

"hpet=disable" seems to work well for me on my HP Pavilion dv6810us running 64bit Ubuntu (dual core AMD64, nvidia graphics). I don't have any problems with the remote or volume controls. The only side effect that I've noticed is that I can now successfully suspend the machine, but resume never comes back. Of course, resume didn't work without disabling hpet either, it was just a lot harder to suspend without that option. I suspect that whatever is causing the error on boot is also affecting resume.

This weekend, I will try to do more testing on different options. But "hpet=disable" seems to be a reasonable workaround for the time being.

wribeiro (wribeiro) wrote :

I tested again and the remote control now is working fine, even with "hpet=disable". Maybe it stopped because of something else.
I confirm the same behavior described above by Minster about suspend/resume.
=> AMD Turion 64x2; nvidia graphics; Broadcom wireless; Ubuntu 8.10 (i386)

SRElysian (srelysian) wrote :

It had just dawned on me to test my remote last night to find it worked... litterally... once. I have no idea what the deal is there but judging by the last few messages here n there, it seems that this might be tied in to this same on-going issue. I have the dv9610us (Turion64x2, nVidia, etc), can anyone confirm/deny it works with hpet=disabled or apci=noirq .. I tried both, the noirq option let me use it once, the hpet is a no-go for me. Also, it's become a pain to physically test it since HP just inserted a reciever that ties in to KB control mimicing, I can't seem to find a physical port it's attached to, alteast nothing that's labeled to the degree that I could find it by browsing /dev/ which means "irdadump" is a no-go and lsinput shows nothing useful. Any ideas would be great... I really hate finding malfunctioning hardware.. especially weeks after initial install.

thegizmoguy (thegizmoguy) wrote :

Confirmed as well on Pavilion dv6646us (amd, nvidia, broadcom). No problems on 8.04. This is something that should be "critical" level because I would expect this out of an alpha...not a final release.

Debian God!! (debianlife) wrote :

In my honest opinion downgrading to hardy and waiting for the 9.04 will be sensible. No developer seems to be interested in this issue. I mean this is only MY opinion.
Cheers,
DebianGod

Morten Minke (morten-amagi) wrote :

I now have been working with ibex for a while and the strange thing is that most of the time this bug is not bothering me anymore. And I mean I do --not-- use any kernel parameters (I have heard of all kinds of side effects, so if my system requires the keypress, I just keep the shift key pressed).

If I start at work in the morning I connect my external monitor, my usb mouse and a network cable and the system boots nicely. However, as soon as I reboot the machine I am in trouble. If I return home in the evening, like 95% of the time everything goes allright and I can boot, but a reboot gives me troubles again.

I know this sounds strange, but this is truly happening.

One more thing to add.
Short power button pressing at the begining of the boot-up process help me don't hold a keyboard button during boot-up. I have no splash screen.

Ney Fabrício (neyfabricio) wrote :

High expectation abou Intrepid, but it slowed me down with this bug... the hpet=disable option worked fine here, but it doesn't seem to fit like the perfect solution, I guees. And I was just happy about my Broadcom Wireless working with native drivers, not the ndiswrapper workaround! But the Ibex let me down with this usplash/keypress/kernel bug. My laptop is a Pavillion dv6650br from HP, all that nVidia stuff inside. Thanks for the hard work!

nitto (nitto) wrote :

Hi all,
I have a Pavilion dv6915nr (AMD Turion 64x2, nvidia graphics 7150M, nvidia MCP67, ubuntu 8.10)
Linux nittux 2.6.27-8-generic #1 SMP Thu Nov 6 17:38:14 UTC 2008 x86_64 GNU/Linux

I have a little new trick, If I start the laptop without the power supply, I wait for the process to freeze AND THEN I plug the power supply, the process re-start without any further key-press. It seems similar to the solution hitting the power button.
Can anybody confirm the same behavior?

Nitto,
In my HP DV6604NR (AMD 64, NVidea) i have exactly the same trick.

wribeiro (wribeiro) wrote :

Yes, I confirm the same behavior with my Pavilion dv6000 (6646us).

danielbooy (deinonychai) wrote :

Re-confirm that Nitto's trick works on a dv6000 (DV6812NR).

Trond Thorbjørnsen (tthorb) wrote :

Re-confirm that Nitto's trick works on a dv6000 (DV6812NR).

Trond Thorbjørnsen (tthorb) wrote :

Re-confirm that Nitto's trick works on a dv6000.

Opr8iVe (shutterjockey) wrote :

Nittos trick also works with my dv9000 (DV9700us)

-jason

Opr8iVe (shutterjockey) wrote :

Also, just tried the "hpet=disable" workaround, and other than loosing the boot splash screen, have seen no other side effects.

Could the rtc-cmos module be screwey? And what am I really sacrificing (if anything) by not running the high precision event timer?

-Jason

dino99 (9d9) wrote :

i've upgraded to Intrepid from Hardy and got this bug too.
What i can say:
- i don't need any specific parameter to boot, i'm just waiting about 20 seconds
- when i start my desktop, all is ok and the led on the ethernet port is on (green light), then boot process start and AT THIS TIME the led turn off (so, no more net).
- booting in verbose mode (without quiet and splash), i see that boot process hang when it try to identify eth0, but can't because ethernet port is off, ... waiting about 20 seconds, then the led move to 'orange light' and the boot process goes on.

It seems that something is wrong with the modules load order.
i've filled a bug about some of them:
https://bugs.launchpad.net/ubuntu/+bug/296710

dino99 (9d9) wrote :
dino99 (9d9) wrote :
dino99 (9d9) wrote :
dino99 (9d9) wrote :
Debian God!! (debianlife) wrote :

In My honest opinion, this is not going to be fixed. Why I am saying this is
because I faced the same problem in 7.10 It never got fixed :( I will now
wait for 9.04
A Grey given during life is better than Orchids on the grave....

On Sun, Nov 16, 2008 at 11:45 AM, dino99 <email address hidden> wrote:

>
> ** Attachment added: "network.log"
> http://launchpadlibrarian.net/19690848/network.log
>
> --
> 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.
>

nitto (nitto) wrote :

Hi all,
I'm trying a kernel bisect, I attached my log until now if somebody is trying the same thing, even if I don't know if just this file is useful.
Anyway, I did not finish yet, I'm running it since yesterday but it takes a lot of time...
I have still 90 revision to test (I started with almost 18000) but as I understood the problem came out in the 2.6.26-rc9 version, I'm still seaching which specific revision.
2.6.26-rc8 seems to be free from the bug but 2.6.26 is affected

Some revisions of the 2.6.26-rc9 are affected, some others no.

I'll probably work on it again the next weekend.

Bye
Nitto

Nitto,

I don't know how easy it is to move between versions, but you may prefer using an algorithm like this:

Starting with revisions from 1 to 90 to check,

startrevision=1
finalrevision=90
while startrevision < finalrevision
    If revision startrevision don't has the bug
        If revision finalrevision has the bug
            middle=(startrevision+finalrevision)/2
            if revision middle has the bug
                startrevision=middle+1
                finalrevision=finalrevision-1
            else (middle don't has the bug)
                startrevision=startrevision+1
                finalrevision=middle-1

It's commonly used in programming, but also very easily applicable in real life. It will help you find quickier with what revision the problem started. Oh, my description of the algorithm should have some bugs, but I'm trusting that you're human and will not get into an infinite loop :P

Just to make it clearer: divide the area of your search by two, check if the middle element of it has the bug, if it has it, it should have started in the first half, if not, it should have started in the second half. Then, repeat the procedure.

Ops, big mistake in the algorithm description,

            if revision middle has the bug
                startrevision=middle+1
                finalrevision=finalrevision-1
            else (middle don't has the bug)
                startrevision=startrevision+1
                finalrevision=middle-1

should have been

            if revision middle has the bug
                startrevision=startrevision+1
                finalrevision=middle
            else (middle don't has the bug)
                startrevision=middle+1
                finalrevision=finalrevision-1

Probably still bugged, but it should work for a human.

dijon (daniel-delaney) wrote :

'morning

I have the same issue on my HP6065EA laptop with both amd64 and i386 versions of 2.6.27-7, hitting any key keeps the boot going. Adding pci=noacpi allows me to start without pressing any keys, for both architectures.

chest069 (chest069) wrote :

Hello,

I am having the exact same issue as everyone else and did not have this issue in 8.04 but it has become a pain in 8.10.

How do I put in the "pci=noacpi" to test and see if it works on my machine? If it works how do I make it permanent so I don't have to enter it again until the problem is fixed.

I think it may be a usb problem of some sort based on what others are saying. So checking the way it is loading the usb drivers maybe with the kernel might be the problem? I am not sure but my guess.

Also is there a way to submit any info to the Ubuntu people for my Laptop for them to look at in trying to figure this out?

Thanks.

chest069 (chest069) wrote :

Hello,

pci=noacpi worked for me when pressing escape and then editing the kernel line to include it.

So I just need to know how to add this so I don't have to type it in all the time.

This is in 8.10 by the way.

Thanks.

nitto (nitto) wrote :

cchester, you should be able to put this string on the relative row in the /etc/fstab file.

Leandro Pereira de Lima e Silva, the procedure used for the bisect (git) already implement an algorithm like this. I don't know exactly how is it implemented but it jumps from a revision to an other narrowing the possibilities.
Each kernel compilation takes me 1 hour and half so I couldn't have been tried 18000 different revision without jumping.
'git bisect' do it for you, if somebody wants to try it is quite easy, it's only time consuming.
I was new with this procedure but i found all the informations following the link indicated in the previous posts and if you have some trouble maybe you can contact me in a private message.

Oh, ok, great :-)

Strider (strideronmoon) wrote :

I installed Ibex on my HP dv6910us laptop and am experiencing the same problem.
(AMD Turion-X2, nvidia graphics 7150M, nvidia MCP67 , Kernel 2.6.27-7)

Strider (strideronmoon) wrote :
Strider (strideronmoon) wrote :
Strider (strideronmoon) wrote :
Chris Knittel (argosreality) wrote :

So still no cause let alone fix other than unplugging and plugging the power cable back in?

Try booting with
hpet=disable

On Tue, Nov 18, 2008 at 7:40 PM, Chris Knittel <email address hidden> wrote:

> So still no cause let alone fix other than unplugging and plugging the
> power cable back in?
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Triaged
> Status in "usplash" source package in Ubuntu: Invalid
> Status in "linux" source package in Mandriva: Invalid
>
> Bug description:
> Binary package hint: usplash
>
> 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 sometime works is
> to add nolapic to GRUB boot kernel options.
>
> 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
> HP Pavilion DV6620es
> Compaq Presario F700
> Sony Vaio PCG-GRT-815E - from the Mandriva errata
> HP DV6745us - from a duplicate
> HP DV6545eg Notebook - from duplicate
>
>
>

chazsheen (chrismuellner) wrote :

I can confirm that this bug is also affecting me with an HP DV6704nr laptop (AMD64 X2, nVidia 7150M, etc.). Nitto's trick does work as well as holding down the button. I noticed this immediately from booting up the LiveCD as without the power supply being plugged in it hung up at the boot and with the power supply plugged in it booted.

Previously had 8.04 installed with no problems. Did a clean install with 8.10 and ran into this issue immediately - booting with no splash screen shows that I'm hanging at the same spot. Same with shutdown/restart.

rawdmon (raw-dmon) wrote :

I can confirm that this is happening to me as well after upgrading from Ubuntu Hardy to Intrepid. I have an Asus M3N-HT Deluxe Mempipe (with latest BIOS update) with a Phenom 9850+ Black Edition processor. When booting the initial boot process will get stuck on one message, then I need to press any key approximately 3 times for it to continue to the next message. Then I need to repeat the same process of pressing any key 3 times to progress to the next message. Eventually the system will proceed to boot on it's own once it hits the steps where it is loading up modules and daemons.

I noticed that it seems to especially get hung up with the following message (or similar):

[25.488258] hub 3-0: 1.0: Unable to enumerate USB device on port 3

Here are some system details (dmesg log is included):

root@nemesis:/home/raw# uname -a
Linux nemesis 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux

root@nemesis:/home/raw# cat /proc/version_signature
Ubuntu 2.6.27-7.16-generic

rawdmon (raw-dmon) wrote :

Oh, I forgot to mention that it freezes up the first time right after I see the following message:

[ 0.004000] Aperture pointing to e820 RAM. Ignoring.
[ 0.004000] Your BIOS doesn't leave a aperture memory hole
[ 0.004000] Please enable the IOMMU option in the BIOS setup
[ 0.004000] This costs you 64 MB of RAM

...and sometimes it will proceed past that message on it's own to the following message and then freeze:

ACPI: Expecting a [Reference] package element, found type 0

rawdmon (raw-dmon) wrote :

Here is the link for the Aperture issue which has also been logged as a bug:

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

I'm not sure if the two issues are related or if the Aperture message has always been there and people have just been noticing it more because of this freezing issue.

Cristian Molina (megatux) wrote :

Also afecting Compaq Presario 756, very annoying

nitto (nitto) wrote :

I finished the kernel bisect, after a week of discontinuous work on it

My result is:
6924d1ab8b7bbe5ab416713f5701b3316b2df85b is first bad commit

I do not know if the commit hash is good enough to recognize which is the bugged version of the kernel. If not, how can I extract something more specific regarding the version with git?

I hope, somebody will help the community solving this bug.
Thanks
Nitto

I attach my log too..

Saivann Carignan (oxmosys) wrote :

nitto : Are you able to know which revision number this is?

nitto (nitto) wrote :

Do you know how to extract it from git?

The only informations I have are the hash, and the following description:
commit 6924d1ab8b7bbe5ab416713f5701b3316b2df85b
Merge: 4e78c91... 25556c1... b764a15... 437a0a5... 41b3eae... 84e65b0... 684eb01... 9302213... 5cb04df... 44974c8... 48cf937... 205f932... c54f9da... 0ed368c... b478458... 2d144e6... 607baf1... 33af903... 3557b18... 63687a5... 009b9fc... f6477cc... e6b0ede... 400d349...
Author: Ingo Molnar <email address hidden>
Date: Tue Jul 8 09:16:56 2008 +0200

    Merge branches 'x86/numa-fixes', 'x86/apic', 'x86/apm', 'x86/bitops', 'x86/build', 'x86/cleanups', 'x86/cpa', 'x86/cpu', 'x86/defconfig', 'x86/gart', 'x86/i8259', 'x86/intel', 'x86/irqstats', 'x86/kconfig', 'x86/ldt', 'x86/mce', 'x86/memtest', 'x86/pat', 'x86/ptemask', 'x86/resumetrace', 'x86/threadinfo', 'x86/timers', 'x86/vdso' and 'x86/xen' into x86/devel

The version number should be the 2.6.26-rc9

I don't know how to reach the revision number.

Saivann Carignan (oxmosys) wrote :

Leann Ogasawara : Any idea on this?

rawdmon (raw-dmon) wrote :

Has anyone else noticed that the new kernel is causing system instability as well? I'm constantly coming back to my computer being frozen on a black screen after leaving it running for a few hours. Not sure if anyone else is observing this behaviour? This only started after the upgrade.

nitto (nitto) wrote :

I have some trouble recovering the section from a suspend but this problem come from other things and I had no time to look for a solution. Maybe you computer enters in suspension after some time of inactivity. You can disable this behavior or search for a solution of the problem (and if you find it you can also mail it to me :-)).

Hi nitto,

Thanks for doing the bisect, it's much appreciated. The sha1 id you've narrowed down was actually applied to the 2.6.27-rc1 kernel. Unfortunately, you'll notice from the description you posted it's merging in quite a few changes. You can view the specific patches by doing 'git log -p 6924d1ab8b7bbe5ab416713f5701b3316b2df85b' However, it would be good if you could post this info to the upstream bug report also - http://bugzilla.kernel.org/show_bug.cgi?id=11973 . I'll try to nudge the Ubuntu kernel team about this as well. Thanks.

Philip (sundiver) wrote :

Hi all,
IMPORTANT!!!!

I have a HP pavillion dv9610us Laptop with same problem with aperture and key press to boot up. However I have only seen one other post about plugging in the power supply or battery charger after booting freezes with battery power only.

To duplicate try this............
I boot with battery power only and let the status bar freeze or stop. Then plug in the charger and it finishes the boot without any key press. This almost acts like a hardware problem with a timer switch not functioning.
.

rawdmon (raw-dmon) wrote :

Philip, this seems to possibly have something to do with ACPI (in part), which is the power management in general. It's either that, or it's the kernel recognizing the power supply much as it would recognize a usb device (since there's been reports that plugging in a USB device has much the same behaviour as you are describing).

Scott Minster (sminster) wrote :

Nitto, thanks for your work with the git bisect. Are you able to use the last good kernel (b764a15f679942a7bc9d4f9645299e1defcc5b43 in the bisect log) without any major problems, like wakeup from suspend? Maybe this could be packaged as a workaround kernel for those of us affected by this bug until it is fixed in the kernel.

nitto (nitto) wrote :

Hi Scott,
I'm not sure the b764a15f679942a7bc9d4f9645299e1defcc5b43 is the last good before the bad one. Because when I performed the bisection, after the last bad, the process started jumping forth and back in the kernel version, also to the 2.6.26rc2 (I sow it from the created file names). This behavior was for me a little strange, I don't know if it can be normal or not. I'm a bit doubtful. This is way I'm performing an other bisect. It was my first bisect, now, I read something more.

Anyway, regarding the wakeup from suspend I remember I had the same problem even in ubuntu 8.04, I think it is related to something other. I'll check using an old kernel version if the problem of suspension is still there.

spudly (spudly) on 2008-11-27
description: updated
SRElysian (srelysian) wrote :

I am going to ask a dumb question here, I've done a bit of research but can't seem to find a good explanation as to what the consequences are so I figured I'd ask here just to get the record straight for myself as well as anyone else with this issue trying to get the same information. So far I've seen a few different options that bypass the problem;

acpi=off (disables power management completely and I personally wouldn't suggest)

acpi=noirq
nolapic

Which is best to use? All documentation I've found seems to state these 2 things are not the same. At current, I am using the apci=noirq, but I am not sure what that actually does, and if perhaps nolapic would be better. Just figured I'd get the best solution until this problem can be properly fixed as opposed to "triaged".

rafaeljcg (rafael-jcg) wrote :

SRElysian,
maybe this answer your question:

Kernel Parameters->
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt

2008/11/27 SRElysian <email address hidden>
>
> I am going to ask a dumb question here, I've done a bit of research but
> can't seem to find a good explanation as to what the consequences are so
> I figured I'd ask here just to get the record straight for myself as
> well as anyone else with this issue trying to get the same information.
> So far I've seen a few different options that bypass the problem;
>
> acpi=off (disables power management completely and I personally wouldn't
> suggest)
>
> acpi=noirq
> nolapic
>
> Which is best to use? All documentation I've found seems to state these
> 2 things are not the same. At current, I am using the apci=noirq, but I
> am not sure what that actually does, and if perhaps nolapic would be
> better. Just figured I'd get the best solution until this problem can be
> properly fixed as opposed to "triaged".
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Triaged
> Status in "usplash" source package in Ubuntu: Invalid
> Status in "linux" source package in Mandriva: Invalid
>
> Bug description:
> Binary package hint: usplash
>
> 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 sometime works is to add nolapic to GRUB boot kernel options.
>
> 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
> HP Pavilion DV6620es
> HP Pavillion DV9700z
> Compaq Presario F700
> Sony Vaio PCG-GRT-815E - from the Mandriva errata
> HP DV6745us - from a duplicate
> HP DV6545eg Notebook - from duplicate
>
>

description: updated
SRElysian (srelysian) wrote :

rafaeljcg: thanks for the link, it was full of all sorts of useful information and I have bookmarked it accordingly.

I found another issue which I suspect may possibly be a result of this on-going bug, however, since I am not sure I was hoping I could get some insight from a few guys frequenting this but report. Since alot of you with this problem seem to have the same chipset (nvidia), I'd like to ask if any of you also have problem with your consoles.

CTRL-ALT-F1 -> F6 have not worked for me since I installed Intrepid beta. It actually seems to be erratic, while diagnosing the problem I had a few consoles open, "tail -f "-ing the following log files:

/var/log/Xorg.0.log
/var/log/kern.log
/home/<user>/.xsession-errors

I could not find anything refecting any sort of error when switching to console, however during repeated tests, the console would randomly start working, and then stop working. After a while my keyboard sort-of went hay-wire out requiring a reboot.

It seems to me that this apci/lapic issue is the only one plaguing these laptops and I am curious as to whether or not it might be related. I'd be more than happy to provide any alternative log files and information anyone requires, or a link to another bug or perhaps a general "you did <this> wrong, or forgot to do <that>". I am fresh out of Ideas.

My laptop is:

HP Pavilion dv9610us (add that to the list of problematic systems if it isn't already (dv9000 series))
gfxcard: nVidia GeForce 7150M @ 1440x900
cpu: AMD Turion(tm) 64 X2 Mobile Technology TL-58 @ 1.9GHZ

bloomtom (bloomtom) wrote :

Hi I have the same issue as everyone else here.
Posting my logs, I hope they help.

bloomtom (bloomtom) wrote :

...

bloomtom (bloomtom) wrote :

yawn

bloomtom (bloomtom) wrote :

...

rawdmon (raw-dmon) wrote :

I just updated to kernel version 2.6.27-9 from 2.6.27-7. The new version does nothing to address this issue. Is this being looked at? It's definitely the most annoying bug that I've ever seen in Linux.

mgroyas (mgtroyas) wrote :

Same problem here, Ubuntu Intrepid (just updated from Hardy) on a HP dv6612es laptop. Very annoying.

nitto (nitto) wrote :

Ok, I finished an other bisect, this time the result is a bit different because I skipped more revision (sometimes I could not compile them) but the last bad version is included as possible bad.

This is the message I got:

There are only 'skip'ped commit left to test.
The first bad commit could be any of:
1a750e0cd7a30c478723ecfa1df685efcdd38a90
7dbceaf9bb68919651901b101f44edd5391ee489
437a0a54eea7b101e8a5b70688009956f6522ed0
5136dea5734cfddbc6d7ccb7ead85a3ac7ce3de2
6924d1ab8b7bbe5ab416713f5701b3316b2df85b
We cannot bisect more!

The last one is the one I got the last time.

I hope this will be my last bisect for a while.... :-)

Leann Ogasawara , how can you extract the kernel version from the sha1 hash?
I ask you this because when I compile the revision (using make-kpkg) the resulting kernel version when the problem arise is the 2.6.26-rc9 and not the 2.6.27-rc1.

Thanks, I hope in a fast bug solving.

nitto (nitto) wrote :

I forgot to attach the bisect log

Stefan Bader (smb) wrote :

The bisected merge seems also to touch timer interrupt issues through the io apic and in another upstream kernel bug I found some hints suspecting something there. Also there was a comment claiming the combination of "noapic lapic" would prevent the stops. This would be more proof to that theory. Also is there anything seen when looking at the output of /proc/interrupts (especially IRQ0/timer), which always should increase.

Changed in linux:
assignee: ubuntu-kernel-team → stefan-bader-canonical
Morten Minke (morten-amagi) wrote :

I do not want to mix bugs here, but I think I have an issue which might be related to this one because of the powerplug in/out trick which also makes the boot continue. Apparently something is triggered by this action.

What I now found out is that if my laptop is running I can connect to wireless networks. However, if I need to unplug the powercord (while my laptop is running), my wireless light starts blinking very rapidly and I have no wireless network anymore.

Again, I do not want to make cross bug reports, but I would like to verify with people having the startup problem, if they also encounter this same issue with the wireless/powercord combination?

Trond Thorbjørnsen (tthorb) wrote :

This isn't a problem on my laptop.
I have an HP Pavillion dv 6000.

$ lspci -v|grep -A8 -i netw
03:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03)
        Subsystem: Hewlett-Packard Company Device 1367
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at b0200000 (64-bit, non-prefetchable) [size=16K]
        Memory at b6000000 (64-bit, prefetchable) [size=1M]
        Capabilities: <access denied>
        Kernel driver in use: ndiswrapper
        Kernel modules: wl, ssb

Perpetual (landonab) wrote :

Trond Thorbjørnsen, interesting. Mine is a DV6000 (6910US) and the problem exists still, including the Jaunty Daily Builds. Is your DV6000 a US laptop?

Trond Thorbjørnsen (tthorb) wrote :

No, I'm sorry - I was a bit short here.

The main issue is a problem for me (see further up the thread).

I was addressing Morten Minke's problem:
"I do not want to mix bugs here, but I think I have an issue which might be related to this one because of the powerplug in/out trick which also makes the boot continue. Apparently something is triggered by this action."

The main issue has two different workarounds for me:

1. Attach the power cord during boot
2. Add nolapic in kernel options

(acpi=noirq didn't work last time I tried)

Perpetual (landonab) wrote :

Trond Thorbjørnsen, no problem. Thanks for the clarification.

worb (mike-worb) wrote :

There is a real solution for this. The issue is caused by problems with interrupt system, which is why any I/O event (holding the shift key, connecting/disconnecting power) are a workaround.

There are advanced boot options available that make the install work fine -

Add the options noapic and nolapic to the boot command line.

Cesar Arguinzones (ceap80) wrote :

I don't think thats a real solution, because sometimes there are unwanted side effects, I for example can not boot with nolapic and have to use hpet=disable to do it successfully. Other peoples had problems with other boot options.

ep (epepin) wrote :

Hi, I've got the same issue and I'm kind of a n00b. Could someone please describe where to add hpet=disable in the menu.lst file? Thanks.

rawdmon (raw-dmon) wrote :

You'll see a line in /boot/grub/menu.lst that looks something like this:

kernel /boot/vmlinuz-2.6.27-9-generic root=UUID=4c5d576a-7d38-43b2-b1d0-9bb18fdae820 ro quiet pci=nomsi

Just add the option to the end of the line, so that it looks something like:

kernel /boot/vmlinuz-2.6.27-9-generic root=UUID=4c5d576a-7d38-43b2-b1d0-9bb18fdae820 ro quiet pci=nomsi hpet=disable

Perpetual (landonab) wrote :

I tried openSUSE 11.1 RC1 today with Linux kernel 2.6.27.7 and it boots fine. Still, no luck with Ubuntu, Mandriva or Fedora. Not sure what is different with openSUSE. How would I figure this out?

On Sun, Dec 07, 2008 at 11:47:07PM -0000, Perpetual wrote:
> I tried openSUSE 11.1 RC1 today with Linux kernel 2.6.27.7 and it boots
> fine. Still, no luck with Ubuntu, Mandriva or Fedora. Not sure what is
> different with openSUSE. How would I figure this out?

It would be worth seeing what kernel command line options are in use
when booting on openSUSE from /proc/cmdline, and also a full dmesg
output from a boot there which might contain some hints as to any quirks
the kernel has applied during boot which may help. For one it would be
worth looking which clock source is slected in both a working and
non-working kernel.

thegizmoguy (thegizmoguy) wrote :

Not really helping but I can confirm what Perpetual said about OpenSUSE 11.1 RC 1 not having this problem.

Andy Whitcroft (apw) wrote :

On Mon, Dec 08, 2008 at 02:14:47AM -0000, thegizmoguy wrote:
> Not really helping but I can confirm what Perpetual said about OpenSUSE
> 11.1 RC 1 not having this problem.

If you can get a dmesg output for booting your machine with your Ubuntu
release, and the OpenSUSE releases and attach them here it may help us
understand the difference between the two which is allowing OpenSUSE to
work on your hardware.

thegizmoguy (thegizmoguy) wrote :

(Linux Noob)

If you could tell me how to do that dmesg output with the OpenSUSE liveCD (since the ubuntu problem happens with its liveCD as well as installation) I'd be happy to help.

Scott Minster (sminster) wrote :

thegizmoguy, you can get a dmesg output by opening a terminal and running `dmesg'. You can do this as a normal user; you don't need to be root. Generally, you'll probably want to redirect that to a file by running something like `dmesg > dmesg.txt'. Then you can upload dmesg.txt here.

On another note, I tried booting my system with my old Hardy 2.6.24 kernel that was still on my system. It seems to still work, and doesn't have this bug. I can suspend and wakeup without too much trouble. For some reason, I have to rmmod and modprobe ath_pci and restart nm-applet to get the wireless working after the wakeup. This didn't happen with Hardy, but I don't think it's related to this bug.

I'm not sure what the long term effects of running the older kernel would be, but I think I'm going to try it for a while.

thegizmoguy (thegizmoguy) wrote :

I suppose long term effects are not getting the latest fixes. From my reading it looks like every kernel update is sent out with the best of intentions to fixing many more bugs between hardware-software integration than it creates. Not to mention possible performance increases as well as additional feature support.

Thanks for the mini-tutorial. I'll do it ASAP but finals are coming up and I need my XP until I have time to migrate my emails and such.

still_fil (filblue) wrote :

Hi all!

I have exactly the same bug on my HP Pavilion dv6000. And yesterday I found something that maybe can help with understanding this issue. It usually requires several key-presses to make system continue booting, but when it first time freezes and I press Power button (not hold, just quick press) - it is booting to the end without freezes.

CptanPanic (cptanpanic) wrote :

Just wanted to say I have this same problem with Toshiba Satellite A35-S139 I tried hpet=disable to no avail. Note I also booted with Fedora 10 live cd and it has the same problem.

Russell Green (r.green) wrote :

Has anyone tried the latest -rc kernel?

Marvin Clavey (mhclavey) wrote :

still_fill suggested to press the power button .... that worked for me also on my dv6000.
thanks for the hint.

Russell Green (r.green) wrote :

I had a problem with debian etch where I had to press the power button at the begining of the boot for it to work, I figured with it not happening on ubuntu on a later kernel I never bothered reporting it thinking that it was fixed upstream.

SRElysian (srelysian) wrote :

>Just wanted to say I have this same problem with Toshiba Satellite A35-S139 I tried hpet=disable to no avail. Note I also >booted with Fedora 10 live cd and it has the same problem.

Try "acpi=noirq" and see if that helps you.That's the one I've been using on my Pavilion dv9610.

ArangeL (softwarej) wrote :

Ok, GOOD NEWS!
This error WAS FIXED IN KERNEL 2.6.28 (FINAL VERSION).

Now "Ubuntu Kernel" Team must do a update to "Intrepid" and "Jaunty" to fix this and more errors.

Thanks to all people that help the community to found the fix.

---
I just make/compile a "default configuration" kernel 2.6.28; And I don't need to use "hpet=disable", "acpi=noirq", or "hold a key down" to boot properly.

Andy Whitcroft (apw) wrote :

On Fri, Dec 26, 2008 at 01:31:48AM -0000, ArangeL wrote:
> Ok, GOOD NEWS!
> This error WAS FIXED IN KERNEL 2.6.28 (FINAL VERSION).
>
> Now "Ubuntu Kernel" Team must do a update to "Intrepid" and "Jaunty" to
> fix this and more errors.
>
> Thanks to all people that help the community to found the fix.

The Juanty kernel has now been rebased to 2.6.28 final and uploaded. So
perhaps you could test that kernel and report back.

Dilan Gilluly (dg14813) wrote :

I had the same problem on Linux Mint 5 main edition, i decided to try the XFCE community addition, no boot freezes, back to mint 5 main edition, problem persists, back to mint 5 xfce, works fine, it's something to do with gnome. My laptop is a compaq persario f700.

Yep. linux-image-2,6,28-4 works very
 nicely. (Downloaded just 30min ago.) No extra
boot arguments are required. You may close the bug report.

Andy Whitcroft wrote:
> On Fri, Dec 26, 2008 at 01:31:48AM -0000, ArangeL wrote:
>> Ok, GOOD NEWS!
>> This error WAS FIXED IN KERNEL 2.6.28 (FINAL VERSION).
>>
>> Now "Ubuntu Kernel" Team must do a update to "Intrepid" and "Jaunty" to
>> fix this and more errors.
>>
>> Thanks to all people that help the community to found the fix.
>
> The Juanty kernel has now been rebased to 2.6.28 final and uploaded. So
> perhaps you could test that kernel and report back.
>

Alex Gryson (alex-grysonweb) wrote :

Intrepid running on an HP Pavillion dv6527ea.
Suffered from this bug, tried the suggested workaround (nolapic) which didn't work, the boot sequence would stop completely and not even keystrokes would nudge it along.
Using acpi=noirq works like a charm though, apart from a few short pauses here and there which I didn't have with Hardy. Otherwise the problem is fixed for me.

description: updated
ArangeL (softwarej) wrote :

I can confirm that this BUG was fixed in "2.6.28-4", that was uploaded to Ubuntu 9.04 "Jaunty" Alpha 2.

¡PLEASE!, "Ubuntu Kernel Team", add this kernel in to Ubuntu 8.10 "Intrepid" too. I like to boot, again, like 8.04, without any problems :-).

Thanks.

thegizmoguy (thegizmoguy) wrote :

I'm going to go so far as to say that if this bug isn't fixed within a week in 8.10 then I'm declaring Ubuntu a release-and-run OS and moving completely to Arch Linux.

Am Montag, den 29.12.2008, 06:21 +0000 schrieb thegizmoguy:
> I'm going to go so far as to say that if this bug isn't fixed within a
> week in 8.10 then I'm declaring Ubuntu a release-and-run OS and moving
> completely to Arch Linux.
>
No one is forcing you to use ubuntu. Linux is all about freedom of
choice. I commented about this bug 2 months back and I am waiting for
this to be resolved. Right now I am using ubuntu 8.04 without any
problems (you can do the same if you wish to). If you are so much in
need of intrepid then download the kernel from kernel.org and compile it
yourself. Stop posting these non-sense messages. If not for this distro,
it would have been difficult for linux to reach this postion it has now.
Have a nice day!!!
cheers,
Debian God

Mark Grandi (markgrandi) wrote :

thegizmoguy, your asking too much, i am effected by this bug, but they cant just release a whole new (VERY new by ubuntu's standards) kernel for the entire ubuntu community just becuase a small part of the users are effected by this bug, it would introduce even more problems then what they have now with this bug.

Sorry you feel that way gizmoguy, but I am sorry to say the threats of one
person aren't going to change anything. I've been using intrepid since beta,
and have been dealing with the problem since then. I've been using a boot
variable to get around it and the problem itself doesn't really bother me so
long as I CAN boot. I also feel that the ability to run KDE 4.2b2 (which I
believe runs far better than 4.0-4.1), far out-weighs a small triagable
problem. Also, the reason linux is far more stable than windows as a whole,
is because they test things before just releasing them, even if a kernel fix
has been found they aren't just going to hand it out to the masses without
it being released in testing first. Because fixing 1 little problem someone,
and causing it to break for many others is unacceptable. I'd suggest you
have a little more patience and appreciation for people whom work hard
without getting paid to bring such an excellent operating system. And as
someone else stated, if you don't like it, try another distro, this board is
for bug reports, save the rants for forum trolling please.

On Mon, Dec 29, 2008 at 06:21:19AM -0000, thegizmoguy wrote:
> I'm going to go so far as to say that if this bug isn't fixed within a
> week in 8.10 then I'm declaring Ubuntu a release-and-run OS and moving
> completely to Arch Linux.

If we knew which of the 9.5k commits fixed this issue we would happily
backport it to Intrepid.

Hi guys,
  I just finish to test my Compaq presario F756 with Jaunty Alpha2 and the
bug continues.

sorry

PD: the bug with nokia phones & USB cable also continues.

On Mon, Dec 29, 2008 at 3:05 PM, SRElysian <email address hidden> wrote:

> Sorry you feel that way gizmoguy, but I am sorry to say the threats of one
> person aren't going to change anything. I've been using intrepid since
> beta,
> and have been dealing with the problem since then. I've been using a boot
> variable to get around it and the problem itself doesn't really bother me
> so
> long as I CAN boot. I also feel that the ability to run KDE 4.2b2 (which I
> believe runs far better than 4.0-4.1), far out-weighs a small triagable
> problem. Also, the reason linux is far more stable than windows as a whole,
> is because they test things before just releasing them, even if a kernel
> fix
> has been found they aren't just going to hand it out to the masses without
> it being released in testing first. Because fixing 1 little problem
> someone,
> and causing it to break for many others is unacceptable. I'd suggest you
> have a little more patience and appreciation for people whom work hard
> without getting paid to bring such an excellent operating system. And as
> someone else stated, if you don't like it, try another distro, this board
> is
> for bug reports, save the rants for forum trolling please.
>
> --
> 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.
>

--
-----------------------------------------------------
  .^. In an open world, who needs windows or gates?
  /V\ Cristian Molina
 // \\ GNU/Linux User #73047, Ubuntu User # 14733
/( _ )\ BsAs-Argentina
 ^^ ^^ ---------------------------------------------

Mark Grandi (markgrandi) wrote :

ill try it with my compaq presario f767NR tonight and confirm to see if this is fixed or not since we now have conflicting reports

Russell Green (r.green) wrote :

Cristian: Are you using the -4 kernel?

Cristian Molina (megatux) wrote :

On Mon, Dec 29, 2008 at 11:43 PM, Russell Green
<email address hidden>wrote:

> Cristian: Are you using the -4 kernel?
>
> --
> 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.
>

Hi Russell,
   this Jaunty alpha use 2.6.28-3 version. I hope that in -4 version this
bug is fixed. I'll try to test that version later.
--
-----------------------------------------------------
  .^. In an open world, who needs windows or gates?
  /V\ Cristian Molina
 // \\ GNU/Linux User #73047, Ubuntu User # 14733
/( _ )\ BsAs-Argentina
 ^^ ^^ ---------------------------------------------

Russell Green (r.green) wrote :

You will get -4 from update manager, its fixed in that.

Debian God!! (debianlife) wrote :

Now if the -4 is backported to intrepid it will be great. Just a
suggestion though. And only if it doesn't break the system.

Sent from my iPod touch

On 31.12.2008, at 03:53, Russell Green <email address hidden>
wrote:

> You will get -4 from update manager, its fixed in that.
>
> --
> 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.

I'm a big fan of linux and I hate windows more than sin, so yeah. I have a Compaq F700 with these problems previously described, and I've downloaded all updates and no bug fixes so far... so right now I'm running an older version (8.04) so when the bug fix makes it into updates can someone notify me so I can upgrade? Awesome, thanks guys, as a programmer I appreciate your work greatly.

Jeff Burns (admiraljkb) on 2009-01-12
description: updated
SRElysian (srelysian) on 2009-01-13
description: updated
Download full text (3.7 KiB)

I have a compaq f700 and it just installed an updated kernel which
seams to have fixed it for me

On 1/13/09, SRElysian <email address hidden> wrote:
> ** Description changed:
>
> 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
> - HP Pavilion DV6620es
> - HP Pavillion DV9700z
> + Nvidia MCP67 Chipset
> Compaq Presario F700
> Compaq Presario F763NR
> Sony Vaio PCG-GRT-815E - from the Mandriva errata
> - HP DV6745us - from a duplicate
> - HP DV6545eg Notebook - from duplicate
> - HP DV6736nr
> + HP Pavilion DV6545eg Notebook - from duplicate
> + HP Pavilion DV6736nr
> + HP Pavilion DV6745us - from a duplicate
> + HP Pavilion DV6620es
> + HP Pavilion DV9610us
> + HP Pavilion DV9700z
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Triaged
> Status in "usplash" source package in Ubuntu: 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.2...

Read more...

I'm running 64 bit and I still haven't gotten a kernel update, so it just must be 32 bit?

Jordan Dunn (jordunn) wrote :

I'm using 64bit, but I have unsuported and backported updates turned on

On 1/13/09, Montag <email address hidden> wrote:
> I'm running 64 bit and I still haven't gotten a kernel update, so it
> just must be 32 bit?
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Triaged
> Status in "usplash" source package in Ubuntu: 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
>
>

--
Sent from my mobile device

Perpetual (landonab) wrote :

Jordan Dunn, which kernel is working for you on 8.10? I did a clean install last night with backports enabled and did not see a 2.6.28 kernel in the updates.

Can anyone confirm if this has been backported to 8.10??

2009/1/15 Perpetual <email address hidden>

> Jordan Dunn, which kernel is working for you on 8.10? I did a clean
> install last night with backports enabled and did not see a 2.6.28
> kernel in the updates.
>
> --
> 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.
>

--
A Grey given during life is better than Orchids on the grave....

SRElysian (srelysian) wrote :

I haven't seen the 2.6.28 kernel either, really hoping it makes it in, since
it's a ways off before they release Jaunty. I have enough beta'd software on
this laptop as it is, I prefer not to make it worse.

On Thu, Jan 15, 2009 at 8:58 AM, Perpetual <email address hidden> wrote:

> Jordan Dunn, which kernel is working for you on 8.10? I did a clean
> install last night with backports enabled and did not see a 2.6.28
> kernel in the updates.
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Triaged
> Status in "usplash" source package in Ubuntu: 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
>
>

Chris Coulson (chrisccoulson) wrote :

As it appears that this is fixed in Jaunty, I'm going to mark this as fixed. It has already been nominated for Intrepid, so could somebody please add an Intrepid task which we can keep open?

Thanks

Changed in linux:
status: Triaged → Fix Released
SRElysian (srelysian) wrote :

No offense to you sir, but I really wouldn't consider it fixed when the
problem is still present in the current "official" release. The only ways to
fix it are to either A) compile the kernel yourself, or B) dist-upgrade to
an Alpha testing release. As well, the distro listed when the bug-report was
filed is intrepid, not jaunty. As of now, we don't get the 2.6.28 kernel,
thus, it is not really fixed at all.

On Thu, Jan 15, 2009 at 10:31 AM, Chris Coulson <
<email address hidden>> wrote:

> As it appears that this is fixed in Jaunty, I'm going to mark this as
> fixed. It has already been nominated for Intrepid, so could somebody
> please add an Intrepid task which we can keep open?
>
> Thanks
>
> ** Changed in: linux (Ubuntu)
> Status: Triaged => Fix Released
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Fix Released
> Status in "usplash" source package in Ubuntu: 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
>
>

Joschi Holaubek (erwin-zsi) wrote :

On 01/15/2009 04:31 PM, Chris Coulson wrote:
> As it appears that this is fixed in Jaunty, I'm going to mark this as
> fixed. It has already been nominated for Intrepid, so could somebody
> please add an Intrepid task which we can keep open?
>
> Thanks
>
> ** Changed in: linux (Ubuntu)
> Status: Triaged => Fix Released
>

As Jaunty is not due for another 3-4 months you can hardly call this
"fixed".

The present situation is that we have the choice of laying a telephone
book on the keyboard during startup or else use the nolapic switch and
work with only one of the two CPU cores.

As long as there is no procedure to boot on this chipset that actually
works (i.e. a kernel update or whatever), setting this bug to "fixed" is
a slap in the face of users.

Thx, E.R.

--
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Erwin Rennert, IT Services
Center for Social Innovation

A-1150 Wien, Linke Wienzeile 246
Austria, Europe
Phone: ++43-1-495 04 42 - 61
Facsimile: ++43-1-495 04 42 - 40
http://www.zsi.at/

Chris Coulson (chrisccoulson) wrote :

It is policy to set a bug as 'fixed' if it is fixed in Ubuntu, whether that is in the development release or not. It is fixed in Jaunty, therefore the bug should be set to "Fix Released". The bug has been nominated for Intrepid, which can be accepted by somebody more privileged than me and will result in an Intrepid task being opened against the bug, which will remain open until it is fixed in Intrepid.

@SRElysian, @Joschi Holaubek -- I think you have missunderstood. What
has happened is the Linux task has been closed. This task _always_
represents the bugs state in the development release, in this case
Jaunty. Which as I understand things has the fixes for this issue.
There is a nomination for Intrepid which once accepted will become the
status for the onging work on this bug. That one is not closed.

Approving intrepid nomination.

Changed in usplash:
status: New → Invalid
Download full text (3.3 KiB)

I suppose I jumped the gun a bit and I appologize, I am sure you understand
I myself, as well as many others (as you can see by the growing number of
posts in this thread), have been dealing with this issue since 8.04 (if I
remember correctly). I was under the impression that now that it is marked
as fixed according to Jaunty that we will be neglected and forced to suffer
through screwy flag fixes until Jaunty becomes official. There have been
quite a few bugs in Intrepid that I over-looked because they intended to fix
it eventually (Like bluetooth being completely un-usable unless you install
the gnome manager). Seems to me that kernel level bugs effecting an entire
chipset, plaguing an entire line of laptops (primarily any HP Pavilion
laptop with nvidia on board), would be a priority. So long as we aren't
dismissed and forgotten, I am content with waiting. Again, I appologize.

On Thu, Jan 15, 2009 at 11:44 AM, Andy Whitcroft <email address hidden> wrote:

> @SRElysian, @Joschi Holaubek -- I think you have missunderstood. What
> has happened is the Linux task has been closed. This task _always_
> represents the bugs state in the development release, in this case
> Jaunty. Which as I understand things has the fixes for this issue.
> There is a nomination for Intrepid which once accepted will become the
> status for the onging work on this bug. That one is not closed.
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Fix Released
> Status in "usplash" source package in Ubuntu: Invalid
> Status in linux in Ubuntu Intrepid: New
> 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 Man...

Read more...

thegizmoguy (thegizmoguy) wrote :

There is always the option of moving to a rolling release distribution where you'd already have the .28 kernel.

Mark Grandi (markgrandi) wrote :

for this to get fixed in intrepid we need to find out what exactly got applied to the .28 kernel that fixed this issue, so they can just apply that patch to the intrepid kernel. I have no idea how to do this, does anyone here know?

SRElysian (srelysian) wrote :

That's hard to say, from what I read the .28 kernel has some
brand-spanking-new stuff in it. Supposedly, it works in Intrepid as is. I've
been poking around on random forums and blogs and found that there are quite
a few people now who are temporarily adding the Jaunty repos` just long
enough to steal the new kernel and it's been working for them. There are a
few other's whom compiled the kernel and had success as well. I also heard
there may be problems with that new kernel and nvidia drivers, but it may
have been remedied.

On Thu, Jan 15, 2009 at 1:44 PM, Polygon <email address hidden>wrote:

> for this to get fixed in intrepid we need to find out what exactly got
> applied to the .28 kernel that fixed this issue, so they can just apply
> that patch to the intrepid kernel. I have no idea how to do this, does
> anyone here know?
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Fix Released
> Status in "usplash" source package in Ubuntu: Invalid
> Status in linux in Ubuntu Intrepid: New
> 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
>
>

Chris Coulson (chrisccoulson) wrote :

Thanks for opening the Intrepid task Leann

Changed in linux:
status: New → Triaged
importance: Undecided → High

Hi guys, I took your suggestions and went ahead and typed acpi=noirq in the boot text file and it no longer freezes. I'm running a Compaq f700 with Intrepid v. 8.10, and it's 64 bit. No updates had fixed the problem previously, but this works. You probably already know this but when I was installing 8.10 64 bit I actually had to hold keys during the beginning of the installation. I'm assuming the screwed up kernel boots during the install, so if that's the case then it makes sense. Anyway, yeah good work guys. Keep it up, I'm a fairly new linux user and I'm diggin' it.

By beginning of the installation I mean I had to hold keys to get certain things such as "scan the cd, install grub, etc" to load. Sorry for being vague. Anyway, peace.

just to add i was having the boot hang up issues. i had done a complete format and fresh install of Intrepid Ibex 8.10. I did the "hpet=disable" and issue, for now, is resolved. So thanks everyone!

Compaq F676NR
w/ AMD Turion 64 X2
NVIDIA GeForce 7000M

wribeiro (wribeiro) wrote :

Bad news: I've just updated to kernel 2.6.27-11 and the problem is still here.

Using hpet=disable everything seems fine.
- HP Pavilion dv6000us, AMD Turion 64x2, nVidia, Broadcom wireless
- Ubuntu 8.10 i386

Thank you!!

Perpetual (landonab) wrote :

In Jaunty, daily build 1/25/2009, this problem still exists with linux-image-generic 2.6.28.5.5.

crjackson (crjackson) wrote :

Okay, so I have read through the comments and can't get a clear grasp. The status if this bug is Fix Released but it sounds like the problem is still there.

I recently convinced my younger brother to convert to Ubuntu and he has one of the affected HP Turion systems. He can't boot a 32-bit distro at all, and can boot the 64-bit distro using the keyboard spacebar method using Intrepid Ibex 64-bit.

Is it possible to make this problem go away fairly easily or should he just go with 8.04? Since 8.10 is already installed and works fine short of this issue, 8.10 is preferred.

Thanks

Download full text (3.7 KiB)

I actually don't believe this problem is fixed at all. I "messed" with
jaunty when I had heard that this problem was fixed in the 2.6.28 kernel but
experienced erratic keyboard/mouse behavior. Might just be me but I never
had the problem in intrepid. Now, I am not sure exactly what your problem is
with the 32bit version crjackson, I do know (having the dv9610us myself),
that it takes a bit of... coaxing... to get it to install out-right. My
laptop refused to boot into the GUI until i pulled up a direct console
(ctrl-alt-f1), customized the xorg.conf file and added the ' Driver "vesa" '
for the video display, then did a 'sudo /etc/init.d/kdm restart'. That
allowed me to install the OS and actually will copy that xorg.conf to the
main drive. After which, I connected it to the net via cat5, installed
"b43-fwcutter" (i believe is the file) which enabled my wireless, then
installed nvidia-glx-180 and re-edited my conf file and changed the driver
to "nvidia". Once all that was done i restarted KDE and was good to go with
accelerated drivers. Everything after that is a breeze.

On Fri, Jan 30, 2009 at 6:18 PM, crjackson <email address hidden>wrote:

> Okay, so I have read through the comments and can't get a clear grasp.
> The status if this bug is Fix Released but it sounds like the problem is
> still there.
>
> I recently convinced my younger brother to convert to Ubuntu and he has
> one of the affected HP Turion systems. He can't boot a 32-bit distro at
> all, and can boot the 64-bit distro using the keyboard spacebar method
> using Intrepid Ibex 64-bit.
>
> Is it possible to make this problem go away fairly easily or should he
> just go with 8.04? Since 8.10 is already installed and works fine short
> of this issue, 8.10 is preferred.
>
> 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: New
> Status in "linux" source package in Ubuntu: Fix Released
> 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 nvid...

Read more...

Mark Grandi (markgrandi) wrote :

I can confirm that this bug is now fixed for my Compaq F764NR laptop. I just downloaded the jaunty daily live cd (for 1/31/09) and it booted from the cd without me pressing or doing anything special (like kernel parameters)

Perpetual (landonab) wrote :

Polygon, same live image still fails to boot for me. Yay me...

Mark Grandi (markgrandi) wrote :

I am not sure if you guys have already but you should post your laptop model and make, since apparently you guys are experiencing a different bug then whats being discussed here, or its different but similar in nature.

also another confirmation that the fix that was released will confirm that we have 2 different bugs on our hands

Perpetual (landonab) wrote :

I posted my info at the very beginning, HP - DV6910US. Same motherboard as mentioned at the beginning, MCP-67.

ArangeL (softwarej) wrote :

This BUG are AGAIN here with the kernel "2.6.28.2".
Was fixed in kernel "2.6.28"; i think that stay fixed in "2.6.28.1"; but i have the same issue in "2.6.28.2".

This is a BAD new :-(

Perpetual (landonab) wrote :

I don't see where it has been fixed upstream.

http://bugzilla.kernel.org/show_bug.cgi?id=11973

So, I don't see how it could be fixed downstream.

Jeff Burns (admiraljkb) wrote :

I confirmed that Ubuntu Jaunty Beta 3 (both LiveCD and after being installed) boots fine on the HP/Compaq F763NR laptop. That has kernel 2.6.28-4.

Perpetual (landonab) wrote :

I am downloading Alpha 3. Jeff Burns, have you tried the daily builds by any chance?

Perpetual (landonab) wrote :

Alpha 3 still requires holding a key during boot.

So, if this is now something different...how do I go about figuring out what is the new problem that exhibits the same issue as the bug reported here?

SRElysian (srelysian) wrote :

If i am not mistaken, the Jaunty alpha series boots from the 2.6.27 kernel
series with the problem on install. What actually fixes the problem is the
2.6.28 kernel you can update to. If it doesn't show up in the normal
updates, try checking pre-release or unsupported. If people are getting this
to work fully feedback would probably be a good idea. As I stated in a
previous post, I tried out the new jaunty, and while the 2.6.28 series
kernel did fix the boot problem, I experienced erratic behavior with the
mouse&keyboard. It would act as if keys were being held down and actually
would randomly paste things into windows and chats as I was typing,
ultimately after not finding where the problem was coming from, I went back
to intrepid with the "acpi=noirq" option which works best for me on my HP
dv9610us.

On Sun, Feb 1, 2009 at 10:21 AM, Perpetual <email address hidden> wrote:

> Alpha 3 still requires holding a key during boot.
>
> So, if this is now something different...how do I go about figuring out
> what is the new problem that exhibits the same issue as the bug reported
> here?
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Fix Released
> 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
>
>

nitto (nitto) wrote :

I was wondering that I can try the 2.6.28 kernel using git in Ubuntu 8.10. don't want to change ubuntu version because I'm working on important things with my pc at the moment. Do you think I can use git to install the new kernel and trying it regarding the bug?

Maybe I'll try later in the day.

Nitto

nitto (nitto) wrote :

Oh.. My laptop is a HP pavilion dv6915nr

description: updated
description: updated
SRElysian (srelysian) wrote :
Download full text (3.8 KiB)

In regards to the GIT question, I have not tried it.. but I came across this
which might be something for you to look at... it's a "zen" kernel for
2.6.28.

https://wiki.kubuntu.org/ZenKernel

On Sun, Feb 1, 2009 at 2:55 PM, Morten Minke <email address hidden>wrote:

> ** Description changed:
>
> 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
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Fix Released
> 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
> Distro...

Read more...

nitto (nitto) wrote :

Is the Bug #254668 a duplicate of this bug? Or vice versa?

The description and the behavior look equal to the bug on my laptop

No luck with GIT, yet

SRElysian (srelysian) wrote :

Tell-tale signs are the apci issues, and the nvidia MCP67 chipset, and it's
HP :/ all the Pavilion laptops with the AMD solution instead of Intel seem
to be effected. But I believe that but report is geared towards mandriva's
kernel, while this one is for ubuntu. I may be wrong tho, but they are
essentially the same problem.

On Mon, Feb 2, 2009 at 12:18 AM, nitto <email address hidden> wrote:

> Is the Bug #254668 a duplicate of this bug? Or vice versa?
>
> The description and the behavior look equal to the bug on my laptop
>
> No luck with GIT, yet
>
> --
> 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: New
> Status in "linux" source package in Ubuntu: Fix Released
> 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
>

Perpetual (landonab) wrote :

Just an update, I downloaded the Daily Build with Linux 2.6.28.6-6 and the live cd booted directly to a desktop with no hangs. I will install tonight and see if the installed image boots properly.

Perpetual (landonab) wrote :

Update to my last post. This is issue still exists with the daily builds. I can not find a bug report open for Jaunty. Is there one? If not I assume one should be opened.

Jeff Burns (admiraljkb) wrote :

Further report confirming that as of Jaunty Alpha 3 (upgraded from Alpha 2 directly rather than from the liveCD) things are good for this bug on my HP/Compaq F763NR laptop (with MCP67 rev a2 chipset). Currently running Alpha4 and it's still good, and the Alpha4 CD boots OK. I'm now at kernel 2.6.28-7, although as I write this, it's updating to 2.6.28-8... AND 2.6.28-8 just booted ok as well. I'm pretty close to upgrading my primary work partition from Intrepid to Jaunty primarily to get rid of this annoyance. If nothing else, it's a real headache when explaining to doubtful buddies how Ubuntu Linux is absolutely ready for General Purpose office usage, and then I had to hold a key down during boot... Generates serious eyerolls from them and some embarrassment for me... Perception is everything unfortunately, even if this is minor bug it generates an immediate negative impression for newbs before the desktop has even come up, and that colours the whole "out of box experience". I'm so glad to see it fixed for my hardware combination!

I've had good luck with kernels:
2.6.28-6
2.6.28-7
2.6.28-8

Perpetual (landonab) wrote :

Alpha 4 still fails on my HP DV6910US as do the daily builds as of 2/18/09.

One thing weird that I noticed a couple of daily builds back...when I first try the live cd it will boot directly to a desktop. If I reboot and try the live cd again, it will not work anymore...I have to hold a key. I am not sure why it works once, I think on daily build even worked twice but after that the problem returns.

Saivann Carignan (oxmosys) wrote :

Setting status back to Triaged since this bug is still confirmed by most of people including the initial bug report, and since the upstream bug report isn't fixed.

Changed in linux:
status: Fix Released → Triaged

I upgraded to Jaunty tonight, and it is fixed for me now, using kernel 2.6.28-8-generic.

On a side note, Jaunty seems pretty impressive so far. Very nice for an alpha release.

Saivann Carignan (oxmosys) wrote :

According to the fact that initial reporter confirms that the latest jaunty kernel fixed the bug, I'm changing status to "fix released". If someone can still reproduce the same issue with a completely up-to-date jaunty, please open a new clean bug report with a reference to bug 272247.

EmigrantMTChris : Thank your very much for your confirmation. Don't hesitate to let a comment if the bug come back at any point.

Changed in linux:
status: Triaged → Fix Released
Changed in ubuntu-release-notes:
status: New → Invalid
ArangeL (softwarej) wrote :

¿"Jaunty" will be relased with kernel 2.6.28-8 or with the last 2.6.28.9-x (for example)?

Saivann Carignan (oxmosys) wrote :

Please don't use bug reports to ask support questions. Bugs that have a lot of subscribers get spammed each time a comment is added and the bug report become unusable.

Stefan Bader (smb) on 2009-03-02
Changed in linux:
assignee: nobody → stefan-bader-canonical

I can confirm that Jaunty Alpha 6 has fixed this bug for me on a HP G6065EA with the nVidia MCP67 based hardware, not sure if any earlier Alphas had the problem fixed as I have had a few time constraints preventing me from testing them.

Mark Grandi (markgrandi) wrote :

this bug is not fixed for me.

i have reported a new bug as instructed: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/342374

TJ (tj) wrote :

If you are affected by this issue with a Jaunty kernel *and* the Nvidia MCP67 chip-set, please add your reports to Polygon's new report, bug #342374 which I've renamed as a master for MCP67-based issues "Nvidia MCP67 system freezes on boot unless key is held down (continuation of #272247)".

67GTA (67gta) wrote :

I just stumbled across this bug. I have a HP dv6815nr laptop with the MCP67 chipset. I was able to get rid of this problem by applying a custom DSDT file.

http://ubuntuforums.org/showthread.php?t=1036051&highlight=dsdt

67GTA (67gta) wrote :

I forgot to mention that this is some kind of bug/conflict with some HP laptops because the DSDT was compiled using Microsofts home brewed compiler. The Linux kernel/acpi do not like it. The aml compiler(iasl) in my how to was made by Intel, and is supposed to be universal. Microsoft is now pushing their version to Bios manufacturers, so this will probably only get worse in time.

Rad3k (trueradzian) wrote :

67GTA:
Man, it worked! And, more importantly, it also fixed wake from suspend for me (it got broken in Intrepid).
Thanks!

On Tue, 2009-03-24 at 22:38 +0000, 67GTA wrote:
> I just stumbled across this bug. I have a HP dv6815nr laptop with the
> MCP67 chipset. I was able to get rid of this problem by applying a
> custom DSDT file.

Could you attach the faulty DSDT *and* the custom DSDT so we can look at
working around the problem?

To extract the DSDT, name it usefully, and compress it:

sudo apt-get install dmidecode
MODEL=$(sudo dmidecode -s system-product-name)
BIOS_VERSION=$(sudo dmidecode -s bios-version)
sudo cat /proc/acpi/dsdt | cat - >${MODEL}-${BIOS_VERSION}-ORIGINAL.aml
gzip ${MODEL}-${BIOS_VERSION}-ORIGINAL.aml

For the custom DSDT it only needs:

gzip </etc/initramfs-tools/DSDT.aml >${MODEL}-${BIOS_VERSION}-CUSTOM.aml.gz

nitto (nitto) wrote :

It works for me too. Bug solved on HP Pavilion dv6915nr (even if not the suspension, but this is an other bug probably).

Just one thing should be correct in http://ubuntuforums.org/showthread.php?t=1036051&highlight=dsdt at row:

sudo cat /proc/acpi/dsdt > dsdt.dat

It should be :

sudo cat /proc/acpi/dsdt > dsdt.alm

I attach my .alm files as requested by TJ.

nitto (nitto) wrote :
nitto (nitto) wrote :
TJ (tj) wrote :

On Wed, 2009-03-25 at 11:45 +0000, nitto wrote:
> It works for me too. Bug solved on HP Pavilion dv6915nr (even if not the
> suspension, but this is an other bug probably).
>
> I attach my .alm files as requested by TJ.

Thanks nitto. I forgot to mention one very important thing, though -
when collecting the -ORIGINAL version the custom DSDT shouldn't be
installed from initrd otherwise the two images are the same!

The best way is probably to boot into an earlier kernel where the custom
DSDT hasn't been added to its initrd image, or alternatively boot from a
live-CD and write the DSDT image to the system's hard disk and then post
it to the bug report once the system has been restarted.

nitto (nitto) wrote :

I suspected it :-)

Here is the true original version of the file, gotten using the previous kernel.

67GTA (67gta) wrote :

I will add mine in case mine and nitto's aren't exactly the same. The "dv6700" covers a lot of HP laptops. I also added the workaround here so that /proc/acpi/thermal_zone/THRM would be populated: https://wiki.edubuntu.org/LaptopTestingTeam/HPdv5z

67GTA (67gta) wrote :
Mark Grandi (markgrandi) wrote :

hmm. I tried following that guid to fix my dsdt, and iasl provided me with 203 errors and it crashed on me, so i have no idea if a custom dsdt file (where do i get this custom dsdt file anyway? ) works,

and i would of posted my original file here, but when i copy and paste TJ's commands, i get the error

bash: ${MODEL}-${BIOS_VERSION}-ORIGINAL.aml: ambiguous redirect

yeah.....

nitto (nitto) wrote :

Hi Polygon,
you need to open the .dsl file with an text editor and fix the file by yourself. Maybe you can get a fixed file for your system in one of the website linked in the article but basically you need to fix it by yourself.
It seems difficult but not so much. Search for solution to your specific errors on google and in the links present in the article.

After fixed, the errors start decreasing and maybe you can run iasl without crashes.
Regarding the TJ commands, I got the same error and I edited the file manually once created, I did like this:

sudo apt-get install dmidecode
(on a not corrected environment)
sudo cat /proc/acpi/dsdt | cat - >ORIGINAL.aml
sudo dmidecode -s system-product-name
sudo dmidecode -s bios-version
I copied and pasted the last two results in the ORIGINAL.aml file name
gzip <your_details>-ORIGINAL.aml

For the custom DSDT it only needs:

gzip </etc/initramfs-tools/DSDT.aml >CUSTOM.aml.gz
then rename the file as before

I hope it's more clear now.

Morten Minke (morten-amagi) wrote :

This solution also fixed it for my HP Pavilion dv9000 ( dv9645ed ) on Ubuntu 8.10

I had about 12 errors which were very easy to fix.

theosophe74 (theosophe74) wrote :

This bug affects me with a Dell OptiPlex 760 and, if it makes a difference, a Radeon HD 3400 graphics card.

I have to hit keys continuously to make the startup complete, whether in regular mode or recovery mode.

Please let me know what the currently recommended short-term and/or long-term fix is.

SRElysian (srelysian) wrote :

I just noticed something I haven't before.. I may have previously stated that the new kernels being used in Jaunty fix the issue, but for the first time in a very long time I booted my laptop via battery instead of the power cord and it went back to it's same old shenanigans. I was forced to use the shift key to boot the system, then it locked up (though later I found the lockup was due to a custom setting I was using for my Intuos3 tablet, while the tablet was not connected).

I think I will look into this custom DSDT file and see if it resolves the issue for Jaunty as well. This is quite upsetting though, if what 67GTA says is true, this problem is not going to go away for a while. Just when we think Linux is becoming easier to use and thus more widely accepted, someone throws a handful of nails under our wheels. :/

Same issue here, unfortunately.

My laptop is plugged in 99% of the time, and is almost always plugged in
while booting. After reading this email, I unplugged it, and rebooted.
The issue is still there for me when running on battery power. There's a
good chance that this was never fixed properly, as this was the first
time that I rebooted on battery power since reporting that it was fixed
for me.

I didn't have the problem with the system locking up as noted below,
once booted everything works fine.

SRElysian wrote:
> I just noticed something I haven't before.. I may have previously stated
> that the new kernels being used in Jaunty fix the issue, but for the
> first time in a very long time I booted my laptop via battery instead of
> the power cord and it went back to it's same old shenanigans. I was
> forced to use the shift key to boot the system, then it locked up
> (though later I found the lockup was due to a custom setting I was using
> for my Intuos3 tablet, while the tablet was not connected).
>
> I think I will look into this custom DSDT file and see if it resolves
> the issue for Jaunty as well. This is quite upsetting though, if what
> 67GTA says is true, this problem is not going to go away for a while.
> Just when we think Linux is becoming easier to use and thus more widely
> accepted, someone throws a handful of nails under our wheels. :/
>
>

Perpetual (landonab) wrote :

As I have said before, this has never been fixed, still exists in 4/3/09 daily build. The Linux Kernel Bug is marked Regression but I have seen no activity there. Very disappointing but in Ubuntu's defense, all distributions are effected by it. Too bad for us HP owners I guess.

Mark Grandi (markgrandi) wrote :

Hi, has anyone else tried the dsdt thingy to see if that fixes it?

Also, an above poster said i should look at a linked site to find a already made dsdt file for my laptop model....which website is this?

67GTA (67gta) wrote :

Sorry, wrong link. This site is no longer updated, so if it is a newer computer, you probably won't find anything.

http://acpi.sourceforge.net/dsdt/edit.php

Mehall (mehall) wrote :

Hey all, i was looking at smaller ones that were dupes of this, just found this.

It seems to be upstream, since I've had issues in other distros also.

Here's what I have tried:

Copied the debug instructions from wiki, added own comments: (it's all fairly clear)

Try booting with the "acpi=off" kernel parameter
This will disable ACPI support. If the error is the same with acpi enabled and disabled, this may not be an ACPI issue.
If "acpi=off" allows the system to boot, try to isolate the ACPI issue with the following boot parameters

Did that, boots fine then

Try booting with "acpi=ht"
This disables all of ACPI except just enough to enable Hyper Threading. If acpi=off works and acpi=ht fails, then the issue is in the ACPI table parsing code itself, or perhaps the SMP code.
Try booting with "pci=noacpi"
This disables ACPI for IRQ routing and PCI scanning.
Try booting with "acpi=noirq"
This disables ACPI for IRQ routing.

All the above make it boot fine.

Try booting with "pnpacpi=off"
This disables the ACPI component of the Linux Plug and Play code.
Try booting with "noapic"
Disables the IO-APIC for IRQ routing or PCI scanning.

Those two options make it boot, but same as original bug, need to press keys to force it to boot.

Try booting with "nolapic"
Disables the local APIC

Boot fails at:

"ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00:qc timeout (cmd 0xec)
ata3.00: failed to IDENTIFY (I/O erroor, err_mask=0x4)"

that's the main thing, then it says "Gave up waiting for root device" and then lists common issues, etc.

Drops to Busybox.

hardware: HP G6062ea, Atheros Wifi, nVidia 7000m nForce 610m, AMD Athlon X2 64 TK-57 1.9GHz

Didn't happen in older kernels, not tried Jaunty yet.

description: updated
DEFHol (dfleener) wrote :

My bug report #290129 was marked as a duplicate of this bug. I can confirm that it is the same, and booting with "acpi=off" or "acpi=noirq" makes the system boot without halting. I didn't try any other boot options. I updated to Jaunty recently, and the bug is gone, meaning that I can boot normally without any extra boot options.

Scott Minster (sminster) wrote :

I tried the method of fixing my DSDT, and was able to fix several errors. This seemed to fix the requirement for "hpet=disable" to workaround the startup problem. It also allowed for /proc/acpi/thermal_zone to be correctly populated.

However, it did not fix the suspend/resume problem (suspend works, but the machine doesn't resume). Also, while fixing the DSDT is probably the "right" solution, I don't know how well it would work for a less technical Ubuntu user.

ArangeL (softwarej) wrote :

Ok, NOW i have all my problems (about Linux and my laptops) fixed! :)
I can now suspend, resume, hibernate, wakeups, etc my system without any problem :D.

I fix it with a custom DSDT that i have made. I am going to upload it here.

There are any solution or something that "Ubuntu Kernel's Team" with HP Pavilion with Vista Preinstalled and Bad DSDT?

Spike (spikenick) wrote :

This sucks the past couple of days with jaunty around the update to the -11 version of the new kernel its back to this problem again what did they do to mess it up this time after months of test versions working correctly

Spike (spikenick) wrote :

I would also like to confirm as above that this does not SEEM to be a problem in jaunty when my laptop is plugged in, but that is the only way, on batter it comes back into effect making it ineffective as a fix.

Julian Alarcon (alarconj) wrote :

We moust put this on release notes, to use "acpi=noirq", cause this is the less intrusive method of workaround.

Changed in ubuntu-release-notes:
status: Invalid → Confirmed
Taylor Jasko (tjasko) wrote :

I've had this error ever since I tried Intrepid Ibex. It worked fin in 8.04 though.

As everything says above, the error has came back.

All I have to say it thanks to the developers who are helping to solve this issue. As being a developer myself, I extremely appreciate it.

My laptop is the Compaq Presario F761US, and of course, MCP-67 based.

Taylor Jasko (tjasko) wrote :

Fine*. Too bad there's no edit button here in LaunchPad.

Mehall (mehall) wrote :

Just upgraded to Jaunty.

Same as Spike, fine when plugged in, bug still there when on battery

Changed in linux (Ubuntu):
status: Fix Released → Confirmed
Perpetual (landonab) wrote :

How can this be marked 'Fix Released - Confirmed' if the bug has not been fixed upstream???

67GTA (67gta) wrote :

Try following my DSDT how to while running on battery power to see if there are any different/additional errors compared to AC power. http://ubuntuforums.org/showthread.php?t=1036051&highlight=dsdt

Russell Green (r.green) wrote :

Perpetual, the status has been changed from "Fix Released" to "Confirmed", thats an arrow, not a dash.;)

Perpetual (landonab) wrote :

Oh... sorry.

Mehall (mehall) wrote :

I would love to fix my DSDT, but I'm no programmer, and when trying to diagnose, it hit maximum errors and segfaulted.

I'll attach my dsdt, and a copy of what errors I could get outputed to a file before the segfault.

Mehall (mehall) wrote :

The errors:

Scott Minster (sminster) wrote :

The "External (^Z00G, IntObj)" really gave iasl a lot of trouble. Everything after that first error happened because of it. I'm not DSDT expert, but based on my experience fixing my DSDT, I'm attaching a set of diffs to apply to your DSDT that at least make it compile. I'm pretty confident about the diffs other than the "Z00G" ones. The others were similar to ones I had to make to my DSDT, and I verified that the _HOT and _CRT changes make sense mathematically (it takes 95, multiplies it by 10 and adds 2732 to return a temperature in Kelvin times 10).

The Z00G changes are completely foreign to me. I made a guess based on the surrounding code, and the compiler seemed OK with it. I have no idea if it is correct, just that it compiles. Maybe someone knowledgeable in DSDT knows if my suggestion is correct or not.

67GTA (67gta) wrote :

That is a seriously broken acpi table! I don't think you could even begin to fix that. As you fix one error, 50 more will appear because of the change you just made. The segmentation fault is because of the maximum 200 error limit of the aml compiler. At that point I guess the developers decided you should probably just start over. Have a look at this section:

If (\_OSI ("Linux"))
                    {
                        Store (0x03E8, OSYS)
                    }

                    If (\_OSI ("Windows 2001"))
                    {
                        Store (0x07D1, OSYS)
                    }

                    If (\_OSI ("Windows 2001 SP1"))
                    {
                        Store (0x07D1, OSYS)
                    }

                    If (\_OSI ("Windows 2001 SP2"))
                    {
                        Store (0x07D2, OSYS)
                    }

                    If (\_OSI ("Windows 2006"))
                    {
                        Store (0x07D6, OSYS)

This is supposed to be the supported OS's for your machine. Obviously your DSDT was compiled by the Microsoft aml compiler instead of Intel's. If you care to test, try adding the entries above to your kernel line in /boot/grub/menu.lst. Try acpi_osi="Linux" first to see if any of the problems your having go away. If not, delete it and try the next, acpi_osi="Windows 2001", etc... Spelling is critical. Here is mine for reference:

title Ubuntu 9.04, kernel 2.6.28-11-generic
uuid 1c99f655-3e3f-43aa-a9a2-7fb6831c98db
kernel /boot/vmlinuz-2.6.28-11-generic root=UUID=1c99f655-3e3f-43aa-a9a2-7fb6831c98db ro acpi_osi="Linux" quiet splash
initrd /boot/initrd.img-2.6.28-11-generic

Mehall (mehall) wrote :

tried all the OSes listed in the file (Linux, the win 2001's and win 2006) problem is still there. As noted above, problem only there when booting on battery, so I booted from battery with those options, since it doesn't matter what happens on ext. power.

Mehall (mehall) wrote :

@Scott Minster:

Not really willing to try messing with the DSDT if you're not too sure it'll work, as I read that it'll possibly/probably stop my OS booting if I screw up the file :/

67GTA (67gta) wrote :

Mehall: If you want to send me a copy of dsdt.dat, I will try to use Scott Minster's diff file to see if I can get your DSDT in a manageable state. You can send it to me by email through the Ubuntu forums. If you do get in a non booting state, you can use a live CD to delete the DSDT.aml file from /etc/initramfs-tools. It will not find it and default to the original DSDT to boot. You can then run "sudo update-initramfs -u -k kernel-version" in a terminal to remove the link to the custom DSDT file to start over.

67GTA (67gta) wrote :

When you dissasembled the dsdt.dat file, did it create a dsdt.aml file? I need that also.

Mehall (mehall) wrote :

No, I only got the .dat and the .dsl files.

67GTA wrote:
> When you dissasembled the dsdt.dat file, did it create a dsdt.aml file?
> I need that also.
>
>

67GTA (67gta) wrote :

I can't get it to recompile on my end for some reason. It complains that the dsdt.aml file is missing, but it is only created after recompiling.... I may just have to walk you through it on your PC. Grab a copy of Scott Minster's diff file. Make the first change in the list to your dsdt.dsl, (External (^Z00G, IntObj) to External (\Z00G, IntObj) save and run iasl -tc on it again to see if it looks better. The problem is that even if there is only one wrong character in the file, everything after it will also be an error. We should probably do this by email to keep this bug report from getting too long from here on in. If we get it right, you can post it here for someone else with your model.

Mehall (mehall) wrote :

With much thanks to 67GTA (MUCH much thanks) we now have a working DSDT.aml for the G6062ea laptop from HP.

download the attatched file, copy it to /etc/initramfs-tools/ and then run the command

"sudo update-initramfs -u -k kernel-version"

in a terminal substituting "kernel-version" for your actual kernel version (you can find this from "uname -r") (my command was "sudo update-initramfs -u -k 2.6.28-11-generic") You then need to also edit /boot/grub/menu.lst (that's lower case LST, btw) and put in:

acpi_osi="Linux"

On the kernel line, then save and run "sudo update-grub"
example version:

title Ubuntu 9.04, kernel 2.6.28-11-generic
uuid 1c99f655-3e3f-43aa-a9a2-7fb6831c98db
kernel /boot/vmlinuz-2.6.28-11-generic root=UUID=1c99f655-3e3f-43aa-a9a2-7fb6831c98db ro acpi_osi="Linux" quiet splash
initrd /boot/initrd.img-2.6.28-11-generic

67GTA (67gta) wrote :

Custom DSDT with zero errors for HP dv6815nr

I have edited my dsdt and fixed my errors. It not only solved this bug but
also my laptop now sleeps and wakes up just fine. This fix is worth a try
IMO.

2009/4/26 67GTA <email address hidden>

> Custom DSDT with zero errors for HP dv6815nr
>
> ** Attachment added: "DSDT.aml"
> http://launchpadlibrarian.net/25987107/DSDT.aml
>
> --
> 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.
>

--
A Grey given during life is better than Orchids on the grave....

Taylor Jasko (tjasko) wrote :

How are you exactly editing the DSDT? It's a huge file, and what exactly is causing the problem?

Are these the correct commands to extract the DSDT?

sudo cat /proc/acpi/dsdt > DSDT.dat
iasl -d DSDT.dat # disassemble to create DSDT.dsl

Sorry, but I haven't modified the DSDT before, and I really don't want to try to apply one of the edited ones here because they are PC specific.

I'll get Ubuntu installed (actually in Windows 7 right now), and extract my DSDT for you. :)

Hopefully we'll be able to create a post with all the DSDT fixes. ;)

I'm so glad we're having some progress here!

67GTA (67gta) wrote :

Taylor: You can see my how to hear to answer all of your questions. It is a step by step tutorial. http://ubuntuforums.org/showthread.php?t=1036051&highlight=dsdt If you get stuck just email me through the Ubuntu forums.

67GTA (67gta) wrote :

TO ALL AFFECTED: I will try to help fix DSDT errors for anyone that can email me a copy of their dsdt.dat. You can obtain it by following my how to http://ubuntuforums.org/showthread.php?t=1036051&highlight=dsdt This is not to slight the devs, but they can only implement workarounds. The problem is with the Bios vendor/HP. Even if the devs are able to patch it, you are still going to have a broken DSDT. Most of the laptops affected by this don't have proper thermal trip points, and get very warm during normal use. This also keeps a large number of laptops from suspending/hibernating. If you want to make the "right" fix, then I will try to help.

Thanks so much! I'm installing Ubuntu now. :)

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of 67GTA
Sent: Sunday, April 26, 2009 10:12 AM
To: <email address hidden>
Subject: [Bug 272247] Re: System freezes during boot, unless I hold a key down

Taylor: You can see my how to hear to answer all of your questions. It
is a step by step tutorial.
http://ubuntuforums.org/showthread.php?t=1036051&highlight=dsdt If you
get stuck just email me through the Ubuntu forums.

--
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

Taylor Jasko (tjasko) wrote :

Thanks so much! I'm so glad that you are willing to help all of us out. I have a friend that has a HP Pavilion DV6809WM, so I will extract his DSDT (he's not a Linux guy at all) for him also and post it. I also want to help to get everyone's DSDT fixed! :)

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of 67GTA
Sent: Sunday, April 26, 2009 10:27 AM
To: <email address hidden>
Subject: [Bug 272247] Re: System freezes during boot, unless I hold a key down

TO ALL AFFECTED: I will try to help fix DSDT errors for anyone that can
email me a copy of their dsdt.dat. You can obtain it by following my how
to http://ubuntuforums.org/showthread.php?t=1036051&highlight=dsdt This
is not to slight the devs, but they can only implement workarounds. The
problem is with the Bios vendor/HP. Even if the devs are able to patch
it, you are still going to have a broken DSDT. Most of the laptops
affected by this don't have proper thermal trip points, and get very
warm during normal use. This also keeps a large number of laptops from
suspending/hibernating. If you want to make the "right" fix, then I will
try to help.

--

67GTA (67gta) wrote :

Please contact me by email through the Ubuntu forums. This bug report is already too long.

Hi all

I can confirm this bug occurs on the Toshiba Satellite A30 Laptop also.

The bug still exists for me in a fully patched 9.04 installation as of about 30 minutes ago.

The machine is a P4 Mobile, Intel 82852 Chipset.

As above the problem is resolvable by passing nosmp or nolapic to the kernel.
I de-compiled the DSDT as per the above instructions and found 3 errors, 10 warnings reported, compiling a patched DSDT from http://acpi.sourceforge.net/dsdt/view.php?id=907 with iasl and using that at boot also fixes the issue.

If it will help resolve the bug, I can provide logs of lspci, dmesg etc

If this is believed to be a separate bug due to the hardware/manufacturer I also happy to raise it separately.

Don Forigua (ingforigua) wrote :

I have the same problem on my laptop HP Pavilon dc6809wm

thanks

To 67GTA:

I noticed on your post in the ubuntu forums you mentioned acpi_osi="Linux".
Has this been known to work without the custom DSDT or is that required? The
custom DSDT file seems a bit beyond my range of knowledge. :/ This problem
is actually really upsetting, I've noticed my laptop being extremely hot
lately, even when closed and idle.

On Tue, Apr 28, 2009 at 3:27 PM, Ing. Forigua
<email address hidden>wrote:

> I have the same problem on my laptop HP Pavilon dc6809wm
>
> 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
>

67GTA (67gta) wrote :

SRElysian:

It will not help without fixing your DSDT errors. It will tell the BIOS?Ubuntu to read the Linux part of the DSDT file at boot to control acpi functions, but the DSDT errors will still cause the same problems. Follow my how to to the point of getting your dsdt.dsl, email it to me through the Ubuntu forums, and I will fix it for you and help you get it implemented.

Xyos (slayerjairo-gmail) wrote :

thank you 67GTA :)

wribeiro (wribeiro) wrote :

In Jaunty i386 (kernel 2.6.28-11) the problem still occours if me laptop is in battery mode. When plugged in, the boot progress is OK.
HP Pavilion dv6646us, AMD turion64x2, nVidia, Broadcom.

SJI (sji) wrote :

I have encountered the same problem on a Sony Vaio PCG-GRT796HP today.
Hardy has no problems at all, Intrepid and Jaunty wont run properly unless a key is held down.

I believe this is a problem caused by ACPI/DSDT.aml

Hardy tries to load DSDT.aml from initramfs but fails. Intrepid and Jaunty succeed in finding DSDT.aml in initramfs, but it seems to be broken.

Stephen

67GTA (67gta) wrote :

wribeiro and SJI: Follow my how to to the point of getting your dsdt.dsl file and send them to me. I will take a look at them.

wribeiro (wribeiro) wrote :

Here are 2 versions of my dsdt file: plugged in and battery mode.

Stefan Bader (smb) wrote :

@67GTA, just trying to confirm your changes to the DSDT (its a bit hard to diff as there are a lot of optimizations). Basically the major things you changes seem to me the return package for the _WAK method, the removal of those two Zero statements and (maybe the thing that has most effect to the bug) change the processor register block. Is that correct?
I am not sure the reason for the bugs experienced on the HPs is the same as I see on one machine here (which is triggered by enabling C1E), but it sounds a bit like it might go down to the same root. Somehow most BIOS define an override for IRQ0 (the timer) and it seems this often is not correct.
Maybe someone wants to give the following a try:
- If you have a custom DSDT, add "acpi_no_initrd_override" to the boot options. This
  should make the kernel ignore that custom DSDT and the hangs should reappear.
- adding "debug apic=debug" add a little more information into the dmesg
- Then try the following combinations:
  * nohpet
  * idle=poll
  * acpi_skip_timer_override
Do any of these make the boot work without a keypress?

67GTA (67gta) wrote :

wribeiro: I have you fixed. 0 errors. Follow the rest of my how to and be sure to add acpi_osi="Linux".

67GTA (67gta) wrote :

Stephan: I will test your method tonight to see if this helps with the boot freezing. So far the majority of the errors have been system wake (WAK), and errors in the thermal methods (HOT) and (CRT). A few (including mine) had errors in the (Q16) method. I'm not sure what it pertains to. It was only a warning, so I don't think it would cause freeze. I am wondering if the wake method is causing the trouble. It doesn't have a valid return value. I wonder if the missing return value causes the system to lock up while it probes the hardware. It is still bazaar that holding down a keyboard key resumes boot.

SJI (sji) wrote :
Download full text (3.4 KiB)

I've tried the following:

>If you have a custom DSDT, add "acpi_no_initrd_override" to the boot options. This
>- Then try the following combinations:
> * nohpet
> * idle=poll
> * acpi_skip_timer_override
>Do any of these make the boot work without a keypress?

idle=poll works on my machine. Boot is as fast as Hardy.
Fan speed is now proportionate to CPU temp again and CPU temps are back to normal.

Watching the boot process without boot options everything is fine until Setting preliminary keyboard.
At that point the keypressing is required.

An odd side effect are the entries in messages:

May 7 11:55:32 sodium kernel: [ 3.433429] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 15:32:59 sodium kernel: [ 2.385370] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 15:43:52 sodium kernel: [ 3.229357] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 15:52:07 sodium kernel: [ 3.465385] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 16:04:34 sodium kernel: [ 3.581852] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 16:10:56 sodium kernel: [ 3.567067] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 16:20:53 sodium kernel: [ 3.490863] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 16:24:45 sodium kernel: [ 3.473706] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 16:30:16 sodium kernel: [ 3.541448] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 16:39:21 sodium kernel: [ 3.507135] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 16:44:54 sodium kernel: [ 3.591142] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 17:14:50 sodium kernel: [ 3.595110] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 17:27:54 sodium kernel: [ 3.563118] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 18:47:35 sodium kernel: [ 2.389358] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 18:54:22 sodium kernel: [ 3.341691] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 7 19:02:00 sodium kernel: [ 3.450953] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 8 02:06:10 sodium kernel: [ 2.405369] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 8 02:10:35 sodium kernel: [ 2.881567] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 8 02:17:12 sodium kernel: [ 3.089372] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 8 02:25:12 sodium kernel: [ 3.251031] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
May 9 02:58:00 sod...

Read more...

@67GTA, To me it feels strange should the _WAK method have any effect there. I
believe this is called on resume from suspend not when transitioning from a C
level. What I noticed when comparing the DSDTs you posted was the following:

- Scope (\_PR)
+ Scope (_PR)
      {
- Processor (CPU0, 0x00, 0x00001010, 0x06) {}
- Processor (CPU1, 0x01, 0x00001010, 0x06) {}
+ Processor (CPU0, 0x00, 0x00000000, 0x06) {}
+ Processor (CPU1, 0x01, 0x00000000, 0x06) {}
      }

This might relate to processor feature. Unfortunately I do not understand yet
what the ACPI spec says about this. But if the effect is a change of the C
states the processor goes, this would explain why this helps. It seems HPET and
C3 might be an evil combination depending on some hardware.
The background here is that when running a tickless kernel (which we do) then
it can happen that all CPUs go into a low power state which turns of external
clocks. The HPET (or the PIT if there is no HPET) is used a trigger to wake the
CPU(s) again. However if there is anything wrong with the connection, the
waking interrupt never arrives. So what you do by pressing a key is just
generating an IRQ and that wakes the CPU.

67GTA (67gta) wrote :

I just assumed that the _WAK method was for all start ups, and not just suspend. Your theory makes more sense. The hpet argument works on my laptop with my custom DSDT removed. (Gets rid of the boot freeze.) The iasl compiler made the changes you pointed out automatically. I didn't even notice them.

67GTA (67gta) wrote :

Here is a copy of my original disassembled DSDT with iasl, and the 1127 optimizations if any of it will help:-) I set iasl to be verbose.

DEFHol (dfleener) wrote :

Stefan, as wribeiro says, this bug only affects me while on battery power, not when plugged in. Boot option 'idle=poll' works for me. Now my system doesn't hang while booting on battery power. I have a Presario F750US laptop. Thanks for your help.

wribeiro (wribeiro) wrote :

This bug follows me since Ubuntu 8.10 and I survived until now (that's amazing!)
It's better for me live with 'idle=poll' option than try to fix and have my PC unstable - I use it for job.
Is there any chance of having this bug fixed in the next version of linux kernel?

Stefan Bader (smb) wrote :

@67GTA, the compile log seems not to show anything touching the Processor declarations. Its a bit weird. I wonder whether you see something noticeably different in powertop (on the C-state usage) between using that modified DSDT and unmodified with nohpet (but thats probably more out of curiosity).

@DEFHol, wribeiro, the problem with that sort of thing is that it is hard to get hold of and likely depends on having certain hardware. The "idle=poll" is not really desirable because it prevents the cpu from any idle method which is not doing good on battery life. If neither "nohpet" nor "acpi_skip_timer_override" work for you, you might give "idle=halt" a try, but the other two options would probably be better.

In general a fix seems to require a dmesg (with "debug apic=debug") and "sudo lspci -vvvnnxxxx" and a good documentation on the chipset. It seems it is not the first time HP get the IRQ0 override wrong.

wribeiro (wribeiro) wrote :

'nohpet' works fine with my HP Pavilion dv6646us in battery power and AC power.
I'll be waiting for the next kernel version and test again.
Thank you very much for your help.

DEFHol (dfleener) wrote :

'nohpet' also works for me. Thanks again.

Stefan Bader (smb) wrote :

wribeiro wrote:
> I'll be waiting for the next kernel version and test again.

The way we currently stand there won't be need to test because there wont be
any change. Repeating myself: "In general a fix seems to require a dmesg (with
"debug apic=debug") and "sudo lspci -vvvnnxxxx" and a good documentation on the
chipset."

The problem with that is, depending on the chipset, there might be no
documentation. But to decide that, the information above is required.

SJI (sji) wrote :
SJI (sji) wrote :
Stephan Fabel (sfabel) wrote :

Can confirm this bug with a HP dv6646us Notebook.

Kernel: 2.6.28-11-generic (JAUNTY)

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.

Don Forigua (ingforigua) wrote :
Don Forigua (ingforigua) wrote :
Don Forigua (ingforigua) wrote :
Don Forigua (ingforigua) wrote :

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

Don Forigua (ingforigua) wrote :

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

Taylor Jasko (tjasko) wrote :

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

For the Compaq F761US. Thanks to 67GTA.

67GTA (67gta) wrote :

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

AlanB66 (apbuys) wrote :

Works fine for me, now, on Compaq F750US.

Thank You!

hackob (hackob.me) wrote :

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

Thank You...

Don Forigua (ingforigua) wrote :

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

Perpetual (landonab) wrote :

@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
>

Xyos (slayerjairo-gmail) wrote :
Download full text (4.8 KiB)

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 ...

Read more...

wm3 (y.s) on 2009-07-08
Changed in ubuntu-release-notes:
assignee: nobody → 3n!Gma (wm3)
Steve Langasek (vorlon) on 2009-07-08
Changed in ubuntu-release-notes:
assignee: 3n!Gma (wm3) → nobody
67GTA (67gta) wrote :

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.

B3rz3rk3r (adamgalt1) wrote :

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

bruno (brunomacagnani) wrote :

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

Stefan Bader (smb) on 2009-08-31
description: updated
Stefan Bader (smb) wrote :

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.

Changed in linux (Ubuntu Intrepid):
status: Triaged → Won't Fix
Lorenzo De Liso (blackz) on 2010-01-04
Changed in linux (Ubuntu):
assignee: Stefan Bader (stefan-bader-canonical) → nobody
assignee: nobody → Stefan Bader (stefan-bader-canonical)
Jeremy Foshee (jeremyfoshee) wrote :

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.]

tags: added: kj-triage
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
SRElysian (srelysian) wrote :

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.

Changed in linux (Ubuntu):
status: Incomplete → New
Mark Grandi (markgrandi) wrote :

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.

SRElysian (srelysian) wrote :

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.

Rad3k (trueradzian) wrote :

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.

sergiom99 (sergiom99) wrote :

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.

Mark Grandi (markgrandi) wrote :

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.

67GTA (67gta) wrote :

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.

Mark Grandi (markgrandi) wrote :

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

sergiom99 (sergiom99) wrote :

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!

Changed in linux (Ubuntu):
status: New → Confirmed
Loïc Minier (lool) wrote :

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!

Changed in ubuntu-release-notes:
status: Confirmed → Incomplete
tags: added: cherry-pick kernel-uncat
Changed in ubuntu-release-notes:
status: Incomplete → Invalid
Changed in ubuntu-release-notes:
status: Invalid → Won't Fix
Magnus Helander (mhelander) wrote :

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

Magnus Helander (mhelander) wrote :
Magnus Helander (mhelander) wrote :
Magnus Helander (mhelander) wrote :
eisbaw (wabsie) wrote :

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

Stefan Bader (smb) wrote :

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?

eisbaw (wabsie) 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?

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

Changed in linux:
importance: Unknown → High
Mark Jonas (mark-jonas) wrote :

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.

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
Changed in linux:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.