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 dyo...@ojctech.com Urbana, IL * (217) 278-3933
