System hangs during boot with Intel w5-2465x (Sapphire Rapids) on ASUS Pro WS W790-ACE motherboard
Hi, I've got my hands on a sapphire rapids based workstation and tried to boot a recent snapshot of OpenBSD current. The system hangs during boot after the "efifb at mainbus0 not configured" line. I've made use of the COM port for serial console and used a preinstalled disk in order to obtain the dmesg output (see attached file). Best regards Andreas> OpenBSD/amd64 BOOTX64 3.66 boot> booting hd0a:/bsd: 17844053+4289544+413728+0+1236992 [1547285+128+1395528+1091701]=0x1a8a458 entry point at 0x1001000 [ using 4035672 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-2024 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.5-current (GENERIC.MP) #56: Wed May 8 16:21:43 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 136904871936 (130562MB) avail mem = 132733939712 (126584MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.6 @ 0x6ef49000 (88 entries) bios0: vendor American Megatrends Inc. version "1202" date 02/06/2024 bios0: ASUS Pro WS W790-ACE efi0 at bios0: UEFI 2.9 efi0: American Megatrends rev 0x50020 acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FIDT SSDT ERST MCFG BDAT HPET MSCT WDDT APIC SRAT SLIT HMAT OEM4 OEM1 OEM2 SSDT SSDT DBG2 HEST BERT SSDT DMAR FPDT SPCR TPM2 WSMT acpi0: wakeup devices PWRB(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S3) PXSX(S4) RP05(S5) PXSX(S4) RP06(S3) PXSX(S4) RP07(S3) PXSX(S4) RP08(S3) PXSX(S4) RP09(S5) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0x8000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) w5-2465X, 3700.41 MHz, 06-8f-08, patch 2b000580 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TSX_CTRL,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,XAPIC_DIS,OVERCLOCK,GDS_NO,RFDS_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,XFD cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 16-way L2 cache, 33MB 64b/line 15-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) w5-2465X, 3100.28 MHz, 06-8f-08, patch 2b000580 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TSX_CTRL,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,XAPIC_DIS,OVERCLOCK,GDS_NO,RFDS_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,XFD cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) w5-2465X, 3100.27 MHz, 06-8f-08, patch 2b000580 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,P
Re: audio(4) output doesn't work yet on ASUS ProArt X670E-CREATOR WIFI mainboard (ALC1220 CODEC)
On 3/21/23 09:53, Paul de Weerd wrote: On Mon, Mar 06, 2023 at 06:46:51PM +0100, Alexandre Ratchov wrote: | On Mon, Mar 06, 2023 at 06:29:11PM +0100, Andreas Bartelt wrote: | > > : | > > :IIRC MSI was disabled to fix lock ups. Please run with your diff for | > > :few days and pay attention on lock ups that require a reboot of the | > > :system to get audio working again. | > > : | > > :I've forwarded your mail to tech@ to try to reach other users | > > :of AMD 17h/1xh HDA. | > > : | > > | > > After running with this patch for an hour, my audio locked up. It | > > started looping, then all programs that want to run audio hang for a few | > > seconds, then continue playing but without any audio. | > > | > > Restarting sndiod doesn't help, and I have to reboot to get my audio back. | > > | > | > Thanks for testing this. | > | > On my system, audio playback worked without problems for multiple hours | > distributed over multiple sessions. Unfortunately, today, I've also | > encountered the same audio lock up problem after ~6 hours of audio playback. | > Restarting sndiod didn't help but audio was working again after reboot. | > | > For the time being, I'll keep this patch on my system since it at least | > makes audio work at all. | > | > I'd be happy to test patches in case someone has an idea how audio could be | > reliably enabled on the ASUS ProArt X670E-CREATOR WIFI (i.e., without msi). | > | | If you have some time to spend on this, I'd suggest you to check what | other operating systems do. Linux doesn't seem to disable MSI, for | instance. | | Not sure, but the problem with MSI seems to be more common on | laptops. If this is actually the case, this might be related to | power-management or alike. So I have the same motherboard as Andreas and am also running with the diff he sent earlier. What I found is that suspend/resume makes the audio work again after it stops working (i.e. no reboot needed). I think that confirms Alexandre's suspicions about it being related to power-management. thanks, that's certainly an improvement -- suspend/resume also restores audio on my system. The only side effect I've noticed is that network connectivity via igc(4) is lost after resume but ifconfig igc0 down/up makes it work again.
Re: audio(4) output doesn't work yet on ASUS ProArt X670E-CREATOR WIFI mainboard (ALC1220 CODEC)
On 3/5/23 13:36, Peter Hessler wrote:
On 2023 Mar 05 (Sun) at 09:03:01 +0100 (+0100), Alexandre Ratchov wrote:
:On Sat, Mar 04, 2023 at 04:12:22PM +0100, Andreas Bartelt wrote:
:> On 2/27/23 6:41 PM, Andreas Bartelt wrote:
:> > On 2/27/23 2:40 PM, Alexandre Ratchov wrote:
:> > > On Sat, Feb 25, 2023 at 05:20:53PM +0100, Andreas Bartelt wrote:
:> > > > Hi,
:> > > >
:> > > > I've tested a recent OpenBSD snapshot of CURRENT on an ASUS ProArt
:> > > > X670E-CREATOR WIFI mainboard. According to the information
:> > > > provided by ASUS,
:> > > > this mainboard features a "Realtek S1220A CODEC" which attaches
:> > > > as Realtek
:> > > > ALC1220 on OpenBSD -- however, audio output (tested with
:> > > > headphones on the
:> > > > line out connector) doesn't work there yet. Applications (e.g.,
mplayer,
:> > > > mpg123) hang and I can hear no sound.
:> > > >
:> > > > [I don't know if this helps but I previously also had access to
:> > > > an ASUS ROG
:> > > > STRIX B550-E GAMING mainboard which, according to ASUS, also features
an
:> > > > S1220A CODEC which also attaches as Realtek ALC1220 on OpenBSD -- audio
:> > > > output (tested on the line out connector) works there without
problems.]
:> > > >
:> > > > In order to verify that the new mainboard doesn't have a physical
defect
:> > > > with regard to the line out audio connector, I've also tested a
:> > > > FreeBSD 13.2
:> > > > BETA3 snapshot on the ASUS ProArt X670E-CREATOR WIFI mainboard.
:> > > > Audio output
:> > > > worked there out-of-the-box, so this might be a fixable problem
:> > > > on OpenBSD.
:> > > >
:> > > > I've found some info with regard to audio debugging at
:> > > > https://www.openbsd.org/faq/faq13.html#audioprob . While running
:> > > > # cat > /dev/audio0 < /dev/zero
:> > > > play.bytes doesn't increase at all:
:> > > > # audioctl play.{bytes,errors}
:> > > > play.bytes=0
:> > > > play.errors=0
:> > > >
:> > >
:> > > mixerctl shows that the host manages communicate with the codec, but
:> > > above lines suggest that DMA doesn't start. Could you check if there
:> > > are any audio-related options in the BIOS? Especially, if there's an
:> > > option to disable the microphone (or "recording" or alike), please
:> > > enable it.
:> >
:> > There's no microphone or recording specific options available. I could
:> > only identify a single audio related configuration option. Under
:> > Advanced\Onboard Devices Configuration: enable/disable "HD Audio
:> > Controller" (description says Enable/Disable Azalia HD Audio). It does
:> > exactly that, i.e., disabling this option removes the azalia1 device
:> > from OpenBSD's dmesg.
:> >
:> > With this option enabled again, mp3 playback works with FreeBSD but
:> > hangs with OpenBSD -- same BIOS config.
:> >
:>
:> I've made audio work on the ASUS ProArt X670E-CREATOR WIFI mainboard, simply
:> by enabling msi.
:>
:> azalia1 at pci21 dev 0 function 6 "AMD 17h/1xh HD Audio" rev 0x00: msi
:> azalia1: codecs: Realtek ALC1220
:> audio0 at azalia1
:>
:> The following diff fixes the problem:
:> Index: src/sys/dev/pci/azalia.c
:> ===
:> RCS file: /cvs/src/sys/dev/pci/azalia.c,v
:> retrieving revision 1.283
:> diff -u -p -r1.283 azalia.c
:> --- src/sys/dev/pci/azalia.c 21 Feb 2023 13:42:59 - 1.283
:> +++ src/sys/dev/pci/azalia.c 4 Mar 2023 15:02:31 -
:> @@ -554,7 +554,6 @@ azalia_pci_attach(struct device *parent,
:> 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;
:> }
:>
:> OK?
:>
:
:IIRC MSI was disabled to fix lock ups. Please run with your diff for
:few days and pay attention on lock ups that require a reboot of the
:system to get audio working again.
:
:I've forwarded your mail to tech@ to try to reach other users
:of AMD 17h/1xh HDA.
:
After running with this patch for an hour, my audio locked up. It
started looping, then all programs that want to run audio hang for a few
seconds, then continue playing but without any audio.
Restarting sndiod doesn't help, and I have to reboot to get my audio back.
Thanks for testing this.
On my system, audio playback worked without problems for multiple hours
distributed over multiple sessions. Unfortunately, today, I've also
encountered the same audio lock up problem after ~6 hours of audio
playback. Restarting sndiod didn't help but audio was working again
after reboot.
For the time being, I'll keep this patch on my system since it at least
makes audio work at all.
I'd be happy to test patches in case someone has an idea how audio could
be reliably enabled on the ASUS ProArt X670E-CREATOR WIFI (i.e., without
msi).
Re: audio(4) output doesn't work yet on ASUS ProArt X670E-CREATOR WIFI mainboard (ALC1220 CODEC)
On 2/27/23 6:41 PM, Andreas Bartelt wrote:
On 2/27/23 2:40 PM, Alexandre Ratchov wrote:
On Sat, Feb 25, 2023 at 05:20:53PM +0100, Andreas Bartelt wrote:
Hi,
I've tested a recent OpenBSD snapshot of CURRENT on an ASUS ProArt
X670E-CREATOR WIFI mainboard. According to the information provided
by ASUS,
this mainboard features a "Realtek S1220A CODEC" which attaches as
Realtek
ALC1220 on OpenBSD -- however, audio output (tested with headphones
on the
line out connector) doesn't work there yet. Applications (e.g., mplayer,
mpg123) hang and I can hear no sound.
[I don't know if this helps but I previously also had access to an
ASUS ROG
STRIX B550-E GAMING mainboard which, according to ASUS, also features an
S1220A CODEC which also attaches as Realtek ALC1220 on OpenBSD -- audio
output (tested on the line out connector) works there without problems.]
In order to verify that the new mainboard doesn't have a physical defect
with regard to the line out audio connector, I've also tested a
FreeBSD 13.2
BETA3 snapshot on the ASUS ProArt X670E-CREATOR WIFI mainboard. Audio
output
worked there out-of-the-box, so this might be a fixable problem on
OpenBSD.
I've found some info with regard to audio debugging at
https://www.openbsd.org/faq/faq13.html#audioprob . While running
# cat > /dev/audio0 < /dev/zero
play.bytes doesn't increase at all:
# audioctl play.{bytes,errors}
play.bytes=0
play.errors=0
mixerctl shows that the host manages communicate with the codec, but
above lines suggest that DMA doesn't start. Could you check if there
are any audio-related options in the BIOS? Especially, if there's an
option to disable the microphone (or "recording" or alike), please
enable it.
There's no microphone or recording specific options available. I could
only identify a single audio related configuration option. Under
Advanced\Onboard Devices Configuration: enable/disable "HD Audio
Controller" (description says Enable/Disable Azalia HD Audio). It does
exactly that, i.e., disabling this option removes the azalia1 device
from OpenBSD's dmesg.
With this option enabled again, mp3 playback works with FreeBSD but
hangs with OpenBSD -- same BIOS config.
I've made audio work on the ASUS ProArt X670E-CREATOR WIFI mainboard,
simply by enabling msi.
azalia1 at pci21 dev 0 function 6 "AMD 17h/1xh HD Audio" rev 0x00: msi
azalia1: codecs: Realtek ALC1220
audio0 at azalia1
The following diff fixes the problem:
Index: src/sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.283
diff -u -p -r1.283 azalia.c
--- src/sys/dev/pci/azalia.c21 Feb 2023 13:42:59 - 1.283
+++ src/sys/dev/pci/azalia.c4 Mar 2023 15:02:31 -
@@ -554,7 +554,6 @@ azalia_pci_attach(struct device *parent,
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;
}
OK?
Re: audio(4) output doesn't work yet on ASUS ProArt X670E-CREATOR WIFI mainboard (ALC1220 CODEC)
On 2/27/23 2:40 PM, Alexandre Ratchov wrote:
On Sat, Feb 25, 2023 at 05:20:53PM +0100, Andreas Bartelt wrote:
Hi,
I've tested a recent OpenBSD snapshot of CURRENT on an ASUS ProArt
X670E-CREATOR WIFI mainboard. According to the information provided by ASUS,
this mainboard features a "Realtek S1220A CODEC" which attaches as Realtek
ALC1220 on OpenBSD -- however, audio output (tested with headphones on the
line out connector) doesn't work there yet. Applications (e.g., mplayer,
mpg123) hang and I can hear no sound.
[I don't know if this helps but I previously also had access to an ASUS ROG
STRIX B550-E GAMING mainboard which, according to ASUS, also features an
S1220A CODEC which also attaches as Realtek ALC1220 on OpenBSD -- audio
output (tested on the line out connector) works there without problems.]
In order to verify that the new mainboard doesn't have a physical defect
with regard to the line out audio connector, I've also tested a FreeBSD 13.2
BETA3 snapshot on the ASUS ProArt X670E-CREATOR WIFI mainboard. Audio output
worked there out-of-the-box, so this might be a fixable problem on OpenBSD.
I've found some info with regard to audio debugging at
https://www.openbsd.org/faq/faq13.html#audioprob . While running
# cat > /dev/audio0 < /dev/zero
play.bytes doesn't increase at all:
# audioctl play.{bytes,errors}
play.bytes=0
play.errors=0
mixerctl shows that the host manages communicate with the codec, but
above lines suggest that DMA doesn't start. Could you check if there
are any audio-related options in the BIOS? Especially, if there's an
option to disable the microphone (or "recording" or alike), please
enable it.
There's no microphone or recording specific options available. I could
only identify a single audio related configuration option. Under
Advanced\Onboard Devices Configuration: enable/disable "HD Audio
Controller" (description says Enable/Disable Azalia HD Audio). It does
exactly that, i.e., disabling this option removes the azalia1 device
from OpenBSD's dmesg.
With this option enabled again, mp3 playback works with FreeBSD but
hangs with OpenBSD -- same BIOS config.
audio(4) output doesn't work yet on ASUS ProArt X670E-CREATOR WIFI mainboard (ALC1220 CODEC)
Hi,
I've tested a recent OpenBSD snapshot of CURRENT on an ASUS ProArt
X670E-CREATOR WIFI mainboard. According to the information provided by
ASUS, this mainboard features a "Realtek S1220A CODEC" which attaches as
Realtek ALC1220 on OpenBSD -- however, audio output (tested with
headphones on the line out connector) doesn't work there yet.
Applications (e.g., mplayer, mpg123) hang and I can hear no sound.
[I don't know if this helps but I previously also had access to an ASUS
ROG STRIX B550-E GAMING mainboard which, according to ASUS, also
features an S1220A CODEC which also attaches as Realtek ALC1220 on
OpenBSD -- audio output (tested on the line out connector) works there
without problems.]
In order to verify that the new mainboard doesn't have a physical defect
with regard to the line out audio connector, I've also tested a FreeBSD
13.2 BETA3 snapshot on the ASUS ProArt X670E-CREATOR WIFI mainboard.
Audio output worked there out-of-the-box, so this might be a fixable
problem on OpenBSD.
I've found some info with regard to audio debugging at
https://www.openbsd.org/faq/faq13.html#audioprob . While running
# cat > /dev/audio0 < /dev/zero
play.bytes doesn't increase at all:
# audioctl play.{bytes,errors}
play.bytes=0
play.errors=0
# mixerctl -v gives the following output:
inputs.dac-0:1=126,126
inputs.dac-2:3=126,126
inputs.dac-4:5=126,126
inputs.dac-6:7=126,126
record.adc-0:1_mute=off [ off on ]
record.adc-0:1=124,124
record.adc-2:3_mute=off [ off on ]
record.adc-2:3=124,124
inputs.mix_source=mic,mic2,line-in,hp { mic mic2 line-in hp }
inputs.mix_mic=120,120
inputs.mix_mic2=120,120
inputs.mix_line-in=120,120
inputs.mix_hp=120,120
inputs.mix2_source=dac-0:1,mix { dac-0:1 mix }
inputs.mix3_source=dac-2:3,mix { dac-2:3 mix }
inputs.mix4_source=dac-4:5,mix { dac-4:5 mix }
inputs.mix5_source=dac-6:7,mix { dac-6:7 mix }
outputs.line_source=mix2 [ mix2 ]
outputs.line_mute=off [ off on ]
outputs.line_boost=off [ off on ]
outputs.line_eapd=on [ off on ]
outputs.mic_source=mix3 [ mix2 mix3 mix4 mix5 mix8 ]
outputs.mic_mute=off [ off on ]
inputs.mic=85,85
outputs.mic_dir=input-vr80 [ none output input input-vr0 input-vr50
input-vr80 input-vr100 ]
outputs.mic2_source=mix8 [ mix2 mix3 mix4 mix5 mix8 ]
outputs.mic2_mute=off [ off on ]
inputs.mic2=85,85
outputs.mic2_dir=input-vr80 [ none output input input-vr0 input-vr50
input-vr80 input-vr100 ]
outputs.mic2_boost=off [ off on ]
outputs.line-in_source=mix4 [ mix2 mix3 mix4 mix5 mix8 ]
outputs.line-in_mute=off [ off on ]
inputs.line-in=85,85
outputs.line-in_dir=input [ none output input input-vr0 input-vr50
input-vr80 input-vr100 ]
outputs.hp_source=mix5 [ mix2 mix3 mix4 mix5 mix8 ]
outputs.hp_mute=off [ off on ]
inputs.hp=85,85
outputs.hp_dir=output [ none output input input-vr0 input-vr50
input-vr80 input-vr100 ]
outputs.hp_boost=off [ off on ]
outputs.hp_eapd=on [ off on ]
record.adc-2:3_source=mic,mic2,line-in,hp,mix { mic mic2 line-in hp mix }
record.adc-0:1_source=mic,mic2,line-in,hp,mix { mic mic2 line-in hp mix }
inputs.dac-8:9=126,126
inputs.mix8_source=dac-8:9,mix { dac-8:9 mix }
outputs.line_sense=unplugged [ unplugged plugged ]
outputs.mic_sense=unplugged [ unplugged plugged ]
outputs.mic2_sense=unplugged [ unplugged plugged ]
outputs.line-in_sense=unplugged [ unplugged plugged ]
outputs.hp_sense=unplugged [ unplugged plugged ]
outputs.master=126,126
outputs.master.mute=off [ off on ]
outputs.master.slaves=dac-0:1,dac-6:7,line,hp { dac-0:1 dac-2:3 dac-4:5
dac-6:7 line mic mic2 line-in hp dac-8:9 }
record.volume=124,124
record.volume.mute=off [ off on ]
record.volume.slaves=adc-0:1,adc-2:3 { adc-0:1 adc-2:3 mic mic2 line-in
hp }
record.enable=sysctl [ off on sysctl ]
dmesg:
OpenBSD 7.2-current (GENERIC.MP) #1075: Fri Feb 24 10:09:47 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 67725545472 (64588MB)
avail mem = 65653587968 (62612MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x794a3000 (79 entries)
bios0: vendor American Megatrends Inc. version "0922" date 02/23/2023
bios0: ASUS ProArt X670E-CREATOR WIFI
efi0 at bios0: UEFI 2.8
efi0: American Megatrends rev 0x5001a
acpi0 at bios0: ACPI 6.4Undefined scope:
\\_SB_.PCI0.GPP7.UP00.DP40.UP00.DP68
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT FIDT MCFG HPET WDRT FPDT VFCT
WPBT TPM2 SSDT CRAT CDIT SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS SSDT
SSDT SSDT SSDT SSDT
acpi0: wakeup devices GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4)
XHC0(S4) XHC1(S4) XHC2(S4) GPP0(S4) GPP1(S4) GPP2(S4) GPP7(S4) UP00(S4)
DP40(S4) UP00(S4) DP00(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 9 7950X 16
lo1 loopback interface doesn't get created anymore from /etc/hostname.lo1
Hi, after upgrading to a recent snapshot from today, I've noticed that an (additionally configured) loopback interface (i.e., lo1) doesn't get created anymore from my preexisting (and previously working) /etc/hostname.lo1 configuration. I've verified that the problem persists and affects current by rebuilding CURRENT from source just a couple of minutes ago. The configuration which previously worked: # cat /etc/hostname.lo1 inet 192.168.1.1 255.255.255.0 NONE Manual workaround after startup to get the the lo1 interface working again: ifconfig lo1 create sh /etc/netstart lo1 Best regards Andreas
Re: nginx on current implicitly enables TLS 1.3 (with only "ssl_protocols TLSv1.2; " in nginx.conf config)
On 12/1/20 2:03 PM, Theo Buehler wrote: On Tue, Dec 01, 2020 at 12:31:19PM +0100, Andreas Bartelt wrote: Hi, I think I've found a bug in current (snapshot from today) with regard to nginx from ports, LibreSSL and TLS 1.3 which is implicitly enabled even if configured otherwise. From nginx.conf: ssl_protocols TLSv1.2; Expected behavior: only enables TLS 1.2 Observed behavior on current: enables TLS 1.2 and TLS 1.3 See also my bug report at nginx mailing list: https://marc.info/?t=16066620793&r=1&w=2 Is there something wrong or missing on the LibreSSL side which triggers this bug? I think this is the consequence of this change to the ports Makefile https://cvsweb.openbsd.org/ports/www/nginx/Makefile#rev1.146 It added -DTLS1_3_VERSION=0x0304 to CFLAGS to work around the fact that LibreSSL deliberately does not expose that yet. This way, 1.3 is enabled and used. Removing that change would again disable 1.3 entirely. An alternative would be to add -DSSL_OP_NO_TLSv1_3=0x2000L to CFLAGS which I would expect to make your config to work as desired. Thanks, I've just tested adding -DSSL_OP_NO_TLSv1_3=0x2000L to CFLAGS and it works: ssl_protocols TLSv1.2; --> only TLS 1.2 is enabled ssl_protocols TLSv1.2 TLSv1.3; --> both, TLS 1.2 and TLS 1.3 are enabled Adding TLS1_3_VERSION results in nginx setting the max_proto_version to TLSv1.3 and without SSL_OP_NO_TLSv1_3, I think it's no longer possible to disable TLSv1.3. Out of curiosity: why do you want to enable TLSv1.2 only? In my opinion, there are too many (and sometimes even ugly since semantically differing) overlaps as well as real differences at protocol level between TLS versions 1.2 and 1.3. TLS 1.2 already can be configured reasonably secure and adding additional, TLS 1.3-specific configuration + code / attack surface to the game doesn't look like a good trade-off to me. That being said, I'd consider using TLS 1.3 for deployments which don't have any interoperability requirements with regard to TLS <=1.2.
nginx on current implicitly enables TLS 1.3 (with only "ssl_protocols TLSv1.2; " in nginx.conf config)
Hi, I think I've found a bug in current (snapshot from today) with regard to nginx from ports, LibreSSL and TLS 1.3 which is implicitly enabled even if configured otherwise. From nginx.conf: ssl_protocols TLSv1.2; Expected behavior: only enables TLS 1.2 Observed behavior on current: enables TLS 1.2 and TLS 1.3 See also my bug report at nginx mailing list: https://marc.info/?t=16066620793&r=1&w=2 Is there something wrong or missing on the LibreSSL side which triggers this bug? Best regards Andreas
Re: rdomain related interface configuration via hostname.if(5) broken in current
On 03/03/18 13:59, Claudio Jeker wrote: On Fri, Mar 02, 2018 at 07:22:05AM +0100, Claudio Jeker wrote: On Thu, Mar 01, 2018 at 07:18:29PM +0100, Andreas Bartelt wrote: On 03/01/18 09:07, Jiri B wrote: On Thu, Mar 01, 2018 at 08:37:38AM +0100, Andreas Bartelt wrote: Please let me know if you need further infos on my specific config. I use this (OpenBSD 6.2-current (GENERIC.MP) #6: Tue Feb 13 20:16:11 MST 2018): /etc/hostname.vether20 rdomain 20 inet 172.16.20.2 255.255.255.0 172.16.20.255 description "archive rdomain" group onion !ifconfig lo20 inet 127.0.0.1/8 !route -T20 -qn add -net 127 127.0.0.1 -reject !route -T20 -qn add default 172.16.20.1 thanks -- your variant for setting an IP address for lo(4) in the underlying interface's rdomain is less evil than delaying the ifconfig statement until /etc/rc.local is run. Your variant also still works on current. Nevertheless, I suppose there was nothing inherently wrong with my previous approach to configuring an IP address for loX via /etc/hostname.loX which is now broken on current. Or is there a good reason I'm not aware of that this variant doesn't work anymore? I will revert the changes to automatically configure the lo interfaces in -current. That should get us back to where it was before. Still I think rdomains should automatically have a 127.0.0.1 and ::1 IP configured just need to figure out how to do this properly. Atfer some more thinking I think this has nothing todo with my reverted diff. The problem is actually the new netstart and the way interfaces are now configured. Before hostname.lo1 was run (and created) after em0 was configured which was adding rdomain 1. Now lo(4) is considered a cloning interface and ifconfig lo1 create is run very early on. Because of this creation of rdomain 1 fails and so the config fails. I can confirm that the /etc/hostname.lo1 config variant from my original mail also doesn't work with yesterday's build which included your reverted patch with regard to 127.0.0.1 autocreate. However, behavior seems to have slightly changed since rdomain 1 is actually created now and lo1 also is inside rdomain 1. However, the underlying interface is not inside rdomain 1 (although it's hostname.if(5) contains a rdomain 1 statement).
Re: rdomain related interface configuration via hostname.if(5) broken in current
On 03/01/18 09:07, Jiri B wrote: On Thu, Mar 01, 2018 at 08:37:38AM +0100, Andreas Bartelt wrote: Please let me know if you need further infos on my specific config. I use this (OpenBSD 6.2-current (GENERIC.MP) #6: Tue Feb 13 20:16:11 MST 2018): /etc/hostname.vether20 rdomain 20 inet 172.16.20.2 255.255.255.0 172.16.20.255 description "archive rdomain" group onion !ifconfig lo20 inet 127.0.0.1/8 !route -T20 -qn add -net 127 127.0.0.1 -reject !route -T20 -qn add default 172.16.20.1 thanks -- your variant for setting an IP address for lo(4) in the underlying interface's rdomain is less evil than delaying the ifconfig statement until /etc/rc.local is run. Your variant also still works on current. Nevertheless, I suppose there was nothing inherently wrong with my previous approach to configuring an IP address for loX via /etc/hostname.loX which is now broken on current. Or is there a good reason I'm not aware of that this variant doesn't work anymore?
rdomain related interface configuration via hostname.if(5) broken in current
configuration of IP addresses via hostname.if(5) is currently broken for lo(4) in case it's an auto-created interface in the context of rdomain usage (i.e., putting em0 in rdomain 1 auto-creates lo1). The problem persists at least since Feb, 23rd and can be worked around by simply configuring an IP address for lo1 via ifconfig command in /etc/rc.local Example: # cat /etc/hostname.em0 rdomain 1 dhcp # cat /etc/hostname.lo1 inet 192.168.1.1 255.255.255.0 NONE This kind of config previously worked well in the following way: - rdomain 1 was created - em0 was put into rdomain 1 - lo1 was auto-created and put into rdomain 1 - /etc/hostname.lo1 added an IP address to the lo1 interface (which remained in rdomain 1) Since the breakage, this config fails to create rdomain 1. Adding a (previously redundant) "rdomain 1" statement to /etc/hostname.lo1 also doesn't solve the problem. Please let me know if you need further infos on my specific config.
Re: Change regarding ssh's SSHFP-related warnings
sorry for the noise -- I should have studied the man page. Setting CanonicalizeHostname and CanonicalDomains in ssh_config(5) resolved the problems. On 09/01/17 14:18, Andreas Bartelt wrote: A change in ssh's SSHFP-related behavior on current confuses me somewhat. I've set VerifyHostKeyDNS to 'ask' in /etc/ssh/ssh_config (before and after the observed change in behavior). Previously, ssh client always kept quiet in case the ssh host key is already known (from known_hosts). Now, ssh client also asks "Are you sure you want to continue connecting?" in case no SSHFP DNS records has been supplied via DNS at all, even when the server's HostKey is already known from known_hosts. In particular, I find this annoying when I use short hostnames on the LAN instead of FQDNs, e.g., "ssh user@host" (which resolves to host.domain.name due to a 'domain domain.name' entry in /etc/resolv.conf. However, ssh seems to directly ask for the SSHFP record 'host.' which doesn't exist in local DNS) instead of "ssh u...@host.domain.name" (works without problems) From my point of view, the expected behaviour of ssh would be to not explicitly ask the user in case the HostKey is already known from known_hosts (i.e., like it was before the observed change in behavior). It should probably also ask in case there is an actual SSHFP fingerprint mismatch, but not in case an SSHFP record is not supplied at all. Regarding the first example from above, I guess ssh should directly ask for the SSHFP record of host's FQDN (host.domain.name) instead of the hostname (host.). Best regards Andreas
Change regarding ssh's SSHFP-related warnings
A change in ssh's SSHFP-related behavior on current confuses me somewhat. I've set VerifyHostKeyDNS to 'ask' in /etc/ssh/ssh_config (before and after the observed change in behavior). Previously, ssh client always kept quiet in case the ssh host key is already known (from known_hosts). Now, ssh client also asks "Are you sure you want to continue connecting?" in case no SSHFP DNS records has been supplied via DNS at all, even when the server's HostKey is already known from known_hosts. In particular, I find this annoying when I use short hostnames on the LAN instead of FQDNs, e.g., "ssh user@host" (which resolves to host.domain.name due to a 'domain domain.name' entry in /etc/resolv.conf. However, ssh seems to directly ask for the SSHFP record 'host.' which doesn't exist in local DNS) instead of "ssh u...@host.domain.name" (works without problems) From my point of view, the expected behaviour of ssh would be to not explicitly ask the user in case the HostKey is already known from known_hosts (i.e., like it was before the observed change in behavior). It should probably also ask in case there is an actual SSHFP fingerprint mismatch, but not in case an SSHFP record is not supplied at all. Regarding the first example from above, I guess ssh should directly ask for the SSHFP record of host's FQDN (host.domain.name) instead of the hostname (host.). Best regards Andreas
Re: httpd incorrectly handles OCSP stapling
On 08/13/17 08:50, Joel Sing wrote: On Friday 11 August 2017 03:31:27 lists+b...@ggp2.com wrote: ... This should already be fixed in -current. I've just tested OCSP stapling via httpd with multiple domains on current (all domains also resolve to the same IP address in this setup). I'm observing the same problem, i.e., OCSP stapling only works for the first domain which has been defined in httpd.conf.
kernel relinking depends on checked out src tree
Hi, reorder_kernel()'s 'make newbsd' step in /etc/rc currently relies on the availability of the file /usr/src/sys/conf/makegap.sh which only works on systems with the /usr/src tree checked out. Best regards Andreas
Re: Problem with boot block / softraid on current
On 01/04/17 20:03, Stefan Sperling wrote: On Wed, Jan 04, 2017 at 07:16:55PM +0100, Stefan Sperling wrote: The diff below fixes the problem for me. As far as I can tell this should work on both 512 and 4k disks. But I cannot test with a 4k disk. And let's check for alloc() failure. Suggested by Theo. your patch also works for me - thanks a lot!
Problem with boot block / softraid on current
One of my amd64 machines does not boot anymore after updating to current (attached dmesg was obtained after booting a build of current from today but with a boot block from December, 22nd). Interestingly, the same disk (with a boot block from today's build) still boots fine with another amd64 machine (an old x61s thinkpad). The disk image makes use of a softraid(4) encrypted root partition. On the affected machine, it triggers a reboot directly after the password has been entered. I could narrow the problem down to the use of installboot(8), i.e., booting current still works on the affected machine with a boot block based on my previous build from December, 22nd. Best regards Andreas OpenBSD 6.0-current (GENERIC.MP) #0: Tue Jan 3 05:18:14 CET 2017 bu...@obsd.bartelt.name:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error d0 real mem = 17083674624 (16292MB) avail mem = 16561262592 (15794MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcba36018 (98 entries) bios0: vendor Hewlett-Packard version "J61 v03.90" date 06/01/2016 bios0: Hewlett-Packard HP Z620 Workstation acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SLIC SSDT SSDT ASF! UEFI DMAR acpi0: wakeup devices PS2K(S3) BR20(S4) EUSB(S4) USBE(S4) GBE_(S4) NPE1(S4) NPE2(S4) NPE3(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PWRB(S3) 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) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2893.29 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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2893294400 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.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,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) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,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) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application processor) cpu5: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 0, core 5, package 0 cpu6 at mainbus0: apid 12 (application processor) cpu6: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 MHz cpu6: 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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu6: 256KB 64b/line 8
Re: regression from 6.0 to -current: local connection on rdomain
On 11/02/16 17:41, Martin Pieuchot wrote: Hello Sebastien, On 01/11/16(Tue) 09:36, Sebastien Marie wrote: Hi, I experiment problem with local connection on specific rdomain. I tried to make a simple and reproductible environment. Thanks for the nice report, could you confirm the diff below fixes your issue? The idea is to stop using lo0 for every routing domain. So with this diff a new loopback is created, and used, per rdomain. thanks, your patch works for me. I have removed the "rdomain 1" line from /etc/hostname.lo1 since this is set automatically now when em2 is put into rdomain 1. Is this the intended way to configure this or should "rdomain 1" still also be explicitly set for lo1? Another functional difference is that it's crucial now to "set skip lo" in /etc/pf.conf which wasn't required for lo1 in rdomain 1 previously (i.e., I had the skip rule explicitly set to lo0 instead of lo). I suppose the new behaviour wrt pf(4) is the intended one. Best regards Andreas
Re: regression from 6.0 to -current: local connection on rdomain
On 11/01/16 10:25, Nils Frohberg wrote: On Tue, Nov 01, 2016 at 09:36:07AM +0100, Sebastien Marie wrote: I experiment problem with local connection on specific rdomain. You're probably running into the same problem as described here: http://marc.info/?l=openbsd-tech&m=147766567226714&w=2 your patch from tech@ also fixes my problem: http://marc.info/?l=openbsd-bugs&m=147772421810737&w=2 Best regards Andreas
rdomain-related breakage on current
Hi, I've stumbled over this problem since unbound <-> nsd interaction is broken for me on current [in rdomains with exception of rdomain 0]. The problem persists since at least October 23rd and maximally since somewhere after October 9th. The following test seems to reproduce it independently of unbound and nsd: # pfctl -d [ensure that PF is out of the loop] # ifconfig lo1 rdomain 1 127.0.0.1 netmask 255.0.0.0 up # nc -V1 -l 5678 from another shell: # nc -V1 127.0.0.1 5678 - doesn't work anymore. The same still works in rdomain 0 (i.e., nc -V0). Best regards Andreas
Re: very slow ssh / sshd performance on current
On 09/02/16 10:24, Alexander Bluhm wrote: On Fri, Sep 02, 2016 at 09:43:13AM +0200, Andreas Bartelt wrote: I'm observing very slow ssh / sshd performance on current (tested on amd64). Throughput is less than 1/50th of what I'm typically seeing on my boxes. This drop in performance seems to be independent of the used ciphers (tested with aes-gcm-128 & chacha20-poly1305). All tested interfaces are em(4) which, however, seems to be completely unrelated since I don't observe this huge drop in performance via nc(1) - it's >70 MB/s via nc(1) vs. ~1-2 MB/s via ssh/scp. I see a performance drop to 10 Mbit/sec on some old i386 machines with em(4). Can you try this kernel diff to see wether it is the same problem? yes, >50 MB/s now. Thanks!
very slow ssh / sshd performance on current
I'm observing very slow ssh / sshd performance on current (tested on amd64). Throughput is less than 1/50th of what I'm typically seeing on my boxes. This drop in performance seems to be independent of the used ciphers (tested with aes-gcm-128 & chacha20-poly1305). All tested interfaces are em(4) which, however, seems to be completely unrelated since I don't observe this huge drop in performance via nc(1) - it's >70 MB/s via nc(1) vs. ~1-2 MB/s via ssh/scp. OpenBSD 6.0-current (GENERIC.MP) #0: Fri Sep 2 07:25:22 CEST 2016 a...@obsd.bartelt.name:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8277159936 (7893MB) avail mem = 8021807104 (7650MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (64 entries) bios0: vendor LENOVO version "N10ET38W (1.17 )" date 08/20/2015 bios0: LENOVO 20CMCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.28 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache 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.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,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-5600U CPU @ 2.60GHz, 798.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,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-5600U CPU @ 2.60GHz, 798.16 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1 acpipwrres1 at acpi0: NVP3, resource for PEG_ acpipwrres2 at acpi0: NVP2, resource for PEG_ acpitz0 at acpi0: critical temperature is 128 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB "LEN0071" at acpi0 not configured "LEN0046" at acpi0 not configured acpibat0 at acpi0: BAT0 model "45N1113" serial 473 type LION oem "LGC" acpibat1 at acpi0: BAT1 model "45N1738" serial 1842 type LION oem "LGC" acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured
openssl s_client -reconnect falls back to session tickets of session resumption is disable
Hello, according to the man page, I would expect that the -reconnect argument is intended for specifically testing the session resumption mechanism. However, in case session resumption is disabled, it may also fall back to the use of session tickets since they are also transmitted. Possible fix: -reconnect implicitly also uses -no-ticket? Best regards Andreas
kernel panic during shutdown on armv7
I've just encountered this panic on an armv7 sabre lite board while playing around with a CURRENT snapshot from Aug, 17th. The panic occurred for a single time at system shutdown via ``halt''. I couldn't reproduce it yet. login: boot: howto=0008 curproc=0xca2c99c8 syncing disks... panic: unmount: dangling vnode Stopped at $d: ldrbr15, [r15, r15, ror r15]! TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *42015 42015 0 0x3 00 halt panic+0x18 scp=0xc03c6890 rlv=0xc03f48c8 ($d) rsp=0xcc468e94 rfp=0xcc468eb8 dounmount+0xc scp=0xc03f475c rlv=0xc03f0028 (vfs_unmountall+0x74) rsp=0xcc468ebc rfp=0xcc468ee0 r8=0xc0705abc r7=0x0001 r6=0x r5=0xc5504c00 r4=0xc5504800 vfs_unmountall+0xc scp=0xc03effc0 rlv=0xc03f0110 (vfs_shutdown+0x78) rsp=0xcc468ee4 rfp=0xcc468ef4 r8=0x0037 r7=0xca2c99c8 r6=0xcc468fb0 r5=0xc06a0660 r4=0x0008 vfs_shutdown+0xc scp=0xc03f00a4 rlv=0xc0531940 (bootsync+0x3c) rsp=0xcc468ef8 rfp=0xcc468f0c bootsync+0x10 scp=0xc0531914 rlv=0xc053cebc (boot+0xf0) rsp=0xcc468f10 rfp=0xcc468f20 r4=0x0008 boot+0x10 scp=0xc053cddc rlv=0xc03b9c08 (reboot+0x2c) rsp=0xcc468f24 rfp=0xcc468f34 reboot+0x10 scp=0xc03b9bec rlv=0xc03b9c54 (sysctl_hwperfpolicy) rsp=0xcc468f38 rfp=0xcc468f4c sys_reboot+0xc scp=0xc03b9c34 rlv=0xc05311e8 (swi_handler+0x174) rsp=0xcc468f50 rfp=0xcc468fac r4=0xcc468fb4 swi_handler+0xc scp=0xc0531080 rlv=0xc0533754 (swi_entry+0x28) rsp=0xcc468fb0 rfp=0xbfff271c r10=0x r9=0x r8=0x0004da28 r7=0x r6=0x0008 r5=0x0001 r4=0x ddb> show uvm Current UVM status: pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12 255078 VM pages: 127 active, 2376 inactive, 0 wired, 244200 free (30522 zero) min 10% (25) anon, 10% (25) vnode, 5% (12) vtext pages 0 anon, 0 vnode, 0 vtext freemin=8502, free-target=11336, inactive-target=0, wired-max=85026 faults=71510, traps=128865, intrs=0, ctxswitch=16229 fpuswitch=0 softint=10733, syscalls=122247, kmapent=22 fault counts: noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0 ok relocks(total)=3301(3301), anget(retries)=35576(0), amapcopy=35597 neighbor anon/obj pg=1898/30651, gets(lock/unlock)=13718/3301 cases: anon=28870, anoncow=6706, obj=12544, prcopy=1174, przero=22216 daemon and swap counts: woke=0, revs=0, scans=0, obscans=0, anscans=0 busy=0, freed=0, reactivate=0, deactivate=0 pageouts=0, pending=0, nswget=0 nswapdev=1, nanon=0, nanonneeded=0 nfreeanon=0 swpages=327679, swpginuse=0, swpgonly=0 paging=0 kernel pointers: objs(kern)=0xc06dda34 ddb> show bcstats Current Buffer Cache status: numbufs 1692 busymapped 0, delwri 5 kvaslots 409 avail kva slots 409 bufpages 6720, dirtypages 20 pendingreads 0, pendingwrites 0 ddb> ps TID PPID PGRPUID S FLAGS WAIT COMMAND *42015 1 42015 0 7 0x3halt 4697 0 0 0 2 0x14200zerothread 51247 0 0 0 3 0x14200 aiodoned aiodoned 71675 0 0 0 3 0x14200 syncerupdate 6617 0 0 0 3 0x14200 cleaner cleaner 5960 0 0 0 3 0x14200 reaperreaper 23257 0 0 0 3 0x14200 pgdaemon pagedaemon 99170 0 0 0 3 0x14200 bored crynlk 67974 0 0 0 3 0x14200 bored crypto 6664 0 0 0 3 0x14200 pftm pfpurge 37024 0 0 0 3 0x14200 mmctsksdmmc1 11066 0 0 0 3 0x14200 mmctsksdmmc0 22963 0 0 0 3 0x14200 usbtskusbtask 61880 0 0 0 3 0x14200 usbatsk usbatsk 4551 0 0 0 3 0x14200 bored sensors 44508 0 0 0 3 0x14200 bored softnet 89762 0 0 0 3 0x14200 bored systqmp 51826 0 0 0 3 0x14200 bored systq 88293 0 0 0 3 0x40014200idle0 58927 0 0 0 3 0x14200 kmalloc kmthread 1 0 1 0 30x82 wait init 0 -1 0 0 3 0x10200 scheduler swapper From the live system: # mount /dev/sd0a on / type ffs (local, noatime, softdep) /dev/sd0l on /home type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0d on /tmp type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0f on /usr type ffs (local, noatime, nodev, softdep) /dev/sd0g on /usr/X11R6 type ffs (local, noatime, nodev, softdep) /dev/sd0h on /usr/local type ffs (local, noatime, nodev, wxallowed, softdep) /dev/sd0k on /usr/obj type ffs (local, noatime, nodev, nosuid, sof
multiple installation problems via miniroot-imx-55.fs on armv7 SABRE Lite
Hello,
I have a couple of problems installing an OpenBSD snapshot (from
03/08/2014) via miniroot-imx-55.fs on a i.MX6 SABRE Lite board.
The default u-boot boot loader in SPI flash seems to expect
"6q_bootscript" instead of "6x_bootscript" which is on miniroot-imx-55.fs.
Simply renaming the file to 6q_bootscript lets the system hang:
<...snip...>
Loading file "/6q_bootscript" from mmc device 1:1 (xxb1)
367 bytes read
## Executing script at 10008000
AHCI . 1 slots 1 ports ? Gbps 0x0 impl SATA mode
flags:
No port device detected!
However, manually entering only the u-boot commands which are specific
for my setup worked for me:
MX6Q SABRELITE U-Boot > mmc rescan
MX6Q SABRELITE U-Boot > setenv bootargs sd0i:/bsd.umg
MX6Q SABRELITE U-Boot > setenv loadaddr 0x1880
MX6Q SABRELITE U-Boot > mmc dev 1
mmc1 is current device
MX6Q SABRELITE U-Boot > ext2load mmc 1:1 ${loadaddr} bsd.umg
Loading file "bsd.umg" from mmc device 1:1 (xxb1)
7620856 bytes read
MX6Q SABRELITE U-Boot > bootm ${loadaddr}
<...see full output of this installation session at the end of this mail...>
After booting into the OpenBSD installer menu, and switching to a shell,
I noticed minor problems with the imxenet(4) network interface. By
default, the MAC address is set to all zeros. Configuring this
interface's MAC address via "ifconfig lladdr" and then looking at the
configuration via "ifconfig imxenet0" lets the system hang (powercycle
required).
Fortunately, direct use of dhclient on this interface did work (with a
DHCP lease for an all zero MAC address).
There also seems to be a problem with the sd0 disk (SDHC card) which
can't be accessed at all (via fdisk, disklabel, newfs...). I could
verify this problem with multiple SDHC cards. Input/output errors
related to sd0 prevented installation of the system with all tested SDHC
cards.
Best Regards
Andreas
Output of the full installation session:
# cu -l cua00 -s 115200
Connected (speed 115200)
U-Boot 2009.08 (Aug 16 2012 - 10:06:42)
CPU: Freescale i.MX 6 family 0.0V at 792 MHz
Temperature: 53 C, calibration data 0x5944d87d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock : 6600Hz
ipg per clock : 6600Hz
uart clock: 8000Hz
cspi clock: 6000Hz
ahb clock : 13200Hz
axi clock : 26400Hz
emi_slow clock: 2933Hz
ddr clock : 52800Hz
usdhc1 clock : 2Hz
usdhc2 clock : 2Hz
usdhc3 clock : 2Hz
usdhc4 clock : 2Hz
nfc clock : 2400Hz
Board: MX6Q-SABRELITE:[ POR]
Boot Device: I2C
I2C: ready
DRAM: 1 GB
MMC: FSL_USDHC: 0,FSL_USDHC: 1
JEDEC ID: 0xbf:0x25:0x41
Reading SPI NOR flash 0xc [0x2000 bytes] -> ram 0x276009b8
SUCCESS
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: got MAC address from IIM: 00:00:00:00:00:00
FEC0 [PRIME]
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
mmc0(part 0) is current device
MMC: block number 0x1 exceeds max(0x0)
** Can't read from device 0 **
** Unable to use mmc 0:1 for fatload **
** Bad partition 1 **
mmc1 is current device
reading /6q_bootscript
** Unable to read "/6q_bootscript" from mmc 1:1 **
Loading file "/6q_bootscript" from mmc device 1:1 (xxb1)
** File not found /6q_bootscript
MX6Q SABRELITE U-Boot > mmc rescan
MX6Q SABRELITE U-Boot > setenv bootargs sd0i:/bsd.umg
MX6Q SABRELITE U-Boot > setenv loadaddr 0x1880
MX6Q SABRELITE U-Boot > mmc dev 1
mmc1 is current device
MX6Q SABRELITE U-Boot > ext2load mmc 1:1 ${loadaddr} bsd.umg
Loading file "bsd.umg" from mmc device 1:1 (xxb1)
7620856 bytes read
MX6Q SABRELITE U-Boot > bootm ${loadaddr}
## Booting kernel from Legacy Image at 1880 ...
Image Name: boot
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:7620792 Bytes = 7.3 MB
Load Address: 1080
Entry Point: 1080
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
OpenBSD/imx booting ...
arg0 0x0 arg1 0xeb9 arg2 0x1100
atag core flags 0 pagesize 0 rootdev 0
atag revision 00063000
atag mem start 0x1000 size 0x4000
atag cmdline [sd0i:/bsd.umg]
bootfile: sd0i:/bsd.umg
bootargs:
Allocating page tables
freestart = 0x10f45000, free_pages = 258235 (0x0003f0bb)
IRQ stack: p0x10f73000 v0xc0f73000
ABT stack: p0x10f74000 v0xc0f74000
UND stack: p0x10f75000 v0xc0f75000
SVC stack: p0x10f76000 v0xc0f76000
Creating L1 page table at 0x10f48000
Mapping kernel
Constructing L2 page tables
undefined page pmap [ using 203188 bytes of bsd ELF symbol table ]
board type: SABRE Lite
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.5 (RAMDISK-IMX) #8: Sat Mar 8 15:48:10 EST 2014
n...@bbb1.openbsd.org:/usr/src/sys/arch/armv7/compile/RAMDISK-IMX
real mem = 1073741824 (1024MB)
avail mem = 1035935744 (
HDDs become unresponsive after wake up from stand-by via apm -S
Hi, some HDDs don't wake up after stand-by via `apm -S` on CURRENT. The problem is reproducible on my PC and always affects sd1 and sd2 -- both are spinning HDDs from Western Digital (WD20EARX). sd0 (SSD) and sd3 (softraid) work as expected. console output after wake-up from `apm -S`: ahci0: device on port 1 didn't come ready, TFD: 0x80(BSY) ahci0: stopping the port, softreset slot 31 was still active. ahci0: unable to communicate with device on port 1 ahci0: device on port 2 didn't come ready, TFD: 0x80(BSY) ahci0: stopping the port, softreset slot 31 was still active. ahci0: unable to communicate with device on port 2 Trying to access sd1 or sd2 after wake-up (i.e., via `atactl sd1` which then simply hangs) results in the following console output which seems to be printed by sys/dev/dev/ic/ahci.c: ahci_get_err_ccb but SACT 0020 != 0? ahci_port_err_ccb_restore but SACT 0020 != 0? (these messages get repeated over time and the actual SACT value showed different values != 0 during my tests...) Best Regards Andreas OpenBSD 5.3-current (GENERIC.MP) #0: Thu May 30 13:50:53 CEST 2013 r...@testhp.test.local:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8466038784 (8073MB) avail mem = 823296 (7851MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb7b0 (56 entries) bios0: vendor Intel Corp. version "KCH7710H.86A.0108.2013.0305.1638" date 03/05/2013 bios0: Intel Corporation DH77KC acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S3) P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) BR21(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(S4) PWRB(S3) 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) i7-3770K CPU @ 3.50GHz, 3492.59 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,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 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,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu4: 256KB 64b/line 8-way L2 cache cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu5: 256KB 64b/line 8-way L2 cache cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3492.07 MHz cpu6: 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,
rc.conf: disable inetd by default
Hi, revision 1.177 doesn't disable inetd. Fix is attached. I suppose the new behavior should also be documented in http://www.openbsd.org/faq/current.html Best Regards Andreas Index: rc.conf === RCS file: /cvs/src/etc/rc.conf,v retrieving revision 1.177 diff -u -p -u -r1.177 rc.conf --- rc.conf 21 Apr 2013 10:30:58 - 1.177 +++ rc.conf 23 Apr 2013 14:38:51 - @@ -132,7 +132,7 @@ shlib_dirs= # extra directories for ld # started in the specified order and stopped in reverse order pkg_scripts= -unset inetd_flags rwhod_flags portmap_flags kdc_flags kadmind_flags +unset rwhod_flags portmap_flags kdc_flags kadmind_flags unset kpasswdd_flags nfsd_flags mountd_flags lockd_flags unset statd_flags amd_flags ypbind_flags sndiod_flags
dhclient dumps core
Hi, I've noticed that dhclient "reproducably" dumps core after running for less than 24 hours. The problem persists for at least the last two i386 snapshots. The lease time from the dhcp server in this setup is one hour. # cat /var/log/messages | grep dhclient ... Feb 14 13:31:13 host dhclient[11144]: default route write: No such process Feb 14 14:01:13 host dhclient[11144]: default route write: No such process Feb 14 14:31:13 host dhclient[11144]: default route write: No such process Feb 14 15:01:13 host dhclient[11144]: default route write: No such process Feb 14 15:31:13 host dhclient[11144]: imsg_read(priv_ibuf): Resource temporarily unavailable Feb 14 15:31:13 host dhclient[8160]: write_file: imsg_flush: Broken pipe Feb 14 15:31:13 host dhclient[8160]: lost connection to [priv] Feb 14 15:31:13 host dhclient[8160]: cleanup: imsg_flush: Broken pipe The dhclient interface runs in a separate rdomain (this didn't cause problems in the past -- I don't know if it's related to the problem): # cat /etc/hostname.vr0 !ifconfig vr0 rdomain 1 dhcp Best Regards Andreas
Re: netstat(1) open socket listings and rdomains
On 10/31/11 06:18, Andreas Bartelt wrote:
...
> I think there's still an inconsistency there. According to the
> netstat(1) man page, Table 0 is the default table. This is the behavior
> of "netstat -anf inet" with your patch applied.
>
> However, when a user/process is in rdomain 1 (i.e. via "route -T 1 exec
> su -" or logging in via sshd running in rdomain 1), "netstat -rn" shows
> the routing table of (the effectively used) rdomain 1. Although this
> differs from the man page, it's the behavior I would expect for "netstat
> -rn" -- and also for "netstat -anf inet".
>
the attached diff should implement the behavior from above.
I've further noticed that rdomains are currently not fully transparent
to some daemons (i.e., transmission-cli). In case a daemon doesn't
provide an option for binding to a specific interface/ip-address, it
usually tries to bind to all available interfaces -- regardless if the
respective interface is in the same rdomain or not...
Index: src/usr.bin/netstat//main.c
===
RCS file: /usr/cvsync/cvs/src/usr.bin/netstat/main.c,v
retrieving revision 1.90
diff -u -r1.90 main.c
--- src/usr.bin/netstat//main.c 1 Nov 2011 00:00:01 - 1.90
+++ src/usr.bin/netstat//main.c 1 Nov 2011 09:28:20 -
@@ -371,6 +371,8 @@
intpr(interval, repeatcount);
exit(0);
}
+ if (!Tflag)
+ tableid = getrtable();
if (rflag) {
if (sflag)
rt_stats();
@@ -379,7 +381,7 @@
nl[N_AF2RTAFIDX].n_value, nl[N_RTBLIDMAX].n_value,
tableid);
else
- p_rttables(af, tableid, Tflag);
+ p_rttables(af, tableid);
exit(0);
}
if (gflag) {
Index: src/usr.bin/netstat//netstat.1
===
RCS file: /usr/cvsync/cvs/src/usr.bin/netstat/netstat.1,v
retrieving revision 1.66
diff -u -r1.66 netstat.1
--- src/usr.bin/netstat//netstat.1 3 Sep 2011 22:59:07 - 1.66
+++ src/usr.bin/netstat//netstat.1 1 Nov 2011 09:36:28 -
@@ -273,7 +273,6 @@
If this option is repeated, counters with a value of zero are suppressed.
.It Fl T Ar tableid
Select an alternate routing table to modify or query.
-Table 0 is the default table.
.It Fl t
With the
.Fl i
Index: src/usr.bin/netstat//netstat.h
===
RCS file: /usr/cvsync/cvs/src/usr.bin/netstat/netstat.h,v
retrieving revision 1.61
diff -u -r1.61 netstat.h
--- src/usr.bin/netstat//netstat.h 1 Nov 2011 00:00:01 - 1.61
+++ src/usr.bin/netstat//netstat.h 1 Nov 2011 09:05:23 -
@@ -116,7 +116,7 @@
char *routename6(struct sockaddr_in6 *);
char *netname6(struct sockaddr_in6 *, struct sockaddr_in6 *);
-void p_rttables(int, u_int, int);
+void p_rttables(int, u_int);
void p_flags(int, char *);
void p_addr(struct sockaddr *, struct sockaddr *, int);
void p_gwaddr(struct sockaddr *, int);
Index: src/usr.bin/netstat//show.c
===
RCS file: /usr/cvsync/cvs/src/usr.bin/netstat/show.c,v
retrieving revision 1.34
diff -u -r1.34 show.c
--- src/usr.bin/netstat//show.c 11 Oct 2010 12:33:36 - 1.34
+++ src/usr.bin/netstat//show.c 1 Nov 2011 09:06:46 -
@@ -116,7 +116,7 @@
* Print routing tables.
*/
void
-p_rttables(int af, u_int tableid, int hastable)
+p_rttables(int af, u_int tableid)
{
struct rt_msghdr *rtm;
struct sadb_msg *msg;
@@ -131,11 +131,8 @@
mib[3] = af;
mib[4] = NET_RT_DUMP;
mib[5] = 0;
- if (hastable) {
- mib[6] = tableid;
- mcnt = 7;
- } else
- mcnt = 6;
+ mib[6] = tableid;
+ mcnt = 7;
if (sysctl(mib, mcnt, NULL, &needed, NULL, 0) < 0)
err(1, "route-sysctl-estimate");
Re: netstat(1) open socket listings and rdomains
On 10/30/11 19:04, Mike Belopuhov wrote: ... fair enough, we should properly support -T flag. this diff achieves that and works well in my setup. ok? thanks, your patch supports the -T flag for socket listings. I think there's still an inconsistency there. According to the netstat(1) man page, Table 0 is the default table. This is the behavior of "netstat -anf inet" with your patch applied. However, when a user/process is in rdomain 1 (i.e. via "route -T 1 exec su -" or logging in via sshd running in rdomain 1), "netstat -rn" shows the routing table of (the effectively used) rdomain 1. Although this differs from the man page, it's the behavior I would expect for "netstat -rn" -- and also for "netstat -anf inet". Best Regards Andreas
netstat(1) open socket listings and rdomains
Hello, while playing with rdomains I've noticed that netstat(1) only respects the -T flag for route listings (i.e. netstat -T 1 -rn), but not for open socket listings (i.e. netstat -T 1 -anf inet). There are no listening services in a freshly created rdomain (i.e. after "ifconfig em0 rdomain1"). However, the following commands currently ignore this and simply return a listing of all inet sockets, respectively: # netstat -T 0 -anf inet # netstat -T 1 -anf inet A quick workaround would be to forbid the usage of the -T flag without an -r flag. A much nicer solution would be to only show open sockets from the currently used rdomain or the rdomain which is explicitely specified via -T. Best Regards Andreas
Re: kernel/6524: vge(4) goes dead under load on recent snapshots
The following reply was made to PR kernel/6524; it has been noted by GNATS. From: Andreas Bartelt To: Mark Kettenis Cc: gn...@openbsd.org, b...@cvs.openbsd.org Subject: Re: kernel/6524: vge(4) goes dead under load on recent snapshots Date: Thu, 16 Dec 2010 13:18:41 +0100 Hello Mark, On 12/16/10 11:54, Mark Kettenis wrote: > Does this diff fix the issue? > I've tested the patch. It doesn't fix the problem. Best regards Andreas
Re: kernel/6524: vge(4) goes dead under load on recent snapshots
Hello Mark, On 12/16/10 11:54, Mark Kettenis wrote: Does this diff fix the issue? I've tested the patch. It doesn't fix the problem. Best regards Andreas
