>Number:         21964
>Category:       kern
>Synopsis:       kernel traps in in_pcbconnect
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 23 04:14:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Brian de Alwis
>Release:        NetBSD 1.6U
>Organization:
>Environment:
System: NetBSD slab 1.6U NetBSD 1.6U (SLAB) #3: Fri Jun 20 12:09:38 PDT 2003 bsd@slab:/usr/src/sys/arch/i386/compile/SLAB i386
Architecture: i386
Machine: i386
>Description:
	I received the following trap on my laptop running very recent
	-current.  I don't think I triggered anything, as I was only
	doing some editting in vi at the time (the previous message
	was from 5 minutes previous):

    Jun 22 20:20:37 slab apm: Resuming done.
    Jun 22 20:25:03 slab syslogd: restart
    Jun 22 20:25:03 slab /netbsd: uvm_fault(0xd3dddb44, 0, 0, 1) -> 0xe
    Jun 22 20:25:03 slab /netbsd: fatal page fault in supervisor mode
    Jun 22 20:25:03 slab /netbsd: trap type 6 code 0 eip c010a588 cs 8 eflags 10297 cr2 60 ilevel 5
    Jun 22 20:25:03 slab /netbsd: panic: trap
    Jun 22 20:25:03 slab /netbsd: Begin traceback...
    Jun 22 20:25:03 slab /netbsd: trap() at netbsd:trap+0x21a
    Jun 22 20:25:03 slab /netbsd: --- trap (number 6) ---
    Jun 22 20:25:03 slab /netbsd: in_pcbconnect(c0a72288,c0a09200,10,c026b101,0) at netbsd:in_pcbconnect+0x19c
    Jun 22 20:25:03 slab /netbsd: udp_usrreq(c0af60d0,4,0,c0a09200,0) at netbsd:udp_usrreq+0x1a1
    Jun 22 20:25:03 slab /netbsd: soconnect(c0af60d0,c0a09200,10,3,d3de5e84) at netbsd:soconnect+0x8d
    Jun 22 20:25:03 slab /netbsd: sys_connect(d3de5e84,d3e38f80,d3e38f78,c02de74c,48272300) at netbsd:sys_connect+0x82
    Jun 22 20:25:03 slab /netbsd: syscall_plain(1f,1f,1f,1f,8098000) at netbsd:syscall_plain+0xab
    Jun 22 20:25:03 slab /netbsd: End traceback...
    Jun 22 20:25:03 slab /netbsd: syncing disks... 1 1 1 done
    Jun 22 20:25:03 slab /netbsd: 
    Jun 22 20:25:03 slab /netbsd: dump to dev 0,1 not possible
    Jun 22 20:25:03 slab /netbsd: rebooting...

	Following the stack trace, and some objdump, in_pcbconnect
	starts at 0x59c, and so 0x19c in is address 0x738, which
	correlates to this section, using objdump:

     726:       83 c4 10                add    $0x10,%esp
     729:       83 f8 23                cmp    $0x23,%eax
     72c:       75 0a                   jne    738 <in_pcbconnect+0x19c>
     72e:       b8 23 00 00 00          mov    $0x23,%eax
     733:       eb 77                   jmp    7ac <in_pcbconnect+0x210>
     735:       8d 76 00                lea    0x0(%esi),%esi
     738:       8b 43 60                mov    0x60(%ebx),%eax
     73b:       89 46 44                mov    %eax,0x44(%esi)
     73e:       89 5e 68                mov    %ebx,0x68(%esi)
     741:       8b 83 94 00 00 00       mov    0x94(%ebx),%eax

	This seems to be in the following lines from in_pcbconnect (from
	net/in_pcb.c, $NetBSD: in_pcb.c,v 1.82 2003/06/15 02:49:33 matt Exp $):

                       if (error == EAGAIN)
                                return (error);
                }               
                KASSERT(inp->inp_ia == NULL);
                inp->inp_laddr = ia->ia_addr.sin_addr;	/** LINE 439 **/
                inp->inp_ia = ia;
                LIST_INSERT_HEAD(&ia->ia_inpcbs, inp, inp_ialink);

	From the assembly, my guess is it corresponds to the load
	of `ia->ia_addr.sin_addr' in the line 439; I'm supposing
	I don't have KASSERT defined.  From looking above, I'd
	guess in my circumstance, this code never enters the foreach
	loop 389, and somehow skips the situation at line 419 such
	that <ia> is NULL.

	As to my situation: my laptop has a builtin ethernet (an
	3Com 3c905C-TX 10/100).  I had this configured to a local
	network in my home, but had powered off the small hub, so
	the machine was effectively standalone.

>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: