Mailing List Archive

Alex Buell wrote:
> I was using DDD - just started it up and started debugging when it locked
> up the kernel really solidly, I *mean* SOLID, such that I couldn't use the
This happenned to me the other day when I did a simple "where" in the gdb
console window (note: not using the backtrace dialog). DDD/gdb messes with my
system big time...
Just so you know you're not on crack...
m.
--
"Plausibility is just what it does have, Crito, rather than truth."
-- Socrates, Euthydemus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Alex Buell wrote:
> Which system library are you using? glibc-2.0.111? Or libc5? It might help
> to narrow it down a bit futher so we can kill this bastard of a bug.
Actually, I'm using the glibc-2.0.7-13 rpm from RedHat. I have successfully
compiled 2.0.111, but am too afraid to install it ;), mostly due to the rpm
issues (yeah, I know, I know...).
Crack-smoking penguins...
m.
--
"Plausibility is just what it does have, Crito, rather than truth."
-- Socrates, Euthydemus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Sun, 24 Jan 1999, Michael K Vance wrote:
> This happenned to me the other day when I did a simple "where" in the
> gdb console window (note: not using the backtrace dialog). DDD/gdb
> messes with my system big time...
>
> Just so you know you're not on crack...
Not that I ever do crack, I stick to the green stuff.. but, damn. I was
doing exactly that in DDD. I moved my mouse pointer over DDD's gdb window
and tried to type in something; BOOM, kernel went into orbit. Looks like
there's a nasty interaction between DDD/gdb and the kernel itself
(2.2.0-final) that sends it bye-bye. :o(
Note that gdb on its own works perfectly well. The problem's getting it to
log what's going on in the kernel's brains when it does that. Maybe Tux's
been at the crack again... ;o)
Which system library are you using? glibc-2.0.111? Or libc5? It might help
to narrow it down a bit futher so we can kill this bastard of a bug.
Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!
Linux tahallah 2.2.0-final #74 SMP Thu Jan 21 20:35:00 EST 1999
Two Intel Pentium Pro 166MHz processors, 331.78 total bogomips, 48M RAM
System library 2.0.111
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Sun, 24 Jan 1999, Michael K Vance wrote:
> Actually, I'm using the glibc-2.0.7-13 rpm from RedHat. I have successfully
> compiled 2.0.111, but am too afraid to install it ;), mostly due to the rpm
> issues (yeah, I know, I know...).
Ok, that's one suspect crossed off the list. Can't be the library. GDB
hasn't changed for a long time, neither has DDD. It works quite well with
different kernels I've used. Let's see if the problem occurs with earlier
kernels. If it doesn't, I think Linus will have to wear a paper bag over
his head.. ;o)
> Crack-smoking penguins...
Heh. =)
Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!
Linux tahallah 2.2.0-final #74 SMP Thu Jan 21 20:35:00 EST 1999
Two Intel Pentium Pro 166MHz processors, 331.78 total bogomips, 48M RAM
System library 2.0.111
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Hi,
On Sun, 24 Jan 1999 19:44:40 -0500 (EST), Alex Buell
<alex.buell@tahallah.demon.co.uk> said:
> I was using DDD - just started it up and started debugging when it locked
> up the kernel really solidly, I *mean* SOLID, such that I couldn't use the
> SAK, had to reset the machine. I wasn't even root!
> I found this item in the logs:
> Jan 24 19:33:34 tahallah kernel: Bad pmd in pte_alloc: 000001e3
> What does that mean? I'm assuming this caused my machine to lock up.
> See signature below for system details.
Most of the time it is bad hardware. pte/pmd errors tend to be CPU or
cache more often than ram errors for some reason (dead CPU fans and
overclocking lead to these quite often).
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Mon, 25 Jan 1999, Stephen C. Tweedie wrote:
> > What does that mean? I'm assuming this caused my machine to lock up.
> > See signature below for system details.
>
> Most of the time it is bad hardware. pte/pmd errors tend to be CPU or
> cache more often than ram errors for some reason (dead CPU fans and
> overclocking lead to these quite often).
I doubt it. If it was bad hardware I'd be crashing all the time. This is
the *first* lock-up I've seen for a very long time (and I've been using
Linux since 2.0.27), I have had another report from someone else who
experienced the exact same lockup that I had.
And, my system is not overclocked (I want my machine to give me many years
of enjoyment, instead of running flat out and burning out shortly!), fans
are working properly. The system runs at very conservative settings which
ensures 24/7 100% high availablity except when the power goes out. 8)
I've been talking to that guy about the circumstances in which the lock-up
occurred. The only common factor between his and mine seems to be a fatal
cocktail of DDD & gdb that makes the kernel do a caca[1].
Cheers,
Alex.
[1] French argot, meaning to take a shit.
---
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
Check out http://www.tahallah.demon.co.uk
Linux lo-pc3035a 2.2.0-final #9 Thu Jan 21 13:08:31 EST 1999
One Intel Pentium 75 - 200 processor, 66.36 total bogomips, 16M RAM
System library 5.4.46
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> I doubt it. If it was bad hardware I'd be crashing all the time. This is
> the *first* lock-up I've seen for a very long time (and I've been using
> Linux since 2.0.27), I have had another report from someone else who
> experienced the exact same lockup that I had.
>
> And, my system is not overclocked (I want my machine to give me many years
> of enjoyment, instead of running flat out and burning out shortly!), fans
> are working properly. The system runs at very conservative settings which
> ensures 24/7 100% high availablity except when the power goes out. 8)
There are a trail of strace/ptrace and crash/reboot reports. I've got
several archived from enough people that Im sure its not hardware
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

My two cents worth:
The ptrace code is fragile. I had a test program that would make the
kernel spin in put_long while holding the kernel lock. I didn't make
the test program by looking for boundary test cases; I made it by running
mec-replay in the normal course of development, watching my kernel hang,
and boiling down a test case.
I think a good place to start is to put a loop counter in get_long
and put_long in arch/*/kernel/ptrace.c and log messages or panic
if the loop counter exceeds 1000. Also drop in some printk's at
the beginning and end of sys_ptrace catch the call sequence. Then add
another two dozen printk's, et cetera.
Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/