Bug 13736

Summary: enabling NAT on 3.3RC results in panic sbappendaddr.
Product: Base System Reporter: kythorn <kythorn>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description kythorn 1999-09-13 19:20:00 UTC
I have recently enabled NAT on my machine, and it has started crashing with a "Panic: sbappendaddr"

I had previously submitted this to freebsd-bugs, but was asked to open an official PR.

The machine is a p166 with 32 megs of ram.

It has two Linksys LNE100TX 10/100mbit ethernet cards.  Before I enabled NAT on this machine, it had one of these cards in it, for normal LAN usage.  I had no problems in that enviroment. 

Here is a trace from the latest crash:

Debugger(c02a0dbb,c3286f00,c050f880,c33f5f50,c017f4d7) at Debugger+0x42
panic(c02a23d2,c3286f00,c050f880,820f144,c33f5f70) at panic+0x74
sbappendaddr(c3286f44,c02f9630,c050f880,0) at sbappendaddr+0x2b
div_input(c050f880,14,c050f880,8169bc,820f144 at div_input+0x12a
ip_input(c050f880) at ip_input+0x69f
ipintr(c024dab3,0,27,27,820f144) at ipintr+0x4b
swi_net_next() at swi_net_next

coredumps and my debug kernel, or anything else you would find useful are available upon request, I do not know how to submit them with this interface. I apologize if I am doing anything wrong in submitting this, I have only been using FreeBSD for a couple of weeks, and am ignorant of official protocols and procedures.

How-To-Repeat: The problem repeats itself at seemingly random intervals.  It apparently has nothing to do with load, or network traffic, as I have transferred several hundred megabytes of data over FTP without a hitch, only to have it crash while I checked my email.
Comment 1 Ruslan Ermilov 1999-09-13 19:37:23 UTC
On Mon, Sep 13, 1999 at 11:11:01AM -0700, kythorn@scorched.com wrote:
> 
> coredumps and my debug kernel, or anything else you would find useful are available upon request, I do not know how to submit them with this interface. I apologize if I am doing anything wrong in submitting this, I have only been using FreeBSD for a couple of weeks, and am ignorant of official protocols and procedures.
> 
Please config your kernel with debug symbols (config -g YOUR_CONFIG),
follow up the instructions on http://www.FreeBSD.org/handbook/kerneldebug.html,
section "Debugging a Kernel Crash Dump with kgdb", and send us
the script(1) of your `gdb -k' session.


Thanks,
-- 
Ruslan Ermilov		Sysadmin and DBA of the
ru@ucb.crimea.ua	United Commercial Bank,
ru@FreeBSD.org		FreeBSD committer,
+380.652.247.647	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age
Comment 2 kythorn 1999-09-13 20:38:54 UTC
Script started on Mon Sep 13 15:30:50 1999
bash-2.03# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 2744320
initial pcb at 234e94
panicstr: sbappendaddr
panic messages:
---
panic: sbappendaddr

syncing disks... done

dumping to dev 20001, offset 196608
dump 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
6 5 4 3 2 1
---
#0  boot (howto=256) at ../../kern/kern_shutdown.c:285
285   dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:285
#1  0xc012f4d1 in panic (fmt=0xc02096ca "sbappendaddr")
    at ../../kern/kern_shutdown.c:446
#2  0xc0148d97 in sbappendaddr (sb=0xc32c5f44, asa=0xc02261cc,
m0=0xc050fc80,
    control=0x0) at ../../kern/uipc_socket2.c:592
#3  0xc0171d56 in div_input (m=0xc050fc80, hlen=20)
    at ../../netinet/ip_divert.c:233
#4  0xc0175607 in ip_input (m=0xc050fc80) at ../../netinet/ip_input.c:708
#5  0xc017566f in ipintr () at ../../netinet/ip_input.c:735
#6  0xc01e55b1 in swi_net_next ()
Cannot access memory at address 0x745a3357.
(kgdb) up
#1  0xc012f4d1 in panic (fmt=0xc02096ca "sbappendaddr")
    at ../../kern/kern_shutdown.c:446
446  boot(bootopt);
(kgdb) up
#2  0xc0148d97 in sbappendaddr (sb=0xc32c5f44, asa=0xc02261cc,
m0=0xc050fc80,
    control=0x0) at ../../kern/uipc_socket2.c:592
592 panic("sbappendaddr");
(kgdb) up
#3  0xc0171d56 in div_input (m=0xc050fc80, hlen=20)
    at ../../netinet/ip_divert.c:233
233   if (sbappendaddr(&sa->so_rcv, (struct sockaddr *)&divsrc,
(kgdb) up
#4  0xc0175607 in ip_input (m=0xc050fc80) at ../../netinet/ip_input.c:708
708  (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen);
(kgdb) up
#5  0xc017566f in ipintr () at ../../netinet/ip_input.c:735
735   ip_input(m);
(kgdb) up
#6  0xc01e55b1 in swi_net_next ()
(kgdb) up
Cannot access memory at address 0x745a3357.
(kgdb) quit
bash-2.03# exit
exit

Script done on Mon Sep 13 15:31:37 1999

I hope this is the output you wanted.  If you need any other info, just ask.

- Jay Oliver
kythorn@scorched.com



> Please config your kernel with debug symbols (config -g YOUR_CONFIG),
> follow up the instructions on
http://www.FreeBSD.org/handbook/kerneldebug.html,
> section "Debugging a Kernel Crash Dump with kgdb", and send us
> the script(1) of your `gdb -k' session.
>
>
> Thanks,
> --
> Ruslan Ermilov Sysadmin and DBA of the
> ru@ucb.crimea.ua United Commercial Bank,
> ru@FreeBSD.org FreeBSD committer,
> +380.652.247.647 Simferopol, Ukraine
>
> http://www.FreeBSD.org The Power To Serve
> http://www.oracle.com Enabling The Information Age
>
Comment 3 Ruslan Ermilov 1999-09-14 00:50:25 UTC
On Mon, Sep 13, 1999 at 03:38:54PM -0400, Jay Oliver wrote:
> panic: sbappendaddr
> 
Please recompile your kernel with "options DIAGNOSTIC" and
resend `gdb -k' output with a crash dump from this kernel.


Thanks,
-- 
Ruslan Ermilov		Sysadmin and DBA of the
ru@ucb.crimea.ua	United Commercial Bank,
ru@FreeBSD.org		FreeBSD committer,
+380.652.247.647	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age
Comment 4 ru freebsd_committer freebsd_triage 2000-10-12 17:02:19 UTC
State Changed
From-To: open->closed

Originator reports that the problem went away in the older releases: 

On Thu, Oct 12, 2000 at 11:57:31AM -0400, Jay Oliver wrote: 
> This problem ceased to exist sometime after I updated to the latest release. 
> I honestly can't say at this point which point on stable it went away, but 
> it did so. I'm currently using 4.1.1 without a problem, but I would like to 
> note the problem went away somewhere in the 3-STABLE series. While I'm not 
> an expert by any means, I believe it was an issue caused by the network 
> interface driver. This is also embarassing, but I can't remember which 
> interface it used to be. The cards are and always have been Linksys 
> LNE100TX's and the interface is currently dc0. I can remember that it wasn't 
> dc0 when I reported this problem, and as long as I upped and downed the 
> interfaces on a daily basis, I could have a workaround to the panic. I'm not 
> currently still doing this of course, but I can't pinpoint exactly when I 
> needed to stop. I neved upgraded to 3.5, so it must have been somewhere 
> between 3.3RC and 3.4-STABLE. Sorry I couldn't be more helpful, I was so 
> ecstatic when it finally went away, I guess I became a little lax in trying 
> to discover what had caused it. My aplogies.