Discussion:
altqd
(too old to reply)
BERTRAND Joël
2015-10-06 10:24:40 UTC
Permalink
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

Regards,

JB

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Christos Zoulas
2015-10-06 17:39:47 UTC
Permalink
Post by BERTRAND Joël
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.
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...