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 +, 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 +, 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 +, 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: USB ports xhci not detected in Dell Precision 7820 Tower

[Adrian Ali]

Hi, fixed in OpenBSD 6.8. Thanks.

On 10/5/19 11:09 PM, Adrian Ali wrote:
Hello, I am Newbie in OpenBSD, I have been using it for 1 year. I am 
an advanced user in Linux and Unix, I have been using it for 25 years. 
My last installation of OpenBSD was on a Dell Precision 7820 Tower 
workstation. I have problems with the detection of USB ports. The last 
test was performed with snapshots from October 3, 2019. Also update 
the Workstation BIOS. Perform tests with different keyboards, mouse 
and pen drive without any positive results.

USB ports are not detected, commands:

nain ~ # usbdevs -v
usbdevs: no USB controllers found

nain ~ # lsusb -v

nain ~ # dmesg | grep -i xhci
acpi0: wakeup devices XHCI(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) 
RP19(S4) PXSX(S4) RP20(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) 
PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...]
xhci0 at pci0 dev 20 function 0 "Intel C620 xHCI" rev 0x09: msi, xHCI 
ff.ff

xhci0: reset timeout
xhci0: init failed, error=5
nain ~ #

nain ~ # dmidecode -t system
# dmidecode 3.1
Scanning /dev/mem for entry point.
SMBIOS 3.2.1 present.
# SMBIOS implementations newer than version 3.1.1 are not
# fully supported by this version of dmidecode.

Handle 0x0001, DMI type 1, 27 bytes
System Information
    Manufacturer: Dell Inc.
    Product Name: Precision 7820 Tower
    Version: Not Specified
    Serial Number: 1XNPZV2
    UUID: 4C4C4544-0058-4E10-8050-B1C04F5A5632
    Wake-up Type: Power Switch
    SKU Number: 0739
    Family: Precision

Handle 0x0005, DMI type 12, 5 bytes
System Configuration Options
    Option 1: Default string

Handle 0x0006, DMI type 15, 35 bytes
System Event Log
    Area Length: 4 bytes
    Header Start Offset: 0x
    Header Length: 2 bytes
    Data Start Offset: 0x0002
    Access Method: Indexed I/O, one 16-bit index port, one 8-bit 
data port

    Access Address: Index 0x046A, Data 0x046C
    Status: Invalid, Not Full
    Change Token: 0x
    Header Format: No Header
    Supported Log Type Descriptors: 6
    Descriptor 1: End of log
    Data Format 1: OEM-specific
    Descriptor 2: End of log
    Data Format 2: OEM-specific
    Descriptor 3: End of log
    Data Format 3: OEM-specific
    Descriptor 4: End of log
    Data Format 4: OEM-specific
    Descriptor 5: End of log
    Data Format 5: OEM-specific
    Descriptor 6: End of log
    Data Format 6: OEM-specific

Handle 0x0008, DMI type 32, 20 bytes
System Boot Information
    Status: No errors detected

nain ~ #

nain ~ # dmidecode -t bios
# dmidecode 3.1
Scanning /dev/mem for entry point.
SMBIOS 3.2.1 present.
# SMBIOS implementations newer than version 3.1.1 are not
# fully supported by this version of dmidecode.

Handle 0x, DMI type 0, 26 bytes
BIOS Information
    Vendor: Dell Inc.
    Version: 2.3.1
    Release Date: 09/01/2019
    Address: 0xF
    Runtime Size: 64 kB
    ROM Size: 32 MB
    Characteristics:
    PCI is supported
    PNP is supported
    BIOS is upgradeable
    BIOS shadowing is allowed
    Boot from CD is supported
    Selectable boot is supported
    EDD is supported
    5.25"/1.2 MB floppy services are supported (int 13h)
    3.5"/720 kB floppy services are supported (int 13h)
    3.5"/2.88 MB floppy services are supported (int 13h)
    Print screen service is supported (int 5h)
    8042 keyboard services are supported (int 9h)
    Serial services are supported (int 14h)
    Printer services are supported (int 17h)
    ACPI is supported
    USB legacy is supported
    BIOS boot specification is supported
    Function key-initiated network boot is supported
    Targeted content distribution is supported
    UEFI is supported
    BIOS Revision: 2.3

