Surprisingly, I managed to compile a kernel way faster than what I
expected.

This didn't help.

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
sched_idle() at sched_idle+0x126
proc_trampoline() at proc_trampoline+0xc
end trace frame: 0x0, count: -12
ddb> show reg
ra                0xffffffc00066c88c    panic+0xfe
sp                0xffffffc0407fda60
gp                                 0
tp                                 0
t0                0x8000000000000009
t1                0xffffffc000449a18    db_format+0x6a
t2                               0x1
s0                0xffffffc0407fda70
s1                               0x1
a0                               0x1
a1                0x242c670fb96e3cfe
a2                0x242c670fb96e3cfe
a3                                 0
a4                0xffffffffffffffff
a5                0xffffffc00066ba54    generic_space_write_4
a6                               0x1
a7                                 0
s2                0xffffffc000879434    substchar+0x222de
s3                                 0
s4                        0xffffc149
s5                                 0
s6                              0x28
s7                0xffffffc000a33a58    cpu_dcache_wbinv_range
s8                               0x1
s9                               0xb
s10                              0x1
s11               0xffffffc000938bd0    ohci_fdt_ca+0x30
t3                               0x3
t4                              0x22
t5                        0xa6016320
t6                        0x7edcc095
panic+0xfe:     addi    a0,zero,256

Also, I'm not sure this is correct. sqh->offs is used exclusively for
usb_syncmem calls, which takes the shared dma.

On Sun, Feb 02, 2025 at 04:38:49PM +0000, Miod Vallat wrote:
> > >Synopsis:  kernel panic: cpu0: _dmamap_sync: ran off map!
> 
> Does this diff help? It looks to me that the offset being already taken
> care of in ehci_alloc_sqh() when computing the physaddr field, it should
> not be applied to the offs field either.
> 
> Index: ehci.c
> ===================================================================
> RCS file: /OpenBSD/src/sys/dev/usb/ehci.c,v
> diff -u -p -r1.222 ehci.c
> --- ehci.c    11 Oct 2024 09:55:24 -0000      1.222
> +++ ehci.c    2 Feb 2025 16:36:40 -0000
> @@ -2268,7 +2268,7 @@ ehci_alloc_sqh(struct ehci_softc *sc)
>                       sqh = KERNADDR(&dma, offs);
>                       sqh->physaddr = DMAADDR(&dma, offs);
>                       sqh->dma = dma;
> -                     sqh->offs = offs;
> +                     sqh->offs = 0;
>                       sqh->next = sc->sc_freeqhs;
>                       sc->sc_freeqhs = sqh;
>               }
> 

Reply via email to