Re: KDE4 testing on Alpha
On Sat, Dec 10, 2011 at 08:03:46PM +0100, Pino Toscano wrote:
> If it's the virtuoso process to create issue, you can try disabling the
> semantic desktop (which uses the virtuoso DB): either you uninstall the
> virtuoso packages, or disable nepomuk for your user in a console with:
> $ kwriteconfig --file nepomukserverrc --group "Basic Settings" \
> --key "Start Nepomuk" --type bool false
> (you can also do that in the "semantic desktop" section of
> `systemsettings`)
>
> If that does not avoid the hard lockup, I don't have more ideas at the
> moment...
Thank you for your reply. Disabling nepomuk did not seem to have any
effect. In fact, with the 3.2-rc5 kernel, the lock-up happened even
more quickly. When starting KDE4, there's the splash screen and five
icons that fade-in from left to right. At the point where the big "K"
icon finishes fading-in, that's where the system locked up this time.
It has done so at this precise point in the past, which is why I suspect
issues with KMS/drm. For what it's worth, Gnome-3 (which requires KMS)
isn't working either: I can't test Gnome-3 components using FreeNX
because there's no KMS for that type of display, so I get "fallback
mode" (Gnome-2) by default.
I'll go ahead and reenable nepomuk, and then try another KDE4 FreeNX
session. Would it be correct to assume nepomuk/virtuoso isn't the issue
if I see those processes running for the FreeNX desktop session?
Trying to debug large packages where there may be multiple failure modes
in play is difficult. I'm trying to determine all the differences
between console and non-console (e.g., FreeNX) GUI sessions, but the
most obvious difference is kernel modesetting. KDE session differences
due to whether KMS is available/enabled would be nice to know about, but
my level of knowledge as to KDE internals is limited at best :-(.
--Bob
Reply to: