From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Chadd Date: Mon, 25 Mar 2013 12:01:19 -0700 Subject: [ath9k-devel] ath9k not connecting to one particular network.. In-Reply-To: <20130325180307.10928.qmail@stuge.se> References: <20130325101251.GA8819@jouni.qca.qualcomm.com> <20130325113001.GA26285@jouni.qca.qualcomm.com> <20130325163514.GA9373@jouni.qca.qualcomm.com> <20130325180307.10928.qmail@stuge.se> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 25 March 2013 11:03, Peter Stuge wrote: > Me and other ath9k users have experienced various similar problems > for years, across different ath9k hardware. NM was usually not part > of the picture, at least never in my case, my problems were always > with only wpa_supplicant, if that. > > ath9k has improved, but I still have "soft" issues that nobody at QCA > will spend time on, because I'm not significant enough for remote > debugging, because QCA doesn't talk about hardware details with > users, and because problems (obviously) can't be reproduced in > their lab. Dude, I don't know if you've been paying attention, but Felix, Luis and I have been ratcheting up both the developer access (still under NDA for now), information about the hardware in general, and now open source HAL code for the AR9300 and later chips. _I_ got involved in this stuff deep enough and quick enough that they hired me. There's enough information and code out there about how their kit works. A sufficiently motivated developer can dive in and get a lot of interesting work done. The unfortunate truth of the matter is that we don't have the time as developers to support users. But it hasn't stopped developers from diving in and fixing things. It's just that for the most part, people seem scared. I don't know why, Felix/Luis were very supportive and patient with me when I was coming up to scratch on how the 11n chips work as part of FreeBSD development _AND_ we found bugs in ath9k together. Heck, Felix and I are _still_ finding bugs/bad assumptions in ath9k even today, because I'm going through the motions of adding AR9300 support to FreeBSD and doing my own code/documentation review. Now - Linus. I'm glad we got to the root cause of this. I'd really appreciate it if you could find an official Google support path to lodge an actual bug report and get the google chromeos people to work on this. Google have people working both on ath9k and the general Linux wireless infrastructure. They're the ones using open source and they can work with the open source community to get the bugs fixed. _I_ would really like to see more community involvement with OEMs using open source wireless (Linux, BSD, Haiku, etc.) That's partially going to happen through the vendors and it's partially going to happen through OEMs who are deploying them. Let's try to work with both to keep the communication lines open. Finally - Peter, I know you've been burnt in the past. Your posts aren't productive. Some of the bugs can be fixed in software. Some bugs you've brought up in the past require a PCI(e) analyser and logic analyser. I don't (yet) have those at home - but if someone wants to work on an FPGA project to build open source versions of both, I'm all ears. There's practical aspects to all of this which I, Luis and Felix are working on but we don't have the magic answer(s) yet. But please acknowledge all the damned fine work that's been going on lately. Luis and I have spent a lot of my non-work time doing code review and working with QCA legal to get things opened up. You convienently seem to miss that. 2c, Adrian