Re: IO-APIC on nforce2 [PATCH] + [PATCH] for nmi_debug=1 + [PATCH] for idle=C1halt, 2.6.5

[Ian Kumlien <pomac@vapor.com>]

[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]