Re: booting and RAID-5
On 2024-06-17, Stuart Henderson wrote: > On 2024-06-15, Marco van Hulten wrote: >> Hello, >> >> I got a new amd64 system with 3 NVMe disks of each 2 TB, with the idea >> to put them in RAID-5. I did not realise until now that one cannot >> boot from RAID-5. > > Why do you want to run three drives in softraid RAID5? > > You'll get the same capacity with three drives in RAID1, and it will > be simpler and much easier to recover in a failure situation. hmm, think I need coffee before doing such complicated calculations. oops. -- Please keep replies on the mailing list.
Re: booting and RAID-5
On 2024-06-15, Marco van Hulten wrote: > Hello, > > I got a new amd64 system with 3 NVMe disks of each 2 TB, with the idea > to put them in RAID-5. I did not realise until now that one cannot > boot from RAID-5. Why do you want to run three drives in softraid RAID5? You'll get the same capacity with three drives in RAID1, and it will be simpler and much easier to recover in a failure situation.
Re: booting and RAID-5
On Sun, 16 Jun 2024 11:57:13 -0400 Nick Holland wrote: > On 6/15/24 09:05, Marco van Hulten wrote: > > Hello, > > > > I got a new amd64 system with 3 NVMe disks of each 2 TB, with the > > idea to put them in RAID-5. I did not realise until now that one > > cannot boot from RAID-5. > > > > Would a good approach be to create a root device on one disk (and > > maybe altroots on one or both of the others) and use the rest of > > all disks as RAID-5 device? Or is there a good reason to boot from > > a disk separate from the envisioned RAID-5 configuration? > > I just set something up like this, myself. Four 4T disks. I wanted > redundancy but also recoverability. > > My solution: > [...] Thank you, Nick. This is a big help. Using RAID-1 for this, as also suggested by Kirill and an off-list poster, seemed like a good idea, and no need for an altroot. Before I read your message, I did an installation with a small (1.5 G) RAID-1 installation with only root. Besides the missed benefit of having a full base system on each drive, it also had problems with installboot(8) at the end of the installation. It could not find /usr/mdec/biosboot, which I guess could have been because I had /usr on a different device (the RAID-5 device). Then I redone it with a 60 GB RAID-1 device, including /, swap, /usr, /usr/X11R6, /tmp and /var. The other partitions went to the large RAID-5 device. This worked! I only have to test if removing drives works, and if I have no access to RAID-5 I can still boot the system to the point I can login and run base-system commands. Marco
Re: booting and RAID-5
On 6/15/24 09:05, Marco van Hulten wrote:
Hello,
I got a new amd64 system with 3 NVMe disks of each 2 TB, with the idea
to put them in RAID-5. I did not realise until now that one cannot
boot from RAID-5.
Would a good approach be to create a root device on one disk (and maybe
altroots on one or both of the others) and use the rest of all disks as
RAID-5 device? Or is there a good reason to boot from a disk separate
from the envisioned RAID-5 configuration?
I just set something up like this, myself. Four 4T disks. I wanted
redundancy but also recoverability.
My solution:
each drive has a 25G disklabel partition and a "almost rest of drive"
disklabel partition ("almost rest" because I'm paranoid about having
to someday replace the drive, and finding the new drive is a thousand
sectors smaller than the old drives. This hasn't been much of a problem
in my observation lately, but I'm old, I remember when Seagate shipped
two drives with the exact same model number, but the replacement drive
had one less cylinder than the original drive...not fun!).
The 25G partitions are in a four drive RAID1, and the "rest of drive"
partitions are in a RAID5 config. The base OS and all standard
partitions is in that 25G array, the "rest of drive" is all data storage.
So..if I lose a drive (or several), I should be able to boot at least
the core OS and get some idea what went wrong. If you need a larger
core OS system, go for it. I do NOT recommend putting just the root
partition on this drive. Make it stand-alone useful.
At this point, some of the kids start screaming, "you can't do a
four drive RAID1!". Yes you can. The fact that your HW RAID card
can't, doesn't mean it's an invalid concept. softraid (and at least
some other software RAID systems) handles >2 drives in a RAID1
config seemingly just fine. It's four copies of the same data.
Stunningly inefficient, not very fast for writes but very robust.
And, what else am I supposed to do with the 25G empty space on the
other drives, anyway? :) (a further benefit -- if I have to swap the
drives to another physical machine, ANY of the drives will able to be
booted, I don't have to make sure I get the right drive in the "drive 0"
position).
One big word of warning: when you have to replace a drive on a system
like this...rebuild one array than the other. You probably don't want
to have the system thrashing between the two partitions on the same disk;
that's a great way to turn a slow process into a glacial process (though
probably not so big a deal with SSDs as it is with spinning drives). So
when I test the drive replacement process, I plan to rebuild the OS
partition first (anticipated time: minutes), then the data partition
later (anticipated time: days).
And yes, I'm testing the behaviors of this thing and the drive replacement
process before I commit it to production.
Nick.
Re: booting and RAID-5
On Sat, 15 Jun 2024 14:05:07 +0100, Marco van Hulten wrote: > > Would a good approach be to create a root device on one disk (and maybe > altroots on one or both of the others) and use the rest of all disks as > RAID-5 device? Or is there a good reason to boot from a disk separate > from the envisioned RAID-5 configuration? > Why not use dedicated RAID-1 for / instead? -- wbr, Kirill
booting and RAID-5
Hello, I got a new amd64 system with 3 NVMe disks of each 2 TB, with the idea to put them in RAID-5. I did not realise until now that one cannot boot from RAID-5. Would a good approach be to create a root device on one disk (and maybe altroots on one or both of the others) and use the rest of all disks as RAID-5 device? Or is there a good reason to boot from a disk separate from the envisioned RAID-5 configuration? Thanks, Marco
Re: Sudden reboot every 5-10 minutes on latest snapshot
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: > > > > > > 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
Re: Sudden reboot every 5-10 minutes on latest snapshot
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 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/X11. > This would confirm that the hardware is still OK. I used my Windows 11 a lot and never seen any sudden reboot in Windows at all; so I think maybe it is not a hardware issue, but amdgpu issue. > Take few quick notes > of what devices are involved, how the machine is used, etc. Save the > dmesg. Most of the time I never
Re: Sudden reboot every 5-10 minutes on latest snapshot
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. This would confirm that the hardware is still OK. Take few quick notes of what devices are involved, how the machine is used, etc. Save the dmesg. If this isn't a hardware problem, then grab a new snapshot and try to understand what changed, compare the dmesg, compare the usage pattern etc. Possibly start bissecting the kernel until you find the change that causes the reboots. HTH
Re: Sudden reboot every 5-10 minutes on latest snapshot
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. 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). 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. [1] https://marc.info/?l=openbsd-misc=171646884302309=2
Re: Sudden reboot every 5-10 minutes on latest snapshot
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
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.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
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".
Then, just do your regular stuff and see if the system reboots.
Re: Sudden reboot every 5-10 minutes on latest snapshot
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...
> 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
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?
when you apply above diff, is audio unstable or it doesn't work at
all?
Re: Sudden reboot every 5-10 minutes on latest snapshot
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
> >
Re: Sudden reboot every 5-10 minutes on latest snapshot
On 2024/05/23 12:12, Ali Farzanrad wrote: > 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? 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 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/ Rade
Re: Sudden reboot every 5-10 minutes on latest snapshot
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
Re: Sudden reboot every 5-10 minutes on latest snapshot
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? Is X running? Do you get the same with 7.5? if yes, try older releases - can you find one where it doesn't happen? > > # (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 &
Sudden reboot every 5-10 minutes on latest snapshot
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
OpenBSD 7.5 released: Apr 5
- OpenBSD 7.5 RELEASED -
April 5, 2024.
We are pleased to announce the official release of OpenBSD 7.5.
This is our 56th release. We remain proud of OpenBSD's record of more
than twenty years with only two remote holes in the default install.
As in our previous releases, 7.5 provides significant improvements,
including new features, in nearly all areas of the system:
- Various kernel improvements:
o Added bt(5) and btrace(8) support for binary modulo operator
('%').
o Added a TIMEOUT_MPSAFE flag to timeout(9).
o Added IBM encoded version of the "Spleen 8x16" font, usable as
console font.
o Cleanup and machine-independent refactoring of three context
switch paths outside of mi_switch(): when a process forks and the
new proc needs to be scheduled by proc_trampoline, cpu_hatch: when
booting APs, and sched_exit: when a proc exits.
o Made vscsi(4) 'vscsi_filtops' mpsafe and extended the
'sc_state_mtx' mutex(9) to protect 'sc_klist' knotes list.
o Made out-of-swap checking more robust, preventing potential
deadlocks.
o Eliminated the ioctl whitelist that bio(4) will tunnel for other
devices, allowing bio to be used with other (non-raid) related
devices.
o On msdos filesystems, ensure that a complete struct fsinfo is read
even if the filesystem sectors are smaller.
o Implemented per-CPU caching for the page table page (vp) pool and
the PTE descriptor (pted) pool in the arm64 pmap implementation.
This significantly reduces the side-effects of lock contention on
the kernel map lock and leads to significant speedups on machines
with many CPU cores.
o Implemented acpi(4) RootPathString support in the LoadTable() AML
function, fixing OpenBSD boot on an older version of Hyper-V.
o Fixed Linux NFS clients freezing after five minutes of inactivity.
o Fixed core file writing when a file map into memory has later been
truncated to be smaller than the mapping.
o Disallow madvise(2) and msync(2) memory/mapping destructive
operations on immutable memory regions. Instead return EPERM.
o Added new amd64-only sysctl machdep.retpoline which says whether
the cpu requires the retpoline branch target injection mitigation.
o Added new accounting flag ABTCFI to acct(5) to indicate SIGILL +
code ILL_BTCFI has occurred in the process.
- SMP Improvements
o Some network timers run without kernel lock.
o TCP syn cache timer runs with shared net lock.
o bind(2) and connect(2) system calls can run in parallel.
o Packet counter for lo(4) loopback interface are MP safe.
o Split protocol control block table for UDP into IPv4 and IPv6
tables to allow concurrent access.
o UDP packets can be sent in parallel by multiple threads.
- Direct Rendering Manager and graphics drivers
o Updated drm(4) to Linux 6.6.19.
o New apldcp(4) and apldrm(4) drivers for Apple display coprocessor.
- VMM/VMD improvements
o Fixed IRQ storm caused by edge-triggered devices such as the UART.
o Fixed block size calculation for vioscsi devices.
o Added io instruction length to vm exit information, allowing
vmd(8) to perform validation in userspace.
o Adopted new imsg_get_*(3) api.
o Rewrote vionet devices to allow zero-copy data transfers between
host and guest.
o Improved error messages related to getgrnam(3) usage and out of
tap(4) device conditions.
o Fixed various things found by smatch static analyzer.
o Fixed various file descriptor lifecycle issues and leaks across
fork(2)/ execve(2) usage.
o Added multi-threading support to vionet device emulation,
improving latency.
o Fixed vmm(4) instability on Intel VMX hosts by updating GDTR & TR
if vcpu moves host cpus.
o Added EPT flushing upon vmm(4) enabling VMX mode.
o Added branch predictor flushing if IBPB is supported.
o Corrected restoring GDTR and IDTR limits upon VMX guest exit.
o Corrected handling of CPUID 0xd subleaves
o Added additional use of VERW and register clobbering to mitigate
RFDS vulnerabilities on Intel Atom cores.
- Various new userland features:
o Made malloc(3) save backtraces to show in leak dump with depth of
backtrace set via malloc option D (aka 1), 2, 3 or 4.
o Added support for cksum(1) -c checking base64 digests in reverse
mode.
o Added kdump(1) [-p program] to filter dumps by basename.
o Made ps(1) accept numerical user IDs.
o Built and provide the tzdata.zi and leap-seconds.list files from
zoneinfo. Some third-party software now expects these files to be
installed. Provide the zonenow.tab file, a table where each row
stands for a timezone where civil timestamps are predicted to
Re: Is CRONTAB(5) random really random ?
On Fri, Jan 06, 2023 at 12:58:48AM +0100, Rachel Roch wrote: > > > > 5 Jan 2023, 18:24 by purushar...@gmx.com: > > > Namaste Rachel, Theo(s), > > > >> Sent: Thursday, January 05, 2023 at 5:50 PM > >> From: "Theo de Raadt" > >> To: "Theo Buehler" > >> Cc: "Rachel Roch" , "Misc" > >> Subject: Re: Is CRONTAB(5) random really random ? > >> > >> Theo Buehler wrote: > >> > >> > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > >> > > According to the docs : > >> > > > >> > > > A random value (within the legal range) may be obtained by using > >> > > > the ???~??? character in a field. > >> > > >> > The random numbers are drawn once and then repeated regularly. This > >> > behavior has always bothered me but never enough to spend the time > >> > needed to fix it (it's not immediately obvious how to do it). A > >> > workaround is to use a > >> > > >> > sleep $((RANDOM \% 512)) && run_whatever > >> > > >> > construct. The number to the right of the modulo should be a power of 2 > >> > to avoid modulo bias. > >> > >> Any solution would need to be careful, so that a operation doesn't run > >> multiple times in an hour. Each column should be '0 + random % range', > >> but multiple columns contain ~, it gets weird. > >> > > > > The following thread may be helpful: > > > > "Regarding randomized times in crontab" > > https://marc.info/?l=openbsd-misc=158705405304672=2 > > > > Dhanyavaad, > > Dharma Artha Kama Moksha > > > > Thank you all for your insightful input, looks like the $RANDOM prefix idea > is the only quick-fix to this. > > I didn't realise the random value was only set once. Maybe someone should > update the man page accordingly ? > To be clear, it is "once per ~ occurrence in the crontab", not once for all ~ or once per crontab line. -Otto
Re: Is CRONTAB(5) random really random ?
5 Jan 2023, 18:24 by purushar...@gmx.com: > Namaste Rachel, Theo(s), > >> Sent: Thursday, January 05, 2023 at 5:50 PM >> From: "Theo de Raadt" >> To: "Theo Buehler" >> Cc: "Rachel Roch" , "Misc" >> Subject: Re: Is CRONTAB(5) random really random ? >> >> Theo Buehler wrote: >> >> > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: >> > > According to the docs : >> > > >> > > > A random value (within the legal range) may be obtained by using >> > > > the ‘~’ character in a field. >> > >> > The random numbers are drawn once and then repeated regularly. This >> > behavior has always bothered me but never enough to spend the time >> > needed to fix it (it's not immediately obvious how to do it). A >> > workaround is to use a >> > >> >sleep $((RANDOM \% 512)) && run_whatever >> > >> > construct. The number to the right of the modulo should be a power of 2 >> > to avoid modulo bias. >> >> Any solution would need to be careful, so that a operation doesn't run >> multiple times in an hour. Each column should be '0 + random % range', >> but multiple columns contain ~, it gets weird. >> > > The following thread may be helpful: > > "Regarding randomized times in crontab" > https://marc.info/?l=openbsd-misc=158705405304672=2 > > Dhanyavaad, > Dharma Artha Kama Moksha > Thank you all for your insightful input, looks like the $RANDOM prefix idea is the only quick-fix to this. I didn't realise the random value was only set once. Maybe someone should update the man page accordingly ?
Re: Is CRONTAB(5) random really random ?
Namaste Rachel, Theo(s), > Sent: Thursday, January 05, 2023 at 5:50 PM > From: "Theo de Raadt" > To: "Theo Buehler" > Cc: "Rachel Roch" , "Misc" > Subject: Re: Is CRONTAB(5) random really random ? > > Theo Buehler wrote: > > > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > > > According to the docs : > > > > > > > A random value (within the legal range) may be obtained by usingthe > > > > ‘~’ character in a field. > > > > The random numbers are drawn once and then repeated regularly. This > > behavior has always bothered me but never enough to spend the time > > needed to fix it (it's not immediately obvious how to do it). A > > workaround is to use a > > > > sleep $((RANDOM \% 512)) && run_whatever > > > > construct. The number to the right of the modulo should be a power of 2 > > to avoid modulo bias. > > Any solution would need to be careful, so that a operation doesn't run > multiple times in an hour. Each column should be '0 + random % range', > but multiple columns contain ~, it gets weird. > > The following thread may be helpful: "Regarding randomized times in crontab" https://marc.info/?l=openbsd-misc=158705405304672=2 Dhanyavaad, Dharma Artha Kama Moksha
Re: Is CRONTAB(5) random really random ?
Theo Buehler wrote: > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > > According to the docs : > > > > > A random value (within the legal range) may be obtained by usingthe > > > ‘~’ character in a field. > > The random numbers are drawn once and then repeated regularly. This > behavior has always bothered me but never enough to spend the time > needed to fix it (it's not immediately obvious how to do it). A > workaround is to use a > > sleep $((RANDOM \% 512)) && run_whatever > > construct. The number to the right of the modulo should be a power of 2 > to avoid modulo bias. Any solution would need to be careful, so that a operation doesn't run multiple times in an hour. Each column should be '0 + random % range', but multiple columns contain ~, it gets weird.
Re: Is CRONTAB(5) random really random ?
On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > According to the docs : > > > A random value (within the legal range) may be obtained by usingthe ‘~’ > > character in a field. The random numbers are drawn once and then repeated regularly. This behavior has always bothered me but never enough to spend the time needed to fix it (it's not immediately obvious how to do it). A workaround is to use a sleep $((RANDOM \% 512)) && run_whatever construct. The number to the right of the modulo should be a power of 2 to avoid modulo bias.
Re: [SPAM?] Is CRONTAB(5) random really random ?
Am Do., 5. Jan. 2023 um 18:16 Uhr schrieb Rachel Roch : > Especially given three of my crontab fields are supposed to be random > (minute, hour, day-of-month) I would expect to see at least one of the three > to be different ?!? AFAIK there is only one random value and it's created at startup of the daemon. Best Martin
Is CRONTAB(5) random really random ?
According to the docs : > A random value (within the legal range) may be obtained by usingthe ‘~’ > character in a field. However I've been running release versions of OpenBSD with the following definition: ~ ~ ~ * * /my/task/goes/here && /usr/bin/logger -t foo "Task done" Feb 18 18:09:01 foobar foo: Task done Mar 18 18:09:01 foobar foo: Task doneMar 24 23:42:01 foobar foo: Task doneApr 20 11:41:01 foobar foo: Task doneMay 16 18:24:01 foobar foo: Task doneJun 6 17:24:01 foobar foo: Task doneJul 6 17:24:01 foobar foo: Task doneAug 6 17:24:01 foobar foo: Task doneSep 6 17:24:01 foobar foo: Task doneOct 6 17:24:01 foobar foo: Task doneOct 31 08:44:01 foobar foo: Task doneNov 19 12:02:01 foobar foo: Task doneDec 19 12:02:02 foobar foo: Task done Surely it would be clutching at straws to describe an event happening at exactly the same time 5 months in a row (Jun–Oct) as genuinely statistically random ? The same with Nov & Dec. Especially given three of my crontab fields are supposed to be random (minute, hour, day-of-month) I would expect to see at least one of the three to be different ?!?
Recently acquired Ryzen 5 computer lacks sound with OpenBSD 7.1.
The computer has a Ryzen 5 4600G processor, as well as AMD High Def and Realtek audio. I have tried unsuccessfully to get audio through the HDMI connection as well as a Behringer UMC20HD USB sound card. I have looked at the relevant man pages and tried to solve this on Reddit. It has been suggested that I try the fount of all OpenBSD wisdom, so I am posting here. The relevant outputs (thanks to Reddit feedback) can be found here: https://pastebin.com/2rvjWuD7 https://pastebin.com/W26cMyMZ My Reddit post can be found here: https://www.reddit.com/r/openbsd/comments/ydsgo2/recently_acquired_ryzen_5_computer_lacks_sound/ I really like this computer, as OpenBSD appears to run well from it so far, so I am hoping the audio issue can be solved...
Re: Question regarding queueing in pf.conf(5) and WireGuard
You should apply queue on interface attached to network you want to limit
banwidth from. For example if your home network attached to 1GB em1 and you
want to limit web for certain ip addresses, perhaps something like this will
work
...
table { ip addrs list }
queue lanq on em1 bandwidth 950M
queue landefq parent lanq bandwidth 950M qlimit 1024 default
queue slowweb parent lanq bandwidth 32K max 64K
match in on em1 proto tcp from to port { www https } set queue slowweb
match out on egress inet from !(egress:network) to any nat-to (egress:0)
...
Some examples on Solene`s page:
https://dataswamp.org/~solene/2021-02-07-limit.html
And also there is a Book of PF written by Peter N. M. Hansteen
On Mon, Jun 14, 2021 at 11:59:59AM -0600, Ashlen wrote:
> Hello. I have an APU4D4 running OpenBSD and acting as a router for my
> home network. It connects to the Internet via pppoe(4), which uses em(4)
> as the physical interface.
>
> The router has a /etc/hostname.wg0 file that connects it as a client to
> my VPN provider on boot. Then, /etc/pf.conf has a nat-to rule for
> WireGuard, for IP masquerading. Here's said rule:
>
> match out on wg inet from !(wg:network) to any nat-to (wg:0)
>
> In pf.conf(5), there's mention of this simple configuration
> for bandwidth control:
>
> queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \
>default
>
> I want to employ this rule. My question is, which interface is
> appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0,
> as I'm unsure how pf(4) would classify traffic otherwise. However, I'm
> not confident in that conclusion, so I decided to ask.
>
> If additional details are needed, I'm happy to provide them.
>
> --
> https://amissing.link
>
Question regarding queueing in pf.conf(5) and WireGuard
Hello. I have an APU4D4 running OpenBSD and acting as a router for my home network. It connects to the Internet via pppoe(4), which uses em(4) as the physical interface. The router has a /etc/hostname.wg0 file that connects it as a client to my VPN provider on boot. Then, /etc/pf.conf has a nat-to rule for WireGuard, for IP masquerading. Here's said rule: match out on wg inet from !(wg:network) to any nat-to (wg:0) In pf.conf(5), there's mention of this simple configuration for bandwidth control: queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ default I want to employ this rule. My question is, which interface is appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0, as I'm unsure how pf(4) would classify traffic otherwise. However, I'm not confident in that conclusion, so I decided to ask. If additional details are needed, I'm happy to provide them. -- https://amissing.link
Re: tc= in remote(5) example
Jan Stary wrote: > /etc/examples/remote contains the following stanzas: > > unixhost:\ > :br#9600: > > cua00|For i386,macppc:\ > :dv=/dev/cua00:tc=unixhost: > > cuaa|For sparc:\ > :dv=/dev/cuaa:tc=unixhost: > > > The remote(5) manpage describes br, dc, dv > but not tc, which seems to be used here as an include. > Is it described elsewhere or is that an omission? The second sentence of the manual page is: It is an ASCII file structured somewhat like the termcap(5) file. That is slightly erroneous. It is not "somewhat like", but "precisely like". Around 4.4BSD this format was generalized for other purposes also, and renamed "capability database", with cap_mkdb(1) and cgetent(3) functions. Thus, the cu(1) code uses the cgetent(3) family of library functions, and thus gains the "tc" capability, which is similar to cpp "include". Other "capability database" format details not documented in remote(5) percolate up (for example, the behaviour of '\' is not entirely intuitive), and these narrow details are not documented in remote(5) either... how far should this go? As to where "tc" is documented: In termcap(5), "tc" is explained thus: tc str Entry of similar terminal; must be last. I'll admit that is poor and vague. It is explained carefully in the cgetent(3) manual page, in the subsection "Capability database semantics", but that page isn't Xr'd, and the subsection is so far down the page I am not sure a reader would scan far enough down to learn anything. I don't know what precisely should be done.
Re: tc= in remote(5) example
On Thu, February 18, 2021 11:38 am, Jan Stary wrote: > /etc/examples/remote contains the following stanzas: > > unixhost:\ > :br#9600: > > cua00|For i386,macppc:\ > :dv=/dev/cua00:tc=unixhost: > > cuaa|For sparc:\ > :dv=/dev/cuaa:tc=unixhost: > > > The remote(5) manpage describes br, dc, dv > but not tc, which seems to be used here as an include. > Is it described elsewhere or is that an omission? > > Jan > References are at the top of the example file. The most complete description of tc is probably in cgetcap(3).
tc= in remote(5) example
/etc/examples/remote contains the following stanzas: unixhost:\ :br#9600: cua00|For i386,macppc:\ :dv=/dev/cua00:tc=unixhost: cuaa|For sparc:\ :dv=/dev/cuaa:tc=unixhost: The remote(5) manpage describes br, dc, dv but not tc, which seems to be used here as an include. Is it described elsewhere or is that an omission? Jan
Re: Suggestion for small improvement in acme-client.conf.5
On Sat, Jan 09, 2021 at 05:08:14PM +0100, Wolf wrote: > Hello, > > I have small suggestion for improving man page for acme-client.conf.5. > Basically just adding "comma separated" to clarify on the format of the > list for alternative names. I had to dig into the parser.y to figure > this out, so it would be nice to have it documented. > hi. a modified version of this diff now committed. thanks, jmc > diff --git a/acme-client.conf.5 b/acme-client.conf.5 > index 7971fb6..a47a8e2 100644 > --- a/acme-client.conf.5 > +++ b/acme-client.conf.5 > @@ -125,9 +125,9 @@ If not specified, the > .Ar handle > of the domain block will be used as common name. > .It Ic alternative names Brq ... > -Specify a list of alternative names for which the certificate will be valid. > -The common name is included automatically if this option is present, > -but there is no automatic conversion/inclusion between "www." and > +Specify a comma separated list of alternative names for which the certificate > +will be valid. The common name is included automatically if this option is > +present, but there is no automatic conversion/inclusion between "www." and > plain domain name forms. > .It Ic domain key Ar file Op Ar keytype > The private key file for which the certificate will be obtained. > > > Have a nice day, > W. > > -- > There are only two hard things in Computer Science: > cache invalidation, naming things and off-by-one errors.
Re: Suggestion for small improvement in acme-client.conf.5
Hello, On 2021-01-09 22:20:26 +, Stuart Henderson wrote: > On 2021-01-09, Wolf wrote: > > I have small suggestion for improving man page for acme-client.conf.5. > > Basically just adding "comma separated" to clarify on the format of the > > list for alternative names. I had to dig into the parser.y to figure > > this out, so it would be nice to have it documented. > > Thanks, but commas are optional, whitespace is fine here too, > so I don't think this change makes sense directly. Oh, now I see it. I didn't check far enough through the grammar, I saw token `comma' and assumed it is, well a comma. You are right, comma can also be nothing. Sorry for not checking properly in the first place. Have a nice day, W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Suggestion for small improvement in acme-client.conf.5
On 2021-01-09, Wolf wrote: > I have small suggestion for improving man page for acme-client.conf.5. > Basically just adding "comma separated" to clarify on the format of the > list for alternative names. I had to dig into the parser.y to figure > this out, so it would be nice to have it documented. Thanks, but commas are optional, whitespace is fine here too, so I don't think this change makes sense directly. > diff --git a/acme-client.conf.5 b/acme-client.conf.5 > index 7971fb6..a47a8e2 100644 > --- a/acme-client.conf.5 > +++ b/acme-client.conf.5 > @@ -125,9 +125,9 @@ If not specified, the > .Ar handle > of the domain block will be used as common name. > .It Ic alternative names Brq ... > -Specify a list of alternative names for which the certificate will be valid. > -The common name is included automatically if this option is present, > -but there is no automatic conversion/inclusion between "www." and > +Specify a comma separated list of alternative names for which the certificate > +will be valid. The common name is included automatically if this option is btw, please use a new line for a new sentence in manpages. > +present, but there is no automatic conversion/inclusion between "www." and > plain domain name forms. > .It Ic domain key Ar file Op Ar keytype > The private key file for which the certificate will be obtained. > > > Have a nice day, > W. >
Suggestion for small improvement in acme-client.conf.5
Hello, I have small suggestion for improving man page for acme-client.conf.5. Basically just adding "comma separated" to clarify on the format of the list for alternative names. I had to dig into the parser.y to figure this out, so it would be nice to have it documented. diff --git a/acme-client.conf.5 b/acme-client.conf.5 index 7971fb6..a47a8e2 100644 --- a/acme-client.conf.5 +++ b/acme-client.conf.5 @@ -125,9 +125,9 @@ If not specified, the .Ar handle of the domain block will be used as common name. .It Ic alternative names Brq ... -Specify a list of alternative names for which the certificate will be valid. -The common name is included automatically if this option is present, -but there is no automatic conversion/inclusion between "www." and +Specify a comma separated list of alternative names for which the certificate +will be valid. The common name is included automatically if this option is +present, but there is no automatic conversion/inclusion between "www." and plain domain name forms. .It Ic domain key Ar file Op Ar keytype The private key file for which the certificate will be obtained. Have a nice day, W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Kde Plasma 5 package missing
Awesome, i`ve installed Lumina, thank you for the tip. Happy holidays! El mié, 23 dic 2020 a las 17:09, Stuart Henderson () escribió: > On 2020-12-23, Manuel Solis wrote: > > Hello Misc, > > > > I am trying to instal KDE, 4 as allways or 5 if avairable, on mi Inspiron > > 1464 laptop, since i have been using FVWM too long, im having trouble > > looking at the right package, could someone point me in the right > > direction? > > > > I did try to install kdebase, version 3, and i gotta say its wonderful > and > > beautiful, but i would like to have dolphin, since the cannot coexist, i > > would like to install a more recent version. > > I did install dolphin and a few more version 5 packages, but i could not > > see the main one as in version3. > > > > Thank you and happy holidays :D > > Ports has nearly all KDE5 frameworks libraries and applications but > not the desktop environment. > > KDE3 is removed in -current, btw. > > If you're looking for a Qt-based desktop environment that's available on > OpenBSD I think your choices are currently lxqt or lumina. > > > -- Lic. Manuel Solís Vázquez
Re: Kde Plasma 5 package missing
On 2020-12-23, Manuel Solis wrote: > Hello Misc, > > I am trying to instal KDE, 4 as allways or 5 if avairable, on mi Inspiron > 1464 laptop, since i have been using FVWM too long, im having trouble > looking at the right package, could someone point me in the right > direction? > > I did try to install kdebase, version 3, and i gotta say its wonderful and > beautiful, but i would like to have dolphin, since the cannot coexist, i > would like to install a more recent version. > I did install dolphin and a few more version 5 packages, but i could not > see the main one as in version3. > > Thank you and happy holidays :D Ports has nearly all KDE5 frameworks libraries and applications but not the desktop environment. KDE3 is removed in -current, btw. If you're looking for a Qt-based desktop environment that's available on OpenBSD I think your choices are currently lxqt or lumina.
Kde Plasma 5 package missing
Hello Misc, I am trying to instal KDE, 4 as allways or 5 if avairable, on mi Inspiron 1464 laptop, since i have been using FVWM too long, im having trouble looking at the right package, could someone point me in the right direction? I did try to install kdebase, version 3, and i gotta say its wonderful and beautiful, but i would like to have dolphin, since the cannot coexist, i would like to install a more recent version. I did install dolphin and a few more version 5 packages, but i could not see the main one as in version3. Thank you and happy holidays :D i1464$ pkg_info -Q kde kde-dev-scripts-20.08.1 kde-dev-utils-20.08.1 kde-i18n-af-3.5.10p6 kde-i18n-ar-3.5.10p6 kde-i18n-az-3.5.10p6 kde-i18n-be-3.5.10p6 kde-i18n-bg-3.5.10p6 kde-i18n-bn-3.5.10p6 kde-i18n-br-3.5.10p6 kde-i18n-bs-3.5.10p6 kde-i18n-ca-3.5.10p6 kde-i18n-cs-3.5.10p6 kde-i18n-csb-3.5.10p6 kde-i18n-cy-3.5.10p6 kde-i18n-da-3.5.10p6 kde-i18n-de-3.5.10p6 kde-i18n-el-3.5.10p6 kde-i18n-en_GB-3.5.10p6 kde-i18n-eo-3.5.10p6 kde-i18n-es-3.5.10p6 kde-i18n-et-3.5.10p6 kde-i18n-eu-3.5.10p6 kde-i18n-fa-3.5.10p6 kde-i18n-fi-3.5.10p6 kde-i18n-fr-3.5.10p6 kde-i18n-fy-3.5.10p6 kde-i18n-ga-3.5.10p6 kde-i18n-gl-3.5.10p6 kde-i18n-he-3.5.10p6 kde-i18n-hi-3.5.10p6 kde-i18n-hr-3.5.10p6 kde-i18n-hu-3.5.10p6 kde-i18n-is-3.5.10p6 kde-i18n-it-3.5.10p6 kde-i18n-ja-3.5.10p6 kde-i18n-kk-3.5.10p6 kde-i18n-km-3.5.10p6 kde-i18n-ko-3.5.10p6 kde-i18n-lt-3.5.10p6 kde-i18n-lv-3.5.10p6 kde-i18n-mk-3.5.10p6 kde-i18n-mn-3.5.10p6 kde-i18n-ms-3.5.10p6 kde-i18n-nb-3.5.10p6 kde-i18n-nds-3.5.10p6 kde-i18n-nl-3.5.10p6 kde-i18n-nn-3.5.10p6 kde-i18n-pa-3.5.10p6 kde-i18n-pl-3.5.10p6 kde-i18n-pt-3.5.10p6 kde-i18n-pt_BR-3.5.10p6 kde-i18n-ro-3.5.10p6 kde-i18n-ru-3.5.10p6 kde-i18n-rw-3.5.10p6 kde-i18n-se-3.5.10p6 kde-i18n-sk-3.5.10p6 kde-i18n-sl-3.5.10p6 kde-i18n-sr-3.5.10p6 kde-i18n-sr@Latn-3.5.10p6 kde-i18n-ss-3.5.10p6 kde-i18n-sv-3.5.10p6 kde-i18n-ta-3.5.10p6 kde-i18n-te-3.5.10p6 kde-i18n-tg-3.5.10p6 kde-i18n-th-3.5.10p6 kde-i18n-tr-3.5.10p6 kde-i18n-uk-3.5.10p6 kde-i18n-uz-3.5.10p6 kde-i18n-uz@cyrillic-3.5.10p6 kde-i18n-vi-3.5.10p6 kde-i18n-wa-3.5.10p6 kde-i18n-zh_CN-3.5.10p6 kde-i18n-zh_TW-3.5.10p6 kde-shared-data-4.14.3p4 (installed) kde3-langlist-3.5.10p4 (installed) kde3-locale-3.5.10p7 (installed) kde3-locale-en_US-3.5.10p8 (installed) kdeaccessibility-3.5.10p27 kdebase-3.5.10p61 kdebugsettings-20.08.1 kdeclarative-5.73.0 (installed) kdeconnect-kde-1.4p0 kded-5.73.0 kdeedu-data-20.08.1 kdegames-3.5.10p23 kdegraphics-mobipocket-kf5-20.08.1 kdegraphics-thumbnailers-kf5-20.08.1 kdelibs-3.5.10p52 (installed) kdelibs4support-5.73.0 kdenetwork-filesharing-kf5-20.08.1 kdenlive-20.08.1 kdepim-addons-20.08.1 kdepim-apps-libs-20.08.1 kdepim-runtime-kf5-20.08.1 kdesamba-3.5.10p30 kdesdk-kioslaves-20.08.1 kdesdk-thumbnailers-20.08.1 kdesignerplugin-5.73.0 kdesu-5.73.0 kdevelop-5.6.0 kdewebkit-5.73.0 libkdegames-kf5-20.08.1 libkdepim-20.08.1 libreoffice-kde-7.0.1.2v0 libsigrokdecode-0.5.3p0 i1464$ pkg_info -Q plasma plasma-framework-5.73.0 (installed) OpenBSD 6.8 (GENERIC.MP) #2: Sat Dec 5 07:17:48 MST 2020 r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 4064165888 (3875MB) avail mem = 3925954560 (3744MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf0b90 (52 entries) bios0: vendor Dell Inc. version "A06" date 02/26/2010 bios0: Dell Inc. Inspiron 1464 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG APIC BOOT SLIC OSFR SSDT acpi0: wakeup devices P0P2(S4) P0P1(S4) EHC1(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP06(S4) PXSX(S4) LID0(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz 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: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz, 2128.36 MHz, 06-25-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 132MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz, 2128.02 MHz, 06-25-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 2, package 0 cpu2 at mainbus0: apid 1 (a
Re: possible relayd.conf(5) documentation mistake regarding session tickets
On 20/10/21 09:26PM, Sebastian Benoit wrote:
> * i'm not sure we wanted session resumption to be enabled by default
> because of the security implications regarding perferct forward
> secrecy. Indeed the option is off by default at the moment.
Hey, thanks for explaining a bit. :) I read about session resumption
after your mail and can see why the default is off.
Originally I noticed the disparity between what the man page states and
what Qualys reports because I was comparing the results of default
ciphers and `tls { ciphers secure }`, as `openssl ciphers -v secure`
returns an error and SSL_CTX_set_cipher_list(3) doesn't list secure as
a control string.
--
https://amissing.link
Re: possible relayd.conf(5) documentation mistake regarding session tickets
Sebastian Benoit(benoit-li...@fb12.de) on 2020.10.21 21:26:00 +0200:
> Ashlen(euryd...@riseup.net) on 2020.10.20 16:02:49 -0600:
> > In relayd.conf(5), the tls section under PROTOCOLS states the following:
> >
> > no session tickets
> > Disable TLS session tickets. relayd(8) supports stateless TLS
> > session tickets (RFC 5077) to implement TLS session resumption.
> > The default is to enable session tickets.
> >
> > However, an SSL Labs test[1] without `tls { session tickets }` specified
> > shows no session tickets.
>
> There are two things i believe happening:
>
> * i'm not sure we wanted session resumption to be enabled by default because
> of the security implications regarding perferct forward secrecy. Indeed the
> option is off by default at the moment.
It's disabled by default on purpose.
Manpage is updated.
>
> * With TLS 1.3, session resumption is called pre-shared key) resumption.
> I have to check what the issue here is, that is if qualys does not show this
> right or if relayd has to do something different.
Indeed, our TLS 1.3 does not yet support session resumption.:
> For now, with the following options you should see session resumption:
>
> tls { session tickets, tlsv1.2, no tlsv1.3 }
Of course if you just do
tls { session tickets }
clients that support 1.3 wont get it, but ones that do not support 1.3 will.
Best,
Benno
Re: possible relayd.conf(5) documentation mistake regarding session tickets
Ashlen(euryd...@riseup.net) on 2020.10.20 16:02:49 -0600:
> In relayd.conf(5), the tls section under PROTOCOLS states the following:
>
> no session tickets
> Disable TLS session tickets. relayd(8) supports stateless TLS
> session tickets (RFC 5077) to implement TLS session resumption.
> The default is to enable session tickets.
>
> However, an SSL Labs test[1] without `tls { session tickets }` specified
> shows no session tickets.
There are two things i believe happening:
* i'm not sure we wanted session resumption to be enabled by default because
of the security implications regarding perferct forward secrecy. Indeed the
option is off by default at the moment.
* With TLS 1.3, session resumption is called pre-shared key) resumption.
I have to check what the issue here is, that is if qualys does not show this
right or if relayd has to do something different.
For now, with the following options you should see session resumption:
tls { session tickets, tlsv1.2, no tlsv1.3 }
I will figure out what to do about the default, the documentation and TLS
1.3.
/Benno
>
> $ uname -a
> OpenBSD lain.lan 6.8 GENERIC.MP#98 amd64
>
> [1]: https://www.ssllabs.com/ssltest/
>
> --
> https://amissing.link
>
--
possible relayd.conf(5) documentation mistake regarding session tickets
In relayd.conf(5), the tls section under PROTOCOLS states the following:
no session tickets
Disable TLS session tickets. relayd(8) supports stateless TLS
session tickets (RFC 5077) to implement TLS session resumption.
The default is to enable session tickets.
However, an SSL Labs test[1] without `tls { session tickets }` specified
shows no session tickets.
$ uname -a
OpenBSD lain.lan 6.8 GENERIC.MP#98 amd64
[1]: https://www.ssllabs.com/ssltest/
--
https://amissing.link
Re: PPP connection terminated every 5 minutes
> Note the time seqence: > * when ifconfig says time 00:05:00, pings die > * after 20 seconds, a LCP Echo Request comes > * after another 10 seconds, another LCP Echo Request comes > * after another 10 seconds, another LCP Echo Request comes > * after another 10 seconds, a LCP Terminate Request comes > and the connection is established anew. > > This pattern has been repeating since the last midnight. > It looks to me like my ISP is cutting me off every 5 minutes, > and than it takes 50 seconds to realize the connection is down, > which is when it sends the Terminate, > and then the connection is re-established. > > Has anyone seen the same? > Is this a known issue with pppoe connections? > > Searching the archives, I found this: > https://marc.info/?l=openbsd-misc=155053560723855=2 > (but see the entire thread for other details). > > Adam's issue 2 rings a bell, because the drop > happens when I get a new IP6 configuraion request. > I do have the "inet6 eui64" in my setup though. Eh, _now_ I do, and the problem disappeared. It seems that for this ISP at least, I have to accept their IP6 setting: if I don't, my connection gets terminated as described; if I do, everything works as expected. # cat /etc/hostname.pppoe0 # 185.63.96.79 -> 10.11.5.146 # The inet6 settings are necessary, # otherwise we get dropped every 5 minutes inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan0 \ authproto 'pap' authname 'X' authkey 'PASS' up dest 0.0.0.1 inet6 eui64 !/sbin/route add default 0.0.0.1 !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 # ifconfig pppoe0 pppoe0: flags=8851 mtu 1492 index 6 priority 0 llprio 3 dev: vlan0 state: session sid: 0x1 PADI retries: 2 PADR retries: 0 time: 01:28:19 sppp: phase network authproto pap authname "X" groups: pppoe egress status: active inet6 fe80::20d:b9ff:fe56:5efc%pppoe0 -> prefixlen 64 scopeid 0x6 inet 185.63.96.79 --> 10.11.5.146 netmask 0x Sorry for the noise. Jan
PPP connection terminated every 5 minutes
This is current/amd64 on an APU2.E2. It is connected via pppoe over vlan over em as follows: $ cat /etc/hostname.em0 up $ cat /etc/hostname.vlan848 descr UVTNET vlan 848 vlandev em0 up $ cat /etc/hostname.pppoe0 inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan848 \ authproto 'pap' authname 'X' authkey 'PASS' up dest 0.0.0.1 !/sbin/route add default 0.0.0.1 (The 'X' and 'PASS' are actual bogus values, the ISP filters by the link I am connected to.) $ ifconfig em0 em0: flags=8843 mtu 1500 lladdr 00:0d:b9:56:5e:fc index 1 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) status: active $ ifconfig vlan848 vlan848: flags=8843 mtu 1500 lladdr 00:0d:b9:56:5e:fc description: UVTNET index 8 priority 0 llprio 3 encap: vnetid 848 parent em0 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (1000baseT full-duplex) status: active $ ifconfig pppoe0 pppoe0: flags=8851 mtu 1492 index 7 priority 0 llprio 3 dev: vlan848 state: session sid: 0x1 PADI retries: 5 PADR retries: 0 time: 00:03:17 sppp: phase network authproto pap authname "X" groups: pppoe egress status: active inet6 fe80::20d:b9ff:fe56:5efc%pppoe0 -> prefixlen 64 scopeid 0x7 inet 185.63.96.79 --> 10.11.5.146 netmask 0x The connection works just fine, except it drops every five minutes - I mean after exactly five minutes, for the last ten hours. This is the test I did: (1) in one script, keep pinging out (2) in another script, watch the pppoe up time in a loop: while true ; do date ; ifconfig pppoe0 ; sleep 1; done (3) run a tcpdump during that This is what the pinging looks like: $ ping stary.fit.cvut.cz PING stary.fit.cvut.cz (147.32.232.84): 56 data bytes 64 bytes from 147.32.232.84: icmp_seq=0 ttl=246 time=6.632 ms 64 bytes from 147.32.232.84: icmp_seq=1 ttl=246 time=7.339 ms 64 bytes from 147.32.232.84: icmp_seq=2 ttl=246 time=6.762 ms 64 bytes from 147.32.232.84: icmp_seq=3 ttl=246 time=6.438 ms 64 bytes from 147.32.232.84: icmp_seq=4 ttl=246 time=6.626 ms 64 bytes from 147.32.232.84: icmp_seq=5 ttl=246 time=6.989 ms 64 bytes from 147.32.232.84: icmp_seq=6 ttl=246 time=6.951 ms 64 bytes from 147.32.232.84: icmp_seq=7 ttl=246 time=7.136 ms 64 bytes from 147.32.232.84: icmp_seq=8 ttl=246 time=7.620 ms 64 bytes from 147.32.232.84: icmp_seq=9 ttl=246 time=7.404 ms ^^^ [no reply for about 50 seconds] 64 bytes from 147.32.232.84: icmp_seq=60 ttl=246 time=6.786 ms ^ 64 bytes from 147.32.232.84: icmp_seq=61 ttl=246 time=7.316 ms 64 bytes from 147.32.232.84: icmp_seq=62 ttl=246 time=7.570 ms 64 bytes from 147.32.232.84: icmp_seq=63 ttl=246 time=7.296 ms [getting replies for precisely 300 pings, then repeats] The drop happens exactly when ifconfig pppoe0 says the interface has been up for 5 minues: Fri Apr 24 13:13:28 CEST 2020 pppoe0: flags=8951 mtu 1492 index 7 priority 0 llprio 3 dev: vlan848 state: session sid: 0x1 PADI retries: 5 PADR retries: 0 time: 00:05:00 ^^^ sppp: phase network authproto pap authname "X" groups: pppoe egress status: active inet 185.63.96.79 --> 10.11.5.146 netmask 0x For almost exactly 50 seconds then, the pings are not getting replies. This is what tcpdump says: [pinging away] 13:13:26.840342 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:26.847192 147.32.232.84 > 185.63.96.79: icmp: echo reply 13:13:27.840399 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:27.847448 147.32.232.84 > 185.63.96.79: icmp: echo reply 13:13:28.840398 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:28.847934 147.32.232.84 > 185.63.96.79: icmp: echo reply [ifconfig pppoe0 shows time 00:05:00] [The pings are no longer getting replies] 13:13:29.450416 IPV6CP Configure-Request Id=0xff: IPv6-Interface-Id=427c:7dff:feea:db03 13:13:29.450438 IPV6CP Configure-Ack Id=0xff: IPv6-Interface-Id=427c:7dff:feea:db03 13:13:29.840366 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:29.847671 147.32.232.84 > 185.63.96.79: icmp: echo reply 13:13:30.840381 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:31.840472 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:32.840499 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:33.840449 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:34.840401 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:35.840431 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:36.840437 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:37.840422 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:38.840517 185.63.96.79 > 147.32.232.84: icmp: ech
Re: Server 5 SSD/best practice
Hi Stuart, hi Nick Many thanks for your answers adn itnersting point you’ve mentioned about the raid levels, it really helped me thinking about the ssd config of that existent server. Greets Oliver On 21 Feb 2020, at 17:15, Stuart Henderson wrote: On 2020-02-21, Nick Holland wrote: On 2020-02-20 11:22, Oliver Marugg wrote: Hi I’ve got a Supermicro 5028D desktop server with 5 identical SATA SSDs, there is no HBA no RAID card in. The purpose of the server is intended as web/smtp and some vmm vms (os plus /home & /var storage). What are your suggestions or best practices configuring the device arrangement (eg. sofraid(4), bio(4),bioctl(4) OS 2x on 2x ssd raid1, data 3xssd raid5 or 1x single ssd for OS and 4x ssd raid5/10 or better ideas)? You came in a bit late with the question (i.e. after you already had the hardware!). IMHO there's little use for RAID5 these days. The advantage is "more storage from a given number of drives". But that can more easily be fixed by using larger drives which are easier to recover in the event of failure. I'm not sure what level of support softraid has for stacked disciplines (it doesn't have direct RAID10 support). The boot loader only supports RAID 1 and crypto, so you will either want RAID 1 on the boot drives, or boot from USB stick etc. I think the only options that really make sense for OpenBSD are 2-drive RAID1 for main OS, and then either 2-drive RAID1 for data, plus a single drive for an extra copy of important things (I hesitate to use the word 'backup' for something in the same machine, but sometimes it can be helpful to have something that is easier to restore than your actual backups ;) - though for such a setup I would have gone with HDD rather than SSD for the 5th drive - or 3 single drives for data. set it up as you need it... If you think your description is anything close to specific for specific recommendations, you need to get out more. Everything you said could vary in demand by many orders of magnitude, except for the model number the server...a curious thing to be specific about. E-mail is one of those things that's really hard to get a good backup of, as it changes minute by minute and is considered fairly important, Dovecot replication (dsync) does a pretty good job of this actually. I think it's a much better idea than trying to backup mailboxes on an active system. Either run periodically to alternative storage on the same machine, or preferably to a different machine (preferably in a different building). so I'd consider a three disk RAID1 for the mail store, as a disk system failure invariably means "lost data", even with frequent backups. Three disk RAID1 gives you a simple disk structure that can tolerate a disk failure and still provide redundancy. (some people will tell you that RAID1 is only two disks. These people are wrong, but often include HW RAID controller makers. Three disk RAID1 examples are in the man pages). Since these are SSDs and apart from random hardware failures (which aren't *so* common) the main failure mode is doing too many writes. So with three disk RAID1 the main thing you end up doing with 3 mirrored SSDs is wearing out three drives rather than two with writes at the same rate. The other risk is data corruption (either on the bus or on storage either over time - "bit rot" - or firmware bugs etc). softraid doesn't have anything to help with this (even for detection, let alone figuring out which copy of the data, if any, is correct). As for the rest...it's a matter of how much space you need and how much down time you can tolerate, and how you are set up to deal with that downtime. And I'm assuming you aren't combining external and internal services on one box. I suspect that's a bad assumption. And even after much careful analysis it's a bit of a guess. Sometimes you guess wrong. So keep your design flexible and be willing and able to say, "Well, this isn't working, let's rebuild it with the knowledge we now have". This idea that you have to have the perfect build the first time out is ... well, just wrong. yep :)
Re: Server 5 SSD/best practice
On 2020-02-21, Nick Holland wrote: > On 2020-02-20 11:22, Oliver Marugg wrote: >> Hi >> >> I’ve got a Supermicro 5028D desktop server with 5 identical SATA SSDs, >> there is no HBA no RAID card in. The purpose of the server is intended >> as web/smtp and some vmm vms (os plus /home & /var storage). >> What are your suggestions or best practices configuring the device >> arrangement (eg. sofraid(4), bio(4),bioctl(4) OS 2x on 2x ssd raid1, >> data 3xssd raid5 or 1x single ssd for OS and 4x ssd raid5/10 or better >> ideas)? You came in a bit late with the question (i.e. after you already had the hardware!). IMHO there's little use for RAID5 these days. The advantage is "more storage from a given number of drives". But that can more easily be fixed by using larger drives which are easier to recover in the event of failure. I'm not sure what level of support softraid has for stacked disciplines (it doesn't have direct RAID10 support). The boot loader only supports RAID 1 and crypto, so you will either want RAID 1 on the boot drives, or boot from USB stick etc. I think the only options that really make sense for OpenBSD are 2-drive RAID1 for main OS, and then either 2-drive RAID1 for data, plus a single drive for an extra copy of important things (I hesitate to use the word 'backup' for something in the same machine, but sometimes it can be helpful to have something that is easier to restore than your actual backups ;) - though for such a setup I would have gone with HDD rather than SSD for the 5th drive - or 3 single drives for data. > set it up as you need it... > If you think your description is anything close to specific for specific > recommendations, you need to get out more. Everything you said could > vary in demand by many orders of magnitude, except for the model number > the server...a curious thing to be specific about. > > E-mail is one of those things that's really hard to get a good backup > of, as it changes minute by minute and is considered fairly important, Dovecot replication (dsync) does a pretty good job of this actually. I think it's a much better idea than trying to backup mailboxes on an active system. Either run periodically to alternative storage on the same machine, or preferably to a different machine (preferably in a different building). > so I'd consider a three disk RAID1 for the mail store, as a disk system > failure invariably means "lost data", even with frequent backups. > Three disk RAID1 gives you a simple disk structure that can tolerate > a disk failure and still provide redundancy. (some people will tell > you that RAID1 is only two disks. These people are wrong, but often > include HW RAID controller makers. Three disk RAID1 examples are in > the man pages). Since these are SSDs and apart from random hardware failures (which aren't *so* common) the main failure mode is doing too many writes. So with three disk RAID1 the main thing you end up doing with 3 mirrored SSDs is wearing out three drives rather than two with writes at the same rate. The other risk is data corruption (either on the bus or on storage either over time - "bit rot" - or firmware bugs etc). softraid doesn't have anything to help with this (even for detection, let alone figuring out which copy of the data, if any, is correct). > As for the rest...it's a matter of how much space you need and how > much down time you can tolerate, and how you are set up to deal with > that downtime. And I'm assuming you aren't combining external and > internal services on one box. I suspect that's a bad assumption. > > And even after much careful analysis it's a bit of a guess. > Sometimes you guess wrong. So keep your design flexible and be > willing and able to say, "Well, this isn't working, let's rebuild > it with the knowledge we now have". This idea that you have to have > the perfect build the first time out is ... well, just wrong. yep :)
Re: Server 5 SSD/best practice
On 2020-02-20 11:22, Oliver Marugg wrote: > Hi > > I’ve got a Supermicro 5028D desktop server with 5 identical SATA SSDs, > there is no HBA no RAID card in. The purpose of the server is intended > as web/smtp and some vmm vms (os plus /home & /var storage). > What are your suggestions or best practices configuring the device > arrangement (eg. sofraid(4), bio(4),bioctl(4) OS 2x on 2x ssd raid1, > data 3xssd raid5 or 1x single ssd for OS and 4x ssd raid5/10 or better > ideas)? > > many thanks > -oliver > set it up as you need it... If you think your description is anything close to specific for specific recommendations, you need to get out more. Everything you said could vary in demand by many orders of magnitude, except for the model number the server...a curious thing to be specific about. E-mail is one of those things that's really hard to get a good backup of, as it changes minute by minute and is considered fairly important, so I'd consider a three disk RAID1 for the mail store, as a disk system failure invariably means "lost data", even with frequent backups. Three disk RAID1 gives you a simple disk structure that can tolerate a disk failure and still provide redundancy. (some people will tell you that RAID1 is only two disks. These people are wrong, but often include HW RAID controller makers. Three disk RAID1 examples are in the man pages). As for the rest...it's a matter of how much space you need and how much down time you can tolerate, and how you are set up to deal with that downtime. And I'm assuming you aren't combining external and internal services on one box. I suspect that's a bad assumption. And even after much careful analysis it's a bit of a guess. Sometimes you guess wrong. So keep your design flexible and be willing and able to say, "Well, this isn't working, let's rebuild it with the knowledge we now have". This idea that you have to have the perfect build the first time out is ... well, just wrong. Nick.
Server 5 SSD/best practice
Hi I’ve got a Supermicro 5028D desktop server with 5 identical SATA SSDs, there is no HBA no RAID card in. The purpose of the server is intended as web/smtp and some vmm vms (os plus /home & /var storage). What are your suggestions or best practices configuring the device arrangement (eg. sofraid(4), bio(4),bioctl(4) OS 2x on 2x ssd raid1, data 3xssd raid5 or 1x single ssd for OS and 4x ssd raid5/10 or better ideas)? many thanks -oliver
Re: man.openbsd.org/table.5
Hi Edgar,
Edgar Pettijohn wrote on Sun, Sep 08, 2019 at 03:00:57PM -0500:
> Not sure if its just me or not, but I was looking at the table(5)
> manual online and sections look odd.
> Particularly `Mailaddr tables' and `Addrname tables'.
Yes, that was indeed badly misformatted:
In blocks, in some situations, damaging line breaks were
inserted into the HTML code.
I fixed it with the following commit.
I also installed the patch on man.openbsd.org, so people can easily
check whether everything looks right now.
Thanks for the useful report!
Ingo
Log Message:
---
Fix line breaking in no-fill mode (.Bd -unfilled/),
which apparently didn't work since the .Pp/ reorg.
The new logic is more similar to what the terminal formatter does:
1. Before a node that starts a new mdoc(7) input line,
start a new HTML output line.
2. An empty input line or a .Pp causes an empty output line.
3. Nothing needs to be done at the end of a node.
Severe misformatting was reported in table(5) by
Edgar Pettijohn on misc@.
Modified Files:
--
mandoc:
mdoc_html.c
Revision Data
-
Index: mdoc_html.c
===
RCS file: /home/cvs/mandoc/mandoc/mdoc_html.c,v
retrieving revision 1.330
retrieving revision 1.331
diff -Lmdoc_html.c -Lmdoc_html.c -u -p -r1.330 -r1.331
--- mdoc_html.c
+++ mdoc_html.c
@@ -351,26 +351,34 @@ print_mdoc_node(MDOC_ARGS)
if (n->type == ROFFT_COMMENT || n->flags & NODE_NOPRT)
return;
- html_fillmode(h, n->flags & NODE_NOFILL ? ROFF_nf : ROFF_fi);
+ if (n->flags & NODE_NOFILL) {
+ html_fillmode(h, ROFF_nf);
+ if (n->flags & NODE_LINE)
+ print_endline(h);
+ } else
+ html_fillmode(h, ROFF_fi);
child = 1;
n->flags &= ~NODE_ENDED;
switch (n->type) {
case ROFFT_TEXT:
+ if (n->flags & NODE_LINE) {
+ switch (*n->string) {
+ case '\0':
+ h->col = 1;
+ print_endline(h);
+ return;
+ case ' ':
+ if ((h->flags & HTML_NONEWLINE) == 0 &&
+ (n->flags & NODE_NOFILL) == 0)
+ print_otag(h, TAG_BR, "");
+ break;
+ default:
+ break;
+ }
+ }
t = h->tag;
t->refcnt++;
-
- /* No tables in this mode... */
- assert(NULL == h->tblt);
-
- /*
-* Make sure that if we're in a literal mode already
-* (i.e., within a ) don't print the newline.
-*/
- if (*n->string == ' ' && n->flags & NODE_LINE &&
- (h->flags & HTML_NONEWLINE) == 0 &&
- (n->flags & NODE_NOFILL) == 0)
- print_otag(h, TAG_BR, "");
if (NODE_DELIMC & n->flags)
h->flags |= HTML_NOSPACE;
print_text(h, n->string);
@@ -439,12 +447,6 @@ print_mdoc_node(MDOC_ARGS)
n->body->flags |= NODE_ENDED;
break;
}
-
- if (n->flags & NODE_NOFILL &&
- (n->next == NULL || n->next->flags & NODE_LINE)) {
- h->col++;
- print_endline(h);
- }
}
static void
@@ -1270,7 +1272,11 @@ mdoc_skip_pre(MDOC_ARGS)
static int
mdoc_pp_pre(MDOC_ARGS)
{
- if ((n->flags & NODE_NOFILL) == 0) {
+ if (n->flags & NODE_NOFILL) {
+ print_endline(h);
+ h->col = 1;
+ print_endline(h);
+ } else {
html_close_paragraph(h);
print_otag(h, TAG_P, "c", "Pp");
}
man.openbsd.org/table.5
Not sure if its just me or not, but I was looking at the table(5) manual online and sections look odd. Particularly `Mailaddr tables' and `Addrname tables'. Thanks, Edgar
login.conf(5) - Do vmemoryuse and memoryuse limit a process' virtual and physical memory?
Namaste misc, As a good practice, I tried to limit the virtual and physical memory available to the svn daemon [1]. To achieve that, I read about login classes and login.conf(5) [2]: ... memoryuse sizeMaximum in core memoryuse size limit. ... vmemoryuse sizeMaximum virtual memoryuse size limit. ... I then tried to verify the meanings of vmemoryuse and memoryuse. That led to RLIMIT_VMEM and RLIMIT_RSS. That in turn led to ulimit in ksh(1) [3] and the following interesting line in that manpage: ... ulimit ... -m n Impose a limit of n kilobytes on the amount of physical memory used. This limit is not enforced. ... That in turn led to a mail thread on misc titled "Large datasize - how to limit physical memory?" [4]. I could not understand much except that the conversation seems to be the reason behind the "This limit is not enforced" line in the ksh(1) manpage. So, 1) Do vmemoryuse (RLIMIT_VMEM) and memoryuse (RLIMIT_RSS, ulimit -m) actually limit a process' virtual and physical memory? 2) If not, should I set datasize (RLIMIT_DATA, ulimit -d) to limit a process' memory, assuming that processvirtualmemory=programsize+datasize? Dhanyavaad. Regards, ab [1] - https://subversion.apache.org/security/CVE-2015-0202-advisory.txt [2] - https://man.openbsd.org/login.conf.5 [3] - https://man.openbsd.org/ksh.1 [4] - https://marc.info/?t=14750472931=1=2 -|-|-|-|-|-|-|--
Answer 5 / Re: 10GBit network performance on OpenBSD 6.4
Am 08.04.2019 23:46, schrieb Anatoli: Thank you very much for the idea Anatoli! Running dd with "/dev/zero" and "/dev/null" gave me back a very good overview what is going on (different server hardware and operating systems) ironm@wheezy:~$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 Bytes (4.3 GB) kopiert, 1.0029 s, 4.3 GB/s -- ironm@fbsdsrv8:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 bytes transferred in 8.432852 secs (509313755 bytes/sec) -- ironm@fbsdsrv1:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 bytes transferred in 5.947370 secs (722162508 bytes/sec) -- ironm@fbsdsrv2:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 bytes transferred in 8.804378 secs (487821753 bytes/sec) -- ronm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 Bytes (4.3 GB) kopiert, 0.410687 s, 10.5 GB/s -- ironm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 Bytes (537 MB) kopiert, 0.0558006 s, 9.6 GB/s -- ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 1.338350 secs (3209151777 bytes/sec) -- ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 bytes transferred in 0.167219 secs (3210581655 bytes/sec) -- ironm@fbsdsrv1:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 1.173098 secs (3661217181 bytes/sec) -- ironm@fbsdsrv1:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 bytes transferred in 0.191353 secs (2805662938 bytes/sec) -- ironm@fbsdsrv2:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 1.159899 secs (3702879890 bytes/sec) -- ironm@fbsdsrv2:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 bytes transferred in 0.213278 secs (2517231248 bytes/sec) -- obsdsrv2$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4294967296 bytes transferred in 9.136 secs (470078173 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 11.280 secs (380734881 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4294967296 bytes transferred in 10.167 secs (422400700 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=2048 && sync 2147483648 bytes transferred in 4.515 secs (475551520 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=1024 && sync 1073741824 bytes transferred in 1.728 secs (621203080 bytes/sec) -- obsdsrv2$ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 536870912 bytes transferred in 0.265 secs (2021821094 bytes/sec) Kind regards Mark -- m...@it-infrastrukturen.org ironm@wheezy:~$ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 Datensätze ein 4096+0 Datensätze aus 4294967296 Bytes (4.3 GB) kopiert, 1.0029 s, 4.3 GB/s real0m1.231s user0m0.000s sys 0m1.224s --- ironm@fbsdsrv8:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 8.432852 secs (509313755 bytes/sec) 8.79 real 0.01 user 3.36 sys --- ironm@fbsdsrv1:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 5.947370 secs (722162508 bytes/sec) 6.41 real 0.00 user 4.65 --- ironm@fbsdsrv2:~ $ time dd if=/dev/zero of=file1.tmp bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 8.804378 secs (487821753 bytes/sec) 9.26 real 0.00 user 4.94 sys ronm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4096+0 Datensätze ein 4096+0 Datensätze aus 4294967296 Bytes (4.3 GB) kopiert, 0.410687 s, 10.5 GB/s real0m0.412s user0m0.000s sys 0m0.408s ironm@wheezy:~$ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 512+0 Datensätze ein 512+0 Datensätze aus 536870912 Bytes (537 MB) kopiert, 0.0558006 s, 9.6 GB/s real0m0.057s user0m0.000s sys 0m0.056s --- ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 1.338350 secs (3209151777 bytes/sec) 1.34 real 0.00 user 1.34 sys ironm@fbsdsrv8:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=512 && sync 512+0 records in 512+0 records out 536870912 bytes transferred in 0.167219 secs (3210581655 bytes/sec) 0.17 real 0.00 user 0.17 sys --- ironm@fbsdsrv1:~ $ time dd if=file1.tmp of=/dev/null bs=1M count=4096 && sync 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 1.173098 secs (3661217181
Re: how to use pf.conf(5) to bypass vpn based on destination port?
> All-in-all, something like that would solve that problem for you: > > pass out quick proto tcp from (self) to port 22 route-to (athn0 > $athn0_gateway) nat-to (athn0) > That worked perfectly! Thank you, Igor. Even with OpenBSD's legendary documentation at my disposal, with my current (limited) understanding of networking there is absolutely no way I would have figured that out on my own. I'm glad I asked here. Thank you so much! -Bruno
Re: how to use pf.conf(5) to bypass vpn based on destination port?
On Thu, 17 Jan 2019 at 23:24, Bruno Dantas wrote:
[...]
> pass out proto {tcp udp} to any port 22022 route-to athn0
>
> and this:
>
> pass out proto {tcp udp} to any port 22022 route-to \
> $athn0_gateway
>
> But both result in ssh authentication attempts to hang at
> "debug1: Connecting to..." then timing out.
On point-to-point links just interface name is sufficient but this is
not so with broadcast media.
Ethernet is broadcast media, thus only specifying interface would
further involve ARP to find
target node on that interface's media.
If it was an external node then no internal network node would respond
to such ARP request
-- unless it's doing Proxy ARP (which is separate subject).
For outside scope nodes proper gateways are supposed to be used
instead. Pf has to be told
which gateway it should use with given interface.
All-in-all, something like that would solve that problem for you:
pass out quick proto tcp from (self) to port 22 route-to (athn0
$athn0_gateway) nat-to (athn0)
More clearer design would be based on separate routing tables though.
--
End of message. Next message?
how to use pf.conf(5) to bypass vpn based on destination port?
My personal laptop runs OpenBSD 6.4. I browse the web using WiFi +
openvpn client for added privacy. The default behavior of all outgoing
traffic going through VPN is generally desirable, but I need some
outgoing packets (e.g., ssh traffic) to bypass VPN--i.e., those packets
should go out via default gateway of my wireless card (athn0), not via
tun0. My machines running ssh servers connect to internet via ISP,
are not running VPN client or server, and listen on port 22022.
Back in my Linux days, I used iptables(8) to put a mark on the packets
that should bypass vpn, then used ip(8) to create a custom route for
the marked packets, like this:
iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 22022 -j \
MARK --set-mark 1
ip route add table 100 $wlan0_default_gateway
ip rule add fwmark 1 table 10
Please, how do I accomplish this on OpenBSD 6.4 using pf.conf(5)?
I already tried various permutations of this:
pass out proto {tcp udp} to any port 22022 route-to athn0
and this:
pass out proto {tcp udp} to any port 22022 route-to \
$athn0_gateway
But both result in ssh authentication attempts to hang at
"debug1: Connecting to..." then timing out.
jggimi at daemonforums.org tried to help but we couldn't figure it out,
so he suggested that I ask for help here. The thread of our attempt is
here (I didn't mention that I use port 22022 instead of 22 because
I don't think it really matters):
http://daemonforums.org/showthread.php?t=10905
I can bypass VPN to reach an *individual* ssh server with this:
athn0_gateway=$(route show | grep default | awk '{print $2}')
route add $ssh_server_ip $athn0_gateway
but I'd really like to learn how to accomplish this using pf.conf(5)
so that I can bypass VPN based on destination port instead of
destination ip address, thereby having an elegant solution that works
for all ssh servers.
Please help me.
Thank you,
Bruno Dantas
Inconsistency between installurl(5) and the info inside regarding the URL
Just found a little error regarding the URL listed in installurl(5) and the website itself. The manpage is listing https://cdn.openbsd.org/pub/OpenBSD while the actual website is [http://cdn.openbsd.org/pub/OpenBSD](https://cdn.openbsd.org/pub/OpenBSD). Pretty certain it´s a new change since I got all the patches up to 18 from that site and checking my /etc/installurl file the website is listed with https. Tried to reach the site via https on a testmashine with no success. Should I have missed a headsup via mailing list or simple being stupid here my apoligies. ___ Always exit with 42 to return the answer.
Fwd: doas.conf(5) question: when password required
Hello, I didn't know, when to reply, I have to specify CC address as misc@openbsd.org. I'm so sorry. Best regards, Hajime Edakawa -- Forwarded message - From: Hajime Edakawa Date: 2018年9月13日(木) 3:12 Subject: Re: doas.conf(5) question: when password required To: Thank you for your kind reply, Mr. Henderson. I am verry sorry, I mistook my first e-mail. There was two my mistook. The correction is as follows; Mistook(1/2): > > Hello to all, > > > > I am sorry to say that I could not understand this behavior intuitively. > > > > $ id -Gn > > hajime wheel > > $ cat /etc/doas.conf > > permit nopass hajime as root cmd mg# A > > permit keepenv :wheel # B > > $ doas mg /etc/doas.conf # no password, ok. > > ... > > Correct(1/2): $ id -Gn hajime wheel $ cat /etc/doas.conf permit nopass hajime as root cmd mg# A permit keepenv :wheel # B $ doas mg /etc/doas.conf # require password, ok? doas (***) password: ... $ Mistook(2/2): > > But, > > > > $ id -Gn > > hajime wheel > > $ cat /etc/doas.conf > > permit keepenv :wheel # B > > permit nopass hajime as root cmd mg# A > > $ doas mg /etc/doas.conf # require password, ok? > > doas (***) password: > > ... > > $ > > > > I understand the former, but I could not understand the letter. > > My question is whether is this correct behavior? Correct(2/2): $ id -Gn hajime wheel $ cat /etc/doas.conf permit keepenv :wheel # B permit nopass hajime as root cmd mg# A $ doas mg /etc/doas.conf # no password, ok. ... $ Excuse me for taking up your time over such my mistook. I am very grateful that you explained that to me politely. My bad. I apologize again. Sincerely yours, Hajime Edakawa 2018年9月13日(木) 1:57 Stuart Henderson : > > On 2018-09-12, Hajime Edakawa wrote: > > Hello to all, > > > > I am sorry to say that I could not understand this behavior intuitively. > > > > $ id -Gn > > hajime wheel > > $ cat /etc/doas.conf > > permit nopass hajime as root cmd mg# A > > permit keepenv :wheel # B > > $ doas mg /etc/doas.conf # no password, ok. > > ... > > $ > > Something seems wrong here, because it is documented as "last match > wins", and that is how it works for me (amd64 -current, FWIW). > Last match is "permit keepenv :wheel", so it should ask for a password. > > $ printf 'permit nopass sthen as root cmd mg\npermit keepenv :wheel\n' > test > $ doas -C test mg > permit > > > But, > > > > $ id -Gn > > hajime wheel > > $ cat /etc/doas.conf > > permit keepenv :wheel # B > > permit nopass hajime as root cmd mg# A > > $ doas mg /etc/doas.conf # require password, ok? > > doas (***) password: > > ... > > $ > > > > I understand the former, but I could not understand the letter. > > My question is whether is this correct behavior? > > This seems wrong too, that isn't what I see (the last match here > is the "nopass" line) > > $ printf 'permit keepenv :wheel\npermit nopass sthen as root cmd mg\n' > test > $ doas -C test mg > permit nopass > > > And, > > > > $ id -Gn > > hajime wheel > > $ cat /etc/doas.conf > > permit keepenv :games # New B: other than wheel group > > permit nopass hajime as root cmd mg# A > > $ doas mg /etc/doas.conf # no password, ok. > > ... > > $ > > This one is working how I expect, last match is "nopass" and that's > what you get. > > $ printf 'permit keepenv :games\npermit nopass sthen as root cmd mg\n' > test > $ doas -C test mg > permit nopass > > > > Excuse me if you not understand or you feel bad with my poor English. > > There is absolutely no problem with your English in this mail, > it's very clear :) What isn't clear, is why doas is behaving like > this. Which version are you running? (dmesg is always a good idea). > >
Re: doas.conf(5) question: when password required
On 2018-09-12, Hajime Edakawa wrote: > Hello to all, > > I am sorry to say that I could not understand this behavior intuitively. > > $ id -Gn > hajime wheel > $ cat /etc/doas.conf > permit nopass hajime as root cmd mg# A > permit keepenv :wheel # B > $ doas mg /etc/doas.conf # no password, ok. > ... > $ Something seems wrong here, because it is documented as "last match wins", and that is how it works for me (amd64 -current, FWIW). Last match is "permit keepenv :wheel", so it should ask for a password. $ printf 'permit nopass sthen as root cmd mg\npermit keepenv :wheel\n' > test $ doas -C test mg permit > But, > > $ id -Gn > hajime wheel > $ cat /etc/doas.conf > permit keepenv :wheel # B > permit nopass hajime as root cmd mg# A > $ doas mg /etc/doas.conf # require password, ok? > doas (***) password: > ... > $ > > I understand the former, but I could not understand the letter. > My question is whether is this correct behavior? This seems wrong too, that isn't what I see (the last match here is the "nopass" line) $ printf 'permit keepenv :wheel\npermit nopass sthen as root cmd mg\n' > test $ doas -C test mg permit nopass > And, > > $ id -Gn > hajime wheel > $ cat /etc/doas.conf > permit keepenv :games # New B: other than wheel group > permit nopass hajime as root cmd mg# A > $ doas mg /etc/doas.conf # no password, ok. > ... > $ This one is working how I expect, last match is "nopass" and that's what you get. $ printf 'permit keepenv :games\npermit nopass sthen as root cmd mg\n' > test $ doas -C test mg permit nopass > Excuse me if you not understand or you feel bad with my poor English. There is absolutely no problem with your English in this mail, it's very clear :) What isn't clear, is why doas is behaving like this. Which version are you running? (dmesg is always a good idea).
doas.conf(5) question: when password required
Hello to all, I am sorry to say that I could not understand this behavior intuitively. $ id -Gn hajime wheel $ cat /etc/doas.conf permit nopass hajime as root cmd mg# A permit keepenv :wheel # B $ doas mg /etc/doas.conf # no password, ok. ... $ But, $ id -Gn hajime wheel $ cat /etc/doas.conf permit keepenv :wheel # B permit nopass hajime as root cmd mg# A $ doas mg /etc/doas.conf # require password, ok? doas (***) password: ... $ I understand the former, but I could not understand the letter. My question is whether is this correct behavior? And, $ id -Gn hajime wheel $ cat /etc/doas.conf permit keepenv :games # New B: other than wheel group permit nopass hajime as root cmd mg# A $ doas mg /etc/doas.conf # no password, ok. ... $ Excuse me if you not understand or you feel bad with my poor English. Regards, Hajime Edakawa
Re: dump/restore and crontab(5)
On Mon, 2 Jul 2018 09:25:37 -0400 "trondd" wrote: > On Mon, July 2, 2018 8:14 am, Ed Ahlsen-Girard wrote: > [...] > > I'd have to look later to see if my dumps are coreectly grabbing the > crontabs. But first, try looking in /var/backups either on disk, or > in your dump. > > Tim. > In the backups. Thanks. -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: dump/restore and crontab(5)
On Mon, July 2, 2018 10:26 am, Ed Ahlsen-Girard wrote: > On Mon, 2 Jul 2018 09:25:37 -0400 > "trondd" wrote: > >> On Mon, July 2, 2018 8:14 am, Ed Ahlsen-Girard wrote: >> [...] >> >> I'd have to look later to see if my dumps are coreectly grabbing the >> crontabs. But first, try looking in /var/backups either on disk, or >> in your dump. >> >> Tim. >> > > In the backups. Thanks. > > -- > > Edward Ahlsen-Girard > Ft Walton Beach, FL > FYI. dump/restore is correctly saving and restoring my /var/cron/tabs/* so double check your dump and restore scripts, parameters, whatever. Tim.
Re: dump/restore and crontab(5)
trondd writes: > On Mon, July 2, 2018 8:14 am, Ed Ahlsen-Girard wrote: >> Having clobbered my crontab (5) file in error (-r and -e are close) I >> merrily went to my level 0 dump to restore it. It's present on the dump >> (which is to file) but the restored file is zero bytes. >> >> Should I have run those dumps manually instead of as cron jobs? >> >> -- >> >> Edward Ahlsen-Girard >> Ft Walton Beach, FL >> > > I'd have to look later to see if my dumps are coreectly grabbing the > crontabs. But first, try looking in /var/backups either on disk, or in > your dump. > > Tim. Indeed, you can find your last file in /var/backups/var_cron_tabs_root.backup or /var/backups/var_cron_tabs_root.current Those files are created by security(8) script, which should be run every day at 1h30.
Re: dump/restore and crontab(5)
On Mon, July 2, 2018 8:14 am, Ed Ahlsen-Girard wrote: > Having clobbered my crontab (5) file in error (-r and -e are close) I > merrily went to my level 0 dump to restore it. It's present on the dump > (which is to file) but the restored file is zero bytes. > > Should I have run those dumps manually instead of as cron jobs? > > -- > > Edward Ahlsen-Girard > Ft Walton Beach, FL > I'd have to look later to see if my dumps are coreectly grabbing the crontabs. But first, try looking in /var/backups either on disk, or in your dump. Tim.
Re: dump/restore and crontab(5)
Ed Ahlsen-Girard writes: > Having clobbered my crontab (5) file in error (-r and -e are close) I > merrily went to my level 0 dump to restore it. It's present on the dump > (which is to file) but the restored file is zero bytes. > > Should I have run those dumps manually instead of as cron jobs? What arguments did you use to backup with dump? What arguments did you use to restore with restore? If you found the file using restore, then it should not be zero-length.
dump/restore and crontab(5)
Having clobbered my crontab (5) file in error (-r and -e are close) I merrily went to my level 0 dump to restore it. It's present on the dump (which is to file) but the restored file is zero bytes. Should I have run those dumps manually instead of as cron jobs? -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: Missing relayd.conf(5) example
On Sat, 2018-04-21 at 14:55 +0200, Hiltjo Posthuma wrote: > I don't mean to hijack the thread, but have you been able to forward > the > HTTP request and modifying the path? I've researched the code, but I > don't > think it's possible at the moment. I did not attempt this. > Locally I have a patch which changes the matching logic to the httpd > Lua > pattern matching. This has some side-effects and complicates the code > though, > so is probably not suitable for upstream. > > One of the reasons I don't use relayd (yet) is because I'd like to > reverse > proxy HTTP traffic but strip the path, for example: > > somedomain.org/someservice to 127.0.0.1:8080/ (stripping > "someservice"). > > Do you perhaps have a solution or idea to do this? If it is not possible with relayd, I recommend adding application middleware to strip it out. -- Aaron
Re: Missing relayd.conf(5) example
On Fri, Apr 20, 2018 at 02:55:04PM -0700, Aaron Miller wrote:
> Hi all,
>
> I was able to setup relayd(8) with URL-based redirection to either a
> local application server or to httpd(8), both listening on lo0; relayd
> also terminates TLS. However, the man pages were not very helpful and I
> ended up resorting to stackoverflow and trial and error.
>
> I recommend an example like this be added to relayd.conf(5) man page:
>
> table { 127.0.0.1 }
> table { 127.0.0.1 }
>
> http protocol "https" {
> match header set "X-Forwarded-For" \
> value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" \
> value "$SERVER_ADDR:$SERVER_PORT"
> match header set "Keep-Alive" value "$TIMEOUT"
>
> pass request quick path "/api/*" forward to
> pass request quick forward to
> block
> }
>
> relay "main" {
> protocol "https"
> listen on 0.0.0.0 port 443 tls
> forward to port 3000
> forward to port 4443
> }
>
> I think that would be helpful for others who want to do what I did...
> any thoughts?
>
> --Aaron
>
Hi,
I think this example is a common use-case and probably helpful.
I don't mean to hijack the thread, but have you been able to forward the
HTTP request and modifying the path? I've researched the code, but I don't
think it's possible at the moment.
Locally I have a patch which changes the matching logic to the httpd Lua
pattern matching. This has some side-effects and complicates the code though,
so is probably not suitable for upstream.
One of the reasons I don't use relayd (yet) is because I'd like to reverse
proxy HTTP traffic but strip the path, for example:
somedomain.org/someservice to 127.0.0.1:8080/ (stripping "someservice").
Do you perhaps have a solution or idea to do this?
--
Kind regards,
Hiltjo
Missing relayd.conf(5) example
Hi all,
I was able to setup relayd(8) with URL-based redirection to either a
local application server or to httpd(8), both listening on lo0; relayd
also terminates TLS. However, the man pages were not very helpful and I
ended up resorting to stackoverflow and trial and error.
I recommend an example like this be added to relayd.conf(5) man page:
table { 127.0.0.1 }
table { 127.0.0.1 }
http protocol "https" {
match header set "X-Forwarded-For" \
value "$REMOTE_ADDR"
match header set "X-Forwarded-By" \
value "$SERVER_ADDR:$SERVER_PORT"
match header set "Keep-Alive" value "$TIMEOUT"
pass request quick path "/api/*" forward to
pass request quick forward to
block
}
relay "main" {
protocol "https"
listen on 0.0.0.0 port 443 tls
forward to port 3000
forward to port 4443
}
I think that would be helpful for others who want to do what I did...
any thoughts?
--Aaron
Re: [patch] 6.3 relayd.conf(5) man page correction
Hi Jason,
When I have a moment later today I will look into it. I wasn't using the
exact example from the man page because I was only proxying for one
host. Since I did not have check hosts setup, that might have been the
cause.
Thanks
On 4/8/2018 10:19 AM, Jason McIntyre wrote:
On Sat, Mar 24, 2018 at 09:51:59AM -0400, Matt Schwartz wrote:
Hi tech@,
One small correction to relayd.conf(5). In the examples section for
TLS acceleration, the configuration option match hash "sessid" results
in a syntax error. Diff below.
Thanks,
Matt
hi.
i'm having trouble getting anyone to look at this. i don;t use relayd
myself, so it's not obvious to me. can i just check - are you using that
*exact* example from the man page? if so, can you mail me the exact
errors you get.
if not, what are you using?
i tried running the example in the man page and got a different error.
so it's not clear to me if that section is meant to be stand-alone or
not.
jmc
Index: relayd.conf.5
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v
retrieving revision 1.182
diff -u -p -r1.182 relayd.conf.5
--- relayd.conf.5 29 Nov 2017 21:17:51 - 1.182
+++ relayd.conf.5 24 Mar 2018 13:47:17 -
@@ -1484,7 +1484,6 @@ http protocol "https" {
match header set "Keep-Alive" value "$TIMEOUT"
match query hash "sessid"
- match hash "sessid"
pass
block path "/cgi-bin/index.cgi" value "*command=*"
Re: OpenBGPd Changes from 5.x to 6.2
Mike Hammett(openbsd-m...@ics-il.net) on 2018.03.26 10:34:24 -0500: > Did the config for openbgpd change from 5 to 6? I copied a config file Yes. > over and it complains about a line I have, `softreconfig in yes`. It > doesn't show in https://man.openbsd.org/bgpd.conf but > https://man.openbsd.org/bgpctl references it. http://www.openbsd.org/faq/upgrade62.html says The softreconfig (in|out) (yes|no) neighbor setting has been removed in bgpd.conf(5). softreconfig can no longer be disabled. Remove the instruction from the configuration. In case you did not notice this before: we overlooked this change originaly, and i added that line to upgrade62.html 3 weeks ago. /Benno
OpenBGPd Changes from 5.x to 6.2
Did the config for openbgpd change from 5 to 6? I copied a config file over and it complains about a line I have, `softreconfig in yes`. It doesn't show in https://man.openbsd.org/bgpd.conf but https://man.openbsd.org/bgpctl references it. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP
Re: sshd(8), sshd_config(5), and the LogLevel directive
On 2018-03-05, Stuart Henderson wrote: > On 2018-03-05, Lars Noodén wrote: >> I'm not able to get sshd(8) to use alternative loglevels, such as Debug3. >> >> When sshd(8) starts, it goes through the normal reporting regardless >> of which LogLevel is set in sshd_config(5). Here is an excerpt from >> /var/log/authlog showing the daemon starting and a first connection >> from outside: > > The default for /var/log/authlog is auth.info. To get these through > syslogd, you'll need something with .debug instead. Ah ha. I hadn't looked there. Thanks for the patience. $ grep -i authlog /etc/syslog.conf auth.info /var/log/authlog > (btw, some of the higher-level debug for SSH is fairly sensitive, you might > prefer to log it to memory buffers rather than disk That explains the syslogd(8) auth.info default. > - set the -s flag to > syslogd and then you can do things like "*.* :64:debug" and watch with > "syslogc -f debug"). Neat. It is clear now and I know what to do. Thanks. /Lars
Re: sshd(8), sshd_config(5), and the LogLevel directive
On 2018-03-05, Lars Noodén <lars.noo...@gmail.com> wrote: > I'm not able to get sshd(8) to use alternative loglevels, such as Debug3. > > When sshd(8) starts, it goes through the normal reporting regardless > of which LogLevel is set in sshd_config(5). Here is an excerpt from > /var/log/authlog showing the daemon starting and a first connection > from outside: The default for /var/log/authlog is auth.info. To get these through syslogd, you'll need something with .debug instead. (btw, some of the higher-level debug for SSH is fairly sensitive, you might prefer to log it to memory buffers rather than disk - set the -s flag to syslogd and then you can do things like "*.* :64:debug" and watch with "syslogc -f debug").
sshd(8), sshd_config(5), and the LogLevel directive
I'm not able to get sshd(8) to use alternative loglevels, such as Debug3. When sshd(8) starts, it goes through the normal reporting regardless of which LogLevel is set in sshd_config(5). Here is an excerpt from /var/log/authlog showing the daemon starting and a first connection from outside: Mar 5 08:02:37 yeeloong sshd[13495]: Server listening on 0.0.0.0 port 22. Mar 5 08:02:37 yeeloong sshd[13495]: Server listening on :: port 22. Mar 5 08:11:55 yeeloong sshd[80107]: Connection from xx.yy.zz.aa port 60502 on xx.yy.zz.bb port 22 rdomain "0" Yet the loglevel seems to be read correctly from the configuration file: # /usr/sbin/sshd -T | grep -i loglevel loglevel DEBUG3 Invoking sshd(8) with -d, -dd, -ddd produces increased logging though, just not to the log file. Is this worth a formal report? /Lars = [ using 735440 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.3-beta (GENERIC) #337: Sat Mar 3 07:36:58 MST 2018 dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC real mem = 1073741824 (1024MB) avail mem = 1055784960 (1006MB) mainbus0 at root: Lemote Yeeloong cpu0 at mainbus0: STC Loongson2F CPU 797 MHz, STC Loongson2F FPU cpu0: cache L1-I 64KB D 64KB 4 way, L2 512KB 4 way bonito0 at mainbus0: memory and PCI-X controller, rev 1 pci0 at bonito0 bus 0 rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 5, address 00:23:8b:59:df:48 rlphy0 at rl0 phy 0: RTL internal PHY smfb0 at pci0 dev 8 function 0 "Silicon Motion LynxEM+" rev 0xb0: 1024x600, 16bpp wsdisplay0 at smfb0 mux 1: console (std, vt100 emulation) glxpcib0 at pci0 dev 14 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 3579 545Hz timer, watchdog, gpio, i2c isa0 at glxpcib0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 mcclock0 at isa0 port 0x70/2: mc146818 or compatible ykbec0 at isa0 port 0x381/3 gpio1 at glxpcib0: 32 pins iic at glxpcib0 not configured glxclk0 at glxpcib0: clock, prof pciide0 at pci0 dev 14 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 1-sector PIO, LBA, 7641MB, 15649200 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) auglx0 at pci0 dev 14 function 3 "AMD CS5536 Audio" rev 0x01: isa irq 9, CS5536 AC97 ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0) audio0 at auglx0 ohci0 at pci0 dev 14 function 4 "AMD CS5536 USB" rev 0x02: isa irq 11, version 1.0, legacy support ehci0 at pci0 dev 14 function 5 "AMD CS5536 USB" rev 0x02: isa irq 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00 addr 1 apm0 at mainbus0 umass0 at uhub0 port 1 configuration 1 interface 0 "Generic USB2.0-CRW" rev 2.00/58.87 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: <Generic-, Multi-Card, 1.00> SCSI0 0/direct removable serial.0bda015811417340 urtw0 at uhub0 port 4 configuration 1 interface 0 "Realtek RTL8187B" rev 2.00/2.00 addr 3 urtw0: RTL8187B rev E, address 00:17:c4:4d:ed:56 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets pmon bootpath: /dev/disk/wd0 boot device: wd0 root on wd0a (7797d94bb0fceead.a) swap on wd0b dump on wd0b
Re: Unsetting a DHCP option in dhcpd.conf(5)
I suspect you can use groups, set it for a group and leave it out of another group. On Tue, Feb 27, 2018 at 12:55 PM, Grzegorz Kowalczyk <grzegorz.kowa...@gmail.com> wrote: > Hi, > > can an option be unset in a host declaration of dhcpd.conf(5)? > > I'm trying to set a generic "option routers A.B.C.D" option in a > subnet block and disable it in some host blocks. > > I've already skimmed through dhcpd.conf(5) and dhcp-options(5) man > pages, to no avail. >
Unsetting a DHCP option in dhcpd.conf(5)
Hi, can an option be unset in a host declaration of dhcpd.conf(5)? I'm trying to set a generic "option routers A.B.C.D" option in a subnet block and disable it in some host blocks. I've already skimmed through dhcpd.conf(5) and dhcp-options(5) man pages, to no avail.
Re: sysctl(8) didnt add parameter to sysctl.conf(5)
On 27 Dec 2017, at 21:30, Theo de Raadt wrote: >> By entering as su/doas sysctl kern.bufcachepercent=80 shows me the >> change from default=20 to 80 as expected, but after a reboot the value >> is set again/still to 20 (%). > > sysctl changes the running state. It does not change that file > for future boots. Thanks Theo, now it's clear.
Re: sysctl(8) didnt add parameter to sysctl.conf(5)
> By entering as su/doas sysctl kern.bufcachepercent=80 shows me the > change from default=20 to 80 as expected, but after a reboot the value > is set again/still to 20 (%). sysctl changes the running state. It does not change that file for future boots.
sysctl(8) didnt add parameter to sysctl.conf(5)
Hi I installed 6.2-release/syspatched on new PC with a NVMe disk, via USB Stick made from miniroot62.fs. It works fine, but something is different from other 6.2 installs on other PC/server I've installed: By entering as su/doas sysctl kern.bufcachepercent=80 shows me the change from default=20 to 80 as expected, but after a reboot the value is set again/still to 20 (%). I found out that /etc/sysctl.conf (5) doesnt exists after installation from miniroot62, and if I create the file as su/doas (new file or cp /etc/examples/sysctl.conf /etc) no entries were made to that file after typing the commands. If I add the tweak manually to sysctl.conf(5) -> it works. Any ideas or hints for me, what to check/verify? dmesg below, thank you devs for OpenBSD. -oliver OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct 3 21:22:29 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16717647872 (15943MB) avail mem = 16203964416 (15453MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6feed000 (25 entries) bios0: vendor American Megatrends Inc. version "P7.40" date 12/07/2017 bios0: ASRock H110M-STX acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT DBGP DBG2 SSDT AAFT SSDT UEFI SSDT BGRT DMAR acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz, 3192.00 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 319200 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz, 3192.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz, 3192.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz, 3192.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus -1 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus -1 (RP01) acpiprt10 at acpi0: bus -1 (RP02) acpiprt11 at acpi0: bus -1 (RP03) acpiprt12 at acpi0: bus -1 (RP04) acpiprt13 at acpi0: bus 2 (RP05) acpiprt14 at acpi0: bus -1 (RP06) acpiprt15 at acpi0: bus -1 (RP07) acpiprt16 at acpi0: bus -1 (RP08) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at acpi0:
Re: Current #197 Nov 5 umb0 ucom0 umodem0 detached.
Ah right, the bug actually trigs below, so this is the XHCI_DEBUG log for the whole bug/failure sequence. Great. > Thanks for your answer. Sorry for the delay. > > In /cc to mpi@. > >> The first thing I see when looking at your report, is that your USB >> devices were plugged in via USB3 (XHCI). > > It is a m.2 card in a ThinkPad. Yes, as it looks, they use USB3 internal. > >> Please recompile your kernel with XHCI_DEBUG, and share the debug >> output here (and with mpi@) when you have it, when the error happened >> next time. Ok? > > Build is done with the snapshot #220 from Nov 17 and the CVS from > yesterday Nov 18 evening. > > Off topic : for my understanding, I followed the FAQ for buiding a > custom kernel and used GENERIC.MP instead of GENERIC because it is a > multiprocessor machine. What is the difference of bsd and bsd.gdb what > is shown at the end of the build ? > > Output of /var/log/messages > > Nov 18 23:32:47 thinkpad-w541 pkg_add: Added git-2.15.0 > Nov 19 00:00:01 thinkpad-w541 syslogd[73165]: restart > Nov 19 05:11:27 thinkpad-w541 xlock: xlock: unable to open display . > Nov 19 05:11:27 thinkpad-w541 xlock: Stop: root, wheel, unknown > display, 0m 0s > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: port=10 change=0x00 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_abort_xfer: > xfer=0xff087b6491e0 status=IN_PROGRESS err=CANCELLED actlen=0 > len=31744 idx=103 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 3 dci 5 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_event_xfer: stopped > xfer=0xff087b6491e0 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async > dev 3 dci 5 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_abort_xfer: > xfer=0xff087b6490f0 status=IN_PROGRESS err=CANCELLED actlen=0 > len=24 idx=13 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 3 dci 3 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_event_xfer: stopped > xfer=0xff087b6490f0 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async > dev 3 dci 3 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3 > Nov 19 13:51:44 thinkpad-w541 /bsd: umb0 detached > Nov 19 13:51:44 thinkpad-w541 /bsd: ucom0 detached > Nov 19 13:51:44 thinkpad-w541 /bsd: umodem0 detached > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3 > Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: port=10 change=0x00 > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: port=10 change=0x00 > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7, > input=0xff00022cc000 slot=0xff00022cc020 > ep0=0xff00022cc040 > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7, setting DCBAA to > 0x022cd000 > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci_pipe_init: > pipe=0x80fec000 addr=0 depth=1 port=10 speed=3 dev 7 dci 1 > (epAddr=0x0) > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_address BSR=1 > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_address BSR=0 > Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7 addr 7 > Nov 19 13:51:55 thinkpad-w541 /bsd: xhci_abort_xfer: > xfer=0xff087b6490f0 status=IN_PROGRESS err=TIMEOUT actlen=0 len=2 > idx=38 > Nov 19 13:51:55 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 7 dci 1 > Nov 19 13:51:55 thinkpad-w541 /bsd: xhci_event_xfer: stopped > xfer=0xff087b6490f0 > Nov 19 13:51:55 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async > dev 7 dci 1 > Nov 19 13:52:00 thinkpad-w541 /bsd: xhci_abort_xfer: > xfer=0xff087b6490f0 status=IN_PROGRESS err=TIMEOUT actlen=0 len=0 > idx=40 > Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 7 dci 1 > Nov 19 13:52:00 thinkpad-w541 /bsd: xhci_event_xfer: stopped > xfer=0xff087b6490f0 > Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async > dev 7 dci 1 > Nov 19 13:52:00 thinkpad-w541 /bsd: uhub0: port 10, set config 0 at > addr 4 failed > Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 7 > Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control > Nov 19 13:52:00 thinkpad-w541 /bsd: uhub0: device problem, disabling > port 10 > Nov 19 18:00:01 thinkpad-w541 syslogd[73165]: restart > Nov 19 21:00:02 thinkpad-w541 syslogd[73165]: restart > Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00 > Nov 19 22:24:32 thinkpad-w541 /bsd: ugen2 detached > Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 4 >
Re: Current #197 Nov 5 umb0 ucom0 umodem0 detached.
Thanks for your answer. Sorry for the delay. In /cc to mpi@. > The first thing I see when looking at your report, is that your USB > devices were plugged in via USB3 (XHCI). It is a m.2 card in a ThinkPad. Yes, as it looks, they use USB3 internal. > Please recompile your kernel with XHCI_DEBUG, and share the debug > output here (and with mpi@) when you have it, when the error happened > next time. Ok? Build is done with the snapshot #220 from Nov 17 and the CVS from yesterday Nov 18 evening. Off topic : for my understanding, I followed the FAQ for buiding a custom kernel and used GENERIC.MP instead of GENERIC because it is a multiprocessor machine. What is the difference of bsd and bsd.gdb what is shown at the end of the build ? Output of /var/log/messages Nov 18 23:32:47 thinkpad-w541 pkg_add: Added git-2.15.0 Nov 19 00:00:01 thinkpad-w541 syslogd[73165]: restart Nov 19 05:11:27 thinkpad-w541 xlock: xlock: unable to open display . Nov 19 05:11:27 thinkpad-w541 xlock: Stop: root, wheel, unknown display, 0m 0s Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: port=10 change=0x00 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_abort_xfer: xfer=0xff087b6491e0 status=IN_PROGRESS err=CANCELLED actlen=0 len=31744 idx=103 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 3 dci 5 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_event_xfer: stopped xfer=0xff087b6491e0 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async dev 3 dci 5 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_abort_xfer: xfer=0xff087b6490f0 status=IN_PROGRESS err=CANCELLED actlen=0 len=24 idx=13 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 3 dci 3 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_event_xfer: stopped xfer=0xff087b6490f0 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async dev 3 dci 3 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3 Nov 19 13:51:44 thinkpad-w541 /bsd: umb0 detached Nov 19 13:51:44 thinkpad-w541 /bsd: ucom0 detached Nov 19 13:51:44 thinkpad-w541 /bsd: umodem0 detached Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3 Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: port=10 change=0x00 Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: port=10 change=0x00 Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7, input=0xff00022cc000 slot=0xff00022cc020 ep0=0xff00022cc040 Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7, setting DCBAA to 0x022cd000 Nov 19 13:51:50 thinkpad-w541 /bsd: xhci_pipe_init: pipe=0x80fec000 addr=0 depth=1 port=10 speed=3 dev 7 dci 1 (epAddr=0x0) Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_address BSR=1 Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_address BSR=0 Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7 addr 7 Nov 19 13:51:55 thinkpad-w541 /bsd: xhci_abort_xfer: xfer=0xff087b6490f0 status=IN_PROGRESS err=TIMEOUT actlen=0 len=2 idx=38 Nov 19 13:51:55 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 7 dci 1 Nov 19 13:51:55 thinkpad-w541 /bsd: xhci_event_xfer: stopped xfer=0xff087b6490f0 Nov 19 13:51:55 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async dev 7 dci 1 Nov 19 13:52:00 thinkpad-w541 /bsd: xhci_abort_xfer: xfer=0xff087b6490f0 status=IN_PROGRESS err=TIMEOUT actlen=0 len=0 idx=40 Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 7 dci 1 Nov 19 13:52:00 thinkpad-w541 /bsd: xhci_event_xfer: stopped xfer=0xff087b6490f0 Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async dev 7 dci 1 Nov 19 13:52:00 thinkpad-w541 /bsd: uhub0: port 10, set config 0 at addr 4 failed Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 7 Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control Nov 19 13:52:00 thinkpad-w541 /bsd: uhub0: device problem, disabling port 10 Nov 19 18:00:01 thinkpad-w541 syslogd[73165]: restart Nov 19 21:00:02 thinkpad-w541 syslogd[73165]: restart Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00 Nov 19 22:24:32 thinkpad-w541 /bsd: ugen2 detached Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 4 Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00 Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00 Nov 19 22:24:33 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control Nov 19 22:24:33 thinkpad-w541 /bsd: xhci0: dev 8, input=0xff00676d4000 slot=0xff00676d4020 ep0=0xff00676d4040 Nov 19 22:24:33 thinkpad-w541 /bsd: xhci0: dev 8, setting DCBAA to 0x676d5000 Nov 19 22:24:33 thinkpad-w541 /bsd: xhci_pipe_init: pipe=0x80fec000 addr=0 depth=1 port=11 speed=2 dev 8 dci 1 (epA
Re: Current #197 Nov 5 umb0 ucom0 umodem0 detached.
Christoph, The first thing I see when looking at your report, is that your USB devices were plugged in via USB3 (XHCI). Please recompile your kernel with XHCI_DEBUG, and share the debug output here (and with mpi@) when you have it, when the error happened next time. Ok? Tinker > Hello ! > > Today I experienced, that umb0 ucom0 umodem0 detached at the same > time. I can't reproduce it but saw it 1 time with snapshot #194 but > before not. [..] > xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev > 3.00/1.00 addr 1 [..] > umb0 at uhub0 port 10 configuration 1 interface 0 "Sierra Wireless > Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 4 > umodem0 at uhub0 port 10 configuration 1 interface 2 "Sierra Wireless > ucom0 at umodem0
Current #197 Nov 5 umb0 ucom0 umodem0 detached.
Hello ! Today I experienced, that umb0 ucom0 umodem0 detached at the same time. I can't reproduce it but saw it 1 time with snapshot #194 but before not. If I lost the connection in the past, I saw a timeout message at the xconsole and could simple re-connect. At this time umb0(4) is not longer shown with ifconfig(8) and I had to reboot to fix it. /var/log/messages show the following : Nov 6 23:55:45 thinkpad-w541 /bsd: umb0 detached Nov 6 23:55:45 thinkpad-w541 /bsd: ucom0 detached Nov 6 23:55:45 thinkpad-w541 /bsd: umodem0 detached Nov 6 23:56:02 thinkpad-w541 /bsd: uhub0: port 10, set config 0 at addr 4 failed Nov 6 23:56:02 thinkpad-w541 /bsd: uhub0: device problem, disabling port 10 Which other informations are need to help to debug ? Thanks for your answers. OpenBSD 6.2-current (GENERIC.MP) #197: Sun Nov 5 12:48:36 MST 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33938599936 (32366MB) avail mem = 32903180288 (31378MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7cd2d000 (69 entries) bios0: vendor LENOVO version "GNET81WW (2.29 )" date 11/24/2016 bios0: LENOVO 20EFS00B00 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI POAT ASF! BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2794.09 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache acpihpet0: recalibrated TSC frequency 2793557357 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.53 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.53 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.54 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.53 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 2, package 0 cpu5 at mainbus0: apid 5 (application processor) cpu5: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.53 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LON
Re: 5-button wheeled mouse and X
on Sunday 29 October 2017 at 22:13, Daniel Jakots wrote: > On Sun, 29 Oct 2017 11:37:45 -0400, gwes <g...@oat.com> wrote: > > On 10/25/17 07:20, Cág wrote: > > > Natasha Kerensikova wrote: > > > > > >> it started as a bug report: it have a 5-button mouse with a wheel, > > >> even though I don't use much the buttons 4 and 5 (I think only for > > >> previous and next in firefox history). I recently switched to > > >> OpenBSD, and I was surprised to find these buttons cause > > >> scrolling, like the wheel. If this behavior is intended, the rest > > >> of this e-mail is moot. > > > > > > This isn't a bug apparently. Are the extra buttons recognised by > > > xev? If they are, remap them with xmodmap(1). If they aren't, well, > > > then it should be done by xf86-input-evdev or libinput. There's > > > been some work in FreeBSD, and the drivers are in ports, but > > > OpenBSD doesn't have them. > > I use a 4-button Logitech trackball mouse. It required remapping in > > xmodmap to make it work. > > Yes, xev showed enough information to see "button up" and "button > > down" events to use as input to xmodmap. > > Do you mind sharing your configuration? I'm also interested in it, because my analysis led me to believe that xmodmap(1) is only able to do the equivalent of a dynamic change to the X configuration "ButtonMapping", which is used after the confusion between physical buttons 4/5 and the wheel, so they cannot be distinguished unless I'm mistaken (or unless there is some non-default "ZAxisMapping" involved, which unless I'm mistaken cannot be changed by xmodmap(1) and is constant after loading of xf86-input-ws). I would welcome being corrected if I'm wrong, especially after being told that the confusion is a feature. Natasha
Re: 5-button wheeled mouse and X
On Sun, 29 Oct 2017 11:37:45 -0400, gwes <g...@oat.com> wrote: > On 10/25/17 07:20, Cág wrote: > > Natasha Kerensikova wrote: > > > >> it started as a bug report: it have a 5-button mouse with a wheel, > >> even though I don't use much the buttons 4 and 5 (I think only for > >> previous and next in firefox history). I recently switched to > >> OpenBSD, and I was surprised to find these buttons cause > >> scrolling, like the wheel. If this behavior is intended, the rest > >> of this e-mail is moot. > > > > This isn't a bug apparently. Are the extra buttons recognised by > > xev? If they are, remap them with xmodmap(1). If they aren't, well, > > then it should be done by xf86-input-evdev or libinput. There's > > been some work in FreeBSD, and the drivers are in ports, but > > OpenBSD doesn't have them. > I use a 4-button Logitech trackball mouse. It required remapping in > xmodmap to make it work. > Yes, xev showed enough information to see "button up" and "button > down" events to use as input to xmodmap. Do you mind sharing your configuration? Cheers, Daniel
Re: 5-button wheeled mouse and X
On 10/25/17 07:20, Cág wrote: Natasha Kerensikova wrote: it started as a bug report: it have a 5-button mouse with a wheel, even though I don't use much the buttons 4 and 5 (I think only for previous and next in firefox history). I recently switched to OpenBSD, and I was surprised to find these buttons cause scrolling, like the wheel. If this behavior is intended, the rest of this e-mail is moot. This isn't a bug apparently. Are the extra buttons recognised by xev? If they are, remap them with xmodmap(1). If they aren't, well, then it should be done by xf86-input-evdev or libinput. There's been some work in FreeBSD, and the drivers are in ports, but OpenBSD doesn't have them. I use a 4-button Logitech trackball mouse. It required remapping in xmodmap to make it work. Yes, xev showed enough information to see "button up" and "button down" events to use as input to xmodmap. geoff steckel
Re: 5-button wheeled mouse and X
Natasha Kerensikova wrote: > it started as a bug report: it have a 5-button mouse with a wheel, even > though I don't use much the buttons 4 and 5 (I think only for previous > and next in firefox history). I recently switched to OpenBSD, and I was > surprised to find these buttons cause scrolling, like the wheel. If this > behavior is intended, the rest of this e-mail is moot. This isn't a bug apparently. Are the extra buttons recognised by xev? If they are, remap them with xmodmap(1). If they aren't, well, then it should be done by xf86-input-evdev or libinput. There's been some work in FreeBSD, and the drivers are in ports, but OpenBSD doesn't have them. -- caóc
5-button wheeled mouse and X
Hello, it started as a bug report: it have a 5-button mouse with a wheel, even though I don't use much the buttons 4 and 5 (I think only for previous and next in firefox history). I recently switched to OpenBSD, and I was surprised to find these buttons cause scrolling, like the wheel. If this behavior is intended, the rest of this e-mail is moot. Assuming this is indeed a bug, I went looking for a cause that I could fix, and found a philosophical or engineering question instead (hence my posting to misc@ instead of bugs@). As far as I can tell, on my setup (which I assume is common), the input is handled by wscons(4) and send to X through xf86-input-ws. I think the root cause of my problem lies in a conceptual mismatch, so I will try to use a maybe-overly precise vocabulary. The physical fidget-toy on my desk which I call "mouse" has clicky parts which I could describe as "physical buttons", and a spinning part which could be called a "physical wheel". I have no idea how this works, but wscons(4) reacts to physical buttons with WSCONS_EVENT_MOUSE_UP and WSCONS_EVENT_MOUSE_DOWN events, and the physical buttons are numbered from 1 to 5, while the physical wheel triggers WSCONS_EVENT_MOUSE_DELTA_Z with an amount of -1 or +1. So a wscons(4) button maps exactly to a physical button, and wscons(4) Z axis maps to the physical wheel. On the other side, as far as I can tell X can't handle the concept of wheel, so the wheel gets inserted as two buttons, as described by ZAxisMapping option. So by default, turning the wheel up is translated as pressing the X button 4, and turning the wheel down is pressing the X button 5. However, from my reading of the function wsSendButtons() in https://github.com/openbsd/xenocara/blob/master/driver/xf86-input-ws/src/ws.c the wscons(4) buttons are sent untranslated to X, so wscons(4) button 4 and 5, which are physical buttons, cannot be distinguished by X from turning the wheel. Meanwhile, with default configuration on Linux and FreeBSD, the physical buttons 4 and above are mysteriously translated into X buttons 8 and above, which allows Firefox to map the extra buttons to previous and next in history while the wheel is still mapped to vertical scrolling. So at this point, one could add a simple if (button >= 4) button += 4; in wsSendButtons() before the call to xf86PostButotnEvent(), and OpenBSD default behavior would match Linux and FreeBSD default behavior. But is this the right thing to do? Or are the 4 hardcoded there a little bit too magic? Maybe we want something more sound, by considering that the virtual button numbers are provided by ZAxisMapping and WAxisMapping, and populating the wscons(4) buttons in the remaining available numbers? Or maybe we/wscons(4) are more right than everybody else, and we want to keep the button numbers between wscons(4) and X, letting the user update ZAxisMapping (and WAxisMapping if they have a really fancy mouse), to available numbers, and maybe reconfiguring all their application for the new numbers. Or maybe leveraging ButtonMapping to return to the standard default numbers. Or whatever floats the user's boat without their pestering the upstream with overly long e-mails in misc@. Not sure how to conclude from there, this button issue has no impact on me outside of my firefox usage, but it keeps declining, w3m makes the web so much more readable and faster, and surf is enough for most javascript-requiring websites still worth my attention, so I let the issue go and wouldn't have posted this if it wasn't commissioned. So the above is really a brain dump of my research for people who care about the issue more than I do (though some of you might not care directly about the issue but care about the new user experiencing out-of-the-box OpenBSD). Natasha
acpidump at bootup blocking for 5 minutes
Hi, I have a Nexcom 1150 (http://www.nexcom.co.uk/Products/network-and-communication-solutions/intel-based-appliance/entry-level-appliance/network-communication-nsa-1150) which I use as Firewall and noticed that it takes up to 7 minutes to bootup. By commenting out some parts of the the /etc/rc boot file I could find out that the acpidump takes 5 minutes to run. So I just commented the following lines out to boot up faster: if [[ -x /usr/sbin/acpidump ]]; then acpidump -o /var/db/acpi/ fi Regards, Mabi
softraid i/o error 5 @ CRYPTO block
Hello During recent update from older -current amd64 to newest -current amd64 kernel printed softraid/CRYPTO error. This error message was printed after re-linking of kernel which failed. What does this mean? Small part of dmesg: sd1 at scsibus1 targ 1 lun 0: <OPENBSD, SR CRYPTO, 006> SCSI2 0/direct fixed sd1: 71682MB, 512 bytes/sector, 146805279 sectors root on rd0a swap on rd0b dump on rd0b softraid0: sd1: i/o error 5 @ CRYPTO block 27426768 syncing disks... OpenBSD 6.2-current (GENERIC.MP) #149: Sat Oct 14 14:21:11 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP *** full dmesg: https://paste.opensuse.org/ebf3782c OpenBSD 6.2-current (RAMDISK_CD) #147: Sat Oct 14 14:25:36 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 632704 (6018MB) avail mem = 6116085760 (5832MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6df0 (39 entries) bios0: vendor Acer version "V2.21" date 12/16/2013 bios0: Acer Aspire E1-531G acpi0 at bios0: rev 2 acpi0: tables DSDT FACP UEFI ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP FPDT SSDT SSDT SSDT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) CPU B960 @ 2.20GHz, 2195.37 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu at mainbus0: not configured ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 2 (RP01) acpiprt3 at acpi0: bus 3 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus 1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu at acpi0 not configured "10250759" at acpi0 not configured "ETD0500" at acpi0 not configured "INT3F0D" at acpi0 not configured "PNP0C0A" at acpi0 not configured "ACPI0003" at acpi0 not configured "PNP0C0C" at acpi0 not configured "PNP0C0D" at acpi0 not configured "PNP0C0E" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT340E" at acpi0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 ppb0 at pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: msi pci1 at ppb0 bus 1 1:0:0: mem address conflict 0xfff8/0x8 vendor "NVIDIA", unknown product 0x1140 (class display subclass VGA, rev 0xa1) at pci1 dev 0 function 0 not configured vga1 at pci0 dev 2 function 0 "Intel HD Graphics 2000" rev 0x09 wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 0 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 "Intel 7 Series HD Audio" rev 0x04 at pci0 dev 27 function 0 not configured ppb1 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: msi pci2 at ppb1 bus 2 2:0:0: mem address conflict 0xf800/0x800 bge0 at pci2 dev 0 function 0 "Broadcom BCM57785" rev 0x10, BCM57765 B0 (0x57785100): msi, address b8:88:e3:d3:08:70 brgphy0 at bge0 phy 1: BCM57765 10/100/1000baseT PHY, rev. 4 sdhc0 at pci2 dev 0 function 1 "Broadcom SD Host Controller" rev 0x10: apic 0 int 17 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma vendor "Broadcom", unknown product 0x16be (class system subclass miscellaneous, rev 0x10) at pci2 dev 0 function 2 not configured vendor "Broadcom", unknown product 0x16bf (class system subclass miscellaneous, rev 0x10) at pci2 dev 0 function 3 not configured ppb2 at pci0 dev 28 function 1 "Intel 7 Series PCIE" rev 0xc4: msi pci3 at ppb2 bus 3 iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, MIMO 2T2R, MoW, address 00:27:10:a7:bf:cc ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 0 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 "Intel HM77 LPC" rev 0x04 at pci0 dev 31 function 0 not configured
Re: USB 3.0 and i/o error 5 @ CRYPTO block
=19, result=33 trb=0x800022185e80 (0x097a10d0 0x1300 0x1008401) xhci0: error stopping endpoint xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4 xhci0: xhci_cmd_stop_ep dev 1 dci 4 xhci0: event error code=19, result=33 trb=0x800022185e80 (0x097a1000 0x1300 0x1008401) xhci0: error stopping endpoint xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4 Output from dmesg OpenBSD 6.1-current (GENERIC.MP) #1: Sat Jul 29 20:09:15 CEST 2017 b...@gateway.lan:/home/code/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4242419712 (4045MB) avail mem = 4107472896 (3917MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xf3bdb000 (64 entries) bios0: vendor HP version "J06" date 11/09/2013 bios0: HP ProLiant MicroServer Gen8 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices PCI0(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2295.10 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2295104920 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2294.79 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 13 (IPT1) acpiprt1 at acpi0: bus -1 (IPT2) acpiprt2 at acpi0: bus -1 (IPT3) acpiprt3 at acpi0: bus -1 (IPT4) acpiprt4 at acpi0: bus 3 (IPT5) acpiprt5 at acpi0: bus -1 (IPT6) acpiprt6 at acpi0: bus 4 (IPT7) acpiprt7 at acpi0: bus 1 (IPT8) acpiprt8 at acpi0: bus 7 (PT02) acpiprt9 at acpi0: bus -1 (PT03) acpiprt10 at acpi0: bus 2 (PT05) acpiprt11 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpicpu1 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpitz0 at acpi0: critical temperature is 31 degC "IPI0001" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0303" at acpi0 not configured "PNP0F13" at acpi0 not configured "ACPI000D" at acpi0 not configured ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci1 at ppb0 bus 7 ppb1 at pci0 dev 6 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci2 at ppb1 bus 2 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 8 int 21 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5 pci3 at ppb2 bus 13 ppb3 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb5 pci4 at ppb3 bus 3 bge0 at pci4 dev 0 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x572), APE firmware NCSI 1.2.46.0: msi, address d0:bf:9c:46:de:14 brgphy0 at bge0 phy 1: BCM5720C 10/100/1000baseT PHY, rev. 0 bge1 at pci4 dev 0 function 1 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x572), APE firmware NCSI 1.2.46.0: msi, address d0:bf:9c:46:de:15 brgphy1 at bge1 phy 2: BCM5720C 10/100/1000baseT PHY, rev. 0 ppb4 at pci0 dev 28 function 6 "Intel 6 Series PCIE" rev 0xb5 pci5 at ppb4 bus 4 xhci0 at pci5 dev 0 function 0 "Renesas uPD720201 xHCI" rev 0x03: msi xhci0: xHCI version 1.0 xhci0: CAPLENGTH=0x20 xhci0: DOORBELL=0x800 xhci0: RUNTIME=0x600 xhci0: 64 bytes context xhci0: supported page size 0x0001 xhci0: 6 ports and 32 slots xhci0: 4 scratch pages usb1 at xhci0: USB revision 3.0 uhub1 at usb1 configuration 1 interface 0 "Renesas xHCI root hub" rev 3.00/1.00 addr 1 xhci0: DCBAAP=00x97a xhci0: CRCR=00 (097a1000) xhci0: ERSTBA=00xf1dc9000 xhci0: ERDP=00x97a2000 xhci0: USBCMD=0x5 xhci0: IMAN=0x2 ppb5 at pci0 dev 28 function 7 "Intel 6 Series PCIE" rev 0xb5 pc
Re: USB 3.0 and i/o error 5 @ CRYPTO block
Bjorn, mpi@ and others would love to get a copy of your system's XHCI stack's debug output. Can you please enable XHCI_DEBUG in your kernel and post the output. Also please see some further notes here https://marc.info/?l=openbsd-misc=149658807922576=2 and here https://marc.info/?l=openbsd-misc=149641168519652=2 . You, me and some other people need to document what works and not and submit the logs. Please share the debug log reports and also what steps you took to produce them! Tinker On 2017-07-29 17:27, Björn Ketelaars wrote: I tried using a 2.5"-drive in an USB3.0 enclosure hooked up to an USB 3.0 port on a machine running OpenBSD current, dmesg enclosed below. The drive has been encrypted using softraid. When rsyncing files to the encrypted filesystem the copying is halted, but the system is still responsive. A quick check of /var/log/message showed: Jul 29 13:46:22 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248926416 Jul 29 13:47:27 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248926480 Jul 29 13:48:33 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248780616 ... In this state it is not possible to umount the filesystem or remove the device from softraid using bioctl. Workaround to umount the filesystem is a hard reset. My first thought was that the drive itself was broken. A fsck gave the same I/O errors. Now the strange part: When I attach the external drive to a USB 2 port, everything works as expected. No errors, and fsck finds no issues. In this configuration the external, encrypted drive is reliable. It seems that my issue is related to the USB 3.0 port of my machine. Are there any known issues with USB 3.0 and FDE using softraid? Any ideas to rule out a hardware issue? -- Björn Ketelaars GPG key: 0x4F0E5F21 OpenBSD 6.1-current (GENERIC.MP) #16: Fri Jul 28 21:09:01 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4242419712 (4045MB) avail mem = 4107489280 (3917MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xf3bdb000 (64 entries) bios0: vendor HP version "J06" date 11/09/2013 bios0: HP ProLiant MicroServer Gen8 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices PCI0(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2295.09 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2295091360 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2294.80 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 13 (IPT1) acpiprt1 at acpi0: bus -1 (IPT2) acpiprt2 at acpi0: bus -1 (IPT3) acpiprt3 at acpi0: bus -1 (IPT4) acpiprt4 at acpi0: bus 3 (IPT5) acpiprt5 at acpi0: bus -1 (IPT6) acpiprt6 at acpi0: bus 4 (IPT7) acpiprt7 at acpi0: bus 1 (IPT8) acpiprt8 at acpi0: bus 7 (PT02) acpiprt9 at acpi0: bus -1 (PT03) acpiprt10 at acpi0: bus 2 (PT05) acpiprt11 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpicpu1 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpitz0 at acpi0: critical temperature is 31 degC "IPI0001" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0303" at acpi0 not configured "PNP0F13" at acpi0 not configured "ACPI000D" at acpi0 not configured ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci1 at ppb0 bus 7 ppb1 at pci0 dev 6 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci2 at ppb1 bus 2 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 8 int 21 usb0 at ehci0: U
Re: USB 3.0 and i/o error 5 @ CRYPTO block
There are some known problems on xhci usb3.0. the driver isn't perfect yet.
USB 3.0 and i/o error 5 @ CRYPTO block
I tried using a 2.5"-drive in an USB3.0 enclosure hooked up to an USB 3.0 port on a machine running OpenBSD current, dmesg enclosed below. The drive has been encrypted using softraid. When rsyncing files to the encrypted filesystem the copying is halted, but the system is still responsive. A quick check of /var/log/message showed: Jul 29 13:46:22 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248926416 Jul 29 13:47:27 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248926480 Jul 29 13:48:33 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248780616 ... In this state it is not possible to umount the filesystem or remove the device from softraid using bioctl. Workaround to umount the filesystem is a hard reset. My first thought was that the drive itself was broken. A fsck gave the same I/O errors. Now the strange part: When I attach the external drive to a USB 2 port, everything works as expected. No errors, and fsck finds no issues. In this configuration the external, encrypted drive is reliable. It seems that my issue is related to the USB 3.0 port of my machine. Are there any known issues with USB 3.0 and FDE using softraid? Any ideas to rule out a hardware issue? -- Björn Ketelaars GPG key: 0x4F0E5F21 OpenBSD 6.1-current (GENERIC.MP) #16: Fri Jul 28 21:09:01 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4242419712 (4045MB) avail mem = 4107489280 (3917MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xf3bdb000 (64 entries) bios0: vendor HP version "J06" date 11/09/2013 bios0: HP ProLiant MicroServer Gen8 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices PCI0(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2295.09 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2295091360 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2294.80 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 13 (IPT1) acpiprt1 at acpi0: bus -1 (IPT2) acpiprt2 at acpi0: bus -1 (IPT3) acpiprt3 at acpi0: bus -1 (IPT4) acpiprt4 at acpi0: bus 3 (IPT5) acpiprt5 at acpi0: bus -1 (IPT6) acpiprt6 at acpi0: bus 4 (IPT7) acpiprt7 at acpi0: bus 1 (IPT8) acpiprt8 at acpi0: bus 7 (PT02) acpiprt9 at acpi0: bus -1 (PT03) acpiprt10 at acpi0: bus 2 (PT05) acpiprt11 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpicpu1 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpitz0 at acpi0: critical temperature is 31 degC "IPI0001" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0303" at acpi0 not configured "PNP0F13" at acpi0 not configured "ACPI000D" at acpi0 not configured ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci1 at ppb0 bus 7 ppb1 at pci0 dev 6 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci2 at ppb1 bus 2 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 8 int 21 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5 pci3 at ppb2 bus 13 ppb3 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb5 pci4 at ppb3 bus 3 bge0 at pci4 dev 0 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x572), APE firmware NCSI 1.2.46.0: msi, address d0:bf:9c:46:de:14 brgphy0 at bge0 phy 1: BCM5720C 10/100/1000baseT PHY, rev. 0 bge1 at pci4 dev 0 function 1 "Broadcom BCM5720&qu
ifstated.conf.5 diff
I am not sure that it makes sense to mention implementation details in the man page in this regard (i.e. libevent). If people want to know the details, they can read the source code. In any event, true and false are not reserved words. Regards, Rob Index: ifstated.conf.5 === RCS file: /cvs/src/usr.sbin/ifstated/ifstated.conf.5,v retrieving revision 1.9 diff -u -p -r1.9 ifstated.conf.5 --- ifstated.conf.5 24 Apr 2012 14:56:09 - 1.9 +++ ifstated.conf.5 7 Jul 2017 13:36:22 - @@ -101,10 +101,7 @@ net = '( "ping -q -c 1 -w 1 192.168.0.1 .Sh TESTS AND EVENTS .Xr ifstated 8 delegates the process of testing to libevent which associates a value with -every test, in this case -.Em true -or -.Em false . +every test, in this case true or false . Whenever the value of a test associated with the current state changes, an event is triggered and the state's body is processed. .Sh STATE DEFINITIONS
Re: dhcrelay broken after Apr 5
> On 05.07.2017, at 11:50, Kapetanakis Giannis <bil...@edu.physics.uoc.gr> > wrote: > > On 05/07/17 12:45, Reyk Floeter wrote: >> >>> On 05.07.2017, at 11:41, Kapetanakis Giannis <bil...@edu.physics.uoc.gr> >>> wrote: >>> >>> On 04/07/17 19:09, Reyk Floeter wrote: >>>> Could you try again with the attached diff? It doesn't change >>>> behavior but it adds some chatty logging when a packet is rejected. >>>> Maybe it helps to find the issue. >>>> >>>> Reyk >>> >>> I've send the bug report as detailed as I could. >>> >> >> Thanks, now it is a good bug report and I think it helps to find the issue >> with carp+dhcrelay. >> >> You had a typo in the email subject ;-) >> >>> In a few words, applying your diff gave me these: >>> Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >>> Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header >>> failed, len 364 >>> Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >>> Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header >>> failed, len 364 >>> >> >> Reyk >> > > oops :)) > > sorry for that, do you want me to send it again with the correct subject so > it's archived ok? > > G > No, no, it's fine. The content of the mail is more important. Reyk
Re: dhcrelay broken after Apr 5
On 05/07/17 12:45, Reyk Floeter wrote: > >> On 05.07.2017, at 11:41, Kapetanakis Giannis <bil...@edu.physics.uoc.gr> >> wrote: >> >> On 04/07/17 19:09, Reyk Floeter wrote: >>> Could you try again with the attached diff? It doesn't change >>> behavior but it adds some chatty logging when a packet is rejected. >>> Maybe it helps to find the issue. >>> >>> Reyk >> >> I've send the bug report as detailed as I could. >> > > Thanks, now it is a good bug report and I think it helps to find the issue > with carp+dhcrelay. > > You had a typo in the email subject ;-) > >> In a few words, applying your diff gave me these: >> Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >> Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header >> failed, len 364 >> Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >> Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header >> failed, len 364 >> > > Reyk > oops :)) sorry for that, do you want me to send it again with the correct subject so it's archived ok? G
