Re: openssl3+postfix issue (ca md too weak)

[trimming tech-crypto from cc because this is a policy and configuration issue, not a cryptography issue] > Date: Mon, 13 Nov 2023 20:34:04 +0100 > From: Manuel Bouyer > > I'm facing an issue with postfix+openssl3 which may be critical (depending > on how it can be fixed). > > Now my postfix

Re: Call for testing: certctl, postinstall, TLS trust anchors

Correcting a small error in the previous message: > Date: Wed, 11 Oct 2023 18:47:02 + > From: Taylor R Campbell > > Note: The formal PKIX language has a way for a CA certificate to > express that the CA it represents is authorized to sign certificates > for TLS ser

Re: Call for testing: certctl, postinstall, TLS trust anchors

say, /etc/smime/certs), which exists only outside the PKIX certificate language. Some other point-by-point replies below: > Date: Mon, 09 Oct 2023 21:04:06 -0400 > From: Greg Troxel > > Taylor R Campbell writes: > > > I'm prioritizing effort on TLS, but I _installed_ the emai

Re: Call for testing: certctl, postinstall, TLS trust anchors

> Date: Sun, 08 Oct 2023 10:54:13 -0400 > From: Greg Troxel > > (I've been putting off thinking about and dealing with this due to > juggling too many other things.) No worries, glad you found some time to review it! > Taylor R Campbell writes: > > > The new

Re: cgd questions

> Date: Sun, 1 Oct 2023 14:50:20 +0200 > From: Thomas Klausner > > I tried finding this in the man page, but it wasn't fully clear to me. > > When I pick up a cgd disk and want to use it on a NetBSD system to > which it was not connected before, what do I need? > > - the passphrase > - the

Re: kerberos issues with 10.0_BETA post openssl update

> Date: Wed, 6 Sep 2023 10:39:34 + > From: Taylor R Campbell > > A possible workaround is to set: > > [libdefaults] > k5login_directory = /root > > However, that applies to _all_ kuserok checks for _all_ users, not > just the pam_ksu one

Re: kerberos issues with 10.0_BETA post openssl update

> Date: Wed, 6 Sep 2023 16:41:00 +1200 > From: Mark Davies > > OK, so revision 1.10 of pam_ksu.c adds a call to > krb5_set_home_dir_access(NULL, FALSE); > which causes the subsequent call to krb5_kuserok() to return false when > previously it would return true causing the whole pam_ksu to

Re: kerberos issues with 10.0_BETA post openssl update

> Date: Wed, 6 Sep 2023 09:54:16 +1200 > From: Mark Davies > > OK, found a simpler reproducible crash. Run "kadmin -l" on a kdc and > try to change a password. > > xen2# kadmin -l > kadmin> passwd ecsproctor > ecsproc...@ecs.vuw.ac.nz's Password: > Verifying - ecsproc...@ecs.vuw.ac.nz's

Re: kerberos issues with 10.0_BETA post openssl update

> Date: Mon, 4 Sep 2023 16:46:35 +1200 > From: Mark Davies > > Having updated from a 10.0_BETA built in march to one built couple > of weeks ago (post the openssl3 merge) I'm now seeing various > kerberos issues that I wasn't seeing before. Can you share `ldd /usr/libexec/kadmind' on the

Call for testing: certctl, postinstall, TLS trust anchors

We're preparing to ship TLS trust anchors in base and configure them so that applications like ftp(1) and pkg_add(1) can do TLS validation out of the box. The new certctl(8) tool is provided to manage the TLS trust anchors configured in /etc/openssl/certs with a simple way to change the source of

Repository conversion is temporarily suspended

The automatic conversion of the NetBSD CVS repository to Fossil, Hg, and Git is temporarily suspended until 2023-09-08. The rack space donated to TNF for the infrastructure is undergoing renovation from 2023-08-28 to 2023-09-08. Apologies for the inconvenience.

git workflow across forced updates

skin crawl like it does for me.) #!/bin/sh # Copyright (c) 2023 Taylor R. Campbell # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must

Re: builds fail w/undef ref in rump tests

> Date: Sun, 20 Aug 2023 09:45:20 -0500 (CDT) > From: "John D. Baker" > > On Sun, 20 Aug 2023, Taylor R Campbell wrote: > > > That's odd, can you share this ident(1) output? > > > > cd $OBJDIR/tests/rump > > ident kernspace/workqueue.o ke

Re: builds fail w/undef ref in rump tests

> Date: Sun, 20 Aug 2023 14:11:02 +0200 > From: Martin Husemann > > On Sun, Aug 20, 2023 at 12:08:01PM +0000, Taylor R Campbell wrote: > > > /r0/build/current/tools/amd64/bin/mips64el--netbsd-gcc > > > --sysroot=/r0/build/current/DEST/evbmips64-el -Wl,--war

Re: builds fail w/undef ref in rump tests

> From: "John D. Baker" > Date: Sat, 19 Aug 2023 11:28:32 -0500 (CDT) > > Now that the MKCROSSGDB and new libpcap issues seem to have been ironed > out, my builds (all arches) have resumed failing due to the following > (evbmips-mips64el shown, sparc, macppc, dreamcast, i386, amd64 show the >

Re: 10.99.7 panic: defibrillate

> Date: Mon, 14 Aug 2023 18:16:49 +0200 > From: Thomas Klausner > > On Mon, Aug 14, 2023 at 12:41:06PM +0200, Thomas Klausner wrote: > > I had followed your suggestion and bumped the heartbeat limit from 15 > > to 300, but today it paniced again. > > > > panic: cpu8: found cpu9 heart stopped

MKCROSSGDB=yes broken in new gdb?

$ time nice -n +10 env -i PATH=/bin:/usr/bin ./build.sh -O ../obj.arm64 -T ../obj.arm64/tooldir -U -u -m evbarm64 -j4 -N1 -V MKCROSSGDB=yes -V MKDEBUG=yes -V USE_PIGZGZIP=yes release [...] In file included from

Re: 10.99.7 panic: defibrillate

> Date: Sun, 13 Aug 2023 06:16:51 -0400 > From: Greg Troxel > > Would it be useful for heartbeat to have a just-log-don't-panic option? Worth considering, but... > It feels like are in a state where we know there is a problem somewhere, > and we don't know if it is in heartbeat, the kernel, or

Re: 10.99.7 panic: defibrillate

> Date: Sun, 13 Aug 2023 06:16:53 + > From: Taylor R Campbell > > > Date: Sun, 13 Aug 2023 08:03:00 +0200 > > From: Thomas Klausner > > > > So it happened again, no bulk build this time, just qt5-qtwebengine in > > a sandbox. > > > >

Re: 10.99.7 panic: defibrillate

> Date: Sun, 13 Aug 2023 08:03:00 +0200 > From: Thomas Klausner > > So it happened again, no bulk build this time, just qt5-qtwebengine in > a sandbox. > > panic: cpu0: softints stuck for 16 seconds You could try `no options HEARTBEAT' in your kernel and see if anything is stuck after a day of

Re: 10.99.7 panic: defibrillate

> Date: Sat, 12 Aug 2023 17:28:27 +0200 > From: Thomas Klausner > > I just got a new panic in 10.99.7 after running a pbulk for less than > a day (after updating from 10.99.5, which was stable for weeks). > ... > vpanic() at netbsd:vpanic+0x173 panic() at netbsd :panic+0x3c > defibrillate() at

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Tue, 01 Aug 2023 16:02:17 -0400 > From: Brad Spencer > > Taylor R Campbell writes: > > > So I just added a printf to the kernel in case this jump happens. Can > > you update to xen_clock.c 1.15 (and sys/arch/x86/include/cpu.h 1.135) > > and tr

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Mon, 31 Jul 2023 12:47:20 -0400 > > # dtrace -x nolibs -n 'sdt:xen:hardclock:jump { @ = quantize(arg1 - arg0) } > sdt:xen:hardclock:jump /arg2 >= 430/ { printf("hardclock jump violated > timecounter contract") }' > dtrace: description 'sdt:xen:hardclock:jump ' matched 2 probes > dtrace:

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Sun, 30 Jul 2023 14:56:53 -0400 > From: Brad Spencer > > Taylor R Campbell writes: > > > Can you please try running with the attached patch and share the > > warnings it produces? Should give slightly more information. > > Caught another one.

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Fri, 28 Jul 2023 09:42:30 -0400 > From: Brad Spencer > > Thanks, that allowed the dtrace to execute, but I never have time to > execute the second probe, as this kernel panic occures within a few > seconds of the first probe being run (probably on the order of 4 - 5 > seconds): > > [

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Fri, 28 Jul 2023 07:42:04 -0400 > From: Brad Spencer > > dtrace: invalid probe specifier sdt:xen:hardclock:jump { @ = quantize(arg1 - > arg0) } tick-10s { printa(@) }: probe description :::tick-10s does not match > any probes modload dtrace_profile

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Thu, 27 Jul 2023 11:17:30 -0400 > From: Brad Spencer > > On the system that I have that exhibits the negative runtime problem, it > may very well be the case that hardclocks are missed for 4.3sec. The > system has to have been up for a while and busy as a prereq., but if I > then run: >

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Thu, 27 Jul 2023 15:05:23 +1000 > from: matthew green > > one problem i've seen in kern_tc.c when the timecounter returns > a smaller value is that tc_delta() ends up returning a very large > (underflowed) value, and that makes the consumers of it do a very > wrong thing. eg, -2 becomes

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

Can you please try running with the attached patch and share the warnings it produces? Should give slightly more information. >From b6f360d9b1fdc418105fcc41b41f1206ca04334d Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Wed, 26 Jul 2023 01:36:28 + Subject: [PATCH] WIP: attribut

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Thu, 20 Jul 2023 21:50:26 -0400 > From: Brad Spencer > > With a DOMU kernel compiled with KDTRACE_HOOKS I get the following with > either of those dtrace probes on the DOMU: > > dtrace -n 'sdt:xen:clock:, sdt:xen:hardclock:, sdt:xen:timecounter: { > printf("%d %d %d %d %d %d %d", arg0,

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Thu, 13 Jul 2023 13:39:43 + > From: Taylor R Campbell > > > Date: Sat, 08 Jul 2023 14:34:56 -0400 > > From: Brad Spencer > > > > [ 1792486.921759] kobj_checksyms, 988: [dtrace]: linker error: symbol > > `dtrace_invop_calltrap_addr' not fou

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Sat, 08 Jul 2023 14:34:56 -0400 > From: Brad Spencer > > Taylor R Campbell writes: > > > Can you either: > > Yes, I can perform as much of this as needed after I get some other > stuff in life dealt with more towards the end of the month. I reall

New ddb command: show all tstiles

We often get reports of the form `system is hung with processes stuck in tstile again, must be the same problem as '. Unfortunately, these are usually _not_ the same problem, or even related in more than a superficial way, because `processes stuck in tstile' just means `waiting for a lock'. And

Re: What to do about "WARNING: negative runtime; monotonic clock has gone backwards"

> Date: Wed, 04 Jan 2023 14:43:25 -0500 > From: Brad Spencer > > So... I have a PV+PVSHIM DOMU running a pretty recent 9.x on a DOM0 > running a 9.99.xx kernel. The DOM0 is not large, a 4 processor E-2224 > with 32GB of memory. The DOMU has 2 VCPUs and 8GB of memory. About > every day a very

Re: Call for testing: New kernel heartbeat(9) checks

> Date: Fri, 7 Jul 2023 17:56:42 +0200 > From: Manuel Bouyer > > On Fri, Jul 07, 2023 at 01:11:54PM +0000, Taylor R Campbell wrote: > > - The magic numbers for debug.crashme.spl_spinout are for evbarm. > > On x86, use IPL_SCHED=7, IPL_VM=6, and IPL_SOFTCLOCK=1. Cor

Call for testing: New kernel heartbeat(9) checks

FYI: In 10.99.5, I just added a new kernel diagnostic subsystem called heartbeat(9) that will make the system crash rather than hang when CPUs are stuck in certain ways that hardware watchdog timers can't detect (or on systems without hardware watchdog timers). It's optional for now, but it's

Re: AMDGPU Driver patches/bugs

> Date: Tue, 21 Feb 2023 13:20:13 -0800 > From: Jeff Frasca > > I was going to try the radeon driver again, because I want to see if > my wayland compositor works better against it than the AMDGPU driver > (I'm getting some weird corruption problems with my compositor that > do not happen under

Re: AMDGPU Driver patches/bugs

tches. Should I open a bug? Send these to the kernel > mailing list? Patches applied, thanks! I tweaked them a little bit, including to fix an arithmetic overflow bug that you had copied & pasted from one Taylor R Campbell, riastr...@netbsd.org, in kern_ksyms.c...oops. (Fix also applied in

Re: specfs/spec_vnops.c diagnostic assertion panic

> Date: Sat, 13 Aug 2022 19:47:54 +0700 > From: Robert Elz > > However, since we now know the issue we have been looking at does involve > the raw devices, not the block ones, I'm not sure what is the point of > reverting that specfs_vnode.c patch, which only affects the block device > open. If

Re: specfs/spec_vnops.c diagnostic assertion panic

if you can reproduce any crash? (I believe specfs_blockopen.patch is still necessary for other reasons but it gets in the way of testing my hypothesis that dk_close_parent needs to be serialized with dk_open_parent anyway.) >From 5eaacbd7d9d6d6b3ccfea5564aebf9548f5b7564 Mon Sep 17 00:00:00 2001

Re: specfs/spec_vnops.c diagnostic assertion panic

Here's a hypothesis about what happened. - You have a RAID volume, say raid0, with a GPT partitioning it. - raid0 is configured with an explicit /etc/raid0.conf file, rather than with an autoconfigured label. - You have devpubd=YES in /etc/rc.conf. On boot, the following sequence of events

Re: specfs/spec_vnops.c diagnostic assertion panic

> Date: Sat, 13 Aug 2022 02:13:23 +0700 > From: Robert Elz > > Apart from dkctl() and the two fsck_ffs processes, there was > the parent fsck (just in wait) and (or course) init, and a whole > set of sh processes (many in pipe_rd or similar) - which will be > the infrastructure used for running

Re: specfs/spec_vnops.c diagnostic assertion panic

Can you try the attached patch and see if (a) it still panics, or if (b) there are any other adverse consequences like fsck failing? >From 7ade169092246e8870aaab2973d8bb252e625d89 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Fri, 12 Aug 2022 20:01:50 + Subject: [PATCH] spe

Re: specfs/spec_vnops.c diagnostic assertion panic

I added a couple more assertions (spec_vnops.c 1.213). Attached is an updated patch with the ABI change to record who was closing when it shouldn't be possible. >From 4df657b9ca2112c556eb7aaf7b6ed5b6912603c1 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Sat, 16 Apr 2022 11:45:06 +0

Re: specfs/spec_vnops.c diagnostic assertion panic

> Date: Fri, 12 Aug 2022 23:28:13 +0700 > From: Robert Elz > > I think I am going to try backing out the patch, and just run with your > (Taylor's) updated specfs_vnops.c in case there is something in the patch > which is altering the behaviour (more than just the nature of the sd_closing >

Re: specfs/spec_vnops.c diagnostic assertion panic

> Date: Thu, 11 Aug 2022 13:01:34 + > From: Taylor R Campbell > > If that still doesn't help, you could try the attached patch (which > I'm not committing at the moment because it changes the kernel ABI). ...patch actually attached now >From 11428c92e7bc51a35942c2024b95c7

Re: specfs/spec_vnops.c diagnostic assertion panic

I've seen something like that in syzkaller before: https://syzkaller.appspot.com/bug?id=47c67ab6d3a87514d0707882a9ad6671beaa864 If you cvs up spec_vnops.c to 1.211, you may get a different assertion firing, or not; which assertion fires now might potentially help to diagnose the problem. If

Re: Virtio Viocon driver - possible to backport from OpenBSD?

rom 50c5c4d195f82ad7b665a7e0adfa922a448e9cfb Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Tue, 9 Aug 2022 14:09:38 + Subject: [PATCH] viocon(4): New virtio tty driver imported from OpenBSD. viocon* at virtio? Tested under qemu with: qemu-system-aarch64 ... \ -device virtio-serial \ -char

Re: kernel deadlock on fstchg with vnd

> Date: Mon, 30 May 2022 14:33:42 +0200 > From: "J. Hannken-Illjes" > > >> 1767 /* Nuke the vnodes for any open instances */ > >> 1768 for (i = 0; i < MAXPARTITIONS; i++) { > >> 1769 mn = DISKMINOR(device_unit(vnd->sc_dev), i); > >> 1770

Re: uvideo uvm_fault panic

> Date: Sat, 14 May 2022 15:14:50 + > From: sc.dy...@gmail.com > > On 2022/05/14 13:47, Taylor R Campbell wrote: > > Can you please try the two attached patches? > > > > 1. uvideobadstream.patch should fix the _crash_ when you try to open a > >vide

Re: entropy startup panic

> Date: Thu, 24 Mar 2022 14:23:09 +0100 > From: Thomas Klausner > > On Thu, Mar 24, 2022 at 01:03:11PM +0000, Taylor R Campbell wrote: > > > Date: Thu, 24 Mar 2022 11:29:16 +0100 > > > From: Thomas Klausner > > > > > > entropy_account_cpu() a

Re: entropy startup panic

> Date: Thu, 24 Mar 2022 11:29:16 +0100 > From: Thomas Klausner > > I've just updated from a 3 days old kernel to todays, and it didn't > finish booting up. > > The console output, hand-copied: > > breakpoint() at netbsd:breakpoint > vpanic() at netbsd:vpanic+0x156 > kern_assert() at

Re: HEADS UP: Merging drm update

> Date: Mon, 03 Jan 2022 22:08:26 +0900 > From: Ryo ONODERA > > Ryo ONODERA writes: > > > __engines_record_defaults > > intel_gt_wait_for_idle > > intel_gt_retire_requests_timeout > > dma_fence_wait_timeout > > i915_fence_wait (via *fence->ops->wait) > > i915_request_wait > > > > In

Re: HEADS UP: Merging drm update (Lenovo X230 mode switch issue in UEFI mode only, BIOS works)

> Date: Fri, 31 Dec 2021 11:30:32 +0100 > From: Matthias Petermann > > - When I boot current in UEFI mode, after the mode switch it only > displays a blank screen with a white background. After that, within a > few seconds, a kind of randomly structured dark spot develops from the > center of

Re: HEADS UP: Merging drm update

> Date: Tue, 28 Dec 2021 11:34:43 +0900 > From: Ryo ONODERA > > intel_gt_pm_fini() at netbsd:intel_gt_pm_fini+0x18 > intel_gt_init() at netbsd:intel_gt_init+0x6ad > i915_gem_init() at netbsd:i915_gem_init+0x14d > i915_driver_probe() at netbsd:i915_driver_probe+0x949 > i915drmkms_attach_real() at

Re: HEADS UP: Merging drm update

> Date: Tue, 28 Dec 2021 08:41:16 +0900 > From: Ryo ONODERA > > panic: mutex_vector_enter,518: uninitialized lock (lock=0xd80023501458, > from=807c091c) > cpu0: Begin traceback... > vpanic() at netbsd:vpanic+0x156 > panic() at netbsd:panic+0x3c > lockdebug_wantlock() at

Re: HEADS UP: Merging drm update

> Date: Mon, 27 Dec 2021 12:34:10 +0900 > From: Ryo ONODERA > > panic: kernel diagnostic assertion "!(!i915_request_completed(rq))" failed: > file "/usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_gt.c", line 475 I committed a change that I think will fix the particular bug leading to

Re: HEADS UP: Merging drm update

Can you try the attached patch? Also, if you haven't already, can you try running a DIAGNOSTIC/DEBUG/LOCKDEBUG kernel? >From 025745d6f43aff21c88bc9e3b393ce146fc9af04 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Sun, 26 Dec 2021 16:05:20 + Subject: [PATCH] drm: Fix locking aro

Re: HEADS UP: Merging drm update

> Date: Sun, 26 Dec 2021 02:37:31 +0900 > From: Ryo ONODERA > > If panic is removed, my LCD turns black finally and stay black forever > and does not reach to USB serial console. > [...] > However I am not sure because I cannot get any message. > > Do you have an idea to investigate deeper?

Re: HEADS UP: Merging drm update

Better yet -- can you try the attached patch? >From e484fe666999730543f490ce6084486f7d7ce524 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Fri, 24 Dec 2021 11:12:43 + Subject: [PATCH] i915: Use AcpiOsMapMemory, not bus_space_map, for opregion. Needed because this appears in firmw

Re: HEADS UP: Merging drm update

> Date: Thu, 23 Dec 2021 17:26:49 + > From: Taylor R Campbell > > > Date: Fri, 24 Dec 2021 01:53:03 +0900 > > From: Ryo ONODERA > > > > And with this patch, I have gotten the following dmesg: > > This has no bus_space_map and extent_alloc_subregio

Re: HEADS UP: Merging drm update

> Date: Fri, 24 Dec 2021 01:53:03 +0900 > From: Ryo ONODERA > > And with this patch, I have gotten the following dmesg: > This has no bus_space_map and extent_alloc_subregion1... OK, can you try the attached patch and see if it gives us any clues in dmesg? This prints a stack trace any time

Re: HEADS UP: Merging drm update

> Date: Thu, 23 Dec 2021 14:56:19 + > From: Taylor R Campbell > > I'm wondering whether the two bus_space_maps in intel_opregion_setup > overlap, and whether one needs to be a bus_space_subregion or > something. Never mind, that's a red herring and obviously not wha

Re: HEADS UP: Merging drm update

> Date: Thu, 23 Dec 2021 20:53:00 +0900 > From: Ryo ONODERA > > I have added panic()s to extent_alloc_region and > extent_insert_and_optimize. > And the kernel with this change does not display anything at all. > After bootloader, my LCD turns black and stays black forever. > I have removed

Re: HEADS UP: Merging drm update

> Date: Wed, 22 Dec 2021 18:58:51 + > From: Taylor R Campbell > > > Date: Thu, 23 Dec 2021 00:57:13 +0900 > > From: Ryo ONODERA > > > > Ryo ONODERA writes: > > > > > I have no useful information or thought yet… > > > > > >

Re: HEADS UP: Merging drm update

> Date: Thu, 23 Dec 2021 00:57:13 +0900 > From: Ryo ONODERA > > Ryo ONODERA writes: > > > I have no useful information or thought yet… > > > > I have added check for BADADDR+OPREGION_SIZE in bus_space_reserve. > > And I have found that no one uses that address. > > I have added similar logic

Re: HEADS UP: Merging drm update

> Date: Tue, 21 Dec 2021 22:47:34 +0900 > From: Ryo ONODERA > > I think that "Cannot find any crtc or sizes" may be related to > "Failed to find VBIOS tables (VBT)". > I have added some printf lines to some functions invoked before > intel_bios_init in >

Re: HEADS UP: Merging drm update

> Date: Mon, 20 Dec 2021 11:35:45 +0900 > From: Kengo NAKAHARA > > GENERIC kernel without DIAGNOSTIC option fails to build. > Could you apply the following patch? > > https://github.com/knakahara/netbsd-src/commit/b1c93870ef5689201b6eb7e08811bc40e3e1543e Thanks! I did it slightly

Re: HEADS UP: Merging drm update

> Date: Sun, 19 Dec 2021 23:51:58 + > From: Taylor R Campbell > > > Date: Sun, 19 Dec 2021 21:41:14 +0100 > > From: Benny Siegert > > > > Meanwhile, I built a new kernel from HEAD on my Pinebook Pro. There is > > a bit of a pause when DRM is initiali

Re: HEADS UP: Merging drm update

> Date: Sun, 19 Dec 2021 21:41:14 +0100 > From: Benny Siegert > > Meanwhile, I built a new kernel from HEAD on my Pinebook Pro. There is > a bit of a pause when DRM is initialized during boot, and X is > basically unusable -- it takes a minute or so to draw the login screen > (slim). > [...] >

Re: HEADS UP: Merging drm update

> Date: Sun, 19 Dec 2021 01:42:53 + > From: Taylor R Campbell > > > Date: Sat, 18 Dec 2021 17:06:13 + > > From: Taylor R Campbell > > > > I'm planning to merge the drm update this weekend -- a cvs import and > > merge commit, plus about 1

Re: HEADS UP: Merging drm update

> Date: Sat, 18 Dec 2021 17:06:13 + > From: Taylor R Campbell > > I'm planning to merge the drm update this weekend -- a cvs import and > merge commit, plus about 1300 commits on top of that from the git > repository. The update is in progress, but my commitbomb sc

HEADS UP: Merging drm update

I'm planning to merge the drm update this weekend -- a cvs import and merge commit, plus about 1300 commits on top of that from the git repository. Please don't commit anything to the following subtrees until done -- if you do, your changes will be lost: sys/external/bsd/drm2

Re: zpool import skips wedges due to a race condition

ch in my tree from a while ago to scan non-wedge disks first, then wedges. For some reason I didn't commit it but I forget why. (Well, it's a little kludgey to look at the pathname to distinguish dkN devices, but...) >From dbee261ca7b5837946e93ec601acb04ae0b0a8b1 Mon Sep 17 00:00:00 2001 From: Taylor

Re: Script command under NetBSD-current

> Date: Mon, 14 Jun 2021 20:01:49 + > From: RVP > > #0 0x7f7fbfa0ab3a in ___lwp_park60 () from /usr/libexec/ld.elf_so > #1 0x7f7fbfa0265d in _rtld_exclusive_enter () from /usr/libexec/ld.elf_so > #2 0x7f7fbfa03125 in _rtld_exit () from /usr/libexec/ld.elf_so > #3

Re: Automated report: NetBSD-current/i386 install success

> Date: Sun, 13 Jun 2021 09:39:22 +0300 > From: Andreas Gustafsson > > The NetBSD Test Fixture wrote: > > The NetBSD-current/i386 install is working again. > > So it is, but the system now panics during the ATF tests: > > dev/fss/t_fss (38/899): 1 test cases > basic: [ 148.2076287]

Re: regarding the changes to kernel entropy gathering

> Date: Mon, 05 Apr 2021 10:58:58 +0700 > From: Robert Elz > > I understand that some people desire highly secure systems (I'm not > convinced that anyone running NetBSD can really justify that desire, > but that's beside the point) and that's fine - make the system be able > to be as secure as

Re: regarding the changes to kernel entropy gathering

> Date: Mon, 5 Apr 2021 01:16:56 + (UTC) > From: RVP > > Then, the issue here is one of predictability. NetBSD doesn't want, > for extremely valid reason, to incorporate any perturbation sources > which have been pooh-poohed in the technical literature. Why do you say that? We do

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 4 Apr 2021 21:24:56 + (UTC) > From: RVP > > I think running the /dev/random bit-stream through some statistical > tests, (both on RDRAND/RDSEED-based and estimator-based as in your > patch) would be useful here. No, because the output of /dev/random and /dev/urandom is the

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 04 Apr 2021 12:58:09 -0700 > From: "Greg A. Woods" > References: > <20210404094958.692f360...@jupiter.mumble.net> > > At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell > wrote: > Subject: Re: regarding the changes to kernel entropy

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 4 Apr 2021 11:14:31 -0700 > From: John Nemeth > > I understand the need for good random sources, and won't argue > it. My question is, how can we tell what random sources a system > actually has, i.e. is there some flag that cpuctl identify shows > when a system has

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 04 Apr 2021 23:47:10 +0700 > From: Robert Elz > > Date:Sun, 4 Apr 2021 15:28:13 + > From: Taylor R Campbell > Message-ID: <20210404152814.3c56360...@jupiter.mumble.net> > > | you can let NetBSD take care of it aut

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 4 Apr 2021 10:40:22 -0400 (EDT) > From: Mouse > > > What NetBSD-current is telling you on your Xen system, on a CPU > > predating RDRAND/RDSEED, is the unfortunate truth that there is no > > reliable source of entropy available in your system -- > > Not quite. That there is

Re: regarding the changes to kernel entropy gathering

> Date: Sat, 03 Apr 2021 12:24:29 -0700 > From: "Greg A. Woods" > > Updating a system, even on -current, shouldn't create a long-lived > situation where the system documentation and the behaviour and actions > of system commands is completely out of sync with the behaviour of the > kernel, and

Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)

> Date: Tue, 30 Mar 2021 16:23:43 -0700 > From: "Greg A. Woods" > > At Tue, 30 Mar 2021 23:53:43 +0200, Manuel Bouyer > wrote: > > On Tue, Mar 30, 2021 at 02:40:18PM -0700, Greg A. Woods wrote: > > > Perhaps the answer is that nothing seems to be contributing anything to > > > the entropy

Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)

> Date: Tue, 30 Mar 2021 23:53:43 +0200 > From: Manuel Bouyer > > On Tue, Mar 30, 2021 at 02:40:18PM -0700, Greg A. Woods wrote: > > [...] > > > > Perhaps the answer is that nothing seems to be contributing anything to > > the entropy pool. No matter what device I exercise, none of the numbers

Re: [HEADS UP] pkgsrc default database directory changed

> Date: Sun, 13 Dec 2020 20:11:53 +0100 > From: Thomas Klausner > > On Sun, Dec 13, 2020 at 02:18:32PM +0100, Rhialto wrote: > > A problem with pkg.refcount might be that files in that directory > > contain absolute pathnames starting with /var/db/pkg. E.g.: > > > > $ cat

Re: Entropy problem [was Re: CVS Problem (again) ,Slightly lesser old code, but old still [was Re: Console problem ,older code]]

> Date: Sat, 5 Dec 2020 15:19:15 -0800 > From: Germain Le Chapelain > > It's building firefox again, > > I haven't yet tried any work-around mentioned in the email > introducing the change But I am confused about the issue, why this > arises. > > I thought the way randomness was implemented is

Re: "wireguard" implementation improperly merged and needs revert

[followups to tech-net to reduce cross-posting noise] Hi, Jason! Sorry about not reaching out. The history is that the code has been kicking around the NetBSD world since Ozaki-san first wrote it in 2018, without getting merged into src. It felt a shame to let it wallow in that state

WireGuard in NetBSD

Back in 2018, ozaki-r@ wrote an in-kernel implementation of WireGuard for NetBSD -- a point-to-point roaming- capable virtual private network tunnel with modern cryptography. Today I imported Ozaki-san's WireGuard code into NetBSD proper. Here's an example of how to

Re: Automated report: NetBSD-current/i386 build failure

> Date: Sun, 26 Jul 2020 15:20:05 +0300 > From: Andreas Gustafsson > > The build is still failing, current error as of 2020.07.26.09.17.24: > > === 1 extra files in DESTDIR = > Files in DESTDIR but missing from flist. > File is obsolete or flist is out of date ? >

Re: VIA Padlock on AMD64

> Date: Fri, 24 Jul 2020 00:35:19 +0300 > From: Andrius V > > > > Cool! Is it reproducible? You can trigger reading from the RNG with: > > > > > > sysctl kern.entropy.gather=1 > > Tested, no messages are triggered for amd64, but sysctl > kern.entropy.gather value is always 0: > sysctl -w

Re: VIA Padlock on AMD64

> Date: Wed, 22 Jul 2020 03:17:21 +0300 > From: Andrius V > > Not sure how useful to work on this though. Linux doesn't seem to have > newer graphics IDs in VIA DRM driver too (possibly abandoned over new > effort?). Currently Xorg server starts on VX900, but screen complains > with "Input

Re: VIA Padlock on AMD64

> Date: Mon, 20 Jul 2020 21:31:20 + > From: Taylor R Campbell > > > Date: Tue, 21 Jul 2020 00:16:16 +0300 > > From: Andrius V > > > > After a bit more investigation, yes, it is kassert (kernel diagnostic > > assertion "viadrm_pci_ids[i].subvendo

Re: VIA Padlock on AMD64

> Date: Tue, 21 Jul 2020 00:16:16 +0300 > From: Andrius V > > After a bit more investigation, yes, it is kassert (kernel diagnostic > assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" ), doesn't > matter amd64/i386. Panic should be fixed in via_pci 1.3. >The cause

Re: 9.99.69 panic - libcrypto changes?

> Date: Thu, 2 Jul 2020 23:09:16 +0100 > From: Chavdar Ivanov > > On amd64 9.99.69 from yesterday I get: > > crash: _kvm_kvatop(0) > Crash version 9.99.69, image version 9.99.69. > Kernel compiled without options LOCKDEBUG. > System panicked: fpudna from kernel, ip 0x802292af, trapframe

x86 in-kernel fpu bug

> Date: Mon, 20 Jul 2020 11:04:21 +0100 > From: Patrick Welche > > After a -current/amd64 update, a sudden outbreak of floating point exceptions: > > /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/tree-ssa-operands.c:1348:1: > > internal compiler error: Floating point exception

Re: VIA Padlock on AMD64

> Date: Mon, 20 Jul 2020 08:16:34 +0300 > From: Andrius V > > Considering it is limited usage isn't the kernel module actually more > useful, since you can add it to boot config once you really need it? > Unless, in-kernel functionality won't work with the kernel module for some > reason.

Re: VIA Padlock on AMD64

> Date: Sun, 19 Jul 2020 14:16:25 +0300 > From: Andrius V > > I just noticed that padlock driver was made to compile on amd64 > recently. I believe it should be included in modules Makefile > (/sys/modules/Makefile) as well (as per my git diff in previous > messages). I guess we could do that.

Re: 9.99.69 panic - libcrypto changes?

> Date: Mon, 6 Jul 2020 13:49:26 +0100 > From: Chavdar Ivanov > > On Mon, 6 Jul 2020 at 02:14, Taylor R Campbell wrote: > > > > This and the earlier panic you reported may be fixed by > > > > https://mail-index.netbsd.org/source-changes/2020/07/06/msg1190

  1   2   >