Re: altqd

[christos%astron.com@localhost (Christos Zoulas)]

In article <5613A168.9030200%systella.fr@localhost>,
BERTRAND Joël  <joel.bertrand%systella.fr@localhost> wrote:
>	Hello,
>
>	I believe I have found why my Blade2000 crashes (deadlocks, panics or 
>some other bugs that trigger kernel debugger like alignment error). I 
>have seen that all crashes occurs after a 'tap0 detached' message. I 
>have modified openvpn configuration and I have seen that if I remove 
>altqd from this configuration, system seems to be stable.
>
>	I haven't filled a PR, as I cannot obtain usable information to debug. 
>I haven't found any related PR on altqd. I'm not sure that this bug is 
>triggered by /etc/rc.d/altqd onestop I have written in openvpn 
>configuration or by altqd itself as tap0 was dropped by openvpn and used 
>in /etc/altq.conf. I don't think if this bug is sparc64 specific.
>
>	My altq configuration is very simple:
>
>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 2M priq
>
>class priq tap0 high_class_vpn NULL priority 1
>class priq tap0 low_class_vpn NULL priority 0 default
>
>filter tap0 high_class_vpn 192.168.10.250 0 0 0 17
>filter tap0 high_class_vpn 0 0 192.168.10.250 0 17
>
>interface hme0 bandwidth 100M priq
>
>class priq hme0 high_class_lan NULL priority 1
>class priq hme0 low_class_lan NULL priority 0 default
>
>filter hme0 high_class_lan 192.168.10.250 0 0 0 17
>filter hme0 high_class_lan 0 0 192.168.10.250 0 17

Do you have a backtrace?

christos