Re: Have sysupgrade run fw_update -vv
What about giving sysupgrade the same verbosity options as fw_update? This would mean -v and -vv I sysupgrade would pass through the same options to fw_update. And for the installer, maybe another question: “Verbose download & install progress?” Or no, as default. On Sun, Aug 13, 2023, at 15:42, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2023/08/13 11:44, Andrew Hewus Fresh wrote: > > > My laptop doesn't have the fastest wifi and sysupgrade already uses a > > > progress bar to show what it's doing, so I'd really like to provide more > > > feedback on what it is doing: > > > > Does a single -v give enough feedback? > > As shown below, -vv is ridiculously verbose. > > I think -v is also too verbose. If you are going to do a progress bar, > I think it should be one progress bar. > > I am sure there is a machine out there where -vv will do more than 24 > lines of output. If not today, eventually. > > So I don't think we want -vv or -v in in sysupgrade or the installer, > unless the output is changed to be less verbose. The IMPORTANT information > from sysupgrade or the installer... is not this wall of text. > > > It's a fair bit quieter (it > > doesn't include the time estimates from ftp, but does still prints > > what it's doing before it starts downloading anything potentially > > large, so at least you aren't sat there downloading 12Mb of intel- > > or iwx-firmware or 25Mb of amdgpu-firmware with zero idea about > > what it's doing). > > > > # fw_update -vv > > Detect firmware ... found. > > Get/Verify SHA256.sig 100% |**| 2371 00:00 > > > > Get/Verify intel-firmware-2023080... 100% |*| 12155 KB00:07 > > > > Install intel-firmware-2023080... 100% || 12155 KB00:00 > > > > Get/Verify iwx-firmware-20230330.tgz 100% |*| 12890 KB00:48 > > > > Install iwx-firmware-20230330.tgz 100% || 12890 KB00:00 > > > > Get/Verify vmm-firmware-1.14.0p4.tgz 100% |*| 42927 00:00 > > > > Install vmm-firmware-1.14.0p4.tgz 100% || 42927 00:00 > > > > fw_update: added intel,iwx,vmm; updated none; kept inteldrm,uvideo > > > > vs. > > > > # fw_update -v > > Get/Verify intel-firmware-20230808v0.tgz ... installed. > > Get/Verify iwx-firmware-20230330.tgz ... installed. > > Get/Verify vmm-firmware-1.14.0p4.tgz ... installed. > > fw_update: added intel,iwx,vmm; updated none; kept inteldrm,uvideo > > > > > $ time doas fw_update > > > fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm > > > 0m58.45s real 0m00.51s user 0m00.35s system > > > > firmware.openbsd.org is handled entirely by DNS round-robin with no > > geographical awareness, so even with good local network and internet > > connection, it can sometimes still take a very long time. For example, > > times from two consecutive runs fetching intel-firmware on a 550M > > download connection: > > > > 0m10.11s real 0m00.71s user 0m00.77s system > > 1m17.47s real 0m01.28s user 0m01.22s system > > > >
IKEv2 tunnel crash when sec(4) pushed with large data
Hi, Testing sec(4) between 2 end points with iperf3, iked has lost the associated iface for the sec(4) point to point link. Specifically: pfkey_sa: unsupported interface Here is the surround log for the event: Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: recv CREATE_CHILD_SA req 3 peer 4.4.4.2:64893 local 4.4.4.1:4500, 305 bytes, policy 'policy1' Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: send CREATE_CHILD_SA res 3 peer 4.4.4.2:64893 local 4.4.4.1:4500, 177 bytes, NAT-T Aug 14 11:30:54 terminator iked[93171]: pfkey_sa: unsupported interface Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #1 ENCR=AES_GCM_16-128 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #1 ENCR=AES_GCM_16-256 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #1 ESN=ESN Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #1 ESN=NONE Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 ENCR=AES_CBC-256 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 ENCR=AES_CBC-192 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 ENCR=AES_CBC-128 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 INTEGR=HMAC_SHA2_256_128 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 INTEGR=HMAC_SHA2_384_192 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 INTEGR=HMAC_SHA2_512_256 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 INTEGR=HMAC_SHA1_96 Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 ESN=ESN Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_log_proposal: ESP #2 ESN=NONE Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: ikev2_add_error: NO_PROPOSAL_CHOSEN Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: send CREATE_CHILD_SA res 3 peer 4.4.4.2:64893 local 4.4.4.1:4500, 65 bytes, NAT-T Aug 14 11:30:54 terminator iked[93171]: spi=0x635987a83a22a13e: deleted 1 SPI: 0x37249f77 Aug 14 11:33:04 terminator iked[93171]: spi=0xffb183f53eae6546: recv IKE_SA_INIT req 0 peer 4.4.4.2:60926 local 4.4.4.1:500, 518 bytes, policy 'policy2' Aug 14 11:33:04 terminator iked[93171]: spi=0xffb183f53eae6546: send IKE_SA_INIT res 0 peer 4.4.4.2:60926 local 4.4.4.1:500, 235 bytes Aug 14 11:33:04 terminator iked[93171]: spi=0xffb183f53eae6546: recv IKE_AUTH req 1 peer 4.4.4.2:64893 local 4.4.4.1:4500, 475 bytes, policy 'policy2' Aug 14 11:33:04 terminator iked[93171]: spi=0xffb183f53eae6546: send IKE_AUTH res 1 peer 4.4.4.2:64893 local 4.4.4.1:4500, 341 bytes, NAT-T Aug 14 11:33:04 terminator iked[93171]: pfkey_sa: unsupported interface Aug 14 11:35:43 terminator iked[93171]: spi=0xffb183f53eae6546: sa_free: reload Aug 14 11:37:45 terminator iked[93171]: spi=0x635987a83a22a13e: retransmit 1 INFORMATIONAL req 6 peer 4.4.4.2:64893 local 4.4.4.1:4500 Aug 14 11:37:49 terminator iked[93171]: spi=0x635987a83a22a13e: retransmit 2 INFORMATIONAL req 6 peer 4.4.4.2:64893 local 4.4.4.1:4500 Aug 14 11:37:57 terminator iked[93171]: spi=0x635987a83a22a13e: retransmit 3 INFORMATIONAL req 6 peer 4.4.4.2:64893 local 4.4.4.1:4500 Aug 14 11:38:13 terminator iked[93171]: spi=0x635987a83a22a13e: retransmit 4 INFORMATIONAL req 6 peer 4.4.4.2:64893 local 4.4.4.1:4500 Aug 14 11:38:45 terminator iked[93171]: spi=0x635987a83a22a13e: retransmit 5 INFORMATIONAL req 6 peer 4.4.4.2:64893 local 4.4.4.1:4500 Aug 14 11:39:04 terminator iked[93171]: spi=0x8e5dc9e7e8a397e0: recv IKE_SA_INIT req 0 peer 4.4.4.2:63301 local 4.4.4.1:500, 518 bytes, policy 'policy6' Aug 14 11:39:04 terminator iked[93171]: spi=0x8e5dc9e7e8a397e0: send IKE_SA_INIT res 0 peer 4.4.4.2:63301 local 4.4.4.1:500, 235 bytes Aug 14 11:39:04 terminator iked[93171]: spi=0x8e5dc9e7e8a397e0: recv IKE_AUTH req 1 peer 4.4.4.2:64893 local 4.4.4.1:4500, 473 bytes, policy 'policy6' Aug 14 11:39:04 terminator iked[93171]: spi=0x8e5dc9e7e8a397e0: send IKE_AUTH res 1 peer 4.4.4.2:64893 local 4.4.4.1:4500, 342 bytes, NAT-T Aug 14 11:39:04 terminator iked[93171]: spi=0x8e5dc9e7e8a397e0: ikev2_childsa_enable: loaded SPIs: 0xbd533d62, 0xf7d5e5fd (enc aes-128-gcm esn) Aug 14 11:39:04 terminator iked[93171]: spi=0x8e5dc9e7e8a397e0: established peer 4.4.4.2:64893[IPV4/10.56.0.0] local 4.4.4.1:4500[IPV4/4.4.4.1] policy 'policy5' as responder (enc aes-128-gcm group curve25519 prf hmac-sha2-256) Aug 14 11:39:49 terminator iked[93171]: spi=0x635987a83a22a13e: sa_free: retransmit limit reached To fix the connection and bring it back online the following had to be performed (sec30 was the interface for context): ifconfig sec30 destroy ifconfig sec30 create
Re: kqueue(2) and close-on-exec
I think that changing the behavior of the existing API in a way that gratuitously increases the differences between BSDs is unwise. IMHO, we should follow NetBSD on this and add kqueue1(), that being obviously consistent with the previous 'add flags argument' extensions: pipe2(), dup3(), and accept4(). (As you know, close-on-fork is imposed because the "take a descriptor number" filters are specified in a way tied to a struct filedesc and there's no obvious extension to the kqueue behavior for sharing it across processes. Oh, and as a result trying to do so would result in use-after-frees and/or assertion failures in the kernel. Using a kqueue after exec() is weird, but not logically undefined in that way.) Philip On Sun, Aug 13, 2023 at 4:55 AM Visa Hankala wrote: > FreeBSD and NetBSD have variants of the kqueue(2) system call that > allow setting the close-on-exec flag on the returned file descriptor. > > In general, I think it is good that the flag can be set atomically > for new descriptors. However, it seems to me that it is almost surely > a mistake if a kqueue descriptor is passed over an exec. > > Instead of adding a new system call, maybe close-on-exec should be > enabled automatically by kqueue(2). Today it feels backwards that > close-on-exec is off by default. > > Note that kqueue cannot be inherited by accident in fork-then-exec > situations because fork(2) closes kqueue descriptors for the child > process. > > Index: sys/kern/kern_event.c > === > RCS file: src/sys/kern/kern_event.c,v > retrieving revision 1.197 > diff -u -p -r1.197 kern_event.c > --- sys/kern/kern_event.c 13 Aug 2023 08:29:28 - 1.197 > +++ sys/kern/kern_event.c 13 Aug 2023 10:42:45 - > @@ -932,7 +932,7 @@ sys_kqueue(struct proc *p, void *v, regi > *retval = fd; > LIST_INSERT_HEAD(>fd_kqlist, kq, kq_next); > kq = NULL; > - fdinsert(fdp, fd, 0, fp); > + fdinsert(fdp, fd, UF_EXCLOSE, fp); > FRELE(fp, p); > out: > fdpunlock(fdp); > Index: lib/libc/sys/kqueue.2 > === > RCS file: src/lib/libc/sys/kqueue.2,v > retrieving revision 1.48 > diff -u -p -r1.48 kqueue.2 > --- lib/libc/sys/kqueue.2 13 Aug 2023 08:29:28 - 1.48 > +++ lib/libc/sys/kqueue.2 13 Aug 2023 10:42:45 - > @@ -74,6 +74,7 @@ on a file descriptor will remove any kev > .Pp > .Fn kqueue > creates a new kernel event queue and returns a descriptor. > +The new descriptor has close-on-exec flag set. > The queue is not inherited by a child created with > .Xr fork 2 . > Similarly, kqueues cannot be passed across UNIX-domain sockets. > >
Re: Have sysupgrade run fw_update -vv
Stuart Henderson wrote: > On 2023/08/13 11:44, Andrew Hewus Fresh wrote: > > My laptop doesn't have the fastest wifi and sysupgrade already uses a > > progress bar to show what it's doing, so I'd really like to provide more > > feedback on what it is doing: > > Does a single -v give enough feedback? As shown below, -vv is ridiculously verbose. I think -v is also too verbose. If you are going to do a progress bar, I think it should be one progress bar. I am sure there is a machine out there where -vv will do more than 24 lines of output. If not today, eventually. So I don't think we want -vv or -v in in sysupgrade or the installer, unless the output is changed to be less verbose. The IMPORTANT information from sysupgrade or the installer... is not this wall of text. > It's a fair bit quieter (it > doesn't include the time estimates from ftp, but does still prints > what it's doing before it starts downloading anything potentially > large, so at least you aren't sat there downloading 12Mb of intel- > or iwx-firmware or 25Mb of amdgpu-firmware with zero idea about > what it's doing). > > # fw_update -vv > Detect firmware ... found. > Get/Verify SHA256.sig 100% |**| 2371 00:00 > > Get/Verify intel-firmware-2023080... 100% |*| 12155 KB00:07 > > Install intel-firmware-2023080... 100% || 12155 KB00:00 > > Get/Verify iwx-firmware-20230330.tgz 100% |*| 12890 KB00:48 > > Install iwx-firmware-20230330.tgz 100% || 12890 KB00:00 > > Get/Verify vmm-firmware-1.14.0p4.tgz 100% |*| 42927 00:00 > > Install vmm-firmware-1.14.0p4.tgz 100% || 42927 00:00 > > fw_update: added intel,iwx,vmm; updated none; kept inteldrm,uvideo > > vs. > > # fw_update -v > Get/Verify intel-firmware-20230808v0.tgz ... installed. > Get/Verify iwx-firmware-20230330.tgz ... installed. > Get/Verify vmm-firmware-1.14.0p4.tgz ... installed. > fw_update: added intel,iwx,vmm; updated none; kept inteldrm,uvideo > > > $ time doas fw_update > > fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm > > 0m58.45s real 0m00.51s user 0m00.35s system > > firmware.openbsd.org is handled entirely by DNS round-robin with no > geographical awareness, so even with good local network and internet > connection, it can sometimes still take a very long time. For example, > times from two consecutive runs fetching intel-firmware on a 550M > download connection: > > 0m10.11s real 0m00.71s user 0m00.77s system > 1m17.47s real 0m01.28s user 0m01.22s system >
Re: [PATCH] Support PS2 keyboard on chrromebook
> CC'ed back the mailing list. Oops, I thought I had replied to the list as well, my bad. > Tested your patch. It works on my Chromebook. Excellent. It's in! Thanks, Miod
Re: Have sysupgrade run fw_update -vv
On 2023/08/13 11:44, Andrew Hewus Fresh wrote: > My laptop doesn't have the fastest wifi and sysupgrade already uses a > progress bar to show what it's doing, so I'd really like to provide more > feedback on what it is doing: Does a single -v give enough feedback? It's a fair bit quieter (it doesn't include the time estimates from ftp, but does still prints what it's doing before it starts downloading anything potentially large, so at least you aren't sat there downloading 12Mb of intel- or iwx-firmware or 25Mb of amdgpu-firmware with zero idea about what it's doing). # fw_update -vv Detect firmware ... found. Get/Verify SHA256.sig 100% |**| 2371 00:00 Get/Verify intel-firmware-2023080... 100% |*| 12155 KB00:07 Install intel-firmware-2023080... 100% || 12155 KB00:00 Get/Verify iwx-firmware-20230330.tgz 100% |*| 12890 KB00:48 Install iwx-firmware-20230330.tgz 100% || 12890 KB00:00 Get/Verify vmm-firmware-1.14.0p4.tgz 100% |*| 42927 00:00 Install vmm-firmware-1.14.0p4.tgz 100% || 42927 00:00 fw_update: added intel,iwx,vmm; updated none; kept inteldrm,uvideo vs. # fw_update -v Get/Verify intel-firmware-20230808v0.tgz ... installed. Get/Verify iwx-firmware-20230330.tgz ... installed. Get/Verify vmm-firmware-1.14.0p4.tgz ... installed. fw_update: added intel,iwx,vmm; updated none; kept inteldrm,uvideo > $ time doas fw_update > fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm > 0m58.45s real 0m00.51s user 0m00.35s system firmware.openbsd.org is handled entirely by DNS round-robin with no geographical awareness, so even with good local network and internet connection, it can sometimes still take a very long time. For example, times from two consecutive runs fetching intel-firmware on a 550M download connection: 0m10.11s real 0m00.71s user 0m00.77s system 1m17.47s real 0m01.28s user 0m01.22s system
Re: Virtio fix for testing
On 2023/08/13 16:10, Andrew Cagney wrote: > On Sun, 13 Aug 2023 at 11:38, Tobias Heider wrote: > > > > On Sun, Aug 13, 2023 at 08:33:54AM -0400, Andrew Cagney wrote: > > > > Hi Andrew, > > > > > > > > can you share the qemu cmd you are using in your tests? > > > > I'd like to see if I can reproduce this. > > > > > > Here's pretty much everything. Thanks for looking at it. > > > > Thank you, I managed to reproduce your crash. > > Some good news (of sorts). > > > I am not yet sure what the exact problem is but you could try using > > install73.img > > instead of install73.iso. It looks like only the iso triggers the bug for > > me. > > I'll need to think about how to do this. The script is adding files > to the iso so they are available after the installer has run. I do > see there's an EFI partition. If the installer is run in an environment with network access, fetching sets from http instead of cd/disk might do the trick.
Re: Virtio fix for testing
On Sun, 13 Aug 2023 at 11:38, Tobias Heider wrote: > > On Sun, Aug 13, 2023 at 08:33:54AM -0400, Andrew Cagney wrote: > > > Hi Andrew, > > > > > > can you share the qemu cmd you are using in your tests? > > > I'd like to see if I can reproduce this. > > > > Here's pretty much everything. Thanks for looking at it. > > Thank you, I managed to reproduce your crash. Some good news (of sorts). > I am not yet sure what the exact problem is but you could try using > install73.img > instead of install73.iso. It looks like only the iso triggers the bug for me. I'll need to think about how to do this. The script is adding files to the iso so they are available after the installer has run. I do see there's an EFI partition. thanks
Re: Have sysupgrade run fw_update -vv
Il Dom 13 Ago 2023, 21:17 Mikhail ha scritto: This will be useful in the installer too, when I first installed OpenBSD > with network connection I thought installation was stuck after > "Multiprocessor machine; using bsd.mp instead of bsd.", only after > some time I understood that the installer was downloading firmware. > +1 for this. Cheers, David
Re: Have sysupgrade run fw_update -vv
On Sun, Aug 13, 2023 at 11:44:33AM -0700, Andrew Hewus Fresh wrote:
> My laptop doesn't have the fastest wifi and sysupgrade already uses a
> progress bar to show what it's doing, so I'd really like to provide more
> feedback on what it is doing:
>
> $ doas fw_update -d intel
> fw_update: deleted intel
> $ time doas fw_update
> fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm
> 0m58.45s real 0m00.51s user 0m00.35s system
> $ doas fw_update -d intel
> fw_update: deleted intel
> $ time doas fw_update -vv
> Detect firmware ... found.
> Get/Verify SHA256.sig 100% |**| 2371 00:00
>
> Get/Verify intel-firmware-2023080... 100% |*| 12155 KB01:04
>
> Install intel-firmware-2023080... 100% || 12155 KB00:00
>
> fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm
> 1m17.46s real 0m00.56s user 0m00.34s system
>
>
> Comments, OK?
>
> Index: usr.sbin/sysupgrade/sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.48
> diff -u -p -r1.48 sysupgrade.sh
> --- usr.sbin/sysupgrade/sysupgrade.sh 8 Jun 2022 09:03:11 - 1.48
> +++ usr.sbin/sysupgrade/sysupgrade.sh 13 Aug 2023 18:22:02 -
> @@ -205,7 +205,7 @@ if [[ ${_NEXTKERNV[1]} == '-current' ]];
> else
> FW_URL=http://firmware.openbsd.org/firmware/${_NEXTKERNV[0]}/
> fi
> -VNAME="${_NEXTKERNV[0]}" fw_update -p ${FW_URL} || true
> +VNAME="${_NEXTKERNV[0]}" fw_update -vv -p ${FW_URL} || true
>
> install -F -m 700 bsd.rd /bsd.upgrade
> logger -t sysupgrade -p kern.info "installed new /bsd.upgrade. Old kernel
> version: $(sysctl -n kern.version)"
This will be useful in the installer too, when I first installed OpenBSD
with network connection I thought installation was stuck after
"Multiprocessor machine; using bsd.mp instead of bsd.", only after
some time I understood that the installer was downloading firmware.
(untested patch)
diff /usr/src
commit - 8afcf90fb39e4a84606e93137c2b6c20f44312cb
path + /usr/src
blob - 4386ec9873c433a99fa83b9a9091c06bd952
file + distrib/miniroot/install.sub
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -3008,7 +3008,7 @@ __EOT
fi
__EOT
- [ -x /mnt/usr/sbin/fw_update ] && DESTDIR=/mnt /mnt/usr/sbin/fw_update
+ [ -x /mnt/usr/sbin/fw_update ] && DESTDIR=/mnt /mnt/usr/sbin/fw_update
-vv
if [[ -f $_kernel_dir.tgz ]]; then
echo -n "Relinking to create unique kernel..."
all platforms: separate cpu_initclocks() from cpu_startclock()
This is the next patch in the clock interrupt reorganization series.
Before we continue breaking up the hardclock(9) we need to detour into
the MD code.
This patch divides the "initialization" parts of cpu_initclocks() from
the "start the clock interrupt" parts. Seprating the two parts leaves
initclocks() an opportunity to prepare the primary CPU for clock
interrupt dispatch in a machine-independent manner before actually
pulling the trigger. It's nearly impossible to do any MI setup during
initclocks() because cpu_initclocks() does everything in one go: both
initialization and kickoff are done when cpu_initclocks() returns.
Many platforms have a "cpu_startclock()" function, so this patch takes
that de facto standard and makes it a rule: cpu_startclock() is now
required. It is prototyped in sys/systm.h and every platform must
implement it.
The revised initclocks() sequence is then:
1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures
hz, stathz, and profhz are initialized. All the machine
independent setup in step (2) (currently) depends upon
these machine-dependent values.
2. Compute intervals using hz, stathz, and profhz.
In a later step I will move the full contents of clockintr_init()
up into initclocks() and get rid of clockintr_init() entirely.
3. Call cpu_startclock(). At minimum, cpu_startclock() starts the
clock interrupt dispatch cycle on the primary CPU.
I have compiled/booted this patch on amd64 (lapic path), arm64, i386
(lapic path), macppc, octeon, and sparc64 (sun4v).
I am looking for compile/boot tests on alpha, armv7, hppa, landisk,
luna88k, powerpc64, and riscv64. I think armv7 is the tricky one
here. Everything else is relatively straightforward, though I may
have missed a few stray variables here or there.
Test results? Ok?
Index: kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.113
diff -u -p -r1.113 kern_clock.c
--- kern/kern_clock.c 12 Aug 2023 13:19:28 - 1.113
+++ kern/kern_clock.c 13 Aug 2023 18:45:30 -
@@ -103,6 +103,9 @@ initclocks(void)
profclock_period = 10 / profhz;
inittimecounter();
+
+ /* Start dispatching clock interrupts on the primary CPU. */
+ cpu_startclock();
}
/*
Index: sys/systm.h
===
RCS file: /cvs/src/sys/sys/systm.h,v
retrieving revision 1.164
diff -u -p -r1.164 systm.h
--- sys/systm.h 5 Aug 2023 20:07:56 - 1.164
+++ sys/systm.h 13 Aug 2023 18:45:30 -
@@ -243,6 +243,7 @@ voidinitclocks(void);
void inittodr(time_t);
void resettodr(void);
void cpu_initclocks(void);
+void cpu_startclock(void);
void startprofclock(struct process *);
void stopprofclock(struct process *);
Index: arch/alpha/alpha/clock.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/clock.c,v
retrieving revision 1.28
diff -u -p -r1.28 clock.c
--- arch/alpha/alpha/clock.c25 Jul 2023 18:16:19 - 1.28
+++ arch/alpha/alpha/clock.c13 Aug 2023 18:45:30 -
@@ -143,7 +143,7 @@ clockattach(dev, fns)
*/
/*
- * Start the real-time and statistics clocks.
+ * Measure and initialize clock frequencies.
*/
void
cpu_initclocks(void)
@@ -193,7 +193,14 @@ cpu_initclocks(void)
stathz = hz;
profhz = stathz;
clockintr_init(0);
+}
+/*
+ * Start the real-time and statistics clocks.
+ */
+void
+cpu_startclock(void)
+{
clockintr_cpu_init(NULL);
/*
Index: arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.286
diff -u -p -r1.286 machdep.c
--- arch/amd64/amd64/machdep.c 27 Jul 2023 00:28:25 - 1.286
+++ arch/amd64/amd64/machdep.c 13 Aug 2023 18:45:31 -
@@ -227,6 +227,7 @@ paddr_t avail_end;
void (*delay_func)(int) = i8254_delay;
void (*initclock_func)(void) = i8254_initclocks;
+void (*startclock_func)(void) = i8254_start_both_clocks;
/*
* Format of boot information passed to us by 32-bit /boot
@@ -1878,6 +1879,12 @@ void
cpu_initclocks(void)
{
(*initclock_func)();
+}
+
+void
+cpu_startclock(void)
+{
+ (*startclock_func)();
}
void
Index: arch/amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.68
diff -u -p -r1.68 lapic.c
--- arch/amd64/amd64/lapic.c26 Apr 2023 10:52:55 - 1.68
+++ arch/amd64/amd64/lapic.c13 Aug 2023 18:45:31 -
@@ -499,8 +499,6 @@ lapic_initclocks(void)
stathz = hz;
profhz = stathz * 10;
clockintr_init(CL_RNDSTAT);
-
- lapic_startclock();
}
@@ -599,6 +597,7 @@ skip_calibration:
lapic_per_second * (1ULL << 32) / 10;
Have sysupgrade run fw_update -vv
My laptop doesn't have the fastest wifi and sysupgrade already uses a
progress bar to show what it's doing, so I'd really like to provide more
feedback on what it is doing:
$ doas fw_update -d intel
fw_update: deleted intel
$ time doas fw_update
fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm
0m58.45s real 0m00.51s user 0m00.35s system
$ doas fw_update -d intel
fw_update: deleted intel
$ time doas fw_update -vv
Detect firmware ... found.
Get/Verify SHA256.sig 100% |**| 2371 00:00
Get/Verify intel-firmware-2023080... 100% |*| 12155 KB01:04
Install intel-firmware-2023080... 100% || 12155 KB00:00
fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm
1m17.46s real 0m00.56s user 0m00.34s system
Comments, OK?
Index: usr.sbin/sysupgrade/sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.48
diff -u -p -r1.48 sysupgrade.sh
--- usr.sbin/sysupgrade/sysupgrade.sh 8 Jun 2022 09:03:11 - 1.48
+++ usr.sbin/sysupgrade/sysupgrade.sh 13 Aug 2023 18:22:02 -
@@ -205,7 +205,7 @@ if [[ ${_NEXTKERNV[1]} == '-current' ]];
else
FW_URL=http://firmware.openbsd.org/firmware/${_NEXTKERNV[0]}/
fi
-VNAME="${_NEXTKERNV[0]}" fw_update -p ${FW_URL} || true
+VNAME="${_NEXTKERNV[0]}" fw_update -vv -p ${FW_URL} || true
install -F -m 700 bsd.rd /bsd.upgrade
logger -t sysupgrade -p kern.info "installed new /bsd.upgrade. Old kernel
version: $(sysctl -n kern.version)"
Re: [PATCH] Support PS2 keyboard on chrromebook
CC'ed back the mailing list.
Tested your patch. It works on my Chromebook.
Le sam. 12 août 2023, 08:50, Miod Vallat a écrit :
> > > Have you checked that the Chromebook EC 8042 emulation returns
> 0xab/0x83
> > > to the 0xf2 command?
> > >
> > I've checked that it returns 0xab/0x83.
>
> Good!
>
> > I attach the updated patch here
>
> Can you give this other diff a try and report whether it works on your
> Chromebook?
>
> Index: sys/dev/pckbc/pckbd.c
> ===
> RCS file: /OpenBSD/src/sys/dev/pckbc/pckbd.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 pckbd.c
> --- sys/dev/pckbc/pckbd.c 25 Jul 2023 10:00:44 - 1.50
> +++ sys/dev/pckbc/pckbd.c 12 Aug 2023 06:49:00 -
> @@ -344,7 +344,7 @@ pckbdprobe(struct device *parent, void *
> {
> struct cfdata *cf = match;
> struct pckbc_attach_args *pa = aux;
> - u_char cmd[1], resp[1];
> + u_char cmd[1], resp[2];
> int res;
>
> /*
> @@ -363,10 +363,40 @@ pckbdprobe(struct device *parent, void *
> /* Reset the keyboard. */
> cmd[0] = KBC_RESET;
> res = pckbc_poll_cmd(pa->pa_tag, pa->pa_slot, cmd, 1, 1, resp, 1);
> - if (res) {
> + if (res != 0) {
> #ifdef DEBUG
> printf("pckbdprobe: reset error %d\n", res);
> #endif
> + } else if (resp[0] != KBR_RSTDONE) {
> +#ifdef DEBUG
> + printf("pckbdprobe: reset response 0x%x\n", resp[0]);
> +#endif
> + res = EINVAL;
> + }
> +#if defined(__i386__) || defined(__amd64__)
> + if (res) {
> + /*
> +* The 8042 emulation on Chromebooks fails the reset
> +* command but otherwise appears to work correctly.
> +* Try a "get ID" command to give it a second chance.
> +*/
> + cmd[0] = KBC_GETID;
> + res = pckbc_poll_cmd(pa->pa_tag, pa->pa_slot,
> + cmd, 1, 2, resp, 0);
> + if (res != 0) {
> +#ifdef DEBUG
> + printf("pckbdprobe: getid error %d\n", res);
> +#endif
> + } else if (resp[0] != 0xab || resp[1] != 0x83) {
> +#ifdef DEBUG
> + printf("pckbdprobe: unexpected id 0x%x/0x%x\n",
> + resp[0], resp[1]);
> +#endif
> + res = EINVAL;
> + }
> + }
> +#endif
> + if (res) {
> /*
> * There is probably no keyboard connected.
> * Let the probe succeed if the keyboard is used
> @@ -386,10 +416,6 @@ pckbdprobe(struct device *parent, void *
> }
> #endif
> return (pckbd_is_console(pa->pa_tag, pa->pa_slot) ? 1 : 0);
> - }
> - if (resp[0] != KBR_RSTDONE) {
> - printf("pckbdprobe: reset response 0x%x\n", resp[0]);
> - return (0);
> }
>
> /*
> Index: sys/dev/pckbc/pckbdreg.h
> ===
> RCS file: /OpenBSD/src/sys/dev/pckbc/pckbdreg.h,v
> retrieving revision 1.2
> diff -u -p -r1.2 pckbdreg.h
> --- sys/dev/pckbc/pckbdreg.h22 Oct 2003 09:44:22 - 1.2
> +++ sys/dev/pckbc/pckbdreg.h12 Aug 2023 06:49:00 -
> @@ -12,6 +12,7 @@
> #defineKBC_DISABLE 0xF5/* as per KBC_SETDEFAULT, but also
> disable key scanning */
> #defineKBC_ENABLE 0xF4/* enable key scanning */
> #defineKBC_TYPEMATIC 0xF3/* set typematic rate and delay */
> +#defineKBC_GETID 0xF2/* get keyboard ID (not supported
> on AT kbd) */
> #defineKBC_SETTABLE0xF0/* set scancode translation table
> */
> #defineKBC_MODEIND 0xED/* set mode indicators (i.e. LEDs)
> */
> #defineKBC_ECHO0xEE/* request an echo from the
> keyboard */
>
Re: Virtio fix for testing
On Sun, Aug 13, 2023 at 08:33:54AM -0400, Andrew Cagney wrote: > > Hi Andrew, > > > > can you share the qemu cmd you are using in your tests? > > I'd like to see if I can reproduce this. > > Here's pretty much everything. Thanks for looking at it. Thank you, I managed to reproduce your crash. I am not yet sure what the exact problem is but you could try using install73.img instead of install73.iso. It looks like only the iso triggers the bug for me. > > virt-install \ > --connect=qemu:///system \ > --check=path_in_use=off \ > --graphics=none \ > --virt-type=kvm \ > --noreboot \ > --console=pty,target_type=serial \ > --cpu=host-passthrough \ > --network=network:swandefault,model=virtio \ > --rng=type=random,device=/dev/random \ > --security=type=static,model=dac,label='1000:107',relabel=yes \ > --vcpus=1 \ > --memory=2048 \ > --name=w.openbsd-base \ > --os-variant=openbsd7.3 \ > --disk=path=/home/libreswan/pool/w.openbsd-base.qcow2,size=10,bus=virtio,format=qcow2 > \ > --filesystem=target=pool,type=mount,accessmode=squash,source=/home/libreswan/pool > \ > --cdrom=/home/libreswan/pool/w.openbsd-base.iso > > base.conf which gets added to the iso looks like: > > #install.conf file for OpenBSD > Terminal type? = com0 > System hostname = openbsd > Which network interface do you wish to configure? = vio0 > IPv4 address for = dhcp > DNS Domain name = testing.libreswan.org > Password for root account? = > $2a$12$YZ8bMn19IHPQpBoD6Xf/re/4pp2kbJtVkIl/Mc4G3WA96qyG7/6qW > Start sshd(8) by default = yes > Start ntpd(8) by default? = no > NTP server? (hostname or 'default') = default > Do you expect to run the X Window System? = no > Do you want the X Window System to be started by xdm(1)? = no > Which speed should com0 use? (or 'done') = 19200 > What timezone are you in? = EST > Change the default console to com0? = yes > Setup a user? = no > Allow root ssh login = yes > Use (W)hole disk or (E)dit the MBR? = W > URL to autopartitioning template for disklabel? = file:/base.disk > Which disk is the root disk? = sd0 > Use DUIDs rather than device names in fstab? = yes > Which disk do you wish to initialize? = done > Set name(s)? = all > Location of sets? = cd0 > oPathname to the sets = 7.1/amd64 > Directory does not contain SHA256.sig. Continue without verification? = yes > > this is the console log, part way through pexpect feeds the VM > commands to start the installer: > > cannot open cd0a:/etc/random.seed: No such file or directory > booting cd0a:/7.3/amd64/bsd.rd: 3973828+1655808+3882568+0+708608 > [109+444720+297256]=0xa76648 > entry point at 0x81001000 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 7.3-current (RAMDISK_CD) #1262: Sat Aug 12 11:54:24 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem = 2130542592 (2031MB) > avail mem = 2062016512 (1966MB) > random: good seed from bootblocks > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf59a0 (9 entries) > bios0: vendor SeaBIOS version "1.16.2-1.fc38" date 04/01/2014 > bios0: QEMU Standard PC (i440FX + PIIX, 1996) > acpi0 at bios0: ACPI 1.0 > acpi0: tables DSDT FACP APIC WAET > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 9 3950X 16-Core Processor, 3500.43 MHz, 17-71-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,STIBP,SSBD,IBPB,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1 > cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache > cpu0: 512KB 64b/line 16-way L2 cache > cpu0: apic clock running at 1000MHz > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpiprt0 at acpi0: bus 0 (PCI0) > "ACPI0006" at acpi0 not configured > acpipci0 at acpi0 PCI0 > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "QEMU0002" at acpi0 not configured > com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > com0: console > acpicmos0 at acpi0 > "ACPI0010" at acpi0 not configured > acpicpu at acpi0 not configured > pvbus0 at mainbus0: KVM > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, > channel 0 wired to compatibility, channel 1 wired to compatibility > atapiscsi0 at pciide0 channel 0 drive 0 > scsibus0 at atapiscsi0: 2 targets > cd0 at scsibus0 targ 0 lun 0: removable > cd0(pciide0:0:0):
Re: httpd server "default" is not what I expected
On 2023/08/13 11:27:18 +0100, Jason McIntyre wrote:
> On Sun, Aug 13, 2023 at 11:21:39AM +0100, Stuart Henderson wrote:
> > On 2023/08/13 11:13, Omar Polo wrote:
> > > @@ -179,7 +179,8 @@ section starts with a declaration of the server
> > > Each
> > > .Ic server
> > > section starts with a declaration of the server
> > > -.Ar name :
> > > +.Ar name .
> > > +If no one matches the request the first one defined is used.
> > > .Bl -tag -width Ds
> > > .It Ic server Ar name Brq ...
> > > Match the server name using shell globbing rules.
> >
> > The rest looks good, but I think this might be a little more clear as:
> >
>
> i just got to stuart's mail. this reads nice and clear too.
> jmc
Stuart, Jason, thanks! I like the updated text.
Crystal Kolipe correctly noted offlist that it's not correct to say
"the first defined", it's the first defined server matching the port.
diff /usr/src
commit - a7b17fe845fceeb2940fa5924ec5843681aa2c64
path + /usr/src
blob - 16b086a9ee00cd6d8e796a890e9774968556f147
file + usr.sbin/httpd/httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5
+++ usr.sbin/httpd/httpd.conf.5
@@ -98,7 +98,7 @@ server "default" {
For example:
.Bd -literal -offset indent
ext_ip="10.0.0.1"
-server "default" {
+server "example.com" {
listen on $ext_ip port 80
}
.Ed
@@ -179,7 +179,11 @@ section starts with a declaration of the server
Each
.Ic server
section starts with a declaration of the server
-.Ar name :
+.Ar name .
+If a request does not match any server name, it is handled by the
+first defined
+.Ic server
+section that matches the listening port.
.Bl -tag -width Ds
.It Ic server Ar name Brq ...
Match the server name using shell globbing rules.
@@ -779,7 +783,7 @@ server "default" {
.Bd -literal -offset indent
prefork 2
-server "default" {
+server "example.com" {
listen on * port 80
}
@@ -800,7 +804,7 @@ server "default" {
.Qq egress
group.
.Bd -literal -offset indent
-server "default" {
+server "example.com" {
listen on egress port 80
}
.Ed
Re: Virtio fix for testing
> Hi Andrew, > > can you share the qemu cmd you are using in your tests? > I'd like to see if I can reproduce this. Here's pretty much everything. Thanks for looking at it. virt-install \ --connect=qemu:///system \ --check=path_in_use=off \ --graphics=none \ --virt-type=kvm \ --noreboot \ --console=pty,target_type=serial \ --cpu=host-passthrough \ --network=network:swandefault,model=virtio \ --rng=type=random,device=/dev/random \ --security=type=static,model=dac,label='1000:107',relabel=yes \ --vcpus=1 \ --memory=2048 \ --name=w.openbsd-base \ --os-variant=openbsd7.3 \ --disk=path=/home/libreswan/pool/w.openbsd-base.qcow2,size=10,bus=virtio,format=qcow2 \ --filesystem=target=pool,type=mount,accessmode=squash,source=/home/libreswan/pool \ --cdrom=/home/libreswan/pool/w.openbsd-base.iso base.conf which gets added to the iso looks like: #install.conf file for OpenBSD Terminal type? = com0 System hostname = openbsd Which network interface do you wish to configure? = vio0 IPv4 address for = dhcp DNS Domain name = testing.libreswan.org Password for root account? = $2a$12$YZ8bMn19IHPQpBoD6Xf/re/4pp2kbJtVkIl/Mc4G3WA96qyG7/6qW Start sshd(8) by default = yes Start ntpd(8) by default? = no NTP server? (hostname or 'default') = default Do you expect to run the X Window System? = no Do you want the X Window System to be started by xdm(1)? = no Which speed should com0 use? (or 'done') = 19200 What timezone are you in? = EST Change the default console to com0? = yes Setup a user? = no Allow root ssh login = yes Use (W)hole disk or (E)dit the MBR? = W URL to autopartitioning template for disklabel? = file:/base.disk Which disk is the root disk? = sd0 Use DUIDs rather than device names in fstab? = yes Which disk do you wish to initialize? = done Set name(s)? = all Location of sets? = cd0 oPathname to the sets = 7.1/amd64 Directory does not contain SHA256.sig. Continue without verification? = yes this is the console log, part way through pexpect feeds the VM commands to start the installer: cannot open cd0a:/etc/random.seed: No such file or directory booting cd0a:/7.3/amd64/bsd.rd: 3973828+1655808+3882568+0+708608 [109+444720+297256]=0xa76648 entry point at 0x81001000 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3-current (RAMDISK_CD) #1262: Sat Aug 12 11:54:24 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 2130542592 (2031MB) avail mem = 2062016512 (1966MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf59a0 (9 entries) bios0: vendor SeaBIOS version "1.16.2-1.fc38" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: ACPI 1.0 acpi0: tables DSDT FACP APIC WAET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 9 3950X 16-Core Processor, 3500.43 MHz, 17-71-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,STIBP,SSBD,IBPB,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1 cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: apic clock running at 1000MHz ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com0: console acpicmos0 at acpi0 "ACPI0010" at acpi0 not configured acpicpu at acpi0 not configured pvbus0 at mainbus0: KVM pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: removable cd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 disabled (no drives) "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured virtio0 at pci0 dev 2 function 0 vendor "Qumranet", unknown product 0x1009 rev 0x00 virtio0: no matching child driver; not configured virtio1 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio1: address 52:54:00:38:8c:5d virtio1: msix per-VQ uhci0 at pci0 dev 4 function 0 "Intel 82801I USB" rev 0x03: apic 0 int 11 uhci1 at pci0
kqueue(2) and close-on-exec
FreeBSD and NetBSD have variants of the kqueue(2) system call that allow setting the close-on-exec flag on the returned file descriptor. In general, I think it is good that the flag can be set atomically for new descriptors. However, it seems to me that it is almost surely a mistake if a kqueue descriptor is passed over an exec. Instead of adding a new system call, maybe close-on-exec should be enabled automatically by kqueue(2). Today it feels backwards that close-on-exec is off by default. Note that kqueue cannot be inherited by accident in fork-then-exec situations because fork(2) closes kqueue descriptors for the child process. Index: sys/kern/kern_event.c === RCS file: src/sys/kern/kern_event.c,v retrieving revision 1.197 diff -u -p -r1.197 kern_event.c --- sys/kern/kern_event.c 13 Aug 2023 08:29:28 - 1.197 +++ sys/kern/kern_event.c 13 Aug 2023 10:42:45 - @@ -932,7 +932,7 @@ sys_kqueue(struct proc *p, void *v, regi *retval = fd; LIST_INSERT_HEAD(>fd_kqlist, kq, kq_next); kq = NULL; - fdinsert(fdp, fd, 0, fp); + fdinsert(fdp, fd, UF_EXCLOSE, fp); FRELE(fp, p); out: fdpunlock(fdp); Index: lib/libc/sys/kqueue.2 === RCS file: src/lib/libc/sys/kqueue.2,v retrieving revision 1.48 diff -u -p -r1.48 kqueue.2 --- lib/libc/sys/kqueue.2 13 Aug 2023 08:29:28 - 1.48 +++ lib/libc/sys/kqueue.2 13 Aug 2023 10:42:45 - @@ -74,6 +74,7 @@ on a file descriptor will remove any kev .Pp .Fn kqueue creates a new kernel event queue and returns a descriptor. +The new descriptor has close-on-exec flag set. The queue is not inherited by a child created with .Xr fork 2 . Similarly, kqueues cannot be passed across UNIX-domain sockets.
Re: httpd server "default" is not what I expected
On Sun, Aug 13, 2023 at 11:21:39AM +0100, Stuart Henderson wrote: > On 2023/08/13 11:13, Omar Polo wrote: > > @@ -179,7 +179,8 @@ section starts with a declaration of the server > > Each > > .Ic server > > section starts with a declaration of the server > > -.Ar name : > > +.Ar name . > > +If no one matches the request the first one defined is used. > > .Bl -tag -width Ds > > .It Ic server Ar name Brq ... > > Match the server name using shell globbing rules. > > The rest looks good, but I think this might be a little more clear as: > i just got to stuart's mail. this reads nice and clear too. jmc > > Each > .Ic server > section starts with a declaration of the server > -.Ar name : > +.Ar name . > +If a request does not match any server name, it is handled by the first > +defined > +.Ic server > +section. > .Bl -tag -width Ds > .It Ic server Ar name Brq ... > Match the server name using shell globbing rules. >
Re: httpd server "default" is not what I expected
On Sun, Aug 13, 2023 at 11:13:28AM +0200, Omar Polo wrote:
> [moving to tech@, there's a diff for the manpage below]
>
hi. comments inline:
>
> diff /usr/src
> commit - a7b17fe845fceeb2940fa5924ec5843681aa2c64
> path + /usr/src
> blob - 16b086a9ee00cd6d8e796a890e9774968556f147
> file + usr.sbin/httpd/httpd.conf.5
> --- usr.sbin/httpd/httpd.conf.5
> +++ usr.sbin/httpd/httpd.conf.5
> @@ -98,7 +98,7 @@ server "default" {
> For example:
> .Bd -literal -offset indent
> ext_ip="10.0.0.1"
> -server "default" {
> +server "example.com" {
> listen on $ext_ip port 80
> }
> .Ed
> @@ -179,7 +179,8 @@ section starts with a declaration of the server
> Each
> .Ic server
> section starts with a declaration of the server
> -.Ar name :
> +.Ar name .
> +If no one matches the request the first one defined is used.
i think it'd be clearer to use "none" rather than "no one" here. i know
what you mean, but it's easy to confuse this with the idea of no person.
also you might want to stick a comma after "request".
i.e.
If none matches the request, the first one ...
jmc
> .Bl -tag -width Ds
> .It Ic server Ar name Brq ...
> Match the server name using shell globbing rules.
> @@ -779,7 +780,7 @@ server "default" {
> .Bd -literal -offset indent
> prefork 2
>
> -server "default" {
> +server "example.com" {
> listen on * port 80
> }
>
> @@ -800,7 +801,7 @@ server "default" {
> .Qq egress
> group.
> .Bd -literal -offset indent
> -server "default" {
> +server "example.com" {
> listen on egress port 80
> }
> .Ed
>
Re: httpd server "default" is not what I expected
On 2023/08/13 11:13, Omar Polo wrote: > @@ -179,7 +179,8 @@ section starts with a declaration of the server > Each > .Ic server > section starts with a declaration of the server > -.Ar name : > +.Ar name . > +If no one matches the request the first one defined is used. > .Bl -tag -width Ds > .It Ic server Ar name Brq ... > Match the server name using shell globbing rules. The rest looks good, but I think this might be a little more clear as: Each .Ic server section starts with a declaration of the server -.Ar name : +.Ar name . +If a request does not match any server name, it is handled by the first +defined +.Ic server +section. .Bl -tag -width Ds .It Ic server Ar name Brq ... Match the server name using shell globbing rules.
Re: Virtio fix for testing
On Sat, Aug 12, 2023 at 06:41:17PM -0400, Andrew Cagney wrote: > On Sat, 12 Aug 2023 at 16:18, Stuart Henderson wrote: > > > > Is there a way to get an updated ISO or kernel with the fix? > > > (we're already adding an installer config file to the ISO, so why not a > > > kernel) > > > > > > Andrew > > > > > > > It was committed to -current, so if you're able to use a snapshot > > build (https://cdn.openbsd.org/pub/OpenBSD/snapshots) that would > > likely be the simplest fix. > > Greg, Stuart, thanks for the pointers. Unfortunately I had no luck: > > OpenBSD 7.3-current (RAMDISK_CD) #1262: Sat Aug 12 11:54:24 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > ... > Installing base73.tgz19% | | 72320 KB > 00:25 ETAwdc_atapi_start: not ready, st = 50 > Installing base73.tgz22% |* | 83840 KB > 00:27 ETAfatal protection fault in supervisor mode > trap type 4 code 0 rip 81008c29 cs 8 rflags 10286 cr2 > 251d44000 cpl 6 rsp 800021749050 > gsbase 0x81908ff0 kgsbase 0x0 > panic: trap type 4, code=0, pc=81008c29 > syncing disks... > > I guess I've a different problem. Now I need a cheat sheet on how to > pull a backtrace :-/ > Hi Andrew, can you share the qemu cmd you are using in your tests? I'd like to see if I can reproduce this. Tobias
Re: httpd server "default" is not what I expected
13.08.2023 12:13, Omar Polo пишет:
> [moving to tech@, there's a diff for the manpage below]
>
> On 2023/08/13 01:04:11 -0700, Alfred Morgan wrote:
>> I was surprised that `server "default"` didn't act like I expected. In this
>> example I expected `test1` to get 200 and everything else to get 404 but
>> this is not the case. In this example server "test1" actually catches all:
>> localhost, test1, and test2 will get code 200.
>>
>> /etc/hosts:
>> 127.0.0.1 localhost test1 test2
>>
>> /tmp/httpd.conf:
>> server "test1" {
>> listen on localhost port 8080
>> block return 200
>> }
>>
>> server "default" {
>> listen on localhost port 8080
>> block return 404
>> }
>>
>> httpd -df /tmp/httpd.conf &
>
> as you've found out, there's no special meaning behind the "default"
> server name. It just means you're defining a virtua host called
> "default".
>
> let's go through your tests.
>
>> ftp -o - http://localhost:8080/ #200
>
> no `server' block match "localhost", so httpd uses the first server.
>
> (this is actually undocumented AFAICS)
>
>> ftp -o - http://test1:8080/ #200
>
> this matches your first server.
>
>> ftp -o - http://test2:8080/ #200
>
> This also doesn't match any server block, so httpd uses the first one.
>
>> man httpd.conf says:
>> "Match the server name using shell globbing rules. This can be an explicit
>> name, www.example.com, or a name including wildcards, *.example.com."
>>
>> There is no mention as to what `server "default"` does even though it is
>> used several times in the man page. I find the behaviour to be odd
>> for it not to be documented. It isn't until I change the line to `server
>> "*"` when it starts doing what I expected:
>>
>> ftp -o- http://localhost:8080/ #404
>> ftp -o- http://test1:8080/ #200
>> ftp -o- http://test2:8080/ #404
>>
>> This is a gotcha in general. I would think the examples should use server
>> "*" instead and document what server "default" actually does.
>
> I agree that's a gotcha and it's easy to misunderstand from the
> manpage. I'd prefer to use "example.com" as is done on many other
> manpages and sample configurations. Diff below.
>
> While here, add a note that if there's no match the first one is used.
> IMHO it's not a great choice, I would have preferred if it returned a
> 4XX error instead (not found or a generic bad request maybe).
>
>> and while we are here. Why does running httpd as a user say:
>> httpd: need root privileges
>>
>> does it...?
>
> If it say so... :)
>
> httpd needs to chroot and run as 'www' user so needs to be started as
> root. It also may need to read private keys which are also owned by
> root.
This reads better to me and "example.com" matches
/etc/examples/httpd.conf; OK kn
>
>
> diff /usr/src
> commit - a7b17fe845fceeb2940fa5924ec5843681aa2c64
> path + /usr/src
> blob - 16b086a9ee00cd6d8e796a890e9774968556f147
> file + usr.sbin/httpd/httpd.conf.5
> --- usr.sbin/httpd/httpd.conf.5
> +++ usr.sbin/httpd/httpd.conf.5
> @@ -98,7 +98,7 @@ server "default" {
> For example:
> .Bd -literal -offset indent
> ext_ip="10.0.0.1"
> -server "default" {
> +server "example.com" {
> listen on $ext_ip port 80
> }
> .Ed
> @@ -179,7 +179,8 @@ section starts with a declaration of the server
> Each
> .Ic server
> section starts with a declaration of the server
> -.Ar name :
> +.Ar name .
> +If no one matches the request the first one defined is used.
> .Bl -tag -width Ds
> .It Ic server Ar name Brq ...
> Match the server name using shell globbing rules.
> @@ -779,7 +780,7 @@ server "default" {
> .Bd -literal -offset indent
> prefork 2
>
> -server "default" {
> +server "example.com" {
> listen on * port 80
> }
>
> @@ -800,7 +801,7 @@ server "default" {
> .Qq egress
> group.
> .Bd -literal -offset indent
> -server "default" {
> +server "example.com" {
> listen on egress port 80
> }
> .Ed
>
Re: httpd server "default" is not what I expected
[moving to tech@, there's a diff for the manpage below]
On 2023/08/13 01:04:11 -0700, Alfred Morgan wrote:
> I was surprised that `server "default"` didn't act like I expected. In this
> example I expected `test1` to get 200 and everything else to get 404 but
> this is not the case. In this example server "test1" actually catches all:
> localhost, test1, and test2 will get code 200.
>
> /etc/hosts:
> 127.0.0.1 localhost test1 test2
>
> /tmp/httpd.conf:
> server "test1" {
> listen on localhost port 8080
> block return 200
> }
>
> server "default" {
> listen on localhost port 8080
> block return 404
> }
>
> httpd -df /tmp/httpd.conf &
as you've found out, there's no special meaning behind the "default"
server name. It just means you're defining a virtua host called
"default".
let's go through your tests.
> ftp -o - http://localhost:8080/ #200
no `server' block match "localhost", so httpd uses the first server.
(this is actually undocumented AFAICS)
> ftp -o - http://test1:8080/ #200
this matches your first server.
> ftp -o - http://test2:8080/ #200
This also doesn't match any server block, so httpd uses the first one.
> man httpd.conf says:
> "Match the server name using shell globbing rules. This can be an explicit
> name, www.example.com, or a name including wildcards, *.example.com."
>
> There is no mention as to what `server "default"` does even though it is
> used several times in the man page. I find the behaviour to be odd
> for it not to be documented. It isn't until I change the line to `server
> "*"` when it starts doing what I expected:
>
> ftp -o- http://localhost:8080/ #404
> ftp -o- http://test1:8080/ #200
> ftp -o- http://test2:8080/ #404
>
> This is a gotcha in general. I would think the examples should use server
> "*" instead and document what server "default" actually does.
I agree that's a gotcha and it's easy to misunderstand from the
manpage. I'd prefer to use "example.com" as is done on many other
manpages and sample configurations. Diff below.
While here, add a note that if there's no match the first one is used.
IMHO it's not a great choice, I would have preferred if it returned a
4XX error instead (not found or a generic bad request maybe).
> and while we are here. Why does running httpd as a user say:
> httpd: need root privileges
>
> does it...?
If it say so... :)
httpd needs to chroot and run as 'www' user so needs to be started as
root. It also may need to read private keys which are also owned by
root.
diff /usr/src
commit - a7b17fe845fceeb2940fa5924ec5843681aa2c64
path + /usr/src
blob - 16b086a9ee00cd6d8e796a890e9774968556f147
file + usr.sbin/httpd/httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5
+++ usr.sbin/httpd/httpd.conf.5
@@ -98,7 +98,7 @@ server "default" {
For example:
.Bd -literal -offset indent
ext_ip="10.0.0.1"
-server "default" {
+server "example.com" {
listen on $ext_ip port 80
}
.Ed
@@ -179,7 +179,8 @@ section starts with a declaration of the server
Each
.Ic server
section starts with a declaration of the server
-.Ar name :
+.Ar name .
+If no one matches the request the first one defined is used.
.Bl -tag -width Ds
.It Ic server Ar name Brq ...
Match the server name using shell globbing rules.
@@ -779,7 +780,7 @@ server "default" {
.Bd -literal -offset indent
prefork 2
-server "default" {
+server "example.com" {
listen on * port 80
}
@@ -800,7 +801,7 @@ server "default" {
.Qq egress
group.
.Bd -literal -offset indent
-server "default" {
+server "example.com" {
listen on egress port 80
}
.Ed
Re: smr_grace_wait(): Skip halted CPUs
On Sat, Aug 12, 2023 at 02:40:31PM +0200, Martin Pieuchot wrote: > So do we want to keep the existing requirement of being able to execute > a thread on a CPU that has been removed from the scheduler? That's is > what smr_flush() currently needs. I find it surprising but I can add > that as a requirement for the upcoming scheduler. I don't know if other > options are possible or even attractive. I think it is useful that the kernel can force a thread to run on a specific CPU even when general scheduling has been stopped. It is maybe a bit crude, but nonetheless effective and machine independent, way of synchronization. The kernel has a few current uses of sched_peg_curproc(). Perhaps the most prominent ones are interrupt barriers and the SMR grace wait mechanism.
