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