> Just would like to add that if we cannot get Maciej's 8259 ack patch
> back into the distro then we need an if statement in the check_timer()
> to turn off timer_ack for nforce2 or Christian might get his hi-load back
> and certainly nmi_debug=1 won't work.
>
> e.g. for 2.4.26-rc2 io_apic.c line 1613 or 2.6.5 line 2180
> if (pin1 != -1) {
> /*
> * Ok, does IRQ0 through the IOAPIC work?
> */
> + if(acpi_skip_timer_override)
> + timer_ack=0;
> unmask_IO_APIC_irq(0);
>
Also on mainline 2.6.5 this if-statement doesn't seem to be necessary. Len's
patch worked on this kernel as well, setting the timer interrupt to
IO-APIC-edge and there is no strange hi-load anymore too.
thanks, christian.
Sorry Christian, meant to send to the list rather than just you.
I'm watching this thread with interest, I've got an ASUS A7N8X board,
and have had annoying lockups with most kernels I've compiled myself
from 2.4 upwards. Some luck caused me to try turning APIC off, and the
system hasn't crashed since.
Is there any reason why turning APIC off reduces performance?
I'd be happy to provide another person to test patches (with the proviso
that if you want detailed debugging information, you'd have to suggest
how to obtain it, since when it locks up, it tends to lock good!)
I'm currently running 2.6.3-gentoo-r1 (Although I can't see a list of
what patches they have already applied).
I'd be happy to try a vanilla kernel with whatever patches if that would
help out solving the problem.
Regards
Peter Clifton
On Thu, 2004-04-15 at 02:35, Peter Clifton wrote:
> Sorry Christian, meant to send to the list rather than just you.
>
> I'm watching this thread with interest, I've got an ASUS A7N8X board,
> and have had annoying lockups with most kernels I've compiled myself
> from 2.4 upwards. Some luck caused me to try turning APIC off, and the
> system hasn't crashed since.
>
> Is there any reason why turning APIC off reduces performance?
>
> I'd be happy to provide another person to test patches (with the proviso
> that if you want detailed debugging information, you'd have to suggest
> how to obtain it, since when it locks up, it tends to lock good!)
>
> I'm currently running 2.6.3-gentoo-r1 (Although I can't see a list of
> what patches they have already applied).
>
> I'd be happy to try a vanilla kernel with whatever patches if that would
> help out solving the problem.
Peter, I have 2.6.3gentoo r1 on my box with a A7N8X Deluxe v2 with Ross
Dicksons 2.6.3 idlec1halt patches and its as stable as a rock. I've left
it on that kernel as there are still many discussions recently posted re
2.6.5. My 3 other PCs are on gentoo dev source 2.6.5 and are solid, but
I've left the Athlon on 2.6.3 due to the fact its working just fine now
Craig
On Thursday 15 April 2004 07:01, Christian Kr?ner wrote:
> > Just would like to add that if we cannot get Maciej's 8259 ack patch
> > back into the distro then we need an if statement in the check_timer()
> > to turn off timer_ack for nforce2 or Christian might get his hi-load back
> > and certainly nmi_debug=1 won't work.
> >
> > e.g. for 2.4.26-rc2 io_apic.c line 1613 or 2.6.5 line 2180
> > if (pin1 != -1) {
> > /*
> > * Ok, does IRQ0 through the IOAPIC work?
> > */
> > + if(acpi_skip_timer_override)
> > + timer_ack=0;
> > unmask_IO_APIC_irq(0);
> >
>
> Also on mainline 2.6.5 this if-statement doesn't seem to be necessary. Len's
> patch worked on this kernel as well, setting the timer interrupt to
> IO-APIC-edge and there is no strange hi-load anymore too.
>
Good that your hi-load is fixed just by routing the timer through io-apic.
Could you try the "nmi_watchdog=1" kernel arg please.
You should get a message in your boot log as to whether it works
also cat /proc/interrupts to see if it stops.
Wouldn't hurt to try "nmi_watchdog=2" either.
I had a situation where "nmi_watchdog=2" tested ok in boot log
but halted after 23 interrupts.
> thanks, christian.
>
>
>