Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN controller

On Sunday 07 January 2007 14:35, Benjamin Close wrote:
Massimo Lusetti wrote:
On 1/5/07, Max Laier <max@xxxxxxxxxxxxxx> wrote:
Thoughts? Volunteers?

I can say that the first attempt still running fine here on my laptop
on a -STABLE as of yesterday. I use it on a daily basis without any
glitch. I must say i don't do or tried to do nothing special or
network intensive job, but for reading emails, doing a lot of ssh and
http/https the drivers is working smoothly.

I will try to compile this new one on my stable during the week end
and will see on Monday how it will perform on my office wi-lan.

For the records: my wpi doesn't still work on OpenBSD-current cause
it's integrated and the switch used to turn it on seems an acpi one
which OpenBSD doesn't attach very well yet.

Hi Folks,
I did the port as my searching led me to believe that progress on a
driver had stagnated.
Port 1: was done by Damien himself
(http://lists.freebsd.org/pipermail/freebsd-mobile/2006-July/008768.htm
l) Port 2: was an updated version by Daminen:
http://osdir.com/ml/freebsd-hackers@xxxxxxxxxxx/msg58154.html
which seems to be duplicated here:
http://people.freebsd.org/~flz/local/wpi/
(http://www.mail-archive.com/freebsd-net@xxxxxxxxxxx/msg20710.html)
With version 2 being minor bug fixes to version 1 to try and get it
working. Since then the driver has come a long way in netbsd with the
FreeBSD version just getting older.

To others working on a wpi driver, please post something indicating
what you've done and even a sample of what your up to so we can one
build one driver that just works. I also did the driver port as
everything I found failed to work on a 64bit kernel, most the time
wouldn't even compile.

I'm happy to try and maintain this driver. I have the hardware.

Excellent!

The main bugs I know about in this driver port are:

* The use of the iee80211_amrr code
The files exist in -current in /usr/src/sys/net80211 but the required
symbols are not in a GENERIC kernel build. There is a wlan_amrr module
which uses this code, though I'm not sure how to make use of this, it
appears a simple dependency on the module is not enough. The use of the
80211_amrr code also means that use under -stable requires quite a bit
more work as Rink pointed out.

* Bus resource allocation issues
Mainly related to: "bus_dmamem_alloc failed to align memory properly."
I'm hoping Mike
(http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/026262.htm
l) might be able to help resolve these.

These allocation issues are caused while allocating of the rx & tx ring
buffers - which if they are broken explain why things don't work.
I'm still coming to grips to how the whole bus_dma_tag_create works.
The Netbsd bus_dma_map_alloc seems much more intuitive.
I've found if the module failed the first time, unloading it, then
reloading it would often make the allocation issues disappear and the
driver just work.
Though I've also found sometimes that even though the allocation issues
are reported, things still work, I'm guessing the alignment is pulled
into line by higher levels of bus_dma.

* ifconfig down causes timeouts reseting the tx ring
I'm still chasing the cause of this. It seems non critical as the
driver still works with an ifconfig up

* Watch dog timer uses an obsolete interface
I'm looking into the correct way to do watchdog timing

I have patches for iwi(4) somewhere and should finally get to doing
something with them ...

* A lock order reversal in wpi_intr
lock order reversal:
1st 0xffffffff812d9e20 wpi0 (network driver) @ if_wpi.c:1554
2nd 0xffffff003cee32f0 radix node head (radix node head) @
net/route.c:147 KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x3a
witness_checkorder() at witness_checkorder+0x4f9
_mtx_lock_flags() at _mtx_lock_flags+0x75
rtalloc1() at rtalloc1+0x7a
arplookup() at arplookup+0x5c
arpintr() at arpintr+0x255
ether_demux() at ether_demux+0x2d3
ether_input() at ether_input+0x1e9
ieee80211_input() at ieee80211_input+0xd05
wpi_intr() at wpi_intr+0x9d7
ithread_loop() at ithread_loop+0xfe
fork_exit() at fork_exit+0xaa
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffffffa0698d40, rbp = 0 ---

This one looks like the same issue as if_iwi.c, 1.43:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/iwi/if_iwi.c#rev1.43

i.e. just drop the driver lock when calling back into the (net80211)
stack. There is some discussion about how the "ic" is protected, but for
now dropping the lock is the right thing to do.

For those wishing to help debug the driver and get it working, I've
posted a new version
http://www.clearchain.com/~benjsc/download/20070107-wpi-freebsd.tar.gz

Your box seems to have a reasonable uptime. Is that right, or should I
continue to mirror your tarballs?

To help debug:

kldload wpi_ucode
kldload if_wpi
wlandebug -i wpi0 0xffffff (I've included a copy of the -current
tool to save having to checkout the tree)
sysctl debug.wpi=10 (Debug levels are explained in if_wpi.c)
ifconfig wpi0 up
... wait 30 seconds then...
ifconfig wpi0 down

Then put /var/log/messages somewhere on the web & let me know

This will dump lots of debug info to syslog but should help me work out
whats happening. If the driver works for you, stick to debug level 5
max, else you'll be bombarded with logs. I'll try to install FBSD 32
-current & -stable (32/64) on the laptop in the next week to see what
might be different. ANY feedback is helpful.

Finally, for those who see "rx tail flags error xxx" this is caused by
a 802.11 frame with an invalid CRC. Hence seeing the occasional one
(with debug level 4 or higher) is quiet normal. If you see floods of
them then chances are the rx ring is really out of alignment and things
will just be busted.

--
/"\ Best regards, | mlaier@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Attachment: pgpNRaml4uOzM.pgp
Description: PGP signature

Relevant Pages

  • Re: [PATCH/RFC] SPI core: turn transfers to be linked list
    ... And what sort of driver measurements are you doing, to conclude that kmalloc doesn't suffice? ... boiled down to keeping a freelist of some structures in the core. ... Doesn't matter where to put an implementation of this memory allocation model. ... especially if a driver is complicated enuff to have transfers of arbitrary size. ...
    (Linux-Kernel)
  • Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN controller
    ... I did the port as my searching led me to believe that progress on a driver had stagnated. ... Since then the driver has come a long way in netbsd with the FreeBSD version just getting older. ... These allocation issues are caused while allocating of the rx & tx ring buffers - which if they are broken explain why things don't work. ... For those wishing to help debug the driver and get it working, ...
    (freebsd-hackers)
  • Re: How to get the physical page addresses from a kernel virtualaddress for DMA SG List?
    ... > The driver doing the allocation would probably be easier. ... He wants to DMA data ... the exact same page of RAM. ...
    (Linux-Kernel)
  • Re: BAD_POOL_HEADER - BSOD
    ... Carefully check your code to see where you are writing to your ctrack ... structure and see if everything is within the range of the allocation. ... ExFreePool instruction causes driver to crash. ... Pool page 8230f878 region is Unknown ...
    (microsoft.public.development.device.drivers)
  • [PATCH 2/4] spi: split up spi_new_device() to allow two stage registration.
    ... spi_new_deviceallocates and registers an spi device all in one swoop. ... If the driver needs to add extra data to the spi_device before it is ... This patch splits the allocation and registration portions of code out ... +extern struct spi_device * ...
    (Linux-Kernel)