Re: CFT: major wireless changes

On Fri, Jun 01, 2007 at 06:30:02PM -0700, David Wolfskill wrote:
> On Fri, Jun 01, 2007 at 10:49:26AM -0700, Sam Leffler wrote:
> > This patch against HEAD imports the work that's been sitting in the 
> > sam_wifi p4 branch:
> > 
> > http://people.freebsd.org/~sam/sam_wifi-20070601.patch.gz
> ...
> Summmary:
> 
> * ifconfig dumped core; not sure why, and debug version doesn't.

I spent some time poking at this today, after having built a stock
CURRENT, then switching over to the slice where I had the patches
installed.  I did a "cvs update" to get the last 24 hrs. changes to
CURRENT (so comparing against "stock" CURRENT would make more sense);
this proceeded without incident, as did the subseequent "make
buildworld" and friends.

As expected, invoking ifconfig again generated a core file (that wasn't
especially useful).

Rebuilding ifconfig (after touching sbin/ifconfig/ifieee80211.c) with
the -g flag generated an executable that didn't dump core. :-/

So I set about hacking the sources by sprinkling -- rather liberally, in
some cases -- printf()s in places I though might possible be strategic.

The problem appears to have the following characteristics:

* It only shows up for 802.11 devices.  (It did not show up when I
  specified either the xl0 or ed1 device.  It did show up when I
  specified no arguments or if I specified either wi0 or an0.)

* It is, indeed, associated with an exit code ("echo $?") of 139.

* It occurs in the af_other_status() function of ifconfig.c.
  In particular, when af_other_status() is processing an afswtch entry
  with an af_name of "af_ieee80211", afp->af_other_status() is invoked
  with a value (stored in variable "s") of 3, but on return, the value
  of "s" is 0.

* The evidence I was able to obtain appears to show that within
  ieee80211_status(), the value of "s" remains at 3.  (I checked on
  entry, on exit, and after every ioctl() I found in the function.)

* In af_other_status(), the statement immediately following the
  invocation of afp->af_other_status(s) is "setbit(afmask, afp->af_af);".
  I believe that this statement does not complete execution.  IIRC -- I
  managed to fail to document this :-(! -- the value of afp->af_af was
  0 at the time of failure.

I hope this is of use.

Peace,
david
-- 
David H. Wolfskill				david_at_catwhisker.org
Anything and everything is a (potential) cat toy.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.