On Wed, 2008-07-16 at 15:41 -0400, Clem Taylor wrote:
> I've been running into an annoying kernel panic with madwifi 0.9.4 and
> thought I'd give the trunk a try. I'm using a MIPS processor (Au1550)
> with 2.6.24. I ran into the 'Branch out of range' compile problem and
> had to add '-ffunction-sections' to get if_ath.c to compile.

It's unfortunate, but I don't think MadWifi is to blame for compiler
limitations specific to MIPS.  Perhaps if_ath.c is getting too big and
could be split or rearranged.

> r3773 manages to connect to the network (WPA2-AES) but the performance
> is really horrible (<145KBps vs >2MBps with 0.9.4). athstats shows a
> huge number of 'long on-chip tx retries' and a large number of 'tx
> failed due to too many retries' errors. The antenna profile shows a
> very small number of tx packets and an approximately correct number of
> rx packets (by looking at /proc/net/dev).
> /proc/net/madwifi/ath0/rate_info (minstrel) shows many attempts but a
> very small (or zero) number of successes.

I believe it's all caused by HAL.  That's the reason we haven't made any
releases with the HAL we have in trunk.

You may want to test "sample" instead of "minstrel" to see if it makes
any difference.

> Another weird thing is that the MAC address isn't getting changed
> correctly. For example, I try and set it to 00:18:08:80:00:6B and it
> ends up 06:18:08:80:00:6B (the first byte is wrong). I'm setting it by
> destroying ath0, bringing wifi0 down, setting the address and then
> bringing things back up.

I can assure you that it's done on purpose to avoid MAC address
duplication between VAPs.  It's not caused by memory corruption or some
other bug.  Perhaps the logic should be changed to obey explicit
requests, but it should not be a big deal.

> Has anyone had any luck with recent trunks or can recommend a revision
> that might work a little better?

I'm not aware of any potentially dangerous changes in the trunk
recently.  The problems you reported are unlikely to be caused by recent
changes.  I think the best approach would be to stay on the trunk and
fix or work around problems one-by-one.

-- 
Regards,
Pavel Roskin

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/