Hi all,
Well, I upgraded my system to glibc 2.2.1 with few problems. Unfortunately,
there are no improvements in my stability problems. X still dies.
So, I ask again, how can I debug this? How can I determine if this is a
kernel problem or not?
Thanks,
--Rainer
-
To
Hi all,
Well, I upgraded my system to glibc 2.2.1 with few problems. Unfortunately,
there are no improvements in my stability problems. X still dies.
So, I ask again, how can I debug this? How can I determine if this is a
kernel problem or not?
Thanks,
--Rainer
-
To
As per Russell King's suggestion, I ran memtest86 on my system for about 12
hours last night. I found no memory errors. Note that the tests did not
complete because I had to stop them this morning. I'll contiue them tonight.
They got through test 9 of 11.
As per David Ford's suggestion, I am
Thanks for all the info, comments below:
First, I ran X in gdb and got the following via 'bt' after X died. This is
my first experience with gdb so if I should do anything in particular,
please tell me.
#0 0x401addeb in __sigsuspend (set=0xb930)
at
Thanks for all the info, comments below:
First, I ran X in gdb and got the following via 'bt' after X died. This is
my first experience with gdb so if I should do anything in particular,
please tell me.
#0 0x401addeb in __sigsuspend (set=0xb930)
at
As per Russell King's suggestion, I ran memtest86 on my system for about 12
hours last night. I found no memory errors. Note that the tests did not
complete because I had to stop them this morning. I'll contiue them tonight.
They got through test 9 of 11.
As per David Ford's suggestion, I am
Rainer Mager wrote:
> > Would this be an SMP IA32 box with glibc 2.2? I have two such boxen
> > showing exactly the same behaviour, although I can't reproduce it at will.
>
> Close, it is actually an SMP IA32 box with glibc 2.1.3. But you've now
> convinced me to not upgrade glibc yet ;-)
On Mon, 22 Jan 2001, Russell King wrote:
> Evidence: I recently had a bad 128MB SDRAM which *always* failed at byte
> address 0x220068,
and X is likely to be the biggest process by far on a box, so
statistically will be the process that hits this bad byte the most.
no?
regards,
--
Paul Jakma
Rogier Wolff writes:
> Harware problems are normally not reproducable. Can you attach a
> debugger to your X server, and catch it when things go bad? (And
> give the Xfree86 people a backtrace)
Bad RAM can be extremely reproducable though, and can certainly produce
SEGVs.
Evidence: I recently
Rainer Mager wrote:
> particular problem still exists. In brief, X windows dies with signal 11. I
[snip]
Does it always happen when you are moving the mouse over a button or
windowbar or some other on-screen object like that?
Usually, when I have that happen, it's because I'm overclocking the
Rainer Mager wrote:
particular problem still exists. In brief, X windows dies with signal 11. I
[snip]
Does it always happen when you are moving the mouse over a button or
windowbar or some other on-screen object like that?
Usually, when I have that happen, it's because I'm overclocking the
Rogier Wolff writes:
Harware problems are normally not reproducable. Can you attach a
debugger to your X server, and catch it when things go bad? (And
give the Xfree86 people a backtrace)
Bad RAM can be extremely reproducable though, and can certainly produce
SEGVs.
Evidence: I recently had
On Mon, 22 Jan 2001, Russell King wrote:
Evidence: I recently had a bad 128MB SDRAM which *always* failed at byte
address 0x220068,
and X is likely to be the biggest process by far on a box, so
statistically will be the process that hits this bad byte the most.
no?
regards,
--
Paul Jakma
> Would this be an SMP IA32 box with glibc 2.2? I have two such boxen
> showing exactly the same behaviour, although I can't reproduce it at will.
Close, it is actually an SMP IA32 box with glibc 2.1.3. But you've now
convinced me to not upgrade glibc yet ;-)
--Rainer
-
To unsubscribe from
Rainer Mager wrote:
> that it is likely a hardware or kernel problem. So, my question is,
> how can I pin point the problem? Is this likely to be a kernel
> issue?
No, not hardware. No not kernel.
Harware problems are normally not reproducable. Can you attach a
debugger to your X server, and
On Mon, 22 Jan 2001, Rainer Mager wrote:
> I brought up this issue last month and had some response but as
> of yet my particular problem still exists. In brief, X windows dies
> with signal 11. I have done quite a bit of testing and this does not
> seem to be a hardware issue. Also, I
On Mon, 22 Jan 2001, Rainer Mager wrote:
I brought up this issue last month and had some response but as
of yet my particular problem still exists. In brief, X windows dies
with signal 11. I have done quite a bit of testing and this does not
seem to be a hardware issue. Also, I have
Rainer Mager wrote:
that it is likely a hardware or kernel problem. So, my question is,
how can I pin point the problem? Is this likely to be a kernel
issue?
No, not hardware. No not kernel.
Harware problems are normally not reproducable. Can you attach a
debugger to your X server, and
Would this be an SMP IA32 box with glibc 2.2? I have two such boxen
showing exactly the same behaviour, although I can't reproduce it at will.
Close, it is actually an SMP IA32 box with glibc 2.1.3. But you've now
convinced me to not upgrade glibc yet ;-)
--Rainer
-
To unsubscribe from this
19 matches
Mail list logo