Handle 0xF047, DMI type 13, 22 bytes
BIOS Language Information
    Language Description Format: Long
    Installable Languages: 2
    en|US|iso8859-1
    
    Currently Installed Language: en|US|iso8859-1

nain ~ #

nain ~ # dmidecode -t baseboard
# dmidecode 3.1
Scanning /dev/mem for entry point.
SMBIOS 3.2.1 present.
# SMBIOS implementations newer than version 3.1.1 are not
# fully supported by this version of dmidecode.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
    Manufacturer: Dell Inc.
    Product Name: 0G7W4R
    Version: A00
    Serial Number: /1XNPZV2/CNFCW008CV00D7/
    Asset Tag: Not Specified
    Features:
    Board is a hosting board
    Board is replaceable
    Location In Chassis: Not Specified
    Chassis Handle: 0x0003
    Type: Motherboard
    Co

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: pf-badhost-0.3 released

[Zann Ali]

Awesome stuff!! I can't wait to upgrade the script on my gateway(s) this 
week.


Thank you.

Zann



On 2020-03-10 14:51, Jordan Geoghegan wrote:

Hey folks,

Last time I posted about this, I got a fair bit of interest and I've
had quite a few downloads and enquiries about pf-badhost, so I figured
I'd share here that I've updated the script.

pf-badhost and unbound-adblock are both now at version 0.3, released
earlier today.

I highly encourage anybody running an older version of these scripts
to update to the latest version, as I have made a number of
significant improvements to the security and robustness of the script.

Links to the scripts can be found here:

www.geoghegan.ca/pfbadhost.html
www.geoghegan.ca/unbound-adblock.html

Regards,
Jordan

USB ports xhci not detected in Dell Precision 7820 Tower

[Adrian Ali]

Hello, I am Newbie in OpenBSD, I have been using it for 1 year. I am an 
advanced user in Linux and Unix, I have been using it for 25 years. My 
last installation of OpenBSD was on a Dell Precision 7820 Tower 
workstation. I have problems with the detection of USB ports. The last 
test was performed with snapshots from October 3, 2019. Also update the 
Workstation BIOS. Perform tests with different keyboards, mouse and pen 
drive without any positive results.

USB ports are not detected, commands:

nain ~ # usbdevs -v
usbdevs: no USB controllers found

nain ~ # lsusb -v

nain ~ # dmesg | grep -i xhci
acpi0: wakeup devices XHCI(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) 
RP19(S4) PXSX(S4) RP20(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) 
RP03(S4) PXSX(S4) RP04(S4) [...]

xhci0 at pci0 dev 20 function 0 "Intel C620 xHCI" rev 0x09: msi, xHCI ff.ff
xhci0: reset timeout
xhci0: init failed, error=5
nain ~ #

nain ~ # dmidecode -t system
# dmidecode 3.1
Scanning /dev/mem for entry point.
SMBIOS 3.2.1 present.
# SMBIOS implementations newer than version 3.1.1 are not
# fully supported by this version of dmidecode.

Handle 0x0001, DMI type 1, 27 bytes
System Information
    Manufacturer: Dell Inc.
    Product Name: Precision 7820 Tower
    Version: Not Specified
    Serial Number: 1XNPZV2
    UUID: 4C4C4544-0058-4E10-8050-B1C04F5A5632
    Wake-up Type: Power Switch
    SKU Number: 0739
    Family: Precision

Handle 0x0005, DMI type 12, 5 bytes
System Configuration Options
    Option 1: Default string

