Re: 10_BETA panic on Ultra 1

(Apologies for the encoding mistake in the CC line; I was copying from
https://mail-index.netbsd.org/port-sparc64/2023/08/23/msg003239.html
but I inadequately reverse-engineered the pseudo-rot13 anti-spam
measure in the quoted-printable UTF-8 encoding of the from address.)

> Date: Thu, 24 Aug 2023 20:52:43 +0200
> From: Martin Husemann <[email protected]>
> 
> There is (at least one) frame missing here, ncr53c9x_done calls scsipi_done:
> 
> (gdb) list *(ncr53c9x_done+0x13c)
> 0x107bb3c is in ncr53c9x_done (../../../../dev/ic/ncr53c9x.c:1284).
> 1279            }
> 1280    
> 1281            ncr53c9x_free_ecb(sc, ecb);
> 1282            ti->cmds++;
> 1283            mutex_exit(&sc->sc_lock);
> 1284            scsipi_done(xs);
> 1285            mutex_enter(&sc->sc_lock);
> 1286    }
> 
> The interrupt handler is established with IPL_BIO in esp_sbus.c:505
> 
>         /* Establish interrupt channel */
>         bus_intr_establish(esc->sc_bustag, esc->sc_pri, IPL_BIO,
>             ncr53c9x_intr, sc);
> 
> and while that has not returned, curcpu()->ci_idepth will indicate
> we are in interrupt context.
> 
> But I don't see how we get from scsipi_done to softint_fastintr.

Probably scsipidone -> sddone -> dk_done -> rnd_add_uint32 ->
rnd_add_data -> rnd_add_data_1 -> entropy_enter_intr ->
softint_schedule.

On sparc64, soft interrupts are actually dispatched via lower-priority
hardware interrupts, it seems, and softint_fastintr is the hardware
interrupt handler for that in intr.c, so at _some point_ after
softint_schedule, we should see a call to softint_fastintr
interrupting some other logic.

But how soft interrupts get disaptched before the higher-priority hard
interrupts have returned is unclear.  That looks like the
sparc64-specific bug here.

If something is doing spl0 that would explain it, or if something is
broken in splx or splsoft* or mutex_exit or something that could also
explain it.  But it's weird that it happens only with esp(4) and not
with every disk driver.