nc of 0's from one rge to another at full speed crashes
in the input interrupt path with corruption of the memory
pool used for the mbufs
It's 100% reproduceable.
Probably race condition & use-after-free or some such
since it takes 200,000+ packets to happen.
I suspect that the crash happens when the corruption is detected
some time after it actually occurs.
This is a ---very--- abbreviated description.
If this crash hasn't been seen before I'll submit a full bug report.
Is there any more info from sysctls, ddb, etc. that would help?
I can put in breakpoints & dump (small) memory areas.
If running the most recent snapshot would give better info I can do that.
A serial console to get an exact transcript is possible but not easy.
Any suggestions of something I can do to help beyond a standard bug
report welcomed. I can run test patches easily.
This is with the standard 1500 mtu.
Setting mtu to 8000 trashes memory enough to cause a kernel protection
fault.
OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 67997949952 (64847MB)
avail mem = 65919754240 (62865MB)
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xe6cc0 (33 entries)
bios0: vendor American Megatrends International, LLC. version "P2.10"
date 08/02/2021
bios0: ASRock B550 Phantom Gaming 4
...
cpu0: AMD Ryzen 5 5600G with Radeon Graphics, 3892.77 MHz, 19-50-00
...
rge0 at pci3 dev 0 function 0 "Realtek RTL8125" rev 0x00: msi, address
78:2d:7e:12:5a:d6
panic hand copied:
sched_idle
apicpu_idle
Xintr_ioapic_edge22_???
intr_handler
rge_intr
rge_rxeof
rge_newbuf
mclget(0, 2, 2400)
pool_get
pool_cache_get
panic: pool cache item mcl9k cp freelist modified
(panic on test 1)
fffffd800b076880 + 16 0x64000403b8f3400 != 0x46b8689556980a7
(panic on test 2 - all previous data identical)
fffffd800b118d40 + 16 0x64000409da03400 != 0x5be8fd0cf17429b
thanks for any input,
Geoff Steckel
