daily CVS update output
Updating src tree: P src/external/mit/xorg/bin/xtrap/Makefile.xtrap P src/external/mit/xorg/lib/libXaw/Makefile P src/external/mit/xorg/lib/libXaw6/Makefile P src/sys/arch/arm/arm/arm_machdep.c P src/sys/arch/arm/fdt/files.fdt P src/sys/arch/arm/fdt/pcihost_fdt.c P src/sys/arch/arm/nvidia/tegra_pcie.c P src/sys/arch/arm/sunxi/sunxi_intc.c P src/sys/arch/arm/sunxi/sunxi_nmi.c P src/sys/arch/hppa/include/mutex.h P src/sys/arch/sh3/include/userret.h P src/sys/arch/x86/x86/pmap.c P src/sys/arch/xen/x86/xen_pmap.c P src/sys/compat/netbsd32/netbsd32_vm.c P src/sys/dev/ic/mfi.c P src/sys/dev/raidframe/rf_compat32.c P src/sys/dev/usb/if_aue.c P src/sys/dev/usb/if_axe.c P src/sys/dev/usb/if_axen.c P src/sys/dev/usb/if_cdce.c P src/sys/dev/usb/if_cue.c P src/sys/dev/usb/if_kue.c P src/sys/dev/usb/if_mos.c P src/sys/dev/usb/if_mue.c P src/sys/dev/usb/if_smsc.c P src/sys/dev/usb/if_udav.c P src/sys/dev/usb/if_upl.c P src/sys/dev/usb/if_ure.c P src/sys/dev/usb/if_url.c P src/sys/dev/usb/if_urndis.c P src/sys/dev/usb/u3g.c P src/sys/dev/usb/uark.c P src/sys/dev/usb/ubsa.c P src/sys/dev/usb/uchcom.c P src/sys/dev/usb/uftdi.c P src/sys/dev/usb/uhub.c P src/sys/dev/usb/uipad.c P src/sys/dev/usb/uipaq.c P src/sys/dev/usb/ukyopon.c P src/sys/dev/usb/umcs.c P src/sys/dev/usb/umct.c P src/sys/dev/usb/umodem.c P src/sys/dev/usb/uplcom.c P src/sys/dev/usb/usbnet.h P src/sys/dev/usb/uvisor.c P src/sys/external/bsd/drm2/dist/drm/radeon/radeon_atombios_dp.c P src/sys/kern/kern_mutex.c P src/sys/kern/tty.c P src/sys/netsmb/smb_smb.c P src/usr.bin/make/util.c P src/usr.bin/make/unit-tests/escape.mk P src/usr.bin/make/unit-tests/modorder.mk Updating xsrc tree: Killing core files: Updating release-7 src tree (netbsd-7): Updating release-7 xsrc tree (netbsd-7): Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.2 P sys/kern/kern_ksyms.c Updating release-8 xsrc tree (netbsd-8): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 35392280 Jan 8 03:11 ls-lRA.gz
Re: panic on zpool create
hello David. I wonder if you're running into another manifestation of kern/54724, which shows zfs corrupting kernel memory in NetBSD-9. I show the problem having to do with xen, but I now believe the problem is entirely with zfs and it was only coincidental that I ran into it with xen. I left the machine in question, running zfs, for a month, doing pretty much nothing, but when I came back to it, I got weird messages like, proc table is full. There were a lot of process running, but I couldn't determine which one was the one that was "really" stuck, since the number of commands I could run was extremely limited. -thanks -Brian On Jan 8, 1:07am, David Brownlee wrote: } Subject: Re: panic on zpool create } On Tue, 7 Jan 2020 at 12:48, David Brownlee wrote: } > } > On Tue, 7 Jan 2020 at 10:07, J. Hannken-Illjes wrote: } > > } > > For some reason locking the directory we want to mount on crashes. } > > } > > Anything special with the root on this machine? } > > } > > Does the directory (/angus_media I suppose) exist? } > } > /angus_media was present after the initial panic, removing it did not } > seem to help. } > } > Ran a fsck -fyP on the system which picked up some issues, rebooted } > and then tried again but the system still panics on zpool import (I'd } > sent a follow up email noting that it appears the create is working } > fine but the import panics, based on being able to create the pool on } > another box running the same OS, but that pool then panics on import } > on this box). } > } > The system is a Dell T320 with three filesystem on an LSI mfii0 } > controller, but I'm testing ZFS as the only two disk on the onboard } > AHCI } > } > I'm going to try a current kernel in a bit (its a server and gateway } > box so I'm trying to minimise downtime :) } } O-Kaayyy... I have another data point. } } The panic does not occur in single user, but does when the system is running. } } Given this box takes approximately four minutes to complete POST to } the point it actually starts to boot anything, and has the primary } copy of quite a lot of data I value, my testing tomorrow is likely to } be a little painful... } } Will update when I know more :) } } David >-- End of excerpt from David Brownlee
Failure with ``build.sh -V USE_PIGZGZIP=yes install-image''
On Mon, 6 Jan 2020, Paul Goyette wrote: Failure to build install-image - sources current as of 2020-01-06 at 13:03:23 UTC Creating rootfs... chmod +r work/var/spool/ftp/hidden /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 1519386624 -m 1519386624 -B 1234 -F work.spec -N work/etc -o bsize=16384,fsize=2048,density=8192 work.rootfs work nbmakefs: `work' size of 1994735616 is larger than the maxsize of 1519386624. *** Failed target: imgroot.fs This seems to be a repeatable failure. Running without specifying USE_PIGZGZIP works correctly. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: "route_enqueue: queue full, dropped message" blast from a 8.99.32 amd64 domU
At Fri, 10 May 2019 13:02:05 -0700, "Greg A. Woods" wrote: Subject: Re: "route_enqueue: queue full, dropped message" blast from a 8.99.32 amd64 domU > > During normal operation I see just over 8000/s (and with the console > spewing there are only about 200/s more), and it all seems to add up > since this is an 8-vcpu domU, and I have HZ=1000. Before I rebooted I > was seeing numbers ranging up to 25000/s. So this happened again today. However I didn't manage to run "systat vm" and see if there was an interrupt storm again, and if so what device it was from. But neither did I have to reboot. It lasted long enough and strong enough to kill all my X11 connections, though by the time emacs was dumping core (as it always does when it loses touch with the X11 server), NFS was running well enough to store the core files. I was in the midst of trying to login on the console to investigate further when things seemed to have returned to normal. The console isn't fully usable though -- I see output sent to it, but I can't seem to send anything to the getty running on it. I'm not yet sure if this is a conserver, xen, or NetBSD problem. This time there were occasional "xennet0: xennet_watchdog" messages too. There's one other possibly related symptom -- sometimes X11 clients running on this host seem to have trouble painting characters, particularly "links" (but it has no trouble displaying images or scrolling images). Unfortunately I have not thought to check for a slightly less voracious interrupt storm while this symptom is present, but hopefully I will remember to do so next time it appears. Until now I've thought this might be some kind of problem with volumes of network traffic interfering with the font server, though I've not observed any truly excessive network traffic. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpewpFianOts.pgp Description: OpenPGP Digital Signature
Re: panic on zpool create
On Tue, 7 Jan 2020 at 12:48, David Brownlee wrote: > > On Tue, 7 Jan 2020 at 10:07, J. Hannken-Illjes > wrote: > > > > For some reason locking the directory we want to mount on crashes. > > > > Anything special with the root on this machine? > > > > Does the directory (/angus_media I suppose) exist? > > /angus_media was present after the initial panic, removing it did not > seem to help. > > Ran a fsck -fyP on the system which picked up some issues, rebooted > and then tried again but the system still panics on zpool import (I'd > sent a follow up email noting that it appears the create is working > fine but the import panics, based on being able to create the pool on > another box running the same OS, but that pool then panics on import > on this box). > > The system is a Dell T320 with three filesystem on an LSI mfii0 > controller, but I'm testing ZFS as the only two disk on the onboard > AHCI > > I'm going to try a current kernel in a bit (its a server and gateway > box so I'm trying to minimise downtime :) O-Kaayyy... I have another data point. The panic does not occur in single user, but does when the system is running. Given this box takes approximately four minutes to complete POST to the point it actually starts to boot anything, and has the primary copy of quite a lot of data I value, my testing tomorrow is likely to be a little painful... Will update when I know more :) David
Re: pmap lock changes: Xen panic
Manuel, On Tue, Jan 07, 2020 at 10:39:33AM +0100, Manuel Bouyer wrote: > Hello, > with 2020-01-05 00:40 UTC sources, Xen domUs panics because of what looks like > locking changes in the pmap code (full log at > http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/): > mlock error: Mutex: mutex_vector_enter,506: assertion failed: !cpu_intr_p(): > lock 0xc0b46300 cpu 0 lwp 0xc1aac100 > [ 39.3701414] cpu0: Begin traceback... > [ 39.3701414] > vpanic(c05b72e8,d7c7c728,d7c7c744,c041c699,c05b72e8,c05b04e0,c05746b4,1fa,c05b0454,c0b46300) > at netbsd:vpanic+0x134 > [ 39.3701414] > panic(c05b72e8,c05b04e0,c05746b4,1fa,c05b0454,c0b46300,0,c1aac100,d7c7c768,c03d2ec9) > at netbsd:panic+0x18 > [ 39.3701414] > lockdebug_abort(c05746b4,1fa,c0b46300,c0b414c8,c05b0454,c0b46240,c0b46300,d7c7c794,c03d3405,c05b0454) > at netbsd:lockdebug_abort+0xc9 > [ 39.3701414] > mutex_abort(c05b0454,0,d39e7004,79339,c0b37340,c1aac100,c0b46240,c0b46300,c1a5e1e8,d7c7c7dc) > at netbsd:mutex_abort+0x39 > [ 39.3701414] > mutex_vector_enter(c0b46300,d7c7c7b8,d7c7c7b4,c03cc135,86908857,d7c7a024,c0b37340,c1aac100,d7c7c7d4,c011924f) > at netbsd:mutex_vector_enter+0x355 > [ 39.3701414] > pmap_extract_ma(c0b46240,d6db3000,d7c7c820,0,c1733508,6,d7e7e000,c1a5e1e0,6,c1a5e008) > at netbsd:pmap_extract_ma+0x1a > [ 39.3701414] > xbd_diskstart(c189e908,c2672e2c,1c0,d7c7c884,c011d25e,c0b35880,c1a5e018,32b0,c1a5e008,) > at netbsd:xbd_diskstart+0x234 > [ 39.3701414] > dk_start(c1a5e008,0,c23fc4dc,23f1000,0,1,c2670558,c1a5e1e0,6,d7e7e000) at > netbsd:dk_start+0xea > [ 39.3701414] > xbd_handler(c1a5e008,6,d7c7c978,c18a6318,d7c7c924,c011cc99,c18a6318,d7c7c978,d7c7ca3c,c04a1a7d) > at netbsd:xbd_handler+0x12e > [ 39.3701414] > xen_intr_biglock_wrapper(c18a6318,d7c7c978,d7c7ca3c,c04a1a7d,c1cba008,23f,0,d7c7c9ec,d7c7ca10,c0c589b8) > at netbsd:xen_intr_biglock_wrapper+0x1f > [ 39.3701414] > evtchn_do_event(6,d7c7c978,c0e670fc,c0e62548,c0e68494,0,c0b37340,c0d9a000,c0b37340,0) > at netbsd:evtchn_do_event+0xf9 > [ 39.3701414] > do_hypervisor_callback(d7c7c978,0,11,31,11,c0b40011,0,0,d7c7ca44,bfec0d70) at > netbsd:do_hypervisor_callback+0x15f > [ 39.3701414] > Xhypervisor_pvhvm_callback(c0b46240,d81ae000,696f3000,1,1ef3000,0,1,21,7ff0,21) > at netbsd:Xhypervisor_pvhvm_callback+0x67 > > > In rev 1.35 of xen/x86/xen_pmap.c the pmap lock is taken unconditionally, > even in the pmap_kernel() case, which means pmap_extract_ma() can't be > used from interrrupt context any more. I don't think we can impose such > restrictions on pmap_kernel(); bus_dma(9) needs it. This was a mistake on my part. We should never need to lock pmap_kernel() for pmap_extract() since it only touches the PTEs. It should be fixed now with xen_pmap.c 1.37. Cheers, Andrew
Re: panic on zpool create
On Tue, 7 Jan 2020 at 10:07, J. Hannken-Illjes wrote: > > For some reason locking the directory we want to mount on crashes. > > Anything special with the root on this machine? > > Does the directory (/angus_media I suppose) exist? /angus_media was present after the initial panic, removing it did not seem to help. Ran a fsck -fyP on the system which picked up some issues, rebooted and then tried again but the system still panics on zpool import (I'd sent a follow up email noting that it appears the create is working fine but the import panics, based on being able to create the pool on another box running the same OS, but that pool then panics on import on this box). The system is a Dell T320 with three filesystem on an LSI mfii0 controller, but I'm testing ZFS as the only two disk on the onboard AHCI I'm going to try a current kernel in a bit (its a server and gateway box so I'm trying to minimise downtime :) Thanks
Re: panic on zpool create
> On 6. Jan 2020, at 15:04, David Brownlee wrote: > > I've just tried to create a zfs pool and had a panic (tried twice, was > gifted a kernel core each time). This is on latest NetBSD-9.0_RC1 from > nyftp (Thu Jan 2 10:02:26 UTC 2020) > > The command were "zpool create angus_media wd0" and "zpool create -f > angus_media wd0 wd1" > > Moved disks to another machine (On which I'd used zfs before), on > which the latter command completed fine (modulus wd1 and wd2 as > different device numbers). > > Disks were 6TB with any labels/gpt blanked. > > Bit of a puzzler... > > crash reports: > > _KERNEL_OPT_NARCNET() at 0 > ?() at a9826c8f4000 > vpanic() at vpanic+0x169 > snprintf() at snprintf > startlwp() at startlwp > calltrap() at calltrap+0x11 > fstrans_start() at fstrans_start+0x64 > VOP_LOCK() at VOP_LOCK+0x52 > vn_lock() at vn_lock+0x11 > secmodel_extensions_system_cb() at secmodel_extensions_system_cb+0x70 > kauth_authorize_action() at kauth_authorize_action+0xaa > kauth_authorize_system() at kauth_authorize_system+0x28 > zfs_mount() at zfs_mount+0xcf > VFS_MOUNT() at VFS_MOUNT+0x4d > mount_domount() at mount_domount+0xdf > do_sys_mount() at do_sys_mount+0x580 > sys___mount50() at sys___mount50+0x33 > syscall() at syscall+0x157 > --- syscall (number 410) --- > 7d6364687aba: For some reason locking the directory we want to mount on crashes. Anything special with the root on this machine? Does the directory (/angus_media I suppose) exist? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
pmap lock changes: Xen panic
Hello, with 2020-01-05 00:40 UTC sources, Xen domUs panics because of what looks like locking changes in the pmap code (full log at http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/): mlock error: Mutex: mutex_vector_enter,506: assertion failed: !cpu_intr_p(): lock 0xc0b46300 cpu 0 lwp 0xc1aac100 [ 39.3701414] cpu0: Begin traceback... [ 39.3701414] vpanic(c05b72e8,d7c7c728,d7c7c744,c041c699,c05b72e8,c05b04e0,c05746b4,1fa,c05b0454,c0b46300) at netbsd:vpanic+0x134 [ 39.3701414] panic(c05b72e8,c05b04e0,c05746b4,1fa,c05b0454,c0b46300,0,c1aac100,d7c7c768,c03d2ec9) at netbsd:panic+0x18 [ 39.3701414] lockdebug_abort(c05746b4,1fa,c0b46300,c0b414c8,c05b0454,c0b46240,c0b46300,d7c7c794,c03d3405,c05b0454) at netbsd:lockdebug_abort+0xc9 [ 39.3701414] mutex_abort(c05b0454,0,d39e7004,79339,c0b37340,c1aac100,c0b46240,c0b46300,c1a5e1e8,d7c7c7dc) at netbsd:mutex_abort+0x39 [ 39.3701414] mutex_vector_enter(c0b46300,d7c7c7b8,d7c7c7b4,c03cc135,86908857,d7c7a024,c0b37340,c1aac100,d7c7c7d4,c011924f) at netbsd:mutex_vector_enter+0x355 [ 39.3701414] pmap_extract_ma(c0b46240,d6db3000,d7c7c820,0,c1733508,6,d7e7e000,c1a5e1e0,6,c1a5e008) at netbsd:pmap_extract_ma+0x1a [ 39.3701414] xbd_diskstart(c189e908,c2672e2c,1c0,d7c7c884,c011d25e,c0b35880,c1a5e018,32b0,c1a5e008,) at netbsd:xbd_diskstart+0x234 [ 39.3701414] dk_start(c1a5e008,0,c23fc4dc,23f1000,0,1,c2670558,c1a5e1e0,6,d7e7e000) at netbsd:dk_start+0xea [ 39.3701414] xbd_handler(c1a5e008,6,d7c7c978,c18a6318,d7c7c924,c011cc99,c18a6318,d7c7c978,d7c7ca3c,c04a1a7d) at netbsd:xbd_handler+0x12e [ 39.3701414] xen_intr_biglock_wrapper(c18a6318,d7c7c978,d7c7ca3c,c04a1a7d,c1cba008,23f,0,d7c7c9ec,d7c7ca10,c0c589b8) at netbsd:xen_intr_biglock_wrapper+0x1f [ 39.3701414] evtchn_do_event(6,d7c7c978,c0e670fc,c0e62548,c0e68494,0,c0b37340,c0d9a000,c0b37340,0) at netbsd:evtchn_do_event+0xf9 [ 39.3701414] do_hypervisor_callback(d7c7c978,0,11,31,11,c0b40011,0,0,d7c7ca44,bfec0d70) at netbsd:do_hypervisor_callback+0x15f [ 39.3701414] Xhypervisor_pvhvm_callback(c0b46240,d81ae000,696f3000,1,1ef3000,0,1,21,7ff0,21) at netbsd:Xhypervisor_pvhvm_callback+0x67 In rev 1.35 of xen/x86/xen_pmap.c the pmap lock is taken unconditionally, even in the pmap_kernel() case, which means pmap_extract_ma() can't be used from interrrupt context any more. I don't think we can impose such restrictions on pmap_kernel(); bus_dma(9) needs it. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
