Re: 6.0BETA3 panic in ip_output (vlan/RIP related?)

On Wed, 2005-08-31 at 17:49 +0400, Yar Tikhiy wrote:
> On Wed, Aug 31, 2005 at 12:24:45PM +0100, Gavin Atkinson wrote:
> > 
> > I've just managed to panic an amd64 machine running 6.0BETA3.
> > 
> > wiggum# ifconfig vlan76 destroy
> > wiggum# Aug 31 12:02:48 wiggum routed[244]: IP_DROP_MEMBERSHIP ALLHOSTS: Can't assign requested address
> > wiggum#
> > wiggum# ifconfig vlan76 create
> > wiggum# ifconfig vlan76 vlan 76 vlandev bge0
> > wiggum# ifconfig vlan76 inet x.y.76.59 netmask 255.255.254.0
> > 
> > 
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 0; apic id = 00
> > instruction pointer     = 0x8:0xffffffff80429420
> > stack pointer           = 0x10:0xffffffffb260b600
> > frame pointer           = 0x10:0xffffffffb260b710
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                         = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 244 (routed)
> 
> Thanks for reporting this!  The problem seems known and has
> to do with a deficiency in our multicast code WRT interface
> removal/re-insertion.  It is on the to-do list of our networking
> gurus and hopefully will be dealt with RSN, after IP multicast
> code locking and cleanup are complete.

It's good to hear that the problem is understood, however it seems that
this panic is trivial to recreate for anyone running routed, and
therefore 6.0-RELEASE may well be unusable for me.  I've just got this
second panic from the same machine which looks like it may also be
related to the multicast code.

wiggum# reboot
Sep  1 18:05:05
wiggum reboot: r
Faooted by root
Sep  1 18:05:05 wiggum syslogd: exiting on signal 15
tal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer     = 0x8:0xffffffff80429420
stack pointer           = 0x10:0xffffffffb49c4590
frame pointer           = 0x10:0xffffffffb49c46a0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 244 (routed)
[thread pid 244 tid 100101 ]
Stopped at      strlen: cmpb    $0,0(%rdi)
db> tr
Tracing pid 244 tid 100101 td 0xffffff0061d1b980
strlen() at strlen
vsnprintf() at vsnprintf+0x2e
panic() at panic+0x14b
_mtx_lock_flags() at _mtx_lock_flags+0xd6
if_delmulti() at if_delmulti+0x3f
in_delmulti() at in_delmulti+0x4b
ip_freemoptions() at ip_freemoptions+0x30
in_pcbdetach() at in_pcbdetach+0x182
udp_detach() at udp_detach+0x51
soclose() at soclose+0x1a0
soo_close() at soo_close+0x3f
fdrop_locked() at fdrop_locked+0xa1
closef() at closef+0x31
fdfree() at fdfree+0x48a
exit1() at exit1+0x302
sys_exit() at sys_exit+0xe
syscall() at syscall+0x4b2
Xfast_syscall() at Xfast_syscall+0xa8

Given I've accidentally been able to panic this machine twice in two
days, is there any chance a fix or at least a band-aid will be in place
before the release?

Thanks,

Gavin