Bug 62053 - Using bridging on 5.2 Sparc64 causes immediate panic
Summary: Using bridging on 5.2 Sparc64 causes immediate panic
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: sparc64 (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-sparc64 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-29 03:10 UTC by Jim Small
Modified: 2005-03-19 15:18 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Small 2004-01-29 03:10:07 UTC
      I am interested in using FreeBSD 5.2 on an Ultra 60 with a PCI qfe card.  I want to use the bridging and dummynet functionality.

I installed FreeBSD 5.2 and added options BRIDGE to a custom kernel conf file and rebuilt/installed the kernel (necessary to use bridging).

I then reboot and do the following:
test60# sysctl -w net.link.ether.bridge.enable=1
net.link.ether.bridge.enable: 0 -> 1
test60# ifconfig hme1 up
test60# ifconfig -a
hme0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.234.208 netmask 0xffffff00 broadcast 192.168.234.255
        inet6 fe80::a00:20ff:fe9a:e692%hme0 prefixlen 64 scopeid 0x1 
        ether 08:00:20:9a:e6:92
        media: Ethernet autoselect (100baseTX)
        status: active
hme1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::a00:20ff:fe9a:e692%hme1 prefixlen 64 scopeid 0x2 
        ether 08:00:20:9a:e6:92
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
(rest cut...)
test60# sysctl -w net.link.ether.bridge.config=hme0,hme1
net.link.ether.bridge.config:  -> hme0,hme1


Consistently within a few seconds I see the following while watching on Serial Port A:
FreeBSD/sparc64 (test60) (ttya)

login: Jan 28 15:28:58 test60 kernel: hme0: promiscuous mode enabled
Jan 28 15:28:58 test60 kernel: hme1: promiscuous mode enabled
panic: trap: memory address not aligned
cpuid = 0; 

syncing disks, buffers remaining... 563 563 563 563 563 563 563 563 563 563 563 563 563 563 563 563 563 563 563 563 
giving up on 455 buffers

Backtrace:
test60# ./gdb53 -k kernel.debug vmcore.0
GNU gdb 5.3 (FreeBSD)
Copyright 2002 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 "sparc64-portbld-freebsd5.2"...
panic: trap: memory address not aligned
panic messages:
---
panic: trap: memory address not aligned
cpuid = 0; 

syncing disks, buffers remaining... 4103 4103 4096 4096 4091 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 4090 
giving up on 3987 buffers
Uptime: 2m23s
Dumping 2048 MB (4 chunks)
  chunk at 0: 536870912 bytes |\^H/\^H
---
#0  0x00000000c0139b08 in doadump () at ../../../kern/kern_shutdown.c:239
239             savectx(&dumppcb);
(kgdb) where
#0  0x00000000c0139b08 in doadump () at ../../../kern/kern_shutdown.c:239
#1  0x00000000c013a124 in boot (howto=256) at ../../../kern/kern_shutdown.c:370
#2  0x00000000c013a54c in panic (fmt=0xc0341790 "trap: %s") at ../../../kern/kern_shutdown.c:548
#3  0x00000000c02939e0 in trap (tf=0xeeb891a0) at ../../../sparc64/sparc64/trap.c:364
#4  0x00000000c01b8c34 in igmp_input (m=0xfffff80000c19bc0, off=0) at ../../../netinet/igmp.c:224
#5  0x00000000c01b8bbc in igmp_input (m=0xc081c500, off=20) at ../../../netinet/igmp.c:202
#6  0x00000000c01c17c0 in ip_input (m=0xc081c500) at ../../../netinet/ip_input.c:983
#7  0x00000000c01aefbc in netisr_processqueue (ni=0xc039b7b0) at ../../../net/netisr.c:152
#8  0x00000000c01af4a0 in swi_net (dummy=0x0) at ../../../net/netisr.c:255
#9  0x00000000c0128a7c in ithread_loop (arg=0xfffff8000082b200) at ../../../kern/kern_intr.c:544
#10 0x00000000c0127a7c in fork_exit (callout=0xc0128900 <ithread_loop>, arg=0xfffff8000082b200, frame=0xeeb89880)
    at ../../../kern/kern_fork.c:793
(kgdb) up 4
#4  0x00000000c01b8c34 in igmp_input (m=0xfffff80000c19bc0, off=0) at ../../../netinet/igmp.c:224
224                     if (igmp->igmp_code == 0) {
(kgdb) p igmp
$1 = (struct igmp *) 0xc01b8c8c
(kgdb) p *igmp
$2 = {igmp_type = 128 '\200', igmp_code = 160 ' ', igmp_cksum = 40960, igmp_group = {s_addr = 38273038}}
(kgdb) p igmp->igmp_code
$3 = 160 ' '
(kgdb)

How-To-Repeat:       Enable bridging in Kernel by adding options BRIDGE to kernel conf and rebuilding.  Reboot.  sysctl -w net.link.ether.bridge.enable=1;  ifconfig hme1 up (2nd NIC up and running);  sysctl -w net.link.ether.bridge.config=hme0,hme1 (bridging between NICs);  Will see panic in a few seconds
Comment 1 tyler 2004-12-18 04:00:29 UTC
I tried this with my Ultra 2 (therefore, two SBus NICs) following this
procedure fine under FreeBSD 6.0-CURRENT (unfortunately only one sparc64
to test on, sorry) and it didn't lock up at all.

Any other way I can try to stress test this?

-R. Tyler Ballance
Comment 2 Marius Strobl freebsd_committer freebsd_triage 2005-02-28 14:03:29 UTC
State Changed
From-To: open->feedback


Jim, this problem was reported to be no longer reproducible by another 
person. Could you please test whether it still persists on your machine 
with a recent version of FreeBSD?
Comment 3 Marius Strobl freebsd_committer freebsd_triage 2005-03-19 15:16:26 UTC
State Changed
From-To: feedback->closed


Close, originator confirms that the problem is gone.