Navigation
User login
Quick Links
Syndicate
Hardware problem solved
I had a problem with my new presario v6000 where it would hang shortly after boot. A quick google and I knew I had to boot with 'noapic', but then spurious interrupts quickly disabled the USB2 port.
A deeper google suggested things like 'irqfixup' and 'irqnodebug', but they all yielded a weird IRQ assignment and one of the processor cores was busy at 90% handling all the spurious interrupts, and generated heat, which in turn made the cooling system work double time, and killed the battery life.
I upgraded the firmware to the latest version from hp and compiled my own 2.6.21 kernel but nothing improved.
Then I noticed that the hang always happened at the same exact time in the bootup sequence. I checked and it was the hwclock script which was supposed to set the hardware clock. After disabling it, the system booted up without any workarounds and the apic generated interrupt table looked perfect.
I will test some more and then create a page about linux on the presario v6000.
UPDATE 1: Things are definitely better, but I still get a hang every three or four boots while "detecting hardware". This is where udev loads drivers for all hardware and I suspect that the wireless driver ( broadcom ) is causing the hangs.
UPDATE 2: Turned out udev was really the actual culprit, loading lots of drivers in parallel and causing some kind of a race condition somewhere. Given that this is actually a kernel / driver bug, I was able to solve it by adding "--debug-trace" to the udev launch command in /etc/rcS.d/S10udev and voila I can always boot reliably :)
Comments
Hello ... I have a lot of
Hello ... I have a lot of problems with the same presario v6000. Where can I find more informtion and tutorials of this item ? Thanks everybody.
Bye
Recetas
Check this page
http://phaeronix.net/node/232
This has more uptodate info.
software
I have the same problem and I tried what you said and sadly I had no succes.
try this
try the suggestion mentioned here http://phaeronix.net/node/223 .
Great!
I always disable fsck for ext3 volumes in /etc/fstab ( 0 0 at the end of the line corresponding to the root volume).
Also I use tune2fs -c 0 -i 0 /dev/sda[n] where n is your partition number, to disable mount and date based fscking.
ext3 has a journal that will always keep your volume in a consistent state. Every once in a blue moon you can manually fsck just to be sure.
As to the scrolling hang yes I did face that sometimes but only when I was logged into single mode. That is the console didn't have a getty. Nowadays, when I use the console I use nvidiafb. It provides a cool high resolution frame buffer that is still quite fast.
You can do that by doing :
{{{
rmmod nvidia
modprobe fbcon
modprobe nvidiafb
}}}
However you can't go back to using nvidia for Xorg, so you will have to reboot.
If that is unacceptable ( like you switch a lot between console and X ), then I would consider looking into getting vesafb-tng to work. It is a kernel patch to add support for vesa-3.0 which is available in the newer geforce GPUs and should play nice with nvidia Xorg. I am yet to test it on ubuntu. It works perfectly in gentoo.
I also just noticed a patch available in the last 2.6.23 rc ( rc7 currently ) that tries to fix broadcom driver (bcm43xx) hangs. Look here : http://bugzilla.kernel.org/show_bug.cgi?id=8937
(after all the help I'm
(after all the help I'm receiving here, I guess it doesn't
hurt to have a little decency and post with my name and email)
Thanks you VERY much for all your help. I think I'll go with disabling
automatic fsck and trying the vesafb-tng patch once Gutsy comes out.
By the way, I don't know if that interests you, but all the problem I'm
having is on the amd64 version of Feisty. Last week I found out that
replacing the 64-bit hwclock executable with its 32-bit version can
also solve the hanging problem.
Great
You are welcome. You encouraged me to publish this page I had on mind, since it might help a lot of people. Here's the announcement http://phaeronix.net/node/216
I am also using the AMD64 version of feisty, and now I remember that vesafb-tng might be dependent on 32bit... I think spock ( the gentoo developer who made it ) has something else that works for both archs.
I will try your workaround with the 32bit hwclock and if it works, I will add it to the page with your permission of course.
Actually, sorry if I gave
Actually, sorry if I gave the impression that I came up with this
by myself, but I have to give credit where credit is due: I took
the 32-bit workaround from a OpenSuSE mailing list. Link below:
http://www.mail-archive.com/opensuse@opensuse.org/msg41964.html
Replacing /sbin/hwclock with the 32-bit binary I got from
packages.ubuntu.com seems to have solved the problem for me,
and got me wondering if the fsck and scrolling problems might
also be related to 64-bit versions of executables.
Once Gutsy comes out, I also plan to put up a page with workarounds
for my Pavilion. :)
Hi, It's interesting that
Hi,
It's interesting that I found this page... I'm having this EXACT
kernel parameter problem with Feisty in a HP Pavilion DV6258se.
I've tried to add '--debug-trace' to all three occurrences of
udevd in /etc/rcS.d/S10udev, but the boot is still freezing.
Am I doing something wrong with udev?
Thanks!
Not only udev
Hello.
It is not only udev that hangs the system. As I said :
"it was the hwclock script which was supposed to set the hardware clock. After disabling it, the system.."
So you see you have to disable that script from system startup. It is usually in /etc/rcS.d/S[n]hwclock where n is a number. So you can just do :
{{{
sudo mv /etc/rcS.d/*hwclock ~
}}}
Try it and tell me if it works :)
Hi, Thanks! It did solve
Hi,
Thanks! It did solve the problem, but there are few loose ends
before I can call this a perfect install. :)
Two things I still can't manage to solve are: 1) fsck hanging at
a random percentage (usually between 70% and 80%) and 2) the
text-mode console hanging whenever I execute something that
produces a lot of output (dmesg).
Both problems do not occur if noapic is enabled, but with noapic
there's the whole spurious interrupts issue.
Post new comment