Re: Xorg hangs on recent snapshots
On Wed, 05 Feb 2020 at 20:29:31 +0100, William Orr wrote: > > Hey, > > On recent a snap (04/02/2020), the unpriv'ed process of Xorg seems to hang, > becoming totally unresponsive. Running `ktrace` on the process fails to log > any output. `top` shows that the process is waiting on `fsleep`. I'm using the > amdgpu driver. Similar issue here. It seems to happen randomly (possibly more often under high memory usage). It's always after X has started and I have been using it for some time (days sometimes). MPD will continue to play music in the background and pressing the power button for a few seconds seems to result in a shutdown, however, it doesn't quite shutdown properly. The screen will go blank and the fans will start to spin at full speed. At which point holding the power button seems to be the only fix. This is on my a485, dmesg below (amdgpu-firmware-20190312) OpenBSD 6.6-current (GENERIC.MP) #628: Sat Feb 1 23:32:22 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33139392512 (31604MB) avail mem = 32122556416 (30634MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x685c8000 (62 entries) bios0: vendor LENOVO version "R0WET60W (1.28 )" date 11/01/2019 bios0: LENOVO 20MUCTO1WW acpi0 at bios0 acpi0: BGRT checksum error: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT CRAT CDIT SSDT TPM2 UEFI MSDM BATB HPET APIC MCFG SBST WSMT VFCT IVRS FPDT SSDT SSDT SSDT UEFI SSDT BGRT acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) L850(S3) GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx, 2196.28 MHz, 17-11-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx, 2195.85 MHz, 17-11-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx, 2195.85 MHz, 17-11-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx, 2195.85 MHz, 17-11-00 cpu3:
Re: umb device no longer detected
I've told Lee to test something for me. I think the priority from match functions are being confused via these (stupid) UMATCH_* variables, which are some weird disguise for what is supposed to be a priority code. In his upgraded case, ubm should win. it returns UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO which is 5. umsm does fewer tests, and returns UMATCH_VENDOR_IFACESUBCLASS which is 6. So with my change umsm wins. I asked Lee to first test if_umb.c returning a higher value such as UMATCH_VENDOR_IFACESUBCLASS_IFACEPROTO which is 7 On my backwards device, if_umb does not match at all, so umsm would win. If I am right, that would satisfy both old and new devices; I think umb_patch is already doing the correct "tests", but simply returning the wrong value. And if that helps, then I think all this should be reconsidered. I *think* the idea behind this UMATCH_* variable naming is that the match return value says "how many fields did I look at and how confident am I", and that's what the naming comes from, but what I don't understand is --- who cares how many fields you looked at, as far as the subr_conf.c code is concerned this is ONLY a priority code not some "what did I do" to decide thing. And the priority value is going to something more magical, it's not some direct mapping between "how much did you look at". However are a mess of relationships here with the many device need "first kick me off umass", so we need to be somewhat careful to pick at this problem from the correct end.
Re: umb device no longer detected
Hello Gerhard, Theo asked me if I could get one of these devices to you. I have two choices: 1. Pick up the one on Yahoo Auctions (I'm in Tokyo) and send it. 2. Remove the one in my machine and send it. I'm easy either way (I won't be actively using mine until I can finish off the umb authentication patches). The one on Yahoo might need unlocking though - it seems to be a bit hit-and-miss as to whether they're locked or not. Let me know what you want to do. Lee. On Wed Feb 5, 2020 at 2:32 PM, Gerhard Roth wrote: > On Wed, 05 Feb 2020 05:55:41 -0700 "Theo de Raadt" > wrote: > > Well, I have been given this particilular MC7700 which works as umsm, > > but it does *NOT* match as umb, probably because it's firmware is too > > old? Or it is in the wrong mode, I can't tell. > > > The current mode can be queried with > > > AT!UDUSBCOMP? > > > And > > > AT!UDUSBCOMP=? > > > should give a list of supported interface compositions. > > > My guess is that the device is in a mode that offers multiple > interfaces. > And MBIM is on config #2. > > > Since umsm now matches on config #1, usbd_probe_and_attach() stops here > and never probes config #2 (like it did before). > > > It would be interesting if config #2 offers an AT-interfac (umsm), too. > In that case umsm and umb could coexist. > > > > > Gerhard > > > > > > > > The alternative is that the device cannot attach at all. > > > > How does this get resolved? I can dig it up and show in a few days. > > > > Gerhard Roth wrote: > > > > > On Wed, 5 Feb 2020 19:54:01 +0900 leeb wrote: > > > > >Synopsis: umb device no longer detected > > > > >Category: kernel > > > > >Environment: > > > > System : OpenBSD 6.6 > > > > Details : OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 > > > > 20:23:40 JST 2020 > > > > > > > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > Architecture: OpenBSD.amd64 > > > > Machine : amd64 > > > > >Description: > > > > Before reworking my umb authentication patches I upgraded > > > > my -current, and found that the LTE modem was no longer > > > > detected as a umb device. It seems to be picked up later > > > > in the boot via umsm, but I don't think that should be > > > > happening. > > > > > > That comes from https://marc.info/?l=openbsd-cvs=157878261716342=2 > > > > > > It's not that 'umsm picks up the device later', it's just that > > > umsm_match() [UMATCH_VENDOR_IFACESUBCLASS] now wins over umb_match() > > > [UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO]. > > > > > > Gerhard > > > > > > > > > > > I happened to have an older working -current kernel saved, > > > > so tried booting from that - the umb device is detected OK. > > > > > > > > To eliminate the possibility of a mistake on my part, I > > > > swapped disks in this machine and installed a fresh current > > > > snapshot. Same result. I've attached below the sendbug > > > > outputs from both the working (old) kernel, and the new > > > > (not working) kernel. > > > > > > > > I installed the clean -current from an image at: > > > > ftp.jaist.ac.jp in /OpenBSD/snapshots/amd64/install66.fs > > > > > > > > Ran 'sysupgrade -s' on the new install to make sure I was > > > > up-to-date. > > > > > > > > >How-To-Repeat: > > > > Install or upgrade to latest snapshot on a machine with a > > > > umb device. > > > > > > > > ** sendbug -P output from OK kernel * > > > > > > > > dmesg: > > > > OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 JST 2020 > > > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > > > real mem = 16972566528 (16186MB) > > > > avail mem = 16445722624 (15683MB) > > > > mpath0 at root > > > > scsibus0 at mpath0: 256 targets > > > > mainbus0 at root > > > > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) > > > > bios0: vendor LENOVO version "G2ET92WW (2.52 )" date 02/22/2013 > > > > bios0: LENOVO 23061Q2 > > > > acpi0 at bios0: ACPI 5.0 > > > > acpi0: sleep states S0 S3 S4 S5 > > > > acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT > > > > FPDT ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2 BGRT > > > > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) > > > > EHC1(S3) EHC2(S3) HDEF(S4) > > > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > > > acpihpet0 at acpi0: 14318179 Hz > > > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > > > cpu0 at mainbus0: apid 0 (boot processor) > > > > cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.78 MHz, 06-3a-09 > > > > cpu0: > > > >
dig: internal_send when network is dead
Hi All, Not sure if this is the expected behavior: $ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes ping: sendmsg: Invalid argument ping: wrote 1.1.1.1 64 chars, ret=-1 ping: sendmsg: Invalid argument ping: wrote 1.1.1.1 64 chars, ret=-1 ping: sendmsg: Invalid argument ping: wrote 1.1.1.1 64 chars, ret=-1 ^C --- 1.1.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss $ ping yahoo.com ping: no address associated with name $ dig yahoo.com /usr/src/usr.sbin/bind/lib/isc/unix/socket.c:1179: internal_send: 68.105.28.11#53: Invalid argument /usr/src/usr.sbin/bind/lib/isc/unix/socket.c:1179: internal_send: 68.105.29.11#53: Invalid argument /usr/src/usr.sbin/bind/lib/isc/unix/socket.c:1179: internal_send: 68.105.28.12#53: Invalid argument /usr/src/usr.sbin/bind/lib/isc/unix/socket.c:1179: internal_send: 68.105.28.11#53: Invalid argument /usr/src/usr.sbin/bind/lib/isc/unix/socket.c:1179: internal_send: 68.105.29.11#53: Invalid argument /usr/src/usr.sbin/bind/lib/isc/unix/socket.c:1179: internal_send: 68.105.28.12#53: Invalid argument ^C $ sysctl kern.version kern.version=OpenBSD 6.6-current (GENERIC.MP) #630: Tue Feb 4 06:40:24 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info
Xorg hangs on recent snapshots
Hey, On recent a snap (04/02/2020), the unpriv'ed process of Xorg seems to hang, becoming totally unresponsive. Running `ktrace` on the process fails to log any output. `top` shows that the process is waiting on `fsleep`. I'm using the amdgpu driver. top, dmesg and Xorg.log contents follow. Let me know if there's other information I need to provide. Thanks! top -n: load averages: 0.30, 0.38, 0.46locke.worr.haus 20:26:41 61 processes: 60 idle, 1 on processor up 0:35 CPU0 states: 6.1% user, 0.0% nice, 3.1% sys, 2.8% spin, 0.4% intr, 87.6% idle CPU1 states: 9.8% user, 0.0% nice, 6.5% sys, 1.9% spin, 0.0% intr, 81.8% idle CPU2 states: 9.6% user, 0.0% nice, 6.4% sys, 1.8% spin, 0.0% intr, 82.2% idle CPU3 states: 7.6% user, 0.0% nice, 4.6% sys, 1.6% spin, 0.0% intr, 86.2% idle Memory: Real: 357M/9821M act/tot Free: 5933M Cache: 8539M Swap: 0K/11G PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND ... 41003 _x11 100 55M 79M idle fsleep0:07 0.00% Xorg ... dmesg: OpenBSD 6.6-current (GENERIC.MP) #630: Tue Feb 4 06:40:24 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17040244736 (16250MB) avail mem = 16511328256 (15746MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xee7f0 (26 entries) bios0: vendor American Megatrends Inc. version "P2.90" date 07/11/2013 bios0: ASRock Z77 Extreme4 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT AAFT HPET SSDT SSDT SSDT BGRT acpi0: wakeup devices PS2K(S4) UAR1(S4) P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP05(S4) RP06(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) i7-3770K CPU @ 3.50GHz, 3500.49 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3500.04 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3500.04 MHz, 06-3a-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3500.04 MHz, 06-3a-09 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 2 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 3 (RP04) acpiprt6 at acpi0: bus 4 (RP05) acpiprt7 at acpi0: bus 5 (RP06) acpiprt8 at acpi0: bus 6 (BR40) acpiprt9 at acpi0: bus -1 (RP07) acpiprt10 at acpi0: bus 7 (RP08) acpiprt11 at acpi0: bus 1 (PEG0) acpiprt12 at acpi0: bus -1 (PEG1) acpiprt13 at acpi0: bus -1 (PEG2) acpiprt14 at acpi0: bus -1 (PEG3) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10), C1(1000@1
Re: IPsec traffic causes system to halt with 'kernel: double fault trap, code=0' at 'pf_setup_pdesc+0x3f'
Hello *,
after experimenting with different MTU sizes and pf normalisation rules,
I am getting the feeling of a root cause lying somewhere near path MTU
discovery - perhaps in combination with IPsec.
These are the console log messages of another crash observed meanwhile:
kernel: double fault trap, code=0
Stopped at rtable_l2+0xf: pushq %rdi
ddb{0}> trace
rtable_l2(0) at rtable_l2+0xf
pf_setup_pdesc(8000210e40a8,2,2,8016c400,fd806ee32e00,f8210e41be)
at pf_setup_pdesc+0x7d
pf_test(2,2,8013f000,8000210e4290) at pf_test+0xfe
ip_output(fd806ee32e00,0,fd807d95a5f8,800,0,fd807d95a588) at
ip_output+0x7cf
tcp_output(80551980) at tcp_output+0x15c1
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
tcp_output(80551980) at tcp_output+0x1914
[... some identical lines omitted...]
tcp_timer_rexmt(80551980) at tcp_timer_rexmt+0x3f5
softclock_thread(8000210d2c58) at softclock_thread+0xfb
end trace frame: 0x0, count: -50
While the first lines differ, the tcp_output(...) and tcp_timer_rexmt(...)
and softclock_thread(...) stay always the same.
At the moment, by reducing the MTU of my vio0 interface to 1488 bytes and
attempting to clear DF flags on packages related to IPsec payload traffic
(/etc/pf.conf snippet: "match on enc0 scrub (max-mss 1360 random-id no-df)"),
I managed to delay crashes from ~ 30 minutes up to some hours in productive
use scenarios. Again, there is no problem if the machine is running idle.
Since these stalls keep happening and I am out of ideas by now, I wonder
if anybody is successfully running a Squid upstream proxy in combination
with an IPsec site-to-site connection on the same machine.
Thanks, and best regards,
Peter Müller
> Hello Alexander,
>
> thank you for your reply. Is there anything I can do about this
> like modifying configurations or provide further information?
>
> Thanks, and best regards,
> Peter Müller
>
>
>> On Fri, Jan 31, 2020 at 03:21:00PM +, Peter M??ller wrote:
>>> tcp_output(80584ee0) at tcp_output+0x1941
>>> tcp_output(80584ee0) at tcp_output+0x1941
>>> tcp_output(80584ee0) at tcp_output+0x1941
>>
>> Looks like stack exhaustion. tcp_output() calls tcp_mtudisc() calls
>> tcp_output().
>>
>> /usr/src/sys/netinet/tcp_output.c:1084
>>
>> if (error == EMSGSIZE) {
>> /*
>> * ip_output() will have already fixed the route
>> * for us. tcp_mtudisc() will, as its last action,
>> * initiate retransmission, so it is important to
>> * not do so here.
>> */
>> tcp_mtudisc(tp->t_inpcb, -1);
>> return (0);
>> }
>>
>> bluhm
>>
>
Re: unwind reports no signature or no DNSSEC
On Wed, Feb 05, 2020 at 04:14:41PM +0100, Florian Obser wrote: > On Tue, Feb 04, 2020 at 11:41:14AM +, Raf Czlonka wrote: > > On Mon, Feb 03, 2020 at 07:29:02PM GMT, Florian Obser wrote: > > > On Mon, Feb 03, 2020 at 07:58:24PM +0100, Solene Rapenne wrote: > > > > On Mon, Feb 03, 2020 at 07:52:29PM +0100, Florian Obser wrote: > > > > > On Mon, Feb 03, 2020 at 06:16:54PM +0100, Solene Rapenne wrote: > > > > > > I re-enabled unwind today (i was using append instead of prepend in > > > > > > dhclient.conf) and I got a few issues resolving domains, often the > > > > > > first > > > > > > time, if I try again I get a result. I'm pretty sure it's not a > > > > > > bug, but > > > > > > I have no idea what's happening here, so maybe log output or > > > > > > documentation could be enhanced. > > > > > > > > > > > > > > > > > > From /var/log/messages (192.168.1.254 is dns from my dhcp) > > > > > > > > > > > > Feb 3 17:55:44 solene unwind[18044]: validation failure > > > > > > : no signatures from > > > > > > 192.168.1.254 for key org. while building chain of trust > > > > > > Feb 3 18:05:10 solene unwind[18044]: validation failure > > > > > > : no DNSSEC records from 192.168.1.254 for DS > > > > > > google.fr. while building chain of trust > > > > > > Feb 3 18:05:18 solene unwind[18044]: validation failure > > > > > > : no signatures from 192.168.1.254 for DS it. > > > > > > while building chain of trust > > > > > > > > > > > > > > > > Looks like your dhcp nameserver strips DNSSEC in a weird way. > > > > > Can you please show > > > > > > > > > > dig @192.168.1.254 +dnssec . SOA > > > > > and > > > > > dig @192.168.1.254 org DNSKEY > > > > > > > > > > -- > > > > > I'm not entirely sure you are real. > > > > > > > > > > > > > sure :) > > > > > > > > solene@t480 ~ $ dig @192.168.1.254 +dnssec . SOA > > > > > > > > ; <<>> dig 9.10.8-P1 <<>> @192.168.1.254 +dnssec . SOA > > > > ; (1 server found) > > > > ;; global options: +cmd > > > > ;; Got answer: > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63346 > > > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > > > > > > > ;; OPT PSEUDOSECTION: > > > > ; EDNS: version: 0, flags:; udp: 4096 > > > > ;; QUESTION SECTION: > > > > ;. IN SOA > > > > > > > > ;; ANSWER SECTION: > > > > . 84857 IN SOA a.root-servers.net. > > > > nstld.verisign-grs.com. 2020020301 1800 900 604800 86400 > > > > > > > > ;; Query time: 25 msec > > > > ;; SERVER: 192.168.1.254#53(192.168.1.254) > > > > ;; WHEN: Mon Feb 03 19:54:35 CET 2020 > > > > ;; MSG SIZE rcvd: 103 > > > > > > > > > > for the archives: 192.168.1.254 is stripping rrsigs but unwind thinks > > > dhcp is validating. This is wrong and we need to figure out why. > > > > > > > Hi all, > > > > I've been having similar (the same?) issues since at least mid-to-late > > December. I hadn't a chance to diagnose it properly hence sending > > an email only now to confirm Solene's isn't an isolated case. > > > > Unlike Solene, I would have to restart unwind to get it resolving. > > I'm sure you had(!) a different issue than Solene. unwind correctly > detects that your dhcp provided nameserver can only do resolving and > strips dnssec records while the recursor can do validation. > > On December 18th I enabled a shared cache for negative answers in > rev 1.116 of resolver.c. > > As kn@ found out the hard way we cannot share a cache with a resolving > strategy that can only do resolving. > This has been fixed on January 20th with rev 1.120: > > We can not share a cache between validating and resolving strategies. > The resolving only strategies mess up the negative cache by claiming > DNSSEC related records do not exist which confuses the validating > strategies. > Found the hard way by kn@ and analysed by otto@ > OK kn@ > > Pretty sure your issue has been resolved with that (The log you are > showing is certainly from the timeframe where the issue existed). > > It's still a bit unclear what Solene's issue was, it looks like the > dhcp provided nameserver did support dnssec in the past and then > suddenly stopped. Possibly a change at the isp. unwind failed to > detect this. I have to think about what to do about it. Maybe several recursors are behind a single IP, being loadbalanced? I have seen setups with muliple recursors from different vendors being used with different settings. In that case the client might see different result depending on the load balancing changing. -Otto > > > > > Not sure whether the first line is at all significant - I've seen > > it only three times since December. > > > > Dec 25 05:17:07 rose unwind[83579]: [83579:0] error: outgoing tcp: > > connect: Permission denied for 194.168.8.100 port 853 > > Dec 26 16:22:44 rose unwind[83579]: validation failure > > : key for validation org. is marked as invalid > > because of a
Re: unwind reports no signature or no DNSSEC
On Tue, Feb 04, 2020 at 11:41:14AM +, Raf Czlonka wrote: > On Mon, Feb 03, 2020 at 07:29:02PM GMT, Florian Obser wrote: > > On Mon, Feb 03, 2020 at 07:58:24PM +0100, Solene Rapenne wrote: > > > On Mon, Feb 03, 2020 at 07:52:29PM +0100, Florian Obser wrote: > > > > On Mon, Feb 03, 2020 at 06:16:54PM +0100, Solene Rapenne wrote: > > > > > I re-enabled unwind today (i was using append instead of prepend in > > > > > dhclient.conf) and I got a few issues resolving domains, often the > > > > > first > > > > > time, if I try again I get a result. I'm pretty sure it's not a bug, > > > > > but > > > > > I have no idea what's happening here, so maybe log output or > > > > > documentation could be enhanced. > > > > > > > > > > > > > > > From /var/log/messages (192.168.1.254 is dns from my dhcp) > > > > > > > > > > Feb 3 17:55:44 solene unwind[18044]: validation failure > > > > > : no signatures from 192.168.1.254 > > > > > for key org. while building chain of trust > > > > > Feb 3 18:05:10 solene unwind[18044]: validation failure > > > > A IN>: no DNSSEC records from 192.168.1.254 for DS google.fr. while > > > > > building chain of trust > > > > > Feb 3 18:05:18 solene unwind[18044]: validation failure > > > > A IN>: no signatures from 192.168.1.254 for DS it. while building > > > > > chain of trust > > > > > > > > > > > > > Looks like your dhcp nameserver strips DNSSEC in a weird way. > > > > Can you please show > > > > > > > > dig @192.168.1.254 +dnssec . SOA > > > > and > > > > dig @192.168.1.254 org DNSKEY > > > > > > > > -- > > > > I'm not entirely sure you are real. > > > > > > > > > > sure :) > > > > > > solene@t480 ~ $ dig @192.168.1.254 +dnssec . SOA > > > > > > ; <<>> dig 9.10.8-P1 <<>> @192.168.1.254 +dnssec . SOA > > > ; (1 server found) > > > ;; global options: +cmd > > > ;; Got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63346 > > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > > > > > ;; OPT PSEUDOSECTION: > > > ; EDNS: version: 0, flags:; udp: 4096 > > > ;; QUESTION SECTION: > > > ;. IN SOA > > > > > > ;; ANSWER SECTION: > > > . 84857 IN SOA a.root-servers.net. > > > nstld.verisign-grs.com. 2020020301 1800 900 604800 86400 > > > > > > ;; Query time: 25 msec > > > ;; SERVER: 192.168.1.254#53(192.168.1.254) > > > ;; WHEN: Mon Feb 03 19:54:35 CET 2020 > > > ;; MSG SIZE rcvd: 103 > > > > > > > for the archives: 192.168.1.254 is stripping rrsigs but unwind thinks > > dhcp is validating. This is wrong and we need to figure out why. > > > > Hi all, > > I've been having similar (the same?) issues since at least mid-to-late > December. I hadn't a chance to diagnose it properly hence sending > an email only now to confirm Solene's isn't an isolated case. > > Unlike Solene, I would have to restart unwind to get it resolving. I'm sure you had(!) a different issue than Solene. unwind correctly detects that your dhcp provided nameserver can only do resolving and strips dnssec records while the recursor can do validation. On December 18th I enabled a shared cache for negative answers in rev 1.116 of resolver.c. As kn@ found out the hard way we cannot share a cache with a resolving strategy that can only do resolving. This has been fixed on January 20th with rev 1.120: We can not share a cache between validating and resolving strategies. The resolving only strategies mess up the negative cache by claiming DNSSEC related records do not exist which confuses the validating strategies. Found the hard way by kn@ and analysed by otto@ OK kn@ Pretty sure your issue has been resolved with that (The log you are showing is certainly from the timeframe where the issue existed). It's still a bit unclear what Solene's issue was, it looks like the dhcp provided nameserver did support dnssec in the past and then suddenly stopped. Possibly a change at the isp. unwind failed to detect this. I have to think about what to do about it. > > Not sure whether the first line is at all significant - I've seen > it only three times since December. > > Dec 25 05:17:07 rose unwind[83579]: [83579:0] error: outgoing tcp: > connect: Permission denied for 194.168.8.100 port 853 > Dec 26 16:22:44 rose unwind[83579]: validation failure > : key for validation org. is marked as invalid because > of a previous validation failure : no signatures from > 194.168.8.100 for key org. while building chain of trust > Dec 26 16:22:58 rose unwind[48598]: dhcp: validation failure <. NS IN>: > no signatures from 194.168.8.100 for trust anchor . while building chain of > trust > > This is the current status of unwind (yesterday's snapshot): > > $ unwindctl status > 1. recursorvalidating, 70ms 3. dhcp resolving, > 150ms > 2. stub resolving, 70ms 4. oDoT-dhcp dead, > N/A > >
acpi prevents PCIe expansion cards to work properly
>Synopsis: acpi prevents PCIe expansion cards to work properly
>Category: kernel
>Environment:
System : OpenBSD 6.6
Details : OpenBSD 6.6-current (GENERIC.MP) #630: Tue Feb 4
06:40:24 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Latest BIOS revision flashed.
"UKC> disable acpipci" does not help.
I have to disable ACPI ("UKC> disable acpi") to make two PCIe
expansion cards work properly:
1. A card with onboard an Asmedia ASM1142 USB 3.1 Gen2
controller.
Tested alone without other expansion cards inserted in other
slots.
With ACPI enabled the devices connected to this card receive
power only for a fraction of second and then poweroff.
The controller is recognized by the kernel (also if with another
name) but not the devices connected to it.
With ACPI disabled everything works perfectly.
2. A card with onboard a Marvel 88SE9128 SATA controller.
Tested alone without other expansion cards inserted in other
slots.
With ACPI enabled every operation on a disk connected to this
card requires an insane amount of time.
If boot OpenBSD from a disk connected to this card the boot has
some blockages in these two points making impossible to complete
the boot and login:
acpitz0: _AL0[0] _PR0 failed
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
>HERE THE BOOT IS BLOCKED FOR ABOUT 15-30 MINUTES<
root on sd0a (e185b01615c54900.a) swap on sd0b dump on sd0b
>HERE THE BOOT IS VIRTUALLY BLOCKED PERMANENTLY<
(Probably the boot is not really blocked permanently but
are necessary an insane amount of hours to mount all the
partitions and do every other disk operation.)
Instead if boot OpenBSD from a disk connected to an IDE port
of the motherboard, with another disk connected to the PCIe
SATA card, the boot has only one blockage and after that the
boot complete normally and it is possible to login:
acpitz0: _AL0[0] _PR0 failed
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
>HERE THE BOOT IS BLOCKED FOR ABOUT 15-30 MINUTES<
root on wd0a (70ee382dd05141e0.a) swap on wd0b dump on wd0b
After that everything works well except operations on the disk
connected to the PCIe SATA card, operations on this disk such as
"disklabel sd0" need many minutes to give an output.
In /etc/fstab there are not entries about "sd0" partitions,
otherwise should expect also in this second configuration more
than one blockage.
Instead without a disk connected to the PCIe SATA card the
system boot smoothly without blockages.
To make everything works perfectly without any blockage with a
disk connected to the PCIe SATA card it is necessary to disable
ACPI.
>How-To-Repeat:
Connect a device to a PCIe expansion card with ACPI enabled.
>Fix:
Unknown.
dmesg:
OpenBSD 6.6-current (GENERIC.MP) #630: Tue Feb 4 06:40:24 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8303607808 (7918MB)
avail mem = 8039473152 (7667MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf (67 entries)
bios0: vendor Phoenix Technologies, LTD version "ASUS M2NPV-VM ACPI BIOS
Revision 5005" date 06/02/2010
bios0: ASUSTek Computer INC. M2NPV-VM
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP MCFG APIC
acpi0: wakeup devices HUB0(S5) XVRA(S5) XVRB(S5) XVRC(S5) UAR1(S5) UAR2(S5)
PS2M(S4) PS2K(S4) USB0(S4) USB2(S4) AZAD(S5) MMAC(S5) MMCI(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II X2 B28 Processor, 3407.61 MHz, 10-06-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
Re: umb device no longer detected
Hmmm. I got mine used off an auction site but unfortunately updated the firmware before installing OpenBSD on this machine. No help there, sorry. Though the latest firmware wasn't all that recent IIRC. Not made any other changes to it apart from that though. Happy to help out with any testing etc. if needed. On Wed, Feb 05, 2020 at 05:55:41AM -0700, Theo de Raadt wrote: > Well, I have been given this particilular MC7700 which works as umsm, > but it does *NOT* match as umb, probably because it's firmware is too > old? Or it is in the wrong mode, I can't tell. > > The alternative is that the device cannot attach at all. > > How does this get resolved? I can dig it up and show in a few days. >
Re: umb device no longer detected
On Wed, 05 Feb 2020 05:55:41 -0700 "Theo de Raadt" wrote: > Well, I have been given this particilular MC7700 which works as umsm, > but it does *NOT* match as umb, probably because it's firmware is too > old? Or it is in the wrong mode, I can't tell. The current mode can be queried with AT!UDUSBCOMP? And AT!UDUSBCOMP=? should give a list of supported interface compositions. My guess is that the device is in a mode that offers multiple interfaces. And MBIM is on config #2. Since umsm now matches on config #1, usbd_probe_and_attach() stops here and never probes config #2 (like it did before). It would be interesting if config #2 offers an AT-interfac (umsm), too. In that case umsm and umb could coexist. Gerhard > The alternative is that the device cannot attach at all. > > How does this get resolved? I can dig it up and show in a few days. > > Gerhard Roth wrote: > > > On Wed, 5 Feb 2020 19:54:01 +0900 leeb wrote: > > > >Synopsis:umb device no longer detected > > > >Category:kernel > > > >Environment: > > > System : OpenBSD 6.6 > > > Details : OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 > > > JST 2020 > > > > > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > > > > > Architecture: OpenBSD.amd64 > > > Machine : amd64 > > > >Description: > > > Before reworking my umb authentication patches I upgraded > > > my -current, and found that the LTE modem was no longer > > > detected as a umb device. It seems to be picked up later > > > in the boot via umsm, but I don't think that should be > > > happening. > > > > That comes from https://marc.info/?l=openbsd-cvs=157878261716342=2 > > > > It's not that 'umsm picks up the device later', it's just that > > umsm_match() [UMATCH_VENDOR_IFACESUBCLASS] now wins over umb_match() > > [UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO]. > > > > Gerhard > > > > > > > > I happened to have an older working -current kernel saved, > > > so tried booting from that - the umb device is detected OK. > > > > > > To eliminate the possibility of a mistake on my part, I > > > swapped disks in this machine and installed a fresh current > > > snapshot. Same result. I've attached below the sendbug > > > outputs from both the working (old) kernel, and the new > > > (not working) kernel. > > > > > > I installed the clean -current from an image at: > > > ftp.jaist.ac.jp in /OpenBSD/snapshots/amd64/install66.fs > > > > > > Ran 'sysupgrade -s' on the new install to make sure I was > > > up-to-date. > > > > > > >How-To-Repeat: > > > Install or upgrade to latest snapshot on a machine with a > > > umb device. > > > > > > ** sendbug -P output from OK kernel * > > > > > > dmesg: > > > OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 JST 2020 > > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > > real mem = 16972566528 (16186MB) > > > avail mem = 16445722624 (15683MB) > > > mpath0 at root > > > scsibus0 at mpath0: 256 targets > > > mainbus0 at root > > > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) > > > bios0: vendor LENOVO version "G2ET92WW (2.52 )" date 02/22/2013 > > > bios0: LENOVO 23061Q2 > > > acpi0 at bios0: ACPI 5.0 > > > acpi0: sleep states S0 S3 S4 S5 > > > acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT > > > ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2 BGRT > > > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) > > > EHC1(S3) EHC2(S3) HDEF(S4) > > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > > acpihpet0 at acpi0: 14318179 Hz > > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > > cpu0 at mainbus0: apid 0 (boot processor) > > > cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.78 MHz, 06-3a-09 > > > cpu0: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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.1.2, IBE > > > cpu1 at mainbus0: apid 1 (application processor) > > > cpu1: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 > > > cpu1: > > >
Re: umb device no longer detected
Well, I have been given this particilular MC7700 which works as umsm, but it does *NOT* match as umb, probably because it's firmware is too old? Or it is in the wrong mode, I can't tell. The alternative is that the device cannot attach at all. How does this get resolved? I can dig it up and show in a few days. Gerhard Roth wrote: > On Wed, 5 Feb 2020 19:54:01 +0900 leeb wrote: > > >Synopsis: umb device no longer detected > > >Category: kernel > > >Environment: > > System : OpenBSD 6.6 > > Details : OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 > > JST 2020 > > > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > Before reworking my umb authentication patches I upgraded > > my -current, and found that the LTE modem was no longer > > detected as a umb device. It seems to be picked up later > > in the boot via umsm, but I don't think that should be > > happening. > > That comes from https://marc.info/?l=openbsd-cvs=157878261716342=2 > > It's not that 'umsm picks up the device later', it's just that > umsm_match() [UMATCH_VENDOR_IFACESUBCLASS] now wins over umb_match() > [UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO]. > > Gerhard > > > > > I happened to have an older working -current kernel saved, > > so tried booting from that - the umb device is detected OK. > > > > To eliminate the possibility of a mistake on my part, I > > swapped disks in this machine and installed a fresh current > > snapshot. Same result. I've attached below the sendbug > > outputs from both the working (old) kernel, and the new > > (not working) kernel. > > > > I installed the clean -current from an image at: > > ftp.jaist.ac.jp in /OpenBSD/snapshots/amd64/install66.fs > > > > Ran 'sysupgrade -s' on the new install to make sure I was > > up-to-date. > > > > >How-To-Repeat: > > Install or upgrade to latest snapshot on a machine with a > > umb device. > > > > ** sendbug -P output from OK kernel * > > > > dmesg: > > OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 JST 2020 > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > real mem = 16972566528 (16186MB) > > avail mem = 16445722624 (15683MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) > > bios0: vendor LENOVO version "G2ET92WW (2.52 )" date 02/22/2013 > > bios0: LENOVO 23061Q2 > > acpi0 at bios0: ACPI 5.0 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT > > ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2 BGRT > > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) > > EHC2(S3) HDEF(S4) > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpihpet0 at acpi0: 14318179 Hz > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.78 MHz, 06-3a-09 > > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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.1.2, IBE > > cpu1 at mainbus0: apid 1 (application processor) > > cpu1: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 > > cpu1: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i3-3120M CPU @ 2.50GHz, 2494.36 MHz, 06-3a-09 > > cpu2: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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:
Re: umb device no longer detected
On Wed, 5 Feb 2020 19:54:01 +0900 leeb wrote: > >Synopsis:umb device no longer detected > >Category:kernel > >Environment: > System : OpenBSD 6.6 > Details : OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 > JST 2020 > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > Before reworking my umb authentication patches I upgraded > my -current, and found that the LTE modem was no longer > detected as a umb device. It seems to be picked up later > in the boot via umsm, but I don't think that should be > happening. That comes from https://marc.info/?l=openbsd-cvs=157878261716342=2 It's not that 'umsm picks up the device later', it's just that umsm_match() [UMATCH_VENDOR_IFACESUBCLASS] now wins over umb_match() [UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO]. Gerhard > > I happened to have an older working -current kernel saved, > so tried booting from that - the umb device is detected OK. > > To eliminate the possibility of a mistake on my part, I > swapped disks in this machine and installed a fresh current > snapshot. Same result. I've attached below the sendbug > outputs from both the working (old) kernel, and the new > (not working) kernel. > > I installed the clean -current from an image at: > ftp.jaist.ac.jp in /OpenBSD/snapshots/amd64/install66.fs > > Ran 'sysupgrade -s' on the new install to make sure I was > up-to-date. > > >How-To-Repeat: > Install or upgrade to latest snapshot on a machine with a > umb device. > > ** sendbug -P output from OK kernel * > > dmesg: > OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 JST 2020 > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > real mem = 16972566528 (16186MB) > avail mem = 16445722624 (15683MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) > bios0: vendor LENOVO version "G2ET92WW (2.52 )" date 02/22/2013 > bios0: LENOVO 23061Q2 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT > ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2 BGRT > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) > EHC2(S3) HDEF(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.78 MHz, 06-3a-09 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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.1.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i3-3120M CPU @ 2.50GHz, 2494.36 MHz, 06-3a-09 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3:
umb device no longer detected
>Synopsis: umb device no longer detected >Category: kernel >Environment: System : OpenBSD 6.6 Details : OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 JST 2020 lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: Before reworking my umb authentication patches I upgraded my -current, and found that the LTE modem was no longer detected as a umb device. It seems to be picked up later in the boot via umsm, but I don't think that should be happening. I happened to have an older working -current kernel saved, so tried booting from that - the umb device is detected OK. To eliminate the possibility of a mistake on my part, I swapped disks in this machine and installed a fresh current snapshot. Same result. I've attached below the sendbug outputs from both the working (old) kernel, and the new (not working) kernel. I installed the clean -current from an image at: ftp.jaist.ac.jp in /OpenBSD/snapshots/amd64/install66.fs Ran 'sysupgrade -s' on the new install to make sure I was up-to-date. >How-To-Repeat: Install or upgrade to latest snapshot on a machine with a umb device. ** sendbug -P output from OK kernel * dmesg: OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 JST 2020 lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP real mem = 16972566528 (16186MB) avail mem = 16445722624 (15683MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) bios0: vendor LENOVO version "G2ET92WW (2.52 )" date 02/22/2013 bios0: LENOVO 23061Q2 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2 BGRT acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.78 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i3-3120M CPU @ 2.50GHz, 2494.36 MHz, 06-3a-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 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 4 (EXP3) acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(350@80 mwait.1@0x20),
