Re: Firefox Not Launching - XPCOMGlueLoad error for file /usr/local/lib/firefox/libmozwayland.so.132.0: File not found
Hi Claudio, * Claudio Miranda wrote: > Hello, > > I just updated all my packages on both my OpenBSD 7.4-current systems > (also updated to the latest snapshot) and I notice that Firefox is not > launching. It spits out the following error when I launch it from the > terminal. > > XPCOMGlueLoad error for file /usr/local/lib/firefox/libmozwayland.so.132.0: > File not found > Couldn't load XPCOM. I also stumbled over it and reported it to ports@ this morning. It is already fixed in CVS and new p0 packages should be available soon. Cheers Matthias
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
* Stuart Henderson wrote: > On 2023/06/13 11:57, Matthias Schmidt wrote: > > $ pkg_info -vv screen | head -30 > > Information for inst:screen-4.9.0 > > [...] > > Size: 1244302 > > Signature: screen-4.9.0,10,c.97.0,curses.14.0,util.16.0 > > Packing-list: > > @comment $OpenBSD: PLIST,v 1.24 2019/08/15 21:01:49 naddy Exp $ > > @name screen-4.9.0 > > @url file:./screen-4.9.0.tgz > > @version 10 > > I'm at a loss to explain how you've got screen-4.9.0 linked against > libc.so.97.0 with @version 10 but with @comment still in the PLIST. > The only way I can see is building locally with parts of an old and > parts of a new ports tree. > > However that happened, I think it is beyond what pkg_add -u can be > expected to deal with. Absolutely, that was my own stupidity. Fixed by now and screen works as expected.
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
Hi, * Sebastien Marie wrote: > On Mon, Jun 12, 2023 at 07:39:21PM +0200, Peter N. M. Hansteen wrote: > > > > That lead to, as far as I can tell, to every package on the system being > > reinstalled. > > > > However, unfortunately both firefox and thunderbird still dump core with > > "Illegal instruction". > > these ones are a bit expected. I have some more packages that abort with SIGILL upon startup: $ pkg_info -vv neovim | head -30 Information for inst:neovim-0.9.1 [...] Size: 28354538 Signature: neovim-0.9.1,10,@desktop-file-utils-0.26,@gettext-runtime-0.21.1,@gtk4-update-icon-cache-4.10.4,@libmpack-1.0.3,@libtermkey-0.22,@libuv-1.44.2,@libvterm-0.3v0,@lua-5.1.5p7,@lua-compat53-0.9,@lua-libmpack-1.0.3,@msgpack-2.1.5p0,@tree-sitter-0.20.8,@unibilium-2.1.0,c++abi.6.0,c.97.0,iconv.7.1,intl.7.0,m.10.1,msgpackc.1.0,pthread.27.0,termkey.0.2,tree-sitter.3.0,unibilium.1.1,util.16.0,uv.4.1,vterm.2.0 Packing-list: @name neovim-0.9.1 @url https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/neovim-0.9.1.tgz @version 10 @signer openbsd-73-pkg @digital-signature signify2:2023-06-11T20:30:08Z:external @option manual-installation @comment pkgpath=editors/neovim ftp=yes $ egdb /usr/local/bin/nvim nvim.core Reading symbols from /usr/local/bin/nvim... (No debugging symbols found in /usr/local/bin/nvim) [New process 155716] Core was generated by `nvim'. Program terminated with signal SIGILL, Illegal instruction. #0 0x08374ed28152 in lj_BC_FUNCC () (gdb) bt #0 0x08374ed28152 in lj_BC_FUNCC () #1 0x08374ed9ef1a in luaL_openlibs () #2 0x08374ef78d54 in nlua_init () #3 0x08374edab3b5 in main () (gdb) disassemble Dump of assembler code for function lj_BC_FUNCC: => 0x08374ed28152 <+0>: movrbp,QWORD PTR [rdx-0x10] 0x08374ed28156 <+4>: shlrbp,0x11 0x08374ed2815a <+8>: shrrbp,0x11 0x08374ed2815e <+12>:movr15,QWORD PTR [rbp+0x28] 0x08374ed28162 <+16>:movrbp,QWORD PTR [rsp+0x10] 0x08374ed28167 <+21>:learax,[rdx+rax*8-0x8] 0x08374ed2816c <+26>:movQWORD PTR [rbp+0x20],rdx 0x08374ed28170 <+30>:learcx,[rax+0xa0] 0x08374ed28177 <+37>:cmprcx,QWORD PTR [rbp+0x30] 0x08374ed2817b <+41>:movQWORD PTR [rbp+0x28],rax 0x08374ed2817f <+45>:movrdi,rbp 0x08374ed28182 <+48>:ja 0x8374ed2839f 0x08374ed28188 <+54>:movDWORD PTR [r14-0xec8],0xfffe 0x08374ed28193 <+65>:call r15 0x08374ed28196 <+68>:movrdx,QWORD PTR [rbp+0x20] 0x08374ed2819a <+72>:movQWORD PTR [r14-0xe10],rbp 0x08374ed281a1 <+79>:movDWORD PTR [r14-0xec8],0x 0x08374ed281ac <+90>:learcx,[rdx+rax*8] 0x08374ed281b0 <+94>:negrcx 0x08374ed281b3 <+97>:addrcx,QWORD PTR [rbp+0x28] 0x08374ed281b7 <+101>: movrbx,QWORD PTR [rdx-0x8] 0x08374ed281bb <+105>: jmp0x8374ed2825c End of assembler dump. Latest screen aborts as well. Both the vanilla version and my own compilation (same as in ports plus 256 color support). $ pkg_info -vv screen | head -30 Information for inst:screen-4.9.0 [...] Size: 1244302 Signature: screen-4.9.0,10,c.97.0,curses.14.0,util.16.0 Packing-list: @comment $OpenBSD: PLIST,v 1.24 2019/08/15 21:01:49 naddy Exp $ @name screen-4.9.0 @url file:./screen-4.9.0.tgz @version 10 $ egdb /usr/local/bin/screen screen.core Reading symbols from /usr/local/bin/screen... (No debugging symbols found in /usr/local/bin/screen) [New process 352402] Core was generated by `screen'. Program terminated with signal SIGILL, Illegal instruction. #0 0x0e68ac0e6780 in _start () (gdb) bt #0 0x0e68ac0e6780 in _start () (gdb) disassemble Dump of assembler code for function _start: => 0x0e68ac0e6780 <+0>: movrcx,rdx 0x0e68ac0e6783 <+3>: movrdi,QWORD PTR [rsp] 0x0e68ac0e6787 <+7>: leardx,[rsp+rdi*8+0x10] 0x0e68ac0e678c <+12>:learsi,[rsp+0x8] 0x0e68ac0e6791 <+17>:subrsp,0x8 0x0e68ac0e6795 <+21>:andrsp,0xfff0 0x0e68ac0e6799 <+25>:addrsp,0x8 0x0e68ac0e679d <+29>:jmp0xe68ac0e67a0 <_start+32> 0x0e68ac0e679f <+31>:int3 0x0e68ac0e67a0 <+32>:push rbp
softraid CRYPTO i/o error on internal NVME
Hi, I got the following message several times in dmesg upon suspend of my Laptop. sd2 is the encrypted volume of sd0 which is the internal NVME drive of the laptop. softraid0: sd2: i/o error 5 @ CRYPTO block 3391043600 It happens reliabliy on suspend/resume, I haven't seen the message during normal operation. My questions now: - Is this something I should be concerned about? - Is there someting I can do to fix (?) this? - Anything else to enable further debugging, etc that could help you? Cheers and thanks Matthias OpenBSD 7.3-current (GENERIC.MP) #1138: Thu Apr 13 11:35:07 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34064420864 (32486MB) avail mem = 33012559872 (31483MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x43ca1000 (119 entries) bios0: vendor American Megatrends International, LLC. version "N.1.15A09" date 03/24/2022 bios0: TUXEDO TUXEDO InfinityBook Pro 14 Gen6 efi0 at bios0: UEFI 2.7 efi0: American Megatrends rev 0x50013 acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP MCFG SSDT FIDT SSDT SSDT SSDT HPET APIC SSDT SSDT NHLT UEFI LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT SSDT BGRT PTDT WSMT FPDT acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xc000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4788.96 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,WAITPKG,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-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 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4788.97 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01 cpu3:
Re: Display regression - flickers with every mouse movement
Hi Jonathan, * Jonathan Gray wrote: > > Can you remove the lines added in the diff one at a time > to figure out which specific parameter is involved? Result of commenting each of the following variables individually, building a new kernel and rebooting each time. dev_priv->params.panel_use_ssc -> no flickering dev_priv->params.enable_dc -> no flickering dev_priv->params.enable_fbc -> no flickering dev_priv->params.enable_psr -> flickers dev_priv->params.disable_power_well -> no flickering dev_priv->params.enable_ips -> no flickering Then I built another kernel and commented all of the above expect for enable_psr. This also leads to no flickering. I didn't test all possible permutations :) Is there anything else I should test? Cheers Matthias
Re: Display regression - flickers with every mouse movement
Hi Jonathan, * Jonathan Gray wrote: > On Mon, Sep 12, 2022 at 09:10:22AM +0200, Matthias Schmidt wrote: > > >Synopsis: Display flickers upon touchpad movement > > >Environment: > > System : OpenBSD 7.2 > > Details : OpenBSD 7.2 (GENERIC.MP) #720: Sun Sep 11 15:41:58 MDT > > 2022 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > > > Hi, > > > > I noticed a regression between 7.2-beta from Sept 6 and the current > > snapshot. > > As soon as I move the mouse with the trackpad the screen flickers. It does > > not > > happen if I use the keyboard. With all other snapshots before I never had > > that > > issue. I made a video for demonstration purposes: > > > > https://xosc.org/misc/flickr.mp4 > > > > [ At first, I move the mouse, then type on the keyboard and the screen > > stops flickering, then switch to Firefox, move the mouse again and the > > screen again starts to flicker ] > > > > Cheers > > > > Matthias > > > > >How-To-Repeat: > > > > Upgrade to latest snapshot on this type of machine. > > > > >Fix: > > Dunno. > > some defaults for power saving features recently changed > > does this diff change what you see? Indeed, this fixes the issue for me. No more flickering here. Cheers and thanks a lot for the fast response! Matthias
Display regression - flickers with every mouse movement
>Synopsis: Display flickers upon touchpad movement >Environment: System : OpenBSD 7.2 Details : OpenBSD 7.2 (GENERIC.MP) #720: Sun Sep 11 15:41:58 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: Hi, I noticed a regression between 7.2-beta from Sept 6 and the current snapshot. As soon as I move the mouse with the trackpad the screen flickers. It does not happen if I use the keyboard. With all other snapshots before I never had that issue. I made a video for demonstration purposes: https://xosc.org/misc/flickr.mp4 [ At first, I move the mouse, then type on the keyboard and the screen stops flickering, then switch to Firefox, move the mouse again and the screen again starts to flicker ] Cheers Matthias >How-To-Repeat: Upgrade to latest snapshot on this type of machine. >Fix: Dunno. OpenBSD 7.2 (GENERIC.MP) #720: Sun Sep 11 15:41:58 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34064420864 (32486MB) avail mem = 33014624256 (31485MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x43ca1000 (119 entries) bios0: vendor American Megatrends International, LLC. version "N.1.15A09" date 03/24/2022 bios0: TUXEDO TUXEDO InfinityBook Pro 14 Gen6 acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP MCFG SSDT FIDT SSDT SSDT SSDT HPET APIC SSDT SSDT NHLT UEFI LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT SSDT BGRT PTDT WSMT FPDT acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xc000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4788.96 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-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 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4788.97 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.11 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01 cpu3:
Re: imt(4) Touchpad freezes from time to time
Hi Joshua, * joshua stein wrote: > On Tue, 31 May 2022 at 15:37:21 +0200, Matthias Schmidt wrote: > > Hi, > > > > weekly bump. Anyone (maybe jcs@) has an idea on how to debug this? > > You could enable IHIDEV_DEBUG in ihidev.c and see if it logs > anything when the touchpad freezes. Thanks, that works. Every time I move on the touchpad, I get an event. Here are the inital ihidev messages upon boot: May 31 20:12:56 kronos /bsd: ihidev0 at iic1 addr 0x2cihidev0: HID command I2C_HID_CMD_DESCR at 0x20 May 31 20:12:56 kronos /bsd: ihidev0: HID descriptor: 1e 00 00 01 7f 02 21 00 24 00 1f 00 25 00 00 00 22 00 23 00 3a 09 55 02 04 59 00 00 00 00 May 31 20:12:56 kronos /bsd: ihidev0: resetting May 31 20:12:56 kronos /bsd: ihidev0: HID command I2C_HID_CMD_SET_POWER(0) May 31 20:12:56 kronos /bsd: ihidev0: HID command I2C_HID_CMD_RESET May 31 20:12:56 kronos /bsd: ihidev0: HID command I2C_HID_REPORT_DESCR at 0x21 with size 639 May 31 20:12:56 kronos /bsd: ihidev0: HID report descriptor: 05 01 09 02 a1 01 85 02 05 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 05 0d 09 32 75 01 95 01 81 02 75 05 95 01 81 03 05 01 75 10 95 01 35 00 45 00 16 00 80 26 ff 7f 09 30 81 26 16 00 80 26 ff 7f 09 31 81 26 c0 c0 05 0d 09 05 a1 01 85 01 05 0d 09 22 a1 02 09 47 09 42 15 00 25 01 75 01 95 02 81 02 95 06 81 03 09 51 25 05 75 08 95 01 81 02 05 01 09 30 75 10 55 0e 65 11 35 00 46 00 05 27 4c 06 00 00 81 02 09 31 46 0c 03 27 d6 03 00 00 81 02 c0 05 0d 09 22 a1 02 09 47 09 42 15 00 25 01 75 01 95 02 81 02 95 06 81 03 09 51 25 05 75 08 95 01 81 02 05 01 09 30 75 10 55 0e 65 11 35 00 46 00 05 27 4c 06 00 00 81 02 09 31 46 0c 03 27 d6 03 00 00 81 02 c0 05 0d 09 22 a1 02 09 47 09 42 15 00 25 01 75 01 95 02 81 02 95 06 81 03 09 51 25 05 75 08 95 01 81 02 05 01 09 30 75 10 55 0e 65 11 35 00 46 00 05 27 4c 06 00 00 81 02 09 31 46 0c 03 27 d6 03 00 00 81 02 c0 05 0d 09 22 a1 02 09 47 09 42 15 00 25 01 75 01 95 02 81 02 95 06 81 03 09 51 25 05 75 08 95 01 81 02 05 01 09 30 75 10 55 0e 65 11 35 00 46 00 05 27 4c 06 00 00 81 02 09 31 46 0c 03 27 d6 03 00 00 81 02 c0 05 0d 09 54 15 00 25 04 75 08 95 01 81 02 05 09 09 01 15 00 25 01 75 01 95 01 81 02 95 07 81 03 05 0d 09 56 55 0c 66 01 10 35 00 47 ff ff 00 00 15 00 27 ff ff 00 00 75 10 95 01 81 02 06 0d 00 09 55 15 00 26 04 00 75 08 96 01 00 85 03 b1 02 06 0d 00 09 59 15 00 26 01 00 75 08 96 01 00 85 04 b1 02 06 00 ff 85 05 75 08 15 00 09 c6 25 08 95 01 b1 02 09 c7 26 ff 00 95 20 b1 02 c0 05 0d 09 0e a1 01 05 0d 09 22 a1 02 09 52 15 00 25 0a 75 08 95 01 85 06 b1 02 c0 05 0d 09 22 a1 00 09 57 09 58 15 00 25 01 75 01 95 02 85 07 b1 02 95 06 b1 03 c0 05 0d 09 60 15 00 25 01 75 01 95 01 85 08 b1 02 95 07 b1 03 c0 06 00 ff 09 01 a1 01 85 42 09 06 15 00 26 ff 00 75 08 95 03 b1 02 06 00 ff 09 05 15 00 26 ff 00 75 08 96 00 01 85 41 b1 02 85 43 09 06 15 00 26 ff 00 75 08 95 03 b1 02 06 00 ff 09 11 15 00 26 ff 00 75 08 96 10 00 85 0c b1 02 c0 May 31 20:12:56 kronos /bsd: ihidev0: 67 report ids May 31 20:12:56 kronos /bsd: ihidev0: repid 1 size 28 May 31 20:12:56 kronos /bsd: ihidev0: repid 2 size 5 May 31 20:12:56 kronos /bsd: imt0 at ihidev0ihidev0: HID command I2C_HID_CMD_GET_REPORT 3 (type 3, len 1) May 31 20:12:56 kronos /bsd: ihidev0: response: 04 00 03 04 May 31 20:12:56 kronos /bsd: ihidev0: HID command I2C_HID_CMD_SET_REPORT 6 (type 3, len 2): 03 00 May 31 20:12:56 kronos /bsd: ims0 at ihidev0 reportid 2: 2 buttons May 31 20:12:56 kronos /bsd: hid at ihidev0 reportid 4 not configured May 31 20:12:56 kronos /bsd: hid at ihidev0 reportid 5 not configured May 31 20:12:56 kronos /bsd: hid at ihidev0 reportid 7 not configured May 31 20:12:56 kronos /bsd: hid at ihidev0 reportid 8 not configured May 31 20:12:56 kronos /bsd: hid at ihidev0 reportid 12 not configured May 31 20:12:56 kronos /bsd: hid at ihidev0 reportid 65 not configured May 31 20:12:56 kronos /bsd: hid at ihidev0 reportid 66 not configured May 31 20:12:56 kronos /bsd: hid at ihidev0 reportid 67 not configured May 31 20:12:56 kronos /bsd: ihidev0: HID command I2C_HID_CMD_SET_POWER(1) May 31 20:12:56 kronos /bsd: ihidev0: ihidev_intr: invalid packet size (0 vs. 31) May 31 20:12:58 kronos /bsd: ihidev0: ihidev_open: state=0 refcnt=0 May 31 20:12:58 kronos /bsd: ihidev0: resetting May 31 20:12:58 kronos /bsd: ihidev0: HID command I2C_HID_CMD_SET_POWER(0) May 31 20:12:58 kronos /bsd: ihidev0: HID command I2C_HID_CMD_RESET May 31 20:12:58 kronos /bsd: ihidev0: ihidev_intr: invalid packet size (0 vs. 31) May 31 20:12:58 kronos /bsd: ihidev0: ihidev_intr: invalid packet size (0 vs. 31) May 31 20:12:59 kronos /bsd: ihidev0: HID command I2C_HID_CMD_SET_REPORT 6 (type 3, len 2): 03 00 May 31 20:12:59 kronos /bsd: ihidev0: ihidev_close: state=1 refcnt=1 May 31 20:12:59 kronos /bsd: ihidev0: HID command I2C_HID_CMD_SET_POWER(1) May 31 20:12:59 kronos /bsd: ihidev0: ihidev_open: state=0 refcnt=0 May 31 20:12:59 kronos /bsd: ihidev0: resetting May 31 20:12:59 kro
Re: imt(4) Touchpad freezes from time to time
Hi, weekly bump. Anyone (maybe jcs@) has an idea on how to debug this? Cheers and thanks Matthias * Claudio Miranda wrote: > Greetings, > > I'm the person whom Matthias linked to. Seems as though we're having > the same issue with the touchpad in spite of them being different > laptops. I'm using the snapshot from Sunday, 22 May 2022, but previous > snapshots also had this issue. After some time, usually when using > Firefox, but also while using other apps when Firefox isn't being > used, the trackpad will just stop responding for a few seconds, or I > have to tap it to get it to respond after a while. On rare occasions, > it will completely stop working and I have to restart the laptop to > get it working again (logging out and back in of X11 or restarting > xenodm doesn't resolve it). > > Both our trackpads use imt(4). I've provided my dmesg, pcidump, and > usbdevs info below. If you require me to submit this separately, > please let me know and I'll do so. Thanks. > > Claudio Miranda > >
imt(4) Touchpad freezes from time to time
>Synopsis: imt(4) Touchpad stalls from time to time >Environment: System : OpenBSD 7.1 Details : OpenBSD 7.1-current (GENERIC.MP) #533: Thu May 19 07:38:57 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: On my new Laptop [1] the touchpad stalls/hangs from time to time when using X11. I move the pointer and suddenly the mouse pointer is frozen. After some seconds (I observed times from 2-3s up to 10s) the pointer is unfrozen and I can continue as usual. So far, I cannot pin point it to any application, so it seems it's application independent. Other users also have seen this issue [2]. Any hints on how I could debug this further? [1] https://www.tuxedocomputers.com/de/Linux-Hardware/Linux-Notebooks/10-14-Zoll/TUXEDO-InfinityBook-Pro-14-Gen6-US-ANSI-Edition.tuxedo [2] https://bsd.network/@claudiom/108346565493371161 >How-To-Repeat: Use the touchpad on such a machine. >Fix: dmesg: OpenBSD 7.1-current (GENERIC.MP) #533: Thu May 19 07:38:57 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34064420864 (32486MB) avail mem = 33014665216 (31485MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x43ca1000 (119 entries) bios0: vendor American Megatrends International, LLC. version "N.1.15A09" date 03/24/2022 bios0: TUXEDO TUXEDO InfinityBook Pro 14 Gen6 acpi0 at bios0: ACPI 6.2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP MCFG SSDT FIDT SSDT SSDT SSDT HPET APIC SSDT SSDT NHLT UEFI LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT SSDT BGRT PTDT WSMT FPDT acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xc000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4788.96 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line disabled 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 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4788.96 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line disabled L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.11 MHz, 06-8c-01 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 256KB 64b/line disabled L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.11 MHz, 06-8c-01 cpu3:
uvm_fault on resume: SPL not lowered on syscall
>Synopsis: uvm_fault on resume SPL not lowered on syscall >Environment: System : OpenBSD 7.1 Details : OpenBSD 7.1-beta (GENERIC.MP) #381: Wed Feb 23 16:19:54 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I was resuming my Thinkpad T450s from sleep when the kernel paniced. The following messages is transcribed by hand, I also can send a photo if needed. uvm_fault(0xfd83590cc780, 0x0, 0, 2) ->e WARNING: SPL NOT LOWERED ON SYSCALL 3 4 EXIT 0 9 Stopped at savectx+0xb1: movl $0, %gs:0x538 TID PID UID PRFLAGS PFLAGS CPU COMMAND 169674 85507 0 0x2 0 3 perl 459614 46233 1000 0x32 0x4000480 2 chrome *210950 18778 74 0x1112 0 0 pflogd 90870 76230 0 0x14000 0x200 1 drmwq savectx() at savectx+0xb1 It's the first time I experiences this panic before. I now have the latest snapshot from 25th running to see if this happens again. Let me know if you need more. Cheers Matthias dmesg: OpenBSD 7.1-beta (GENERIC.MP) #381: Wed Feb 23 16:19:54 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12765257728 (12173MB) avail mem = 12361170944 (11788MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries) bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019 bios0: LENOVO 20BX0049GE acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA 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) i5-5200U CPU @ 2.20GHz, 2095.41 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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
ntpd constraint validation shows timestamp from 1899
>Synopsis: ntpd constraint validation shows timestamp from 1899 >Environment: System : OpenBSD 7.0 Details : OpenBSD 7.0-current (GENERIC.MP) #216: Mon Jan 3 16:04:47 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: Yesterday, the following log message from OpenNTPD appeared for the first and only time in my logs: Jan 4 19:35:04 sigma ntpd[72304]: maximum length exceeded Jan 4 19:35:04 sigma ntpd[72304]: tls certificate not yet valid: 9.9.9.9 (9.9.9.9): not before 2021-07-27 00:00:00 UTC, now 1899-12-31 00:00:00 UTC It seems like some hiccup during constraint TLS certificate validation. Here are the log messages of the last two minutes BEFORE the lines above appeared: Jan 4 19:33:08 sigma ntpd[65131]: peer 134.76.249.201 now invalid Jan 4 19:33:16 sigma ntpd[65131]: peer 141.2.22.74 now invalid Jan 4 19:33:20 sigma ntpd[2066]: adjusting local clock by 0.468916s Jan 4 19:33:20 sigma ntpd[65131]: clock is now unsynced Jan 4 19:34:04 sigma ntpd[65131]: peer 134.76.249.201 now valid Jan 4 19:34:22 sigma ntpd[2066]: adjusting local clock by 0.153686s Jan 4 19:34:26 sigma ntpd[65131]: peer 134.76.249.201 now invalid Jan 4 19:34:54 sigma ntpd[65131]: clock is now synced Jan 4 19:34:54 sigma ntpd[65131]: constraint reply from 82.165.229.152: offset -0.891146 Jan 4 19:35:00 sigma ntpd[65131]: constraint reply from 82.165.229.87: offset -0.776174 The next time 9.9.9.9 appeared in the logs was around 15 minutes later: Jan 4 19:50:43 sigma ntpd[65131]: constraint reply from 2620:fe::fe: offset -0.848819 Jan 4 19:50:43 sigma ntpd[65131]: constraint reply from 9.9.9.9: offset -0.872381 I attached the full ntpd log in case that helps. Here's my ntpd.conf servers time.uni-paderborn.de servers ntp.1und1.de server ntp1.uni-ulm.de server ntp2.uni-ulm.de server ntp.uni-osnabrueck.de server times.tubit.tu-berlin.de constraint from "9.9.9.9" # quad9 v4 without DNS constraint from "2620:fe::fe" # quad9 v6 without DNS constraints from "gmx.de" >How-To-Repeat: Sorry, no idea. Happened for the first time. >Fix: Unknown as well. dmesg: OpenBSD 7.0-current (GENERIC.MP) #216: Mon Jan 3 16:04:47 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12765257728 (12173MB) avail mem = 12362371072 (11789MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries) bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019 bios0: LENOVO 20BX0049GE acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA 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) i5-5200U CPU @ 2.20GHz, 2095.44 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i5-5200U CPU @ 2.20GHz, 2095.15 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i5-5200U CPU @ 2.20GHz, 2095.15 MHz, 06-3d-04 cpu2:
Re: VM panic'ed in _rb_remove
Hi, * Paul de Weerd wrote: > Hi all, > > This morning I found one of my vmm VMs at the ddb> prompt. Mail, logs > and the ps output from ddb all suggest this was during the daily(8) > run of security(8): i did get the daily mail, but not the one from > security (I was expecting one, as the machine was upgraded a few hours > earlier). That's the same panic I see once or twice a year on one of my local machines having a NFS share mounted. I reported it the first time back in 2019 [1]. Sadly, I cannot pin-point it to any concrete action. Cheers Matthias [1] https://marc.info/?l=openbsd-bugs=157652205500810=2
Re: [External] : double fault while using IPSec/iked
Hi, * Alexander Bluhm wrote: > > > Could you try this diff? > > > > I have a kernel running with your diff over the last hours and created > > quite some network traffic and the error didn't appear so far. > > Previously, I was able to create it quite fast. So definitely an > > improvement. > > That's strange. The diff would help only if routing domains are > involved. But you said that you don't have them. > > tobhe@ and I could reproduce the problem on our setup. It looks > like using enc0 as iked interface may trigger it. But the panic > is not clearly reproducable, we don't see the pattern that actually > causes the stack overflow. > > Sometimes it happens when a dynamic PMTU route expires, or when > IPsec traffic begins, or when iked is restarted, or it does not > panic at all. And the PMTU is not always calculated correctly. > > So please continue testing and report configurations that work and > don't work. For the last days I ran a vanilla kernel with iface set to lo1 instead of enc0. The error has not occured so far. Following the documentation is always a good advice ;) Cheers Matthias
Re: [External] : double fault while using IPSec/iked
Hi, * Alexander Bluhm wrote: > On Mon, Jun 21, 2021 at 09:40:06AM +0200, Alexandr Nedvedicky wrote: > > looks like there must be yet another code path, which > > enters the recursion. > > Yes. > > Do you use routing domains in pf? Do you have reject or blackhole > routes? > > Please send: > - netstat -rn > - a description which routes are used for IPsec > - ipsecctl -s flow > - pf rules that affect rdomains or rtable. > > I guess that path MTU discovery does not work in your case. It > recurses over tcp_mtudisc(). > > If it is a reject route, this check in icmp_mtudisc_clone() could > prevent that my fix works. > > /* IPsec needs the route only for PMTU, it can use reject for that */ > if (!ipsec && (rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE))) > goto bad; > > Could you try this diff? I have a kernel running with your diff over the last hours and created quite some network traffic and the error didn't appear so far. Previously, I was able to create it quite fast. So definitely an improvement. Cheers Matthias
Re: [External] : double fault while using IPSec/iked
Hi, * Alexander Bluhm wrote: > On Mon, Jun 21, 2021 at 09:40:06AM +0200, Alexandr Nedvedicky wrote: > > looks like there must be yet another code path, which > > enters the recursion. > > Yes. > > Do you use routing domains in pf? Do you have reject or blackhole > routes? No, not that I am aware of. I use the default pf.conf and made no modifcation. > Please send: > - netstat -rn Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default10.0.5.163 UGS00 - 6 enc0 default172.23.5.1 UGS 10 481 - 8 trunk0 224/4 127.0.0.1 URS00 32768 8 lo0 10.0.5.163 enc0 UHLhl 12 - 1 enc0 10.0.5.163/32 10.0.5.163 UCn00 - 4 enc0 82.165.126.225 172.23.5.1 UGHS 00 - 6 trunk0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 2 1184 32768 1 lo0 172.23.5/24172.23.5.36UCn1 413 - 4 trunk0 172.23.5.1 cc:ce:1e:8b:cf:cf UHLch 2 1024 - 3 trunk0 172.23.5.3650:7b:9d:73:aa:8a UHLl 0 486 - 1 trunk0 172.23.5.255 172.23.5.36UHb00 - 1 trunk0 Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultfd5b:24b3:ff78:23::5d0:7466UGS0 0 - 6 enc0 defaultfe80::cece:1eff:fe8b:cfcf%trunk0 UGS 2 114 - 8 trunk0 ::/96 ::1UGRS 0 0 32768 8 lo0 ::1::1UHhl 14 8156 32768 1 lo0 :::0.0.0.0/96 ::1UGRS 0 0 32768 8 lo0 2001:16b8:245e:b00::/642001:16b8:245e:b00:7e06:208a:22a4:3ac5 UCPn 11 - 4 trunk0 2001:16b8:245e:b00::/642001:16b8:245e:b00:e8a5:4adc:6b84:a7ed UCPn 00 - 4 trunk0 2001:16b8:245e:b00:7e06:208a:22a4:3ac5 50:7b:9d:73:aa:8a UHLl 00 - 1 trunk0 2001:16b8:245e:b00:bbbe:4458:681c:493f link#5 UHLc 0 67 - 3 trunk0 2001:16b8:245e:b00:e8a5:4adc:6b84:a7ed 50:7b:9d:73:aa:8a UHLl 07 - 1 trunk0 2002::/24 ::1UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1UGRS 0 0 32768 8 lo0 fd00:23:42:5::/64 fd00:23:42:5:c019:d20a:d1e:a33f UCPn 1 1 - 4 trunk0 fd00:23:42:5::/64 fd00:23:42:5:c0e8:a8d9:b26c:d589 UCPn 00 - 4 trunk0 fd00:23:42:5:c019:d20a:d1e:a33f50:7b:9d:73:aa:8a UHLl 0 68 - 1 trunk0 fd00:23:42:5:c0e8:a8d9:b26c:d589 50:7b:9d:73:aa:8a UHLl 0 7 - 1 trunk0 fd00:23:42:5:cece:1eff:fe8b:cfcf cc:ce:1e:8b:cf:cf UHLc 1 609 - 3 trunk0 fd5b:24b3:ff78:23::5d0:7466enc0 UHLhl 1 2 - 1 enc0 fe80::/10 ::1UGRS 0 2 32768 8 lo0 fec0::/10 ::1UGRS 0 0 32768 8 lo0 fe80::1%lo0fe80::1%lo0UHl0 0 32768 1 lo0 fe80::%trunk0/64 fe80::527b:9dff:fe73:aa8a%trunk0 UCn 12 - 4 trunk0 fe80::527b:9dff:fe73:aa8a%trunk0 50:7b:9d:73:aa:8a UHLl 0 320 - 1 trunk0 fe80::cece:1eff:fe8b:cfcf%trunk0 cc:ce:1e:8b:cf:cf UHLch 1 1046 - 3 trunk0 ff01::/16 ::1UGRS 2 4 32768 8 lo0 ff01::%lo0/32 fe80::1%lo0Um 0 1 32768 4 lo0 ff01::%trunk0/32 fe80::527b:9dff:fe73:aa8a%trunk0 Um 04 - 4 trunk0 ff02::/16 ::1UGRS 2 4 32768 8 lo0 ff02::%lo0/32 fe80::1%lo0Um 0 1 32768 4 lo0 ff02::%trunk0/32
Re: double fault while using IPSec/iked
Hi Vitaliy, * Vitaliy Makkoveev wrote: > Hi, > > Have you tried this setup with previous snapshots? Which date they were? No, I haven't. This was not a planned setup, I just did it out of curiosity since I recognized a lot of IPSec changes in the tree over the last year and want to give it a try. If it helps, I can download an older bsd.mp from ftp.hostserver.de and test the setup with it... In case it helps, the server (responders) runs OpenBSD 6.9-current (GENERIC) #75: Sat Jun 19 06:54:01 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Cheers Matthias
double fault while using IPSec/iked
>Synopsis: double fault while using IPSec >Environment: System : OpenBSD 6.9 Details : OpenBSD 6.9-current (GENERIC.MP) #82: Sat Jun 19 07:05:12 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I had successfully set up a ipsec/iked roadwarrior setup and while browsing the web over the tunnel the following error occurred. I transcribed the message by hand: kernel: double fault trap, code=0 Stopped at m_copydata+0x17:pushq %r14 m_copydata(fd807cfbb100,14,14,800022e5d1d4) at m_copydata+0x17 pf_pull_hdr(fd807cfbb100,14,800022e5d1d4,14,0,800022e5d22e) at pf_pull_hdr+0xa9 pf_setup_pdsec(800022e5d130,2,2,806bd600,fd807cfbb100,800022e5d22e) at pf_setup_pdesc+0x213 pf_test(2,2,8018800,800022e5d320) qt pf_test+0x172 ip_output(fd807cfbb100,0,fd8259008d80,800,0,fd8259008d10) ad ip_out0ut+0x7b6 tcp_output(813ab000) at tcp_output+0x1a10 tcp_output(813ab000) at tcp_nutput+0x1a10 tcp_output(813ab000) at tcp_output+0x1a10 tcp_output(813ab000) at tcp_output+0x1a10 tcp_output(fDff813ab000) at tcp_output+0x1a10 tcp_output(813ab000) at tcp_output+0x1a10 [...] The iked.conf on the server side looks as follows: ikev2 'vpn' passive esp \ from any to dynamic \ config address 10.0.5.0/24 \ tag "ROADW" The iked.conf on the roadwarrior looks as follows: ikev2 'roadwarrior' active esp \ from dynamic to any \ peer XX.XX.XX.XX \ srcid client.example.com \ dstid server.example.com \ request address any \ iface enc0 I had iked running in the foreground with -dv. Cheers Matthias dmesg: OpenBSD 6.9-current (GENERIC.MP) #82: Sat Jun 19 07:05:12 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12765265920 (12173MB) avail mem = 12362915840 (11790MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries) bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019 bios0: LENOVO 20BX0049GE acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA 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) i5-5200U CPU @ 2.20GHz, 2095.46 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i5-5200U CPU @ 2.20GHz, 2095.17 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i5-5200U CPU @ 2.20GHz, 2095.17 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i5-5200U CPU @ 2.20GHz, 2095.17 MHz, 06-3d-04 cpu3:
Re: iwm: Fatal firmware error (could not add sta (error 35))
Hi Stefan, * Stefan Sperling wrote: > On Fri, May 14, 2021 at 02:39:15PM +0200, Matthias Schmidt wrote: > > I am now running > > > > OpenBSD 6.9-current (GENERIC.MP) #17: Wed May 12 11:14:50 MDT 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > which contains your described fix. Since then I occasionally see a new > > firmare error I haven't seen before. Most of the time the interface > > recovers but sometimes I have to bring it down and up again. > > This looks like your AP is disappearing for some reason. > The AP may be switching channels or you may have moved out of range. > And the driver doesn't handle the resulting state transitions correctly. > > Thanks for reporting this! I will look into it. Switching channels might be, I doubt moving out of range since I do all work from the same desk all day and almost never carry the laptops around. FWIW I also see the same error on a Thinkpad X250 with an iwm 7256. I can even maneuver the system into a state where I cannot recover the WiFi. I ran "doas ifconfig iwm0 mode 11a" since my AP supports 11a and I wanted to give it a try. That triggered the firmware error basically in a loop. A reboot was the only method to get the Wifi working again. Cheers Matthias
Re: iwm: Fatal firmware error (could not add sta (error 35))
Hi Stefan, * Stefan Sperling wrote: > On Tue, May 11, 2021 at 11:44:17AM +0200, Stefan Sperling wrote: > > Can you please run with this and let me know if it changes anything? > > I have finally managed to reproduce the problem locally by playing around > with forced background scans and roaming. This patch is a superset of the > previous patch. It should fix the 'add sta' problem and also fixes a couple > of small bugs I found along the way. I am now running OpenBSD 6.9-current (GENERIC.MP) #17: Wed May 12 11:14:50 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP which contains your described fix. Since then I occasionally see a new firmare error I haven't seen before. Most of the time the interface recovers but sometimes I have to bring it down and up again. Cheers Matthias May 14 13:59:59 sigma /bsd: iwm0: received msg 1/2 of the group key handshake from cc:ce:1e:8b:cf:d1 May 14 13:59:59 sigma /bsd: iwm0: sending msg 2/2 of the group key handshake to cc:ce:1e:8b:cf:d1 May 14 14:01:20 sigma /bsd: iwm0: RUN -> ASSOC May 14 14:01:20 sigma /bsd: iwm0: sending action to cc:ce:1e:8b:cf:d1 on channel 100 mode 11n May 14 14:01:20 sigma /bsd: iwm0: sending assoc_req to cc:ce:1e:8b:cf:d1 on channel 100 mode 11n May 14 14:01:24 sigma /bsd: iwm0: association timed out for cc:ce:1e:8b:cf:d1 May 14 14:01:24 sigma /bsd: iwm0: dumping device error log May 14 14:01:24 sigma /bsd: iwm0: Start Error Log Dump: May 14 14:01:24 sigma /bsd: iwm0: Status: 0x9, count: 6 May 14 14:01:24 sigma /bsd: iwm0: 0x3421 | ADVANCED_SYSASSERT May 14 14:01:24 sigma /bsd: iwm0: 0220 | trm_hw_status0 May 14 14:01:24 sigma /bsd: iwm0: | trm_hw_status1 May 14 14:01:24 sigma /bsd: iwm0: 00023FDC | branchlink2 May 14 14:01:24 sigma /bsd: iwm0: 0003915A | interruptlink1 May 14 14:01:24 sigma /bsd: iwm0: | interruptlink2 May 14 14:01:24 sigma /bsd: iwm0: | data1 May 14 14:01:24 sigma /bsd: iwm0: 0001 | data2 May 14 14:01:24 sigma /bsd: iwm0: DEADBEEF | data3 May 14 14:01:24 sigma /bsd: iwm0: | beacon time May 14 14:01:24 sigma /bsd: iwm0: E8F0FA81 | tsf low May 14 14:01:24 sigma /bsd: iwm0: 0024 | tsf hi May 14 14:01:24 sigma /bsd: iwm0: | time gp1 May 14 14:01:24 sigma /bsd: iwm0: 20010BB2 | time gp2 May 14 14:01:24 sigma /bsd: iwm0: 0001 | uCode revision type May 14 14:01:24 sigma /bsd: iwm0: 0022 | uCode version major May 14 14:01:24 sigma /bsd: iwm0: | uCode version minor May 14 14:01:24 sigma /bsd: iwm0: 0230 | hw version May 14 14:01:24 sigma /bsd: iwm0: 18089000 | board version May 14 14:01:24 sigma /bsd: iwm0: 007C0028 | hcmd May 14 14:01:24 sigma /bsd: iwm0: 24022082 | isr0 May 14 14:01:24 sigma /bsd: iwm0: 0100 | isr1 May 14 14:01:24 sigma /bsd: iwm0: 08201802 | isr2 May 14 14:01:24 sigma /bsd: iwm0: 004140C0 | isr3 May 14 14:01:24 sigma /bsd: iwm0: | isr4 May 14 14:01:24 sigma /bsd: iwm0: 007B002B | last cmd Id May 14 14:01:24 sigma /bsd: iwm0: | wait_event May 14 14:01:24 sigma /bsd: iwm0: 0080 | l2p_control May 14 14:01:24 sigma /bsd: iwm0: 00018010 | l2p_duration May 14 14:01:24 sigma /bsd: iwm0: 003F | l2p_mhvalid May 14 14:01:24 sigma /bsd: iwm0: | l2p_addr_match May 14 14:01:24 sigma /bsd: iwm0: 000D | lmpm_pmg_sel May 14 14:01:24 sigma /bsd: iwm0: 30101345 | timestamp May 14 14:01:24 sigma /bsd: iwm0: A8B8 | flow_handler May 14 14:01:24 sigma /bsd: iwm0: Start UMAC Error Log Dump: May 14 14:01:24 sigma /bsd: iwm0: Status: 0x9, count: 7 May 14 14:01:24 sigma /bsd: iwm0: 0x0070 | NMI_INTERRUPT_LMAC_FATAL May 14 14:01:24 sigma /bsd: iwm0: 0x | umac branchlink1 May 14 14:01:24 sigma /bsd: iwm0: 0xC0086964 | umac branchlink2 May 14 14:01:24 sigma /bsd: iwm0: 0xC0083A94 | umac interruptlink1 May 14 14:01:24 sigma /bsd: iwm0: 0xC0083A94 | umac interruptlink2 May 14 14:01:24 sigma /bsd: iwm0: 0x0800 | umac data1 May 14 14:01:24 sigma /bsd: iwm0: 0xC0083A94 | umac data2 May 14 14:01:24 sigma /bsd: iwm0: 0xDEADBEEF | umac data3 May 14 14:01:24 sigma /bsd: iwm0: 0x0022 | umac major May 14 14:01:24 sigma /bsd: iwm0: 0x | umac minor May 14 14:01:24 sigma /bsd: iwm0: 0xC088628C | frame pointer May 14 14:01:24 sigma /bsd: iwm0: 0xC088628C | stack pointer May 14 14:01:24 sigma /bsd: iwm0: 0x007C0028 | last host cmd May 14 14:01:24 sigma /bsd: iwm0: 0x | isr status reg May 14 14:01:24 sigma /bsd: driver status: May 14 14:01:24 sigma /bsd: tx ring 0: qid=0 cur=125 queued=1 May 14 14:01:24 sigma /bsd: tx ring 1: qid=1 cur=0 queued=0 May 14 14:01:24 sigma /bsd: tx ring 2: qid=2 cur=0 queued=0 May 14 14:01:24 sigma /bsd: tx ring 3: qid=3 cur=0 queued=0 May 14 14:01:24 sigma /bsd: tx ring 4: qid=4 cur=0 queued=0 May 14 14:01:24 sigma /bsd: tx ring 5: qid=5 cur=119 queued=2 May 14 14:01:24 sigma /bsd: tx ring 6: qid=6 cur=0 queued=0 May 14 14:01:24 sigma /bsd: tx ring 7:
Re: iwm: Fatal firmware error (could not add sta (error 35))
Hi Stefan, * Stefan Sperling wrote: > > Given that this problem doesn't occur very frequently, my best guess is that > the firmware is unhappy about us simply removing outstanding frames from Tx > queues when we are stopping a Tx block ack session. This 'add sta' error, > which happens during a re-association attempt, could be side effect of that. > One of your firmware errors occured after a Tx command (host command 0x1c) > which is probably closer to the origin of the actual problem. > > The Linux driver sends a special command to the firmware before stopping a BA > session in order to flush Tx queues. We should probably be doing this, too. > They way I've implemented it here blocks all Tx queues when a Tx BA session > is stopped. Given how the firmware commands seem to work I am not sure how > this could be optimized to happen per-queue instead. This means you could see > brief but harmless drops in throughput during tcpbench measurements when a > Tx BA session is torn down at the request of the AP. If that is too annoying > I can try to implement per-queue flushing but otherwise the extra code > complexity this implies will simply not be worth it. > > This patch also implements an automatic device reset in case we run into > problems during BA session setup or teardown. You should no longer need > to down/up the interface manually to get things going again. > > Could you run with this patch for a while please and let me know if it > causes new problems or makes any difference regarding the known firmware > errors? I had the Laptop running over the weekend and generated a lot of network traffic. As you can see from the logs below, the error occurred again, however, in a much lower frequency. Also the device recovered itself so it was hardly noticeable. Let me know if there is more to test... Cheers Matthias 2021-05-08T07:47:05.098Z sigma /bsd: iwm0: dumping device error log 2021-05-08T07:47:05.098Z sigma /bsd: iwm0: Start Error Log Dump: 2021-05-08T07:47:05.099Z sigma /bsd: iwm0: Status: 0x19, count: 6 2021-05-08T07:47:05.099Z sigma /bsd: iwm0: 0x21A0 | ADVANCED_SYSASSERT 2021-05-08T07:47:05.100Z sigma /bsd: iwm0: 0220 | trm_hw_status0 2021-05-08T07:47:05.152Z sigma /bsd: iwm0: | trm_hw_status1 2021-05-08T07:47:05.152Z sigma /bsd: iwm0: 00023FDC | branchlink2 2021-05-08T07:47:05.158Z sigma /bsd: iwm0: 0003915A | interruptlink1 2021-05-08T07:47:05.158Z sigma /bsd: iwm0: | interruptlink2 2021-05-08T07:47:05.159Z sigma /bsd: iwm0: 01E0 | data1 2021-05-08T07:47:05.163Z sigma /bsd: iwm0: 05E0 | data2 2021-05-08T07:47:05.164Z sigma /bsd: iwm0: | data3 2021-05-08T07:47:05.177Z sigma /bsd: iwm0: F9C1717D | beacon time 2021-05-08T07:47:05.178Z sigma /bsd: iwm0: 75A06FCF | tsf low 2021-05-08T07:47:05.178Z sigma /bsd: iwm0: 0003 | tsf hi 2021-05-08T07:47:05.179Z sigma /bsd: iwm0: | time gp1 2021-05-08T07:47:05.179Z sigma /bsd: iwm0: 7D5D5F60 | time gp2 2021-05-08T07:47:05.180Z sigma /bsd: iwm0: 0001 | uCode revision type 2021-05-08T07:47:05.180Z sigma /bsd: iwm0: 0022 | uCode version major 2021-05-08T07:47:05.192Z sigma /bsd: iwm0: | uCode version minor 2021-05-08T07:47:05.193Z sigma /bsd: iwm0: 0230 | hw version 2021-05-08T07:47:05.193Z sigma /bsd: iwm0: 18089000 | board version 2021-05-08T07:47:05.194Z sigma /bsd: iwm0: 000D0018 | hcmd 2021-05-08T07:47:05.194Z sigma /bsd: iwm0: 24022080 | isr0 2021-05-08T07:47:05.207Z sigma /bsd: iwm0: | isr1 2021-05-08T07:47:05.207Z sigma /bsd: iwm0: 08201802 | isr2 2021-05-08T07:47:05.208Z sigma /bsd: iwm0: 004140C0 | isr3 2021-05-08T07:47:05.208Z sigma /bsd: iwm0: | isr4 2021-05-08T07:47:05.219Z sigma /bsd: iwm0: 000C0019 | last cmd Id 2021-05-08T07:47:05.219Z sigma /bsd: iwm0: | wait_event 2021-05-08T07:47:05.220Z sigma /bsd: iwm0: 00D4 | l2p_control 2021-05-08T07:47:05.220Z sigma /bsd: iwm0: 00018030 | l2p_duration 2021-05-08T07:47:05.221Z sigma /bsd: iwm0: 0007 | l2p_mhvalid 2021-05-08T07:47:05.234Z sigma /bsd: iwm0: 0081 | l2p_addr_match 2021-05-08T07:47:05.234Z sigma /bsd: iwm0: 000D | lmpm_pmg_sel 2021-05-08T07:47:05.235Z sigma /bsd: iwm0: 30101345 | timestamp 2021-05-08T07:47:05.236Z sigma /bsd: iwm0: C8D0 | flow_handler 2021-05-08T07:47:05.236Z sigma /bsd: iwm0: Start UMAC Error Log Dump: 2021-05-08T07:47:05.248Z sigma /bsd: iwm0: Status: 0x19, count: 7 2021-05-08T07:47:05.249Z sigma /bsd: iwm0: 0x0070 | NMI_INTERRUPT_LMAC_FATAL 2021-05-08T07:47:05.250Z sigma /bsd: iwm0: 0x | umac branchlink1 2021-05-08T07:47:05.250Z sigma /bsd: iwm0: 0xC0086964 | umac branchlink2 2021-05-08T07:47:05.251Z sigma /bsd: iwm0: 0xC0083A94 | umac interruptlink1 2021-05-08T07:47:05.251Z sigma /bsd: iwm0: 0xC0083A94 | umac interruptlink2 2021-05-08T07:47:05.263Z sigma /bsd: iwm0: 0x0800 | umac data1 2021-05-08T07:47:05.266Z sigma /bsd: iwm0: 0xC0083A94 | umac data2 2021-05-08T07:47:05.277Z sigma /bsd: iwm0: 0xDEADBEEF |
Re: iwm: Fatal firmware error (could not add sta (error 35))
Hi Stefan, * Stefan Sperling wrote: > > This patch also implements an automatic device reset in case we run into > problems during BA session setup or teardown. You should no longer need > to down/up the interface manually to get things going again. > > Could you run with this patch for a while please and let me know if it > causes new problems or makes any difference regarding the known firmware > errors? Sure, will do. Compile is in progress and I'll test over the weekend! Cheers Matthias
iwm: Fatal firmware error (could not add sta (error 35))
>Synopsis: Fatal firmware error with iwm >Environment: System : OpenBSD 6.9 Details : OpenBSD 6.9-current (GENERIC.MP) #4: Wed May 5 11:06:38 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I noticed an iwm "fatal firmware error" I've never seen before. This happened since some days and I assume it is related to the recent Wifi changes that so awesomely speed up the Wifi. The error usually appears multiple times and sometimes the wifi recovers, sometimes I have to take the interface down and up again for recovery. Here's an excerpt from my messages: 2021-05-03T15:41:07.069Z sigma /bsd: iwm0: fatal firmware error 2021-05-03T15:41:08.069Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-03T17:25:05.355Z sigma /bsd: iwm0: fatal firmware error 2021-05-03T17:25:06.405Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-03T17:25:23.905Z sigma /bsd: iwm0: fatal firmware error 2021-05-03T17:25:24.905Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-03T17:25:43.655Z sigma /bsd: iwm0: fatal firmware error 2021-05-03T17:25:44.655Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-03T17:49:02.712Z sigma /bsd: iwm0: fatal firmware error 2021-05-03T17:49:28.858Z sigma /bsd: iwm0: fatal firmware error 2021-05-03T17:49:29.852Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-04T07:21:41.018Z sigma /bsd: iwm0: fatal firmware error 2021-05-04T07:21:42.018Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-04T07:41:50.175Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-04T07:45:28.374Z sigma /bsd: iwm0: fatal firmware error 2021-05-04T07:45:29.424Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-04T08:58:25.572Z sigma /bsd: iwm0: fatal firmware error 2021-05-04T08:58:26.572Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-04T09:02:04.491Z sigma /bsd: iwm0: fatal firmware error 2021-05-04T09:02:05.491Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-04T09:22:39.061Z sigma /bsd: iwm0: fatal firmware error 2021-05-04T09:22:40.061Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-04T09:31:18.270Z sigma /bsd: iwm0: fatal firmware error 2021-05-04T10:01:42.366Z sigma /bsd: iwm0: fatal firmware error 2021-05-04T10:01:43.366Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-05T12:27:16.883Z sigma /bsd: iwm0: fatal firmware error 2021-05-05T12:27:17.893Z sigma /bsd: iwm0: failed to update MAC 2021-05-05T12:28:56.195Z sigma /bsd: iwm0: fatal firmware error 2021-05-05T12:28:57.195Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-05T17:08:30.547Z sigma /bsd: iwm0: fatal firmware error 2021-05-05T17:08:31.597Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-05T19:47:36.736Z sigma /bsd: iwm0: fatal firmware error 2021-05-05T19:47:37.731Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-05T19:47:52.666Z sigma /bsd: iwm0: fatal firmware error 2021-05-05T19:47:53.661Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-05T19:48:08.636Z sigma /bsd: iwm0: fatal firmware error 2021-05-05T19:48:09.631Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-05T19:48:27.243Z sigma /bsd: iwm0: fatal firmware error 2021-05-05T20:21:20.768Z sigma /bsd: iwm0: fatal firmware error 2021-05-05T20:21:21.818Z sigma /bsd: iwm0: could not add sta (error 35) 2021-05-06T06:53:21.933Z sigma /bsd: iwm0: dumping device error log 2021-05-06T06:53:21.934Z sigma /bsd: iwm0: Start Error Log Dump: 2021-05-06T06:53:21.934Z sigma /bsd: iwm0: Status: 0x39, count: 6 2021-05-06T06:53:21.934Z sigma /bsd: iwm0: 0x1043 | ADVANCED_SYSASSERT 2021-05-06T06:53:21.934Z sigma /bsd: iwm0: 00A00283 | trm_hw_status0 2021-05-06T06:53:21.935Z sigma /bsd: iwm0: | trm_hw_status1 2021-05-06T06:53:21.935Z sigma /bsd: iwm0: 00023FDC | branchlink2 2021-05-06T06:53:21.935Z sigma /bsd: iwm0: 0003915A | interruptlink1 2021-05-06T06:53:21.935Z sigma /bsd: iwm0: | interruptlink2 2021-05-06T06:53:21.936Z sigma /bsd: iwm0: 27C4 | data1 2021-05-06T06:53:21.936Z sigma /bsd: iwm0: 2818 | data2 2021-05-06T06:53:21.936Z sigma /bsd: iwm0: DEADBEEF | data3 2021-05-06T06:53:21.936Z sigma /bsd: iwm0: 8440C4DD | beacon time 2021-05-06T06:53:21.937Z sigma /bsd: iwm0: 86CDBB2A | tsf low 2021-05-06T06:53:21.937Z sigma /bsd: iwm0: 06F6 | tsf hi 2021-05-06T06:53:21.937Z sigma /bsd: iwm0: 036F | time gp1 2021-05-06T06:53:21.937Z sigma /bsd: iwm0: 1082349D | time gp2 2021-05-06T06:53:21.938Z sigma /bsd: iwm0: 0001 | uCode revision type 2021-05-06T06:53:21.938Z sigma /bsd: iwm0: 0022 | uCode version major 2021-05-06T06:53:21.938Z sigma /bsd: iwm0: | uCode version minor 2021-05-06T06:53:21.938Z sigma /bsd: iwm0: 0230 | hw version 2021-05-06T06:53:21.939Z sigma /bsd: iwm0: 18089000 | board version 2021-05-06T06:53:21.939Z sigma /bsd: iwm0: 0524001C | hcmd 2021-05-06T06:53:21.939Z
Re: mpv: segmentation fault on exit
Hi, * Klemens Nanni wrote: > On Sat, Sep 05, 2020 at 07:18:00AM +0200, Klemens Nanni wrote: > > Audio output makes no difference but video output is the culprit: all > > work except "gpu", i.e. "xv", "sdl", "x11" and "tct" quit fine without > > segmentation fault. > FWIW, still happens with the latest snap that should contain the recent > mesa update: > > OpenBSD 6.8-beta (GENERIC.MP) #59: Fri Sep 4 22:46:14 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP FWIW, I can confirm the behaviour on a Thinkpad T450s running OpenBSD 6.8-beta (GENERIC.MP) #64: Sun Sep 6 18:19:41 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Cheers Matthias
Re: uvm_fault panic at drm_mode_rmfb_work_dn
Hi Jonathan, * Jonathan Gray wrote: > > You are using a snapshot just before the drm tree was replaced by a new > port of drm from linux 5.7. Can you reproduce this with a newer > snapshot? So far not. I am now running OpenBSD 6.7-current (GENERIC.MP) #254: Mon Jun 8 18:47:16 MDT 2020 and everything seems stable so far. Will run some more tests tomorrow and only report back if I have another panic. Cheers and thanks for all your work! Matthias
Re: uvm_fault panic at drm_mode_rmfb_work_dn
Hi, * Matthias Schmidt wrote: > Hi, > > I run > > OpenBSD 6.7-current (GENERIC.MP) #250: Sun Jun 7 19:48:27 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > on my Thinkpad T450s. While watching a movie mounted on a NFS share the > kernel paniced with the following message (transcribed by hand). The > movie was played with mpv in full-screen. The panic is reproducible with mpv and watching a video in full-screen. If you want to reproduce without hassle, install mpv and youtube-dl from ports and use the latter to download https://vimeo.com/427096874 (a totally random video I picked because its CC licensed). Play it, seek a bit around and the kernel will panic. Cheers Matthias
uvm_fault panic at drm_mode_rmfb_work_dn
Hi,
I run
OpenBSD 6.7-current (GENERIC.MP) #250: Sun Jun 7 19:48:27 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
on my Thinkpad T450s. While watching a movie mounted on a NFS share the
kernel paniced with the following message (transcribed by hand). The
movie was played with mpv in full-screen.
kernel: page fault trap, code=0
Stopped at drm_mode_rmfb_work_fn+0x18: movq0x30(%rdi),%rax
ddb{1}> bt
drm_mode_rmfb_work_fn(c00464af) at drm_mode_rmfb_work_fn+0x18
taskq_thread(8013b280) at taskq_thread+0x8d
end trace frame: 0x0, count: -2
I took a lot of photos showing the panic, registers, ps etc and uploaded
them to https://xosc.org/misc/panic/ There is also a file called dmesg
with the "leftovers" of the dmesg buffer.
If there is anything I should test, please let me know.
Cheers
Matthias
OpenBSD 6.7-current (GENERIC.MP) #250: Sun Jun 7 19:48:27 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12765265920 (12173MB)
avail mem = 12365598720 (11792MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries)
bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019
bios0: LENOVO 20BX0049GE
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT
SSDT SSDT SSDT SSDT PCCT SSDT TCPA 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) i5-5200U CPU @ 2.20GHz, 2095.48 MHz, 06-3d-04
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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
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 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04
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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: 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
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
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
0x40 - 0xff
extent `acpipci0 pciio' (0x0 - 0x), flags=0
0xcf8 - 0xcff
0x1 - 0x
extent `acpipci0 pcimem' (0x0 - 0x), flags=0
0x0 - 0x9
0xc - 0x9fff
0xfec0 - 0xfed3
0xfed4c000 - 0x
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "45N" serial 16646 type LiP oem "SONY"
acpibat1 at acpi0: BAT1 model "45N1777" serial 410 type LION oem "SANYO"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0: version 1.0
tpm0 at acpi0 TPM_ addr 0xfed4/0x5000, device 0x104a rev 0x4e
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT340F" at acpi0 not configured
acpivideo0 at acpi0: VID_
acpivout0 at acpivideo0: LCD0
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2201, 2200, 2100, 2000, 1800, 1700,
1600, 1500, 1300, 1200, 1100, 1000, 900, 700, 600, 500 MHz
pci0 at
uvm_fault Panic on recent -current
Hi, My Thinkpad T450s paniced with uvm_fault while fetching a large git repository to /usr/src. I had a read-only NFS share mounted during the git pull and copied a file over to my local disk in the background. The panic trace transcribed by hand. I can provide a photo upon request: uvm_fault () kernel: page fault trap, code=0 Stopped at _rb_remove+0x1eb:movq %r13,0(%rsi) _rb_remove() at _rb_remove+0x1eb nfs_reclaim() at nfs_reclaim+0x7e VOP_RECLAIM() at VOB_RECLAIM+0x46 vclean() at vclean+0xda vgonel() at vgonel+0x3c getnewvnode() at getnewvnode+0x208 ffs_vget() at ffs_vget+0x88 ufs_lookup() at ufs_lookup+0xc5c VOP_LOOKUP() at VOP_LOOKUP+0x... vfs_lookup() at vfs_lookup+0x3d2 namei() at namei+0x3a5 dofstatat() at dofstatat+0x... syscall() at syscall+0x389 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x20b7a046a20: count: -14 The disk/mount looks as follows: /dev/sd1a on / type ffs (local) /dev/sd1l on /home type ffs (local, noatime, nodev, nosuid, with quotas, softdep) /dev/sd1d on /tmp type ffs (local, noatime, nodev, nosuid) /dev/sd1f on /usr type ffs (local, nodev) /dev/sd1g on /usr/X11R6 type ffs (local, nodev) /dev/sd1h on /usr/local type ffs (local, nodev, wxallowed) /dev/sd1j on /usr/obj type ffs (asynchronous, local, noatime, nodev, nosuid) /dev/sd1k on /usr/ports type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd1i on /usr/src type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd1e on /var type ffs (local, nodev, nosuid) nas:/d on /mnt type nfs (noatime, read-only, v3, tcp, soft, intr, wsize=32768, rsize=32768, rdirsize=32768, timeo=100, readahead=4) Let me know if you need more details or if I should test something. Cheers Matthias OpenBSD 6.6-current (GENERIC.MP) #531: Sun Dec 15 02:17:57 MST 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12573335552 (11990MB) avail mem = 12179873792 (11615MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries) bios0: vendor LENOVO version "JBET73WW (1.37 )" date 08/14/2019 bios0: LENOVO 20BX0049GE acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA 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) i5-5200U CPU @ 2.20GHz, 2095.41 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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 2 (application processor) cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz, 06-3d-04 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,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,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 acpimcfg0: 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 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 acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "45N" serial 16646 type LiP oem "SONY" acpibat1 at acpi0: BAT1 model "45N1777" serial 410 type LION oem "SANYO" acpiac0 at acpi0: AC unit online
Re: signify error when installing ports on -current
Hi, * Marc Espie wrote: > On Sun, May 19, 2019 at 06:25:03PM +0200, Matthias Schmidt wrote: > > Hi, > > > > today I wanted to upgrade my local ports because of the recent libc > > bump. Turns out the ports build system cannot install packages any > > longer and fails with a signify error. I only upgrade the two ports > > I use whevener there is a library version bump, so it definitely worked > > at that time (IIRC it was libssl or so). > > You're not passing the env variable TRUSTED_PKG_PATH through doas. Thanks a lot, that solved my problem! Has this been changed in the last month or why am I hitting this issue now? I never recall fiddling around with the variable... Cheers Matthias
signify error when installing ports on -current
Hi, today I wanted to upgrade my local ports because of the recent libc bump. Turns out the ports build system cannot install packages any longer and fails with a signify error. I only upgrade the two ports I use whevener there is a library version bump, so it definitely worked at that time (IIRC it was libssl or so). Here is the error. I cleaned /usr/ports/packages, however, no changes. $ cd /usr/ports/sysutils/tarsnap $ doas make install `/usr/ports/pobj/tarsnap-1.0.39/fake-amd64/.fake_done' is up to date. ===> Building package for tarsnap-1.0.39 Create /usr/ports/packages/amd64/all/tarsnap-1.0.39.tgz Creating package tarsnap-1.0.39 ===> Installing tarsnap-1.0.39 from /usr/ports/packages/amd64/all/ quirks-3.153 signed on 2019-05-17T15:16:11Z file:/usr/ports/packages/amd64/all/tarsnap-1.0.39.tgz: unsigned package (signify(1) doesn't see old-style signatures) Can't find /usr/ports/packages/amd64/all/tarsnap-1.0.39.tgz Couldn't install tarsnap-1.0.39 *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2043 '/var/db/pkg/tarsnap-1.0.39/+CONTENTS': @/usr/bin/env -i PKG_TMPDIR=/var/tmp...) *** Error 1 in /usr/ports/sysutils/tarsnap (/usr/ports/infrastructure/mk/bsd.port.mk:2466 'install') Completely different port I never used before: $ cd /usr/ports/sysutils/safecat $ make [...] $ doas make install ===> Faking installation for safecat-1.13p0 /usr/ports/pobj/safecat-1.13/bin/install -c -s -m 755 /usr/ports/pobj/safecat-1.13/safecat-1.13/safecat /usr/ports/pobj/safecat-1.13/fake-amd64/usr/local/bin/safecat /usr/ports/pobj/safecat-1.13/bin/install -c -m 755 /usr/ports/pobj/safecat-1.13/safecat-1.13/maildir /usr/ports/pobj/safecat-1.13/fake-amd64/usr/local/bin/maildir /usr/ports/pobj/safecat-1.13/bin/install -c -m 644 /usr/ports/pobj/safecat-1.13/safecat-1.13/safecat.1 /usr/ports/pobj/safecat-1.13/fake-amd64/usr/local/man/man1/ /usr/ports/pobj/safecat-1.13/bin/install -c -m 644 /usr/ports/pobj/safecat-1.13/safecat-1.13/maildir.1 /usr/ports/pobj/safecat-1.13/fake-amd64/usr/local/man/man1/ ===> Building package for safecat-1.13p0 Create /usr/ports/packages/amd64/all/safecat-1.13p0.tgz Creating package safecat-1.13p0 Link to /usr/ports/packages/amd64/ftp/safecat-1.13p0.tgz ===> Verifying specs: c ===> found c.95.1 ===> Installing safecat-1.13p0 from /usr/ports/packages/amd64/all/ quirks-3.153 signed on 2019-05-17T15:16:11Z file:/usr/ports/packages/amd64/all/safecat-1.13p0.tgz: unsigned package (signify(1) doesn't see old-style signatures) Can't find /usr/ports/packages/amd64/all/safecat-1.13p0.tgz Couldn't install safecat-1.13p0 *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2043 '/var/db/pkg/safecat-1.13p0/+CONTENTS': @/usr/bin/env -i PKG_TMPDIR=/var/tmp...) *** Error 1 in /usr/ports/sysutils/safecat (/usr/ports/infrastructure/mk/bsd.port.mk:2466 'install') I run -current from (GENERIC.MP) #18: Mon May 13 19:17:43 MDT 2019 Cheers Matthias
Re: X lock up 2019-04-19 snapshot with Intel graphics
Hi, * Jonathan Gray wrote: > > This should be fixed in the latest snapshot. Thanks. Is fixed for me. Cheers
Re: X lock up 2019-04-19 snapshot with Intel graphics
Hi,
* Jonathan Gray wrote:
>
> There is some kind of use after free or double free that triggers only
> when opting into the 'intel' driver on recent hardware instead of the
> 'modesetting' default.
>
> As you are using xf86-video-intel you are likely hitting that.
> Doesn't trigger on machines I can easily use serial on like x61.
>
> here is a trace provided by sthen@
>
> login: kernel: protection fault trap, code=0
> Stopped at linux_root_RB_NEXT+0x23:movq0(%rcx),%rcx
> ddb{0}> sh reg
> rdi 0x80eb1228
> rsi 0x10
> rbp 0x800022335d70
> rbx 0x80eb1228
> rdx 0xfe0003ff1e32
> rcx 0xdeafbeaddeafbead
> rax 0xdeafbeaddeafbead
> r8 0x7f
> r90x81dce788sched_lock
> r10 0xde411193c377fb0c
> r11 0xdef8fb561704900e
> r12 0x80eb1200
> r13 0x80eb1200
> r14 0x80efe028
> r15 0x80eb1200
> rip 0x814db7c3linux_root_RB_NEXT+0x23
> cs 0x8
> rflags 0x10282__ALIGN_SIZE+0xf282
> rsp 0x800022335d60
> ss 0x10
> linux_root_RB_NEXT+0x23:movq0(%rcx),%rcx
> ddb{0}> ps /o
> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> 482804 44419 350x12 03 Xorg
> 186441 838637320x23 0x4801 mongod
> * 27314 7158 0 0x14000 0x2000K i915
> ddb{0}> tr
> linux_root_RB_NEXT(80eb1228) at linux_root_RB_NEXT+0x23
> i915_vma_destroy(80efe028) at i915_vma_destroy+0x15d
> __i915_gem_free_objects(8011a000,80f009f8) at
> __i915_gem_free_objects+0xc3
> __i915_gem_free_work(8011de90) at __i915_gem_free_work+0x5b
> taskq_thread(801ef300) at taskq_thread+0x4d
> end trace frame: 0x0, count: -5
I was hit by the bug as well on a Thinkpad T450s while I was about to
move my xorg.conf config for the Intel driver away. Interestingly, I
was on ttyC0 and restarting xenodm.
Here is the backtracke (transcript by hand):
linux_root_RB_NEXT() at linux_root_RB_NEXT+0x23
i915_vma_destroy() at i915_vma_destroy+0x15d
i915_ppgtt_release() at i915_oogtt_release+0x7f
i915_gem_context_free() at i915_gem_context_free+0x3e
contexts_free_worker() at contexts_free_worker+0x4d
taskq_thread() at taskq_thread+0x4d
Cheers
Matthias
OpenBSD 6.5-current (GENERIC.MP) #8: Fri Apr 19 21:48:49 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12573335552 (11990MB)
avail mem = 12182183936 (11617MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries)
bios0: vendor LENOVO version "JBET71WW (1.35 )" date 09/14/2018
bios0: LENOVO 20BX0049GE
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT
SSDT SSDT SSDT SSDT PCCT SSDT TCPA 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) i5-5200U CPU @ 2.20GHz, 2095.49 MHz, 06-3d-04
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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
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 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.15 MHz, 06-3d-04
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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
Current snapshot hangs at loader prompt
Hi, I upgraded to the latest snapshot (timestamp is from April 6) and boot stucks at the loader prompt. After upgrading I see the following message (transcript by hand): Using drive 0, partition 3. Loading. probing: pc0 mem[... a20=on] disk: hd0+ Usually, "sr0*" plus the loader info is following. Using the archive from hostserver.de I tried several versions where even the miniroot65.fs USB boot loader stick. The kernel in 2019-04-05-0105 (dmesg below) allowed me to boot the system again. I tried it on two different Thinkpads (t450s, x220) and it happens on both systems. Cheers Matthias OpenBSD 6.5 (GENERIC.MP) #839: Tue Apr 2 20:38:19 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12573335552 (11990MB) avail mem = 12182650880 (11618MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries) bios0: vendor LENOVO version "JBET71WW (1.35 )" date 09/14/2018 bios0: LENOVO 20BX0049GE acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA 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) i5-5200U CPU @ 2.20GHz, 2095.48 MHz, 06-3d-04 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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 2 (application processor) cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.15 MHz, 06-3d-04 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 acpimcfg0: 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 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 acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "45N" serial 16646 type LiP oem "SONY" acpibat1 at acpi0: BAT1 model "45N1777" serial 410 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x104a rev 0x4e "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT340F" at acpi0 not configured acpivideo0 at acpi0: VID_ acpivout at acpivideo0 not configured cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2201, 2200, 2100, 2000, 1800, 1700, 1600, 1500, 1300, 1200, 1100, 1000, 900, 700, 600, 500 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1920x1080, 32bpp error: [drm:pid0:intel_dp_link_training_clock_recovery] *ERROR* too many full retries, give up Unclaimed register detected before reading register 0x64040 wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
Re: cwm with "ignore" option changes window geometry from "-0-0" to "-2-2"
Hi Andre, * Andre Stoebe wrote: > Hi, > > I know this little bug is pretty trivial and more so pedantic, but I > wanted to report it nonetheless and especially ask for confirmation from > other cwm users. It would be great if anyone could try to reproduce. Yes, I can reproduce it here (since I have exactly the same setup as you do). According to xwininfo the clock is 2 pixels off. However, xprop and cwm itself shows an offset of 0 pixels. Cheers Matthias
Booting NetBSD on vmm fails with uvm_fault
Hi, today I wanted to use NetBSD 8.0 on vmm and it fails on boot always at the same point (see dmesg below). I'm dropped from vmctl back to the console and the following messages are shown on the OpenBSD host: 2018-09-22T10:11:04.327Z sigma /bsd: vmx_fault_page: uvm_fault returns 14, GPA=0xfed40014, rip=0x8021f758 2018-09-22T10:11:04.327Z sigma vmd[39939]: vcpu_run_loop: vm 10 / vcpu 0 run ioctl failed: Bad address Originally, I used a disk image (qcow2) from an existing NetBSD qemu installation and added the image to vm.conf. I also tried to boot form a fresh 8.0 and 7.2 amd64 ISO image and this also fails with the same message. Not sure if NetBSD on vmm is even supported... :) Cheers Matthias The dmesg of the booting NetBSD looks as follows: NetBSD 8.0 (GENERIC) #0: Tue Jul 17 14:59:51 UTC 2018 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC total memory = 511 MB avail memory = 473 MB cpu_rng: RDSEED running cgd selftest aes-xts-256 aes-xts-512 done mainbus0 (root) ACPI BIOS Error (bug): A valid RSDP was not found (20170303/tbxfroot-261) acpi_probe: failed to initialize tables ACPI Error: Could not remove SCI handler (20170303/evmisc-312) cpu0 at mainbus0 cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, id 0x306d4 cpu0: package 0, core 0, smt 0 pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0: vendor 0b5d product 0666 (rev. 0x00) virtio0 at pci0 dev 1 function 0 virtio0: Virtio Entropy Device (rev. 0x00) viornd0 at virtio0: Features: 0x0 virtio0: interrupting at irq 3 virtio1 at pci0 dev 2 function 0 virtio1: Virtio Block Device (rev. 0x00) ld0 at virtio1: Features: 0x2 ld0: Clip SEG_MAX from 1024K to 64K virtio1: interrupting at irq 5 ld0: 20480 MB, 10402 cyl, 64 head, 63 sec, 512 bytes/sect x 41943040 sectors virtio2 at pci0 dev 3 function 0 virtio2: Virtio Network Device (rev. 0x00) vioif0 at virtio2: Features: 0x20 vioif0: Ethernet address fe:e1:bb:d1:15:a0 virtio2: interrupting at irq 6 vendor 0b5d product 0777 (miscellaneous communications) at pci0 dev 4 function 0 not configured isa0 at mainbus0 [ Boot stops here and enter brings me back to the console ] The messages from vmd -d are the following: vm_opentty: vm netbsd tty /dev/ttypd uid 1000 gid 4 mode 620 vm_register: registering vm 5 vm_priv_ifconfig: interface tap0 description vm5-if0-netbsd vm_priv_ifconfig: interface tap0 address 100.64.5.2/31 netbsd: started vm 5 successfully, tty /dev/ttypd loadfile_bios: loaded BIOS image run_vm: initializing hardware for vm netbsd pic_set_elcr: setting level triggered mode for irq 3 pic_set_elcr: setting level triggered mode for irq 5 pic_set_elcr: setting level triggered mode for irq 6 virtio_init: vm "netbsd" vio0 lladdr fe:e1:bb:d1:7c:d0, local pic_set_elcr: setting level triggered mode for irq 7 run_vm: starting vcpu threads for vm netbsd vcpu_reset: resetting vcpu 0 for vm 11 run_vm: waiting on events for VM netbsd i8259_write_datareg: master pic, reset IRQ vector to 0x8 i8259_write_datareg: slave pic, reset IRQ vector to 0x70 vcpu_exit_i8253: channel 0 reset, mode=2, start=65535 virtio_blk_io: device reset vcpu_process_com_lcr: set baudrate = 115200 vcpu_process_com_lcr: set baudrate = 9600 vcpu_process_com_lcr: set baudrate = 9600 i8259_write_datareg: master pic, reset IRQ vector to 0x20 i8259_write_datareg: slave pic, reset IRQ vector to 0x28 vcpu_exit_i8253: channel 0 reset, mode=2, start=11932 virtio_blk_io: device reset virtio_net_io: device reset vcpu_run_loop: vm 11 / vcpu 0 run ioctl failed: Bad address vmm_sighdlr: handling signal 20 vmm_sighdlr: terminated vm netbsd (id 5) vm_remove: vmm vmm_sighdlr removing vm 5 from running config vm_stop: vmm vmm_sighdlr stopping vm 5 vm_stop: parent vmd_dispatch_vmm stopping vm 5 dmesg of my system: OpenBSD 6.4-beta (GENERIC.MP) #299: Mon Sep 17 18:30:44 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12573237248 (11990MB) avail mem = 12182913024 (11618MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cbfd000 (65 entries) bios0: vendor LENOVO version "JBET67WW (1.31 )" date 12/14/2017 bios0: LENOVO 20BX0049GE acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA 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) i5-5200U CPU @ 2.20GHz, 2095.50 MHz, 06-3d-04 cpu0:
Re: Performance degradation with two systems running iwm(4)
Hi, * Stefan Sperling wrote: > > > If it helps further I'll record a dump from a second machine tomorrow. > > I have the second system with iwm and another that I could set up with > > an iwn. > > Yes please use iwn(4) in monitor mode. Thanks to a number of spare disks and my Thinkpad X220 I got a working iwn system. I connected to the local wifi and enabled mediaopt monitor. Now the wireshark statistic looks a bit different :) I uploaded another, this time larger dump to https://kappa.xosc.org/misc/iwn.zip, zipped and encrypted with password C9uaefllad . The last one and a half minutes (or so) of the dump are ones with very low speed. Cheers Matthias
Re: Performance degradation with two systems running iwm(4)
Hi Stefan, * Stefan Sperling wrote: > > I think a packet capture could shed some light on this. > I would not be surprised if slowdowns coincide with your neighbours > watching video streams or something over wifi. What's strange is that this does not affect me with the kernel from Dec 8. > I use a separate iwn(4) device in monitor mode for this, and: > tcpdump -n -i iwn0 -s 4096 -y IEEE802_11_RADIO -w /tmp/iwn.pcap > This captures data, management, and control frames. Most other drivers > omit some of these which makes it hard to figure out what's going on. I did a dump on the same machine and uplodaed it: https://kappa.xosc.org/misc/iwm.pcap.gz If it helps further I'll record a dump from a second machine tomorrow. I have the second system with iwm and another that I could set up with an iwn. > If you open iwn.pcap in wireshark you can go to Wireless -> WLAN Traffic > to see some aggregated stats of what's going on around you. A lot of other WLANs, some beacon frames from others but no packets. Cheers Matthias
Re: Performance degradation with two systems running iwm(4)
Hi, * Peter Hessler wrote: > > Please don't do that. That information will likely tell us that the 2018-01-03T17:56:39.224Z sigma /bsd: - 00:1e:2a:e1:18:906! +9 54M ess privacy rsn "ChaosUnlimited"! 2018-01-03T17:56:39.224Z sigma /bsd: - 04:f0:21:34:36:de8! +50 54M ess privacy rsn "guest.ka.v01d"! 2018-01-03T17:56:39.225Z sigma /bsd: - 24:65:11:23:e1:661! +13 54M ess privacy rsn "FRITZ!Box 6340 Cable"! 2018-01-03T17:56:39.225Z sigma /bsd: - 34:31:c4:29:dd:c61! +16 54M ess privacy rsn "FRITZ!Box 7272"! 2018-01-03T17:56:39.225Z sigma /bsd: - 54:67:51:3d:90:46 11! +25 54M ess privacy rsn "melbourne2016"! 2018-01-03T17:56:39.226Z sigma /bsd: - 54:67:51:3d:90:c8 100! +28 54M ess privacy rsn "melbourne2016"! 2018-01-03T17:56:39.226Z sigma /bsd: - 54:67:51:de:44:ae 11! +4 54M ess privacy rsn "UPC94933E6"! 2018-01-03T17:56:39.226Z sigma /bsd: - 54:fa:3e:89:48:3b4! +9 54M ess privacy rsn "miao"! 2018-01-03T17:56:39.226Z sigma /bsd: - 56:67:11:3d:90:46 11! +24 54M ess privacy rsn! "Unitymedia WifiSpot"! 2018-01-03T17:56:39.227Z sigma /bsd: - 90:5c:44:70:75:37 11! +12 54M ess privacy rsn "UPC241F9A1"! 2018-01-03T17:56:39.227Z sigma /bsd: - 90:5c:44:cf:2c:e6 11! +12 54M ess privacy rsn "UPCE5AEF49"! 2018-01-03T17:56:39.227Z sigma /bsd: - 94:4a:0c:81:3e:4b1! +8 54M ess privacy rsn "WLAN-903491"! 2018-01-03T17:56:39.228Z sigma /bsd: - a4:71:74:56:ce:606! +6 54M ess privacy rsn "WLAN-LZHX9Z"! 2018-01-03T17:56:39.228Z sigma /bsd: - a4:71:74:56:ce:616! +5 54M ess no! rsn! "Telekom_FON"! 2018-01-03T17:56:39.228Z sigma /bsd: - ac:22:05:d0:db:bf1! +11 54M ess privacy rsn "UPC1934418"! 2018-01-03T17:56:39.229Z sigma /bsd: - ae:22:15:d0:db:bf1! +8 54M ess privacy rsn! "Unitymedia WifiSpot"! 2018-01-03T17:56:39.229Z sigma /bsd: - b8:c7:5d:05:5e:a16! +10 54M ess privacy rsn ""! 2018-01-03T17:56:39.238Z sigma /bsd: - c8:0e:14:3d:a5:606! +7 54M ess privacy rsn "Laubi-Repeater"! 2018-01-03T17:56:39.239Z sigma /bsd: - c8:0e:14:e0:3b:6d6! +11 54M ess privacy rsn "FRITZ!Box 7490"! 2018-01-03T17:56:39.239Z sigma /bsd: + cc:ce:1e:8b:cf:d1 60 +31 54M ess privacy rsn "karlsruhe.v01d" 2018-01-03T17:56:39.240Z sigma /bsd: - cc:ce:1e:8b:cf:d26! +36 54M ess privacy rsn "karlsruhe.v01d" 2018-01-03T17:56:39.240Z sigma /bsd: - ce:ce:1e:8b:cf:d1 60 +31 54M ess privacy rsn "untrusted.ka.v01d"! 2018-01-03T17:56:39.240Z sigma /bsd: - ce:ce:1e:8b:cf:d26! +36 54M ess privacy rsn "untrusted.ka.v01d"! 2018-01-03T17:56:39.240Z sigma /bsd: - d0:66:7b:03:12:801! +27 54M ess privacy rsn "SEC_LinkShare_04c4f4"! 2018-01-03T17:56:39.241Z sigma /bsd: - d4:40:f0:b0:aa:fd1! +8 54M ess privacy rsn "WLAN-Y2DX74"! > wifi air-time is massively polluted, and that you're SOL. Oh yes, there are a lot of other APs here. And BTW, what's SOL? > Switch to 5Ghz, if at all possible. 2.4Ghz is basically unusable in the > modern world. As strange as this sounds, switching to 5Ghz made the slowdown disappear. I set mode to 11n and chan to 60 and I no longer see the effect. Going back to 2.4Ghz and I see the slowdown again after some time. Now I am totally puzzled. Cheers Matthias
Re: Performance degradation with two systems running iwm(4)
Hi benno, hi Stefan, * Sebastian Benoit wrote: > > and then running your test - with current, and maybe with the older "fast" > kernel as well. Sure, here you go. First run with the kernel from Dec 8, second run with a fresh kernel from Jan 1. I also run netstat -W/-I for the second run. Cheers Matthias -- - First run with the fast kernel - -- OpenBSD 6.2-current (GENERIC.MP) #261: Fri Dec 8 11:22:29 MST 2017 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 100M 100 100M0 0 2844k 0 0:00:36 0:00:36 --:--:-- 3068k 100 100M 100 100M0 0 3200k 0 0:00:32 0:00:32 --:--:-- 3107k 100 100M 100 100M0 0 3103k 0 0:00:33 0:00:33 --:--:-- 3287k 100 100M 100 100M0 0 3103k 0 0:00:33 0:00:33 --:--:-- 3089k 100 100M 100 100M0 0 2925k 0 0:00:35 0:00:35 --:--:-- 3146k 100 100M 100 100M0 0 2767k 0 0:00:37 0:00:37 --:--:-- 2369k 100 100M 100 100M0 0 3303k 0 0:00:31 0:00:31 --:--:-- 2768k 100 100M 100 100M0 0 3011k 0 0:00:34 0:00:34 --:--:-- 3017k 100 100M 100 100M0 0 3303k 0 0:00:31 0:00:31 --:--:-- 2869k 100 100M 100 100M0 0 2925k 0 0:00:35 0:00:35 --:--:-- 2896k 2018-01-03T16:49:20.236Z sigma /bsd: iwm0: RUN -> INIT 2018-01-03T16:49:20.323Z sigma /bsd: iwm0: begin active scan 2018-01-03T16:49:20.375Z sigma /bsd: iwm0: SCAN -> INIT 2018-01-03T16:49:20.462Z sigma /bsd: iwm0: begin active scan 2018-01-03T16:49:20.466Z sigma /bsd: iwm0: SCAN -> INIT 2018-01-03T16:49:20.553Z sigma /bsd: iwm0: begin active scan 2018-01-03T16:49:20.560Z sigma /bsd: iwm0: SCAN -> INIT 2018-01-03T16:49:20.648Z sigma /bsd: iwm0: begin active scan 2018-01-03T16:49:20.652Z sigma /bsd: iwm0: SCAN -> INIT 2018-01-03T16:49:20.739Z sigma /bsd: iwm0: begin active scan 2018-01-03T16:49:20.748Z sigma /bsd: iwm0: SCAN -> INIT 2018-01-03T16:49:20.749Z sigma dhclient[43144]: fatal in iwm0: down 2018-01-03T16:49:20.846Z sigma /bsd: iwm0: begin active scan 2018-01-03T16:49:25.316Z sigma /bsd: iwm0: end active scan 2018-01-03T16:49:25.317Z sigma /bsd: - 00:0e:c6:03:xx:xx1! +9 54M ess no! rsn! "WiFi_OBDII"! [ Cut APs from neighbours ] 2018-01-03T16:49:25.327Z sigma /bsd: - d4:40:f0:b0:xx:xx1! +11 54M ess privacy rsn "WLAN-Y2DX74"! 2018-01-03T16:49:25.327Z sigma /bsd: iwm0: SCAN -> AUTH 2018-01-03T16:49:25.328Z sigma /bsd: iwm0: sending auth to cc:ce:1e:8b:cf:d2 on channel 6 mode 11g 2018-01-03T16:49:25.328Z sigma /bsd: iwm0: AUTH -> ASSOC 2018-01-03T16:49:25.329Z sigma /bsd: iwm0: sending assoc_req to cc:ce:1e:8b:cf:d2 on channel 6 mode 11g 2018-01-03T16:49:25.339Z sigma /bsd: iwm0: received msg 1/4 of the 4-way handshake from cc:ce:1e:8b:cf:d2 2018-01-03T16:49:25.340Z sigma /bsd: iwm0: sending msg 2/4 of the 4-way handshake to cc:ce:1e:8b:cf:d2 2018-01-03T16:49:25.342Z sigma /bsd: iwm0: ASSOC -> RUN 2018-01-03T16:49:25.342Z sigma /bsd: iwm0: associated with cc:ce:1e:8b:cf:d2 ssid "home" channel 6 start MCS 0 short preamble short slot time HT enabled 2018-01-03T16:49:25.343Z sigma /bsd: iwm0: missed beacon threshold set to 7 beacons, beacon interval is 100 TU 2018-01-03T16:49:25.350Z sigma /bsd: iwm0: received msg 3/4 of the 4-way handshake from cc:ce:1e:8b:cf:d2 2018-01-03T16:49:25.351Z sigma /bsd: iwm0: sending msg 4/4 of the 4-way handshake to cc:ce:1e:8b:cf:d2 2018-01-03T16:49:26.301Z sigma /bsd: iwm0: sending action to cc:ce:1e:8b:cf:d2 on channel 6 mode 11n 2018-01-03T16:55:47.987Z sigma /bsd: iwm0: received msg 1/2 of the group key handshake from cc:ce:1e:8b:cf:d2 2018-01-03T16:55:47.988Z sigma /bsd: iwm0: sending msg 2/2 of the group key handshake to cc:ce:1e:8b:cf:d2 [ Stopped here ] - - Second run where performance drops after a while - - OpenBSD 6.2-current (GENERIC.MP) #313: Mon Jan 1 17:51:21 MST 2018 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 100M 100 100M0 0 2625k 0 0:00:39 0:00:39 --:--:-- 3075k 100 100M 100 100M0 0 2844k 0 0:00:36 0:00:36 --:--:-- 2677k 100 100M 100 100M0 0 2844k 0 0:00:36 0:00:36 --:--:-- 2766k 100 100M 100 100M0 0 2497k 0 0:00:41 0:00:41 --:--:-- 2824k 100 100M 100 100M0 0 3657k 0 0:00:28 0:00:28 --:--:-- 2919k 100 100M 100 100M0 0 2438k 0 0:00:42 0:00:42 --:--:-- 3012k 100 100M 100 100M0 0 2844k 0 0:00:36 0:00:36 --:--:--
Re: Performance degradation with two systems running iwm(4)
Hi again, * Matthias Schmidt wrote: > > When I start a new download, the data transfer rate on both devices > significantly drops after a while. When the transfer is still fast, my > DSL router says that both devices are connected with 11n and have about > 130Mbit/s. After a while I am down to 1-2MBit/s. When I abort the > transfer and wait some time (around 30s) I can again start with full > speed and the AP shows 130MBit/s. After a while I am down to 1-2Mbit/s, > again. I downloaded all snapshot kernel from December and did some reboot -> download -> repeat loops and found that the last working kernel where I get full speed with my AP is the following: OpenBSD 6.2-current (GENERIC.MP) #265: Sat Dec 9 10:24:12 MST 2017 With the kernel from Dec 12 on download takes forever. @Stefan: Since I saw you quite often in the commit logs at that time ... any idea what's happening here? Cheers Matthias OpenBSD 6.2-current (GENERIC.MP) #261: Fri Dec 8 11:22:29 MST 2017 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 100M 100 100M0 0 4266k 0 0:00:24 0:00:24 --:--:-- 4476k 100 100M 100 100M0 0 4096k 0 0:00:25 0:00:25 --:--:-- 4380k 100 100M 100 100M0 0 3938k 0 0:00:26 0:00:26 --:--:-- 4281k 100 100M 100 100M0 0 3938k 0 0:00:26 0:00:26 --:--:-- 4067k 100 100M 100 100M0 0 3531k 0 0:00:29 0:00:29 --:--:-- 4027k 100 100M 100 100M0 0 3792k 0 0:00:27 0:00:27 --:--:-- 4636k 100 100M 100 100M0 0 4266k 0 0:00:24 0:00:24 --:--:-- 4550k OpenBSD 6.2-current (GENERIC.MP) #265: Sat Dec 9 10:24:12 MST 2017 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 100M 100 100M0 0 2438k 0 0:00:42 0:00:42 --:--:-- 3330k 100 100M 100 100M0 0 3103k 0 0:00:33 0:00:33 --:--:-- 3288k 100 100M 100 100M0 0 3103k 0 0:00:33 0:00:33 --:--:-- 3208k 100 100M 100 100M0 0 2694k 0 0:00:38 0:00:38 --:--:-- 1225k 100 100M 100 100M0 0 3200k 0 0:00:32 0:00:32 --:--:-- 3165k 100 100M 100 100M0 0 2767k 0 0:00:37 0:00:37 --:--:-- 2039k 100 100M 100 100M0 0 2925k 0 0:00:35 0:00:35 --:--:-- 3044k OpenBSD 6.2-current (GENERIC.MP) #268: Sun Dec 10 11:18:16 MST 2017 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 100M 100 100M0 0 1528k 0 0:01:07 0:01:07 --:--:-- 2485k 100 100M 100 100M0 0 2767k 0 0:00:37 0:00:37 --:--:-- 3057k 100 100M 100 100M0 0 2560k 0 0:00:40 0:00:40 --:--:-- 2747k 100 100M 100 100M0 0 1505k 0 0:01:08 0:01:08 --:--:-- 1975k 100 100M 100 100M0 0 1528k 0 0:01:07 0:01:07 --:--:-- 1114k 100 100M 100 100M0 0 2048k 0 0:00:50 0:00:50 --:--:-- 500k 100 100M 100 100M0 0 1442k 0 0:01:11 0:01:11 --:--:-- 1932k OpenBSD 6.2-current (GENERIC.MP) #271: Mon Dec 11 10:35:21 MST 2017 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 18 100M 18 18.5M0 0 112k 0 0:15:07 0:02:48 0:12:19 165k
Performance degradation with two systems running iwm(4)
Hi guys, I'm currently facing a network performance degradation with two different devices both connected via iwm(4) to the local access point. Both are running 6.2-current, one with a snapshot from Dec 16 the other with a snapshot from Dec 26. dmesg of one device attached. Both devices are connected to a standard German FritzBox with 11n in the 2.4GHz band. I do not have 5GHz enabled. When I start a new download, the data transfer rate on both devices significantly drops after a while. When the transfer is still fast, my DSL router says that both devices are connected with 11n and have about 130Mbit/s. After a while I am down to 1-2MBit/s. When I abort the transfer and wait some time (around 30s) I can again start with full speed and the AP shows 130MBit/s. After a while I am down to 1-2Mbit/s, again. I downloaded the 100M file from hostserver.de in a loop and it looks like this (stripped down curl downloads): % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 100M 100 100M0 0 3657k 0 0:00:28 0:00:28 --:--:-- 4266k 100 100M 100 100M0 0 2327k 0 0:00:44 0:00:44 --:--:-- 2356k 100 100M 100 100M0 0 2275k 0 0:00:45 0:00:45 --:--:-- 1961k 100 100M 100 100M0 0 1678k 0 0:01:01 0:01:01 --:--:-- 131k 100 100M 100 100M0 0 193k 0 0:08:50 0:08:50 --:--:-- 117k 8 100M8 8516k0 0 144k 0 0:11:49 0:00:59 0:10:50 141k^C I run the above download loop for the last couple of days and could reproduce it every time. Any hint on how I could debug further? Cheers Matthias OpenBSD 6.2-current (GENERIC.MP) #292: Sat Dec 16 13:27:27 MST 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17047859200 (16258MB) avail mem = 16524275712 (15758MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7b1d5000 (58 entries) bios0: vendor Intel Corp. version "SYSKLi35.86A.0062.2017.0831.1905" date 08/31/2017 bios0: Intel corporation NUC6i5SYB acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT UEFI SSDT DMAR acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) SIO1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(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-6260U CPU @ 1.80GHz, 1696.55 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,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 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.04 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,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 1 (application processor) cpu2: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.04 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.04 MHz cpu3:
Re: uvm_fault while running X and quitting Firefox
Hi Alexander, * Alexander Bluhm wrote: > On Fri, Nov 03, 2017 at 07:06:34PM +0100, Matthias Schmidt wrote: > > my system dropped into ddb when running X11 and quitting Firefox (with > > the intention to quit X and shutdown). > > pf_test_rule+0xa0b is when pf_send_tcp() calls ip_send(). > This was fixed here: You are right, upgrading to tonight's snapshot fixed the problem. Thanks and cheers Matthias
Re: uvm_fault while running X and quitting Firefox
Hi, * Matthias Schmidt wrote: > Hi, > > my system dropped into ddb when running X11 and quitting Firefox (with > the intention to quit X and shutdown). Suddenly it dropped into the > console and ddb and showed a uvm_fault(). I could not acquire a dump > since the system stuck in "syncing disks". After half an hour I > resetted the system. > > I captured photos from all ddb messages including trace, ps: > > https://kappa.xosc.org/misc/ > > I run a snapshot from Oct 31: > > OpenBSD tau.xosc.org 6.2 GENERIC.MP#190 amd64 > > Maybe it's worth mentioning that I run Firefox 57 beta 13 from laundry@ > > firefox-57.0beta13 > > If you need further information please get back to me. However, I am > not sure if I can reproduce it. Interestingly, I could reproduce it by simply quitting Firefox. The only thing different from two days ago when I updated to the snapshot is that I upgraded to Firefox 57 Beta 13 from Beta 12. Thus, CC landry@. Cheers Matthias
uvm_fault while running X and quitting Firefox
Hi, my system dropped into ddb when running X11 and quitting Firefox (with the intention to quit X and shutdown). Suddenly it dropped into the console and ddb and showed a uvm_fault(). I could not acquire a dump since the system stuck in "syncing disks". After half an hour I resetted the system. I captured photos from all ddb messages including trace, ps: https://kappa.xosc.org/misc/ I run a snapshot from Oct 31: OpenBSD tau.xosc.org 6.2 GENERIC.MP#190 amd64 Maybe it's worth mentioning that I run Firefox 57 beta 13 from laundry@ firefox-57.0beta13 If you need further information please get back to me. However, I am not sure if I can reproduce it. Cheers Matthias OpenBSD 6.2-current (GENERIC.MP) #190: Tue Oct 31 18:49:52 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17047859200 (16258MB) avail mem = 16524353536 (15758MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7b1d5000 (58 entries) bios0: vendor Intel Corp. version "SYSKLi35.86A.0062.2017.0831.1905" date 08/31/2017 bios0: Intel corporation NUC6i5SYB acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT UEFI SSDT DMAR acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) SIO1(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(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-6260U CPU @ 1.80GHz, 1696.56 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,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 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,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 1 (application processor) cpu2: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz, 1696.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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,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, 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 1 (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: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1
Re: slaacd(8) is generating IPv6 addresses at a very high rate
Hi Stefan, I was on a business trip since Sunday evening and now I can - strangely enough - no longer reproduce the issue :/ The machine was in suspend during that time. I rebooted, plugged in a cable, however, everything works as expected. Nevertheless, I will answer your questions below since I hit the issue in the first place. * Stefan Sperling wrote: > On Sun, Jun 25, 2017 at 08:34:46PM +0200, Matthias Schmidt wrote: > > Hi, > > > > I installed a recent snapshot from June 23 and noticed that slaacd is > > generating IPv6 addresses with privacy extensions enabled in a high > > rate. I can easily reproduce the bug by just starting slaacd. After > > one second I already see 29 IPv6 addresses: > > > > $ ifconfig trunk0 | grep inet6 | wc -l > > 29 > > Does this number keep growing over time? Or does it just > collect a bunch of addresses when the interface comes up? Initially the number was growing over time. After some minutes I had so many fd00:: addresses that the ifconfig output scrolled for some seconds long. > > inet6 fd00::c8c1:eda0:2f1b:7e99 prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7044 > > inet6 fd00::b081:7ff1:9740:fb6 prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7044 > > inet6 fd00::3ceb:3269:d174:c8cd prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7046 > > inet6 fd00::e875:55ac:6557:2d74 prefixlen 64 deprecated autoconf > > autoconfprivacy pltime 0 vltime 7046 > > All the fd00 addresses are from the fc00::/7 prefix. > See https://en.wikipedia.org/wiki/Unique_local_address > > Not sure what the fritzbox is announcing this prefix for. > The fritzbox might be doing this if it does not have a routable IPv6 > prefix yet, perhaps? A prefix lifetime of zero implies that these addresses > are not used for new connections. They should disappear once vltime hits zero. > > > [...] > > What did you omit here? More addresses? Yes. > Were these all from the fc00::/7 prefix? Yes. > Were there any with pltime > 0? Yes. > Could you record router solicitations and router advertisements with tcpdump > and show us what they contain? Does the fritzbox keep announcing the fd00::/64 > prefix with a non-zero prefix lifetime? > > The kernel SLAAC code probably filtered these addresses out somehow. > My guess (from code inspection) is that, in 6.1-release, the fd00 > addresses were replaced once a "real" global prefix was configured. > But the details are not immediately obvious. It's IPv6, after all :) As said above, I no longer see any fd00:: addresses assigned. Whenever the issue comes back, I'll write another email. Cheers and thanks Matthias
slaacd(8) is generating IPv6 addresses at a very high rate
Hi, I installed a recent snapshot from June 23 and noticed that slaacd is generating IPv6 addresses with privacy extensions enabled in a high rate. I can easily reproduce the bug by just starting slaacd. After one second I already see 29 IPv6 addresses: $ ifconfig trunk0 | grep inet6 | wc -l 29 $ ifconfig trunk0 | grep inet6 inet6 fe80::527b:9dff:fe73:aa8a%trunk0 prefixlen 64 scopeid 0x5 inet6 fd00::c00d:a431:9cfc:899a prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 7043 inet6 2001:16b8:2234:3200:527b:9dff:fe73:aa8a prefixlen 64 autoconf pltime 3461 vltime 7061 inet6 fd00::527b:9dff:fe73:aa8a prefixlen 64 deprecated autoconf pltime 0 vltime 7061 inet6 2001:16b8:2234:3200:50e2:4a65:a0af:3926 prefixlen 64 autoconf autoconfprivacy pltime 3443 vltime 7043 inet6 fd00::c8c1:eda0:2f1b:7e99 prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 7044 inet6 fd00::b081:7ff1:9740:fb6 prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 7044 inet6 fd00::3ceb:3269:d174:c8cd prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 7046 inet6 fd00::e875:55ac:6557:2d74 prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 7046 [...] syslog is filled with the following error messages Jun 25 19:56:43 sigma slaacd[19817]: ignoring router advertisement that lowers vltime: Undefined error: 0 Jun 25 19:56:43 sigma slaacd[19817]: ignoring router advertisement that lowers vltime: Undefined error: 0 Jun 25 19:56:45 sigma slaacd[19817]: ignoring router advertisement that lowers router lifetime: Undefined error: 0 I am running OpenBSD sigma 6.1 GENERIC.MP#43 amd64, dmesg is attached. The prefix is sent from a Fritz!Box on a local LAN. I do not see the issue on the same LAN with another machine running 6.1-STABLE with autoconf. It also happens when I use em0 or iwm0 directly. If you have further questions, get back to me. Cheers Matthias