Handle 0x0006, DMI type 15, 35 bytes
System Event Log
    Area Length: 4 bytes
    Header Start Offset: 0x
    Header Length: 2 bytes
    Data Start Offset: 0x0002
    Access Method: Indexed I/O, one 16-bit index port, one 8-bit 
data port

    Access Address: Index 0x046A, Data 0x046C
    Status: Invalid, Not Full
    Change Token: 0x
    Header Format: No Header
    Supported Log Type Descriptors: 6
    Descriptor 1: End of log
    Data Format 1: OEM-specific
    Descriptor 2: End of log
    Data Format 2: OEM-specific
    Descriptor 3: End of log
    Data Format 3: OEM-specific
    Descriptor 4: End of log
    Data Format 4: OEM-specific
    Descriptor 5: End of log
    Data Format 5: OEM-specific
    Descriptor 6: End of log
    Data Format 6: OEM-specific

Handle 0x0008, DMI type 32, 20 bytes
System Boot Information
    Status: No errors detected

nain ~ #

nain ~ # dmidecode -t bios
# dmidecode 3.1
Scanning /dev/mem for entry point.
SMBIOS 3.2.1 present.
# SMBIOS implementations newer than version 3.1.1 are not
# fully supported by this version of dmidecode.

Handle 0x, DMI type 0, 26 bytes
BIOS Information
    Vendor: Dell Inc.
    Version: 2.3.1
    Release Date: 09/01/2019
    Address: 0xF
    Runtime Size: 64 kB
    ROM Size: 32 MB
    Characteristics:
    PCI is supported
    PNP is supported
    BIOS is upgradeable
    BIOS shadowing is allowed
    Boot from CD is supported
    Selectable boot is supported
    EDD is supported
    5.25"/1.2 MB floppy services are supported (int 13h)
    3.5"/720 kB floppy services are supported (int 13h)
    3.5"/2.88 MB floppy services are supported (int 13h)
    Print screen service is supported (int 5h)
    8042 keyboard services are supported (int 9h)
    Serial services are supported (int 14h)
    Printer services are supported (int 17h)
    ACPI is supported
    USB legacy is supported
    BIOS boot specification is supported
    Function key-initiated network boot is supported
    Targeted content distribution is supported
    UEFI is supported
    BIOS Revision: 2.3

Handle 0xF047, DMI type 13, 22 bytes
BIOS Language Information
    Language Description Format: Long
    Installable Languages: 2
    en|US|iso8859-1
    
    Currently Installed Language: en|US|iso8859-1

nain ~ #

nain ~ # dmidecode -t baseboard
# dmidecode 3.1
Scanning /dev/mem for entry point.
SMBIOS 3.2.1 present.
# SMBIOS implementations newer than version 3.1.1 are not
# fully supported by this version of dmidecode.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
    Manufacturer: Dell Inc.
    Product Name: 0G7W4R
    Version: A00
    Serial Number: /1XNPZV2/CNFCW008CV00D7/
    Asset Tag: Not Specified
    Features:
    Board is a hosting board
    Board is replaceable
    Location In Chassis: Not Specified
    Chassis Handle: 0x0003
    Type: Motherboard
    Contained Object Handles: 0

Handle 0x0049, DMI type 10, 6 bytes
On Board Device Information
    Type: 

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

Re: relayd.conf error

[Ali H. Fardan]

On 2016-10-16 01:47, trondd wrote:

This has an error:
listen 127.0.0.1 port 7000
This does not:
listen on 127.0.0.1 port 7003

This has an error:
forward with tls to  6697
The rest of your forward to lines do not.


Tim.


Sorry for late response, this mail server went down for a while, anyway,
thanks Tim!

relayd.conf error

[Ali H. Fardan]

Hey misc@, I'm having issues with relayd.conf. this is the error I get
when I try to run relayd:


# rcctl -df start relayd
doing _rc_parse_conf
doing _rc_quirks
relayd_flags empty, using default ><
doing _rc_parse_conf /var/run/rc.d/relayd
doing _rc_quirks
doing rc_check
relayd
doing rc_pre
host_dns: chat.freenode.net resolves to more than 1 hosts
host_dns: irc.oftc.net resolves to more than 1 hosts
/etc/relayd.conf:11: syntax error
/etc/relayd.conf:12: protocol irctls defined twice
/etc/relayd.conf:17: syntax error
/etc/relayd.conf:18: protocol irctls defined twice
/etc/relayd.conf:23: syntax error
/etc/relayd.conf:24: protocol irctls defined twice
/etc/relayd.conf:31: syntax error
no actions, nothing to do
doing _rc_rm_runfile
(failed)
#


using this config:


# cat /etc/relayd.conf
protocol "irctls" {
tcp { nodelay, sack }
}

table { chat.freenode.net }
table { irc.oftc.net }
table{ irc.swepipe.se }
table { irc.krustykrab.restaurant }

relay "freenode" {
listen 127.0.0.1 port 7000
protocol "irctls"
forward with tls to  port 6697
}

relay "oftc" {
listen 127.0.0.1 port 7001
protocol "irctls"
forward with tls to  port 6697
}

relay "efnet" {
listen 127.0.0.1 port 7002
protocol "irctls"
forward with tls to  port 6697
}

relay "volatile" {
listen on 127.0.0.1 port 7003
protocol "irctls"
forward with tls to  6697
}
#


by the way, this config used to work the last time I tried it on my
last server, not this though, have relayd.conf syntax change in last
update?

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.

Re: OpenBSD -current AHCI on HP Probook 450 G0

[ali]

Atanas Vladimirov vlado at bsdbg.net writes:

 
 Hi,
 This is the first time when I try to install OpenBSD on a such hardware.
 I used bsd.rd to install it on a usb flash drive. After reboot I choose 
 to boot from the usb drive.
 Bootloader can't load bsd kernel and the laptop restarts without error.
 If I change SATA mode in BIOS from AHCI to IDE I can boot from the usb 
 drive.

I have the same problem with my HP ProBook 4530s. I don't want to switch
to AHCI. Is there another way to install OpenBSD?

Je sur comptable a la banque BCB je vais virée $6.million a la etranger

[Saidou Ali]

Invitationnbsp;: Je sur comptable a la banque BCB je vais virie $6.million a 
la etranger.


