ipfw kernel panic solution

Y

Yelphos

I don't know if it's Ryzen which is causing this and if it's the Ryzen-bug or if it is something else.

Commands like this are causing kernel-panics:
Code: 
ipfw table test create type number algo number:array
ipfw table test add 1001
ipfw table test add 1002
ipfw table test add 1003
ipfw table test add 1005
ipfw table test add 1007
ipfw table test add 1008
ipfw table test add 1009
ipfw table test add 1010
ipfw table test add 1011
ipfw table test add 1012
ipfw table test add 1013

ipfw add 0 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state lookup uid test
this also causes kernel-panic:
Code: 
ipfw add 0 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1001 uid 1002 uid 1003 uid 1005 uid 1007 uid 1008 uid 1009 uid 1010 uid 1011 uid 1012 uid 1013
this causes no kernel-panic:
Code: 
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1001
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1002
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1003
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1005
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1007
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1008
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1009
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1010
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1011
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1012
ipfw add 3 deny src-ip any dst-ip 0.0.0.0 dst-port 0 keep-state uid 1013
Adjusting hardware-settings(memory-frequency, CPU-frequency, disabling cores, disabling smt) down to lowest settings within bios stops the kernel from panicing if you need to reconfigure your firewall, this indicates something I previously recognized. The hardware is mainly causing this but there seems also something wrong with software if weak changes like this are causing kernel-panics.

According to another bug-report some people said it's a software-problem but that's wrong. I repeatedly said the motherboard is causing this but this got ignored and they did some changes to software and implemented this into FreeBSD. It's stopping the system from crashing but also removes functionality. At least this issue makes me absolutely sure it's not only the software causing this and if some user experiences this kind of bug this is the workaround. Don't use lookup-tables and don't place commands like within the second example.
 
Generally you'll get better response for these kind of issues on the mailing list.

It's hard to say anything to this issue as you didn't mention the FreeBSD version and the panic string/backtrace to indicate what/where happened.
 
You must log in or register to reply here.
Back
Top