Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Jun 2007 17:55:53 -0700
From:      David Wolfskill <david@catwhisker.org>
To:        Sam Leffler <sam@errno.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: CFT: major wireless changes
Message-ID:  <20070603005553.GJ27746@bunrab.catwhisker.org>
In-Reply-To: <20070602013002.GH27746@bunrab.catwhisker.org>
References:  <46605C26.9090304@errno.com> <20070602013002.GH27746@bunrab.catwhisker.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--7AwgMNpd3VkAVXjS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
> > sam_wifi p4 branch:
> >=20
> > http://people.freebsd.org/~sam/sam_wifi-20070601.patch.gz
> ...
> Summmary:
>=20
> * 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
--=20
David H. Wolfskill				david@catwhisker.org
Anything and everything is a (potential) cat toy.

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

--7AwgMNpd3VkAVXjS
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)

iEYEARECAAYFAkZiEZgACgkQmprOCmdXAD0/2QCdG5SvLFecmo/I8qoWitJu3LWA
DokAmQGrJt6i2yMcsxzGoEDkvrhuLvw5
=NyAv
-----END PGP SIGNATURE-----

--7AwgMNpd3VkAVXjS--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070603005553.GJ27746>