re: altqd and kernel panic

[matthew green <mrg%eterna.com.au@localhost>]

BERTRAND Jo?l writes:
> 	Hello,
> 
> 	I have seens some panics on recent kernel when I try to use altqd with 
> openvpn.
> 
> 	Network configuration :
> gem0 : WAN interface
> tap0 : VPN on gem0 (mainly used for VoIP)
> hme[0123] : LAN's
> 
> 	When tap0 is coming up, openvpn configuration file calls following script :
> 
> #!/bin/sh
> /sbin/route add -net 192.168.0.0/24 192.168.1.1
> /sbin/route add -host gwvoip.ext.nerim.net 192.168.1.1
> /sbin/route add -net 79.170.216.0/28 192.168.1.1
> /etc/rc.d/altqd onestart
> exit 0
> 
> 	It works without any trouble. When tap0 is deconfigured by openvpn, it 
> calls :
> 
> #!/bin/sh
> /sbin/route delete 192.168.0.0/24
> /sbin/route delete gwvoip.ext.nerim.net
> /sbin/route delete 79.170.216.0/28
> /etc/rc.d/altqd onestop
> exit 0
> 
> and system randomly panics as altqd stop tries to deconfigure QoS on a 
> non existant network interface (tap0).
> 
> 	My /etc/altqd.conf file :
> interface gem0 bandwidth 10M priq
> 
> class priq gem0 high_class NULL priority 1
> class priq gem0 low_class NULL priority 0 default
> 
> filter gem0 high_class 0 1194 0 0 17
> filter gem0 high_class 0 0 0 1194 17
> 
> interface tap0 bandwidth 10M priq
> 
> class priq tap0 high_class NULL priority 1
> class priq tap0 low_class NULL priority 0 default
> 
> filter tap0 high_class 0 0 0 0 17
> 
> 	I don't know if this issue is sparc64 specific or not. I have find some 
> very old PR.

this sounds like a generic bug in altq or perhaps a bug in
the gem(4) or tap(4) drivers, i recommend re-posting this
to tech-net and tech-kern.

but without a stack trace it's hard to tell -- do you have
one?


.mrg.