Subject: Is this the same de problem?
To: None <port-alpha@netbsd.org>
From: None <kpneal@pobox.com>
List: port-alpha
Date: 08/08/2002 23:01:25
I've got a repeatable crash on my 164lx running 1.5.3.
rune# mount -t nfs tome:/local /mnt
rune# cd /mnt
rune# cd netconf/rune/image
rune# ls -la
total 2604
drwxr-xr-x 4 root wheel 512 Aug 8 21:47 .
drwxr-xr-x 4 root wheel 512 Aug 8 21:34 ..
drwxr-xr-x 5 root wheel 1024 Aug 8 21:38 etc
-rwxr-xr-x 1 root wheel 2552452 Oct 22 2001 netbsd
-rwxr-xr-x 1 root wheel 98304 Aug 8 21:59 netbsd.new
drwx------ 2 root wheel 512 Dec 23 2001 root
rune# cp /netbsd netbsd.new
panic: lockmgr: no context
Stopped at cpu_Debugger+0x4: ret zero,(ra)
db>
Is this the same de bug that was discussed earlier in the week? The
workaround in the other email was, I think, using the tlp driver. I
can't do that since the tlp driver blows up as well (details later).
The problem cards (I have two installed) are combo SCSI-10/100-networking
cards.
ppb0 at pci0 dev 5 function 0: Digital Equipment DECchip 21152 PCI-PCI Bridge (rev. 0x02)
pci1 at ppb0 bus 2
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
siop0 at pci1 dev 4 function 0: Symbios Logic 53c875 (ultra-wide scsi)
siop0: using on-board RAM
siop0: interrupting at eb164 irq 2
scsibus0 at siop0: 16 targets, 8 luns per target
de0 at pci1 dev 6 function 0
de0: interrupting at eb164 irq 13
de0: 21140A [10-100Mb/s] pass 2.2
de0: address 00:06:2b:00:6c:07
de0: enabling 10baseT port
Here's detail on my de problem:
rune# cp /netbsd netbsd.new
panic: lockmgr: no context
Stopped at cpu_Debugger+0x4: ret zero,(ra)
db> show map
fatal kernel trap:
trap entry = 0x4 (unaligned access fault)
a0 = 0xfffffc00004c354c
a1 = 0x29
a2 = 0x12
pc = 0xfffffc0000456d70
ra = 0xfffffc0000315b68
curproc = 0x0
Caught exception in ddb.
db> trace
cpu_Debugger() at cpu_Debugger+0x4
panic() at panic+0xfc
lockmgr() at lockmgr+0xac
uvm_fault() at uvm_fault+0x184
trap() at trap+0x374
XentMM() at XentMM+0x20
--- memory management fault (from ipl 4) ---
tulip_tx_intr() at tulip_tx_intr+0x2bc
tulip_intr_handler() at tulip_intr_handler+0x578
tulip_intr_normal() at tulip_intr_normal+0x1c
alpha_shared_intr_dispatch() at alpha_shared_intr_dispatch+0x6c
eb164_iointr() at eb164_iointr+0x6c
interrupt() at interrupt+0x1dc
XentInt() at XentInt+0x1c
--- interrupt (from ipl 0) ---
idle() at idle+0x24
mi_switch() at mi_switch+0x1fc
ltsleep() at ltsleep+0x2d0
nfs_rcvlock() at nfs_rcvlock+0xdc
nfs_reply() at nfs_reply+0x3c
nfs_request() at nfs_request+0x4fc
nfs_writerpc() at nfs_writerpc+0xb14
nfs_doio() at nfs_doio+0x67c
nfssvc_iod() at nfssvc_iod+0x1e4
start_nfsio() at start_nfsio+0x1c
esigcode() at esigcode
--- root of call graph ---
db> sync
syncing disks...
fatal kernel trap:
trap entry = 0x2 (memory management fault)
a0 = 0x70
a1 = 0x1
a2 = 0x0
pc = 0xfffffc000049017c
ra = 0xfffffc000048ff34
curproc = 0x0
panic: trap
Stopped at cpu_Debugger+0x4: ret zero,(ra)
db> sync
dumping to dev 8,9 offset 4191
--
Kevin P. Neal http://www.pobox.com/~kpn/
'Concerns about "rights" and "ownership" of domains are inappropriate.
It is appropriate to be concerned about "responsibilities" and "service"
to the community.' -- RFC 1591, page 4: March 1994