Atheros Continued.

[David Zeuthen]

On Sat, 2004-06-26 at 00:38 -0400, Pat Suwalski wrote:
> I decided to take another evening for hal/ath debugging.
> 

Hey, thanks for looking into this,

> Again, very unusual results, as can be seen in the pasted in gdb excerpt 
> from mii_get_rate(). The ->udi field goes crazy for no good reason, and 
> that it what ultimately causes the program to crash.
> 
> There is some sort of memory corruption in mii_get_link(). I know this, 
> because if I return right after the first mdio_read, everything is well. 
> On the other hand, if I comment out the second mdio_read, it will crash 
> because the next line is there. This has been successfully iteratively 
> tested by commenting out successive lines.
> 
> While I could not come to any conclusions whatsoever, commenting out the 
> call to mii_get_link() solves all problems in terms of crashes.
> 
> My suspicions lie in the ioctl() calls within mdio_read, which cause the 
> following:
> 
> [E] linux/net_class_device.c:132 mdio_read() : SIOCGMIIREG on ath0 
> failed: Invalid argument
> 
> That whole function is suspicious and not documented. The way it 
> accesses data[] seems potentially dangerous. The ways it uses 
> new_ioctl_nums is cryptic. However that function pokes at my card might 
> be what's causing a cascade to prevent other io reads from working later 
> and then weird detrimental effects throughout.
> 
> I'm wondering if the 'right' thing to do at this point isn't to actually 
> blacklist ath* from entering mii_get_link(). :(
> 

The Atheros is a wireless card, right? I'm wondering if it make sense to
speak about link at all? 

Since we do test if the networking device is wireless, in this case we
shouldn't test for link. In general, we should also be able to blacklist
problematic by merging a property 'bool net.link_monitor'. Should I go
ahead and add this?

Many thanks,
David



_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal