Date: Sun, 03 Oct 2004 09:29:09 -0700 From: Sam Leffler <sam@errno.com> To: Matthew Luckie <mjl@luckie.org.nz> Cc: freebsd-mobile@freebsd.org Subject: Re: ath driver on thinkpad R50p Message-ID: <416028D5.4020803@errno.com> In-Reply-To: <20041003203548.S83317@lycra.luckie.org.nz> References: <20041003203548.S83317@lycra.luckie.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Luckie wrote: > Hi > > I'm running BETA7 on a new ThinkPad R50p and have the issue (which i've > seen others having on -mobile). > > http://lists.freebsd.org/pipermail/freebsd-mobile/2004-September/004833.html > > > Here's what is dumped by the ath driver: > > ath0: <Atheros 5212> mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 > ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 > ath0: Ethernet address: 00:05:4e:4a:bd:34 > ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps > > I'm also having trouble compiling the BETA7 code with the patch in > http://people.freebsd.org/~sam/net80211+ath-20040818.tgz > > the patch applies cleanly but it doesn't compile, like > > http://lists.freebsd.org/pipermail/freebsd-mobile/2004-September/004785.html > > > But I thought I'd try and get the 11b modes detected. I did not > succeed, but here's what I saw: > > For the ath_rate_setup call with MODE_11A, the dot11Rate returned in > rs_rates are 130, 132, 139, and 150. I presume they are supposed to be > 2, 4, 10, 22 > > I tried hacking the rs_rates to those values (by subtracting 128 from > dot11Rate), but that did not apparently help detect the 11b modes either. 128 is the bit that indicates the rate is a basic rate. However the issue is in the hal and no amount of hacking rates will help you. > > So I looked at merging some of the extra code in ath_attach before the > calls to ath_rate_setup, but I got stuck at the call to > ath_hal_init_channels. It appears that the prototype is missing the > last parameter - xchanmode, and that appears to depend on what the hal.o > provides. Just set xchanmod to "true" (1); it controls whether to enable channels 13+14 when possible. > > I notice that the HAL has changed and that NetBSD has a more recent HAL, > one with that xchanmode parameter. FreeBSD has 0.9.6.3 while NetBSD has > 0.9.9.13 and perhaps my bug will be fixed with a more recent hal.o Your problem is indeed in the hal and what you need to do is get a more up to date hal. > > I'm happy to test any patches to the ath driver, and I'm also happy to > have a spare clue on where I might focus my efforts in getting the ath > driver going for my particular system. Is there demand for some grunt > work in merging netbsd's changes back to FreeBSD, or has that mostly > been handled for now and will be committed once 5.3 is out the door? I'm trying to update the patch to a more current -current but don't have an updated patch available yet. You can try bringing over code from netbsd or wait for me. > > I know that I could use project evil, but I thought I'd try and get the > source driver going if I could. If you're hungup the ndis driver is an excellent alternative. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416028D5.4020803>