Re: Sudden reboot every 5-10 minutes on latest snapshot

[Ali Farzanrad]

Ali Farzanrad  wrote:
> Thomas Frohwein  wrote:
> > On Sat, May 25, 2024 at 12:06:39PM +0000, Ali Farzanrad wrote:
> > > Ali Farzanrad  wrote:
> > > > Alexandre Ratchov  wrote:
> > > > > On Fri, May 24, 2024 at 09:04:29PM +, Ali Farzanrad wrote:
> > > > > > Alexandre Ratchov  wrote:
> > > > > > > On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote:
> > 
> > [...]
> > 
> > > > I have another problem here.  My USB keyboard works great in BOOTX64.EFI
> > > > but will not work on kernel config.
> > > > 
> > > > I created /etc/bsd.re-config file and rebooted my system twice to
> > > > disable azalia and then checked if it is disabled using config(8) and
> > > > dmesg(8).
> > > > 
> > > > Even when azalia is disabled my system gets sudden reboots.
> > > > First sudden reboot was just after playing a music; but next 2 reboots
> > > > was happened without playing anything.
> > > > 
> > > > > Then, just do your regular stuff and see if the system reboots.
> > > 
> > > I tested again with my patch.  When azalia is disabled, it suddenly
> > > reboots after few minutes, without playing anything.  When azalia is
> > > enabled, it lives.
> > > 
> > 
> > This looks to me like you are chasing down a new rabbit hole every time
> > I open one of your emails. I'd suggest you take a step back from all
> > the stuff you seem to be trying without having a firm grasp on how to
> > observe or report reproducibility. Have you tried out sthen@'s advice
> > to check old kernels + snapshots[1]? I may have missed your response to
> > this. You wrote that you rarely got the issue prior 17-May-2024? If
> > that *is correct*, then you should be able to bisect using the snapshot
> > archive around what date things change.
> 
> Actually I see some kind of sudden reboots for such a long time (maybe
> since the time I have this mini pc) which happen almost certainly on
> every boot after a long shutdown!
> 
> It is funny that my Windows 11 don't get those reboots; so I usually
> use Windows for an hour, then reboot to OpenBSD without facing those
> sudden reboots.
> 
> Anyway, I tested this snapshot for few days:
> https://ftp.hostserver.de/archive/2024-05-20-0105
> 
> I only get sudden reboots after a long shutdown (for example boot after
> 3 hours off); however using the next snapshot:
> https://ftp.hostserver.de/archive/2024-05-21-0105
> 
> I saw this other kind of sudden reboots which might happen after every
> boot/reboot (not just after a long shutdown).
> 
> > I am highlighting *is correct* above because your issue seems to be
> > unpredictable enough that a few minutes of testing don't mean anything.
> > I suggest you try to find a *clear difference*, meaning between a
> > snapshot where no reboot happens for ideally a whole day of use, and
> > the next one where it clearly happens very quickly (and reproducible
> > at least a second or third time).
> 
> I couldn't find a snapshot without any sudden reboot at all.
> 
> > Your reports also make me wonder how much customization you are
> > running. You've mentioned at least compiling custom kernels and
> > setting bsd.re-config. It's easy to find yourself in virtually
> > unsolvable scenarios by configuring too much. It might be best to try
> > a clean install, ideally without activating xenodm/X11.
> 
> The bsd.re-config file was just for disabling azalia.
> I have FDE using softraid level C without swap and /tmp mounted as mfs.
> I don't think that I configured too much.
> 
> Anyway, I also tested those snapshots on a clean install on a single
> partition outside softraid and again without swap (I don't like swap);
> I see similar results.
> 
> I also disabled xenodm/X11 and see my OpenBSD lived for more than an
> hour, then I started xenodm and it suddenly rebooted in less than 3
> minutes.
> 
> I didn't test OpenBSD without xenodm/X11 much, because I need them;
> that's why I disabled amdgpu and placed it in my bsd.re-config file.
> Since then (~3 days) I see no single sudden reboot at all (not even

I'm really sorry.  My whole snapshot tests takes about 3 days.  I tested
2024-05-20-0105 snapshot for about 2 days, and 2024-05-21-0105 snapshot
with disabled amdgpu and then latest snapshot with disabled amdgpu
together for about 1 day.

> after a long shutdown).
> 
> I'm currenly on latest snapshot with amdgpu disabled.
> 
> Alexandre Ratchov  wrote:
> > On Sat, May 25, 2024 at 09:13:56AM +, Ali Farzanrad wrote:
>

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Ali Farzanrad]

Thomas Frohwein  wrote:
> On Sat, May 25, 2024 at 12:06:39PM +0000, Ali Farzanrad wrote:
> > Ali Farzanrad  wrote:
> > > Alexandre Ratchov  wrote:
> > > > On Fri, May 24, 2024 at 09:04:29PM +, Ali Farzanrad wrote:
> > > > > Alexandre Ratchov  wrote:
> > > > > > On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote:
> 
> [...]
> 
> > > I have another problem here.  My USB keyboard works great in BOOTX64.EFI
> > > but will not work on kernel config.
> > > 
> > > I created /etc/bsd.re-config file and rebooted my system twice to
> > > disable azalia and then checked if it is disabled using config(8) and
> > > dmesg(8).
> > > 
> > > Even when azalia is disabled my system gets sudden reboots.
> > > First sudden reboot was just after playing a music; but next 2 reboots
> > > was happened without playing anything.
> > > 
> > > > Then, just do your regular stuff and see if the system reboots.
> > 
> > I tested again with my patch.  When azalia is disabled, it suddenly
> > reboots after few minutes, without playing anything.  When azalia is
> > enabled, it lives.
> > 
> 
> This looks to me like you are chasing down a new rabbit hole every time
> I open one of your emails. I'd suggest you take a step back from all
> the stuff you seem to be trying without having a firm grasp on how to
> observe or report reproducibility. Have you tried out sthen@'s advice
> to check old kernels + snapshots[1]? I may have missed your response to
> this. You wrote that you rarely got the issue prior 17-May-2024? If
> that *is correct*, then you should be able to bisect using the snapshot
> archive around what date things change.

Actually I see some kind of sudden reboots for such a long time (maybe
since the time I have this mini pc) which happen almost certainly on
every boot after a long shutdown!

It is funny that my Windows 11 don't get those reboots; so I usually
use Windows for an hour, then reboot to OpenBSD without facing those
sudden reboots.

Anyway, I tested this snapshot for few days:
https://ftp.hostserver.de/archive/2024-05-20-0105

I only get sudden reboots after a long shutdown (for example boot after
3 hours off); however using the next snapshot:
https://ftp.hostserver.de/archive/2024-05-21-0105

