> Date: Sun, 2 Feb 2025 09:24:38 +0100 > From: Marcus Glocker <mar...@nazgul.ch> > > On Sat, Feb 01, 2025 at 05:01:58PM GMT, Mark Kettenis wrote: > > > > Date: Sat, 1 Feb 2025 14:56:53 +0000 > > > From: Lucas Gabriel Vuotto <lu...@sexy.is> > > > > > > >Synopsis: kernel panic: cpu0: _dmamap_sync: ran off map! > > > >Category: kernel riscv64 > > > >Environment: > > > System : OpenBSD 7.6 > > > Details : OpenBSD 7.6-current (GENERIC) #140: Fri Jan 31 06:08:51 > > > MST 2025 > > > > > > dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC > > > > > > Architecture: OpenBSD.riscv64 > > > Machine : riscv64 > > > >Description: > > > I run into a kernel panic when booting my board with an usb wifi > > > dongle attached. > > > > > > ddb> show panic > > > *cpu0: _dmamap_sync: ran off map! > > > ddb> bt > > > panic() at panic+0xfe > > > _dmamem_alloc() at _dmamem_alloc > > > ehci_idone() at ehci_idone+0x17e > > > ehci_softintr() at ehci_softintr+0xfe > > > softintr_dispatch() at softintr_dispatch+0x76 > > > riscv_do_pending_intr() at riscv_do_pending_intr+0x94 > > > plic_irq_dispatch() at plic_irq_dispatch+0xde > > > plic_irq_handler() at plic_irq_handler+0x3e > > > riscv_cpu_intr() at riscv_cpu_intr+0x20 > > > cpu_exception_handler_supervisor() at > > > cpu_exception_handler_supervisor+0x7a > > > uvn_io() at uvn_io+0xec > > > uvm_fault_lower_io() at uvm_fault_lower_io+0x178 > > > uvm_fault_lower() at uvm_fault_lower+0xbe > > > uvm_fault() at uvm_fault+0xfc > > > do_trap_user() at do_trap_user+0x112 > > > cpu_exception_handler_user() at cpu_exception_handler_user+0x7c > > > end of kernel > > > end trace frame: 0x4b8828e0, count: -16 > > > > This basically means the bus_dmamap_sync() call (called from > > usb_dmasync()) in ehci_idone() is syncing more memory than was mapped > > using bus_dmamap_load(). Could be a bug in ehci(4) or the usb wifi > > driver. > > I can't reproduce the issue on a amd64 ehci machine with urtwn attached > during boot. Maybe something specific to riscv64 which triggers this?
Since amd64 is (mostly) cache-coherent, bus_dmamap_sync(9) is a no-op (unless you're using bounce-buffers for SEV) so it doesn't have this check. We have these checks on armv7 and arm64 too (but on arm64 it will be bypassed if DMA is cache-coherent). It would be interesting to see if the same thing happens on a board with an Allwinner SoC with ARM cores.
