I had the same experience as @gridcube (comment 15) on Xubuntu
11.10/Oneiric; very slow first open of Thunar, with multiple instances
popping open. Last test, I tried to open my ~/Downloads folder in Thunar
(via Kupfer); while nothing was happening, I tried opening my home
folder in thunar from
@dualityim: FWIW, your workaround in comment #28 works well for me as
well (Maverick 64-bit). Thanks.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-settings-daemon in ubuntu.
https://bugs.launchpad.net/bugs/625670
Title:
I can confirm this as well: top panel always looks awful after a reboot;
generally takes numerous logout/login cycles to get clean theme; fast
system w/nVidia, i7 and SSD:
Maverick/10.10 64-bit
System76 Serval Pro (SER-P6) laptop
Core i7-840QM Processor ( 45nm, 8MB L3 Cache, 1.86GHz )
8 GB - DDR3
Martin, Seth: Thanks for the confirmation. FWIW, I've narrowed my
newfound nasty crashes down to the Chrome browser, with nVidia drivers
installed, but only when on battery power! If I disable nVidia drivers,
or simply keep AC power connected to my laptop, everything is fine; but
with battery
Martin,
Based on my previous comment (#79), I'm curious whether you think this
bug is still relevant or whether I should be opening a new bug (I'm
guessing the latter). I've further confirmed the battery power
relationship by working for a few hours with AC power plugged in and now
crash, then
Martin,
As you suggested, I've changed to this in my gdm.conf:
start on (filesystem
and started dbus
and stopped udevtrigger)
I will run with this for normal use and report back in a few days, or
whenever a crash might occur (hopefully none!). I can also do 20 reboots
in a
Martin:
Crashes which happen during the running GNOME/KDE session are
unrelated to this.
Interesting. After sharing extensive results in bug #625239, it seemed
quite clear that my issue related to the correct bug and that #625239
was a duplicate of this one (and has been marked as such). Am I
Martin:
by looking at glxinfo or just the X server look it should
be possible to detect this situation right after boot.
Sorry, I'm not entirely sure what to look for, but I've attached the
output from a glxinfo command just after boot/login.
** Attachment added: glxinfo.out
Seth:
Include
ps -ef | grep X
gdmtty=$(ps --no-heading -o tty -p $(pgrep X))
stty -F /dev/$gdmtty
ps -f -t $gdmtty
I rebooted, switched to tty1 and I'm attaching the output from the
above. Thanks.
** Attachment added: out_20100922-1156.tgz
@John
Do you remember if you are typing anything when they happen? Anything
else you can remember about the circumstances? You mentioned above a
resume, is that always or usually involved?
I'm fairly certain I was *not* typing anything, but usually had just
clicked something (e.g., a link). I
I have some new clues on my crashes! First, Martin's changes to my
gdm.conf as mentioned in comment #67 did not fix all for me, as I just
had a few more crashes. What I noticed (and had a hunch this morning
too), is that I believe I've primarily (if not always) had crashes occur
while on battery
The patch from comment #64 does not entirely fix this issue for me on
Lucid, although it has certainly improved things. I looked at the patch
and changed my /etc/init/gdm.conf file accordingly (hopefully that's all
I was supposed to do?). My gdm.conf is included with the archive
attached to this
As I mentioned in my previous comment, I had another GDM crash right
after a reboot. The logs for this one are attached here. Please let me
know if there's anything else I can provide. Thanks.
** Attachment added: logs_20100921-2053.tar.gz
Forgive me if I'm missing something, but based on comments from Martin
and Steve, and Seth's thorough testing reported in comment #159, my
understanding is that I should simply wait for the bug #615549 fix to be
back-ported to Lucid. Is this correct? Should I be updating bug #615549
for Lucid in
Steve Langasek wrote in #150:
Thanks. Could you now provide the same files when *not* booting with this
workaround?
Yes, the attached archive contains two sets of logs, both without
vga=799 or any other workaround in place. One has quiet splash
appended to the boot line, which landed X on tty2
Steve,
Please show the contents of a plymouth:debug log, and /proc/fb, when
booting with vga=799 (and without grub_gfxmode set).
Attaching /var/log/udev, /var/log/plymouth-debug.log and /proc/fb after boot
with no GRUB_GFXMODE set and:
GRUB_CMDLINE_LINUX_DEFAULT=vga=799 plymouth:debug
Steve,
Seth, Jamie, can one of you also show the output of 'grep fb
/var/log/kern.log' on a system showing this problem?
Attached, after boot with standard configuration (no workarounds or
related custom config at all).
** Attachment added: kern.log-grep-fb.out
Steve,
I meant to confirm that the boot that produced the output file attached to
comment #127 did indeed land me with X on vt2, and I did crash, as expected,
after a few minutes, when pressing enter in Terminal.
--
X starts on wrong tty because gdm starts before nvidia driver is ready
Steve,
You might also be able to confirm this is the problem by commenting out
the graphics-device-added fb0 part of the start condition.
Okay, testing with standard disto version of /etc/default/grub and the
following in my /etc/init/gdm.conf:
start on (filesystem
and started dbus
Seth,
So let me get this straight, you just removed the graphics-device-added
fb0 PRIMARY_DEVICE_FOR_DISPLAY=1 disjunction?
Yes, that is exactly what I did, and nothing else.
--
X starts on wrong tty because gdm starts before nvidia driver is ready
https://bugs.launchpad.net/bugs/625239
You
Steve, Seth,
The graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1 removal
tweak is not a guaranteed workaround after all. I just booted up again
and crashed within a minute of use. I was just waiting for a Chrome tab
to open--no keyboard activity this time.
--
X starts on wrong tty
I seem to have discovered a slightly new style of crashes, which I believe have
only occurred when I have a modified /etc/init/gdm.conf file. Yesterday and
today I've witnessed this new crash behavior with both:
* Seth's /etc/init/gdm.conf workaround from
Seth,
May I suggest _not_ tweaking your gdm.conf in that particular way
then?
Yes :) I did so only as a workaround, but obviously that was not stable.
I also just discovered that the same crashes can now occur even with a
untouched gdm.conf. Possibly a different bug, sure, but I hope not!?!
Seth, thanks for the additional workaround. I've applied your patch from
ppa:bugs-sehe/gdm625239 and all has been well for about an hour. My boot
time seemed a little slow again, after re-enabling my nVidia drivers,
but I can live with that if I have a stable X session! I will report
back if I see
Seth,
I just installed bootchart, rebooted and had 2 quick crashes (with your
patch installed). I only see black screen when switching tty, so unable
to check out logs so far. I'll report back soon.
--
X starts on wrong tty because gdm starts before nvidia driver is ready
Seth,
With just a couple bootcharts, it appears I take 4 seconds longer to
boot with nVidia drivers enabled. Also, despite having an extremely fast
machine, your boots were about 400% faster than mine! I've attached the
two, in case they're of any interest.
Is there any reason installing
26 matches
Mail list logo
