When I enable shared 3rd-level pagetables between processes KDE 3.0.x and KDE
3.1 beta2 at least do not work.
Especially "ksmserver" do not start anylonger.
Taken from my root's .xsession-errors file:
Mutex destroy failure: Device or resource busy
Mutex destroy failure: Device or resource busy
kdeinit: Pipe closed unexpectedly: No such file or directory
kdeinit: Pipe closed unexpectedly: Success
KInit could not launch 'ksmserver'.
kdeinit: Fatal IO error: client killed
ICE default IO error handler doing an exit(), pid = 4489, errno = 2
ICE default IO error handler doing an exit(), pid = 4497, errno = 0
kdeinit: Communication error with launcher. Exiting!
kdeinit: sending SIGHUP to children.
kdeinit: sending SIGTERM to children.
kdeinit: Exit.
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
DCOPClient::attachInternal. Attach failed Could not open network socket
Any ideas?
Thanks,
Dieter
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 :(
Sorry, I should have mentioned that in the release notes. shared
pagetables are still "under development".
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
It looks like maybe this problem shows up in different ways. Anyone
have ideas about how to debug this?
-Paul Larson
Am Freitag, 8. November 2002 16:27 schrieben Sie:
> --On Friday, November 08, 2002 01:50:04 +0100 Dieter N?tzel
>
> <[email protected]> wrote:
> > Any clue for what I should looking for or how we get some useful log?
> > I'll try ksmserver and kdm "by hand".
>
> How do you start KDE? I'm not a regular KDE user, so I just call ksmserver
> in my .xinitrc file. What's the proper way to start it?
Don't know...;-)
OK, I think all would be started through "rcxdm" which call "kdm" and "kdm"
run "startkde" (SuSE 3.1 beta version included).
Wild guess: Could it be "FAST_MALLOC"?
# Should we really enable FAM support for KDE ?
export USE_FAM="$KDE_USE_FAM"
# Should we use the fast malloc function from kdecore ?
case $KDE_USE_FAST_MALLOC in
yes|YES|1) KDE_MALLOC=1 ;;
esac
I'll try without it, but have to rebuild my kernel with SHAREPTE before.
-Dieter
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.
> It looks like maybe this problem shows up in different ways.
Somewhat.
> Anyone have ideas about how to debug this?
See my former post.
Maybe some KDE developers out here?
-Dieter
>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