I don't know if its ryzen which is causing this and if its the ryzen-bug or if it is something else. Commands like this are causing kernel-panics: 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: 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: 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, this indicates something i previously recognised. The hardware is causing this but there is also something wrong with software if weak changes like this are causing kernel-panics. Please don't mark this as duplicate until its clear whats causing it. According to another bug-report some people sayed its a software-problem but thats wrong, i repeadetly sayed the motherboard is causing this but this got ignored and they did some changes to software. It's stoping the system from crashing but also removes functionality. At least this makes me absolutely sure its not the software causing this and if some user experience this kind of bug this is the workaround.
For the HW component of this: Please try running the kill-ryzen script, with all hardware settings at defaults, to see if you have a faulty processor.[0] [0]: https://github.com/cemeyer/ryzen-test I'd suggest running it overnight (i.e., for 8+ hrs). It will consume all CPU so you won't be able to use the machine for much else at the same time. If you find it reports failures, please RMA your processor to AMD and we can resolve this Not a Bug.
Since reconfiguring my firewall with this knowledge iam experiencing no kernel-panics anymore. My computer is completely stable.
So should this PR be closed?
No confirmation this bug has been resolved from developers, its just a workaround.
I've also seen this behavior on an early production ryzen 1700 with FreeBSD 11.4. Switching the CPU out to a 2700 resolves the issue. ipfw definitely triggers the bug in 11.x. I could get FreeBSD 10.x to work fine on it.
Unless we have a clue, that kind of compiled machine code will trigger the bug in the CPU, this ticket will be stalled. It's hard for anyone else to reproduce the bug, so even trial and error modifications to the code or to the compiler settings are impossible. Please provide some way out of this situation or close the ticket.