Quoting myself... 
> I'm more hopeful about the patch from Mathieu <cheuche+lkml () free ! fr>...

>           CPU0
>   0:     267486    IO-APIC-edge  timer
>   1:       9654    IO-APIC-edge  keyboard
>   2:          0          XT-PIC  cascade
>   8:          1    IO-APIC-edge  rtc
>   9:          0   IO-APIC-level  acpi
>  14:      28252    IO-APIC-edge  ide0
>  15:        103    IO-APIC-edge  ide1
>  16:     251712   IO-APIC-level  eth0
>  17:      90632   IO-APIC-level  EMU10K1
>  19:     415529   IO-APIC-level  nvidia
>  20:          0   IO-APIC-level  usb-ohci
>  21:        153   IO-APIC-level  ehci_hcd
>  22:      58257   IO-APIC-level  usb-ohci
> NMI:        479
> LOC:     265875
> ERR:          0
> MIS:          0

> this far and it feels like a closer match to what windows does from what
> i have read on the ml. 

I think that this is what we want, ie know how windows handles the spic
since i just bet that all the mb manuf. ppl only care about windows and
anything else is secondary. [Can we get some more info from nvidia about
differences in the setup?]

> I haven't even come close to testing this yet, I've only been up 45 mins
> but i'll leave it running and do what i usually do when it hangs... =)

And that some great 2 hours, everything was dandy, screen refreshes
faster (moving windows with contents was snappier and you saw less
trailing refreshes)... but it ended in a beeeeeeeep deadlock.

I later reproduced it again in console mode... It required 2 full grep
-rne test * in my /usr/src, that is, 2.6.0-test11 and 2.4.23*2 + some
rpm's... all in all: 624M + 219M

-- 
Ian Kumlien <pomac@vapor.com>