Hi,
ok, i have tried it. I have no hangs on the textconsole (box was up for
10 hours with intensiv Memory and IO throughput.
I then tried to run X with KDE together with the old symtom.
I modified my X configuration to startup the X-server manually and then
run startkde manually. The effect was the same.
Next step was to start the X-server and the run fvwm2 manually. The
configuration came up without problems. I was 20 Minutes online via ISDN
and all was fine.
Hmmm, looks like either a X-server or KDE-problem.
I will try to install SuSE 6.3 soon and see if there were some changes
in X and KDE.
Will let u know what is happening,
Juergen
Andrea Arcangeli wrote:
>
> 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
--
################### ################### Juergen Bierlein
################### ################# IT-PSS / Server Management
################### ############### - System Manager
################### ############# Phone: +49 (6227) 7 46986
################### ########### Fax : +49 (6227) 7 56986
## ### ### ## ######### EMail: [EMAIL PROTECTED]
# ###### ## ## # ####### SAP AG Walldorf
# ## # ## ## ##### Neurottstrasse 16
##### # # ##### ### D-69190 Walldorf
# ## ### # ##### # http://www.sap.com/
The sun shines on my way, every night and every day. :-)
