Re: iwm0: fatal firmware error
Marco Scholz [t...@disroot.org] wrote:
> Hello.
> My laptop (Lenovo Thinkpad T495s AMD Ryzen) reports an iwm0 fatal
> firmware error. I'm running 6.9 #29.
> System gets quite hot, systat shows 40-50% interrupt while idling.
> Networking works fine.
>
> Anybody else has this issue?
>
> Regards, Marco.
>
> ehci0 at pci3 dev 0 function 4 "Realtek RealManage USB" rev 0x0e: apic
> 33 int 15
> ehci0: pre-2.0 USB rev
It probably won't help your actual problem, but for EHCI support,
you'll need this patch I still have hanging around in my tree.
Index: ehci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ehci_pci.c,v
retrieving revision 1.31
diff -u -p -u -r1.31 ehci_pci.c
--- ehci_pci.c 2 May 2019 20:28:46 - 1.31
+++ ehci_pci.c 28 May 2021 22:03:49 -
@@ -186,9 +186,14 @@ ehci_pci_attach(struct device *parent, s
case PCI_USBREV_PRE_1_0:
case PCI_USBREV_1_0:
case PCI_USBREV_1_1:
- sc->sc.sc_bus.usbrev = USBREV_UNKNOWN;
- printf("%s: pre-2.0 USB rev\n", devname);
- goto disestablish_ret;
+ /*
+* NOTE: some EHCI USB controllers have the wrong USB
+* revision number. It appears those controllers are
+* fully compliant so we just ignore this value.
+*/
+ printf("%s: pre-2.0 USB rev (ignored)\n", devname);
+ /* FALLTHROUGH */
case PCI_USBREV_2_0:
sc->sc.sc_bus.usbrev = USBREV_2_0;
break;
Re: iwm0: fatal firmware error
On Mon, May 24, 2021 at 02:35:02PM +0200, Marco Scholz wrote: > Hello. > My laptop (Lenovo Thinkpad T495s AMD Ryzen) reports an iwm0 fatal > firmware error. I'm running 6.9 #29. > System gets quite hot, systat shows 40-50% interrupt while idling. > Networking works fine. > > Anybody else has this issue? This looks like a known issue. I hope to get it fixed eventually but for now there other changes we need to make with higher priority (i.e. we need fimware updates for fragattack security fixes).
iwm0: fatal firmware error
Hello. My laptop (Lenovo Thinkpad T495s AMD Ryzen) reports an iwm0 fatal firmware error. I'm running 6.9 #29. System gets quite hot, systat shows 40-50% interrupt while idling. Networking works fine. Anybody else has this issue? Regards, Marco. OpenBSD 6.9-current (GENERIC.MP) #29: Fri May 21 13:20:08 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6334730240 (6041MB) avail mem = 6127292416 (5843MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc025000 (63 entries) bios0: vendor LENOVO version "R13ET27W(1.01 )" date 04/18/2019 bios0: LENOVO 20QJ000AUS acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT MSDM SLIC BATB HPET APIC MCFG SBST WSMT VFCT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI 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 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.35 MHz, 17-18-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.08 MHz, 17-18-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: disabling user TSC (skew=-2613216764) cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.08 MHz, 17-18-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: disabling user TSC (skew=-2613216711) cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.08 MHz, 17-18-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu3: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: disabling user TSC (skew=-2613216774) cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.08 MHz, 17-18-01 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
Re: iwm0: fatal firmware error on Dell Latitude E5570
On 24 Sep 12:24, Jan Stary wrote: > On Sep 24 11:36:24, h...@stare.cz wrote: > > This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below). > > iwm stopped working, saying > > > > iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08 > > iwm0: fatal firmware error > > iwm0: could not remove MAC context (error 35) > > iwm0: fatal firmware error > > iwm0: could not remove MAC context (error 35) > > iwm0: fatal firmware error > > iwm0: could not remove MAC context (error 35) > > [etc] > > > > This is after sysupgrade and a fw_update. > > Is anyone seeing the same? > > > > Last changes to sys/dev/pci/*iwm* are months ago, > > and I have seen it work this week ... > > After recompiling current, everything works again. Note that > it's GENERIC.MP now, as opposed to GENERIC installed by the sysupgrade. > (Can that be related to a iwm error?) > > Jan > Hi Jan, I have a similiar problem when using sysupgrade on Dell 7400 and on one Dell 7280 - installer switches to bsd.sp. I tried to debug that but when I boot into ramdisk it properly detects MP cpu. Checked that several times. I have another 7280 with exact the same config (dd'ed the hd) where it doesn't happen. That's strange. -- wq: ~uw
Re: iwm0: fatal firmware error on Dell Latitude E5570
Uwe Werler wrote: > On 24 Sep 12:24, Jan Stary wrote: > > On Sep 24 11:36:24, h...@stare.cz wrote: > > > This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below). > > > iwm stopped working, saying > > > > > > iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08 > > > iwm0: fatal firmware error > > > iwm0: could not remove MAC context (error 35) > > > iwm0: fatal firmware error > > > iwm0: could not remove MAC context (error 35) > > > iwm0: fatal firmware error > > > iwm0: could not remove MAC context (error 35) > > > [etc] > > > > > > This is after sysupgrade and a fw_update. > > > Is anyone seeing the same? > > > > > > Last changes to sys/dev/pci/*iwm* are months ago, > > > and I have seen it work this week ... > > > > After recompiling current, everything works again. Note that > > it's GENERIC.MP now, as opposed to GENERIC installed by the sysupgrade. > > (Can that be related to a iwm error?) > > > > Jan > > > > Hi Jan, > > I have a similiar problem when using sysupgrade on Dell 7400 and on one Dell > 7280 - installer switches to bsd.sp. I tried to debug that but when I boot > into ramdisk it properly detects MP cpu. Checked that several times. I have > another 7280 with exact the same config (dd'ed the hd) where it doesn't > happen. That's strange. I think kernel random relinking and other address space randomization is exposing either an uninitialized variable or alignment attribute the chip wants but the driver doesn't satisfy.
Re: iwm0: fatal firmware error on Dell Latitude E5570
On 2020-09-24, Jan Stary wrote: > This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below). > iwm stopped working, saying > > iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08 > iwm0: fatal firmware error > iwm0: could not remove MAC context (error 35) I've been getting a lot of those lately, but my iwm keeps recovering from them eventually. Frankly, I've mostly stopped paying attention. I update my laptop every other week or so, and the reliability of wi-fi keeps fluctuating from kernel to kernel, sometimes it's better, sometimes it's worse, and I don't think it correlates well with commits or firmware updates. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: iwm0: fatal firmware error on Dell Latitude E5570
On Sep 24 11:36:24, h...@stare.cz wrote: > This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below). > iwm stopped working, saying > > iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08 > iwm0: fatal firmware error > iwm0: could not remove MAC context (error 35) > iwm0: fatal firmware error > iwm0: could not remove MAC context (error 35) > iwm0: fatal firmware error > iwm0: could not remove MAC context (error 35) > [etc] > > This is after sysupgrade and a fw_update. > Is anyone seeing the same? > > Last changes to sys/dev/pci/*iwm* are months ago, > and I have seen it work this week ... After recompiling current, everything works again. Note that it's GENERIC.MP now, as opposed to GENERIC installed by the sysupgrade. (Can that be related to a iwm error?) Jan OpenBSD 6.8-beta (GENERIC.MP) #0: Thu Sep 24 12:15:13 CEST 2020 h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16810315776 (16031MB) avail mem = 16285798400 (15531MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeac10 (107 entries) bios0: vendor Dell Inc. version "1.5.0" date 04/22/2016 bios0: Dell Inc. Latitude E5570 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP DBG2 SSDT UEFI SSDT SSDT SLIC ASF! acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(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-6440HQ CPU @ 2.60GHz, 2295.26 MHz, 06-5e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 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-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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) i5-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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) i5-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acp
iwm0: fatal firmware error on Dell Latitude E5570
This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below). iwm stopped working, saying iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08 iwm0: fatal firmware error iwm0: could not remove MAC context (error 35) iwm0: fatal firmware error iwm0: could not remove MAC context (error 35) iwm0: fatal firmware error iwm0: could not remove MAC context (error 35) [etc] This is after sysupgrade and a fw_update. Is anyone seeing the same? Last changes to sys/dev/pci/*iwm* are months ago, and I have seen it work this week ... Jan OpenBSD 6.8-beta (GENERIC) #76: Wed Sep 23 15:23:23 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 16810315776 (16031MB) avail mem = 16285892608 (15531MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeac10 (107 entries) bios0: vendor Dell Inc. version "1.5.0" date 04/22/2016 bios0: Dell Inc. Latitude E5570 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP DBG2 SSDT UEFI SSDT SSDT SLIC ASF! acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(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-6440HQ CPU @ 2.60GHz, 2295.52 MHz, 06-5e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 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 2 (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 (RP14) acpiprt22 at acpi0: bus -1 (RP15) acpiprt23 at acpi0: bus -1 (RP16) acpiec0 at acpi0 acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 extent `acpipci0 pcibus' (0x0 - 0xff), flags=0 0x7f - 0xff extent `acpipci0 pciio' (0x0 - 0x), flags=0 0xcf8 - 0xcff 0x1 - 0x extent `acpipci0 pcimem' (0x0 - 0x), flags=0 0x0 - 0x9 0xc - 0xafff 0xf000 - 0xfcff 0xfe80 - 0x acpicmos0 at acpi0 "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "SMO8810" at acpi0 not configured "INT3403" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT33A1" at acpi0 not configured "PNP0C14" at acpi0 not configured acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model "DELL 7V69Y53" serial 2106 type LiP oem "SMP" "DELLABC6" at acpi0 not configured "DELLABCE" at acpi0 not configured "INT3400" at acpi0 not configured acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PG00, resource for PEG0 acpipwrres1 at acpi0: PG01, resource for PEG1 acpipwrres2 at acpi0: PG02, resource for PEG2 acpipwrres3 at acpi0: WRST acpipwrres4 at acpi0: WRST acpipwrres5 at acpi0: WRST acpipwrres6 at acpi0: WRST acpipwrres7 at acpi0: WRST acpipwrres8 at acpi0: WRST acpipwrres9 at acpi0: WRST acpipwrres10 at acpi0: WRST acpipwrres11 at acpi0: WRST acpipwrres12 at acpi0: WRST acp
Re: iwm0: fatal firmware error / could not initiate scan
On Mon, 4 May 2015, Maximilian Pichler wrote: From: Maximilian Pichler maxim.pich...@gmail.com To: misc@openbsd.org Date: Mon, 4 May 2015 06:19:13 Subject: iwm0: fatal firmware error / could not initiate scan I'm getting these console errors on startup and each time I run ifconfig iwm0 scan: iwm0: fatal firmware error iwm0: could not initiate scan Not sure how to diagnose the problem better. I tried rebooting, but to no avail. Full dmesg below. ... iwm0: hw rev: 0x140, fw ver 25.228 (API ver 9), address f8:16:54:dd:a7:0c iwm0: fatal firmware error iwm0: could not initiate scan Don't have an iwm interface. But is the firmware installed? Is the following thread of any use: http://openbsd-archive.7691.n7.nabble.com/iwm0-fatal-firmware-error-on-current-td267434.html -- Dennis Davis dennisda...@fastmail.fm
Re: iwm0: fatal firmware error / could not initiate scan
On Mon, May 04, 2015 at 08:56:08AM +0100, Dennis Davis wrote:
iwm0: hw rev: 0x140, fw ver 25.228 (API ver 9), address f8:16:54:dd:a7:0c
iwm0: fatal firmware error
iwm0: could not initiate scan
Don't have an iwm interface. But is the firmware installed?
Yes, the firmware is installed at version 25.228 as shown by
the text you quoted ;-)
Is the following thread of any use:
http://openbsd-archive.7691.n7.nabble.com/iwm0-fatal-firmware-error-on-current-td267434.html
That might be it. Maximilian, can you please try this patch which was
committed by jsg@ in r1.39 of if_iwm.c? This fix went in after 5.7.
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -p -u -r1.38 -r1.39
--- if_iwm.c16 Mar 2015 04:09:53 - 1.38
+++ if_iwm.c23 Mar 2015 00:35:19 - 1.39
@@ -5471,7 +5471,8 @@ iwm_endscan_cb(void *arg)
DPRINTF((scan ended\n));
- if (sc-sc_scanband == IEEE80211_CHAN_2GHZ) {
+ if (sc-sc_scanband == IEEE80211_CHAN_2GHZ
+ sc-sc_nvm.sku_cap_band_52GHz_enable) {
int error;
done = 0;
if ((error = iwm_mvm_scan_request(sc,
@@ -6409,6 +6410,11 @@ iwm_preinit(struct iwm_softc *sc)
IWM_UCODE_MINOR(sc-sc_fwver),
IWM_UCODE_API(sc-sc_fwver),
ether_sprintf(sc-sc_nvm.hw_addr));
+
+ /* not all hardware can do 5GHz band */
+ if (!sc-sc_nvm.sku_cap_band_52GHz_enable)
+ memset(ic-ic_sup_rates[IEEE80211_MODE_11A], 0,
+ sizeof(ic-ic_sup_rates[IEEE80211_MODE_11A]));
/* Reattach net80211 so MAC address and channel map are picked up. */
ieee80211_ifdetach(ifp);
Re: iwm0: fatal firmware error / could not initiate scan
On Mon, May 4, 2015 at 6:10 AM, Stefan Sperling s...@stsp.name wrote: Is the following thread of any use: http://openbsd-archive.7691.n7.nabble.com/iwm0-fatal-firmware-error-on-current-td267434.html That might be it. Maximilian, can you please try this patch which was committed by jsg@ in r1.39 of if_iwm.c? This fix went in after 5.7. That did it, with the patch it's working now. Thanks!
iwm0: fatal firmware error / could not initiate scan
Hi, I'm getting these console errors on startup and each time I run ifconfig iwm0 scan: iwm0: fatal firmware error iwm0: could not initiate scan Not sure how to diagnose the problem better. I tried rebooting, but to no avail. Full dmesg below. Best, Max OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17088098304 (16296MB) avail mem = 16629297152 (15858MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec170 (84 entries) bios0: vendor Intel Corp. version WYLPT10H.86A.0030.2014.0919.1139 date 09/19/2014 bios0: Intel Corporation D54250WYK acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT MCFG HPET SSDT SSDT DMAR CSRT acpi0: wakeup devices PS2K(S3) PS2M(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] 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-4250U CPU @ 1.30GHz, 2295.06 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID 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, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz, 2294.69 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID 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-4250U CPU @ 1.30GHz, 2294.69 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID 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-4250U CPU @ 1.30GHz, 2294.69 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus -1 (PEG0) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1, PSS acpicpu2 at acpi0: C2, C1, PSS acpicpu3 at acpi0: C2, C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 2295 MHz: speeds: 1901, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 779 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 4G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel HD Graphics 5000 rev 0x09 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10 inteldrm0: 2560x1440 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 3 function 0 Intel Core 4G HD Audio rev 0x09: msi azalia0: No codecs found xhci0 at pci0 dev 20 function 0
Re: iwm0: fatal firmware error on -current
On Sun, Mar 22, 2015 at 06:49:33AM -0400, Ted Unangst wrote: Jonathan Gray wrote: On Sun, Mar 22, 2015 at 09:16:08AM +0100, Stefan Sperling wrote: If the firmare image is not present at boot, no interface is created. After installing the firmware with fw_update (which succeeds because it looks for iwm in dmesg not ifconfig) there is no way to recover the interface without a reboot because 'ifconfig iwm0' doesn't work. If the mac address and the supported 802.11 modes depend on having the firmware loaded, is it really worth adding a interface that allows invalid parameters to be set? Maybe? See above. If I don't have firmware when I boot, but install firmware later, the interface should still be useable. Putting the interface into a must reboot state should be considered a bug. I'd be surprised if the 802.11 reattach doesn't cause problems... Anyway here is the minimal version diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c index 6072e6a..58a50d4 100644 --- sys/dev/pci/if_iwm.c +++ sys/dev/pci/if_iwm.c @@ -6410,6 +6410,11 @@ iwm_preinit(struct iwm_softc *sc) IWM_UCODE_API(sc-sc_fwver), ether_sprintf(sc-sc_nvm.hw_addr)); + /* not all hardware can do 5GHz band */ + if (!sc-sc_nvm.sku_cap_band_52GHz_enable) + memset(ic-ic_sup_rates[IEEE80211_MODE_11A], 0, + sizeof(ic-ic_sup_rates[IEEE80211_MODE_11A])); + /* Reattach net80211 so MAC address and channel map are picked up. */ ieee80211_ifdetach(ifp); ieee80211_ifattach(ifp);
Re: iwm0: fatal firmware error on -current
On Sun, Mar 22, 2015 at 01:45:45PM +1100, Jonathan Gray wrote:
Try the following.
This diff re-introduces an unrelated problem fixed in r1.7.
Interface attachment is moved back to the attach-hook, and the driver
tries to load the firmware from disk before creating an interface.
If the firmare image is not present at boot, no interface is created.
After installing the firmware with fw_update (which succeeds because
it looks for iwm in dmesg not ifconfig) there is no way to recover
the interface without a reboot because 'ifconfig iwm0' doesn't work.
# ifconfig iwm0 down up
ifconfig: SIOCGIFFLAGS: Device not configured
# ifconfig iwm0
iwm0: no such interface
The only other driver I'm aware of that does this is athn(4) on USB.
However, in that case the USB device can simply be re-plugged to force
the entire attach procedure to run again.
diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c
index 6072e6a..3bec032 100644
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -6410,8 +6410,38 @@ iwm_preinit(struct iwm_softc *sc)
IWM_UCODE_API(sc-sc_fwver),
ether_sprintf(sc-sc_nvm.hw_addr));
- /* Reattach net80211 so MAC address and channel map are picked up. */
- ieee80211_ifdetach(ifp);
+ ic-ic_phytype = IEEE80211_T_OFDM; /* not only, but not used */
+ ic-ic_opmode = IEEE80211_M_STA;/* default to BSS mode */
+ ic-ic_state = IEEE80211_S_INIT;
+
+ /* Set device capabilities. */
+ ic-ic_caps =
+ IEEE80211_C_WEP | /* WEP */
+ IEEE80211_C_RSN | /* WPA/RSN */
+ IEEE80211_C_SCANALL | /* device scans all channels at once */
+ IEEE80211_C_SHSLOT |/* short slot time supported */
+ IEEE80211_C_SHPREAMBLE; /* short preamble supported */
+
+ if (sc-sc_nvm.sku_cap_band_52GHz_enable)
+ ic-ic_sup_rates[IEEE80211_MODE_11A] =
ieee80211_std_rateset_11a;
+ ic-ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
+ ic-ic_sup_rates[IEEE80211_MODE_11G] = ieee80211_std_rateset_11g;
+
+ /* IBSS channel undefined for now. */
+ ic-ic_ibss_chan = ic-ic_channels[1];
+
+ /* Max RSSI */
+ ic-ic_max_rssi = IWM_MAX_DBM - IWM_MIN_DBM;
+
+ ifp-if_softc = sc;
+ ifp-if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
+ ifp-if_ioctl = iwm_ioctl;
+ ifp-if_start = iwm_start;
+ ifp-if_watchdog = iwm_watchdog;
+ IFQ_SET_READY(ifp-if_snd);
+ memcpy(ifp-if_xname, DEVNAME(sc), IFNAMSIZ);
+
+ if_attach(ifp);
ieee80211_ifattach(ifp);
ic-ic_node_alloc = iwm_node_alloc;
@@ -6421,6 +6451,12 @@ iwm_preinit(struct iwm_softc *sc)
ic-ic_newstate = iwm_newstate;
ieee80211_media_init(ifp, iwm_media_change, ieee80211_media_status);
+#if NBPFILTER 0
+ iwm_radiotap_attach(sc);
+#endif
+ timeout_set(sc-sc_calib_to, iwm_calib_timeout, sc);
+ task_set(sc-init_task, iwm_init_task, sc);
+
return 0;
}
@@ -6441,8 +6477,6 @@ iwm_attach(struct device *parent, struct device *self,
void *aux)
struct pci_attach_args *pa = aux;
pci_intr_handle_t ih;
pcireg_t reg, memtype;
- struct ieee80211com *ic = sc-sc_ic;
- struct ifnet *ifp = ic-ic_if;
const char *intrstr;
int error;
int txq_i, i;
@@ -6592,22 +6626,6 @@ iwm_attach(struct device *parent, struct device *self,
void *aux)
/* Clear pending interrupts. */
IWM_WRITE(sc, IWM_CSR_INT, 0x);
- ic-ic_phytype = IEEE80211_T_OFDM; /* not only, but not used */
- ic-ic_opmode = IEEE80211_M_STA;/* default to BSS mode */
- ic-ic_state = IEEE80211_S_INIT;
-
- /* Set device capabilities. */
- ic-ic_caps =
- IEEE80211_C_WEP | /* WEP */
- IEEE80211_C_RSN | /* WPA/RSN */
- IEEE80211_C_SCANALL | /* device scans all channels at once */
- IEEE80211_C_SHSLOT |/* short slot time supported */
- IEEE80211_C_SHPREAMBLE; /* short preamble supported */
-
- ic-ic_sup_rates[IEEE80211_MODE_11A] = ieee80211_std_rateset_11a;
- ic-ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
- ic-ic_sup_rates[IEEE80211_MODE_11G] = ieee80211_std_rateset_11g;
-
for (i = 0; i nitems(sc-sc_phyctxt); i++) {
sc-sc_phyctxt[i].id = i;
}
@@ -6615,30 +6633,6 @@ iwm_attach(struct device *parent, struct device *self,
void *aux)
sc-sc_amrr.amrr_min_success_threshold = 1;
sc-sc_amrr.amrr_max_success_threshold = 15;
- /* IBSS channel undefined for now. */
- ic-ic_ibss_chan = ic-ic_channels[1];
-
- /* Max RSSI */
- ic-ic_max_rssi = IWM_MAX_DBM - IWM_MIN_DBM;
-
- ifp-if_softc = sc;
- ifp-if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
- ifp-if_ioctl = iwm_ioctl;
- ifp-if_start = iwm_start;
- ifp-if_watchdog =
Re: iwm0: fatal firmware error on -current
Jonathan Gray wrote: On Sun, Mar 22, 2015 at 09:16:08AM +0100, Stefan Sperling wrote: If the firmare image is not present at boot, no interface is created. After installing the firmware with fw_update (which succeeds because it looks for iwm in dmesg not ifconfig) there is no way to recover the interface without a reboot because 'ifconfig iwm0' doesn't work. If the mac address and the supported 802.11 modes depend on having the firmware loaded, is it really worth adding a interface that allows invalid parameters to be set? Maybe? See above. If I don't have firmware when I boot, but install firmware later, the interface should still be useable. Putting the interface into a must reboot state should be considered a bug.
Re: iwm0: fatal firmware error on -current
On Sun, Mar 22, 2015 at 09:16:08AM +0100, Stefan Sperling wrote:
On Sun, Mar 22, 2015 at 01:45:45PM +1100, Jonathan Gray wrote:
Try the following.
This diff re-introduces an unrelated problem fixed in r1.7.
Interface attachment is moved back to the attach-hook, and the driver
tries to load the firmware from disk before creating an interface.
If the firmare image is not present at boot, no interface is created.
After installing the firmware with fw_update (which succeeds because
it looks for iwm in dmesg not ifconfig) there is no way to recover
the interface without a reboot because 'ifconfig iwm0' doesn't work.
# ifconfig iwm0 down up
ifconfig: SIOCGIFFLAGS: Device not configured
# ifconfig iwm0
iwm0: no such interface
The only other driver I'm aware of that does this is athn(4) on USB.
However, in that case the USB device can simply be re-plugged to force
the entire attach procedure to run again.
Plenty of drivers do the interface attach in the hook.
zyd(4), otus(4), atu(4), upgt(4), kue(4), ral(4), bnx(4), myx(4), txp(4)...
I can't think of anything that tries to detach/reattach
the interface so it can be used to load firmware on interface up.
If the mac address and the supported 802.11 modes depend on
having the firmware loaded, is it really worth adding a
interface that allows invalid parameters to be set?
diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c
index 6072e6a..3bec032 100644
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -6410,8 +6410,38 @@ iwm_preinit(struct iwm_softc *sc)
IWM_UCODE_API(sc-sc_fwver),
ether_sprintf(sc-sc_nvm.hw_addr));
- /* Reattach net80211 so MAC address and channel map are picked up. */
- ieee80211_ifdetach(ifp);
+ ic-ic_phytype = IEEE80211_T_OFDM; /* not only, but not used */
+ ic-ic_opmode = IEEE80211_M_STA;/* default to BSS mode */
+ ic-ic_state = IEEE80211_S_INIT;
+
+ /* Set device capabilities. */
+ ic-ic_caps =
+ IEEE80211_C_WEP | /* WEP */
+ IEEE80211_C_RSN | /* WPA/RSN */
+ IEEE80211_C_SCANALL | /* device scans all channels at once */
+ IEEE80211_C_SHSLOT |/* short slot time supported */
+ IEEE80211_C_SHPREAMBLE; /* short preamble supported */
+
+ if (sc-sc_nvm.sku_cap_band_52GHz_enable)
+ ic-ic_sup_rates[IEEE80211_MODE_11A] =
ieee80211_std_rateset_11a;
+ ic-ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
+ ic-ic_sup_rates[IEEE80211_MODE_11G] = ieee80211_std_rateset_11g;
+
+ /* IBSS channel undefined for now. */
+ ic-ic_ibss_chan = ic-ic_channels[1];
+
+ /* Max RSSI */
+ ic-ic_max_rssi = IWM_MAX_DBM - IWM_MIN_DBM;
+
+ ifp-if_softc = sc;
+ ifp-if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
+ ifp-if_ioctl = iwm_ioctl;
+ ifp-if_start = iwm_start;
+ ifp-if_watchdog = iwm_watchdog;
+ IFQ_SET_READY(ifp-if_snd);
+ memcpy(ifp-if_xname, DEVNAME(sc), IFNAMSIZ);
+
+ if_attach(ifp);
ieee80211_ifattach(ifp);
ic-ic_node_alloc = iwm_node_alloc;
@@ -6421,6 +6451,12 @@ iwm_preinit(struct iwm_softc *sc)
ic-ic_newstate = iwm_newstate;
ieee80211_media_init(ifp, iwm_media_change, ieee80211_media_status);
+#if NBPFILTER 0
+ iwm_radiotap_attach(sc);
+#endif
+ timeout_set(sc-sc_calib_to, iwm_calib_timeout, sc);
+ task_set(sc-init_task, iwm_init_task, sc);
+
return 0;
}
@@ -6441,8 +6477,6 @@ iwm_attach(struct device *parent, struct device
*self, void *aux)
struct pci_attach_args *pa = aux;
pci_intr_handle_t ih;
pcireg_t reg, memtype;
- struct ieee80211com *ic = sc-sc_ic;
- struct ifnet *ifp = ic-ic_if;
const char *intrstr;
int error;
int txq_i, i;
@@ -6592,22 +6626,6 @@ iwm_attach(struct device *parent, struct device
*self, void *aux)
/* Clear pending interrupts. */
IWM_WRITE(sc, IWM_CSR_INT, 0x);
- ic-ic_phytype = IEEE80211_T_OFDM; /* not only, but not used */
- ic-ic_opmode = IEEE80211_M_STA;/* default to BSS mode */
- ic-ic_state = IEEE80211_S_INIT;
-
- /* Set device capabilities. */
- ic-ic_caps =
- IEEE80211_C_WEP | /* WEP */
- IEEE80211_C_RSN | /* WPA/RSN */
- IEEE80211_C_SCANALL | /* device scans all channels at once */
- IEEE80211_C_SHSLOT |/* short slot time supported */
- IEEE80211_C_SHPREAMBLE; /* short preamble supported */
-
- ic-ic_sup_rates[IEEE80211_MODE_11A] = ieee80211_std_rateset_11a;
- ic-ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
- ic-ic_sup_rates[IEEE80211_MODE_11G] = ieee80211_std_rateset_11g;
-
for (i = 0; i nitems(sc-sc_phyctxt); i++) {
sc-sc_phyctxt[i].id = i;
}
@@ -6615,30 +6633,6 @@ iwm_attach(struct device *parent, struct device
*self,
Re: iwm0: fatal firmware error on -current
On Sun, Mar 22, 2015 at 2:06 PM, Jonathan Gray j...@jsg.id.au wrote: On Sun, Mar 22, 2015 at 06:49:33AM -0400, Ted Unangst wrote: Jonathan Gray wrote: On Sun, Mar 22, 2015 at 09:16:08AM +0100, Stefan Sperling wrote: If the firmare image is not present at boot, no interface is created. After installing the firmware with fw_update (which succeeds because it looks for iwm in dmesg not ifconfig) there is no way to recover the interface without a reboot because 'ifconfig iwm0' doesn't work. If the mac address and the supported 802.11 modes depend on having the firmware loaded, is it really worth adding a interface that allows invalid parameters to be set? Maybe? See above. If I don't have firmware when I boot, but install firmware later, the interface should still be useable. Putting the interface into a must reboot state should be considered a bug. I'd be surprised if the 802.11 reattach doesn't cause problems... Anyway here is the minimal version Hi, Unfortunately, neither of the two patchs works for me. Errors are the same. Is there something I can do to help debugging this? -- Mattieu Baptiste /earth is 102% full ... please delete anyone you can.
Re: iwm0: fatal firmware error on -current
On Sun, Mar 22, 2015 at 06:27:19PM +0100, Mattieu Baptiste wrote:
On Sun, Mar 22, 2015 at 2:06 PM, Jonathan Gray j...@jsg.id.au wrote:
On Sun, Mar 22, 2015 at 06:49:33AM -0400, Ted Unangst wrote:
Jonathan Gray wrote:
On Sun, Mar 22, 2015 at 09:16:08AM +0100, Stefan Sperling wrote:
If the firmare image is not present at boot, no interface is created.
After installing the firmware with fw_update (which succeeds because
it looks for iwm in dmesg not ifconfig) there is no way to recover
the interface without a reboot because 'ifconfig iwm0' doesn't work.
If the mac address and the supported 802.11 modes depend on
having the firmware loaded, is it really worth adding a
interface that allows invalid parameters to be set?
Maybe? See above. If I don't have firmware when I boot, but install
firmware
later, the interface should still be useable. Putting the interface into a
must reboot state should be considered a bug.
I'd be surprised if the 802.11 reattach doesn't cause problems...
Anyway here is the minimal version
Hi,
Unfortunately, neither of the two patchs works for me.
Errors are the same.
Is there something I can do to help debugging this?
Updated diff that makes 11a scanning conditional.
diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c
index 6072e6a..4815e06 100644
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -5470,9 +5470,10 @@ iwm_endscan_cb(void *arg)
int done;
DPRINTF((scan ended\n));
- if (sc-sc_scanband == IEEE80211_CHAN_2GHZ) {
+ if (sc-sc_scanband == IEEE80211_CHAN_2GHZ
+ sc-sc_nvm.sku_cap_band_52GHz_enable) {
int error;
done = 0;
if ((error = iwm_mvm_scan_request(sc,
IEEE80211_CHAN_5GHZ, ic-ic_des_esslen != 0,
@@ -6409,8 +6410,13 @@ iwm_preinit(struct iwm_softc *sc)
IWM_UCODE_MINOR(sc-sc_fwver),
IWM_UCODE_API(sc-sc_fwver),
ether_sprintf(sc-sc_nvm.hw_addr));
+ /* not all hardware can do 5GHz band */
+ if (!sc-sc_nvm.sku_cap_band_52GHz_enable)
+ memset(ic-ic_sup_rates[IEEE80211_MODE_11A], 0,
+ sizeof(ic-ic_sup_rates[IEEE80211_MODE_11A]));
+
/* Reattach net80211 so MAC address and channel map are picked up. */
ieee80211_ifdetach(ifp);
ieee80211_ifattach(ifp);
Re: iwm0: fatal firmware error on -current
On Sun, Mar 22, 2015 at 11:03 PM, Jonathan Gray j...@jsg.id.au wrote: On Sun, Mar 22, 2015 at 06:27:19PM +0100, Mattieu Baptiste wrote: On Sun, Mar 22, 2015 at 2:06 PM, Jonathan Gray j...@jsg.id.au wrote: On Sun, Mar 22, 2015 at 06:49:33AM -0400, Ted Unangst wrote: Jonathan Gray wrote: On Sun, Mar 22, 2015 at 09:16:08AM +0100, Stefan Sperling wrote: If the firmare image is not present at boot, no interface is created. After installing the firmware with fw_update (which succeeds because it looks for iwm in dmesg not ifconfig) there is no way to recover the interface without a reboot because 'ifconfig iwm0' doesn't work. If the mac address and the supported 802.11 modes depend on having the firmware loaded, is it really worth adding a interface that allows invalid parameters to be set? Maybe? See above. If I don't have firmware when I boot, but install firmware later, the interface should still be useable. Putting the interface into a must reboot state should be considered a bug. I'd be surprised if the 802.11 reattach doesn't cause problems... Anyway here is the minimal version Hi, Unfortunately, neither of the two patchs works for me. Errors are the same. Is there something I can do to help debugging this? Updated diff that makes 11a scanning conditional. Great, it's working fine now. I'm sending this mail with the iwm(4) interface. Thanks!
Re: iwm0: fatal firmware error on -current
On Thu, Mar 19, 2015 at 08:20:41PM +1100, Jonathan Gray wrote:
On Thu, Mar 19, 2015 at 09:59:39AM +0100, Mattieu Baptiste wrote:
On Thu, Mar 19, 2015 at 9:09 AM, Jonathan Gray j...@jsg.id.au wrote:
It doesn't change anything.
As soon as I set an address on the interface (manually or with
dhclient), mode 11g is resetted and the errors in the logs are the
same.
Can you include the output of pcidump -v?
It's possible you have an adapter that doesn't support 11a.
Here it is:
The way your device is handled in Intel's Linux code is:
{IWL_PCI_DEVICE(0x08B2, 0xC262, iwl7260_n_cfg)},
Which is Intel(R) Wireless N 7260
http://ark.intel.com/products/75174/Intel-Wireless-N-7260
the 7260 adapters that can do multiple bands are
Intel(R) Dual Band Wireless N 7260 iwl7260_2n_cfg
http://ark.intel.com/products/75440/Intel-Dual-Band-Wireless-N-7260
Intel(R) Dual Band Wireless AC 7260
iwl7260_2ac_cfg,iwl7260_2ac_cfg_high_temp
http://ark.intel.com/products/75439/Intel-Dual-Band-Wireless-AC-7260
The driver wrongly assumes all devices support 11a, this needs to be fixed.
Though the Linux code seems to make the band decision based on the EEPROM
not the sub device id.
Try the following.
diff --git sys/dev/pci/if_iwm.c sys/dev/pci/if_iwm.c
index 6072e6a..3bec032 100644
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -6410,8 +6410,38 @@ iwm_preinit(struct iwm_softc *sc)
IWM_UCODE_API(sc-sc_fwver),
ether_sprintf(sc-sc_nvm.hw_addr));
- /* Reattach net80211 so MAC address and channel map are picked up. */
- ieee80211_ifdetach(ifp);
+ ic-ic_phytype = IEEE80211_T_OFDM; /* not only, but not used */
+ ic-ic_opmode = IEEE80211_M_STA;/* default to BSS mode */
+ ic-ic_state = IEEE80211_S_INIT;
+
+ /* Set device capabilities. */
+ ic-ic_caps =
+ IEEE80211_C_WEP | /* WEP */
+ IEEE80211_C_RSN | /* WPA/RSN */
+ IEEE80211_C_SCANALL | /* device scans all channels at once */
+ IEEE80211_C_SHSLOT |/* short slot time supported */
+ IEEE80211_C_SHPREAMBLE; /* short preamble supported */
+
+ if (sc-sc_nvm.sku_cap_band_52GHz_enable)
+ ic-ic_sup_rates[IEEE80211_MODE_11A] =
ieee80211_std_rateset_11a;
+ ic-ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
+ ic-ic_sup_rates[IEEE80211_MODE_11G] = ieee80211_std_rateset_11g;
+
+ /* IBSS channel undefined for now. */
+ ic-ic_ibss_chan = ic-ic_channels[1];
+
+ /* Max RSSI */
+ ic-ic_max_rssi = IWM_MAX_DBM - IWM_MIN_DBM;
+
+ ifp-if_softc = sc;
+ ifp-if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
+ ifp-if_ioctl = iwm_ioctl;
+ ifp-if_start = iwm_start;
+ ifp-if_watchdog = iwm_watchdog;
+ IFQ_SET_READY(ifp-if_snd);
+ memcpy(ifp-if_xname, DEVNAME(sc), IFNAMSIZ);
+
+ if_attach(ifp);
ieee80211_ifattach(ifp);
ic-ic_node_alloc = iwm_node_alloc;
@@ -6421,6 +6451,12 @@ iwm_preinit(struct iwm_softc *sc)
ic-ic_newstate = iwm_newstate;
ieee80211_media_init(ifp, iwm_media_change, ieee80211_media_status);
+#if NBPFILTER 0
+ iwm_radiotap_attach(sc);
+#endif
+ timeout_set(sc-sc_calib_to, iwm_calib_timeout, sc);
+ task_set(sc-init_task, iwm_init_task, sc);
+
return 0;
}
@@ -6441,8 +6477,6 @@ iwm_attach(struct device *parent, struct device *self,
void *aux)
struct pci_attach_args *pa = aux;
pci_intr_handle_t ih;
pcireg_t reg, memtype;
- struct ieee80211com *ic = sc-sc_ic;
- struct ifnet *ifp = ic-ic_if;
const char *intrstr;
int error;
int txq_i, i;
@@ -6592,22 +6626,6 @@ iwm_attach(struct device *parent, struct device *self,
void *aux)
/* Clear pending interrupts. */
IWM_WRITE(sc, IWM_CSR_INT, 0x);
- ic-ic_phytype = IEEE80211_T_OFDM; /* not only, but not used */
- ic-ic_opmode = IEEE80211_M_STA;/* default to BSS mode */
- ic-ic_state = IEEE80211_S_INIT;
-
- /* Set device capabilities. */
- ic-ic_caps =
- IEEE80211_C_WEP | /* WEP */
- IEEE80211_C_RSN | /* WPA/RSN */
- IEEE80211_C_SCANALL | /* device scans all channels at once */
- IEEE80211_C_SHSLOT |/* short slot time supported */
- IEEE80211_C_SHPREAMBLE; /* short preamble supported */
-
- ic-ic_sup_rates[IEEE80211_MODE_11A] = ieee80211_std_rateset_11a;
- ic-ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
- ic-ic_sup_rates[IEEE80211_MODE_11G] = ieee80211_std_rateset_11g;
-
for (i = 0; i nitems(sc-sc_phyctxt); i++) {
sc-sc_phyctxt[i].id = i;
}
@@ -6615,30 +6633,6 @@ iwm_attach(struct device *parent, struct device *self,
void *aux)
sc-sc_amrr.amrr_min_success_threshold
Re: iwm0: fatal firmware error on -current
On Thu, Mar 19, 2015 at 08:50:11AM +0100, Mattieu Baptiste wrote: On Thu, Mar 19, 2015 at 12:38 AM, Stefan Sperling s...@stsp.name wrote: Ok, so I tried reverting one by one every commit. Starting with rev. 1.33 of if_iwm.c, the interface cannot be brought up (no carrier). With rev. 1.32, the connection is OK and rather stable. My AP is capable of 802.11a/b/g/n at 2.4 and 5 GHz. And I guess your AP is configured to use some 2.4GHz channel? Yes, both 2.4 and 5. Revision 1.33 enabled 11a support, which means scans will take much longer since more channels must be scanned. With if_iwm.c at HEAD, if you run 'ifconfig iwm0 media autoselect mode 11g' before doing anything else does it behave better again? It doesn't change anything. As soon as I set an address on the interface (manually or with dhclient), mode 11g is resetted and the errors in the logs are the same. Can you include the output of pcidump -v? It's possible you have an adapter that doesn't support 11a.
Re: iwm0: fatal firmware error on -current
On Thu, Mar 19, 2015 at 9:09 AM, Jonathan Gray j...@jsg.id.au wrote: It doesn't change anything. As soon as I set an address on the interface (manually or with dhclient), mode 11g is resetted and the errors in the logs are the same. Can you include the output of pcidump -v? It's possible you have an adapter that doesn't support 11a. Here it is: Domain /dev/pci0: 0:0:0: Intel Core 4G Host 0x: Vendor ID: 8086 Product ID: 0a04 0x0004: Command: 0006 Status: 2090 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 0b 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 220c 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel HD Graphics 0x: Vendor ID: 8086 Product ID: 0a16 0x0004: Command: 0007 Status: 0090 0x0008: Class: 03 Subclass: 00 Interface: 00 Revision: 0b 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xf000/0x0040 0x0018: BAR mem prefetchable 64bit addr: 0xe000/0x1000 0x0020: BAR io addr: 0x3000/0x0040 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 220c 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0090: Capability 0x05: Message Signaled Interrupts (MSI) 0x00d0: Capability 0x01: Power Management 0x00a4: Capability 0x13: PCI Advanced Features 0:3:0: Intel Core 4G HD Audio 0x: Vendor ID: 8086 Product ID: 0a0c 0x0004: Command: 0006 Status: 0010 0x0008: Class: 04 Subclass: 03 Interface: 00 Revision: 0b 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 10 0x0010: BAR mem 64bit addr: 0xf063/0x4000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 220c 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0050: Capability 0x01: Power Management 0x0060: Capability 0x05: Message Signaled Interrupts (MSI) 0x0070: Capability 0x10: PCI Express 0:20:0: Intel 8 Series xHCI 0x: Vendor ID: 8086 Product ID: 9c31 0x0004: Command: 0006 Status: 0290 0x0008: Class: 0c Subclass: 03 Interface: 30 Revision: 04 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xf062/0x0001 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 220c 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0070: Capability 0x01: Power Management 0x0080: Capability 0x05: Message Signaled Interrupts (MSI) 0:22:0: Intel 8 Series MEI 0x: Vendor ID: 8086 Product ID: 9c3a 0x0004: Command: 0006 Status: 0010 0x0008: Class: 07 Subclass: 80 Interface: 00 Revision: 04 0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xf0639000/0x0020 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 220c 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0050: Capability 0x01: Power Management 0x008c: Capability 0x05: Message Signaled Interrupts (MSI) 0:25:0: Intel I218-LM 0x: Vendor ID: 8086 Product ID: 155a 0x0004: Command: 0007 Status: 0010 0x0008: Class: 02 Subclass: 00 Interface: 00 Revision: 04 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 32bit addr: 0xf060/0x0002 0x0014: BAR mem 32bit addr: 0xf063e000/0x1000 0x0018: BAR io addr: 0x3080/0x0020 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 2214 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x00c8: Capability 0x01: Power Management 0x00d0: Capability 0x05: Message Signaled Interrupts (MSI) 0x00e0: Capability 0x13: PCI Advanced Features 0:27:0: Intel 8 Series HD Audio 0x: Vendor ID: 8086 Product ID: 9c20 0x0004: Command: 0006 Status: 0010 0x0008: Class: 04 Subclass: 03 Interface: 00 Revision: 04 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00
Re: iwm0: fatal firmware error on -current
On Thu, Mar 19, 2015 at 09:59:39AM +0100, Mattieu Baptiste wrote:
On Thu, Mar 19, 2015 at 9:09 AM, Jonathan Gray j...@jsg.id.au wrote:
It doesn't change anything.
As soon as I set an address on the interface (manually or with
dhclient), mode 11g is resetted and the errors in the logs are the
same.
Can you include the output of pcidump -v?
It's possible you have an adapter that doesn't support 11a.
Here it is:
The way your device is handled in Intel's Linux code is:
{IWL_PCI_DEVICE(0x08B2, 0xC262, iwl7260_n_cfg)},
Which is Intel(R) Wireless N 7260
http://ark.intel.com/products/75174/Intel-Wireless-N-7260
the 7260 adapters that can do multiple bands are
Intel(R) Dual Band Wireless N 7260iwl7260_2n_cfg
http://ark.intel.com/products/75440/Intel-Dual-Band-Wireless-N-7260
Intel(R) Dual Band Wireless AC 7260
iwl7260_2ac_cfg,iwl7260_2ac_cfg_high_temp
http://ark.intel.com/products/75439/Intel-Dual-Band-Wireless-AC-7260
The driver wrongly assumes all devices support 11a, this needs to be fixed.
Though the Linux code seems to make the band decision based on the EEPROM
not the sub device id.
3:0:0: Intel Dual Band Wireless AC 7260
0x: Vendor ID: 8086 Product ID: 08b2
0x0004: Command: 0006 Status: 0010
0x0008: Class: 02 Subclass: 80 Interface: 00 Revision: 6b
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 10
0x0010: BAR mem 64bit addr: 0xf040/0x2000
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS:
0x002c: Subsystem Vendor ID: 8086 Product ID: c262
0x0030: Expansion ROM Base Address:
0x0038:
0x003c: Interrupt Pin: 01 Line: 09 Min Gnt: 00 Max Lat: 00
0x00c8: Capability 0x01: Power Management
0x00d0: Capability 0x05: Message Signaled Interrupts (MSI)
0x0040: Capability 0x10: PCI Express
Link Speed: 2.5 / 2.5 GT/s Link Width: x1 / x1
Re: iwm0: fatal firmware error on -current
On Thu, Mar 19, 2015 at 12:38 AM, Stefan Sperling s...@stsp.name wrote: Ok, so I tried reverting one by one every commit. Starting with rev. 1.33 of if_iwm.c, the interface cannot be brought up (no carrier). With rev. 1.32, the connection is OK and rather stable. My AP is capable of 802.11a/b/g/n at 2.4 and 5 GHz. And I guess your AP is configured to use some 2.4GHz channel? Yes, both 2.4 and 5. Revision 1.33 enabled 11a support, which means scans will take much longer since more channels must be scanned. With if_iwm.c at HEAD, if you run 'ifconfig iwm0 media autoselect mode 11g' before doing anything else does it behave better again? It doesn't change anything. As soon as I set an address on the interface (manually or with dhclient), mode 11g is resetted and the errors in the logs are the same. -- Mattieu Baptiste /earth is 102% full ... please delete anyone you can.
Re: iwm0: fatal firmware error on -current
On Wed, Mar 18, 2015 at 06:31:03PM +0100, Mattieu Baptiste wrote: Anyone seeing this? Yes, all the time. I'll try to find this night the commit which is causing this regression. If there was particular commit that made it much worse, that would be good to know. But I believe this problem has been present since the driver was added. I made sure to list frequent firmware timeouts in the man page as one of the outstanding bugs. Usually the firmware manages to recover after a few association attempts. The problem(s?) is/are in the transition from initial state to successful association. Once the driver manages to associate the connection is stable. I think this problem is caused by the net80211 state machine racing the firmware/hardware. I haven't yet found time to confirm this theory though. Testing the theory involves introducing synchronous register i/o operations in the driver. Currently they happen asynchronously to net80211 state changes (else the kernel panics very quickly). I don't know why the driver was written this way. Perhaps it's a remnant from the porting process from Linux. This driver has a peculiar history. OpenBSD adopted it but it wasn't originally written by us. In any case, please make sure you have 2 antennas connected to the device. The driver doesn't handle a missing antenna yet.
Re: iwm0: fatal firmware error on -current
On Wed, Mar 18, 2015 at 10:45:16PM +0100, Mattieu Baptiste wrote: On Wed, Mar 18, 2015 at 7:01 PM, Stefan Sperling s...@stsp.name wrote: On Wed, Mar 18, 2015 at 06:31:03PM +0100, Mattieu Baptiste wrote: Anyone seeing this? Yes, all the time. I'll try to find this night the commit which is causing this regression. If there was particular commit that made it much worse, that would be good to know. Ok, so I tried reverting one by one every commit. Starting with rev. 1.33 of if_iwm.c, the interface cannot be brought up (no carrier). With rev. 1.32, the connection is OK and rather stable. My AP is capable of 802.11a/b/g/n at 2.4 and 5 GHz. And I guess your AP is configured to use some 2.4GHz channel? Revision 1.33 enabled 11a support, which means scans will take much longer since more channels must be scanned. With if_iwm.c at HEAD, if you run 'ifconfig iwm0 media autoselect mode 11g' before doing anything else does it behave better again?
iwm0: fatal firmware error on -current
Hi, Since a few days, after upgrading to -current, I cannot use my iwm(4) device anymore. When trying to connect to an AP, I got the messages below (debug on). Anyone seeing this? I'll try to find this night the commit which is causing this regression. Mar 18 17:54:55 westvleteren /bsd: iwm0: begin active scan Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from fa:8f:ca:76:d0:8a rssi 23 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 06:18:0a:e0:20:a0 rssi 32 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 00:18:0a:e0:3c:50 rssi 26 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 06:18:0a:e0:3d:50 rssi 33 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 00:18:0a:e0:32:20 rssi 35 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 06:18:0a:e0:3c:50 rssi 24 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 00:18:0a:e0:3d:50 rssi 32 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 06:18:0a:e0:20:a0 rssi 31 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 00:18:0a:e0:33:80 rssi 18 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 00:18:0a:e0:2c:c0 rssi 21 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 06:18:0a:e0:3d:40 rssi 13 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: received beacon from 00:18:0a:e0:3d:60 rssi 24 mode 11g Mar 18 17:54:55 westvleteren /bsd: iwm0: fatal firmware error Mar 18 17:54:56 westvleteren /bsd: iwm0: could not initiate scan Here is a dmesg: OpenBSD 5.7-current (GENERIC.MP) #893: Sun Mar 15 19:04:07 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3951230976 (3768MB) avail mem = 3827544064 (3650MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (61 entries) bios0: vendor LENOVO version GJET77WW (2.27 ) date 05/20/2014 bios0: LENOVO 20B7S2G900 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM ASF! 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 acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 1796.10 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM 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, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 1795.85 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM 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-4300U CPU @ 1.90GHz, 1795.85 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM 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-4300U CPU @ 1.90GHz, 1795.85 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus
Re: iwm0: fatal firmware error on -current
On Wed, Mar 18, 2015 at 7:01 PM, Stefan Sperling s...@stsp.name wrote: On Wed, Mar 18, 2015 at 06:31:03PM +0100, Mattieu Baptiste wrote: Anyone seeing this? Yes, all the time. I'll try to find this night the commit which is causing this regression. If there was particular commit that made it much worse, that would be good to know. Ok, so I tried reverting one by one every commit. Starting with rev. 1.33 of if_iwm.c, the interface cannot be brought up (no carrier). With rev. 1.32, the connection is OK and rather stable. My AP is capable of 802.11a/b/g/n at 2.4 and 5 GHz. -- Mattieu Baptiste /earth is 102% full ... please delete anyone you can.