I saw this other kind of sudden reboots which might happen after every
boot/reboot (not just after a long shutdown).

> I am highlighting *is correct* above because your issue seems to be
> unpredictable enough that a few minutes of testing don't mean anything.
> I suggest you try to find a *clear difference*, meaning between a
> snapshot where no reboot happens for ideally a whole day of use, and
> the next one where it clearly happens very quickly (and reproducible
> at least a second or third time).

I couldn't find a snapshot without any sudden reboot at all.

> Your reports also make me wonder how much customization you are
> running. You've mentioned at least compiling custom kernels and
> setting bsd.re-config. It's easy to find yourself in virtually
> unsolvable scenarios by configuring too much. It might be best to try
> a clean install, ideally without activating xenodm/X11.

The bsd.re-config file was just for disabling azalia.
I have FDE using softraid level C without swap and /tmp mounted as mfs.
I don't think that I configured too much.

Anyway, I also tested those snapshots on a clean install on a single
partition outside softraid and again without swap (I don't like swap);
I see similar results.

I also disabled xenodm/X11 and see my OpenBSD lived for more than an
hour, then I started xenodm and it suddenly rebooted in less than 3
minutes.

I didn't test OpenBSD without xenodm/X11 much, because I need them;
that's why I disabled amdgpu and placed it in my bsd.re-config file.
Since then (~3 days) I see no single sudden reboot at all (not even
after a long shutdown).

I'm currenly on latest snapshot with amdgpu disabled.

Alexandre Ratchov  wrote:
> On Sat, May 25, 2024 at 09:13:56AM +, Ali Farzanrad wrote:
> > 
> > Even when azalia is disabled my system gets sudden reboots.
> > First sudden reboot was just after playing a music; but next 2 reboots
> > was happened without playing anything.
> > 
> 
> This suggests the reboots are not directly caused by the azalia's msi
> vs old-style interrupts.
> 
> I'd suggest that you find and old enough snapshot (or release) that
> used to work reliably on this machine and make sure it still works
> reliably with the old software version. Not just an hour, use it few
> days for real work.

As I said above, I couldn't find such reliable snapshot.  I only get
reliably using disabled amdgpu, or (I didn't test this much) disabled
xenodm/

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Ali Farzanrad]

Ali Farzanrad  wrote:
> Alexandre Ratchov  wrote:
> > On Fri, May 24, 2024 at 09:04:29PM +0000, Ali Farzanrad wrote:
> > > Alexandre Ratchov  wrote:
> > > > On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote:
> > > > > Hi again,
> > > > > 
> > > > > During my tests it seems that this version of kernel works fine:
> > > > > 
> > > > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src
> > > > > 
> > > > > But this version of kernel will cause sudden reboots without any 
> > > > > kernel
> > > > > panic or message after 5-60 minutes in my Minisforum UM790:
> > > > > 
> > > > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src
> > > > > 
> > > > > After investigation I found this patch could fix my problem:
> > > > > 
> > > > > Index: azalia.c
> > > > > ===
> > > > > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
> > > > > diff -u -p -r1.287 azalia.c
> > > > > --- azalia.c  17 May 2024 19:43:45 -  1.287
> > > > > +++ azalia.c  24 May 2024 16:26:38 -
> > > > > @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
> > > > >   azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
> > > > >   }
> > > > >  
> > > > > + /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
> > > > > + if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
> > > > > + switch (PCI_PRODUCT(sc->pciid)) {
> > > > > + case PCI_PRODUCT_AMD_17_HDA:
> > > > > + case PCI_PRODUCT_AMD_17_1X_HDA:
> > > > > + case PCI_PRODUCT_AMD_HUDSON2_HDA:
> > > > > + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
> > > > > + }
> > > > > + }
> > > > > +
> > > > >   /* interrupt */
> > > > >   if (pci_intr_map_msi(pa, ) && pci_intr_map(pa, )) {
> > > > >   printf(": can't map interrupt\n");
> > > > > 
> > > > > However it breaks my front 3.5mm audio port and I should use my
> > > > > USB-to-3.5mm audio port adapter again.
> > > > > 
> > > > > How may I investigate more?
> > > > > 
> > > > 
> > > > could you confirm that the system reboots only while you're using the
> > > > azalia device?
> > > 
> > > I disabled sndiod, and unplugged my USB-to-3.5mm audio adapter and also
> > > unplugged front 3.5mm audio port, then reboot my OpenBSD and waited on
> > > xenodm login screen for few minutes; most of the time it reboots in
> > > less than 10 minutes... without any interaction from me, or playing
> > > anything...
> > > 
> > 
> > Could you disable the azalia driver and redo your test? reboot, then
> > on the boot(8) prompt type "boot -c", then "disable azalia", then
> > "quit".
> 
> I have another problem here.  My USB keyboard works great in BOOTX64.EFI
> but will not work on kernel config.
> 
> I created /etc/bsd.re-config file and rebooted my system twice to
> disable azalia and then checked if it is disabled using config(8) and
> dmesg(8).
> 
> Even when azalia is disabled my system gets sudden reboots.
> First sudden reboot was just after playing a music; but next 2 reboots
> was happened without playing anything.
> 
> > Then, just do your regular stuff and see if the system reboots.

I tested again with my patch.  When azalia is disabled, it suddenly
reboots after few minutes, without playing anything.  When azalia is
enabled, it lives.

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Ali Farzanrad]

