On Thu, 20 Jan 2000, Juergen Bierlein wrote:
>i have applied the 2.2.14aa1 Patch, but things went uglier.
This make sense since you said a fully static kernel was locking up as
well.
>Now i am unable to get my KDE Desktop fully started. X is starting, then
>KDE with lots of windows starting and then comes the hard lock. With
>2.2.14 i sometimes get locks when starting my X-Desktop but not always.
The fact is more reproducible is a good thing.
>May be it is something in the scheduling code which gets confused when
>lots of running programs are in the queue (i haven't had a deeper look
>at the code now).
No, the scheduling code is not the problem (unless your hardware screwup
the basic conditional move inside spinlocks or similar buggy-hardware
issues).
I think what can happen is that a different scheduling behaviour could
make a race to trigger more easily.
Could you please chmod -x the X server? Please try to left the machine
running without X. Make sure it's not an X server bug.
>Are there any hints ?
See above :)
>Is it possible to debug a running and then frozen kernel ?
Supposing it's a kernel bug (and not an X one) on IA32 in these cases the
trivial way is the NMI oopser watchdog.
On alpha we could use the rtc and change __cli() to not mask the rtc
interrupt to have the same effect of the NMI interrupt, and using the pit
irq as timer source. I'll probably try that in my 2.3.x irq SMP rewrite.
BTW currently the state of the rewrite is that the code is rock solid on
tsunami and all other platforms except SX164 should be updated.
Andrea
