CFT: major wireless changes
david at catwhisker.org
Sun Jun 3 00:57:16 UTC 2007
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
> * 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
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070603/c8a5464d/attachment.pgp
More information about the freebsd-current