Alexandre Ratchov  wrote:
> On Fri, May 24, 2024 at 09:04:29PM +0000, Ali Farzanrad wrote:
> > Alexandre Ratchov  wrote:
> > > On Fri, May 24, 2024 at 04:30:52PM +0000, Ali Farzanrad wrote:
> > > > Hi again,
> > > > 
> > > > During my tests it seems that this version of kernel works fine:
> > > > 
> > > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src
> > > > 
> > > > But this version of kernel will cause sudden reboots without any kernel
> > > > panic or message after 5-60 minutes in my Minisforum UM790:
> > > > 
> > > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src
> > > > 
> > > > After investigation I found this patch could fix my problem:
> > > > 
> > > > Index: azalia.c
> > > > ===
> > > > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
> > > > diff -u -p -r1.287 azalia.c
> > > > --- azalia.c17 May 2024 19:43:45 -  1.287
> > > > +++ azalia.c24 May 2024 16:26:38 -
> > > > @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
> > > > azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
> > > > }
> > > >  
> > > > +   /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
> > > > +   if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
> > > > +   switch (PCI_PRODUCT(sc->pciid)) {
> > > > +   case PCI_PRODUCT_AMD_17_HDA:
> > > > +   case PCI_PRODUCT_AMD_17_1X_HDA:
> > > > +   case PCI_PRODUCT_AMD_HUDSON2_HDA:
> > > > +   pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
> > > > +   }
> > > > +   }
> > > > +
> > > > /* interrupt */
> > > > if (pci_intr_map_msi(pa, ) && pci_intr_map(pa, )) {
> > > > printf(": can't map interrupt\n");
> > > > 
> > > > However it breaks my front 3.5mm audio port and I should use my
> > > > USB-to-3.5mm audio port adapter again.
> > > > 
> > > > How may I investigate more?
> > > > 
> > > 
> > > could you confirm that the system reboots only while you're using the
> > > azalia device?
> > 
> > I disabled sndiod, and unplugged my USB-to-3.5mm audio adapter and also
> > unplugged front 3.5mm audio port, then reboot my OpenBSD and waited on
> > xenodm login screen for few minutes; most of the time it reboots in
> > less than 10 minutes... without any interaction from me, or playing
> > anything...
> > 
> 
> Could you disable the azalia driver and redo your test? reboot, then
> on the boot(8) prompt type "boot -c", then "disable azalia", then
> "quit".

I have another problem here.  My USB keyboard works great in BOOTX64.EFI
but will not work on kernel config.

I created /etc/bsd.re-config file and rebooted my system twice to
disable azalia and then checked if it is disabled using config(8) and
dmesg(8).

Even when azalia is disabled my system gets sudden reboots.
First sudden reboot was just after playing a music; but next 2 reboots
was happened without playing anything.

> Then, just do your regular stuff and see if the system reboots.

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Ali Farzanrad]

Alexandre Ratchov  wrote:
> On Fri, May 24, 2024 at 04:30:52PM +0000, Ali Farzanrad wrote:
> > Hi again,
> > 
> > During my tests it seems that this version of kernel works fine:
> > 
> > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src
> > 
> > But this version of kernel will cause sudden reboots without any kernel
> > panic or message after 5-60 minutes in my Minisforum UM790:
> > 
> > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src
> > 
> > After investigation I found this patch could fix my problem:
> > 
> > Index: azalia.c
> > ===
> > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
> > diff -u -p -r1.287 azalia.c
> > --- azalia.c17 May 2024 19:43:45 -  1.287
> > +++ azalia.c24 May 2024 16:26:38 -
> > @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
> > azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
> > }
> >  
> > +   /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
> > +   if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
> > +   switch (PCI_PRODUCT(sc->pciid)) {
> > +   case PCI_PRODUCT_AMD_17_HDA:
> > +   case PCI_PRODUCT_AMD_17_1X_HDA:
> > +   case PCI_PRODUCT_AMD_HUDSON2_HDA:
> > +   pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
> > +   }
> > +   }
> > +
> > /* interrupt */
> > if (pci_intr_map_msi(pa, ) && pci_intr_map(pa, )) {
> > printf(": can't map interrupt\n");
> > 
> > However it breaks my front 3.5mm audio port and I should use my
> > USB-to-3.5mm audio port adapter again.
> > 
> > How may I investigate more?
> > 
> 
> could you confirm that the system reboots only while you're using the
> azalia device?

I disabled sndiod, and unplugged my USB-to-3.5mm audio adapter and also
unplugged front 3.5mm audio port, then reboot my OpenBSD and waited on
xenodm login screen for few minutes; most of the time it reboots in
less than 10 minutes... without any interaction from me, or playing
anything...

> when you apply above diff, is audio unstable or it doesn't work at
> all?

It doesn't work at all.  No input, no output.  Even sndioctl will
freeze.

However when I plug my USB-to-3.5mm audio adapter, and run sndiod with
these arguments: -f rsnd/0 -F rsnd/1
I have audio output.  However I don't have audio input for such a long
time, maybe 2 months (if it could help I can search for latest version
of kernel which my mic works with USB-to-3.5mm audio adapter).

With latest kernel front 3.5mm audio port works great, both as input and
as output; the only problem that I have with it is sudden reboots :(

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Ali Farzanrad]

Hi again,

During my tests it seems that this version of kernel works fine:

# TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src

But this version of kernel will cause sudden reboots without any kernel
panic or message after 5-60 minutes in my Minisforum UM790:

# TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src

After investigation I found this patch could fix my problem:

Index: azalia.c
===
RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
diff -u -p -r1.287 azalia.c
--- azalia.c17 May 2024 19:43:45 -  1.287
+++ azalia.c24 May 2024 16:26:38 -
@@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
}
 
+   /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
+   if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
+   switch (PCI_PRODUCT(sc->pciid)) {
+   case PCI_PRODUCT_AMD_17_HDA:
+   case PCI_PRODUCT_AMD_17_1X_HDA:
+   case PCI_PRODUCT_AMD_HUDSON2_HDA:
+   pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
+   }
+   }
+
/* interrupt */
if (pci_intr_map_msi(pa, ) && pci_intr_map(pa, )) {
printf(": can't map interrupt\n");

However it breaks my front 3.5mm audio port and I should use my
USB-to-3.5mm audio port adapter again.

How may I investigate more?

> > > > My Minisforum UM790 keeps reboot every 5-10 minutes, without any Kernel
> > > > Panic or visible message how may I debug it?
> > > > I'm using latest OpenBSD snapshot with this amd64/BUILDINFO:
> > > > Build date: 1716424636 - Thu May 23 00:37:16 UTC 2024
> > > 
> > > Not a lot to go on really.
> > > 
> > > Is the machine doing anything or just idle?
> > 
> > It get reboot even in xenodm login screen without any interaction from me.
> > 
> > > Is X running?
> > 
> > It's funny.  I disabled the xenodm and it lived for more than 10 minutes;
> > then I enabled and started xenodm and it suddenly rebooted after few
> > minutes!
> > 
> > Next time I keep xenodm running, but switched to ttyC0 terminal using
> > Alt+Ctrl+F1 key and it lived for more than 10 minutes; then I just
> > switched to Xorg using Alt+Ctrl+F5 and it suddenly rebooted again after
> > few minutes!
> > 
> > > Do you get the same with 7.5? if yes, try older releases - can you
> > > find one where it doesn't happen?
> > 
> > I rarely got same issue in previous snapshots (I think my last snapshot
> > was for 6 days ago and I had no serious issue with that).
> > 
> > I think I sould compile and test previous versions of xenocara, right?
> 
> Try with just an older kernel first and leave userland alone.
> ftp.hostserver.de and openbsd.cs.toronto.edu both have some old
> snaps in /archive. (If no snap was built on a certain day then
> the files will be identical in the archive so no point testing
> when there was no change - you can use what(1) to show the
> version - I'd save a few under names like /bsd.mp.
> and type "boot bsd.mp." at the boot loader).
> 
> 
> > > >
> > > > # (dmesg; sysctl hw.sensors)
> > > > OpenBSD 7.5-current (GENERIC.MP) #78: Wed May 22 18:31:14 MDT 2024
> > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > real mem = 31909883904 (30431MB)
> > > > avail mem = 30921310208 (29488MB)
> > > > random: good seed from bootblocks
> > > > mpath0 at root
> > > > scsibus0 at mpath0: 256 targets
> > > > mainbus0 at root
> > > > bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x9ab7f000 (45 entries)
> > > > bios0: vendor American Megatrends International, LLC. version "1.01" 
> > > > date 06/05/2023
> > > > bios0: Micro Computer (HK) Tech Limited F7BSC
> > > > efi0 at bios0: UEFI 2.8
> > > > efi0: American Megatrends rev 0x5001d
> > > > acpi0 at bios0: ACPI 6.4
> > > > acpi0: sleep states S0 S4 S5
> > > > acpi0: tables DSDT FACP SSDT SSDT FIDT MCFG FPDT VFCT BGRT TPM2 SSDT 
> > > > CRAT CDIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS 
> > > > SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
> > > > acpi0: wakeup devices GPP1(S4) GPP0(S4) GPP5(S4) GPP7(S4) GP11(S4) 
> > > > SWUS(S4) GP12(S4) SWUS(S4)
> > > > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > > > acpimcfg0 at acpi0
> > > > acpimcfg0: addr 0xe000, bus 0-255
> > > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > > > cpu0 at mainbus0: apid 0 (boot processor)
> > > > cpu0: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 
> > > > 19-74-01, patch 0a704101
> > > > cpu0: cpuid 1 
> > > > edx=178bfbff
> > > >  
> > > > ecx=76f8320b
> > > > cpu0: cpuid 6 eax=4 ecx=1
> > > > cpu0: cpuid 7.0 
> > > > ebx=f1bf97a9
> > > >  ecx=405fce edx=1000
> > > > cpu0: cpuid d.1 eax=f
> > > > cpu0: cpuid 8001 edx=2fd3fbff 
> > > > ecx=75c237ff
> > > > cpu0: cpuid 8007 edx=e799
> > > > cpu0: cpuid 8008 
> > > > ebx=791ef257
> > > > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way 

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Ali Farzanrad]

