5 Jun
2017
5 Jun
'17
6: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)