Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Wed, Jun 22, 2016 at 09:34:08PM +1200, Carlin Bingham wrote:
> I've seen fatal iwm firmware errors the last couple of days, that I
> think coincide with this going in, although I can't figure out how to
> reproduce it to see if backing this out makes them go away. Just seems
> to happen randomly.

Unless you can clearly show that these errors are related to that commit,
I'm going to file this as a different problem. There are many situations
where the firmware errors out, and we have certainly not fixed all of them
(if that's even possible in a lifetime...)

The code path which was changed by the commit is only taken while the device
is brought up. From the timestamps of the messages you provided it looks as
if the firmware error is not happening during association, but much later.

A kernel compiled with IWM_DEBUG (add "#define IWM_DEBUG" before the line
"#ifdef IWM_DEBUG" in sys/dev/pci/if_iwm.c) may shed more light on the nature
of the firmware error. However, in most cases, I cannot tell what's wrong just
by looking at a firmware error dump. A reproducible test case makes it much
more likely that the problem can be fixed after some experimentation.

> Jun 21 17:14:46 vorpal /bsd: iwm0: sending action to 20:cf:30:c6:36:f7 on 
> channel 3 mode 11n
> Jun 21 17:14:46 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 
> rssi 59 mode 11n
> Jun 21 17:14:48 vorpal /bsd: iwm0: sending action to 20:cf:30:c6:36:f7 on 
> channel 3 mode 11n
> Jun 21 17:14:48 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 
> rssi 65 mode 11n
> Jun 21 17:27:09 vorpal /bsd: iwm0: fatal firmware error
> [...]
> Jun 22 15:14:15 vorpal /bsd: iwm0: sending action to 20:cf:30:c6:36:f7 on 
> channel 3 mode 11n
> Jun 22 15:14:15 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 
> rssi 61 mode 11n
> Jun 22 15:16:31 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 
> rssi 62 mode 11n
> Jun 22 15:16:31 vorpal /bsd: iwm0: sending action to 20:cf:30:c6:36:f7 on 
> channel 3 mode 11n
> Jun 22 15:16:31 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 
> rssi 64 mode 11n
> Jun 22 15:36:06 vorpal /bsd: iwm0: fatal firmware error
> 
> 
> This is a Thinkpad T440p with AC 7260

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Carlin Bingham]

On Mon, Jun 20, 2016 at 12:18:30AM +0200, Stefan Sperling wrote:
> On Tue, Jun 07, 2016 at 01:10:34AM +0200, Theo Buehler wrote:
> > On Mon, Jun 06, 2016 at 03:09:34PM +0200, Stefan Sperling wrote:
> > > On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote:
> > > > Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
> > > 
> > > This indicates there is a race condition bug which is avoided
> > > by the additional time spent on printing data to the console.
> > > 
> > 
> > I could not get my 
> > 
> > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, 
> > msi
> > 
> > to find a network, let alone associate with one at all (from bsd.rd).
> > 
> > Contrary to what kettenis@ reports, repeated up/down/up/scan/scan/scan
> > doesn't help.
> > 
> > As Remi reports, things work just fine when IWM_DEBUG is enabled.
> > 
> > I did some bisecting and it turns out that the last version that works
> > on bsd.rd is if_iwm.c -r1.81 (with the old firmware), -r1.82 which
> > made the transition to the new firmware stops working.
> > 
> > No problems whatsoever with GENERIC and GENERIC.MP
> 
> Remi, Mark, can you confirm that this diff fixes the problem for you?

I've seen fatal iwm firmware errors the last couple of days, that I
think coincide with this going in, although I can't figure out how to
reproduce it to see if backing this out makes them go away. Just seems
to happen randomly.