Hi Stuart,

Stuart Henderson  wrote:
> On 2024-05-23, Ali Farzanrad  wrote:
> > Hi misc@,
> >
> > My Minisforum UM790 keeps reboot every 5-10 minutes, without any Kernel
> > Panic or visible message how may I debug it?
> > I'm using latest OpenBSD snapshot with this amd64/BUILDINFO:
> > Build date: 1716424636 - Thu May 23 00:37:16 UTC 2024
> 
> Not a lot to go on really.
> 
> Is the machine doing anything or just idle?

It get reboot even in xenodm login screen without any interaction from me.

> Is X running?

It's funny.  I disabled the xenodm and it lived for more than 10 minutes;
then I enabled and started xenodm and it suddenly rebooted after few
minutes!

Next time I keep xenodm running, but switched to ttyC0 terminal using
Alt+Ctrl+F1 key and it lived for more than 10 minutes; then I just
switched to Xorg using Alt+Ctrl+F5 and it suddenly rebooted again after
few minutes!

> Do you get the same with 7.5? if yes, try older releases - can you
> find one where it doesn't happen?

I rarely got same issue in previous snapshots (I think my last snapshot
was for 6 days ago and I had no serious issue with that).

I think I sould compile and test previous versions of xenocara, right?

> >
> > # (dmesg; sysctl hw.sensors)
> > OpenBSD 7.5-current (GENERIC.MP) #78: Wed May 22 18:31:14 MDT 2024
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 31909883904 (30431MB)
> > avail mem = 30921310208 (29488MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x9ab7f000 (45 entries)
> > bios0: vendor American Megatrends International, LLC. version "1.01" date 
> > 06/05/2023
> > bios0: Micro Computer (HK) Tech Limited F7BSC
> > efi0 at bios0: UEFI 2.8
> > efi0: American Megatrends rev 0x5001d
> > acpi0 at bios0: ACPI 6.4
> > acpi0: sleep states S0 S4 S5
> > acpi0: tables DSDT FACP SSDT SSDT FIDT MCFG FPDT VFCT BGRT TPM2 SSDT CRAT 
> > CDIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS SSDT SSDT 
> > SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
> > acpi0: wakeup devices GPP1(S4) GPP0(S4) GPP5(S4) GPP7(S4) GP11(S4) SWUS(S4) 
> > GP12(S4) SWUS(S4)
> > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > acpimcfg0 at acpi0
> > acpimcfg0: addr 0xe000, bus 0-255
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, 
> > patch 0a704101
> > cpu0: cpuid 1 
> > edx=178bfbff
> >  
> > ecx=76f8320b
> > cpu0: cpuid 6 eax=4 ecx=1
> > cpu0: cpuid 7.0 
> > ebx=f1bf97a9
> >  ecx=405fce edx=1000
> > cpu0: cpuid d.1 eax=f
> > cpu0: cpuid 8001 edx=2fd3fbff 
> > ecx=75c237ff
> > cpu0: cpuid 8007 edx=e799
> > cpu0: cpuid 8008 
> > ebx=791ef257
> > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 
> > 64b/line 8-way L2 cache, 16MB 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 24MHz
> > cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, 
> > patch 0a704101
> > cpu1: smt 0, core 1, package 0
> > cpu2 at mainbus0: apid 4 (application processor)
> > cpu2: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, 
> > patch 0a704101
> > cpu2: smt 0, core 2, package 0
> > cpu3 at mainbus0: apid 6 (application processor)
> > cpu3: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, 
> > patch 0a704101
> > cpu3: smt 0, core 3, package 0
> > cpu4 at mainbus0: apid 8 (application processor)
> > cpu4: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, 
> > patch 0a704101
> > cpu4: smt 0, core 4, package 0
> > cpu5 at mainbus0: apid 10 (application processor)
> > cpu5: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, 
> > patch 0a704101
> > cpu5: smt 0, core 5, package 0
> > cpu6 at mainbus0: apid 12 (application processor)
> > cpu6: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, 
> > patch 0a704101
> > cpu6: smt 0, core 6, package 0
> > cpu7 at mainbus0: apid 14 (application processor)
> > cpu7: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, 
> > patch 0a704101
> > cpu7: smt 0, core 7, pac

Sudden reboot every 5-10 minutes on latest snapshot

[Ali Farzanrad]

Hi misc@,

My Minisforum UM790 keeps reboot every 5-10 minutes, without any Kernel
Panic or visible message how may I debug it?
I'm using latest OpenBSD snapshot with this amd64/BUILDINFO:
Build date: 1716424636 - Thu May 23 00:37:16 UTC 2024

# (dmesg; sysctl hw.sensors)
OpenBSD 7.5-current (GENERIC.MP) #78: Wed May 22 18:31:14 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 31909883904 (30431MB)
avail mem = 30921310208 (29488MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x9ab7f000 (45 entries)
bios0: vendor American Megatrends International, LLC. version "1.01" date 
06/05/2023
bios0: Micro Computer (HK) Tech Limited F7BSC
efi0 at bios0: UEFI 2.8
efi0: American Megatrends rev 0x5001d
acpi0 at bios0: ACPI 6.4
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SSDT SSDT FIDT MCFG FPDT VFCT BGRT TPM2 SSDT CRAT CDIT 
SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices GPP1(S4) GPP0(S4) GPP5(S4) GPP7(S4) GP11(S4) SWUS(S4) 
GP12(S4) SWUS(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
cpu0: cpuid 1 
edx=178bfbff
 
ecx=76f8320b
cpu0: cpuid 6 eax=4 ecx=1
cpu0: cpuid 7.0 
ebx=f1bf97a9
 ecx=405fce edx=1000
cpu0: cpuid d.1 eax=f
cpu0: cpuid 8001 edx=2fd3fbff 
ecx=75c237ff
cpu0: cpuid 8007 edx=e799
cpu0: cpuid 8008 
ebx=791ef257
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
8-way L2 cache, 16MB 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 24MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 10 (application processor)
cpu5: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
cpu5: smt 0, core 5, package 0
cpu6 at mainbus0: apid 12 (application processor)
cpu6: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
cpu6: smt 0, core 6, package 0
cpu7 at mainbus0: apid 14 (application processor)
cpu7: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
cpu7: smt 0, core 7, package 0
cpu8 at mainbus0: apid 1 (application processor)
cpu8: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.01 MHz, 19-74-01, patch 
0a704101
cpu8: smt 1, core 0, package 0
cpu9 at mainbus0: apid 3 (application processor)
cpu9: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.01 MHz, 19-74-01, patch 
0a704101
cpu9: smt 1, core 1, package 0
cpu10 at mainbus0: apid 5 (application processor)
cpu10: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.01 MHz, 19-74-01, patch 
0a704101
cpu10: smt 1, core 2, package 0
cpu11 at mainbus0: apid 7 (application processor)
cpu11: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.01 MHz, 19-74-01, patch 
0a704101
cpu11: smt 1, core 3, package 0
cpu12 at mainbus0: apid 9 (application processor)
cpu12: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.01 MHz, 19-74-01, patch 
0a704101
cpu12: smt 1, core 4, package 0
cpu13 at mainbus0: apid 11 (application processor)
cpu13: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.01 MHz, 19-74-01, patch 
0a704101
cpu13: smt 1, core 5, package 0
cpu14 at mainbus0: apid 13 (application processor)
cpu14: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.01 MHz, 19-74-01, patch 
0a704101
cpu14: smt 1, core 6, package 0
cpu15 at mainbus0: apid 15 (application processor)
cpu15: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.01 MHz, 19-74-01, patch 
0a704101
cpu15: smt 1, core 7, package 0
ioapic0 at mainbus0: apid 33 pa 0xfec0, version 21, 24 pins, can't remap
ioapic1 at mainbus0: apid 34 pa 0xfec01000, version 21, 32 pins, can't remap
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (GPP1)
acpiprt2 at acpi0: bus -1 (GPP2)
acpiprt3 at acpi0: bus -1 (GPP0)
acpiprt4 at acpi0: bus -1 (GPP3)
acpiprt5 at acpi0: bus -1 (GPP4)
acpiprt6 at acpi0: bus 2 (GPP5)
acpiprt7 at acpi0: bus -1 (GPP6)
acpiprt8 at 

Re: upgrade to latest snapshot failing

[Ali Farzanrad]

Ali Farzanrad  wrote:
> Hi Stuard,
> 
> Stuart Henderson  wrote:
> > On 2023-11-17, Sonic  wrote:
> > > Following -current:
> > > OpenBSD 7.4-current (GENERIC.MP) #1447: Wed Nov 15 09:56:54 MST 2023
> > > Upgrade via "sysupgrade -s" now failing with:
> > > init: single user shell terminated, restarting
> > > init: single user shell terminated, restarting
> > > init: single user shell terminated, restarting
> > > 
> > 
> > Bit old by now, boot bsd.rd and try a newer one?
> 
> I have the same issue and I fetched a new bsd.rd from my mirror.
> 
> $ cat BUILDINFO
> Build date: 1700241082 - Fri Nov 17 17:11:22 UTC 2023
> 
> I see exact same problem after booting bsd.rd:
> 
> [...]
> root on rd0a swap on rd0b dump on rd0b
> iwx0: could not read firmware iwx-ty-a0-gf-a0-77 (error 2)
> iwx0: failed to load init firmware
> init: single user shell terminated, restarting
> init: single user shell terminated, restarting
> init: single user shell terminated, restarting
> [...repeating...]
> 
> > If that fails too: which arch?
> 
> My machine is amd64

I also fetched latest bsd.mp file from same mirror (same BUILDINFO) and
it droped me into single user mode prompting for a shell.
Interesting thing was that the single user mode was terminated after any
single command I entered! (maybe because I hadn't updated userland sets)
I couldn't capture dmesg from bsd.rd, but here is my captured dmesg from
bsd.mp which might be helpful:

OpenBSD 7.4-current (GENERIC.MP) #1451: Fri Nov 17 10:05:18 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 31909883904 (30431MB)
avail mem = 30923165696 (29490MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x9ab7f000 (45 entries)
bios0: vendor American Megatrends International, LLC. version "1.01" date 
06/05/2023
bios0: Micro Computer (HK) Tech Limited F7BSC
efi0 at bios0: UEFI 2.8
efi0: American Megatrends rev 0x5001d
acpi0 at bios0: ACPI 6.4
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SSDT SSDT FIDT MCFG FPDT VFCT BGRT TPM2 SSDT CRAT CDIT 
SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices GPP1(S4) GPP0(S4) GPP5(S4) GPP7(S4) GP11(S4) SWUS(S4) 
GP12(S4) SWUS(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
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,x2APIC,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, 16MB 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 24MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
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,x2APIC,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, 16MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics, 4000.00 MHz, 19-74-01, patch 
0a704101
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,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,S

Re: upgrade to latest snapshot failing

[Ali Farzanrad]

Hi Stuard,

Stuart Henderson  wrote:
> On 2023-11-17, Sonic  wrote:
> > Following -current:
> > OpenBSD 7.4-current (GENERIC.MP) #1447: Wed Nov 15 09:56:54 MST 2023
> > Upgrade via "sysupgrade -s" now failing with:
> > init: single user shell terminated, restarting
> > init: single user shell terminated, restarting
> > init: single user shell terminated, restarting
> > 
> 
> Bit old by now, boot bsd.rd and try a newer one?

I have the same issue and I fetched a new bsd.rd from my mirror.

$ cat BUILDINFO
Build date: 1700241082 - Fri Nov 17 17:11:22 UTC 2023

I see exact same problem after booting bsd.rd:

[...]
root on rd0a swap on rd0b dump on rd0b
iwx0: could not read firmware iwx-ty-a0-gf-a0-77 (error 2)
iwx0: failed to load init firmware
init: single user shell terminated, restarting
init: single user shell terminated, restarting
init: single user shell terminated, restarting
[...repeating...]

> If that fails too: which arch?

My machine is amd64

> -- 
> Please keep replies on the mailing list.

Weird clang behavior

[Ali Farzanrad]

Hi,

Is it normal to have such behavior?

$ cat loop.c
int
main(void)
{
for (;;)
;
}
$ clang -O1 -Wall -Wextra -S -o loop.c.s loop.c
$ clang++ -O1 -Wall -Wextra -S -o loop.cxx.s loop.c
clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated [-Wdeprecated]
$ diff -U8 loop.c.s loop.cxx.s
--- loop.c.sThu Mar  2 11:55:02 2023
+++ loop.cxx.s  Thu Mar  2 11:55:08 2023
@@ -5,20 +5,16 @@
.type   main,@function
 main:   # @main
.cfi_startproc
 # %bb.0:
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
-   .cfi_def_cfa_register %rbp
-   .p2align4, 0x90
-.LBB0_1:# =>This Inner Loop Header: Depth=1
-   jmp .LBB0_1
 .Lfunc_end0:
.size   main, .Lfunc_end0-main
.cfi_endproc
 # -- End function
.section
.text.__llvm_retpoline_r11,"axG",@progbits,__llvm_retpoline_r11,comdat
.hidden __llvm_retpoline_r11# -- Begin function 
__llvm_retpoline_r11
.weak   __llvm_retpoline_r11
.p2align4, 0xcc


See that jmp instruction which is removed.
Without that jmp instruction the main function might reach other codes!

Re: Securely managing TLS certificates on growing server (website, XMPP, soon email)?

[Ali Farzanrad]

Hi Ashlen,

The best way to handle your concerns is to review httpd, OpenSMTPd, and
other projects code and send a patch to these project to handle Certificates
in a more secure way.  This way you can help yourself and the others.


Bests,
Ali Farzanrad

Ashlen  wrote:
> Hi all, so I'm wondering how to securely deal with TLS certificates on a 
> server
> that's grown to host multiple services (website, XMPP, soon email as well).
> Specifically how to handle permissions and to what degree certificates should 
> be
> separated.
> 
> (I recognize this is a long email. I'm unsure how to break down my thoughts
> further)
> 
> I know that I could add a load of Subject Alternative Names to one big
> certificate, but I have a couple of concerns with this.
> 
> 1) If I understand it right, if there's a security issue with one program and 
> an
> attacker gains arbitrary read, and the effective user id can read the private
> key, the exposure is greater than it has to be (that is to say, domains that 
> are
> completely unrelated to the insecure program are exposed). Daemons outside of
> base unfortunately often lack privilege separation to the extent that it 
> exists
> in base, so there may not be a separate user to handle private keys, and then
> the whole thing has the potential to blow up later.
> 
> 2) A long list of Subject Alternative Names means that anyone connecting to 
> the
> web server can see all of the additional subdomains that are unrelated to the
> web server being hosted. This is really a nitpick compared to the first point,
> as even without this being the case there are other methods of enumeration and
> discovery (nmap and friends), and relying on DNS entries being hidden seems 
> like
> a bad idea.
> 
> The best way I can think of how to handle this so far, and "best" is used very
> loosely since I don't think it's a perfect solution, is to split the keys up,
> add a separate group, and modify `/etc/ssl/private`.
> 
> ```
> # groupadd tls
> # usermod -G tls _prosody
> # chown root:tls /etc/ssl/private
> # chmod 750 /etc/ssl/private
> ```
> 
> Then the private keys within would all have 0400 permissions, user and group
> being the same (so _prosody:_prosody for XMPP-related TLS). I noted that the
> default is 700 permissions on `/etc/ssl/private` with root:wheel ownership. Is
> the approach I've just outlined with adding a group and modifying permissions 
> a
> bad idea?
> 
> Even if it makes sense to do it this way, I still have a separate issue in 
> that
> when two or more services need the certificate for the root domain, they'll 
> end
> up sharing it, and I'm unclear what the right way to fix that problem is. If
> it's only services in the base system, that's one thing. But Prosody also has
> this issue with the way I set it up. Currently it's configured so that 
> usernames
> can be in the form "u...@example.com" rather than "u...@xmpp.example.com"
> (similar to how email usernames use the root domain). This means it needs the
> certificate for the root domain so that authentication can take place over 
> TLS,
> and that breaks the separation.
> 
> For some services, it can make sense to use relayd(8) and let that handle TLS
> instead, which simplifies things since relayd has proper privilege separation
> and can even use SNI. But I'm unsure how this could be done with something 
> like
> Prosody since XMPP uses STARTTLS (outside of exceptions to that rule like
> XEP-0368).
> 
> What can I do to manage this better? Any ideas/suggestions are very welcome.
> Thank you for reading all of this if you made it here.
> 
> 

Re: unable to install texlive_texmf-full due to python reaching 2.7 end-of-life

[Ali Farzanrad]

Hi Stuart,

I think that I know the problem.
pkg_add will search python in stable directory before searching for it
in release directory and it find python.  However it will only find
version 3, because there is no python 2 in stable directory.

So it will stop searching (because it found python) and report that
there is no python 2 available.

I had similar problem with pkg_info, but I don't know Perl well, so I
couldn't fix the issue.  See my older email:

https://marc.info/?l=openbsd-tech=159233657617055

Stuart Henderson  wrote:
> On 2022-09-01, Sandeep Gupta  wrote:
> > Is there a workaround for installing texlive_full on openbsd 7.1?
> > Installing via package manager currently fails because
> > it has Python2.7 as dependency which has reached end-of-life. Can I force
> > the installation?
> 
> Python 2.7 packages are still availsble, this doesn't block things in
> packages.
> 
> What exactly do you see when you try to install texlive?
> 
> 
> -- 
> Please keep replies on the mailing list.
> 
> 

Re: chromium/iridium/firefox no dns resolve on rtable

[Ali Farzanrad]

Ali Farzanrad  wrote:
> Hi,
> 
> I have a wireguard configuration in my system with local unbound dns
> resolver.  In the past, I'd configured my wireguard as a separated
> rdomain, so whenever I needed to run my browser, I did one of these 2
> options:
> 
>  1. change /etc/resolv.conf and user a global dns resolver,
> 
>  2. run an unwind locally for my wg rdomain: route -T exec unwind
> 
> This was working for me, until recently that I changed my configuration
> to have a single rdomain with different rtables.  I've added these
> routes to my rtable:
> 
> route -T add 127/8 127.0.0.1
> route -T add default 
> 
> I've tested this configuration with curl and confirm that it is OK:
> 
> route -T exec curl -s https://location.ipfire.org | grep Hey
> 
> But whenever I run chromium or iridium or firefox-esr on this rtable,
> it could not resolve any dns name (they displays websites such as
> https://1.1.1.1 which doesn't require any dns resolving correctly).
> 
> I've tested different nameservers, global and local with same rtable,
> but it didn't work.
> 
> What is the problem?
> How may I debug it?
> 
> 
> Thanks in Advance

Forget to mention, I've tested all of these in OpenBSD-CURRENT
(following base from source, but packages from binary).  I've updated
all of my packages except iridium which I didn't find in snapshots.

This is my routes:

$ route -T show
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default  UGS04 - 8 wg
127/8  localhost  UGS0   29 32768 8 lo0

chromium/iridium/firefox no dns resolve on rtable

[Ali Farzanrad]

Hi,

I have a wireguard configuration in my system with local unbound dns
resolver.  In the past, I'd configured my wireguard as a separated
rdomain, so whenever I needed to run my browser, I did one of these 2
options:

 1. change /etc/resolv.conf and user a global dns resolver,

 2. run an unwind locally for my wg rdomain: route -T exec unwind

This was working for me, until recently that I changed my configuration
to have a single rdomain with different rtables.  I've added these
routes to my rtable:

route -T add 127/8 127.0.0.1
route -T add default 

I've tested this configuration with curl and confirm that it is OK:

route -T exec curl -s https://location.ipfire.org | grep Hey

But whenever I run chromium or iridium or firefox-esr on this rtable,
it could not resolve any dns name (they displays websites such as
https://1.1.1.1 which doesn't require any dns resolving correctly).

I've tested different nameservers, global and local with same rtable,
but it didn't work.

What is the problem?
How may I debug it?


Thanks in Advance

OpenBSD 7.1 AMDGPU: No video after suspend

[Ali Farzanrad]

Hi,

Thanks for new release.  I have this issue for few years in my system
(maybe since OpenBSD 6.6).  Whenever I suspend my system using zzz
command, It suspends well, however after I press power button I see no
video and my monitor remain in sleep mode.

I've replaced my old Radeon RX 550 video card with a Radeon RX 6600
recently, however this didn't solve my problem.  Last time I pressed
power button again to power off my system properly and attached my dmesg
to this mail.

Also there is a problem with syspatch, why syspatch for OpenBSD 7.1 is
in this directory?

/pub/OpenBSD/syspatch/7.1-no/


Thanks in advance


OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17094057984 (16302MB)
avail mem = 16558698496 (15791MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe8d60 (49 entries)
bios0: vendor American Megatrends Inc. version "F51b" date 07/02/2020
bios0: Gigabyte Technology Co., Ltd. AB350-Gaming 3
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT MCFG SSDT HPET SSDT UEFI 
IVRS SSDT CRAT CDIT BGRT SSDT SSDT WSMT SSDT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) 
GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) 
GPPF(S4) GP17(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 1700 Eight-Core Processor, 2994.87 MHz, 17-01-01
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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz, 17-01-01
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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz, 17-01-01
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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz, 17-01-01
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,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu3: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu3: smt 0, core 3, package 0
cpu4 at 

Re: Can't figure out what's taking up space on /

[Ali Farzanrad]

I also suspected that it is a filesystem corruption.
Do you have `async` mount option on your root?

Sebastien Marie  wrote:
> On Tue, Aug 03, 2021 at 10:03:44AM +0200, Paul de Weerd wrote:
> > df shows you how much data you can write to an fs, while du shows the
> > disk usage of files it can find.  If it can't find a file (because
> > it's been deleted), it won't account for it.  But if it's been deleted
> > and still held open by some process, it would still consume disk
> > space.
> > 
> > So it looks like a process has a file open on the root filesystem that
> > has been deleted.  You're looking for a root-owned process that is
> > (probably) long-running.  My guess the file is in /dev/ (that's my
> > crystal ball talking though).
> > 
> > Easiest way out is generally to reboot - this stops all processes
> > (d0h), dus freeing up all the resources they had tied up, including
> > files that had been deleted from the filesystem.  But going through
> > your process list to see if you can spot something that may have done
> > this can be a good learning experience.  In general, base OpenBSD
> > daemons don't behave this way.
> 
> I agree with Paul: you should have a running process which hold
> descriptor on unlinked file.
> 
> fstat(1) could be used to see list of opened files, and specially
> unlinked files:
> 
>  INUM   The inode number of the file.  It will be followed by an asterisk
> (‘*’) if the inode is unlinked from disk.
> 
> 
> $ fstat | grep -F '* -'
> [...]
> semarie  chrome   537   25 /tmp   48* -rw---   rwp   279793
> [...]
> 
> here, chrome (pid 537) has descriptor 25 opened to a file on /tmp
> inode=48 (unlinked), the file size is 279793 bytes.
> 
> -- 
> Sebastien Marie
> 
> 

Re: openbsd.org down?

[Ali Farzanrad]

Monah Baki  wrote:
> firefox does not work
> 

Maybe that's a firefox bug:

https://support.mozilla.org/he/questions/1276819

Re: Future of X.org?

[Ali Farzanrad]

Juan Francisco Cantero Hurtado  wrote:
> On Mon, Jul 01, 2019 at 06:39:01PM +0300, li...@wrant.com wrote:
> > Mon, 1 Jul 2019 17:13:44 +0200 Juan Francisco Cantero Hurtado
> > 
> > > On Mon, Jul 01, 2019 at 05:20:20PM +0300, li...@wrant.com wrote:
> > > > Mon, 1 Jul 2019 00:46:33 +0200 Juan Francisco Cantero Hurtado
> > > >   
> > > > > On Sun, Jun 30, 2019 at 09:09:08PM +, Roderick wrote:  
> > > > > > 
> > > > > > On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote:
> > > > > > 
> > > > > > > Nope, you misunderstood the text.
> > > > > > 
> > > > > > No. It is *you* that do not understand what X11 is and want it 
> > > > > > death.
> > > > > > A very destructive attitude.
> > > > > 
> > > > > You're the only one with a destructive attitude here. I'm trying to 
> > > > > help
> > > > > you because usually people doesn't understand how wayland works.  
> > > > 
> > > > You can't do without YOU understanding basics of X11, do something 
> > > > else..
> > > > Juan, I don't trust your lack of any qualification for even feature 
> > > > bait.  
> > > 
> > > Show me where I am wrong. Enlighten us with your qualification No Name.
> > > 
> > 
> > Here you go wrong on all points..  Next time, bring 100% more experience.
> > 
> > Sat, 29 Jun 2019 20:45:14 +0200 Juan Francisco Cantero Hurtado
> > 
> > > 
> > > The missing parts are not so big but nobody is working on that.
> > > 
> > > I dont' know why people are so sad. X11 should have died long time ago.
> > > 
> > 
> > This is not exactly inspirational, neither convincing.  Try again later..
> > Juan, I still can not find one single piece of text where you were right.
> 
> Can you show me what missing Wayland part is bigger than DRM+Mesa+LLVM?.

I used Wayland on Debian for few weeks.  One day all of a sudden screen
rotated on my laptop and I couldn't find any way to fix it.  I think
Wayland is far from beeing stable.

Re: chrome pledge "", syscall 289

[Ali Farzanrad]

Cord  wrotes:
>
> Hi,
> I have found the following errors on the log:
>
> /bsd: chrome[18585]: pledge "", syscall 289
>
> they appear everytime I start chrome.. they are about 4 or 5, what means?
> It's the first time, yesterday and in the past there aren't any.
>
> thx cord
>

It might be related:
https://marc.info/?l=openbsd-tech=155899373514678=2

Re: samba client

[Ali Farzanrad]

I also recommend curl if you know exact address of receiving/sending
resource.

It needs zero config and works great in non-root users.

Re: bug tracking system for OpenBSD

[Ali Farzanrad]

On Sat, Dec 23, 2017 at 10:24:25AM +, Stuart Henderson wrote:
> The idea of a bug tracking system is to spread the work and help
> people remember things. It should *reduce* work done by devs because
> they no longer have to drag even the most basic information out
> of a reporter and figure out whether it's a bug or user error
> or a support request in disguise.
> 
> If it means *extra* work for devs, it's not going to work.
> 

I think that a simple directory in CVS repository could do that.  Also
it can be updated simply using `cvs commit'.  The directory sould have
plain text files for each unsolved issue.

Re: Copy files to usb (slow)

[Ali Farzanrad]

G  wrotes:
>Hello.
>Im trying to copy files from my laptop to a usb stick.
>The speed varies between 300kB/sec and 400kB/sec. Its really slow.

I also have the same problem.
It seems that block files are slow and it is not possible to mount raw
files.
I tested it with dd(1) and found that fastest way to transfer data is
using raw devices:

# dd if=/dev/rsd1c of=temp.fs bs=1m
# vnconfig vnd0 temp.fs
# mount /dev/vnd0i /mnt/usb
# ... do copy ...
# umount /mnt/usb
# vnconfig -u vnd0
# dd if=temp.fs of=/dev/rsd1c bs=1m

xenocara/app/cwm: sticky command

[Ali Farzanrad]

Hi,

It seems that cwmrc(5) could not change default key binding for sticky
command and whenever I try to bind keys to sticky, I receive "syntax error".

I check the codes and found out that in parse.y file "sticky" is a keyword.

I don't know which is the best patch for this problem, but this patch works 
for me:

Index: conf.c
===
RCS file: /usr/cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.204
diff -u -p -r1.204 conf.c
--- conf.c  13 Aug 2016 09:59:48 -  1.204
+++ conf.c  9 Sep 2016 19:50:22 -
@@ -207,7 +207,7 @@ static const struct {
{ "CM-g",   "grouptoggle" },
{ "CM-f",   "fullscreen" },
{ "CM-m",   "maximize" },
-   { "CM-s",   "sticky" },
+   { "CM-s",   "togglesticky" },
{ "CM-equal",   "vmaximize" },
{ "CMS-equal",  "hmaximize" },
{ "CMS-f",  "freeze" },
@@ -408,7 +408,7 @@ static const struct {
{.i = (CWM_CLIENT_RCYCLE | CWM_CLIENT_CYCLE_INGRP)} },
{ "grouptoggle", kbfunc_client_grouptoggle, CWM_CONTEXT_CLIENT,
{.i = CWM_KBD}},
-   { "sticky", kbfunc_client_toggle_sticky, CWM_CONTEXT_CLIENT, {0} },
+   { "togglesticky", kbfunc_client_toggle_sticky, CWM_CONTEXT_CLIENT, {0} 
},
{ "fullscreen", kbfunc_client_toggle_fullscreen, CWM_CONTEXT_CLIENT,
{0} },
{ "maximize", kbfunc_client_toggle_maximize, CWM_CONTEXT_CLIENT, {0} },
Index: cwmrc.5
===
RCS file: /usr/cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.61
diff -u -p -r1.61 cwmrc.5
--- cwmrc.5 12 Jul 2015 14:31:47 -  1.61
+++ cwmrc.5 9 Sep 2016 20:12:10 -
@@ -301,7 +301,7 @@ Raise current window.
 Label current window.
 .It freeze
 Freeze current window geometry.
-.It sticky
+.It togglesticky
 Stick current window to all groups (same as assigning to nogroup).
 .It fullscreen
 Full-screen current window (gap + border removed).

Re: Installer overwrites partition table

[Ali Farzanrad]

Stuart Henderson wrotes:

>On 2016-08-24, Bertram Scharpf  wrote:
>> The installers partitioning tool didn't offer me a variant
>> that keeps my existing partitions.
>
>If you wanted to try it again, when it asks "Use (W)hole disk or
>(E)dit the MBR?", choose E.
>
>It doesn't exactly hold your hand every step of the way, but
>what could be clearer than "Use whole disk"?
>

The installer has 2 different steps to partitioning your disk.
At first ("Use (W)hole disk MBR, whole disk (G)PT or (E)dit?") it uses
fdisk(8) and after this step it will overwrites your partition table.

The next step ("Use (A)uto layout, (E)dit auto layout, or create (C)ustom
layout?") could not recover you partition table from previous step even by
pressing Ctrl+C.

Re: xlock permission problem

[Ali Farzanrad]

Jyri Hovila [iki.fi] wrotes:
>
>Hello, world!
>
>I'm having an issue with xlock being unable to unlock a locked session.
>
>I'm running a CURRENT version of OpenBSD on amd64 architecture.
>
>I can lock my X session with xlock just fine, but when I enter my
>password the unlock, xlock says the password is invalid. However, the
>password I've entered (several times) is 100% correct.
>
It might be ugly, but are you sure that you are in rigth keyboard layout?

I have similar issue when using another layout (in my case ir) and lock
my system without changing back layout.