# Seems madwifi-ng is screwed for my hardware since 0.9.2[sol]

## Jykke

I have netgear - is it WG300T or something with atheros chipset - actually on two machines.

Now I started installing gentoo on the other machine as well. It was no joy - I got something like

this for loading ath_pci module:

ath_hal: module license 'Proprietary' taints kernel.

ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)

wlan: 0.8.4.2 (0.9.3)

ath_pci: 0.9.4.5 (0.9.3)

ACPI: PCI Interrupt 0000:00:0c.0[A] -> GSI 17 (level, low) -> IRQ 169

Unable to load needed module: ath_rate_sample; no support for automatic module loading<3>Error loading module "ath_rate_sample"

I then masked 0.9.3 and stuff installed again 0.9.2 and module loads and I get ath0 interface. Is this known or am I just

too stupid and missed some trick that everyone knows?

I have been masking madwifi on the other machine already for a longer time but it is a kind of

bother to always look through the list once doing emerge -uDavn world to see if there is yet another

non-working madwifi pending...Last edited by Jykke on Sat May 26, 2007 12:28 pm; edited 1 time in total

----------

## Paczesiowa

I had that problem. I think you need to modprobe modules in correct order to get >=0.9.3 working. the easiest way to do this is actually to enable automodule loading in kernel.

----------

## Jykke

I have it enabled and I don't understand the bit from loading modules in right order. For

madwifi I have only one module to load ath_pci and that's that.

----------

## Paczesiowa

maybe dont modprobe ath_pci. let it get loaded by itself.

----------

## terminallymortal

I had the same problem.  I found this order of module insertion worked:

ath_hal

wlan

ath_rate_sample

ath_pci 

others

(specifically ath_rate_sample before ath_pci)

----------

## mangylj

I have a Dlink DWL-G520 Rev.B, and I experience the same problem with then new madwifi-ng driver...

I absolutely detest updating anything related to my network, since it breaks it as a rule.  *growls*

Anyways, I'll try to change the module order in  modules.autoload according to teminallymortal, but I doubt it'll work.  :Razz: 

My pro solution for these problems is usually to put madwifi-ng in rsync_exludes, but this update has some good security fixes afaik..

Well, I'll report back with the results.

----------

## mangylj

Well, no, it didn't work..

Hm, I've got a slightly different problem than Jykke.. Guess I'll make a new post. :S

----------

## wyv3rn

You need to recompile your kernel with CONFIG_KMOD=y then udev will handle all the module loading.

You should not need to load any modules from /etc/modules.autoload.d/*

And if you still have an /etc/udev/rules.d/65-madwifi.rules from old versions you should remove it.

The only options you may want to modify are now held in /etc/modules.d/ath_pci

----------

## terminallymortal

The problem with letting udev handle it is that, as far as I can tell, you can't control the order, so it will load ath_pci before rate sample, and completely disregard the contents of /etc/modules.autoload.d/*

You can keep udev from handling it and thus control the order via modules.autoload.d by changing to RC_COLDPLUG="no" in /etc/conf.d/rc

/etc/modules.autoload.d/* is really unused if RC_COLDPLUG is set to yes...

----------

## wyv3rn

 *terminallymortal wrote:*   

> The problem with letting udev handle it is that, as far as I can tell, you can't control the order, so it will load ath_pci before rate sample, and completely disregard the contents of /etc/modules.autoload.d/*

 

That is what it is supposed to do.  ath_pci is requesting ath_rate_sample to be loaded as a dependency.  Since the OP does not have his kernel compiled with CONFIG_KMOD=y it is failing to load ath_rate_sample.  Fix this and all /etc/modules.autoload.d/ hackery is unnecessary.

http://madwifi.org/changeset/2168

----------

## Jykke

I have CONFIG_KMOD=y

and I have that COLDPLUG bit set to yes - ath_pci is uncommented in modules.autoload.d/kernel.2.6 so what gives.

Although it has been awhile now before I tried the new madwifi and I might have uncommented the

ath_pci later so I'll give it another try in next boot.

----------

## Jykke

Indeed that seems to have done the trick.

Remove ath_pci and stuff from modules.autoload.d and so on.

I have made quite a few other changes since I reported the problem

so it might be something else too but now it seemed to work ok...

I don't remember when I uncommented the ath_pci away...

----------

## r00dy

 *wyv3rn wrote:*   

> You need to recompile your kernel with CONFIG_KMOD=y then udev will handle all the module loading.
> 
> You should not need to load any modules from /etc/modules.autoload.d/*
> 
> And if you still have an /etc/udev/rules.d/65-madwifi.rules from old versions you should remove it.
> ...

 

I've modified options in /etc/modules.d/ath_pci to autocreate AP mode.

But I'm getting the managed mode all the time (on boot or while modprobing by hand). 

My /etc/modules.d/ath_pci:

```

options ath_pci autocreate=ap xchanmode=1

```

Are these options correct?

----------