Jun 21 17:14:46 vorpal /bsd: iwm0: sending action to 20:cf:30:c6:36:f7 on 
channel 3 mode 11n
Jun 21 17:14:46 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 rssi 
59 mode 11n
Jun 21 17:14:48 vorpal /bsd: iwm0: sending action to 20:cf:30:c6:36:f7 on 
channel 3 mode 11n
Jun 21 17:14:48 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 rssi 
65 mode 11n
Jun 21 17:27:09 vorpal /bsd: iwm0: fatal firmware error
[...]
Jun 22 15:14:15 vorpal /bsd: iwm0: sending action to 20:cf:30:c6:36:f7 on 
channel 3 mode 11n
Jun 22 15:14:15 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 rssi 
61 mode 11n
Jun 22 15:16:31 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 rssi 
62 mode 11n
Jun 22 15:16:31 vorpal /bsd: iwm0: sending action to 20:cf:30:c6:36:f7 on 
channel 3 mode 11n
Jun 22 15:16:31 vorpal /bsd: iwm0: received action from 20:cf:30:c6:36:f7 rssi 
64 mode 11n
Jun 22 15:36:06 vorpal /bsd: iwm0: fatal firmware error


This is a Thinkpad T440p with AC 7260


OpenBSD 6.0-beta (GENERIC.MP) #2200: Mon Jun 20 21:07:29 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16835846144 (16055MB)
avail mem = 16321081344 (15564MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xacd3d000 (66 entries)
bios0: vendor LENOVO version "GLET70WW (2.24 )" date 05/21/2014
bios0: LENOVO 20ANCTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT PCCT SSDT UEFI MSDM ASF! BATB FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) EXP3(S4) XHCI(S3) 
EHC1(S3) EHC2(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz, 2494.55 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz, 2494.22 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz, 2494.23 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Tue, Jun 21, 2016 at 08:13:25AM +0200, Remi Locherer wrote:
> I noticed that this is allready commited. So I did cvs up and built a
> new release (with r 1.89 of if_iwm.c). iwm0 now works fine in bsd.rd.
> Thanks!
> 
> Remi

Great. Thanks for confirming!

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Remi Locherer]

On Mon, Jun 20, 2016 at 12:18:30AM +0200, Stefan Sperling wrote:
> On Tue, Jun 07, 2016 at 01:10:34AM +0200, Theo Buehler wrote:
> > On Mon, Jun 06, 2016 at 03:09:34PM +0200, Stefan Sperling wrote:
> > > On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote:
> > > > Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
> > > 
> > > This indicates there is a race condition bug which is avoided
> > > by the additional time spent on printing data to the console.
> > > 
> > 
> > I could not get my 
> > 
> > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, 
> > msi
> > 
> > to find a network, let alone associate with one at all (from bsd.rd).
> > 
> > Contrary to what kettenis@ reports, repeated up/down/up/scan/scan/scan
> > doesn't help.
> > 
> > As Remi reports, things work just fine when IWM_DEBUG is enabled.
> > 
> > I did some bisecting and it turns out that the last version that works
> > on bsd.rd is if_iwm.c -r1.81 (with the old firmware), -r1.82 which
> > made the transition to the new firmware stops working.
> > 
> > No problems whatsoever with GENERIC and GENERIC.MP
> 
> Remi, Mark, can you confirm that this diff fixes the problem for you?

I noticed that this is allready commited. So I did cvs up and built a
new release (with r 1.89 of if_iwm.c). iwm0 now works fine in bsd.rd.
Thanks!

Remi

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Tue, Jun 07, 2016 at 01:10:34AM +0200, Theo Buehler wrote:
> On Mon, Jun 06, 2016 at 03:09:34PM +0200, Stefan Sperling wrote:
> > On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote:
> > > Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
> > 
> > This indicates there is a race condition bug which is avoided
> > by the additional time spent on printing data to the console.
> > 
> 
> I could not get my 
> 
> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi
> 
> to find a network, let alone associate with one at all (from bsd.rd).
> 
> Contrary to what kettenis@ reports, repeated up/down/up/scan/scan/scan
> doesn't help.
> 
> As Remi reports, things work just fine when IWM_DEBUG is enabled.
> 
> I did some bisecting and it turns out that the last version that works
> on bsd.rd is if_iwm.c -r1.81 (with the old firmware), -r1.82 which
> made the transition to the new firmware stops working.
> 
> No problems whatsoever with GENERIC and GENERIC.MP

