Re: 5.99.30 sparc panic during startup

[David Young <dyoung%pobox.com@localhost>]

On Sat, Jun 19, 2010 at 06:36:57PM +0200, Hauke Fath wrote:
> Hi,
> 
> Matthew Green sent me here with a -current issue on sparc which appears to
> be something else than the ususal post-netbsd-4 SMP issues on the platform.
> The full boot log is here
> <http://la.causeuse.org/hauke/NetBSD/sparc-smp/PIZZA_UP_PF.5_99_30>, the
> corresponding kernel configs are here
> <http://la.causeuse.org/hauke/NetBSD/sparc-smp/PIZZA_UP_PF> and here
> <http://la.causeuse.org/hauke/NetBSD/sparc-smp/PIZZA>.
> 
> The panic bit is
> 
> <snip>
> [...]
> Setting tty flags.
> pfctl: DIOCADDRULE: Operation not supported by device
> Setting sysctl variables:
> net.inet.tcp.rfc1323: 1 -> 0
> net.inet.tcp.mss_ifmtu: 0 -> 1
> net.inet.ip.forwarding: 1 -> 1
> net.inet.ip.redirect: 1 -> 0
> net.inet.ip.do_loopback_cksum: 0 -> 1
> net.inet.tcp.do_loopback_cksum: 0 -> 1
> net.inet.udp.do_loopback_cksum: 0 -> 1
> kern.logsigexit: 1 -> 1
> kern.maxproc: 1044 -> 4096
> Starting network.
> Hostname: pizza.causeuse.org
> NIS domainname: Forstquelle
> Configuring network interfaces: hmeMutex error: lockdebug_wantlock: locking
> against myself
> 
> lock address : 0x00000000f036b8c8 type     :               spin
> initialized  : 0x00000000f01da1a0
> shared holds :                  0 exclusive:                  1
> shares wanted:                  0 exclusive:                  1
> current cpu  :                  0 last held:                  0
> current lwp  : 0x00000000f36142c0 last held: 0x00000000f36142c0
> last locked  : 0x00000000f01d7464 unlocked : 0x00000000f01d7ff4
> owner field  : 0x000000000007ff00 wait/spin:                0/1
> 
> panic: LOCKDEBUG
> Stopped in pid 177.1 (sh) at    netbsd:cpu_Debugger+0x4: or %o7, %g0, %g1
> db> t
> cpu_Debugger(0xf0309988, 0x0, 0xf02d5fc8, 0xf0338c00, 0xf0388000, 0x104) at
> netbsd:lockdebug_abort1+0xa4
> lockdebug_abort1(0xf36b5908, 0xf00, 0xf02d5fc8, 0xf02f0028, 0x1, 0x1) at
> netbsd:mutex_enter+0x280
> mutex_enter(0xf036b8c8, 0x0, 0xf036b8c8, 0xf36142c0, 0xf0002000, 0x1) at
> netbsd:config_alldevs_lock+0xc
> 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
> netbsd:lockdebug_unlocked
> lockdebug_unlocked(0xf036b8c8, 0xf0307e78, 0xf036b8c8, 0xf0307f80,
> 0xf416c7f4, 0x1) at netbsd:device_lookup+0x98
> device_lookup(0xf4167270, 0x0, 0x1, 0xf36142c0, 0x0, 0x1) at
> netbsd:device_lookup_private+0x8
> device_lookup_private(0xf033607c, 0x0, 0x0, 0xf36142c0, 0xf0002000, 0x1) at
> netbsd:sdstrategy+0x24
> sdstrategy(0xf0d91f00, 0x700, 0x0, 0x0, 0x0, 0xf416c660) at
> netbsd:bdev_strategy+0x20

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.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933