As mentioned lately in another thread I moved to amd64 unstable last week.
So far OK ... but:
I see X11 crashing repeatedly but I don't have a clue what component
might be the reason.
Sometimes my gnome-session (2.28) works for hours, sometimes for minutes.
It crashes when starting a new program like opera, firefox, thunderbird,
amarok, ... something ....
I don't have a clear way to reproduce the crash and the logs don't tell
me anything.
-->
I rebuilt xorg-server, xorg-drivers, xf86-input-* .... opera, etc
I re-emerged @system overnight, ran revdep-rebuild, lalefixer etc (yeah,
I know, X11 isn't @system ... but just to do the basement right)
I use nvidia-drivers here, so I also did "eselect opengl ..." again.
I erased xorg.conf and redid it via nvidia-xconfig ... and changed it to
use absolute coordinates, as the xorg-server-1.7 seems to have issues
with "LeftOf" ...
Additional info:
I use compiz and xinerama ... two monitors ... might add some problems.
The two monitors are the reason for still using xorg.conf with
xorg-server-1.7.x (maybe there's a better solution? I don't know yet).
bugs.gentoo.org doesn't show anything describing my issues, I hesitate
to file a bug as long as the symptoms are that vague ...
Some clues, someone?
There were NO such crashes before moving to full ~amd64, I ran
xorg-server-1.6 before (mixing stable and unstable ...).
Simply going back to xorg-server-1.6 ?
Thanks a lot, Stefan.
Daniel
What happens when X crashes? Does the X session go away? Is there an error
message? Or does it just hang?
Your symptoms as described are random, I find far more often than not that is
hardware, usually the power supply, ram and video card (in that order)
Give your hardware a thorough stress test, then only start playing with
downgrades
--
alan dot mckinnon at gmail dot com
> I might have a similar problem, that is definitely related to the second
> monitor and power management. If you disconnect your 2nd monitor, do the
> crashes still occur? But maybe this isn't related, because I have a
> Radeon card... just a lucky guess...
I could try with one monitor only, yes. Thanks for the hint, I'll give
it a try asap.
>> Sometimes my gnome-session (2.28) works for hours, sometimes for minutes.
>
> What happens when X crashes? Does the X session go away? Is there an error
> message? Or does it just hang?
The whole X-session restarts, as if I do "xdm restart" or
"ctrl-alt-backspace". I get back to the login-prompt of gdm.
No error message, I also browsed the xorg-logs, dmesg, /var/log/messages
... nothing related as far as I understand.
> Your symptoms as described are random, I find far more often than not that is
> hardware, usually the power supply, ram and video card (in that order)
>
> Give your hardware a thorough stress test, then only start playing with
> downgrades
Hmm, I don't know ... why should a hardware-problem only shoot X11 ... ?
It should crash then also when I dualboot windows xp for gaming (it does
not crash there even under quite high gaming load).
OK, RAM might do that, I had a customers pc which rebooted (! reboot,
not only kicking off one app) here and then because of defective RAM.
I start some memtest while having my coffee just to check that out for a
start.
But I really assume some other reason, as I only recently went up to
~amd64 ... for me it is much more likely that maybe the step up to
xorg-server 1.7.x or something related might be the reason here.
bugs.gentoo.org didn't really list such a bug, maybe I should file one.
But to me it seems a bit early as I can't reproduce it or really show
some error-messages so far.
Greets, Stefan
I still think a hardware stress test will be useful. The least that will
happen is you will verify your hardware is probably OK.
If it is software, then you have a long road ahead of you debugging it. With
no error messages of any kind you will likely have to rebuild in debug mode
and provide the devs with a backtrace. In which case it's probably easier to
downgrade to versions you know work.
I can attest to xorg-server-1.7.1 working just fine here with latest nvidia-
drivers in the tree on amd64
> I still think a hardware stress test will be useful. The least that will
> happen is you will verify your hardware is probably OK.
hmm, yes. What do you suggest? I ran memtest for 2 passes now without an
error. Maybe I will game a bit this evening, this should stress the
graphics, cpu, ram quite a bit as well ...
> If it is software, then you have a long road ahead of you debugging it. With
> no error messages of any kind you will likely have to rebuild in debug mode
> and provide the devs with a backtrace. In which case it's probably easier to
> downgrade to versions you know work.
>
> I can attest to xorg-server-1.7.1 working just fine here with latest nvidia-
> drivers in the tree on amd64
Just to compare:
xorg-server: 1.7.1
nvidia-drivers: 190.42-r3
compiz: 0.8.4
compiz-fusion: 0.8.4
(hmm, I assume I don't need them both?)
emerald: 0.8.4
gnome 2.28 ... ~amd64 everything ...
Linux version 2.6.31-tuxonice (gcc version 4.4.2 (Gentoo 4.4.2 p1.0) )
----
hmmm.
Greets, Stefan
> I can attest to xorg-server-1.7.1 working just fine here with latest nvidia-
> drivers in the tree on amd64
Update: no more crashes for 2 days now (ok, I wasn't working full days
on the machine, but for several hours today, seems OK now).
Maybe some of the newer updates fixed something, or it crashes again
after I hit SEND for this message.
SEND
;)
and as I said: within minutes after SEND I clicked gwibber and BANG ...
:-(
S
> I can attest to xorg-server-1.7.1 working just fine here with latest
> nvidia- drivers in the tree on amd64
Here I have xorg-server-1.7.1 on an all-~amd64 system and I get long delays,
no matter whether I use nv or nvidia-drivers-190.42-r3. This is with
kde-4.3.3.
--
Rgds
Peter
> I can attest to xorg-server-1.7.1 working just fine here with latest nvidia-
> drivers in the tree on amd64
I somehow think the use-flag "xinerama" might be responsible.
Do you use that one?
I currently rebuild some pkgs without it ...
nvidia-driver and multi-monitors will NOT work with USE="-xinerama"
TwinView uses the xinerama protocol to do it's stuff, it doesn't
mean it uses the xinerama app to render onto large screens composed
of multiple monitors
> nvidia-driver and multi-monitors will NOT work with USE="-xinerama"
>
> TwinView uses the xinerama protocol to do it's stuff, it doesn't
> mean it uses the xinerama app to render onto large screens composed
> of multiple monitors
So you have xinerama in make.conf, correct?
Right now I rebooted without xinerama, looks a bit different, but works
... but I prefer the other way.
S
You are misunderstanding. There are two things with the name
xinerama - one is an X protocol to allow multiple screens to chat
with each other, the other is a chunk off code to do it.
nvidia-drivers uses the former. When you say "I rebooted without
xinerama" you are trying to do the latter (I have no ide how you
would do that, but still).
So. Do not run xinerama. Do put xinerama in USE.
> You are misunderstanding. There are two things with the name
> xinerama - one is an X protocol to allow multiple screens to chat
> with each other, the other is a chunk off code to do it.
>
> nvidia-drivers uses the former. When you say "I rebooted without
> xinerama" you are trying to do the latter (I have no ide how you
> would do that, but still).
I meant:
I rebooted after re-emerging every relevant pkg with USE="-xinerama"
So that no pkg with enabled useflag xinerama would be active.
> So. Do not run xinerama. Do put xinerama in USE.
I do now, as I always did before the strange crashes happened.
I rebuilt the relevant pkgs with "xinerama" in USE, yep.
Since then no crashes, but I would have to test clicking some more stuff
to really believe ...
Thanks, Stefan
> Since then no crashes, but I would have to test clicking some more stuff
> to really believe ...
As always, after hitting SEND ... one more crash ...
Sometimes it crashes after clicking opera, sometimes after clicking
thunderbird, so far never when clicking/starting a gnome-terminal.
I am still looking for a pattern or an error-message somewhere ...
Stefan
This reminds me of a problem we had just recently.
Have you got a multi-core CPU ?
If yes, read on.
We have 6 machines here running an identical Gentoo system
(just different hostname and IP number)
with a AMD Phenom II quad core CPU and identical mother boards.
One of them had these random crashes you reported.
I've totured memory by running up to 3 memtester-processes
over night - no single fault. Our dealer has replaced the motherboard -
again no change. Then I suspected the CPU itself although it has stood
a burnK7 run for several hours.
After the CPU has been replaced the spook has gone.
I suspect a cache coherence problem. The normal memory tests
assign a given window of the physical storage to a given core -
even if run in parallel. But a typical usage under Linux switches
the core which executes a given thread quite frequently.
Now the Phenom II has 4 core each with a private 0.5 Mb primary cache
but a 6 Mb second level cache common to all 4 cores.
In the BIOS one can opt for all 4 cores using this secondary cache
or for only a single core using it.
When a core writes to this cache or to memory all other cores must be
informed that their private cache is invalid. If this doesn't happen or
happens a bit too late, a core will fetch invalid (old) memory contents
which may result in a crash.
So, if you can, set the BIOS switch that only a single core
can use the secondary cache. If the problems disappears
the CPU is broken.
I hope you can solve your problem,
Helmut.
--
Helmut Jarausch
Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany
Phew, quite some theory ... do you positively know that this was the reason?
I think I haven't seen such a setting in my BIOS.
I use an Intel Core2Duo E6600 on a Intel DP965LT board here, 8 gigs of
RAM lately ...
BUT my issues really only started after completely going to ~amd64, I
never saw such a crash before when I used a mixed setup (most pkgs
stable, some unstable ...)
I will have a look at my BIOS now.
Thanks anyway for that information, greets to Aachen (from Austria) ...
Stefan
If you all think it might be multi-core related, check out a recent
post that was syndicated to planet.gentoo:
http://gentooexperimental.org/~patrick/weblog/archives/2009-11.html#e2009-11-19T00_43_58.txt
This discusses how using a feature in the 2.6.32 kernel one can kill
various cores in a multi-core system.
In any case, it's a way to experiment with this theory.
~daid
Thanks for the link.
I rather suspect something else:
Just now had a look at the gnome-shell as I read another thread from 2
days ago ... (Mike Higgins on this list ...) mentioning this new gnome-part.
I disabled compiz and used gnome-shell.
It started fine but I was not able to start thunderbird, it always
crashed the session. Starting opera and/or firefox: OK
Another thing I did today (before that gnome-shell-test):
I remembered that I had added the gnome-overlay back then when I wanted
gnome-2.28 but still wasn't using full ~amd64.
So I wondered if I might have pulled some packages from there that
caused my crashes. I removed the overlay and did a "emerge -avuDN world"
, some pkgs were rebuilt, (yep, revdep-rebuild as well) after that I did
a reboot but still the X-session crashed occasionally.
Only with gnome-shell it seems to be thunderbird that does something
special ...
OK, I perfectly know that gnome-shell is beta ... just to add some info
to this thread.
I will now disable compiz and see what happens.
Greets to you, Stefan
> I will now disable compiz and see what happens.
could have waited for that:
first click on thunderbird crashed session, logged in again, next click
opend thunderbird fine.
hmm
So, just to test the theory "it works until I hit SEND" again ;-) ->
Not a single crash since I upgraded to xorg-server-1.7.2
Stefan
SEND
and which you will be asked to downgrade back to 1.7.1 with the next --sync.
With luck, it won't bring your crashes back.
One of the most valuable files you get when you do a --sync is
$PORTDIR/profiles/package.mask. It answers this question:
# Rémi Cardona <re...@gentoo.org> (29 Nov 2009)
# Breaks Video ABI
=x11-base/xorg-server-1.7.2
>> Not a single crash since I upgraded to xorg-server-1.7.2
>
> and which you will be asked to downgrade back to 1.7.1 with the next --sync.
Correct, I already saw that but ignored it so far as I am so happy
without "my" crashes.
> With luck, it won't bring your crashes back.
What's the reason for the downgrade? Should I do it?
Greets, Stefan
> One of the most valuable files you get when you do a --sync is
> $PORTDIR/profiles/package.mask. It answers this question:
>
> # R�mi Cardona <re...@gentoo.org> (29 Nov 2009)
> # Breaks Video ABI
> =x11-base/xorg-server-1.7.2
everyday is schoolday.
Thank you, Alan.
I decide to leave it as it is for the next days.
Afaik I don't need Video ABI on this machine for now.
Stefan
> I decide to leave it as it is for the next days.
> Afaik I don't need Video ABI on this machine for now.
I gave it a try and went back to 1.7.1 ... the first click after login
crashed the session.
So it seems to be related to xorg-server here.
I will do some more tests to filter things out a bit closer.
This will maybe allow me to file a meaningful bug.
S
> So it seems to be related to xorg-server here.
>
> I will do some more tests to filter things out a bit closer.
> This will maybe allow me to file a meaningful bug.
For the records: 1.7.2 has been dropped because of that Video ABI stuff,
1.7.3 is stable for me since I built it.