Ahmon Dancy wrote:
>
> On the topic of various ways to try to fix the lockup problem..
> perhaps we should try a different approach.
> Does anyone know the exact nature of the lockup? i.e.:
> Is the kernel getting stuck in a loop somewhere?
> Is the kernel waiting for something to happen that will never happen?
> Is it an actual hardware lockup? i.e., Is the CPU trying to talk to hardware
> that is no longer responding?
I haven't had a lockup in a long while, but IIRC there were two types:
one in which you got a mesg "TLB stuck on IPI wait" when one CPU hung
but the other was still working, and a total non-responsive lockup.
This second wouldn't respond to any interrupts, so I believe was
a failure of the [IO] APIC or it's bus. This thing is an accident
waiting to happen [open drain wired-or at BCLK/4]. Abit didn't
help by placing the Southbridge PIIX4 where the IO-APIC lives so
far away from the CPUs.
> Unfortunately, the best person to answer this is probably
> Andre.. but he doesn't experience the problem.
He's also smart enough not to put a lockup generator^H^H^H^H^H^H
sound card in his machines. I firmly believe the hardware side
of these things were never designed for reliability, still less
for real operating systems, and the drivers still less for SMP.
I have put my BP6es under brutal interrupt load: full-dupex,
bi-directional runt-packet flood pings on two 100bTX ethercards
through crossover cables to other machines, plus md5sum /dev/hda1
and HZ=1000. They stay stable. I've got the /proc/interrupts
around somewhere.
I'd like to learn how to program the parport, especially register
an ISR, so I could try to reach even higher int loads. I can get
~300kints/sec (near theoretical) with the APIC ICR, but that's
cheating because it doesn't use the weak IO-APIC.
-- Robert author `cpuburn` http://users.ev1.net/~redelm
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
