Messages in this thread | | | Subject | Re: IO-APIC on nforce2 [PATCH] + [PATCH] for nmi_debug=1 + [PATCH] for idle=C1halt, 2.6.5 | From | Ian Kumlien <> | Date | Wed, 05 May 2004 15:23:31 +0200 |
| |
On Wed, 2004-05-05 at 15:12, Ross Dickson wrote: > On Wednesday 05 May 2004 22:27, Ian Kumlien wrote: > > On Wed, 2004-05-05 at 14:14, Ross Dickson wrote: > > > To my knowledge the only thing left to sort out for the normal kernel > > > distro is what to do about the timer_ack issue in check_timer(). > > > > > > We need it off for nforce2 to get nmi_watchdog=1 working with ioapic > > > 8254 timer pin0 timer override patch routing. I vote to revisit Maciej's > > > patch that was dropped by Linus after appearing in 2.6.3-mm3. > > > For those with problems of clock skew with the timer into pin0 routing, > > > that patch gave a virtual wire timer routing which worked well for those > > > users. > > > > Whats the real difference between nmi_watchdog?1 and =2? Since > > nmi_watchdog=2 works here: > > > > NMI: 9884 > > LOC: 80297310 > > ERR: 0 > > MIS: 0 > > From memory 2 uses resources that code profiling tools need to use so > if you can use 1 then you can have your watchdog and profile too.
Ahh outch...
> > Also, wouldn't it be better to not depend on bioses and bios versions > > atm, ie hardcode pin0 since Allen Martin stated that it's hardwired on > > pin0? > > > > ie, just: > > if(pin2 && nforce2_chip) > > { > > printk("ALERT: Known defect in bios, mail your manufacturer. Using > > pin0\n"); > > <whateverisneededtousepin0> > > } > > It should be OK, but those with mobos that get clock skew on pin 0 would > then demand a clock skew fix for their noisy hardware. I don't have a > motherboard with skew problems.
Like: cat ntp.drift -12.282
> Personally I think that the clock system should be made immune to noise > generated timer interrupts just as it has been coded to detect missing > timer interrupts. I am pretty sure on nforce2 athlon mobos the tsc is used > in detecting missing pulses. Kind of like a digital phase locked loop? so > should it not also debounce the interrupts given that the ioapic interrupt > hardware cannot? > http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-04/6385.html > Obviously the pc hardware design is flawed in this respect.
x86 is flawed in many ways, but it's cheap and you get what you pay for =).
But wouldn't that cause problems with cpu freq scaling?
> Anyone know how to modify the existing timer tsc code to do this? And > offer to do it? Any brand/type of mobo is open to clock speed up due > to this effect, so I think it should be fixed, debouncing is fundamental > to input transitions that need to be counted.
-- Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net [unhandled content-type:application/pgp-signature] | |