ddb 'step' recovers from a page fault

[David Young <dyoung%pobox.com@localhost>]

I am seeing "recoverable" page fault traps in ether_output().  What I
mean by "recoverable" is that if I type 'continue' at the ddb prompt,
the fault does not re-occur!  In the console log, below, I have typed
'step' instead of 'continue' at the debugger prompt.  Note that after
the 'step', esp and ss registers have changed from outlandish numbers
(esp 0xc0743240, ss 0x2) to normal numbers (0xc6d427a4, 0x10).

I have a few questions for the collective wisdom:

1 Did the fault really occur at the instruction that ddb indicates,
  movl %ebx,%eax ?  Or is it the instruction before or after?

2 Could the fault indicate that the TLB was momentarily out-of-sync with
  the page table?  How could that occur?

3 What will momentarily corrupt ss and esp?  Is this merely a ddb bug?

4 What information should I collect the next time that this fault occurs?

5 I have a hunch that one or more hardware and/or software interrupts
  occurring while the kernel is in ether_output, is there some simple
  instrumentation that I can add to find out?

6 Why should this fault occur so frequently at this *particular*
  instruction?

FYI, disassembly of ether_output is here,
<ftp://elmendorf.ojctech.com/users/netbsd-8d530943/ether_output.asm>.

Here is the fault:

uvm_fault(0xc58546e4, 0, 2) -> 0xe
kernel: supervisor trap page fault, code=0
Stopped in pid 396.1 (hslsd) at netbsd:ether_output+0x3f:       movl    %ebx,%ea
x
ether_output(c077a004,c0880600,c0836fe0,0,0,c08806d8,c077a004,2,c6d42900,c0843e0
0) at netbsd:ether_output+0x3f
ip6_output(c0880600,0,c0840c90,0,c06f9580,c071b250,0,c0891f38,c077a004,c0843e00)
 at netbsd:ip6_output+0xf76
udp6_output(c0840c60,c0880600,c0855300,0,c6d237a0,c6d237a0,6,c071b250,1,0) at ne
tbsd:udp6_output+0x4e5
udp6_usrreq(c071b250,9,c0891f00,c0855300,0,c6d237a0,c6d237a0,bc,c58546e4,c071b25
0) at netbsd:udp6_usrreq+0x1cc
udp6_usrreq_wrapper(c071b250,9,c0891f00,c0855300,0,c6d237a0,c6d42c48,c,3,c071b2a
4) at netbsd:udp6_usrreq_wrapper+0x2d
sosend(c071b250,c0855300,c6d42c48,c0891f00,0,4,c6d237a0,0,c6d42c08,0) at netbsd:
sosend+0x42c
do_sys_sendmsg(c6d237a0,9,c6d42cb8,4,c6d42d28,0,4792639b,96e1c8c6,8391fcee,c03b3
fb0) at netbsd:do_sys_sendmsg+0x324
sys_sendto(c6d237a0,c6d42d00,c6d42d28,c6d24b80,c02ed526,c5855910,1,9,bb928814,bc
) at netbsd:sys_sendto+0x54
syscall(c6d42d48,b3,bb9000ab,1f,bfbf001f,0,bb91f00c,bfbfda98,bbbe2994,bb91f00c) 
a
t netbsd:syscall+0xa0
ds          0x10
es          0x10
fs          0x30
gs          0x10
edi         0xc0880600
esi         0
ebp         0xc6d427dc
ebx         0
edx         0xe0004c39
ecx         0x4
eax         0
eip         0xc02d1d0f  ether_output+0x3f
cs          0x8
eflags      0x10282
esp         0xc0743240
ss          0x2
netbsd:ether_output+0x3f:       movl    %ebx,%eax
db{0}> con   step
sip0: receive FIFO overrun
sip0: receive ring overrun
Stopped in pid 396.1 (hslsd) at netbsd:ether_output+0x41:       leal    0xffffff
f4(%ebp),%esp
ether_output(c077a004,c0880600,c0836fe0,0,0,c08806d8,c077a004,2,c6d42900,c0843e0
0) at netbsd:ether_output+0x41
ip6_output(c0880600,0,c0840c90,0,c06f9580,c071b250,0,c0891f38,c077a004,c0843e00)
 at netbsd:ip6_output+0xf76
udp6_output(c0840c60,c0880600,c0855300,0,c6d237a0,c6d237a0,6,c071b250,1,0) at ne
tbsd:udp6_output+0x4e5
udp6_usrreq(c071b250,9,c0891f00,c0855300,0,c6d237a0,c6d237a0,bc,c58546e4,c071b25
0) at netbsd:udp6_usrreq+0x1cc
udp6_usrreq_wrapper(c071b250,9,c0891f00,c0855300,0,c6d237a0,c6d42c48,c,3,c071b2a
4) at netbsd:udp6_usrreq_wrapper+0x2d
sosend(c071b250,c0855300,c6d42c48,c0891f00,0,4,c6d237a0,0,c6d42c08,0) at netbsd:
sosend+0x42c
do_sys_sendmsg(c6d237a0,9,c6d42cb8,4,c6d42d28,0,4792639b,96e1c8c6,8391fcee,c03b3
fb0) at netbsd:do_sys_sendmsg+0x324
sys_send

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24