Re: xenodm freezes on current

[Ronald Dahlgren]

On Mon, Aug 19, 2024 at 7:28 AM Jonathan Gray  wrote:
>
> On Mon, Aug 19, 2024 at 12:04:58PM +0100, Kevin Chadwick wrote:
> > 19 Aug 2024 02:29:39 Henry Ford :
> >
> > > Have you enabled the intel driver in xorg.conf?
> > > I had this same issue, and switching back to the default modesetting
> > > driver fixed it for me.
> >
> > I have the same issue on the latest snapshot kernel #266 on a thinkpad t410 
> > with no xorg.conf used.
> >
> > regards, kc
>
> should be fixed with rev 1.20 of
> sys/dev/pci/drm/i915/gem/i915_gem_mman.c
>
> merge error in a path used by older intel hardware
>
> just committed, not yet in snapshots
>

Thank you for the information, Jonathan.

Would you be so kind as to bump this thread when it's available in
snapshots? I'll give it a test shortly thereafter.

Ron

xenodm freezes on current

[Ronald Dahlgren]

Hello list,

Today I updated to the latest snapshot and updated all packages. When the
system rebooted, the fans started spinning full speed and the system was
totally locked. The num-lock light would not toggle.

After a hard reset, I disabled xenodm from single-user mode and rebooted.
The system boots normally. The last entry in `/var/log/messages` is
"reorder_kernel: kernel relinking done". `/var/log/Xorg.0.log` and
`/var/log/Xorg.0.log.old` are both empty.

"/var/log/daemon" shows entries from ntpd before the freeze.

"/var/log/xenodm.log" is empty and was last updated a few reboots back.

Failing a simple fix, what's the best way back to a workable system? Do a
7.5 install?

Thank you,
Ron

dmesg below
=
OpenBSD 7.6-beta (GENERIC.MP ) #260: Sat Aug 17
22:18:53 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 17032646656 (16243MB)
avail mem = 16493068288 (15729MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xc9764000 (56 entries)
bios0: vendor HP version "P21 Ver. 02.46" date 03/28/2023
bios0: HP HP EliteDesk 800 G3 DM 35W
efi0 at bios0: UEFI 2.5
efi0: HP rev 0x2002e
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT UEFI SSDT TPM2 SSDT MSDM SLIC WSMT HPET APIC
MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT ASF! FPDT BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz, 2693.73 MHz, 06-5e-03,
patch 00f0
cpu0: cpuid 1
edx=bfebfbff
ecx=77fafbff
cpu0: cpuid 6 eax=27f7 ecx=9
cpu0: cpuid 7.0
ebx=29c6fbf
edx=bc002e00
cpu0: cpuid a vers=4, gp=4, gpwidth=48, ff=3, ffwidth=48
cpu0: cpuid d.1 eax=f
cpu0: cpuid 8001 edx=2c100800
ecx=121
cpu0: cpuid 8007 edx=100
cpu0: msr 10a=c04
cpu0: MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz, 2693.73 MHz, 06-5e-03,
patch 00f0
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz, 2693.73 MHz, 06-5e-03,
patch 00f0
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz, 2693.73 MHz, 06-5e-03,
patch 00f0
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz, 2693.73 MHz, 06-5e-03,
patch 00f0
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz, 2693.73 MHz, 06-5e-03,
patch 00f0
cpu5: smt 1, core 1, package 0
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz, 2693.73 MHz, 06-5e-03,
patch 00f0
cpu6: smt 1, core 2, package 0
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz, 2693.73 MHz, 06-5e-03,
patch 00f0
cpu7: smt 1, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus -1 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus -1 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpiec0 at acpi0: not present
acpiec1 at acpi0
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
"PNP0A06" at acpi0 not configured
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
tpm0 at acpi0 TPM_ 2.0 (TIS) addr 0

Re: Hard freeze during `pkg_add -u` on -current

[Ronald Dahlgren]

Thank you for the reply, Stuart.

Running pkg_check startout out fine and then went off the rails. The output
is captured here -> https://sw.gy/files/pkg_check.html

The control characters passed through xterm and a clipboard so they may not
be accurate. Here are some screenshots of the original:

https://sw.gy/files/pkg_check-1.png
https://sw.gy/files/pkg_check-2.png

Thankfully this behavior did not crash the system :)

Ron

On Fri, Jul 5, 2024 at 12:33 PM Stuart Henderson 
wrote:

