Re: 5.99.30 sparc panic during startup

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

David Young <dyoung%pobox.com@localhost> wrote:
> > <...>
> > config_alldevs_lock(0x0, 0x700, 0x0, 0x0, 0x0, 0xf416c660) at
> > netbsd:device_lookup+0x4
> > device_lookup(0xf0335ebc, 0x0, 0x37f, 0xf0307208, 0x0, 0x0) at
> > netbsd:device_lookup_private+0x8
> > device_lookup_private(0xf0335ebc, 0x0, 0x0, 0xf0307000, 0xffffffff,
> > 0xf416c478) at netbsd:zshard+0x28
> > zshard(0x0, 0xf028fc0c, 0xf00, 0x408000e3, 0xf0002000, 0x0) at
> > netbsd:sparc_interrupt44c+0x1a4
> > sparc_interrupt44c(0xf036b8c8, 0xf01d803c, 0x0, 0x0, 0xf036b8c8, 0x0) at
> > <...>
> 
> Supposing the lock involved (0x00000000f036b8c8) is alldevs_mtx (is
> it?), and the lower device_lookup() on the call stack holds it, then
> interrupt priorities IPL_VM and lower should be blocked, and zshard()
> should not appear where it does on that call stack.

Seems the case where device_lookup_private() is called from interrupt
context running at IPL_HIGH.

-- 
Mindaugas