Subject: port-pmax/17894: pmax X server causes TLB miss w/ securelevel=1
To: None <email@example.com>
From: John Hawkinson <firstname.lastname@example.org>
Date: 08/08/2002 11:03:40
>Synopsis: pmax X server causes TLB miss w/ securelevel=1
>Arrival-Date: Fri Aug 09 08:18:01 PDT 2002
>Originator: John Hawkinson
>Release: NetBSD 1.6_BETA5
System: NetBSD phantom.mit.edu 1.6_BETA5 NetBSD 1.6_BETA5 (PHANTOM) #1: Tue Aug 6 18:27:20 EDT 2002 email@example.com:/usr/src/sys/arch/pmax/compile/PHANTOM pmax
On this freshly installed 1.6_BETA5 5000/25, attempted to
start the X server yields:
trap: TLB miss (load or instr. fetch) in kernel mode
status=0x0, cause=0x2808, epc=0x8020fa3c, vaddr=0x2003c
pid=915 cmd=Xpmax usp=0x7ffffeaf8 ksp=c48e7b30
And then it immediately goes into a downward spiral, repeating the
same trap over and over again, with the epc and vaddr 0'd, and
the ksp counting down.
the epc was uvm_mmap+0x308. It took a lot of speed to try to get the
numbers written down before they scrolled off, so I didn't try too hard
on the others, thus confidence is low.
There seem a number of problems here:
1) That we get a TLB miss at all
2) That the TLB miss leads to a continual stream of TLB misses counting
down the stack. Is this a generic bug in the TLB handler?
3) That we don't go into DDB [or something -- though DDB_ONPANIC is
apparently 0, so perhaps this is unremarkable?] or return to
Ctrl-Alt-Escape and Ctrl-Alt-Del do nothing.
Then I tried starting the X server from single user mode, and of course
it worked. A little light went on, and I determined that setting securelevel
to 1 causes this problem to exist, otherwise the X server works fine.
kernel config is GENERIC+2 fonts.
Here's the dmesg output:
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 1.6_BETA5 (PHANTOM) #1: Tue Aug 6 18:27:20 EDT 2002
Personal DECstation 5000/25 (MAXINE)
total memory = 40960 KB
avail memory = 34236 KB
using 537 buffers containing 2148 KB of memory
cpu0 at mainbus0: MIPS R3000A CPU (0x230) Rev. 3.0 with MIPS R3010 FPC Rev. 4.0
cpu0: 64KB/4B direct-mapped Instruction cache, 64 TLB entries
cpu0: 64KB/4B direct-mapped write-through Data cache
tc0 at mainbus0: 12.5 MHz clock
ioasic0 at tc0 slot 3 offset 0x0
le0 at ioasic0 offset 0xc0000: address 08:00:2b:2a:79:ee
le0: 32 receive buffers, 8 transmit buffers
scc0 at ioasic0 offset 0x100000
mcclock0 at ioasic0 offset 0x200000: mc146818 or compatible
bba0 at ioasic0 offset 0x240000
audio0 at bba0: full duplex, mmap
dtop0 at ioasic0 offset 0x280000
fdc at ioasic0 offset 0x2c0000 not configured
asc0 at ioasic0 offset 0x300000: NCR53C94, 25MHz, SCSI ID 7
scsibus0 at asc0: 8 targets, 8 luns per target
xcfb0 at tc0 slot 2 offset 0x0: 1024x768x8 console
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <QUANTUM, FIREBALL_TM2110S, 300X> SCSI2 0/direct fixed
sd0: 2014 MB, 6810 cyl, 4 head, 151 sec, 512 bytes/sect x 4124736 sectors
sd0: sync (200.0ns offset 15), 8-bit (5.000MB/s) transfers, tagged queueing
sd1 at scsibus0 target 3 lun 0: <SEAGATE, ST31200N, 8648> SCSI2 0/direct fixed
sd1: 1006 MB, 2700 cyl, 9 head, 84 sec, 512 bytes/sect x 2061108 sectors
sd1: sync (200.0ns offset 15), 8-bit (5.000MB/s) transfers, tagged queueing
Kernelized RAIDframe activated
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs
workaround: options INSECURE
real fix: I dunno, I'm not familiar enough with this code.