Remi, Mark, can you confirm that this diff fixes the problem for you?

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.87
diff -u -p -r1.87 if_iwm.c
--- if_iwm.c18 Jun 2016 07:49:24 -  1.87
+++ if_iwm.c19 Jun 2016 19:35:58 -
@@ -2161,7 +2161,7 @@ iwm_send_phy_db_cmd(struct iwm_softc *sc
struct iwm_phy_db_cmd phy_db_cmd;
struct iwm_host_cmd cmd = {
.id = IWM_PHY_DB_CMD,
-   .flags = IWM_CMD_SYNC,
+   .flags = IWM_CMD_ASYNC,
};
 
DPRINTFN(10, ("Sending PHY-DB hcmd of type %d, of length %d\n", type, 
length));

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Theo Buehler]

On Mon, Jun 06, 2016 at 03:09:34PM +0200, Stefan Sperling wrote:
> On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote:
> > Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
> 
> This indicates there is a race condition bug which is avoided
> by the additional time spent on printing data to the console.
> 

I could not get my 

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi

to find a network, let alone associate with one at all (from bsd.rd).

Contrary to what kettenis@ reports, repeated up/down/up/scan/scan/scan
doesn't help.

As Remi reports, things work just fine when IWM_DEBUG is enabled.

I did some bisecting and it turns out that the last version that works
on bsd.rd is if_iwm.c -r1.81 (with the old firmware), -r1.82 which
made the transition to the new firmware stops working.

No problems whatsoever with GENERIC and GENERIC.MP

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote:
> Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.

This indicates there is a race condition bug which is avoided
by the additional time spent on printing data to the console.

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Remi Locherer]

On Sun, Jun 05, 2016 at 07:25:30PM +0200, Stefan Sperling wrote:
> On Sun, Jun 05, 2016 at 01:26:41PM +0200, Remi Locherer wrote:
> > On Sun, Jun 05, 2016 at 09:48:47AM +0200, Stefan Sperling wrote:
> > > On Sat, Jun 04, 2016 at 11:16:32PM +0200, Remi Locherer wrote:
> > > > On my installation the upgrade process looks like this (snapshot bsd.rd
> > > > from Jun 2):
> > >  
> > > > [...]
> > > 
> > > > iwm0: no link ... sleeping
> > > 
> > > > My /etc/hostname.iwm0:
> > > > 
> > > > nwid tsunami wpakey 
> > > > dhcp
> > > > inet6 autoconf
> > > > !pkill -9 -lf wifinwid
> > > > !/etc/wifinwid \$if &
> > > 
> > > Please add a 'debug' line at the top of your hostname.iwm0 file.
> > > That might reveal more of what's going on.
> > 
> > There is no additional output with debug in hostname.iwm0 when
> > booting bsd.rd (snapshot Jun 2). When booting bsd.mp I see that iwm0
> > does scanning and receives beacons and more.
> 
> Strange. ifconfig iwm0 debug definitely works in the ramdisk for me.
> 
> Can we set aside the install script and hostname.if magic for a while,
> and just determine whether your device works at all in bsd.rd?
> 
> Try the following:
> 
>   Boot bsd.rd
>   Select the (S)hell option
>   cd /dev
>   sh MAKEDEV sd1
>   mount /dev/sd1a /mnt   # for firmware
>   ifconfig iwm0 debug
>   ifconfig iwm0 scan
> 
> Repeat the scan command a few times. I expect that, at least after a few
> tries, you should see the same behaviour you would see with GENERIC.
> Is that not the case?
> 
> If the scan works, can you manually associate to a network and
> run dhclient iwm0? Does that work?
> 
> All of the above works for me.
> 
> > > Additionally, could you build a release with IWM_DEBUG defined
> > > in if_iwm.c and try bsd.rd from that? This would again print more.
> > 
> > I'll try that next. Is it correct that I need to put the below line
> > in sys/arch/amd64/conf/RAMDISK_CD?
> > 
> > option  IWM_DEBUG=1
> 
> I believe it would be just 'option IWM_DEBUG'.
> 
> You could also apply this patch.
> 
> Index: if_iwm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
> retrieving revision 1.86
> diff -u -p -r1.86 if_iwm.c
> --- if_iwm.c  3 Jun 2016 16:16:25 -   1.86
> +++ if_iwm.c  5 Jun 2016 17:23:44 -
> @@ -148,6 +148,7 @@
>  #define le16_to_cpup(_a_) (le16toh(*(const uint16_t *)(_a_)))
>  #define le32_to_cpup(_a_) (le32toh(*(const uint32_t *)(_a_)))
>  
> +#define IWM_DEBUG
>  #ifdef IWM_DEBUG
>  #define DPRINTF(x)   do { if (iwm_debug > 0) printf x; } while (0)
>  #define DPRINTFN(n, x)   do { if (iwm_debug >= (n)) printf x; } while (0)

Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
(dmesg below). These commands are what produced the below dmesg:

