Subject: Is this the same de problem?
To: None <>
From: None <>
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
drwx------  2 root  wheel      512 Dec 23  2001 root
rune# cp /netbsd
panic: lockmgr: no context
Stopped at      cpu_Debugger+0x4:       ret     zero,(ra)

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 

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
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                      
      '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