On 6 Jun 2025, at 15:57, Mark Johnston wrote:
The branch main has been updated by markj:
URL:
https://cgit.FreeBSD.org/src/commit/?id=ded037e65e5239671b1292ec987a2e0894b217b5
commit ded037e65e5239671b1292ec987a2e0894b217b5
Author: Hareshx Sankar Raj <hareshx.sankar....@intel.com>
AuthorDate: 2025-05-07 09:38:21 +0000
Commit: Mark Johnston <ma...@freebsd.org>
CommitDate: 2025-06-06 13:43:54 +0000
qat: driver updates to improve code and fix bugs
Bug fixes and improvements are done for the qat code base
to improve code quality.
Reviewed by: markj, ziaee
MFC after: 2 weeks
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D50379
---
…
diff --git a/sys/dev/qat/qat_hw/qat_c3xxx/adf_c3xxx_hw_data.h
b/sys/dev/qat/qat_hw/qat_c3xxx/adf_c3xxx_hw_data.h
index bfc5db1f5e5c..cddfc3f84853 100644
--- a/sys/dev/qat/qat_hw/qat_c3xxx/adf_c3xxx_hw_data.h
+++ b/sys/dev/qat/qat_hw/qat_c3xxx/adf_c3xxx_hw_data.h
@@ -1,11 +1,11 @@
/* SPDX-License-Identifier: BSD-3-Clause */
-/* Copyright(c) 2007-2022 Intel Corporation */
+/* Copyright(c) 2007-2025 Intel Corporation */
#ifndef ADF_C3XXX_HW_DATA_H_
#define ADF_C3XXX_HW_DATA_H_
/* PCIe configuration space */
-#define ADF_C3XXX_PMISC_BAR 0
-#define ADF_C3XXX_ETR_BAR 1
+#define ADF_C3XXX_PMISC_BAR 1
+#define ADF_C3XXX_ETR_BAR 2
#define ADF_C3XXX_RX_RINGS_OFFSET 8
#define ADF_C3XXX_TX_RINGS_MASK 0xFF
#define ADF_C3XXX_MAX_ACCELERATORS 3
We’re seeing panics loading the QAT driver on Atom Processor C3000
(with pfSense).
I believe this change is the trigger.
This causes us to look for the ETR registers in the third BAR, but there
are only two on that hardware:
# pciconf -l -b -vV pci0:1:0:0
none0@pci0:1:0:0: class=0x0b4000 rev=0x11 hdr=0x00 vendor=0x8086
device=0x19e2 subvendor=0x8086 subdevice=0x19e2
vendor = 'Intel Corporation'
device = 'Atom Processor C3000 Series QuickAssist Technology'
class = processor
bar [18] = type Memory, range 64, base 0x80700000, size 262144,
enabled
bar [20] = type Memory, range 64, base 0x80740000, size 262144,
enabled
That produces this backtrace:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 18
fault virtual address = 0x10
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff83c4c25a
stack pointer = 0x28:0xfffffe00681c26b0
frame pointer = 0x28:0xfffffe00681c26b0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 3075 (kldload)
rdi: 0000000000000000 rsi: 0000000000000000 rdx: 0000000000000000
rcx: 0000000000000000 r8: fffffe00681c2715 r9: 000000000000000a
rax: 00000000000001ff rbx: 0000000000000000 rbp: fffffe00681c26b0
r10: 0000000000000000 r11: 0000000000000001 r12: 0000000000000000
r13: fffff80003a1a000 r14: 0000000000000000 r15: 0000000000000008
trap number = 12
panic: page fault
cpuid = 1
time = 1753859856
KDB: enter: panic
[ thread pid 3075 tid 100160 ]
Stopped at kdb_enter+0x33: movq $0,0x1b55532(%rip)
db> bt
Tracing pid 3075 tid 100160 td 0xfffff80100d4a780
kdb_enter() at kdb_enter+0x33/frame 0xfffffe00681c2530
panic() at panic+0x43/frame 0xfffffe00681c2590
trap_pfault() at trap_pfault+0x3c9/frame 0xfffffe00681c25e0
calltrap() at calltrap+0x8/frame 0xfffffe00681c25e0
--- trap 0xc, rip = 0xffffffff83c4c25a, rsp = 0xfffffe00681c26b0, rbp =
0xfffffe00681c26b0 ---
write_csr_ring_config() at write_csr_ring_config+0xa/frame
0xfffffe00681c26b0
adf_init_etr_data() at adf_init_etr_data+0x36a/frame 0xfffffe00681c2840
adf_dev_init() at adf_dev_init+0xc1/frame 0xfffffe00681c28f0
adf_attach() at adf_attach+0x4e1/frame 0xfffffe00681c2950
device_attach() at device_attach+0x43d/frame 0xfffffe00681c29a0
pci_driver_added() at pci_driver_added+0xf2/frame 0xfffffe00681c29e0
devclass_driver_added() at devclass_driver_added+0x29/frame
0xfffffe00681c2a10
devclass_add_driver() at devclass_add_driver+0x11e/frame
0xfffffe00681c2a50
module_register_init() at module_register_init+0x85/frame
0xfffffe00681c2a80
linker_load_module() at linker_load_module+0xc0f/frame
0xfffffe00681c2d80
kern_kldload() at kern_kldload+0x165/frame 0xfffffe00681c2dd0
sys_kldload() at sys_kldload+0x59/frame 0xfffffe00681c2e00
amd64_syscall() at amd64_syscall+0x126/frame 0xfffffe00681c2f30
fast_syscall_common() at fast_syscall_common+0xf8/frame
0xfffffe00681c2f30
--More--
Because we’ve tried to use a pci_bars[2] entry with virt_addr == 0
(because it’s outside of the BARs we set up).
Reverting just the above hunk of the patch fixes the panic for us.
Best regards,
Kristof