ifconfig iwm0
ifconfig iwm0 up
ifconfig iwm0
ifconfig iwm0 scan
ifconfig iwm0 nwid tsunami wpakey XXX
dhclient iwm0


So iwm0 did not work on my notebook with bsd.rd from snapshots (May 31 and 
Jun 2 tested).

It works fine with bsd.rd I built today (CVS up from Jun 6).

I have 1 modification in my local tree (Which I hope does not influence iwm
behaviour.):

Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.223
diff -u -p -r1.223 dsdt.c
--- dsdt.c  8 May 2016 11:08:01 -   1.223
+++ dsdt.c  6 Jun 2016 12:04:27 -
@@ -1457,7 +1457,7 @@ struct aml_defval {
struct aml_value**gval;
 } aml_defobj[] = {
{ "_OS_", AML_OBJTYPE_STRING, -1, osstring },
-   { "_REV", AML_OBJTYPE_INTEGER, 2, NULL },
+   { "_REV", AML_OBJTYPE_INTEGER, 5, NULL },
{ "_GL", AML_OBJTYPE_MUTEX, 1, NULL, _global_lock },
{ "_OSI", AML_OBJTYPE_METHOD, 1, aml_callosi },



dmesg from bsd.rd:

OpenBSD 6.0-beta (RAMDISK_CD) #2: Mon Jun  6 13:16:55 CEST 2016
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 8473636864 (8081MB)
avail mem = 8215109632 (7834MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries)
bios0: vendor Dell Inc. version "A07" date 11/11/2015
bios0: Dell Inc. XPS 13 9343
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT 
SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.58 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,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, 

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Mark Kettenis]

