Re: wpa_supplicant causes panic in ieee80211_newstate

> On Fri, Apr 29, 2005 at 04:18:11PM +0100, Brian Candler wrote:
> [regarding Netgear WG311 (v2) card]
> > I have given the NDIS driver a try, but haven't been able to make it work.
> 
> I see there have been several commits regarding NDIS over the weekend, so
> I've done a cvsup as of around 08:30 UTC 2005-05-09, and a
> complete buildworld/buildkernel cycle. My kernel has:
> 
> device		ndis
> options		NDISAPI
> 
> The good news is that ndisgen and kldload now don't panic the system. The
> bad news is that it still doesn't work with the WG311 drivers.
> 
> Here's what I did to convert the Win2K drivers:

Generally speaking, you should use the Windows XP drivers. (It doesn't
matter for this particular issue, but the WinXP drivers are the ones
that understand the latest 802.11 OIDs in the NDIS 5.1 spec, including
the ones needed to support WPA.)

> ------------------------
> # ndisgen
> 3] convert driver
> > wg311v2.inf
> This .INF file appears to be ASCII.
> > netwg311_2K.sys
> This .SYS file appears to be in Windows(r) PE format.
> Firmware file conversion
> > FwRad16.bin
> > FwRad17.bin
> > FW1130.BIN
> List of files converted firmware files:
> FwRad16.bin.o
> FwRad17.bin.o
> FW1130.BIN.o
> The file netwg311_2K_sys.ko has been successfully generated.
> 4] exit
> ------------------------

This looks fine.

> And here's what happened when I tried to load it:
> 
> # sync
> # kldload ./netwg311_2K_sys.ko
> # tail -5 /var/log/messages
> May  9 16:45:00 foo kernel: ndis0: <NETGEAR WG311v2 802.11g Wireless PCI Adapter> mem 0xfaffc000-0xfaffdfff,0xfafc0000-0xfafdffff irq 11 at device 11.0 on pci2
> May  9 16:45:00 foo kernel: ndis0: [GIANT-LOCKED]
> May  9 16:45:00 foo kernel: ndis0: NDIS API version: 5.0
> May  9 16:45:00 foo kernel: ndis0: init handler failed
> May  9 16:45:00 foo kernel: device_attach: ndis0 attach returned 6

This is not so fine. :(
 
> I also tried:
> 
> # cp FW1130.BIN* FwRad1* /compat/ndis/
> 
> to copy all the .ko and .o files into that location, then did a kldunload
> and kldload of the module. The response in /var/log/messages was exactly the
> same. sysctl shows:
> 
> hw.ndis_filepath: /compat/ndis
> 
> All I can deduce from the source is that ndis_init_nic() failed, code 6
> being ENXIO. Is there anything else I can try, or any way to get more useful
> debugging output?

Not really, I'll have to debug this myself. Luckily, I have one of these
cards. I'll have to pull it out of the pile and stick it in a test target
when I get home. I'm a little confused, because this card did work the
last time I tested it.

When ndis_init_nic() fails, it means the call to the driver's
MiniportInitialize() routine failed, which means any number of
things could have gone wrong. Debugging the problem means tracing
through the MiniportInitialize() process and seeing where it gets
confused.

Note that NdisOpenFile() searches the internal linker list for files
first, and then looks in /compat/ndis. If you tell ndisgen to bundle
all your firmware files into the converted module, then it won't look
in /compat/ndis no matter what you do. If you want to force it to
load files directly out of the filesystem, re-run ndisgen and this
time give it only the .inf and the .sys file. Put the firmware images
in /compat/ndis.

In any case, NdisOpenFile() would have generated some sort of error
message on the console if looking up the files failed, so that's probably
not the issue. Odds are I screwed something else up. :(

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================