> On 2024-07-05, Ronald Dahlgren  wrote:
> > --cbf9af061c80339e
> > Content-Type: text/plain; charset="UTF-8"
> > Content-Transfer-Encoding: quoted-printable
> >
> > Hello,
> >
> > On July 2nd, I updated a machine to the latest snapshot and rebooted. It
> > came back without issue. I then issued `pkg_add -U`. This machine was
> last
> > updated on June 6th, so not terribly long ago. Partway during the
> process,
> > the disk indicated it was full (not true) and no commands were available
> > (ls, cd, etc). Unable to do anything, I terminated my SSH session and
> > attempted to reconnect. The machine failed to respond to pings. I had
> > someone onsite reboot the machine. It then came back up. I did not try
> the
> > `pkg_add -u` command again. Inspection showed that partitions had plenty
> of
> > available space and inodes.
> >
> > The daily insecurity output that ran the following day, on Wednesday the
> > 3rd, had this unusual snippet:
> >
> > ```
> > vmm-firmware-1.16.3p0 firmware binary images for vmm(4) driver
> > -xz-5.4.5library and tools for XZ and LZMA compressed files
> > +xz-5.6.2
> > /??^L???.???/?..??/??$???+DESC???/?
> >
> +CONTENTS0^L+REQUIRED_BY??=
> >
> ???=
> >
> ???=
> >
> ???=
> >
> ???=
> > ??
> >  zsh-5.9p0   Z shell, Bourne shell-compatible
> > ```
>
> The filesystem holding /var/db/pkg has some corruption.
> I'd try running pkg_check and allow it to repair, reinstall xz
> "pkg_add -r -D installed xz", and see how you get on.
>
> > Given the package with the wacky description is `xz`, I'm more concerned
> > than I would be otherwise.
>
> The same could have happened to any package, there's nothing special
> about xz there.
>
> > I can see in `/var/log/messages` the snapshot update occurred without
> > issue. Logs after the physical reboot show no core dump and only have
> > complaints about filesystems not being properly unmounted - expected when
> > the plug is pulled.
> >
> > Are there any other logs I can check and share to help get to the bottom
> of
> > this? The impacted computer has been running current and humming along
> > happily in a network closet for over a year.
>
> Not sure about the disk full message (spurious seems unlikely - if space
> is ok, is some filesystem tight on inodes? df -hi) or the hang.
>
> --
> Please keep replies on the mailing list.
>
>

Hard freeze during `pkg_add -u` on -current

[Ronald Dahlgren]

Hello,

On July 2nd, I updated a machine to the latest snapshot and rebooted. It
came back without issue. I then issued `pkg_add -U`. This machine was last
updated on June 6th, so not terribly long ago. Partway during the process,
the disk indicated it was full (not true) and no commands were available
(ls, cd, etc). Unable to do anything, I terminated my SSH session and
attempted to reconnect. The machine failed to respond to pings. I had
someone onsite reboot the machine. It then came back up. I did not try the
`pkg_add -u` command again. Inspection showed that partitions had plenty of
available space and inodes.

The daily insecurity output that ran the following day, on Wednesday the
3rd, had this unusual snippet:

```
vmm-firmware-1.16.3p0 firmware binary images for vmm(4) driver
-xz-5.4.5library and tools for XZ and LZMA compressed files
+xz-5.6.2
 /??^L???.???/?..??/??$???+DESC???/?
 
+CONTENTS0^L+REQUIRED_BY
 zsh-5.9p0   Z shell, Bourne shell-compatible
```

Given the package with the wacky description is `xz`, I'm more concerned
than I would be otherwise.

I can see in `/var/log/messages` the snapshot update occurred without
issue. Logs after the physical reboot show no core dump and only have
complaints about filesystems not being properly unmounted - expected when
the plug is pulled.

Are there any other logs I can check and share to help get to the bottom of
this? The impacted computer has been running current and humming along
happily in a network closet for over a year.

Respectfully,
Ron

Working towards numpy 2.0 support

[Ronald Dahlgren]

I've made incremental progress in getting numpy 2.0 to build and install on
current. Today, older versions must be used as the latest fails during
installation with a compilation problem.