> Date: Sun, 5 Jun 2016 19:25:30 +0200
> From: Stefan Sperling 
> 
> On Sun, Jun 05, 2016 at 01:26:41PM +0200, Remi Locherer wrote:
> > On Sun, Jun 05, 2016 at 09:48:47AM +0200, Stefan Sperling wrote:
> > > On Sat, Jun 04, 2016 at 11:16:32PM +0200, Remi Locherer wrote:
> > > > On my installation the upgrade process looks like this (snapshot bsd.rd
> > > > from Jun 2):
> > >  
> > > > [...]
> > > 
> > > > iwm0: no link ... sleeping
> > > 
> > > > My /etc/hostname.iwm0:
> > > > 
> > > > nwid tsunami wpakey 
> > > > dhcp
> > > > inet6 autoconf
> > > > !pkill -9 -lf wifinwid
> > > > !/etc/wifinwid \$if &
> > > 
> > > Please add a 'debug' line at the top of your hostname.iwm0 file.
> > > That might reveal more of what's going on.
> > 
> > There is no additional output with debug in hostname.iwm0 when
> > booting bsd.rd (snapshot Jun 2). When booting bsd.mp I see that iwm0
> > does scanning and receives beacons and more.
> 
> Strange. ifconfig iwm0 debug definitely works in the ramdisk for me.
> 
> Can we set aside the install script and hostname.if magic for a while,
> and just determine whether your device works at all in bsd.rd?
> 
> Try the following:
> 
>   Boot bsd.rd
>   Select the (S)hell option
>   cd /dev
>   sh MAKEDEV sd1
>   mount /dev/sd1a /mnt   # for firmware
>   ifconfig iwm0 debug
>   ifconfig iwm0 scan
> 
> Repeat the scan command a few times. I expect that, at least after a few
> tries, you should see the same behaviour you would see with GENERIC.
> Is that not the case?

In my case, after "ifconfig iwm0 scan" it will print the

  iwm0: hw rev 0x210, fw ver 16.242414.0, address 11:22:33:44:55:66

line, but no further output.  It doesn't see any of the access points
around me.  Repeating the scan a couple of times doesn't help.

Only if I do:

  ifconfig iwm0 up
  ifconfig iwm0 scan

it starts spewing debug messages and will it list the access points.

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Sun, Jun 05, 2016 at 01:26:41PM +0200, Remi Locherer wrote:
> On Sun, Jun 05, 2016 at 09:48:47AM +0200, Stefan Sperling wrote:
> > On Sat, Jun 04, 2016 at 11:16:32PM +0200, Remi Locherer wrote:
> > > On my installation the upgrade process looks like this (snapshot bsd.rd
> > > from Jun 2):
> >  
> > > [...]
> > 
> > > iwm0: no link ... sleeping
> > 
> > > My /etc/hostname.iwm0:
> > > 
> > > nwid tsunami wpakey 
> > > dhcp
> > > inet6 autoconf
> > > !pkill -9 -lf wifinwid
> > > !/etc/wifinwid \$if &
> > 
> > Please add a 'debug' line at the top of your hostname.iwm0 file.
> > That might reveal more of what's going on.
> 
> There is no additional output with debug in hostname.iwm0 when
> booting bsd.rd (snapshot Jun 2). When booting bsd.mp I see that iwm0
> does scanning and receives beacons and more.

Strange. ifconfig iwm0 debug definitely works in the ramdisk for me.

Can we set aside the install script and hostname.if magic for a while,
and just determine whether your device works at all in bsd.rd?

Try the following:

  Boot bsd.rd
  Select the (S)hell option
  cd /dev
  sh MAKEDEV sd1
  mount /dev/sd1a /mnt   # for firmware
  ifconfig iwm0 debug
  ifconfig iwm0 scan

Repeat the scan command a few times. I expect that, at least after a few
tries, you should see the same behaviour you would see with GENERIC.
Is that not the case?

If the scan works, can you manually associate to a network and
run dhclient iwm0? Does that work?

All of the above works for me.

> > Additionally, could you build a release with IWM_DEBUG defined
> > in if_iwm.c and try bsd.rd from that? This would again print more.
> 
> I'll try that next. Is it correct that I need to put the below line
> in sys/arch/amd64/conf/RAMDISK_CD?
> 
> option  IWM_DEBUG=1

I believe it would be just 'option IWM_DEBUG'.

You could also apply this patch.

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.86
diff -u -p -r1.86 if_iwm.c
--- if_iwm.c3 Jun 2016 16:16:25 -   1.86
+++ if_iwm.c5 Jun 2016 17:23:44 -
@@ -148,6 +148,7 @@
 #define le16_to_cpup(_a_) (le16toh(*(const uint16_t *)(_a_)))
 #define le32_to_cpup(_a_) (le32toh(*(const uint32_t *)(_a_)))
 
