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: dig -p should abort instead of printing a warning

[Peter van Dijk]

Hello Ted,

On 4 Jun 2016, at 20:28, Ted Unangst wrote:


peter.van.d...@powerdns.com wrote:
Since revision 1.15 at 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bind/bin/dig/dig.c, 
dig ignores the -p option and instead sends to 53. I understand how 
support for pledge() makes it impossible to support -p, however, just 
ignoring the argument leads to several painful potential failure 
modes.



How-To-Repeat:

$ dig -p 5300 www.example.com @localhost
;; Warning, -p option ignored


This should work a little better.


Index: dig.c
===
RCS file: /cvs/src/usr.sbin/bind/bin/dig/dig.c,v
retrieving revision 1.16
diff -u -p -r1.16 dig.c
--- dig.c   11 Nov 2015 02:52:46 -  1.16
+++ dig.c   4 Jun 2016 18:28:08 -
@@ -1192,8 +1192,10 @@ dash_option(char *option, char *next, di
strlcpy(keyfile, value, sizeof(keyfile));
return (value_from_next);
case 'p':
-   fprintf(stderr, ";; Warning, -p option ignored\n");
-   /* port = (in_port_t) parse_uint(value, "port number", 
MAXPORT); */
+   if (parse_uint(value, "port number", MAXPORT) != 53) {
+   fprintf(stderr, ";; Error, only port 53 supported\n");
+   exit(1);
+   }
return (value_from_next);
case 'q':
if (!config_only) {


Did not test it but yes, that should do!

Maybe while you’re at it, also remove/update this line (line 152) from 
dig.c:


" -p port (specify port number)\n"

I notice the man page did get that change.

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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?