Bug 6975 - Asus M2NPV-VM Motherboard - hangs on boot.
Summary: Asus M2NPV-VM Motherboard - hangs on boot.
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 blocking
Assignee: Len Brown
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-08 17:38 UTC by Marc Perkel
Modified: 2007-11-06 01:03 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.18rc5
Tree: Mainline
Regression: ---


Attachments

Description Marc Perkel 2006-08-08 17:38:51 UTC
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.
Comment 1 Martin J. Bligh 2006-08-08 17:41:48 UTC
I doubt that's a bug in the bug tracking system ;-)
Will shift categories

try booting with "elevator=as" on the command line?
Comment 2 Marc Perkel 2006-08-08 17:51:24 UTC
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
Comment 3 Marc Perkel 2006-08-08 18:08:18 UTC
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?
Comment 4 Marc Perkel 2006-08-08 21:31:18 UTC
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.
Comment 5 Jens Axboe 2006-08-09 00:32:00 UTC
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.

Comment 6 Marc Perkel 2006-08-10 21:51:07 UTC
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?
Comment 7 Jens Axboe 2006-08-11 00:04:49 UTC
Boot with initcall_debug added as a boot parameter, that'll show you the
last initcall that took place.

Comment 8 Marc Perkel 2006-08-11 09:19:39 UTC
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?
Comment 9 Marc Perkel 2006-08-11 15:16:54 UTC
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.
Comment 10 Marc Perkel 2006-08-12 21:30:58 UTC
The 2.6.18rc4 kernel will boot with the noapic parameter. Got the hint from the
article.

http://www.linuxjournal.com/node/1000074
Comment 11 Marc Perkel 2006-08-18 16:09:01 UTC
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.
Comment 12 Prakash Punnoor 2006-08-27 22:15:47 UTC
Just deactivate the nvidia acpi_skip_timer_override quirk, as I posted in 
lkml, then it boots fine and runs stable.
Comment 13 Marc Perkel 2006-09-02 12:27:14 UTC
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.
Comment 14 Jens Axboe 2006-09-03 11:14:57 UTC
This is misplaced as a block layer issue. Reassigning to Len for acpi, Len keep
it going if that's not it...
Comment 15 Marc Perkel 2006-09-05 08:04:04 UTC
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.
Comment 16 Marc Perkel 2006-09-18 09:26:46 UTC
So - is this ever going to get fixed. Kind of interesting that an AMD bug is
assigned to an Intel employee. :)
Comment 17 Marc Perkel 2006-09-27 16:30:13 UTC
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.


Comment 18 Prakash Punnoor 2006-09-28 10:12:55 UTC
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.
Comment 19 Fatih Asici 2006-09-28 12:24:31 UTC
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.
Comment 20 Patrick Hohmeyer 2006-10-05 15:43:13 UTC
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.
Comment 21 Marc Perkel 2006-10-06 08:32:04 UTC
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.
Comment 22 David Fritzsche 2006-10-12 12:26:40 UTC
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.
Comment 23 C 2006-10-18 11:35:36 UTC
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.
Comment 24 C 2006-10-18 11:36:30 UTC
sory...

noapic option...
Comment 25 C 2006-10-30 16:04:45 UTC
with bios version 0504 my system is now stable without any boot option
Comment 26 Jason Smith 2006-11-01 20:08:57 UTC
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.
Comment 27 Fatih Asici 2006-11-01 22:26:26 UTC
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.
Comment 28 Fabio Erculiani 2006-11-21 01:49:12 UTC
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.
Comment 29 Natalie Protasevich 2007-10-04 02:51:07 UTC
Any updates on this issue, how is it working with recent kernels? 
Did anyone get chance to test according to #28?
Thanks.
Comment 30 Fu Michael 2007-11-06 01:02:06 UTC
According to comment# 26, sounds like a bios bug that has been fixed via a bios update. resolve this bug as wontfix.
Comment 31 Fu Michael 2007-11-06 01:03:29 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.