On Mon, Apr 11, 2011 at 9:40 PM, Hasan Rashid <hras...@avionica.com> wrote:
>
> The throughput results are consistent regardless of mixed or purely 802.11n
> clients. If you notice the iw phy info shows only non-HT data rates. This
> wasn't the case when I used a Ralink 2860 chipset based card.
to make sure that HT is configured in driver please do this
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 1b5bd13..720a866 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
else
pCap->hw_caps &= ~ATH9K_HW_CAP_HT;
+ pCap->hw_caps |= ATH9K_HW_CAP_HT;
+
if (AR_SREV_9271(ah))
pCap->num_gpio_pins = AR9271_NUM_GPIO;
else if (AR_DEVID_7010(ah))
>
> Hasan R.
>
> -----Original Message-----
> From: Mohammed Shafi [mailto:shafi.at...@gmail.com]
> Sent: Monday, April 11, 2011 12:05 PM
> To: Hasan Rashid
> Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org; Peter Stuge
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Mon, Apr 11, 2011 at 6:58 AM, Hasan Rashid <hras...@avionica.com> wrote:
>>
>> I have contacted the manufacturer of the card as well. The correspondent
>> claimed to have used ath9k without any issues. When I first rant lspci the
>> output looked suspiciously bogus to me as well for this card.
>>
>> I am using a Ubuntu 10.10 x86 distro and I have little reason to believe
>> lspci has a bug in it. It's most likely that card's eeprom has a bogus
>> vendor id in it. Any how, I was able to modify the code to load the driver
>> for this vendor id. The only problem now is that the driver transmit at
>> non-HT rates only.
>>
>> The iw phy info output is attached. I have about 29 clients associated with
>> this AP.
>
> if you have 29 clients and incase you run the traffic surely the rate will be
> low and what about the legacy stations.
>
>>
>> Hasan R.
>>
>>
>> -----Original Message-----
>> From: ath9k-devel-boun...@lists.ath9k.org
>> [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Mohammed
>> Shafi
>> Sent: Sunday, April 10, 2011 11:41 AM
>> To: Adrian Chadd
>> Cc: ath9k-devel@lists.ath9k.org; Peter Stuge
>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>> On Sun, Apr 10, 2011 at 9:04 PM, Adrian Chadd <adr...@freebsd.org> wrote:
>>> Incorrect or misplaced EEPROM/OTP data, perhaps?
>>> From what I gather, the PCI ID on earlier devices is loaded out of
>>> EEPROM by the silicon itself at power-on. 'abcd' sounds a bit too
>>> convenient to be what's in EEPROM/OTP; so maybe it's a default value in the
>>> silicon?
>>> (All just conjecture here at this point.)
>>
>> Yes, 'abcd' surely looks like a default value stored.
>>
>>>
>>> Adrian
>>> On 10 April 2011 23:17, Mohammed Shafi <shafi.at...@gmail.com> wrote:
>>>>
>>>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <pe...@stuge.se> wrote:
>>>> > Mohammed Shafi wrote:
>>>> >> > Is this a serious proposal from Atheros, or just your attempt
>>>> >> > at a quick fix?
>>>> >>
>>>> >> No! its purely a personal idea (am completely responsible for the
>>>> >> mistake),and I will take a look at it carefully to fix this.
>>>> >
>>>> > Sorry, I didn't mean that you made a mistake, just that the
>>>> > suggestion probably would not get us closer to the actual issue.
>>>> >
>>>> > Bus level issues are indeed difficult. :\
>>>>
>>>> thanks, i did not know that. thought simple as adding another device id.
>>>> >
>>>> >
>>>> >> > A device having an unexpected PCI id means that something is
>>>> >> > really wrong in the device or on the bus, and the solution is
>>>> >> > rarely to pretend that it didn't happen.]
>>>> >>
>>>> >> Yeah I can see that, hoping that I may get a correct Device ID
>>>> >> from the reporter. I dont think 'abcd' is a proper vendor id.
>>>> >
>>>> > Yes, it's easy to spot. The question is how we can find out *why*
>>>> > this happened, so that this error case can be prevented.
>>>>
>>>> Yes sure.
>>>> >
>>>> >
>>>> >> > Since this card should work fine in principle, maybe it's some
>>>> >> > issue with missing, or wrong, firmware stored on the Linux system.
>>>> >>
>>>> >> AR9382 does not seems to have firmware
>>>> >
>>>> > Aha! That's only for the USB devices maybe. I don't know much
>>>> > detail for these latest devices.
>>>> >
>>>> currently only ath9k_htc needs firmware.
>>>>
>>>> >
>>>> >> and you have any idea what might went wrong.
>>>> >
>>>> > Sorry, I don't understand what you mean here.
>>>>
>>>> Your suggestions about what might have went wrong, as you had
>>>> already told it might be a bus level issue.
>>>>
>>>> >
>>>> >
>>>> >> Also why its detected as Ethernet Controller rather than Network
>>>> >> controller.
>>>> >
>>>> > This string comes from the pciutils package and could easily have
>>>> > changed. Better look at the numerical device class code, which is
>>>> > what is read from hardware.
>>>>
>>>> thanks, I will look into that.
>>>>
>>>> >
>>>> > But I expect that when one thing in config space (device id) is
>>>> > bogus then the rest of config space is also quite possibly bogus,
>>>> > for the same reason, whatever it is.
>>>> >
>>>> >
>>>> > //Peter
>>>> > _______________________________________________
>>>> > ath9k-devel mailing list
>>>> > ath9k-devel@lists.ath9k.org
>>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>> >
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel@lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel@lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>> This communication contains information that may be confidential or
>> privileged. The information is solely intended for the use of the addressee.
>> If you are not the intended recipient, be advised that any disclosure, copy,
>> distribution, or use of the contents of this communication is prohibited. If
>> you have received this communication in error, please immediately notify the
>> sender by telephone or by electronic mail.
> This communication contains information that may be confidential or
> privileged. The information is solely intended for the use of the addressee.
> If you are not the intended recipient, be advised that any disclosure, copy,
> distribution, or use of the contents of this communication is prohibited. If
> you have received this communication in
> error, please immediately notify the sender by telephone or by electronic
> mail.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
