Most recent kernel where this bug did not occur: Distribution: Fedora Core 5 Hardware Environment: AMD AM2 4600 CPU Dual Core Software Environment: Problem Description: Hangs on boot using stock 2157_FC5 kernel. Last message on screen is: io scheduler cfq registered (default) Steps to reproduce: The system did boot with the distribution kernel 2.6.15. I have 4 gigs of ram installed - using a SATA drive.
I doubt that's a bug in the bug tracking system ;-) Will shift categories try booting with "elevator=as" on the command line?
Also - I upgraded the bios to 0303 and I think the problem might be related to this bios version. Before I upgraded the bios I was having other problems so people should be aware that this might be related to the latest bios. Tried elevator=as Same Problem
On other boots I briefly noticed that there was something complaining about a timer. In looking at another dmesg file I notice that the very next line after the one my computer hangs on is "Setting latency timer of device" Could the problem be related to this timer?
I tried the newest fedora core kernel that is in the testing section but still 2.6.17 and it fails as well. However I reinstalled the original 2.6.15 kernel and it boots. So something broke between 2.6.15 and 2.6.17 with respect to this noard. I still think it's in the Latency Timer - the line in dmesg just after the line it freezes on.
If you want to help out, you should try and narrow the breaking point down some more. You can either git bisect your way out of it, or just try the various -rc kernels and see which one breaks it first.
I just tried the 2.6.18rc4 kernel and it still has the same problem. The Asus M2NPV-VM motherboard doesn't work. Hangs at the same place. The last line on the screen is still io scheduler cfq registered (default). So - it looks like the latency timer is next. What can I do to help troubleshoot this?
Boot with initcall_debug added as a boot parameter, that'll show you the last initcall that took place.
OK - I ran it with initcall_debug on the command line. I get one more line following the last line I used to get. Wish I had a way to copy and paste it. After the line io scheduler cfq registered (default) I get this one more line. Calling initcall ..... pci_init 0x0/0x2b() And that';s where it hangs. So - what shall I try next?
It sure would be nice if we could fix this bug so that Asus motherboards didn't freeze up on boot before the 2.6.18 kernel is released.
The 2.6.18rc4 kernel will boot with the noapic parameter. Got the hint from the article. http://www.linuxjournal.com/node/1000074
I suppose whenever a new processor is introduced that I should wait 6 months to buy it because that's how long it seems to take to make it Linux compatible.
Just deactivate the nvidia acpi_skip_timer_override quirk, as I posted in lkml, then it boots fine and runs stable.
Tried the 2.6.18rc5 kernel on Asus M2NPV-VM motherboard and upgraded Bios to version 0405 and the problem is still there. Hangs on boot. I don't know if Prakash Punnoor's fix made it into this release or not. I'm just reporting that the latest kernel still doesn't run.
This is misplaced as a block layer issue. Reassigning to Len for acpi, Len keep it going if that's not it...
I just tried the 2.6.18rc6 kernel and it hangs as well. Not yet fixed. However setting acpi_skip_timer_override to 0 instead of 1 makes the problem go away.
So - is this ever going to get fixed. Kind of interesting that an AMD bug is assigned to an Intel employee. :)
Ok - I don't understand why this bug is being ignored. It appears that this bug applies to many models of motherboards all using the new nVidia chipset for AM2 socket AMD processoes causing these motherboards to lock up on boot. This bug has been reported for a long time and it appears that there seems to be some understanding as to what the problem is. Yet no one is fixing it. So what's up with that? I know this is free software but I would think that someone would want to put out some effort to make Linux run on the AM2 systems. So why is this being ignored? I compiled 2.6.18 and setting acpi_skip_timer_override to 0 instead of 1 makes the problem go away. Obviously the logic needs to e a little more complex than is but this shouldn't be that hard to resolve.
The problem is *Nvidia* hasn't made any comment yet, what would be the correct fix. And thus my proposed fix is only an empirical result of testing but nothing for sure.
I am using ASUS M2NPV-MX motherboard. With the kernel 2.6.16.x I haven't any problem but; with 2.6.18 problems appear. I get the following messages: kernel: irq 11: nobody cared (try booting with the "irqpoll" option) and I tried booting with "irqpoll" and now it boots.
I had a very similar problem with my M2N4-SLI board (nForce4 AM2), 2.6.16 works fine, 2.6.17 and 2.6.18 halts after the io scheduler cfq registered line. I solved it by providing the (rather undocumented) enable_8254_timer parameter to the kernel. Somewhere between 2.6.16 and 2.6.17, the default behavior switched from using the 8254 timer (breaks ATI mainboards) to not using it (breaks my nVidia board and perhaps others too). According to Andi Kleen (x86_64 maintainer), I'm the first person reporting a problem with the timer, so, please try this parameter and report about it.
This might be yet a separate bug or it could be related to this new chipset so I'm going to add it to this thread. I'm currently running 2.6.18 with acpi_skip_timer_override = 0 and I was seeing the server lock up about once a day. This is after changing memory and power supplies. I found others on the net having the same problem with lockups under Linux and they suggested setting pci=nommconf and 4 days and it hasn't locked up. So - might want to look into that as well.
I tried to use the enable_8254_timer boot parameter (thanks, Patrick) and it works on my M2NPV-VM. I'm running the standard Debian 2.6.18-1-686 kernel.
on my M2NPV-VM with BIOS 405 and Gentoo kernel 2.6.17-gentoo-r8 the system boot with with the option enable_8254_timer but the the clock run too fast after 24h the date can be several hours in advance. With the apic option the system seems to be stable.
sory... noapic option...
with bios version 0504 my system is now stable without any boot option
Hardware M2NPV-VM BIOS ver. 0405 w/ AMD 4200+ Dual-Core 2-512MB DDR2 800mhz. Initially after upgrading from Ubuntu 6.06.1 AMD64 to 6.10 AMD64 which updated the kernel from 2.6.15-27 to 2.6.17-10 had issues with booting as described above. Was able to boot by passing noapic or enable_8254_timer at boot time. After reading through this bug report and other LKML postings upgraded BIOS to ver. 0504. After upgrading I was able to boot with no kernel options and no momentary hangs. System hasn't been up for very long, will monitor for stability. Appears maybe that Asus had a buggy BIOS. Wonder what they changed that would make things work? Thanks to all the kernel maintainers for all there hard work. It doesn't go unnoticed.
My board is ASUS M2NPV-MX. I have upgraded BIOS and the problem related with timer has gone. But it still does not boot because of MSI. It works only with pci=nomsi option.
any gentooer here could try gentoo-sources-2.6.18-r4 that's available in the "sabayon" overlay? svn co http://svn.sabayonlinux.org/overlay I tried to backport two patches from 2.6.19 and since I'd like to have this issue fixed upstream (by gentoo devs) I need feedback.
Any updates on this issue, how is it working with recent kernels? Did anyone get chance to test according to #28? Thanks.
According to comment# 26, sounds like a bios bug that has been fixed via a bios update. resolve this bug as wontfix.
(In reply to comment #19) > I am using ASUS M2NPV-MX motherboard. With the kernel 2.6.16.x I haven't any > problem but; with 2.6.18 problems appear. I get the following messages: > > kernel: irq 11: nobody cared (try booting with the "irqpoll" option) > > and I tried booting with "irqpoll" and now it boots. Hi, Fatih Asici , this is a different issue compared with this bug report. If it still bothers you on the latest kernel, please open a new bug. thanks.