iwn driver on 7.1

[Brandon Gooch]

The kernel panic was due to a NULL pointer dereference in the module.
The code that was commented out created a situation in which the array
of structs (line 2412):

static const struct iwn_chan_band iwn_bands[]

contained only 2 items. The code following the struct array that
obtained the list of authorized channels:

/* read the list of authorized channels */
	for (i = 0; i < N(iwn_bands)-2; i++)
		iwn_read_eeprom_band(sc, &iwn_bands[i]);

didn't actually get a list of anything, since N(iwn_bands)-2 evaluates
to zero in this case.

The NULL pointer part comes in when the call to
ieee80211_sort_channels() on line 2436 sends a list of no items with a
value of 0 for ic->ic_nchans. The backported insertion sort code from
8.0-CURRENT's 802.11 stack fails somewhere because of this value, due
to access of some memory address in the chancompar() or swap(?) -- I
didn't really dig that far into it.

I guess the purpose of commenting out the A channels in the
iwn_bands[] was to keep the driver from potentially using them, but
honestly, I'm not sure if that's the appropriate way to do that (I'm
just getting into this stuff). I'm sure the MFC'd VAP stuff that Sam
Leffler is working on will alleviate all of this, but I wanted a
working iwn(4) for now ;)

On Sun, Jan 18, 2009 at 4:10 PM, Jan Henrik Sylvester <me at janh.de> wrote:
> Da Rock wrote:
>>
>> On Sun, 2009-01-18 at 14:17 -0600, Brandon Gooch wrote:
>>>
>>> I have a working driver for the Intel 4965, aka iwn(4), loaded on my
>>> Lenovo X300 running FreeBSD 7.1-RELEASE (amd64).
>>>
>>> This driver is a slightly-modified version of the iwn(4) driver
>>> backported from 8.0-CURRENT by Gavin Atkinson:
>>>
>>>
>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=221758+0+/usr/local/www/db/text/2008/freebsd-stable/20080928.freebsd-stable
>>>
>>> I was seeing the same symptoms described in these threads (among others):
>>>
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045264.html
>>>
>>>
>>> http://www.freebsd.org/cgi/getmsg.cgi?fetch=1334322+1338147+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions
>>>
>>>
>>> http://www.freebsd.org/cgi/getmsg.cgi?fetch=1418632+1421765+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions
>>>
>>> ...so I debugged and modified Gavin's driver for my system.
>>>
>>> The driver and the source tree diff can be downloaded here for any
>>> brave souls wanting to test it out:
>>>
>>> http://sites.google.com/site/bsdgooch/files
>>>
>>> I'm using the driver now to send this e-mail over a link to my TP-LINK
>>> TL-WR941ND access point (with WPA2). Feedback and bug reports would be
>>> useful.
>>>
>>> -brandon
>>
>> Sounds like you got to it before I did- thank god! :)
>>
>> Question though: have you got it figured for a channels yet?
>>
>> I'll test it for you and keep you updated with my results.
>
> Thanks for working on the driver!
>
> The only difference to the version of gavin that I could see is that the
> bands in iwn_bands that got commented out were brought back. Or did I miss
> something? Do you know why they were commented out and it was unnecessary?
> Or was it just to fix the crash?
>
> I did a few test runs: It does not crash immediately as the version from
> gavin, but the error I had with the perforce version
>  iwn0: error, INTR=82000000<SW_ERROR,RX_INTR> STATUS=0x10000
>  iwn0: iwn_config: could not set power mode, error 35
> is there -- in 3 out of 3 tries. So nothing improved there. (I hit that
> error on first use in about 50% of the cases before.)
>
> Moreover, at 3 out of 4 tries to 'kldunload if_iwn' after hitting the error
> (after '/etc/rc.d/netif stop iwn0' and 'ifconfig iwn0 down'), there was a
> crash: 2 page faults and 1 freeze. I have not had that with the perforce
> version. (Maybe once long ago, but I think I forgot to stop iwn0 at that
> time.)
>
> The one time I actually got the (WPA2) connection up, I was able to transfer
> with a similar speed as with the perforce version.
>
> Thus, for me, there are no improvement over the (old) perforce version.
> Probably by chance, but I had more crashes.
>
> I think the thread on stable@ should rather be continued than the one on
> questions@, but since Da Rock answered on questions@, I reinclude both.
>
> Cheers,
> Jan Henrik
>