Messages in this thread | | | Subject | Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered | From | Ian Kumlien <> | Date | Sun, 14 Dec 2003 00:21:23 +0100 |
| |
On Sun, 2003-12-14 at 00:16, Ross Dickson wrote: > On Sunday 14 December 2003 08:28, you wrote: > > On Sat, 2003-12-13 at 19:07, Ross Dickson wrote: > > > ..APIC TIMER ack delay, reload:16701, safe:16691 > > > > calibrating APIC timer ... > > ..... CPU clock speed is 2079.0146 MHz. > > ..... host bus clock speed is 332.0663 MHz. > > NET: Registered protocol family 16 > > ..APIC TIMER ack delay, reload:20791, safe:20779 > > ..APIC TIMER ack delay, predelay count: 20769 > > ..APIC TIMER ack delay, predelay count: 20786 > > ..APIC TIMER ack delay, predelay count: 20716 > > ..APIC TIMER ack delay, predelay count: 20731 > > ..APIC TIMER ack delay, predelay count: 20747 > > ..APIC TIMER ack delay, predelay count: 20762 > > ..APIC TIMER ack delay, predelay count: 20780 > > ..APIC TIMER ack delay, predelay count: 20729 > > ..APIC TIMER ack delay, predelay count: 20740 > > ..APIC TIMER ack delay, predelay count: 20757 > > Thanks Ian. > From this we see your local apic is indeed counting 1.2 times faster than mine > ratio of 333/266 fsb. So the reload:20791 - safe:20779 gives 12 counts time. > Given 20791 is 1ms on your system then your 12 counts is 577ns > But more importantly from the ack delay theory as your machine like mine is > prone to lockups then a lockup could likely have occured at count:20786 having > only 240ns time expired. Next worst case was less likely to lockup at count:20780.
I just had a lockup running with preempt, now trying with preempt disabled. This is a clean 2.6.0-test11 with just io-apic and apic v2 patches.
> The only ones any delay would have been added to by the patch would be the > count:20786 and count:20780 and it would have been just enough to wait until > the counter got below the safe:20779 so the patch contributes little overhead.
> > Survived my greptest which no non patched kernel has ever done on this > > machine. > > > > Has anyone got that extended ringbuffer to work? I haven't been able to > > get a complete "boot" dmesg in ages because of all the output all the > > drivers make... Does it need a updated dmesg? > > This may be what you have already tried: > I am not sure where it is in the 2.6 config or indeed if it is different but it is > CONFIG_LOG_BUF_SHIFT under kernel hacking on 2.4.23 maybe try 16 for 64K. > To match dmesg output try > > dmesg -s65536 > > (unless dmesg can automatically pick up the expanded ring buffer size on 2.6?)
Ahhh great!, no, it doesn't auto detect it... Maybe there is a newer version, i hate mdk for being so nice to new versions and ignoring the old.
-- Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net [unhandled content-type:application/pgp-signature] | |