Re: OpenBSD 7.4 in virtualize env
> Sometimes, rarely, across multiple version ( did not see it in 7.5 so far ) > the log `scsi_xfer pool exhausted` just get spammed forever, > > It doesn't crash, the device just spam the message , so it s active > > I do not have a way to create the problem , but, > i wonder if the code could be modified so the device just drop to DDB >Did you run out of memory / swap perhaps? I have noticed that occurring when my system runs out of swap space. -- jrmu IRCNow (https://ircnow.org) signature.asc Description: PGP signature
Re: OpenBSD 7.4 in virtualize env
On 2024-05-24, Sven F. wrote: > --c4123906193364e5 > Content-Type: text/plain; charset="UTF-8" > > Hello, > > Sometimes, rarely, across multiple version ( did not see it in 7.5 so far ) > the log `scsi_xfer pool exhausted` just get spammed forever, > > It doesn't crash, the device just spam the message , so it s active > > I do not have a way to create the problem , but, > i wonder if the code could be modified so the device just drop to DDB It can, just change the printf to panic. /sys/scsi/scsi_base.c r1.283 fixed the main thing triggering that problem, but it was already committed before 7.4
OpenBSD 7.4 in virtualize env
Hello, Sometimes, rarely, across multiple version ( did not see it in 7.5 so far ) the log `scsi_xfer pool exhausted` just get spammed forever, It doesn't crash, the device just spam the message , so it s active I do not have a way to create the problem , but, i wonder if the code could be modified so the device just drop to DDB something like if this pool is exhausted for "longtime" just crash (or reboot if sysctl is configured that way ) ``` bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68b0 (9 entries) bios0: vendor SeaBIOS version "2:1.10.2-58953eb7" date 04/01/2014 bios0: OpenStack Foundation OpenStack Nova ... vioscsi0 at virtio1: qsize 128 scsibus1 at vioscsi0: 255 targets sd0 at scsibus1 targ 0 lun 0: ``` I will upgrade to 7.5 soon anyway Best.
Re: gmake compile of python3.12 crashes on openBSD 7.5 but not on openBSD 7.4
On 2024-05-12, Sandeep Gupta wrote: > ./Tools/scripts/pydoc3 > build/scripts-3.12/pydoc3.12 > Illegal instruction (core dumped) > > I am unable to find a proper debugger into which to load the python.core > generated after core dump, so can't provide any useful debug info. pkg_add gdb and use the 'egdb' command.
gmake compile of python3.12 crashes on openBSD 7.5 but not on openBSD 7.4
I was able to compile Python 3.12 from source code on openBSD 7.4. However, after upgrade to 7.5 the compile process crashes with core dump: cc -pthread -g -Wl,--export-dynamic -o Programs/_testembed Programs/_testembed.o -L. -lpython3.12 -lpthread -lutil -lm _testembed.c:1848 (./Programs/_testembed.c:1848)(Programs/_testembed.o:(test_init_use_frozen_modules)): warning: wcscpy() is almost always misused, please use wcslcpy() sed -e "s,/usr/bin/env python3,/home/kabiraatmonallabs/Execution/Runtime/bin/python3.12," < ./Tools/scripts/2to3 > build/scripts-3.12/2to3-3.12 sed -e "s,/usr/bin/env python3,/home/kabiraatmonallabs/Execution/Runtime/bin/python3.12," < ./Tools/scripts/idle3 > build/scripts-3.12/idle3.12 sed -e "s,/usr/bin/env python3,/home/kabiraatmonallabs/Execution/Runtime/bin/python3.12," < ./Tools/scripts/pydoc3 > build/scripts-3.12/pydoc3.12 Illegal instruction (core dumped) gmake[2]: *** [Makefile:1142: checksharedmods] Error 132 gmake[2]: Leaving directory '/home/kabiraatmonallabs/Execution/Runtime/Python-3.12.2' gmake[1]: *** [Makefile:793: profile-gen-stamp] Error 2 gmake[1]: Leaving directory '/home/kabiraatmonallabs/Execution/Runtime/Python-3.12.2' gmake: *** [Makefile:805: profile-run-stamp] Error 2 I am unable to find a proper debugger into which to load the python.core generated after core dump, so can't provide any useful debug info. I don't think this is due to some changes in Python code that is creating the core dump. Any ideas would be helpful. Thanks Sandeep
cdce issues with upgrade from OpenBSD 7.4 to 7.5
Hello. I am seeing a possible issue with the cdce driver since I upgraded from 7.4 to 7.5. I was using a u-blox modem connected via a PCIe-USB board that worked under OpenBSD 7.4. See following link for pertinent info: https://www.eskimo.com/~joji/cdce/obsd74 Once I upgraded to 7.5, the board is being detected. However, network access (ping, dns resolution, etc. is hanging). I ran tcpdump on the cdce0 interface and I see, for example, queries going out to a DNS server and responses coming back. However, "host " and "ping " hangs. See for more info: https://www.eskimo.com/~joji/cdce/obsd75 I'm reaching out to see if there are others using the cdce interface that are seeing issues with the cdce interface after upgrade. Thank you. joseph
Re: SATA slow/timeouts, AMD 600 Series AHCI, OpenBSD 7.4 amd64
I've found trying to upgrade such a system with this bug to be very difficult. It just hangs while attempting the upgrade (post the reboot). Attempting an upgrade via a usb install does much the same. Is slow to prompt to ask for keyboard layout. After that, just hangs. Perhaps me having setup a software raid1 made this bug worse. Pity I have to have a motherboard that is not very compatible with openbsd :( b...@po.cwru.edu writes: >> Divan Santana [20240131 165546 +0200]: >> >> b...@po.cwru.edu writes: >> >> > Onboard SATA seems to require additional initialization on a Gigabyte >> > B650 in OpenBSD 7.4 amd64; basic requests take minutes to complete and >> > each block read takes 30 seconds. During boot, attached SSDs will block >> > pending these requests; >> >> I have the same issue. I was hoping to install openbsd 7.4 on this new >> AMD MSI board server. >> >> This issue is quite a show stopper for me. >> >> If anyone wants some further input from me to debug this, let me know. >> >> @b...@po.cwru.edu is there any workaround? > > The only user-land workaround I know is to suspend with `zzz -z`. After > resuming, the bus seems to be in a workable state. > > I've had great success with the noted kernel driver workaround, which > applies the reset during system startup. Optical drive performance has > been as expected with that workaround. > > Hopefully one of those will work for you, and if any OpenBSD developers > are listening, maybe one of them can see the "right" way to do this.
Re: nodejs/node package seems broken on openbsd 7.4 on amd64
It's not the node package that's broken, but the esbuild binary distributed on
npm, see also
https://github.com/evanw/esbuild/issues/3523
You might want to try building esbuild yourself, on your OpenBSD system.
On 2024-03-05 10:12, Sandeep Gupta wrote:
As best i can see, node (node-18.18) is broken and cannot be used at all.
No matter the package config "npm install" results in same error:
```
npm install
npm ERR! code 1
npm ERR! path
/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild
npm ERR! command failed
npm ERR! command sh -c node install.js
npm ERR! node:internal/errors:865
npm ERR! const err = new Error(message);
npm ERR! ^
npm ERR!
npm ERR! Error: Command failed:
/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/bin/esbuild
--version
npm ERR! at checkExecSyncError (node:child_process:890:11)
npm ERR! at Object.execFileSync (node:child_process:926:15)
npm ERR! at validateBinaryVersion
(/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/install.js:99:28)
npm ERR! at
/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/install.js:286:5
{
npm ERR! status: null,
npm ERR! signal: 'SIGILL',
npm ERR! output: [ null, Buffer(0) [Uint8Array] [], Buffer(0)
[Uint8Array] [] ],
npm ERR! pid: 50423,
npm ERR! stdout: Buffer(0) [Uint8Array] [],
npm ERR! stderr: Buffer(0) [Uint8Array] []
npm ERR! }
npm ERR!
npm ERR! Node.js v18.18.0
```
Re: nodejs/node package seems broken on openbsd 7.4 on amd64
El Tue, 5 Mar 2024 10:12:31 +0530
Sandeep Gupta escribió:
> As best i can see, node (node-18.18) is broken and cannot be used at
> all. No matter the package config "npm install" results in same error:
> ```
> npm install
> npm ERR! code 1
> npm ERR! path
> /home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild
> npm ERR! command failed
> npm ERR! command sh -c node install.js
> npm ERR! node:internal/errors:865
> npm ERR! const err = new Error(message);
> npm ERR! ^
> npm ERR!
> npm ERR! Error: Command failed:
> /home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/bin/esbuild
> --version
> npm ERR! at checkExecSyncError (node:child_process:890:11)
> npm ERR! at Object.execFileSync (node:child_process:926:15)
> npm ERR! at validateBinaryVersion
> (/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/install.js:99:28)
> npm ERR! at
> /home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/install.js:286:5
> {
> npm ERR! status: null,
> npm ERR! signal: 'SIGILL',
> npm ERR! output: [ null, Buffer(0) [Uint8Array] [], Buffer(0)
> [Uint8Array] [] ],
> npm ERR! pid: 50423,
> npm ERR! stdout: Buffer(0) [Uint8Array] [],
> npm ERR! stderr: Buffer(0) [Uint8Array] []
> npm ERR! }
> npm ERR!
> npm ERR! Node.js v18.18.0
> ```
Hi!
The last version in ports (-current) is v18.19.1, I checked (updating
my global packages) and not problem, all work fine.
--
*
Dios en su cielo, todo bien en la Tierra
nodejs/node package seems broken on openbsd 7.4 on amd64
As best i can see, node (node-18.18) is broken and cannot be used at all.
No matter the package config "npm install" results in same error:
```
npm install
npm ERR! code 1
npm ERR! path
/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild
npm ERR! command failed
npm ERR! command sh -c node install.js
npm ERR! node:internal/errors:865
npm ERR! const err = new Error(message);
npm ERR! ^
npm ERR!
npm ERR! Error: Command failed:
/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/bin/esbuild
--version
npm ERR! at checkExecSyncError (node:child_process:890:11)
npm ERR! at Object.execFileSync (node:child_process:926:15)
npm ERR! at validateBinaryVersion
(/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/install.js:99:28)
npm ERR! at
/home/kabiraatmonallabs/Garage/my-skeleton-app/node_modules/esbuild/install.js:286:5
{
npm ERR! status: null,
npm ERR! signal: 'SIGILL',
npm ERR! output: [ null, Buffer(0) [Uint8Array] [], Buffer(0)
[Uint8Array] [] ],
npm ERR! pid: 50423,
npm ERR! stdout: Buffer(0) [Uint8Array] [],
npm ERR! stderr: Buffer(0) [Uint8Array] []
npm ERR! }
npm ERR!
npm ERR! Node.js v18.18.0
```
Re: GNUstep back and base in OpenBSD 7.4 ARM
On 2024 Feb 04 (Sun) at 20:17:44 +0800 (+0800), Tito Mari Francis Escaño wrote: :Hi misc, :I was hoping to install GNUstep packages in ARM but it seems gnustep-back :and gnustep-base are not yet available in ARM. :I was under the impression that these are needed to start basic GNUstep :development. :Please advise what options are available to move forward. :Also addressed to Sebastian Reitenbach. :Thank you. Stuart already discussed armv7. On arm64 gnustep-base simply failed to build for 7.4-release packages, but it and the rest of gnustep are building just fine in -current. -- Right now I'm having amnesia and deja vu at the same time. -- Steven Wright
Re: GNUstep back and base in OpenBSD 7.4 ARM
Hi, On Sunday, February 04, 2024 13:17 CET, Tito Mari Francis Escaño wrote: > Hi misc, > I was hoping to install GNUstep packages in ARM but it seems gnustep-back > and gnustep-base are not yet available in ARM. > I was under the impression that these are needed to start basic GNUstep > development. > Please advise what options are available to move forward. > Also addressed to Sebastian Reitenbach. I don't have arm around, but if you could test as @sthen advised, or find another way to make it work, and provide a patch, I'm happy to take it. Sebastian > Thank you.
Re: GNUstep back and base in OpenBSD 7.4 ARM
On 2024-02-04, Tito Mari Francis Escaño wrote: > Hi misc, > I was hoping to install GNUstep packages in ARM but it seems gnustep-back > and gnustep-base are not yet available in ARM. > I was under the impression that these are needed to start basic GNUstep > development. gnustep's libobjc2 failed to build on arm (32-bit), and afaik all the other gnustep ports directly or indirectly depend on that. http://build-failures.rhaalovely.net/arm/2023-11-23/x11/gnustep/libobjc2.log armv7 is not a great development environment on OpenBSD, package builds are pretty slow (over a month for a bulk build) so there's a slow turnaround of finding out whether any changes result in breaking things on the arch, and not many people have machines, so not many people are able to test fixes. > Please advise what options are available to move forward. You could try fixing the libobjc2 port, there's a chance that adding -fPIC to CFLAGS might help. -- Please keep replies on the mailing list.
GNUstep back and base in OpenBSD 7.4 ARM
Hi misc, I was hoping to install GNUstep packages in ARM but it seems gnustep-back and gnustep-base are not yet available in ARM. I was under the impression that these are needed to start basic GNUstep development. Please advise what options are available to move forward. Also addressed to Sebastian Reitenbach. Thank you.
Re: SATA slow/timeouts, AMD 600 Series AHCI, OpenBSD 7.4 amd64
b...@po.cwru.edu writes: >> Divan Santana [20240131 165546 +0200]: >> >> b...@po.cwru.edu writes: >> >> > Onboard SATA seems to require additional initialization on a Gigabyte >> > B650 in OpenBSD 7.4 amd64; basic requests take minutes to complete and >> > each block read takes 30 seconds. During boot, attached SSDs will block >> > pending these requests; >> >> I have the same issue. I was hoping to install openbsd 7.4 on this new >> AMD MSI board server. >> >> This issue is quite a show stopper for me. >> >> If anyone wants some further input from me to debug this, let me know. >> >> @b...@po.cwru.edu is there any workaround? > The only user-land workaround I know is to suspend with `zzz -z`. After > resuming, the bus seems to be in a workable state. > > I've had great success with the noted kernel driver workaround, which > applies the reset during system startup. Optical drive performance has > been as expected with that workaround. OK, the zzz -z works well. After that the issue appears resolved. I just had to enable/start apmd. How can one apply your patch, so the issue is resolved on boot? Currently to boot the system takes REALLY long because of this issue and the 3 SATA drives I have in it. > Hopefully one of those will work for you, and if any OpenBSD developers > are listening, maybe one of them can see the "right" way to do this. Hope so :)
Re: SATA slow/timeouts, AMD 600 Series AHCI, OpenBSD 7.4 amd64
> Divan Santana [20240131 165546 +0200]: > > b...@po.cwru.edu writes: > > > Onboard SATA seems to require additional initialization on a Gigabyte > > B650 in OpenBSD 7.4 amd64; basic requests take minutes to complete and > > each block read takes 30 seconds. During boot, attached SSDs will block > > pending these requests; > > I have the same issue. I was hoping to install openbsd 7.4 on this new > AMD MSI board server. > > This issue is quite a show stopper for me. > > If anyone wants some further input from me to debug this, let me know. > > @b...@po.cwru.edu is there any workaround? The only user-land workaround I know is to suspend with `zzz -z`. After resuming, the bus seems to be in a workable state. I've had great success with the noted kernel driver workaround, which applies the reset during system startup. Optical drive performance has been as expected with that workaround. Hopefully one of those will work for you, and if any OpenBSD developers are listening, maybe one of them can see the "right" way to do this.
Re: SATA slow/timeouts, AMD 600 Series AHCI, OpenBSD 7.4 amd64
b...@po.cwru.edu writes: > Onboard SATA seems to require additional initialization on a Gigabyte > B650 in OpenBSD 7.4 amd64; basic requests take minutes to complete and > each block read takes 30 seconds. During boot, attached SSDs will block > pending these requests; I have the same issue. I was hoping to install openbsd 7.4 on this new AMD MSI board server. This issue is quite a show stopper for me. If anyone wants some further input from me to debug this, let me know. @b...@po.cwru.edu is there any workaround? OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:39:04 MST 2023 r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 67784667136 (64644MB) avail mem = 65710604288 (62666MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.6 @ 0xb9ad6000 (43 entries) bios0: vendor American Megatrends International, LLC. version "1.93" date 01/26/2024 bios0: Micro-Star International Co., Ltd. MS-7E26 efi0 at bios0: UEFI 2.9 efi0: American Megatrends rev 0x50020 acpi0 at bios0: ACPI 6.5 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT FIDT MCFG HPET WDRT UEFI FPDT VFCT SSDT SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS SSDT SSDT SSDT SSDT SSDT BGRT acpi0: wakeup devices GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) XHC2(S4) GPP0(S4) GPP1(S4) GPP2(S4) GPP7(S4) UP00(S4) DP48(S4) EP00(S4) DP50(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 9 7900 12-Core Processor, 3700.00 MHz, 19-61-02, patch 0a601206 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,HWPSTATE,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,L1DF,IBPB,IBRS,STIBP,STIBP_ALL,IBRS_PREF,IBRS_SM,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: AMD Ryzen 9 7900 12-Core Processor, 3700.00 MHz, 19-61-02, patch 0a601206 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,HWPSTATE,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,L1DF,IBPB,IBRS,STIBP,STIBP_ALL,IBRS_PREF,IBRS_SM,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: AMD Ryzen 9 7900 12-Core Processor, 3700.00 MHz, 19-61-02, patch 0a601206 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,HWPSTATE,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,L1DF,IBPB,IBRS,STIBP,STIBP_ALL,IBRS_PREF,IBRS_SM,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: AMD Ryzen 9 7900 12-Core Processor, 3700.00 MHz, 19-61-02, patch 0a601206 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,HWPSTATE,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX5
new releases of CPAN smoker for OpenBSD 7.4
Hello folks, I just uploaded the new releases for OpenBSD smoker on version 7.4. Here are the links: * https://app.vagrantup.com/arfreitas/boxes/openbsd-7.4-cpan-smoker-i386 * https://app.vagrantup.com/arfreitas/boxes/openbsd-7.4-cpan-smoker-amd64 Regards, Alceu
OpenBSD 7.4 USB-Tethering Google Pixel with GrapheneOS
Hi guys
Happy New Year! Hope you all started well ;-)
Unfortunately the USB-Tethering does not work on OpenBSD7.4-stable with
Google Pixel 6a or Google Pixel 8 pro, both running latest stable
GrapheneOS.
1. Laptop running OpenBSD 7.4-stable with latest patches and updates:
kern.osrelease=7.4
kern.version=OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:39:04 MST 2023
hw.machine=amd64
hw.model=Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz
hw.vendor=Hewlett-Packard
hw.product=HP EliteBook 840
2. Smartphones running latest stable GrapheneOS:
Google Pixel 6a
Google Pixel 8 pro
dmesg on OpenBSD (Pixel 6a):
ugen0 at uhub0 port 2 "Google Pixel 6a" rev 2.10/5.10 addr 7
dmesg on OpenBSD (Pixel 8 pro):
ugen0 at uhub0 port 2 "Google Pixel 8 Pro" rev 2.10/5.15 addr 7
Unfortunately no access to 'File Transfer' or 'USB tethering'.
('ifconfig' shows no additional interface and 'mtp-connect' exits with
error):
23:11 root@hp:~# mtp-connect
libmtp version: 1.1.21
Device 0 (VID=18d1 and PID=4ee1) is a Google Inc Nexus/Pixel (MTP).
libusb_detach_kernel_driver() failed, continuing anyway...: Device not
configured
Android device detected, assigning default bug flags
23:13 root@hp:~#
I tested the USB-Cable and -ports, they are working ;-)
It seems like something is missing?
Can you help me or point me into the right direction?
Please let me know if you need any further information.
Thanks a lot
Klaus
P.S. btw.
Same constellation (Multi-OS-Boot on same Laptop, same Phones, same
USB-cable) on Linux is working:
dmesg on Devuan GNU/Linux daedalus
Linux hp840 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1
(2023-12-30) x86_64 GNU/Linux
[ 2855.880610] usb 2-2: new high-speed USB device number 25 using
xhci_hcd
[ 2856.032202] usb 2-2: New USB device found,
idVendor=18d1,idProduct=4eeb, bcdDevice= 5.10[ 2856.032215] usb 2-2:
New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2856.032221] usb 2-2: Product: Pixel 6a
[ 2856.032225] usb 2-2: Manufacturer: Google
[ 2856.032229] usb 2-2: SerialNumber: 28011JEGR10193
[ 2856.058155] cdc_ncm 2-2:1.0: MAC-Address: a6:16:d2:6e:fa:eb
[ 2856.058396] cdc_ncm 2-2:1.0 usb0: register 'cdc_ncm' at usb
:00:14.0-2, CDC NCM (NO ZLP), a6:16:d2:6e:fa:eb
SATA slow/timeouts, AMD 600 Series AHCI, OpenBSD 7.4 amd64
Onboard SATA seems to require additional initialization on a Gigabyte
B650 in OpenBSD 7.4 amd64; basic requests take minutes to complete and
each block read takes 30 seconds. During boot, attached SSDs will block
pending these requests; optical drives pass that boot step quickly but
userland requests are still impacted. I narrowed down my investigation
to the AHCI source code because reads worked at speed from a FreeBSD 14
ramdisk, but also work in OBSD after a full suspend/resume (with
caveats, such as killing the video, which isn't a great solution).
I have managed to come up with a boot-time workaround in dev/ic/ahci.c
that issues a secondary ahci_port_init, as described below, but this is
the extent of my experience with this code and these device details, so
I worry about side effects and would like a result that has better
performance for these devices.
Questions:
* Recommendations for PCI SATA controllers that are known to behave
well? As a workaround; eg, I've seen lots of comments about MSI
problems on some controllers.
* Is there some commandline tool I should be using instead to reset the
AHCI ports that would be safer?
* Can I provide any additional information that might help developers
improve the sources the right way?
* Any pointer to relevant AMD documentation that might detail what's
missing from the PCI/AHCI commands at boot?
Here are the basic attempts I made that were all slow/non-responsive:
* OpenBSD 7.4 amd64 ramdisk
* OpenBSD 7.4 amd64 booted
* OpenBSD 7.4 amd64 bsd.sp
* OpenBSD 7.0 amd64 ramdisk (seven point zero)
* 'Tests' were mostly `time disklabel /dev/cd0c` (~7min),
or mount (~3min), or 1kB dd, or `atactl /dev/cd0c`
Hardware issues were ruled out:
* New optical drive tested (slow)
* Old optical drive tested (slow)
* SATA hard drives tested (slow)
* New and old SATA cables tested (slow)
* FreeBSD 14 ramdisk mounted quickly, md5 of large files nominal
More advanced attempts:
* Custom device in ahci_pci.c, combinations of: -MSI, -PMP, -NCQ, +IMPS
* Not a laptop, but apmd, `zzz -z`, and a resume showed uptime>>0min and
test commands became 'fast'! Video does not recover, and this would
not solve the boot-sequence hanging with SSDs.
* AHCI_DEBUG, and hacking in ahci.c and ahci_pci.c to get additional
behavioral information
I've worked backwards from the suspend/resume behavior and have arrived
at this kernel modification. With this change, disklabel/mount takes
0.3sec and device reads after media spin-up around ~1MB/sec; slow, but
at least responsive. This is after the devices appear in dmesg,
however, and would not work for SSDs during boot (though I have not
explicitly tested that):
*** /usr/src/sys/dev/ic/ahci.c Fri Feb 3 10:31:16 2023
--- /usr/src/sys/dev/ic/ahci.c Sun Jan 7 10:28:14 2024
***
*** 321,326
--- 321,331
sc->sc_atascsi = atascsi_attach(>sc_dev, );
+ for (i = 0; i < AHCI_MAX_PORTS; i++) {
+ if (sc->sc_ports[i] != NULL)
+ ahci_port_init(sc, i);
+ }
+
/* Enable interrupts */
ahci_write(sc, AHCI_REG_GHC, AHCI_REG_GHC_AE | AHCI_REG_GHC_IE);
It would be really nice to get better performance since this system
needs to handle lots of optical media. I can gather additional data if
it helps developers, and I'm going to look more at ahci_port_init to try
to reason about which step of that process might be making the devices
responsive. Of course what I'm doing could be completely wrong for AHCI
devices.
Many thanks in advance for guidance and ideas!
Brian
Related AHCI debug information (GENERIC.MP, full dmesg at bottom):
ahci0 at pci14 dev 0 function 0 "AMD 600 Series AHCI" rev 0x01: msi,
GHC 0x8000 AHCI 1.3.1
ahci0: capabilities
0xef36ff25, 6 ports,
32 cmds, gen 3 (6.0Gb/s)
ahci0: extended capabilities 0x3c
ahci0: ports implemented: 0x000f
ahci0.0: port reset
ahci0.1: port reset
ahci0.2: port reset
ahci0.3: port reset
ahci0: no device detected on port 0
ahci0.1: PMP probe 2
ahci0.1: sending PMP reset cmd
ahci0.1: port busy after first PMP probe FIS
ahci0.1: sending PMP probe status cmd
ahci0.1: PMP probe 1
ahci0.1: sending PMP reset cmd
ahci0.1: port busy after first PMP probe FIS
ahci0.1: sending PMP probe status cmd
ahci0.1: device is not a PMP
ahci0.1: no PMP found, resetting the port
ahci0: detected device on port 1; 0
ahci0.1: port 1: 1.5Gb/s
ahci0: no device detected on port 2
ahci0: no device detected on port 3
scsibus2 at ahci0: 32 targets
cd0 at scsibus2 targ 1 lun 0: removable
ktrace demonstrates how slow individual commands are to respond (`kdump -R`):
16659 disklabel 0.000298 CALL open(0x77e2d9e8c0,0)
16659 disklabel 0.00 NAMI "/dev/cd0c"
16659 di
Re: OpenBSD 7.4 released -- Oct 16, 2023
Just dropping a thanks for release 7.4. After used it some days I noticed an average cpu temperature almost six degrees lower than the usual one (despite the lower environment temperature of the season). == Nowarez Market
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
On Mon, Nov 27, 2023 at 11:38:01AM -0700, Theo de Raadt wrote: > Mike Larkin wrote: > > > On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: > > > Hi, > > > > > > > > > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on > > > OpenBSD 7.4. > > > > > > It seems to be doing this in the kernel. > > > > > > > > > Here is the CPU's line from top(1). > > > > > > CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 > > > > > > > > > It's always this specific CPU, and it's been draining my battery. > > > > > > How do I find what causes this? > > > > > > > > > I think that it starts doing it after waking from sleep, as it doesn't do > > > it > > > when the system is freshly started. > > > > > > But I'd need to do some tests before verifying this. > > > > > > > > > Laurent > > > > > > > Please search the list, this has been reported and solved many times, > > specifically for this machine. > > > > It is not solved. > > There is a "workaround" > > We do something wrong by not managing thunderbolt, but it is not clear > what we are supposed to do. My theory is that thunderbolt is initialized > far enough by BIOS or chipset default configuration or our driver, that > interrupts occur which we don't handle, and spin. > fair enough, that's a more accurate description.
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
Mike Larkin wrote: > On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: > > Hi, > > > > > > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on > > OpenBSD 7.4. > > > > It seems to be doing this in the kernel. > > > > > > Here is the CPU's line from top(1). > > > > CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 > > > > > > It's always this specific CPU, and it's been draining my battery. > > > > How do I find what causes this? > > > > > > I think that it starts doing it after waking from sleep, as it doesn't do it > > when the system is freshly started. > > > > But I'd need to do some tests before verifying this. > > > > > > Laurent > > > > Please search the list, this has been reported and solved many times, > specifically for this machine. > It is not solved. There is a "workaround" We do something wrong by not managing thunderbolt, but it is not clear what we are supposed to do. My theory is that thunderbolt is initialized far enough by BIOS or chipset default configuration or our driver, that interrupts occur which we don't handle, and spin.
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
On 11/27/23 13:12, Mike Larkin wrote: On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: Hi, The CPU0 on my Thinkpad 480 is always running at around 100%. It's on OpenBSD 7.4. It seems to be doing this in the kernel. Here is the CPU's line from top(1). CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 It's always this specific CPU, and it's been draining my battery. How do I find what causes this? I think that it starts doing it after waking from sleep, as it doesn't do it when the system is freshly started. But I'd need to do some tests before verifying this. Laurent Please search the list, this has been reported and solved many times, specifically for this machine. I found the solution on the Lenovo forums. It's an ACPI issue with Thunderbolt, affecting even Linux and older versions of Windows. The solution is to disable Thunderbolt in the BIOS. Security -> I/O Port Access. Laurent
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: > Hi, > > > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on > OpenBSD 7.4. > > It seems to be doing this in the kernel. > > > Here is the CPU's line from top(1). > > CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 > > > It's always this specific CPU, and it's been draining my battery. > > How do I find what causes this? > > > I think that it starts doing it after waking from sleep, as it doesn't do it > when the system is freshly started. > > But I'd need to do some tests before verifying this. > > > Laurent > Please search the list, this has been reported and solved many times, specifically for this machine.
CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
Hi, The CPU0 on my Thinkpad 480 is always running at around 100%. It's on OpenBSD 7.4. It seems to be doing this in the kernel. Here is the CPU's line from top(1). CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 It's always this specific CPU, and it's been draining my battery. How do I find what causes this? I think that it starts doing it after waking from sleep, as it doesn't do it when the system is freshly started. But I'd need to do some tests before verifying this. Laurent
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
Am Donnerstag 16 November 2023 um 15:29:27 +0100, schrieb Manuel Kuklinski 1,7K: > Until yesterday my WiFi on an iPhone 7 (iOS 15.8) was working > flawlessly; the IPv4s are statically assigned by dhcp(8). I disabled MAC > address randomization on the smartphone. As it seems, I can ping, e.g. > google.de (both IPv4 and IPv6), proof-checked with "HE.NET Network > Tools" on the smartphone. The router is running OpenBSD 7.4. Not the first time I did that, but I reset the network config of the iPhone, restarted the router and now it works :-| Pardon the noise...
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
Am Donnerstag 16 November 2023 um 20:08:16 +0100, schrieb Manuel Kuklinski 1,0K: > I opened a support ticket with Cupertino, since TCP seems to be clearly > working, according to the mentioned app - just "regular" connections can't > be openend to HTTP, IMAP et al, via TCP in different apps... "Clearly working" can be proofed with: apu# tcpdump -ni athn0 src host 10.0.0.20 - - - - - - - - - - %< - - - - - - - - - - 12:10:54.316614 10.0.0.20.50005 > 10.10.10.10.53: 9061+ A? sdf.org.(25) 12:10:54.317999 10.0.0.20.60630 > 10.10.10.10.53: 44056+ ? sdf.org.(25) 12:10:54.796151 10.0.0.20.49291 > 205.166.94.16.22: SWE 580629622:580629622(0) win 65535 (DF) 12:10:55.300692 10.0.0.20.49291 > 205.166.94.16.22: . ack 546809152 win 4117 (DF) - - - - - - - - - - %< - - - - - - - - - -
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
Am Freitag 17 November 2023 um 21:31:44 +1100, schrieb jslee 0,5K: > Are you sure your phone isn’t attempting a DNS lookup, failing and deciding > that the WiFi is pointless? As posted in a reply to my e-mail, I tested a TCP connection with "ELX TCP CLient" from the smartphone and captured with tcpdump on the gateway: - - - - - - - - - - %< - - - - - - - - - - 12:10:54.316614 10.0.0.20.50005 > 10.10.10.10.53: 9061+ A? sdf.org.(25) 12:10:54.317999 10.0.0.20.60630 > 10.10.10.10.53: 44056+ ? sdf.org.(25) 12:10:54.796151 10.0.0.20.49291 > 205.166.94.16.22: SWE 580629622:580629622(0) win 65535 (DF) 12:10:55.300692 10.0.0.20.49291 > 205.166.94.16.22: . ack 546809152 win 4117 (DF) - - - - - - - - - - %< - - - - - - - - - -
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
Am Donnerstag 16 November 2023 um 20:27:37 -0700, schrieb David Rinehart 0,7K: > Maybe... Is the clock set to the correct time on the iPhone? Yes, the clock is set to the correct time.
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
On Fri, 17 Nov 2023, at 01:29, Manuel Kuklinski wrote: > Until yesterday my WiFi on an iPhone 7 (iOS 15.8) was working > flawlessly; the IPv4s are statically assigned by dhcp(8). I disabled MAC > address randomization on the smartphone. As it seems, I can ping, e.g. > google.de (both IPv4 and IPv6), proof-checked with "HE.NET Network > Tools" on the smartphone. The router is running OpenBSD 7.4. Are you sure your phone isn’t attempting a DNS lookup, failing and deciding that the WiFi is pointless? John
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
Maybe... Is the clock set to the correct time on the iPhone? > o I tried disabling the RPZ: > no luck. > > o I tried loading /etc/examples/pf.conf: > no luck. > > o I tried re-naming the WiFi and changing the wpakey: > no luck. > > o I tried enabling and disabling encryption on my WiFi: > no luck. > > o I tried handing out different IPs / re-enabling MAC address > randomization: > no luck. > > o I tried bringing down the interface, rebooting, flushing the > routing table: > no luck. > > Any suggestions, ideas, tips, either network- or software-wise - or > is > this simply a hardware defect / support case for Cupertino? > > Best regards. >
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
On 11/16/2023 9:39 AM, Manuel Kuklinski wrote: Am Donnerstag 16 November 2023 um 8:53:10 -0700, schrieb John Brooks 2,1K: I had a similar problem a few weeks back. Turned out to be a partial failure of a network card. I could send and receive ICMP traffic, but not TCP traffic. Replaced the network card, then everything worked as expected. Was the failure on the endpoint or the gateway? The failure was an ethernet network interface card on a clients firewall protecting his internal network. PCI dual port gigabit with Intel chipset. Complete failures are fairly easy to troubleshoot, partial failures become more complicated.
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
Am Donnerstag 16 November 2023 um 17:39:36 +0100, schrieb Manuel Kuklinski 0,3K: > Am Donnerstag 16 November 2023 um 8:53:10 -0700, schrieb John Brooks 2,1K: > > I had a similar problem a few weeks back. Turned out to be a partial > > failure of a network card. I could send and receive ICMP traffic, but > > not TCP traffic. Replaced the network card, then everything worked > > as expected. > > Was the failure on the endpoint or the gateway? O.K. - I tested a TCP connection via "ELX TCP Client" to different hosts and ports; if the app isn't lying, connections can be made via TCP... Since ping is working, I guess ICMP is working too; to be safe, I purchased a second AR5BXB92 for my APU to finally rule out this error. I opened a support ticket with Cupertino, since TCP seems to be clearly working, according to the mentioned app - just "regular" connections can't be openend to HTTP, IMAP et al, via TCP in different apps... They will call me at Saturday - I'll report! Debugging such a thing on a smartphone sucks :-|
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
On 11/16/2023 7:29 AM, Manuel Kuklinski wrote: Hi misc, I quickly chatted on #openbsd over at libera and tried different solutions but none of them worked; my problem is as follows: Until yesterday my WiFi on an iPhone 7 (iOS 15.8) was working flawlessly; the IPv4s are statically assigned by dhcp(8). I disabled MAC address randomization on the smartphone. As it seems, I can ping, e.g. google.de (both IPv4 and IPv6), proof-checked with "HE.NET Network Tools" on the smartphone. The router is running OpenBSD 7.4. I can ping the local network, e.g. 10.10.10.10, but can't connect to services running on that IP - likewise I can't make outbound connections to (secure) HTTP, IMAP et al. I can connect via ethernet and WiFi to https://www.apple.com/library/test/success.html and to the mentionend, local services with my M1. The only client that has troubles connecting is the iPhone 7. I double-checked with an iPhone 8 of a relative: connection is working fine. DNS blocking with a RPZ in unbound is enforced for the whole network, but as far as I'm concerned that is not the problem since a connection is possible with the M1 & iPhone 8. Anyway - these are the steps I already checked off my list: o I tried disabling the RPZ: no luck. o I tried loading /etc/examples/pf.conf: no luck. o I tried re-naming the WiFi and changing the wpakey: no luck. o I tried enabling and disabling encryption on my WiFi: no luck. o I tried handing out different IPs / re-enabling MAC address randomization: no luck. o I tried bringing down the interface, rebooting, flushing the routing table: no luck. Any suggestions, ideas, tips, either network- or software-wise - or is this simply a hardware defect / support case for Cupertino? Best regards. I had a similar problem a few weeks back. Turned out to be a partial failure of a network card. I could send and receive ICMP traffic, but not TCP traffic. Replaced the network card, then everything worked as expected.
Re: OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
Am Donnerstag 16 November 2023 um 8:53:10 -0700, schrieb John Brooks 2,1K: > I had a similar problem a few weeks back. Turned out to be a partial > failure of a network card. I could send and receive ICMP traffic, but > not TCP traffic. Replaced the network card, then everything worked > as expected. Was the failure on the endpoint or the gateway?
OpenBSD 7.4, iOS 15.8 - sudden defunct of WiFi
Hi misc, I quickly chatted on #openbsd over at libera and tried different solutions but none of them worked; my problem is as follows: Until yesterday my WiFi on an iPhone 7 (iOS 15.8) was working flawlessly; the IPv4s are statically assigned by dhcp(8). I disabled MAC address randomization on the smartphone. As it seems, I can ping, e.g. google.de (both IPv4 and IPv6), proof-checked with "HE.NET Network Tools" on the smartphone. The router is running OpenBSD 7.4. I can ping the local network, e.g. 10.10.10.10, but can't connect to services running on that IP - likewise I can't make outbound connections to (secure) HTTP, IMAP et al. I can connect via ethernet and WiFi to https://www.apple.com/library/test/success.html and to the mentionend, local services with my M1. The only client that has troubles connecting is the iPhone 7. I double-checked with an iPhone 8 of a relative: connection is working fine. DNS blocking with a RPZ in unbound is enforced for the whole network, but as far as I'm concerned that is not the problem since a connection is possible with the M1 & iPhone 8. Anyway - these are the steps I already checked off my list: o I tried disabling the RPZ: no luck. o I tried loading /etc/examples/pf.conf: no luck. o I tried re-naming the WiFi and changing the wpakey: no luck. o I tried enabling and disabling encryption on my WiFi: no luck. o I tried handing out different IPs / re-enabling MAC address randomization: no luck. o I tried bringing down the interface, rebooting, flushing the routing table: no luck. Any suggestions, ideas, tips, either network- or software-wise - or is this simply a hardware defect / support case for Cupertino? Best regards.
Re: lilypond PDF builds broken in OpenBSD 7.4 following ghostscript-10.02.0->10.02.1 ?
On 2023-11-14, Stuart Henderson wrote: > On 2023-11-13, Jeremy Mates wrote: >> Nov 12 19:41:30 gear pkg_add: Added firefox-119.0->119.0.1 >> Nov 12 19:41:55 gear pkg_add: Added ghostscript-10.02.0->10.02.1 >> >> PDF builds fail, can someone confirm this isn't my system being wacky? > > This was fixed in -current but that hasn't been applied to -stable yet. > I think it was only identified as a build issue though it affects runtime too. > > I'll backport it. Ah I see kili@ has a diff on ports@ already.
Re: lilypond PDF builds broken in OpenBSD 7.4 following ghostscript-10.02.0->10.02.1 ?
On 2023-11-13, Jeremy Mates wrote: > Nov 12 19:41:30 gear pkg_add: Added firefox-119.0->119.0.1 > Nov 12 19:41:55 gear pkg_add: Added ghostscript-10.02.0->10.02.1 > > PDF builds fail, can someone confirm this isn't my system being wacky? This was fixed in -current but that hasn't been applied to -stable yet. I think it was only identified as a build issue though it affects runtime too. I'll backport it.
lilypond PDF builds broken in OpenBSD 7.4 following ghostscript-10.02.0->10.02.1 ?
Nov 12 19:41:30 gear pkg_add: Added firefox-119.0->119.0.1
Nov 12 19:41:55 gear pkg_add: Added ghostscript-10.02.0->10.02.1
PDF builds fail, can someone confirm this isn't my system being wacky?
$ ls test.*
test.ly
$ cat test.ly
\version "2.22.2"
\score {
{ \new Staff { e4 e e c1 } }
\layout {}
\midi {}
}
$ /usr/local/bin/lilypond test.ly
GNU LilyPond 2.22.2
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
MIDI output to `test.midi'...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `test.pdf'...
warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH
-dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-3901926)' failed (256)
fatal error: failed files: "test.ly"
If the "build PDF" bit is disabled, then no error:
$ ed test.ly
84
/lay
\layout {}
s/^/%
% \layout {}
wq
85
$ /usr/local/bin/lilypond test.ly
GNU LilyPond 2.22.2
Processing `test.ly'
Parsing...
Interpreting music...
MIDI output to `test.midi'...
Success: compilation successfully completed
$ ls test.*
test.ly test.midi
ktrace -di shows lilypond and gs chatting but nothing clear as to what or why
there was an error:
18383 gs GIO fd 2 wrote 7 bytes
"10.02.1"
42762 lilypond STRU struct pollfd [2] { fd=9,
events=0x19, revents=0<> } { fd=11, events=0x19,
revents=0x1 }
18383 gs RET write 7
42762 lilypond RET poll 1
18383 gs CALL write(2,0x7365ef51ef40,0x2)
42762 lilypond CALL read(11,0x758d0fb810a0,0x1000)
18383 gs GIO fd 2 wrote 2 bytes
": "
42762 lilypond GIO fd 11 read 25 bytes
"GPL Ghostscript 10.02.1: "
18383 gs RET write 2
42762 lilypond RET read 25/0x19
18383 gs CALL write(2,0x7365ef51ef40,0x21)
42762 lilypond CALL poll(0x758d0fb82190,2,INFTIM)
18383 gs GIO fd 2 wrote 33 bytes
"Unrecoverable error, exit code 1
"
Re: ImageMagick fails on OpenBSD 7.4 fresh install
On 2023-10-22, Mark wrote: > pkg_add ImageMagick-6.9.12.88p0 gives me; > > (after fetching few libraries) > > "Can't install ImageMagick-6.9.12.88p0: can't resolve > djvulibre-3.5.28p1,libheif-1.16.2p0" > > and then; > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 > libheif-1.16.2p0." > > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to > cdn.openbsd.org/pub/OpenBSD. > > Any other php packages were installed fine. But both pecl80-imagick-3.7.0p1 > and ImageMagick fail. > > Some idea would be much appreciated! There was an issue with the gtk-update-icon-cache update between 7.3 and 7.4 (switching from gtk+3 to gtk+4) which causes this. Try simply rerunning pkg_add -u, it has fixed things for me. -- Please keep replies on the mailing list.
Re: ImageMagick fails on OpenBSD 7.4 fresh install
Ah, sorry for my misreading what you wrote.
Please use 'sendbug' to report the sequence of pkg_add operations that
didn't work.
Philip Guenther
On Sun, Oct 22, 2023 at 5:50 PM Mark wrote:
> It wasn't an upgraded system, that's fresh install, a completely new
> OpenBSD 7.4 amd64.
>
> And the first package I wanted to install, was imagick. And it failed as on
> the screenshot image link.
>
> However, installing the "gtk-update-icon-cache" package, and after, pkg_add
> imagick solved the problem.
>
> That was the suggestion of "quinq", from IRC #openbsd. ("can you try
> installing that package, and then ImageMagick?")
>
> Philip Guenther , 23 Eki 2023 Pzt, 02:54 tarihinde
> şunu
> yazdı:
>
> > Don't know what's wrong with the pkg database (/var/db/pkg/) on your
> > system, but on mine the shared-mime-info-2.2 package includes a
> definition
> > for the update-mime-info tag, so if yours lacks that then something in
> > there got hosed during your upgrade. Could be data loss from disk
> failure,
> > could be something pruned critical info from /var/db/pkg/, could be
> > something I can't think of.
> >
> > So, I would suggest starting with verifying your confidence in your
> > storage (no kernel log error messages about I/O errors? If this machine
> > has suffered any file system issues then maybe backup, verify-backup,
> newfs
> > and restore?)
> >
> > Then I would probably reinstall *all* packages, but since I don't (fully)
> > trust the pkg database, I would probably do it with the
> > 1) pkg_info -mz > manual
> > 2) cd /var/db/pkg && pkg_delete *
> > 3) make sure nothing unexpected has been left behind in /var/db/pkg/ or
> > /usr/local/*
> > 4) pkg_add -l manual
> >
> >
> > Or maybe now's a good time to do a fresh install.
> >
> >
> > Philip Guenther
> >
> >
> > On Sun, Oct 22, 2023 at 3:34 PM Mark wrote:
> >
> >> Tried changing the installurl, an another mirror, but didn't help.
> >>
> >> Here's what actually happens;
> >>
> >> https://i.ibb.co/G0wbGf5/terminal-sshot.png
> >>
> >> Regards.
> >>
> >> Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu
> >> yazdı:
> >>
> >> > pkg_add ImageMagick-6.9.12.88p0 gives me;
> >> >
> >> > (after fetching few libraries)
> >> >
> >> > "Can't install ImageMagick-6.9.12.88p0: can't resolve
> >> > djvulibre-3.5.28p1,libheif-1.16.2p0"
> >> >
> >> > and then;
> >> > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1
> >> > libheif-1.16.2p0."
> >> >
> >> > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to
> >> > cdn.openbsd.org/pub/OpenBSD.
> >> >
> >> > Any other php packages were installed fine. But both
> >> > pecl80-imagick-3.7.0p1 and ImageMagick fail.
> >> >
> >> > Some idea would be much appreciated!
> >> >
> >> > Regards.
> >> >
> >>
> >
>
Re: ImageMagick fails on OpenBSD 7.4 fresh install
It wasn't an upgraded system, that's fresh install, a completely new
OpenBSD 7.4 amd64.
And the first package I wanted to install, was imagick. And it failed as on
the screenshot image link.
However, installing the "gtk-update-icon-cache" package, and after, pkg_add
imagick solved the problem.
That was the suggestion of "quinq", from IRC #openbsd. ("can you try
installing that package, and then ImageMagick?")
Philip Guenther , 23 Eki 2023 Pzt, 02:54 tarihinde şunu
yazdı:
> Don't know what's wrong with the pkg database (/var/db/pkg/) on your
> system, but on mine the shared-mime-info-2.2 package includes a definition
> for the update-mime-info tag, so if yours lacks that then something in
> there got hosed during your upgrade. Could be data loss from disk failure,
> could be something pruned critical info from /var/db/pkg/, could be
> something I can't think of.
>
> So, I would suggest starting with verifying your confidence in your
> storage (no kernel log error messages about I/O errors? If this machine
> has suffered any file system issues then maybe backup, verify-backup, newfs
> and restore?)
>
> Then I would probably reinstall *all* packages, but since I don't (fully)
> trust the pkg database, I would probably do it with the
> 1) pkg_info -mz > manual
> 2) cd /var/db/pkg && pkg_delete *
> 3) make sure nothing unexpected has been left behind in /var/db/pkg/ or
> /usr/local/*
> 4) pkg_add -l manual
>
>
> Or maybe now's a good time to do a fresh install.
>
>
> Philip Guenther
>
>
> On Sun, Oct 22, 2023 at 3:34 PM Mark wrote:
>
>> Tried changing the installurl, an another mirror, but didn't help.
>>
>> Here's what actually happens;
>>
>> https://i.ibb.co/G0wbGf5/terminal-sshot.png
>>
>> Regards.
>>
>> Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu
>> yazdı:
>>
>> > pkg_add ImageMagick-6.9.12.88p0 gives me;
>> >
>> > (after fetching few libraries)
>> >
>> > "Can't install ImageMagick-6.9.12.88p0: can't resolve
>> > djvulibre-3.5.28p1,libheif-1.16.2p0"
>> >
>> > and then;
>> > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1
>> > libheif-1.16.2p0."
>> >
>> > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to
>> > cdn.openbsd.org/pub/OpenBSD.
>> >
>> > Any other php packages were installed fine. But both
>> > pecl80-imagick-3.7.0p1 and ImageMagick fail.
>> >
>> > Some idea would be much appreciated!
>> >
>> > Regards.
>> >
>>
>
Re: ImageMagick fails on OpenBSD 7.4 fresh install
Don't know what's wrong with the pkg database (/var/db/pkg/) on your system, but on mine the shared-mime-info-2.2 package includes a definition for the update-mime-info tag, so if yours lacks that then something in there got hosed during your upgrade. Could be data loss from disk failure, could be something pruned critical info from /var/db/pkg/, could be something I can't think of. So, I would suggest starting with verifying your confidence in your storage (no kernel log error messages about I/O errors? If this machine has suffered any file system issues then maybe backup, verify-backup, newfs and restore?) Then I would probably reinstall *all* packages, but since I don't (fully) trust the pkg database, I would probably do it with the 1) pkg_info -mz > manual 2) cd /var/db/pkg && pkg_delete * 3) make sure nothing unexpected has been left behind in /var/db/pkg/ or /usr/local/* 4) pkg_add -l manual Or maybe now's a good time to do a fresh install. Philip Guenther On Sun, Oct 22, 2023 at 3:34 PM Mark wrote: > Tried changing the installurl, an another mirror, but didn't help. > > Here's what actually happens; > > https://i.ibb.co/G0wbGf5/terminal-sshot.png > > Regards. > > Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu > yazdı: > > > pkg_add ImageMagick-6.9.12.88p0 gives me; > > > > (after fetching few libraries) > > > > "Can't install ImageMagick-6.9.12.88p0: can't resolve > > djvulibre-3.5.28p1,libheif-1.16.2p0" > > > > and then; > > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 > > libheif-1.16.2p0." > > > > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to > > cdn.openbsd.org/pub/OpenBSD. > > > > Any other php packages were installed fine. But both > > pecl80-imagick-3.7.0p1 and ImageMagick fail. > > > > Some idea would be much appreciated! > > > > Regards. > > >
Re: ImageMagick fails on OpenBSD 7.4 fresh install
Tried changing the installurl, an another mirror, but didn't help. Here's what actually happens; https://i.ibb.co/G0wbGf5/terminal-sshot.png Regards. Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu yazdı: > pkg_add ImageMagick-6.9.12.88p0 gives me; > > (after fetching few libraries) > > "Can't install ImageMagick-6.9.12.88p0: can't resolve > djvulibre-3.5.28p1,libheif-1.16.2p0" > > and then; > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 > libheif-1.16.2p0." > > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to > cdn.openbsd.org/pub/OpenBSD. > > Any other php packages were installed fine. But both > pecl80-imagick-3.7.0p1 and ImageMagick fail. > > Some idea would be much appreciated! > > Regards. >
ImageMagick fails on OpenBSD 7.4 fresh install
pkg_add ImageMagick-6.9.12.88p0 gives me; (after fetching few libraries) "Can't install ImageMagick-6.9.12.88p0: can't resolve djvulibre-3.5.28p1,libheif-1.16.2p0" and then; "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 libheif-1.16.2p0." This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to cdn.openbsd.org/pub/OpenBSD. Any other php packages were installed fine. But both pecl80-imagick-3.7.0p1 and ImageMagick fail. Some idea would be much appreciated! Regards.
Re: OpenBSD 7.4 released -- Oct 16, 2023
Same. Preparing to upgrade. On 10/16/23 10:42, Claudio Miranda wrote: Congratulations to Theo and everyone involved in making OpenBSD 7.4 a reality and for this awesome project altogether! I also love the artwork (big thanks also to the artist that created it). so I'll be getting some 7.4 merch soon! Claudio Miranda On Mon, Oct 16, 2023 at 9:37 AM pela0 wrote: Upgrading... ;) --- Original Message --- On Monday, October 16th, 2023 at 09:53, Theo de Raadt wrote: - OpenBSD 7.4 RELEASED - October 16, 2023. We are pleased to announce the official release of OpenBSD 7.4. This is our 55th release. We remain proud of OpenBSD's record of more than twenty years with only two remote holes in the default install. As in our previous releases, 7.4 provides significant improvements, including new features, in nearly all areas of the system: - Various kernel improvements: o On arm64, show BTI and SBSS features in dmesg(8). o New kqueue1(2) system call supporting the O_CLOEXEC flag. o Map device tree read/write to unbreak root on softraid(4). o Correctly recognize umass(4) floppy disk devices as floppy disks. o In wscons(4), catch up with box drawing characters which have been standardized in unicode after the original wscons code was written and chose placeholder values. o In wscons(4), make sure we do not increase the escape sequence argument count beyond usable bounds. o Implement dt(4) utrace(2) support on amd64 and i386. o Correct undefined behavior when using MS-DOS filesystems, fixes imported from FreeBSD. o Make the softdep mount(8) option a no-op. Softdep was a significant impediment to improving the vfs layer. o Allow unveil(2)ed programs to dump core(5) into the current working directory. o Address incomplete validation of ELF program headers in execve(2). o On arm64, use the deep idle state available on Apple M1/M2 cores in the idle loop and for suspend, resulting in power savings. o Update AMD CPU microcode if a newer patch is available. o Enable a workaround for the 'Zenbleed' AMD CPU bug. o Report speculation control bits in dmesg(8) CPU lines. o To give the primary CPU an opportunity to perform clock interrupt preparation in a machine-independent manner we need to separate the "initialization" parts of cpu_initclocks() from the "start the clock interrupt" parts. Separate cpu_initclocks() from cpu_startclock(). o Fix a problem where CPU time accounting and RLIMIT_CPU was unreliable on idle systems. o Improve the output of the "show proc" command of the kernel debugger ddb(4) and show both the PID and TID of the proc. - SMP Improvements o Rewrite pfsync(4), in particular to improve locking and to help with unlocking more of pf(4) and with parallelisation of the network stack in the future. The protocol remains compatible with the older version. o Remove kernel locks from the ARP input path. o Pull MP-safe arprequest() out of kernel lock. o Remove the kernel lock from IPv6 neighbor discovery. o Unlock more parts of ioctl(2) and the routing code in the network stack. - Direct Rendering Manager and graphics drivers o Update drm(4) to Linux 6.1.55. o Don't change end marker in sg_set_page(). Caused bad memory accesses when using page flipping on Alder Lake and Raptor Lake. - VMM/VMD improvements o Allowed vmm(4) guests to enable and use supervisor IBT. o Suppressed AMD hardware p-state visibility to vmm(4) guests. o Avoid use of uninitialised memory in vmd(8). o Migrate vmd_vm.vm_ttyname to char array allowing a vmd_vm object to be transmitted over an ipc channel. o Cleaned up file descriptor closing in vmd(8) vmm process. o Fixed vm send/receive, restoring device virtqueue addresses on receive. o Introduced execvp(3) after fork for child vm processes. o No longer generate an error in vmd(8) if vm.conf(5) is absent. o Split vmm(4) into MI/MD parts. o Introduced multi-process model for vmd(8) virtio block and network devices. o Allowed vm owners to override boot kernel when using vmctl(8) to start a vm. o Changed staggered start of vms to number of online CPUs. o Fixed a segfault on vm creation. o Switched to anonymous shared memory mappings for vmd(8) vm processes, introducing a new vmm(4) ioctl(2). o Relaxed absolute path requirements for vmd(8) configtest mode (-n). o Adjusted shutdown logic by vm id to function similarly as by name. o Moved validation of local network prefixes for the internal vmd(8) DHCP service into the config parser. o Fixed QCOW2 base images when used with the vmd(8) multi-process device model. o Fixed setting verbose logging in child processes. o Fixed a race condition related to the emulated i8259 interrupt controller by ignoring interrupt masks on assert. o Inlined pending interrupts in the vmm(4) ioctl(2) for running the vcpu, reducing vm latency. o Added zero-copy, vectored io to the vmd(8) virtio bloc
Re: OpenBSD 7.4 released -- Oct 16, 2023
Awesome new release as usual and the artwork is also superb. Regards, Jean-François
Re: OpenBSD 7.4 released -- Oct 16, 2023
Wow. 55 releases. I remember starting out with OpenBSD 2.2 or 2.3 and still have the CDs in a box downstairs somewhere :) Congratulations on another fine release. I'll have to go stock up on some tshirts in a bit.
Re: OpenBSD 7.4 released -- Oct 16, 2023
Congratulations to Theo and everyone involved in making OpenBSD 7.4 a reality and for this awesome project altogether! I also love the artwork (big thanks also to the artist that created it). so I'll be getting some 7.4 merch soon! Claudio Miranda On Mon, Oct 16, 2023 at 9:37 AM pela0 wrote: > > Upgrading... > > ;) > > > > > --- Original Message --- > On Monday, October 16th, 2023 at 09:53, Theo de Raadt > wrote: > > > > > > > > > > -------- > > - OpenBSD 7.4 RELEASED - > > > > October 16, 2023. > > > > We are pleased to announce the official release of OpenBSD 7.4. > > This is our 55th release. We remain proud of OpenBSD's record of more > > than twenty years with only two remote holes in the default install. > > > > As in our previous releases, 7.4 provides significant improvements, > > including new features, in nearly all areas of the system: > > > > - Various kernel improvements: > > o On arm64, show BTI and SBSS features in dmesg(8). > > o New kqueue1(2) system call supporting the O_CLOEXEC flag. > > o Map device tree read/write to unbreak root on softraid(4). > > o Correctly recognize umass(4) floppy disk devices as floppy disks. > > o In wscons(4), catch up with box drawing characters which have been > > standardized in unicode after the original wscons code was written > > and chose placeholder values. > > o In wscons(4), make sure we do not increase the escape sequence > > argument count beyond usable bounds. > > o Implement dt(4) utrace(2) support on amd64 and i386. > > o Correct undefined behavior when using MS-DOS filesystems, fixes > > imported from FreeBSD. > > o Make the softdep mount(8) option a no-op. Softdep was a > > significant impediment to improving the vfs layer. > > o Allow unveil(2)ed programs to dump core(5) into the current > > working directory. > > o Address incomplete validation of ELF program headers in execve(2). > > o On arm64, use the deep idle state available on Apple M1/M2 cores > > in the idle loop and for suspend, resulting in power savings. > > o Update AMD CPU microcode if a newer patch is available. > > o Enable a workaround for the 'Zenbleed' AMD CPU bug. > > o Report speculation control bits in dmesg(8) CPU lines. > > o To give the primary CPU an opportunity to perform clock interrupt > > preparation in a machine-independent manner we need to separate > > the "initialization" parts of cpu_initclocks() from the "start the > > clock interrupt" parts. Separate cpu_initclocks() from > > cpu_startclock(). > > o Fix a problem where CPU time accounting and RLIMIT_CPU was > > unreliable on idle systems. > > o Improve the output of the "show proc" command of the kernel > > debugger ddb(4) and show both the PID and TID of the proc. > > > > - SMP Improvements > > o Rewrite pfsync(4), in particular to improve locking and to help > > with unlocking more of pf(4) and with parallelisation of the > > network stack in the future. The protocol remains compatible with > > the older version. > > o Remove kernel locks from the ARP input path. > > o Pull MP-safe arprequest() out of kernel lock. > > o Remove the kernel lock from IPv6 neighbor discovery. > > o Unlock more parts of ioctl(2) and the routing code in the network > > stack. > > > > - Direct Rendering Manager and graphics drivers > > o Update drm(4) to Linux 6.1.55. > > o Don't change end marker in sg_set_page(). Caused bad memory > > accesses when using page flipping on Alder Lake and Raptor Lake. > > > > - VMM/VMD improvements > > o Allowed vmm(4) guests to enable and use supervisor IBT. > > o Suppressed AMD hardware p-state visibility to vmm(4) guests. > > o Avoid use of uninitialised memory in vmd(8). > > o Migrate vmd_vm.vm_ttyname to char array allowing a vmd_vm object > > to be transmitted over an ipc channel. > > o Cleaned up file descriptor closing in vmd(8) vmm process. > > o Fixed vm send/receive, restoring device virtqueue addresses on > > receive. > > o Introduced execvp(3) after fork for child vm processes. > > o No longer generate an error in vmd(8) if vm.conf(5) is absent. > > o Split vmm(4) into MI/MD parts. > > o Introduced multi-process model for vmd(8) virtio block and network > > devices. > > o Allowed vm owners to override boot kernel when using vmctl(8) to > > start a vm. > > o Changed staggered start of vms to number of online CP
Re: OpenBSD 7.4 released -- Oct 16, 2023
Upgrading... ;) --- Original Message --- On Monday, October 16th, 2023 at 09:53, Theo de Raadt wrote: > > > > ---- > - OpenBSD 7.4 RELEASED - > > October 16, 2023. > > We are pleased to announce the official release of OpenBSD 7.4. > This is our 55th release. We remain proud of OpenBSD's record of more > than twenty years with only two remote holes in the default install. > > As in our previous releases, 7.4 provides significant improvements, > including new features, in nearly all areas of the system: > > - Various kernel improvements: > o On arm64, show BTI and SBSS features in dmesg(8). > o New kqueue1(2) system call supporting the O_CLOEXEC flag. > o Map device tree read/write to unbreak root on softraid(4). > o Correctly recognize umass(4) floppy disk devices as floppy disks. > o In wscons(4), catch up with box drawing characters which have been > standardized in unicode after the original wscons code was written > and chose placeholder values. > o In wscons(4), make sure we do not increase the escape sequence > argument count beyond usable bounds. > o Implement dt(4) utrace(2) support on amd64 and i386. > o Correct undefined behavior when using MS-DOS filesystems, fixes > imported from FreeBSD. > o Make the softdep mount(8) option a no-op. Softdep was a > significant impediment to improving the vfs layer. > o Allow unveil(2)ed programs to dump core(5) into the current > working directory. > o Address incomplete validation of ELF program headers in execve(2). > o On arm64, use the deep idle state available on Apple M1/M2 cores > in the idle loop and for suspend, resulting in power savings. > o Update AMD CPU microcode if a newer patch is available. > o Enable a workaround for the 'Zenbleed' AMD CPU bug. > o Report speculation control bits in dmesg(8) CPU lines. > o To give the primary CPU an opportunity to perform clock interrupt > preparation in a machine-independent manner we need to separate > the "initialization" parts of cpu_initclocks() from the "start the > clock interrupt" parts. Separate cpu_initclocks() from > cpu_startclock(). > o Fix a problem where CPU time accounting and RLIMIT_CPU was > unreliable on idle systems. > o Improve the output of the "show proc" command of the kernel > debugger ddb(4) and show both the PID and TID of the proc. > > - SMP Improvements > o Rewrite pfsync(4), in particular to improve locking and to help > with unlocking more of pf(4) and with parallelisation of the > network stack in the future. The protocol remains compatible with > the older version. > o Remove kernel locks from the ARP input path. > o Pull MP-safe arprequest() out of kernel lock. > o Remove the kernel lock from IPv6 neighbor discovery. > o Unlock more parts of ioctl(2) and the routing code in the network > stack. > > - Direct Rendering Manager and graphics drivers > o Update drm(4) to Linux 6.1.55. > o Don't change end marker in sg_set_page(). Caused bad memory > accesses when using page flipping on Alder Lake and Raptor Lake. > > - VMM/VMD improvements > o Allowed vmm(4) guests to enable and use supervisor IBT. > o Suppressed AMD hardware p-state visibility to vmm(4) guests. > o Avoid use of uninitialised memory in vmd(8). > o Migrate vmd_vm.vm_ttyname to char array allowing a vmd_vm object > to be transmitted over an ipc channel. > o Cleaned up file descriptor closing in vmd(8) vmm process. > o Fixed vm send/receive, restoring device virtqueue addresses on > receive. > o Introduced execvp(3) after fork for child vm processes. > o No longer generate an error in vmd(8) if vm.conf(5) is absent. > o Split vmm(4) into MI/MD parts. > o Introduced multi-process model for vmd(8) virtio block and network > devices. > o Allowed vm owners to override boot kernel when using vmctl(8) to > start a vm. > o Changed staggered start of vms to number of online CPUs. > o Fixed a segfault on vm creation. > o Switched to anonymous shared memory mappings for vmd(8) vm > processes, introducing a new vmm(4) ioctl(2). > o Relaxed absolute path requirements for vmd(8) configtest mode > (-n). > o Adjusted shutdown logic by vm id to function similarly as by name. > o Moved validation of local network prefixes for the internal vmd(8) > DHCP service into the config parser. > o Fixed QCOW2 base images when used with the vmd(8) multi-process > device model. > o Fixed setting verbose logging in child processes. > o Fixed a race condition related to the emulated i8259 interrupt > controller by ignoring interrupt masks on assert. > o Inlined pending interrupts in the vmm(4) io
OpenBSD 7.4 released -- Oct 16, 2023
- OpenBSD 7.4 RELEASED - October 16, 2023. We are pleased to announce the official release of OpenBSD 7.4. This is our 55th release. We remain proud of OpenBSD's record of more than twenty years with only two remote holes in the default install. As in our previous releases, 7.4 provides significant improvements, including new features, in nearly all areas of the system: - Various kernel improvements: o On arm64, show BTI and SBSS features in dmesg(8). o New kqueue1(2) system call supporting the O_CLOEXEC flag. o Map device tree read/write to unbreak root on softraid(4). o Correctly recognize umass(4) floppy disk devices as floppy disks. o In wscons(4), catch up with box drawing characters which have been standardized in unicode after the original wscons code was written and chose placeholder values. o In wscons(4), make sure we do not increase the escape sequence argument count beyond usable bounds. o Implement dt(4) utrace(2) support on amd64 and i386. o Correct undefined behavior when using MS-DOS filesystems, fixes imported from FreeBSD. o Make the softdep mount(8) option a no-op. Softdep was a significant impediment to improving the vfs layer. o Allow unveil(2)ed programs to dump core(5) into the current working directory. o Address incomplete validation of ELF program headers in execve(2). o On arm64, use the deep idle state available on Apple M1/M2 cores in the idle loop and for suspend, resulting in power savings. o Update AMD CPU microcode if a newer patch is available. o Enable a workaround for the 'Zenbleed' AMD CPU bug. o Report speculation control bits in dmesg(8) CPU lines. o To give the primary CPU an opportunity to perform clock interrupt preparation in a machine-independent manner we need to separate the "initialization" parts of cpu_initclocks() from the "start the clock interrupt" parts. Separate cpu_initclocks() from cpu_startclock(). o Fix a problem where CPU time accounting and RLIMIT_CPU was unreliable on idle systems. o Improve the output of the "show proc" command of the kernel debugger ddb(4) and show both the PID and TID of the proc. - SMP Improvements o Rewrite pfsync(4), in particular to improve locking and to help with unlocking more of pf(4) and with parallelisation of the network stack in the future. The protocol remains compatible with the older version. o Remove kernel locks from the ARP input path. o Pull MP-safe arprequest() out of kernel lock. o Remove the kernel lock from IPv6 neighbor discovery. o Unlock more parts of ioctl(2) and the routing code in the network stack. - Direct Rendering Manager and graphics drivers o Update drm(4) to Linux 6.1.55. o Don't change end marker in sg_set_page(). Caused bad memory accesses when using page flipping on Alder Lake and Raptor Lake. - VMM/VMD improvements o Allowed vmm(4) guests to enable and use supervisor IBT. o Suppressed AMD hardware p-state visibility to vmm(4) guests. o Avoid use of uninitialised memory in vmd(8). o Migrate vmd_vm.vm_ttyname to char array allowing a vmd_vm object to be transmitted over an ipc channel. o Cleaned up file descriptor closing in vmd(8) vmm process. o Fixed vm send/receive, restoring device virtqueue addresses on receive. o Introduced execvp(3) after fork for child vm processes. o No longer generate an error in vmd(8) if vm.conf(5) is absent. o Split vmm(4) into MI/MD parts. o Introduced multi-process model for vmd(8) virtio block and network devices. o Allowed vm owners to override boot kernel when using vmctl(8) to start a vm. o Changed staggered start of vms to number of online CPUs. o Fixed a segfault on vm creation. o Switched to anonymous shared memory mappings for vmd(8) vm processes, introducing a new vmm(4) ioctl(2). o Relaxed absolute path requirements for vmd(8) configtest mode (-n). o Adjusted shutdown logic by vm id to function similarly as by name. o Moved validation of local network prefixes for the internal vmd(8) DHCP service into the config parser. o Fixed QCOW2 base images when used with the vmd(8) multi-process device model. o Fixed setting verbose logging in child processes. o Fixed a race condition related to the emulated i8259 interrupt controller by ignoring interrupt masks on assert. o Inlined pending interrupts in the vmm(4) ioctl(2) for running the vcpu, reducing vm latency. o Added zero-copy, vectored io to the vmd(8) virtio block device. o Changed to logging vmd(8) vm ids in the vcpu run loop on error and not the ids used by vmm(4). o Fi
Re: OpenBSD 7.4
On Oct 15 11:48, Nick Holland wrote: > On 10/12/23 13:54, Karel Lucas wrote: > > Is it already known when openBSD 7.4 will be released? I would like to > > know that, because of a project I am working on. > > The answer to your question is already out there, but I offer this > procedural tip: > > IF you wish to follow releases, start your project on the PREVIOUS release. > When you think your project is complete, but before going into actual > production, do an upgrade to the active release. > > Why? Because the hardest part of most long-term projects seems to be > keeping things up-to-date. You shouldn't be putting things into > production and hoping that the upgrade process will be figured out "later", > and maximize you get to put off that "problem". The upgrade process has > to be core to the design and implementation, and should be tested before > going into production. > > This isn't an OpenBSD specific tip, either. In fact, this is easier on > OpenBSD than most Linuxes, because routine upgrades are part of the OpenBSD > mindset, unlike many linux distros, where upgrades are to be put off as > long as possible via "Long Term Support" distributions. After watching the > fiascos at every company I've ever seen "Long Term Support" Linux releases > used in, I've become absolutely convinced LTS is just a BAD IDEA and I'm > thankful OpenBSD doesn't do that. > > Nick. > This is brilliant advice. I have seen too many projects rushed into production, and later pinned to a vulnerable version of software. People do not want to take responsibility for an upgrade which will break a project. Risk continues to increase as they wait until an incident occurs.
Re: OpenBSD 7.4
On 10/12/23 13:54, Karel Lucas wrote: Is it already known when openBSD 7.4 will be released? I would like to know that, because of a project I am working on. The answer to your question is already out there, but I offer this procedural tip: IF you wish to follow releases, start your project on the PREVIOUS release. When you think your project is complete, but before going into actual production, do an upgrade to the active release. Why? Because the hardest part of most long-term projects seems to be keeping things up-to-date. You shouldn't be putting things into production and hoping that the upgrade process will be figured out "later", and maximize you get to put off that "problem". The upgrade process has to be core to the design and implementation, and should be tested before going into production. This isn't an OpenBSD specific tip, either. In fact, this is easier on OpenBSD than most Linuxes, because routine upgrades are part of the OpenBSD mindset, unlike many linux distros, where upgrades are to be put off as long as possible via "Long Term Support" distributions. After watching the fiascos at every company I've ever seen "Long Term Support" Linux releases used in, I've become absolutely convinced LTS is just a BAD IDEA and I'm thankful OpenBSD doesn't do that. Nick.
Re: OpenBSD 7.4
On Oct 13 08:03, Crystal Kolipe wrote: > > Or just wait until Monday. > Or just run -current, not wasting time on versions and release dates.
Re: OpenBSD 7.4
On Fri, Oct 13, 2023 at 10:36:43AM +, Laura Smith wrote: > Certainly by all means, track that file on CVS as the "source of truth" but > ultimately there's no certainty until it happens. For more accuracy you could try grabbing a local copy of the CVS repo with reposync and writing a script to carefully analyse the changes to every file across each release ever made, compare them to previous known release dates, do some kind of statistical analysis using a machine learning system, produce a mathematical model that approximates the mental processes of the developers involved, manually adjust the algo for known external factors then compute an estimated release date for 7.4. Or just wait until Monday.
Re: OpenBSD 7.4
> I usually track the following file. > > https://cvsweb.openbsd.org/src/etc/root/root.mail > Ironically, that file seems to support the earlier statement made by Peter Hansteen that he got shot down for (i.e. "The exact date will not be generally known until it happens if recent releases are anything to go by."). Peter was absolutely right, and the CVS shows it, the date is constantly subject to change until such point as the powers that be call time. Certainly by all means, track that file on CVS as the "source of truth" but ultimately there's no certainty until it happens.
Re: OpenBSD 7.4
On Oct 12 19:54, Karel Lucas wrote: > Is it already known when openBSD 7.4 will be released? I would like to know > that, because of a project I am working on. I usually track the following file. https://cvsweb.openbsd.org/src/etc/root/root.mail Date: Oct 16 07:04:00 MDT 2023
Re: OpenBSD 7.4
Thanks for the date, helpful and well received.. -- Daniele Bonini
Re: OpenBSD 7.4
Don't be ridiculous, there is no point to be so obtuse. The date is already visible in many files in our tree, and you know it. Oct 16. Peter N. M. Hansteen wrote: > On Thu, Oct 12, 2023 at 07:54:04PM +0200, Karel Lucas wrote: > > Is it already known when openBSD 7.4 will be released? I would like to know > > that, because of a project I am working on. > > The exact date will not be generally known until it happens if recent releases > are anything to go by. > > That said, you can be quite sure that the project has planned for > a specific date. > > Traditionally the release dates have been November 1st and May 1st, but > several times the release has been earlier, up to a couple of weeks > in some cases. > > So my advice would be to plan for November 1st as a time that release > will be available. > > And anyway it will be useful to move any not yet upgraded systems to > 7.3 ahead of that date, since 7.2 will join the ranks of no longer > supported releases the moment 7.4 becomes generally available. > > - Peter > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. >
Re: OpenBSD 7.4
On Thu, Oct 12, 2023 at 07:54:04PM +0200, Karel Lucas wrote: > Is it already known when openBSD 7.4 will be released? I would like to know > that, because of a project I am working on. The exact date will not be generally known until it happens if recent releases are anything to go by. That said, you can be quite sure that the project has planned for a specific date. Traditionally the release dates have been November 1st and May 1st, but several times the release has been earlier, up to a couple of weeks in some cases. So my advice would be to plan for November 1st as a time that release will be available. And anyway it will be useful to move any not yet upgraded systems to 7.3 ahead of that date, since 7.2 will join the ranks of no longer supported releases the moment 7.4 becomes generally available. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
OpenBSD 7.4
Is it already known when openBSD 7.4 will be released? I would like to know that, because of a project I am working on.
