Bug 228332

Summary: ipfw crashes with lookup tables or similiar configurations on ryzen
Product: Base System Reporter: SF <shitman71>
Component: miscAssignee: Mark Linimon <linimon>
Status: New ---    
Severity: Affects Some People CC: cem
Priority: ---    
Version: 11.1-RELEASE   
Hardware: amd64   
OS: Any   

Description SF 2018-05-18 13:25:31 UTC
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.
Comment 1 Conrad Meyer freebsd_committer 2018-05-18 16:55:53 UTC
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.
Comment 2 SF 2018-05-22 21:31:30 UTC
Since reconfiguring my firewall with this knowledge iam experiencing no kernel-panics anymore. My computer is completely stable.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2018-08-12 14:15:50 UTC
So should this PR be closed?
Comment 4 SF 2018-08-14 11:25:32 UTC
No confirmation this bug has been resolved from developers, its just a workaround.