I'm happy to report the first of those dependent items has been updated -
x86-simd-sort. Pull request 157 (
https://github.com/intel/x86-simd-sort/pull/157) adds conditional
compilation flags for our type sizes as well as being behind on Clang major
versions.

If anyone else is working on numpy 2.0 support or has already gone down
this path, I would be happy to coordinate to fix all the upstream
dependencies.

Note that even with this fix in place, numpy still fails. I will report
back when more progress is made.

Respectfully,
Ron

Re: Updated Operations Research tools

[Ronald Dahlgren]

Thank you for the note, Michel.

The software packages I mentioned are not yet packaged for use with the
OpenBSD package manager. Instead, they are now able to be built on OpenBSD.
I hope the Google or-tools package will be posted for Python. The others
will need to be added as ports.


On Sat, Jun 15, 2024 at 12:57 PM Michel von Behr 
wrote:

> Thank you Ronald! Ive been exploring Operations Research tools every now
> and then, always relying on Linux; great to know we have some of those
> tools in OpenBSD as packages, will definitely take a look in the future.
>
> I'm running -current, far from being a "guru" in OR and OpenBSD, but if
> you need some help with testing in the future let me know.
>
> Regards
>
> Michel
>
> On Mon, 10 Jun 2024 at 10:00 PM Ronald Dahlgren 
> wrote:
>
>> I am excited to announce a number of software packages that have been
>> updated to work on OpenBSD.
>>
>> 1. COIN-OR (coin-or.org) - The CBC solver was failing to build due to a
>> casting error. Pull request 653 (https://github.com/coin-or/Cbc/pull/653)
>> corrects this issue;
>> 2. HiGHS solver (https://ergo-code.github.io/HiGHS/stable/) - failed to
>> build due to the `strerror_r` prototype. Pull request 1783 (
>> https://github.com/ERGO-Code/HiGHS/pull/1783) corrects this.
>> 3. Google or-tools (https://developers.google.com/optimization/) -
>> several compilation issues prevented building the associated Python
>> package. Pull requests 4257 (https://github.com/google/or-tools/pull/4257),
>> 4259 (https://github.com/google/or-tools/pull/4259), and 4266 (
>> https://github.com/google/or-tools/pull/4266) correct each of these
>> problems.
>>
>> With these changes introduced, we can now run the relevant solvers and
>> python packages on an OpenBSD system! I'm so happy I was able to give back
>> to the OpenBSD community in this way.
>>
>> Ron
>>
>

Updated Operations Research tools

[Ronald Dahlgren]

I am excited to announce a number of software packages that have been
updated to work on OpenBSD.

1. COIN-OR (coin-or.org) - The CBC solver was failing to build due to a
casting error. Pull request 653 (https://github.com/coin-or/Cbc/pull/653)
corrects this issue;
2. HiGHS solver (https://ergo-code.github.io/HiGHS/stable/) - failed to
build due to the `strerror_r` prototype. Pull request 1783 (
https://github.com/ERGO-Code/HiGHS/pull/1783) corrects this.
3. Google or-tools (https://developers.google.com/optimization/) - several
compilation issues prevented building the associated Python package. Pull
requests 4257 (https://github.com/google/or-tools/pull/4257), 4259 (
https://github.com/google/or-tools/pull/4259), and 4266 (
https://github.com/google/or-tools/pull/4266) correct each of these
problems.

With these changes introduced, we can now run the relevant solvers and
python packages on an OpenBSD system! I'm so happy I was able to give back
to the OpenBSD community in this way.

Ron

Re: iridium core dumps on current

[Ronald Dahlgren]

Following up on the above, on current with the most recent version of all
packages, the initial attempt to start iridium core dumps with the
following:

```
[rdahlgren@builder :: ~] $ iridium
[59856:-1030190016:1120/113635.371153:ERROR:bus.cc(407)] Failed to connect
to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No
such file or directory
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: MESA-LOADER: failed to open i915: Cannot load specified object
(search paths /usr/X11R6/lib/modules/dri, suffix _dri)
libGL error: failed to load driver: i915
libGL error: failed to open /dev/dri/card0: No such file or directory
libGL error: failed to load driver: i965
libGL error: MESA-LOADER: failed to open swrast: Cannot load specified
object (search paths /usr/X11R6/lib/modules/dri, suffix _dri)
libGL error: failed to load driver: swrast
zsh: trace trap (core dumped)  iridium
```

Note that chromium works without issue, firefox works, and glxgears works.

I've emailed the iridium maintainer as well but have not received a
response.

Ron

On Fri, Nov 3, 2023 at 6:35 PM Ronald Dahlgren 
wrote:

> Hello,
>
> I'm running  7.4 GENERIC.MP#1440 amd64 and the latest iridium package,
> iridium-2023.10.118. Lately, iridium has been failing to start, immediately
> dying with a core dump:
> ```
> [rdahlgren@ranger2 :: ~] $ iridium
> [89014:-471097792:1103/183201.949947:ERROR:bus.cc(407)] Failed to connect
> to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No
> such file or directory
> zsh: trace trap (core dumped)  iridium
> ```
>
> Note that if the messagebus service is started, the dbus error goes away
> but the core dump still occurs. This has been happening for at least a
> week, across the intervening snapshots and package updates.
>
> How can I collect more information to identify the problem? Nothing
> relevant appears in /var/log/messages
>
> Respectfully,
> Ron
>
> --
> RD
>
>


-- 
RD

Re: Pimp my APU

[Ronald Dahlgren]

I’ve got several APUs and a couple Alix boards. The s1 button should work
as a power / reset button out of the box.



On Fri, Nov 10, 2023 at 6:54 PM Anders Andersson  wrote:

> I'm running OpenBSD on my (recently EOL) APU4 and I'm wondering how
> much of the "extra" hardware is expected to work on OpenBSD.
>
> 1) On the back of the board is a button "S1" and three status LEDs,
> The documentation says they are handled by the AMD FCH south bridge.
> Is there a way to control these in software from OpenBSD?
>
> 2) There are 16 additional GPIO on a header, via the Nuvoton NCT5104D
> chip on the LPC bus. I've seen a few patches circulating that mentions
> gpio and the wbsio(4) driver but I could not figure out if anything
> has been committed or not.
>
> 3) There is a simple watchdog timer in the NCT5104D that can be
> connected to the reset line. Would this be implemented? I'm not sure
> it's really useful, I assume there's an integrated watchdog in the
> CPU.
>
> Would be interested in hearing from any OpenBSD APUx user who put
> these to good use!
>
> // Anders
>
>

Understanding -current as 7.4 is released

[Ronald Dahlgren]

Hello friends,

I’ve been running -current for several months now. Recently I started using
“-D snap” when updating packages with pkg_add.

I ask the list to help me understand what, if anything, I need to do with
my machines that run snapshots when 7.4 is released. Will I need to perform
the upgrade procedures differently? Is the release just a blessed snapshot
and everything will continue to work as-is?

Thank you,
Ron

Re: Installer loop on apu6b4

[Ronald Dahlgren]

On Wed, Aug 2, 2023 at 9:04 PM Chris Cappuccio  wrote:

>
> This should be an FAQ entry.
>
> You need to setup the serial console in the boot blocks:
> boot> stty com0 115200
> boot> set tty com0
>
> Chris


That solved the problem. Thank you, Chris. Apologies to the list.

>
> --
RD

Installer loop on apu6b4

[Ronald Dahlgren]

I have a PC Engines apu6b4 that is acting up during the installation
process. I want to see if this group has any insight before I try an RMA
with the seller.

The apu6b4 (https://www.pcengines.ch/apu6b4.htm) runs an AMD processor and
has the standard ports. It uses a micro-USB serial port rather than an
RS-232 interface. When loading the 7.3 release installer, I get to a point
where "entry point at 0x8100100" is printed before the device loads
the BIOS and starts the POST / boot process again. There isn't much output
to use for clues.

I run current on an apu2, so I'm wondering if it's the apu6b4 model
generally or just my example that is the problem.

For comparison, I tried loading Debian stable as well and found that it got
partially into the text installer before appearing to hang when I selected
a "video" mode. Note that I've never done a serial console installation of
Debian. It may be expected behavior.

Does anyone have guidance on how to proceed with investigating the problem?
Has anyone run OpenBSD on the apu6b4?

Here are some relevant screenshots:

https://star.sw.gy/pub/boot-loop-1.png
https://star.sw.gy/pub/boot-loop-2.png
https://star.sw.gy/pub/debian-installer-1.png
https://star.sw.gy/pub/debian-installer-2.png

Here's the captured output from the boot loop I mentioned:

SeaBIOS (version rel-1.12.1.3-0-g300e8b70)

Press F10 key now for boot menu

Booting from Hard Disk...
Using drive 0, partition 3.
Loading..
probing: pc0 com0 com1 mem[639K 3325M 752M a20=on]
disk: hd0+ hd1+*
>> OpenBSD/amd64 BOOT 3.55
boot>
cannot open hd0a:/etc/random.seed: No such file or directory
booting hd0a:/7.3/amd64/bsd.rd: 3924676+1647616+3886216+0+704512
[109+440424+293
778]=0xa667f0
entry point at 0x8100100PC Engines apu6
coreboot build 20202509
BIOS version v4.12.0.

-- 
RD

Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches

[Ronald Dahlgren]

For what it’s worth, my Vultr VPS machine is running snapshots and updated
without issue.

Hope this helps as a clue!

On Tue, Jul 25, 2023 at 10:45 AM Theo de Raadt  wrote:

> It seems some of the smaller hypervisor companies didn't get the memo,
> and they are blocking the msr write to to set the chicken bit.
>
> They block it by raising an exception.
> They should IGNORE that bit if they allow setting it.
>
> I also have a strong suspicion some of them do not have the firmware
> fixes, and that the chickenbit-off state we read is true.
>
> Anyways, a brand new errata to skip setting the chickenbit on such
> hypervisors is going out the door right now.
>
>
> --
RD