Re: 2.5.46-mm1: CONFIG_SHAREPTE do not work with KDE 3

Waldo Bastian (bastian@kde.org)
Sat, 9 Nov 2002 00:20:30 +0100


>Am Freitag, 8. November 2002 19:18 schrieb Paul Larson:
>> On Wed, 2002-11-06 at 22:53, Andrew Morton wrote:
>> > Dieter Nützel wrote:
>> > > When I enable shared 3rd-level pagetables between processes KDE 3.0.x
>> > > and KDE 3.1 beta2 at least do not work.
>> >
>> > Yup. That's a bug which happens to everyone in the world
>> > except Dave :(
>>
>> I've tried to reproduce this also on a RH 7.3 box. ksmserver is
>> running, but strace says it's stuck on a select() call. There are no
>> kernel messages, but I got this from startx:
>>
>> DCOPServer up and running.
>> Warning: connect() failed: : Connection refused
>
>That's similar to mine.

Not sure where that comes from, it's either someone who tries to make
connection to ksmserver for the purpose of session management or it
is someone who tries to connect to the dcop server. It would surprise
me somewhat if it is the dcop server because the dcopserver has a
self-test and that apparently has succeeded.

It says "KDE does not work" but it doesn't mention to what degree.
Does nothing show up? By the time ksmserver gets executed already a
bunch of KDE processes should be running, what happens with them?

You may want to try to start the various KDE components one by one:

* dcopserver, it's workings can be tested by running the dcop command.
* kbuildsycoca, it should build/verify the sycoca database (see
/tmp/kde-$USER/ksycoca)
* kdeinit, this should start another 4 processes or so
* kedit, simple application
* kwin, window manager, your kedit should now get a window border
* 'kdeinit_wrapper kedit', the same application but now started through kdeinit
* ksmserver
* 'kdeinit_wrapper kedit', the same application but it should now
connect to ksmserver for session management purposes.

You may also want to test what happens when you start ksmserver with
'kdeinit_wrapper ksmserver'

ksmserver, when idle, hangs in a select() waiting for input on some
sockets, including the connection with the X server, (as part of the
Qt event loop) not sure if that select call sets a timeout as well.
You say it "hangs in select", I'm not sure if you mean with that "is
stuck in select()" or just "waits for select to return", but the
latter would be the normal idle state for most KDE applications. They
often (always?) have a timeout set though.

Since you guys seems to be working page-tables the problems may be
related to kdeinit which forks and then loads applications in the
form of libraries. That usage pattern is somewhat different from the
more common fork() + exec() combination. The exec() basically never
happens.

Hope this helps a bit.

Cheers,
Waldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/