+#define IWM_DEBUG
 #ifdef IWM_DEBUG
 #define DPRINTF(x) do { if (iwm_debug > 0) printf x; } while (0)
 #define DPRINTFN(n, x) do { if (iwm_debug >= (n)) printf x; } while (0)

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Remi Locherer]

On Sun, Jun 05, 2016 at 09:48:47AM +0200, Stefan Sperling wrote:
> On Sat, Jun 04, 2016 at 11:16:32PM +0200, Remi Locherer wrote:
> > On my installation the upgrade process looks like this (snapshot bsd.rd
> > from Jun 2):
>  
> > [...]
> 
> > iwm0: no link ... sleeping
> 
> > My /etc/hostname.iwm0:
> > 
> > nwid tsunami wpakey 
> > dhcp
> > inet6 autoconf
> > !pkill -9 -lf wifinwid
> > !/etc/wifinwid \$if &
> 
> Please add a 'debug' line at the top of your hostname.iwm0 file.
> That might reveal more of what's going on.

There is no additional output with debug in hostname.iwm0 when
booting bsd.rd (snapshot Jun 2). When booting bsd.mp I see that iwm0
does scanning and receives beacons and more.

> Additionally, could you build a release with IWM_DEBUG defined
> in if_iwm.c and try bsd.rd from that? This would again print more.

I'll try that next. Is it correct that I need to put the below line
in sys/arch/amd64/conf/RAMDISK_CD?

option  IWM_DEBUG=1

> Is there a difference between cold boots (i.e. power up) and warm
> boots (i.e. reboots) to bsd.rd?

I could not find a difference.

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Sat, Jun 04, 2016 at 11:16:32PM +0200, Remi Locherer wrote:
> On my installation the upgrade process looks like this (snapshot bsd.rd
> from Jun 2):
 
> [...]

> iwm0: no link ... sleeping

> My /etc/hostname.iwm0:
> 
> nwid tsunami wpakey 
> dhcp
> inet6 autoconf
> !pkill -9 -lf wifinwid
> !/etc/wifinwid \$if &

Please add a 'debug' line at the top of your hostname.iwm0 file.
That might reveal more of what's going on.

Additionally, could you build a release with IWM_DEBUG defined
in if_iwm.c and try bsd.rd from that? This would again print more.

Is there a difference between cold boots (i.e. power up) and warm
boots (i.e. reboots) to bsd.rd?

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Thu, Jun 02, 2016 at 11:04:48PM +0200, Remi Locherer wrote:
> On Thu, Jun 02, 2016 at 08:23:24PM +0200, Stefan Sperling wrote:
> > On Wed, Jun 01, 2016 at 11:12:25PM +0200, Remi Locherer wrote:
> > > >Synopsis:bsd.rd from May 31 fails to load the firmware for 
> > > >iwm-7265-16
> > > >Category:kernel
> > > >Environment:
> > >   System  : OpenBSD 6.0
> > >   Details : OpenBSD 6.0-beta (GENERIC.MP) #26: Wed May 25 07:34:23 
> > > CEST 2016
> > >
> > > r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > 
> > >   Architecture: OpenBSD.amd64
> > >   Machine : amd64
> > > 
> > > >Description
> > > 
> > > bsd.rd from May 31 fails to load the iwm firmware during an upgrade.
> > > dmesg says:
> > > 
> > > iwm0: could not read firmware iwm-7265-16 (error 2)
> > > iwm0: failed to load init firmware
> > 
> > The ramdisk kernel tries two directories, /etc/firmware and 
> > /mnt/etc/firmware.
> > 
> > Perhaps the above failure is the attempt to load firmware from 
> > /etc/firmware,
> > which does not exist on the ramdisk? I've added the 'failed to load init
> > firmware' message in the commit which made the dirver use newer firmware.
> > Before that commit, this failure case was silent. So it is possible that
> > nothing has changed, except for this message now being printed.
> > 
> > The following line indicates that the second attempt (from 
> > /mnt/etc/firmware)
> > works. It is only printed if firmware could be loaded successfully:
> > 
> > > iwm0: hw rev 0x210, fw ver 16.242414.0, address 5c:e0:c5:1f:ad:c4
> > 
> > > A generic kernel (not bsd.rd!) I built from source on May 31 can load the
> > > iwm firmware and it works fine.
> > 
> > Are you implying that the device does not work in the ramdisk?
> 
> Yes. With the ramdisk kernel the status of iwm0 does not go to active anymore.
> Last time I did a snapshot upgrade on this notebook it worked as expected.
> That was on May 25.

