5 Jun
2017
5 Jun
'17
8:12 p.m.
Hi,
I'm using 211bsd (Version 447) and found that a 'here document' in tcsh
leads to a kernel panic. It's absolutely reproducible on my system, both
when run it on my FPGA PDP-11 or in simh. Just doing
tcsh
cat << EOF
is enough, and I get
ka6 31333 aps 147472
pc 161324 ps 30004
ov 4
cpuerr 20
trap type 0
panic: trap
syncing disks... done
looking at the crash dump gives
cd /etc/crash
./why 4
Backtrace:
0147372: _boot(05000,0100) from ~panic+072
0147414: _etext(011350) from ~trap+0350
0147450: ~trap() from call+040
0147516: _psignal(0101520,0160750) from ~trap+0364
0147554: ~trap() from call+040
so the crash is in psignal, which is afaik the kernel internal
mechanism to dispatch signals.
Questions:
1. has anybody seen this before ?
2. any idea what the reason could be ?
With best regards, Walter
5 Jun
5 Jun
10:16 p.m.
On 5 Jun 2017 16:12 +0200, from w.f.j.mueller(a)retro11.de (Walter F.J. Mueller):
I'm using 211bsd (Version 447) and found that a
'here document' in tcsh
leads to a kernel panic. It's absolutely reproducible on my system, both
when run it on my FPGA PDP-11 or in simh. Just doing
tcsh
cat << EOF
I'm curious whether the same thing happens if you try that in some
other shell? (Not sure how widely here documents were supported back
then, but I'm asking anyway.)
is enough, and I get
ka6 31333 aps 147472
pc 161324 ps 30004
ov 4
cpuerr 20
trap type 0
panic: trap
syncing disks... done
looking at the crash dump gives
cd /etc/crash
./why 4
Backtrace:
0147372: _boot(05000,0100) from ~panic+072
0147414: _etext(011350) from ~trap+0350
0147450: ~trap() from call+040
0147516: _psignal(0101520,0160750) from ~trap+0364
0147554: ~trap() from call+040
so the crash is in psignal, which is afaik the kernel internal
mechanism to dispatch signals.
The PC value in the panic report ("pc 161324") strikes me as high, but
161324 octal is 58068 decimal, so it's not excessively so, and perhaps
in line with what one might expect to see with a kernel pinned near
top of memory. Are the offsets in the backtrace constant, i.e. does it
always crash on the same code?
Not knowing what cpuerr 20 is specifically doesn't help, and at least
http://www.retro11.de/ouxr/29bsd/usr/src/sys/sys/trap.c.html#n:112
(which doesn't seem to be too far from what you are running) isn't
terribly enlightening; CPUERR is simply a pointer into a memory-mapped
register of some kind, as seen at
http://www.retro11.de/ouxr/29bsd/usr/include/sys/iopage.h.html#m:CPUERR,
and at least pdp11_cpumod.c from the simh source code at
http://simh.trailing-edge.com/interim/pdp11_cpumod.c wasn't terribly
enlightening, though of course I could be looking in entirely the
wrong place.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
10:33 p.m.
Trap type 0 is bus error. The two causes of this are either addressing memory location
that does not respond (as opposed to being umapped) or an word operation on an odd
address.
Since you have a cpuerr print out you have a 44/45/70 CPU. The 020 value indicates that
it was the bus timeout case.
Something touched memory that was mapped in but didn't physically exist.
6 Jun
6 Jun
4:08 a.m.
Nice snipe, Ron! Where might one find the list of trap_types and cpuerrs?
On Mon, Jun 5, 2017 at 12:33 PM, Ron Natalie <ron(a)ronnatalie.com> wrote:
Trap type 0 is bus error. The two causes of this
are either addressing
memory location that does not respond (as opposed to being umapped) or an
word operation on an odd address.
Since you have a cpuerr print out you have a 44/45/70 CPU. The 020 value
indicates that it was the bus timeout case.
Something touched memory that was mapped in but didn't physically exist.
5:43 p.m.
Chapter 3 of the PDP-11 processor handbook.
Crudely scanned copy here:
<http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf>
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170p…
From: Jacob Ritorto [mailto:jacob.ritorto@gmail.com]
Sent: Monday, June 5, 2017 6:08 PM
To: Ron Natalie
Cc: Michael Kjörling; tuhs(a)minnie.tuhs.org
Subject: Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh
Nice snipe, Ron! Where might one find the list of trap_types and cpuerrs?
On Mon, Jun 5, 2017 at 12:33 PM, Ron Natalie <ron(a)ronnatalie.com> wrote:
Trap type 0 is bus error. The two causes of this are either addressing memory location
that does not respond (as opposed to being umapped) or an word operation on an odd
address.
Since you have a cpuerr print out you have a 44/45/70 CPU. The 020 value indicates that
it was the bus timeout case.
Something touched memory that was mapped in but didn't physically exist.
2536
days inactive
2537
days old
4 comments
4 participants
participants (4)
-
Jacob Ritorto -
Michael Kjörling -
Ron Natalie -
Walter F.J. Mueller