Messages in this thread | | | From | Ross Dickson <> | Subject | Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered | Date | Sun, 14 Dec 2003 04:07:28 +1000 |
| |
Greetings, I have updated the apic timer ack delay patch and the io-apic edge patch although I do not think anyone had any problems with the first release.
These patches may not be required if your bios is sorted out - mine are not yet.
The apic ack delay no longer adds a small delay to every timer int so I believe its performance hit is barely detectable.
In fact the busier the system gets with irqs- the more likelyhood of the delay time expiring naturally and the less the impact of the patch.
It now only delays the ones that would be too quick and most likely cause a hard lockup. It also reports its existence on boot if used. e.g.
..APIC TIMER ack delay, reload:16701, safe:16691
And if
#define APIC_DEBUG 0
is set to 1 in
/usr/src/linux-2.4.23-rd2/include/asm-i386/apic.h
Then you can report at boot ten pre delay apic timer times as well to get a feel as to whether the delay had to kick in or not. Note that ten is a very small sample size but it gives an idea of the timing numbers.
The apic timer counts down from the reload value and interrupts at zero. The reload value corresponds to the time between HZ at the rate the counter counts. Nothing new so far. e.g. My system is running 1000Hz so the time is 1ms. The reload value is 16701 so that represents 1ms.
The safe count it calculates for my system is 16691 so any number smaller than that is expected to be when it is safe to ack the local apic after an apic timer interrupt. If you want to experiment with the delay time in nano seconds just change the 600UL. If I set mine to 400UL then my hard lockups return. Interestingly I can read the local apic timer safely right after the interrupt - I just can't safely ack it then. It is as if the C1 disconnect logic within the processor only screws with the ACK irq cancellation logic and then only for a short time after an irq.
The io-apic edge patch has been cleaned up a little. If the above debug is on then it will display the 8259a xtpic interrupt mask. I get hex fb and hex ff indicating that the only int enabled on the 8259A xtpic which handles irq 0-7 is the cascade irq 2 which is OK because on the other 8259A irq 8-15 are masked. This masked xtpic should always be the case. We want the 8259A off during our test to see if the 8254 timer is connected directly to pin 0 of the ioapic. The other messages are as per previous version.
Lastly I need sleep (4 am) so they are not yet done as patch files. I have put them into two text files and bzipped them as an attachment. Anyhow they are small and insert in the same places as their previous versions.
Thanks Jesse for rediffing the original patches for 2.6 would you like to repeat the favour with these please?
Again they are still experimental.... so I am hoping Ian, Jesse and others will put them to the test.
Thanks Ross Dickson.
[unhandled content-type:application/x-tbz] | |