Works for me with -current built today.
This is what the upgrade process looks like over here (hand-copied
from very small font on UEFI console, beware of typos):

root on rd0a swap on rd0b dump on rd0b
iwm0: could not read firmware: iwm-7265-16 (error 2)
iwm0: failed to load init firmware
erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to the OpenBSD/amd64 6.0 installation program.
(I)nstall, (U)pgrade, (A)utoinstall, (S)hell? u
At any prompt you can 

Choose your keyboard layout('?' or 'L' for list) [default]
Available disks are: sd0 sd1 sd2.
Which disk the root disk? ('?' for details): [sd0] sd2
Root filesystem? [sd2a]
Checking root filesystem (fsck -fp /dev/sd2a)...OK.
Mounting root filesystem (mount -o ro /dev/sd2a /mnt)...OK.
iwm0: hw rev 0x210, fw ver 16.242414.0, address 34:13:e8:37:4d:51
iwm0: no link  got link
DHCPDISCOVER on iwm0 - interval 3
DHCPOFFER from 217.197.84.34 (fe:e1:54:e3:c3:90)
DHCPREQUEST on iwm0 to 255.255.255.255
DHCPACK from 217.197.84.34 (fe:e1:54:e3:c3:90)
bound to 217.197.84.45 -- renewal in 18000 seconds
Force checking fo clean non-root filesystems? [no]

It has trouble finding firmware at first, which is expected since the
ramdisk does not have it. When the system's root filesystem is mounted,
the firmware is loaded and the device works OK.

What's different in your case?

Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16

[Stefan Sperling]

On Wed, Jun 01, 2016 at 11:12:25PM +0200, Remi Locherer wrote:
> >Synopsis:bsd.rd from May 31 fails to load the firmware for iwm-7265-16
> >Category:kernel
> >Environment:
>   System  : OpenBSD 6.0
>   Details : OpenBSD 6.0-beta (GENERIC.MP) #26: Wed May 25 07:34:23 
> CEST 2016
>
> r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> 
> >Description
> 
> bsd.rd from May 31 fails to load the iwm firmware during an upgrade.
> dmesg says:
> 
> iwm0: could not read firmware iwm-7265-16 (error 2)
> iwm0: failed to load init firmware

The ramdisk kernel tries two directories, /etc/firmware and /mnt/etc/firmware.

Perhaps the above failure is the attempt to load firmware from /etc/firmware,
which does not exist on the ramdisk? I've added the 'failed to load init
firmware' message in the commit which made the dirver use newer firmware.
Before that commit, this failure case was silent. So it is possible that
nothing has changed, except for this message now being printed.

The following line indicates that the second attempt (from /mnt/etc/firmware)
works. It is only printed if firmware could be loaded successfully:

> iwm0: hw rev 0x210, fw ver 16.242414.0, address 5c:e0:c5:1f:ad:c4

> A generic kernel (not bsd.rd!) I built from source on May 31 can load the
> iwm firmware and it works fine.

Are you implying that the device does not work in the ramdisk?