Date: Thu, 30 Nov 2006 08:41:10 -0800 From: Sam Leffler <sam@errno.com> To: John Hay <jhay@meraka.org.za> Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem Message-ID: <456F09A6.7090609@errno.com> In-Reply-To: <20061130142146.GA50022@zibbi.meraka.csir.co.za> References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> <456DD60C.2000208@errno.com> <20061129193842.GA98569@zibbi.meraka.csir.co.za> <20061130120217.GA41346@zibbi.meraka.csir.co.za> <20061130142146.GA50022@zibbi.meraka.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
John Hay wrote: >> Ok, I built a kernel without all those options, but it didn't make a >> difference. I also tried sta mode and it still looks the same. Some >> new info that I have is that when I do a tcpdump on the arm box itself, >> adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing >> packets looks ok, but with it 2 bytes are added between the ether (802.11) >> header and the ip(v6) header. > > Ok, I found the problem. Using LLC_SNAPFRAMELEN works better than > sizeof(struct llc). LLC_SNAPFRAMELEN is defined as 8 and sizeof() > returns 10. Doing a grep in net/ if see that LLC_SNAPFRAMELEN is used > a lot, so I guess this is the correct way go. I nobody has anything > against it, I can commit it. > > With this patch traffic seems to flow normally over the atheros wifi > link. I have not done too much testing, but olsrd works and I can ssh > to it. Very strange. I did not need this change on my systems and was not seeing the problem. But what you found makes sense. > > I see a lot of rix packets: > > Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 > Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 > Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 > Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 > Nov 30 15:49:30 arm-tst kernel: rix 2601 (0) bad ratekbps 0 mode 1 > > I don't see it on our wrap and soekris boxes, but they are running > 6-stable... Well I have seen it, but that was if I put the link in > 11b mode, not in 11a or 11g mode. I'm using 11a at the moment. > > Sam, are they related to the rate changes you made recently? No they are unrelated. These are the complaints I saw in my testing and hadn't had time to resolve. They appear to be caused by extracting bogus rate codes from the h/w descriptors and then feeding them back into the rate control module. I'm still trying to get a new hal out for testing and that hal will have the descriptor state split into cache+uncached areas so I'd prefer to chase any problems like this w/ that code and not code that's about to be replaced. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?456F09A6.7090609>