Bug 6975

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.