daily CVS update output
Updating src tree: P src/build.sh P src/distrib/evbarm/instkernel/Makefile P src/doc/3RDPARTY P src/doc/CHANGES P src/lib/libterminfo/compile.c P src/lib/libterminfo/term_private.h P src/share/man/man4/audio.4 P src/sys/arch/amd64/conf/GENERIC P src/sys/arch/arm/amlogic/gxlphy.c P src/sys/arch/arm/sociox/if_scx.c P src/sys/arch/evbarm/conf/GENERIC P src/sys/arch/evbarm/conf/GENERIC64 P src/sys/arch/i386/conf/GENERIC P src/sys/arch/macppc/conf/GENERIC P src/sys/arch/sparc64/conf/GENERIC P src/sys/dev/audio/audiodef.h P src/sys/dev/mii/brgphy.c P src/sys/dev/mii/ihphy.c P src/sys/dev/mii/micphy.c P src/sys/dev/mii/nsphyter.c P src/sys/dev/mii/ukphy.c P src/sys/external/bsd/acpica/dist/changes.txt P src/sys/external/bsd/acpica/dist/common/acfileio.c P src/sys/external/bsd/acpica/dist/common/acgetline.c P src/sys/external/bsd/acpica/dist/common/adfile.c P src/sys/external/bsd/acpica/dist/common/adisasm.c P src/sys/external/bsd/acpica/dist/common/adwalk.c P src/sys/external/bsd/acpica/dist/common/ahids.c P src/sys/external/bsd/acpica/dist/common/ahpredef.c P src/sys/external/bsd/acpica/dist/common/ahtable.c P src/sys/external/bsd/acpica/dist/common/ahuuids.c P src/sys/external/bsd/acpica/dist/common/cmfsize.c P src/sys/external/bsd/acpica/dist/common/dmextern.c P src/sys/external/bsd/acpica/dist/common/dmrestag.c P src/sys/external/bsd/acpica/dist/common/dmswitch.c P src/sys/external/bsd/acpica/dist/common/dmtable.c P src/sys/external/bsd/acpica/dist/common/dmtables.c P src/sys/external/bsd/acpica/dist/common/dmtbdump.c P src/sys/external/bsd/acpica/dist/common/dmtbdump1.c P src/sys/external/bsd/acpica/dist/common/dmtbdump2.c P src/sys/external/bsd/acpica/dist/common/dmtbdump3.c P src/sys/external/bsd/acpica/dist/common/dmtbinfo.c P src/sys/external/bsd/acpica/dist/common/dmtbinfo1.c P src/sys/external/bsd/acpica/dist/common/dmtbinfo2.c P src/sys/external/bsd/acpica/dist/common/dmtbinfo3.c P src/sys/external/bsd/acpica/dist/common/getopt.c P src/sys/external/bsd/acpica/dist/compiler/aslallocate.c P src/sys/external/bsd/acpica/dist/compiler/aslanalyze.c P src/sys/external/bsd/acpica/dist/compiler/aslascii.c P src/sys/external/bsd/acpica/dist/compiler/aslbtypes.c P src/sys/external/bsd/acpica/dist/compiler/aslcache.c P src/sys/external/bsd/acpica/dist/compiler/aslcodegen.c P src/sys/external/bsd/acpica/dist/compiler/aslcompile.c P src/sys/external/bsd/acpica/dist/compiler/aslcompiler.h P src/sys/external/bsd/acpica/dist/compiler/aslcompiler.l P src/sys/external/bsd/acpica/dist/compiler/aslcstyle.y P src/sys/external/bsd/acpica/dist/compiler/asldebug.c P src/sys/external/bsd/acpica/dist/compiler/asldefine.h P src/sys/external/bsd/acpica/dist/compiler/aslerror.c P src/sys/external/bsd/acpica/dist/compiler/aslexternal.c P src/sys/external/bsd/acpica/dist/compiler/aslfileio.c P src/sys/external/bsd/acpica/dist/compiler/aslfiles.c P src/sys/external/bsd/acpica/dist/compiler/aslfold.c P src/sys/external/bsd/acpica/dist/compiler/aslglobal.h P src/sys/external/bsd/acpica/dist/compiler/aslhelp.c P src/sys/external/bsd/acpica/dist/compiler/aslhelpers.y P src/sys/external/bsd/acpica/dist/compiler/aslhex.c P src/sys/external/bsd/acpica/dist/compiler/aslkeywords.y P src/sys/external/bsd/acpica/dist/compiler/asllength.c P src/sys/external/bsd/acpica/dist/compiler/asllisting.c P src/sys/external/bsd/acpica/dist/compiler/asllistsup.c P src/sys/external/bsd/acpica/dist/compiler/aslload.c P src/sys/external/bsd/acpica/dist/compiler/asllookup.c P src/sys/external/bsd/acpica/dist/compiler/aslmain.c P src/sys/external/bsd/acpica/dist/compiler/aslmap.c P src/sys/external/bsd/acpica/dist/compiler/aslmapenter.c P src/sys/external/bsd/acpica/dist/compiler/aslmapoutput.c P src/sys/external/bsd/acpica/dist/compiler/aslmaputils.c P src/sys/external/bsd/acpica/dist/compiler/aslmessages.c P src/sys/external/bsd/acpica/dist/compiler/aslmessages.h P src/sys/external/bsd/acpica/dist/compiler/aslmethod.c P src/sys/external/bsd/acpica/dist/compiler/aslnamesp.c P src/sys/external/bsd/acpica/dist/compiler/asloffset.c P src/sys/external/bsd/acpica/dist/compiler/aslopcodes.c P src/sys/external/bsd/acpica/dist/compiler/asloperands.c P src/sys/external/bsd/acpica/dist/compiler/aslopt.c P src/sys/external/bsd/acpica/dist/compiler/asloptions.c P src/sys/external/bsd/acpica/dist/compiler/aslparseop.c P src/sys/external/bsd/acpica/dist/compiler/aslparser.y P src/sys/external/bsd/acpica/dist/compiler/aslpld.c P src/sys/external/bsd/acpica/dist/compiler/aslpredef.c P src/sys/external/bsd/acpica/dist/compiler/aslprepkg.c P src/sys/external/bsd/acpica/dist/compiler/aslprimaries.y P src/sys/external/bsd/acpica/dist/compiler/aslprintf.c P src/sys/external/bsd/acpica/dist/compiler/aslprune.c P src/sys/external/bsd/acpica/dist/compiler/aslresource.c P src/sys/external/bsd/acpica/dist/compiler/aslresources.y P src/sys/external/bsd/acpica/dist/compiler/aslrestype1.c P src/sys/external/bsd/acpica/dist/compiler/aslrestype1i.c P
Re: Build time measurements
On Thu, Mar 26, 2020 at 08:44:13PM +, Andrew Doran wrote: > It's a software problem right now. The ACPI idle loop doesn't currenly > enter a low power sleep state because there are issues with interrupts to > solve first. Nevertheless it's very heavy on I/O port access, takes locks > and under certain conditions flushes the entire L1/L2/L3 cache (I haven't > verified that yet but the cache miss rate observed with tprof(8) is very > high). None of above is really true. Well, true, it takes a lock, but I doubt whether locking explains the numbers you are seeing. Because C3 states are not currently used, the other things do not happen. Flushing the caches (when entering/leaving C3) happens only with old CPUs, which certainly is not the case with these benchmarks. The same goes with I/O access. To gain more insights, I'd just commment out acpi_cpu::acpicpu_cstate_attach. It could be, for instance, that you are getting interrupts because of thermal issues (a.k.a. T-states), which, in turn, is a sign that you shouldn't be hitting your CPU so hard. - Jukka
Re: gpt type for zfs?
Sevan Janiyan writes: > On 28/03/2020 21:56, Thomas Klausner wrote: >> Are ZFS users on NetBSD using fbsd-zfs or avoiding gpt? :) > > ZFS doesn't actually care the filesystem time, it's happy to initialise > whatever device node you point at it. I actually partition things up in > sysinst as fat32 partitions. > > Regarding GPT, I connected up a pool which I created on MacOS some years > back to my laptop running 9.99.52, turns out I'd used a GPT scheme, I > couldn't actually import the pool because dk(4) hogs the device. (I > meant to try disabling dk support and retrying but haven't gotten around > to it yet). > > > Sevan I am a little suprised that the import didn't work. "zpool import" didn't find anything to import?? I currently use a gpt presented disk between NetBSD and FreeBSD without any particular problems. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: More POSIX Issue 8 changes (msg #2)
Rhialto wrote in <20200328203055.gc27...@falu.nl>: |and I'm not so sure about the text that follows: | |whereas the ERE ".*?c" matches the first character 'c', the third |character in the string. [[ "abc abc" ]] | |Possibly it should match "abc", because that is leftmost; just matching |"c" is shortest but I don't see it as being leftmost. I'm not sure how |rigorous they define these terms. I like Hermann van Veen. This is in German though. https://www.youtube.com/watch?v=dlgejLidA6A --End of <20200328203055.gc27...@falu.nl> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: gpt type for zfs?
On 28/03/2020 21:56, Thomas Klausner wrote: > Are ZFS users on NetBSD using fbsd-zfs or avoiding gpt? :) ZFS doesn't actually care the filesystem time, it's happy to initialise whatever device node you point at it. I actually partition things up in sysinst as fat32 partitions. Regarding GPT, I connected up a pool which I created on MacOS some years back to my laptop running 9.99.52, turns out I'd used a GPT scheme, I couldn't actually import the pool because dk(4) hogs the device. (I meant to try disabling dk support and retrying but haven't gotten around to it yet). Sevan
Re: gpt type for zfs?
Thomas Klausner writes: > Hi! > > I just noticed that the gpt man page has a type fbsd-zfs, but none for > NetBSD ZFS or any other type. > > Are ZFS users on NetBSD using fbsd-zfs or avoiding gpt? :) > > Is there something we should do in gpt or the man page? > Thomas For gpt, I think anything will work, but I use fbsd-zfs especially if I think I might share the pool with FreeBSD. I have also put pools on raw devices and DOMU xbd* back stored by a LVM lvs. A lot of different combinations seem to work fine. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
gpt type for zfs?
Hi! I just noticed that the gpt man page has a type fbsd-zfs, but none for NetBSD ZFS or any other type. Are ZFS users on NetBSD using fbsd-zfs or avoiding gpt? :) Is there something we should do in gpt or the man page? Thomas
Re: More POSIX Issue 8 changes (msg #2)
and I'm not so sure about the text that follows: whereas the ERE ".*?c" matches the first character 'c', the third character in the string. [[ "abc abc" ]] Possibly it should match "abc", because that is leftmost; just matching "c" is shortest but I don't see it as being leftmost. I'm not sure how rigorous they define these terms. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Panic during reboot on amd64 9.99.52
> On Mar 28, 2020, at 10:08 AM, Paul Goyette wrote: > > I've filed PR kern/55121 for this issue... > > I _do_ have a crash dump available if anyone wants me to provide any > additional info. I've analyzed the problem and have a fix. It's due to the incredibly misguided DVF_DETACH_SHUTDOWN flag. You just happened to win the lottery -- my test system uses makphy, which doesn't set that flag, but ihphy does. -- thorpej
Re: Panic during reboot on amd64 9.99.52
I've filed PR kern/55121 for this issue... I _do_ have a crash dump available if anyone wants me to provide any additional info. On Fri, 27 Mar 2020, Paul Goyette wrote: On Fri, 27 Mar 2020, Paul Goyette wrote: With a curent built from sources updated just a few hours ago (on 2020-03-27 at 16:13:55 UTC), I get a panic during shutdown. The stack trace doesn't seem to be saved, but I manually transcribed it: vpanic + 0x178 kern_assert + 0x48 config_detach + 0x65 mii_detach + 0x109 wm_detach + 0xb0 config_detach + 0xe5 config_detach_all + 0x97 cpu_reboot + 0x198 sys_reboot sys_reboot + 0x63 syscall + 0x299 (syscall #208) Unfortunately, the actual panic message had scrolled off the screen, but it included "bad device fstate". The only mii on my machine should be ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5 and is configured as ihphy0 at mii? phy ? Anyone got any ideas? For now I have reverted to my previous 9.99.46 kernel... A bit more info... The panic message is from the KASSERTMSG() at line 1742 in source file kern/subr_autoconf.c rev 1.269 (very early in config_detach()): KASSERTMSG((cf == NULL || cf->cf_fstate == FSTATE_FOUND || cf->cf_fstate == FSTATE_STAR), "config_detach: %s: bad device fstate: %d", device_xname(dev), cf ? cf->cf_fstate : -1); The actual panic message is config_detach: ihphy0: bad device fstate: 0 According to the #defines in sys/device.h we have #define FSTATE_NOTFOUND 0 /* has not been found */ Just idle curiousity (I am unfamiliar with these drivers), I wonder if it's possible for the ihphy to be detached twice? Perhaps it can be detached by config_detach_all() and then the wm driver tries to detach again? ++--+---+ | 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 | ++--+---+ !DSPAM:5e7e69ae64171663757142! ++--+---+ | 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 | ++--+---+