Par votre htte Saidou Ali:


 Date:  mercredi 12 ao{t 2009

 Heure: 19h 00 - 20h 00 (GMT+00:00)
 Lieu:  Cher Ami Salut, Je suis MR, Saidou Ali comptable a la 
BANQUE COMERCIALE DU BURKINA (BCB), je vais virie $6.million (usd) a la 
etranger si vous pour vais me aide ci ga vous intersse je vous enverrons tous 
les ditails sur la fagon dont on va fait le demache et igalement noter que vous 
aurez 30% du montant indiqui .si vous jtes d'accord pour m'aider ` exicuter 
cette transaction. reponne moi rapidement et s.v.p ces un propossition 
confidentielle merci

Invitis:

 * gagnee...@yahoo.ca
 * astor...@yahoo.ca
 * mtbc...@yahoo.ca
 * bobdo...@yahoo.ca
 * blanc_...@yahoo.ca
 * theonlyone2...@yahoo.ca
 * denil...@yahoo.ca
 * tremblayyves2...@yahoo.ca
 * associationdesbouc...@yahoo.ca
 * lefjordtil...@yahoo.ca
 * matoma...@yahoo.ca
 * diaguy...@yahoo.ca
 * sproage...@yahoo.ca
 * fete_ad...@yahoo.ca
 * laquetejour...@yahoo.ca
 * hameaulacv...@yahoo.ca
 * nuage892...@yahoo.ca
 * gwen99...@yahoo.ca
 * nadous1...@yahoo.ca
 * gauthier.jasm...@yahoo.ca
 * maiso...@yahoo.ca
 * maevam...@yahoo.ca
 * ecolemouve...@yahoo.ca
 * dth...@yahoo.ca
 * pierremauri...@yahoo.ca
 * vicveill...@yahoo.ca
 * transportxtr...@yahoo.ca
 * eric.a...@sympatico.ca
 * misc@openbsd.org
 * energie_...@yahoo.ca
 * marcdaphne_mar...@yahoo.ca
 * mottet.e...@uqam.ca
 * eric.2.lan...@hec.ca
 * dijiany...@yahoo.ca
 * sam3sleb...@yahoo.ca9
 * jaggisin...@yahoo.ca
 * n...@yahoo.ca
 * laluness...@yahoo.ca
 * lagreline...@yahoo.ca
 * sce_v...@yahoo.ca
 * dg.representantafri...@yahoo.fr
 * kerneltrapjaggisin...@yahoo.ca
 * benjamin.constan...@usherbrooke.ca
 * bferi...@yahoo.ca
 * kuu...@yahoo.ca
 * kfys...@yahoo.ca
 * ghislaindesjard...@yahoo.ca
 * gerard_mal...@yahoo.ca
 * mecb...@rogers.com
 * e...@yahoo.ca
 * catay...@cyberus.ca
 * rianeprisca_e...@yahoo.ca
 * sergewebserv...@yahoo.ca
 * aider.qbert_psy...@yahoo.catu
 * cog7winni...@yahoo.ca
 * x5zwx...@yahoo.ca
 * lesetoilescondomini...@yahoo.ca
 * christel_ser...@yahoo.ca
 * csodou...@yahoo.ca
 * will42...@yahoo.ca
 * secretariat...@yahoo.ca
 * rothing...@yahoo.ca
 * mljo...@yahoo.ca
 * retardedc...@yahoo.ca
 * serd...@yahoo.ca
 * josslyn...@yahoo.ca
 * jane45sale...@yahoo.ca
 * lespantheresro...@yahoo.ca
 * le_refuge_...@yahoo.ca
 * spilleds...@yahoo.ca
 * jolie_na...@yahoo.ca
 * mmebrigitte_koffi0...@yahoo.ca
 * jamime...@epochworks.net
 * jyel_ro...@yahoo.ca
 * avinc...@arsece.com
 * cf-pol...@yahoo-inc.comleperegrin
 * yahoo.cacf-webmas...@yahoo-inc.comcf-
 * mdjlasa...@yahoo.ca
 * comgranite...@yahoo.ca
 * isabellemd2...@yahoo.ca

invitation_add_to_your_yahoo_calendar:

 
http://fr.calendar.yahoo.com//?v=60ST=20090812T19%2BTITLE=Je+sur+comptable+a+la+banque+BCB+je+vais+vir%c3%a9e+$6.million+a+la+etrangerDUR=0100VIEW=din_loc=Cher+Ami+Salut,+Je+suis+MR,+Saidou+Ali+comptable+a+la+BANQUE+COMERCIALE+DU+BURKINA+(BCB),+je+vais+vir%c3%a9e+$6.million+(usd)+a+la+etranger+si+vous+pour+vais+me+aide+ci+%c3%a7a+vous+intersse+je+vous+enverrons+tous+les+d%c3%a9tails+sur+la+fa%c3%a7on+dont+on+va+fait+le+demache+et+%c3%a9galement+noter+que+vous+aurez+30%25+du+montant+indiqu%c3%a9+.si+vous+%c3%aates+d%27accord+pour+m%27aider+%c3%a0+ex%c3%a9cuter+cette+transaction.+reponne+moi+rapidement+et+s.v.p+ces+un+propossition+confidentielle+merciTYPE=10


Copyright ) 2009 Tous droits riservis.
 www.yahoo.fr

Donnies personnelles:
 http://privacy.yahoo.com/privacy/us

Conditions d'utilisation:
 http://docs.yahoo.com/info/terms/

Q: How to shop for a laptop to run OpenBSD?

[Ali M.]

Greetings,

I will (hope) to buy a new laptop in a couple of months, how to make
sure that the one I pick will work under OpenBSD.
I understand that there is a list of supported hardware at:
http://www.openbsd.org/i386.html

So should I check the laptop detailed specs and make sure everything
in on that list!
Is this how everyone does it, is there another way?

How up to date is that list, the laptop I get will be new (again I
hope ;), what if I don't find its component on that list?

Any tips like
is there specific brands (Asus, Dell, etc ... ) that are known to be
more OpenBSD friendly than others!
is there brands I should avoid, components and specs that should be
warning signs, I read for example on the OpenBSD site that I should
avoid Nvidia etc 

It would be helpful, if you bought a laptop recently that run Openbsd
smoothly to tell me the model
As i see that
http://www.openbsd.org/i386-laptop.html
is now dead

Regards,
Ali

$30milion business proposal if you are interested reply me or call+22678217398

[Mohammed Ali]

You are invited to $30milion business proposal if you are interested reply me 
or call+22678217398.


By your host Mohammed Ali:


 Date:  Sunday May 18, 2008

 Time:  8:00 am - 9:00 am (GMT +00:00)

Will you attend? RSVP to this invitation at:

 
http://calendar.yahoo.com/mohammed.ali001?v=126a1=0iid=uhBnfgpbIuxC%40JH7JxQNQqd%40oFAbBMnGHpC76F7bW9v%40igid=uhBnfgpbIuxC%40JH7JxQNQqd%409FBbBM7CWpC7MB7fW9v%40

Copyright ) 2008 All Rights Reserved
 www.yahoo.com

Privacy Policy:
 http://privacy.yahoo.com/privacy/us

Terms of Service:
 http://docs.yahoo.com/info/terms/

Re: squid on openbsd 3.7

[Askar Ali]

Karsten McMinn wrote:


On 7/7/05, Askar Ali [EMAIL PROTECTED] wrote:
 


Adam wrote:
I would love if you can gives any other suggestion that could makes
squid performance cool, may be in sysctl.conf?
   



Squid is a cpu, descriptor and disk hog. After you
have allocated the disk space and compiled with
ample available FDs you pretty much just
use an acl to keep its cpu utilization in control.



 

Okay squid is running with desired file descriptors, I just want to 
know, for transparent proxy do I have to reinstall squid by passing some 
arguments during instaling from ports?


Or pf nat rule would be enough ? ( i know howto do nat, and other pf 
stuff)


secondly I want to --enabe-snmp and some other things which are not 
presently enable while I install squid from port...


Squid Cache: Version 2.5.STABLE9
configure options:  --datadir=/usr/local/share/squid 
'--enable-auth=basic digest' '--enable-basic-auth-helpers=NCSA 
YP'--enable-digest-auth-helpers=password 
'--enable-external-acl-helpers=ip_user unix_group' 
'--enable-removal-policies=lruheap' --enable-ssl '--enable-storeio=ufs 
diskd' --localstatedir=/var/squid --prefix=/usr/local --sysconfdir=/etc


squid is installed with the above default configurations, I duno howto 
pass arugment while installing from ports, (heh coming from linux 
background where ./configure blah blah kinda cool)



regards

Askar Ali

Re: squid on openbsd 3.7

[Askar Ali]

Simon Dassow wrote:


On Fri, Jul 08, 2005 at 04:54:51PM +0500, Askar Ali wrote:
[snip]
 

secondly I want to --enabe-snmp and some other things which are not 
presently enable while I install squid from port...


Squid Cache: Version 2.5.STABLE9
configure options:  --datadir=/usr/local/share/squid 
'--enable-auth=basic digest' '--enable-basic-auth-helpers=NCSA 
YP'--enable-digest-auth-helpers=password 
'--enable-external-acl-helpers=ip_user unix_group' 
'--enable-removal-policies=lruheap' --enable-ssl '--enable-storeio=ufs 
diskd' --localstatedir=/var/squid --prefix=/usr/local --sysconfdir=/etc


squid is installed with the above default configurations, I duno howto 
pass arugment while installing from ports, (heh coming from linux 
background where ./configure blah blah kinda cool)
   



Hi Askar,
start reading the manpages... for example bsd.port.mk(5) [1]
to get more information about ports and flavors. There's also the famous
FAQ [2] and the archives.

Your actual problem may lead to:
$ cd /usr/ports/www/squid  env FLAVOR=transparent snmp sudo make


Regards,
Simon

[1] bsd.port.mk(5) 
http://www.openbsd.org/cgi-bin/man.cgi?query=bsd.port.mk#FLAVORS+AND
[2] FAQ http://cvs.openbsd.org/faq/



 


yep mate i'm reading man, :)

what i did vi Makefile and then put all teh --enable lines what i need.

CONFIGURE_ARGS+=--datadir=${PREFIX}/share/squid \
   --enable-auth=basic digest \
   --enable-basic-auth-helpers=NCSA YP \
   --enable-digest-auth-helpers=password \
   --enable-external-acl-helpers=ip_user unix_group \
   --enable-removal-policies=lru heap \
   --enable-ssl \
   --enable-poll \
   --enable-pf-transparent \
   --enable-snmp \
   --enable-delay-pools \
   --enable-htcp \
   --enable-storeio=ufs diskd \
   --localstatedir=${SQUIDDIR}


aren't this the recommended approach ?


regards

Askar

squid on openbsd 3.7

[Askar Ali]

Hi,

I'm trying to configure squid on 3.7, everything working fine just 
one thing. I want to run squid with 8192 file descriptor or more, till 
without any success :)


I had install squid-2.5.STABLE10-transparent-snmp.tgz 
ftp://mirror.switch.ch/pub/OpenBSD/3.7/packages/i386/squid-2.5.STABLE10-transparent-snmp.tgz 
from pkg then...

and properly configured squid.conf.
1) Increase the maxfiles via sysctl -w kern.maxfiles = 

2) before running/starting squid I didn't forget to ulimit -HSn  (as 
root)


3) I also tried to created a login class for _squid user in /etc/login.conf

with this in it

squid:\
   :datasize-cur=75M:\
   :datasize-max=infinity:\
   :maxproc-max=256:\
   :openfiles-cur=8192:\
   :maxproc-cur=128:\
   :ignorenologin:\
   :requirehome@:\
   :tc=default:

and

#usermod -L squid _squid (to change the _squid login class)

However nothing gives me increase in file descriptors for squid, each 
time I run squid cache.log and cachemrg shows me that With 1024 file 
descriptors available DAMN!


What I'm missing?

I also love to hear honestly is openbsd good for cache/proxy servers 
(serving more then 500 users or more)?


Regards

Askar Ali

Re: clamav package upgrade

[Askar Ali]

J. Lievisse Adriaanse wrote:


On Tue, 21 Jun 2005 10:58:12 -0300
FBN [EMAIL PROTECTED] wrote:

 


Hi

I had installed clamav-0.83.tgz package in my OpenBSD 3.7, but it displays:

LibClamAV Warning: 
LibClamAV Warning: ***  This version of ClamAV engine is outdated.  ***
LibClamAV Warning: *** Please update it IMMEDIATELY!***
LibClamAV Warning: 
Do i have to uninstall the clamav package and install it again from source ?

Thanks 
   



Version 0.85.1 is in the ports collection. So you can try that instead.

Good luck,
Jasper 




 

clamav will not function properly i-e will not block latest viri if you 
don't use the latest clamav version, and yep they had released 0.86 
yesterday, therefore go for it.



regards

Askar