[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Alex Hacker]

Adrian Chadd wrote:
> Is there an easy way to get an EEPROM/OTP contents dump in ath9k?

For AR93xx you can try to use the following script:

#!/usr/bin/perl -w

my $debugPath = '/debug/ath9k/phy0';

sub RegGet($)
{
  open(F,">$debugPath/regidx") or die("Unable to open $debugPath/regidx.");
  printf(F "0x%x\n",shift());
  close(F);

  open(F,"$debugPath/regval") or die("Unable to open $debugPath/regval.");
  local $val = <F>;
  $val =~ s/\s+$//g;
  close(F);

  return hex($val);
}

sub EepromRead($)
{
  RegGet(0x2000 + ((shift()/2) << 2));
  while ((RegGet(0x4084) & 0x50000) != 0) {}
  return RegGet(0x4084);
}

for (local $addr = 0; $addr < 0x400; $addr += 2)
{
  printf("\n%04x:",$addr) if ($addr%16 == 0);
  local $val = EepromRead($addr);
  printf(" %02x %02x",$val >> 8,$val & 0xff);
}
printf("\n");

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Steffen Dettmer]

Hi,

some time ago there was a thread "Sparklan WPEA-121N AR9382 168c:abcd" about the issue that the mentioned device was erroneously reported as device ID 0xabcd. There were EEPROM issues assumed and BIOS issues reported that could cause this effect (by resetting the PCI bus at system power on) and a proposed workaround to add the wrong ID to the driver to make it load - it had been reported working.

I'm facing such a situation with embedded devices (I assume BIOS updates probably are at least very difficult) and a WPEA-127N and would like to know whether there were new findings and share mine in case they'd be of some interest.

Are there any news on that?

Is the proposed workaround adding 0xabcd to the driver still best way of handling this?

On my board it happens /from time to time/ that the device reports 0xabcd - but not always.

I made 20 tests were I saw 4 such failures. All those failures appeared after cold boot, but none after warm boot. After cold boot sometimes one of two installed devices appeared with wrong device ID but other correctly, and at other times both were working. Of course the number of tests is insufficient to draw conclusions, I write it just in case it rings a bell.

It is some Intel atom board running Linux (for example, Debian 7). Can I provide information that could help (and if so, how do I get those)?

Best regards,
Steffen

Some test results:

root at nomad:~# lspci|grep -i ath
01:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01)
07:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01)
root at nomad:~# grep '' /sys/devices/pci0000:00/0000:00:1c.*/0000:0{1,7}:00.0/{vendor,device}
/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/vendor:0x168c
/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/device:0xabcd
/sys/devices/pci0000:00/0000:00:1c.2/0000:07:00.0/vendor:0x168c
/sys/devices/pci0000:00/0000:00:1c.2/0000:07:00.0/device:0xabcd
root at nomad:~# reboot
[ssh...]
root at nomad:~# lspci|grep -i ath
01:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01)
07:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01)
root at nomad:~# grep '' /sys/devices/pci0000:00/0000:00:1c.*/0000:0{1,7}:00.0/{vendor,device}
/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/vendor:0x168c
/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/device:0x0030
/sys/devices/pci0000:00/0000:00:1c.2/0000:07:00.0/vendor:0x168c
/sys/devices/pci0000:00/0000:00:1c.2/0000:07:00.0/device:0x0030


root at nomad:/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0# grep '' *
broken_parity_status:0
class:0x020000
Binary file config matches
consistent_dma_mask_bits:32
device:0xabcd
dma_mask_bits:32
enable:0
grep: firmware_node: Is a directory
irq:10
local_cpulist:0-31
local_cpus:ffffffff
modalias:pci:v0000168Cd0000ABCDsv00000000sd00000000bc02sc00i00
grep: power: Is a directory
grep: remove: Permission denied
grep: rescan: Permission denied
grep: reset: Permission denied
resource:0x00000000fdfe0000 0x00000000fdffffff 0x0000000000140204
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x00000000fdfd0000 0x00000000fdfdffff 0x000000000004e200
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
grep: resource0: Input/output error
grep: rom: Invalid argument
grep: subsystem: Is a directory
subsystem_device:0x0000
subsystem_vendor:0x0000
uevent:PCI_CLASS=20000
uevent:PCI_ID=168C:ABCD
uevent:PCI_SUBSYS_ID=0000:0000
uevent:PCI_SLOT_NAME=0000:01:00.0
uevent:MODALIAS=pci:v0000168Cd0000ABCDsv00000000sd00000000bc02sc00i00
vendor:0x168c

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

Hi,

The general consensus at work is - BIOSes are buggy and don't
necessarily reset the PCI bus correctly.

So either you can do your own PCI bus reset post-boot (and
re-enumerate all the PCI devices, including initialising their BARs)
or smack your vendor to fix their BIOSes. I can't really make any
further suggestions besides that.


Adrian

On 27 March 2013 11:34, Steffen Dettmer <steffen.dettmer@nomadrail.com> wrote:
> Hi,
>
> some time ago there was a thread "Sparklan WPEA-121N AR9382 168c:abcd" about the issue that the mentioned device was erroneously reported as device ID 0xabcd. There were EEPROM issues assumed and BIOS issues reported that could cause this effect (by resetting the PCI bus at system power on) and a proposed workaround to add the wrong ID to the driver to make it load - it had been reported working.
>
> I'm facing such a situation with embedded devices (I assume BIOS updates probably are at least very difficult) and a WPEA-127N and would like to know whether there were new findings and share mine in case they'd be of some interest.
>
> Are there any news on that?
>
> Is the proposed workaround adding 0xabcd to the driver still best way of handling this?
>
> On my board it happens /from time to time/ that the device reports 0xabcd - but not always.
>
> I made 20 tests were I saw 4 such failures. All those failures appeared after cold boot, but none after warm boot. After cold boot sometimes one of two installed devices appeared with wrong device ID but other correctly, and at other times both were working. Of course the number of tests is insufficient to draw conclusions, I write it just in case it rings a bell.
>
> It is some Intel atom board running Linux (for example, Debian 7). Can I provide information that could help (and if so, how do I get those)?
>
> Best regards,
> Steffen
>
> Some test results:
>
> root at nomad:~# lspci|grep -i ath
> 01:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01)
> 07:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01)
> root at nomad:~# grep '' /sys/devices/pci0000:00/0000:00:1c.*/0000:0{1,7}:00.0/{vendor,device}
> /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/vendor:0x168c
> /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/device:0xabcd
> /sys/devices/pci0000:00/0000:00:1c.2/0000:07:00.0/vendor:0x168c
> /sys/devices/pci0000:00/0000:00:1c.2/0000:07:00.0/device:0xabcd
> root at nomad:~# reboot
> [ssh...]
> root at nomad:~# lspci|grep -i ath
> 01:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01)
> 07:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01)
> root at nomad:~# grep '' /sys/devices/pci0000:00/0000:00:1c.*/0000:0{1,7}:00.0/{vendor,device}
> /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/vendor:0x168c
> /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/device:0x0030
> /sys/devices/pci0000:00/0000:00:1c.2/0000:07:00.0/vendor:0x168c
> /sys/devices/pci0000:00/0000:00:1c.2/0000:07:00.0/device:0x0030
>
>
> root at nomad:/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0# grep '' *
> broken_parity_status:0
> class:0x020000
> Binary file config matches
> consistent_dma_mask_bits:32
> device:0xabcd
> dma_mask_bits:32
> enable:0
> grep: firmware_node: Is a directory
> irq:10
> local_cpulist:0-31
> local_cpus:ffffffff
> modalias:pci:v0000168Cd0000ABCDsv00000000sd00000000bc02sc00i00
> grep: power: Is a directory
> grep: remove: Permission denied
> grep: rescan: Permission denied
> grep: reset: Permission denied
> resource:0x00000000fdfe0000 0x00000000fdffffff 0x0000000000140204
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x00000000fdfd0000 0x00000000fdfdffff 0x000000000004e200
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> resource:0x0000000000000000 0x0000000000000000 0x0000000000000000
> grep: resource0: Input/output error
> grep: rom: Invalid argument
> grep: subsystem: Is a directory
> subsystem_device:0x0000
> subsystem_vendor:0x0000
> uevent:PCI_CLASS=20000
> uevent:PCI_ID=168C:ABCD
> uevent:PCI_SUBSYS_ID=0000:0000
> uevent:PCI_SLOT_NAME=0000:01:00.0
> uevent:MODALIAS=pci:v0000168Cd0000ABCDsv00000000sd00000000bc02sc00i00
> vendor:0x168c
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

Adrian Chadd wrote:
> The general consensus at work is - BIOSes are buggy

That is very true..


> and don't necessarily reset the PCI bus correctly.

..but this doesn't make any sense at all.


> So either you can do your own PCI bus reset post-boot

What *exactly* is meant by "PCI bus reset" here? I ask because those
words don't map to any of the tasks of PC firmware.


> I can't really make any furthere suggestions besides that.

I'm afraid "PCI bus reset" is no suggestion, because it means
nothing. Please go into (much) more detail about what the hardware
requires?


Thanks

//Peter

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

Sure, here's what's going on:

* There's a PCI bus reset. It's a pin. On the PCI bus.
* The BIOS can yank that down to reset all the devices.
* There's timing requirements for how long that pin can be pulled down
to reset and release.
* After the PCI bus is reset, the atheros MAC initialises the PCI
space by reading a bunch of values from EEPROM/OTP and writing them
into the register space. Most of these are PCI space registers but
there can be others.
* Some vendors do daft things, like multiple quick PCI bus resets
back-to-back rather than doing a reset and waiting for whatever the
standard requires or the best practice is; or just asserting reset
quickly rather than holding it down for the required time is;
* .. and this can interrupt / confuse the MAC during this whole
register initialisation path.

So, the "quick" fix is to re-reset the PCI slot or the PCI bus. But I
think that requires you to take care of PCI device resource allocation
and enumeration; which the Linux kernel may or may not do. For
cardbus/expresscard devices there's some resource allocation going on,
but not necessarily for always-attached cards.

The real fix is to smack the heck out of BIOS writers who do strange
and wonderful crap in their BIOS when resetting and enumerating PCI
devices.




Adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Michael Schwingen]

Am 27.03.2013 23:33, schrieb Adrian Chadd:
> Sure, here's what's going on:
>
> * There's a PCI bus reset. It's a pin. On the PCI bus.
> * The BIOS can yank that down to reset all the devices.
> * There's timing requirements for how long that pin can be pulled down
> to reset and release.
> * After the PCI bus is reset, the atheros MAC initialises the PCI
> space by reading a bunch of values from EEPROM/OTP and writing them
> into the register space. Most of these are PCI space registers but
> there can be others.
> * Some vendors do daft things, like multiple quick PCI bus resets
> back-to-back rather than doing a reset and waiting for whatever the
> standard requires or the best practice is; or just asserting reset
> quickly rather than holding it down for the required time is;
> * .. and this can interrupt / confuse the MAC during this whole
> register initialisation path.
I have had this on an ambedded design - IIRC with an AR5414, back when
Atheros switched from 3-wire EEPROMs to I2C EEPROMs on the MiniPCI modules.

If you do a PCI reset just at the time when the MAC is doing an I2C
read, the I2C EEPROM will hang in the middle of a bus cycle, with no
possibility to reset it when the MAC does the next read access, so at
least the first read will get corrupt data.

AFAIK, the PCI standard does not forbid this (there are only minimum
times for *assertion* of the reset signal), so technically, the card
violates the PCI spec if it can't cope with two PCI resets in direct order.

However, I would consider this really bad practice.

In our case, inserting a minimum delay between the point where the
hardware de-asserts reset and the point where the code re-asserts it
(because it might be a warm boot) fixed the problem reliably.

cu
Michael

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

Michael Schwingen wrote:
> If you do a PCI reset just at the time when the MAC is doing an I2C
> read, the I2C EEPROM will hang in the middle of a bus cycle, with no
> possibility to reset it when the MAC does the next read access, so at
> least the first read will get corrupt data.

Yes, that makes sense.


> AFAIK, the PCI standard does not forbid this (there are only minimum
> times for *assertion* of the reset signal), so technically, the card
> violates the PCI spec if it can't cope with two PCI resets in direct
> order.

I agree.


> However, I would consider this really bad practice.

I agree that violating the spec is bad practice. I don't agree that
permitted reset patterns are bad practice. Especially I do not agree
that doing anything quicker than normal, while staying compliant, is
bad practice.


> In our case, inserting a minimum delay between the point where the
> hardware de-asserts reset and the point where the code re-asserts it
> (because it might be a warm boot) fixed the problem reliably.

Thanks for the detailed information!


It makes perfect sense that the I?C transaction would be interrupted.

It would be very simple to investigate that on problematic hardware
with something quite low cost such as the $50 Openbench Logic Sniffer
or even a Logic Shrimp.


//Peter

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

Adrian Chadd wrote:
> the "quick" fix is to re-reset the PCI slot or the PCI bus.

Read the quote from Daniel's email again. It explains how that caused
the problem.

In his bad case there was a reset at time 1 and another reset at time 2.

Removing the reset at time 1 and keeping an unchanged reset at time 2
made the problem disappear.

It seems that the hardware could not handle the reset at time 1,
presumably because the reset was incorrect per the specification.

The reset at time 2 is presumably correct, since things work with it.

If something (the reset at time 1) is able to screw up hardware so
badly that even a correct reset (time 2) does not *actually* reset
the hardware then I would consider that a very serious bus IP
problem in the hardware.

It would be interesting to know if this is *really* the problem. I'm
not at all sure.


> PCI device resource allocation and enumeration; which the Linux
> kernel may or may not do.

It does not.


> The real fix is to smack the heck out of BIOS writers who do
> strange and wonderful crap in their BIOS when resetting

Enumeration comes much later. The only two possibilities are a. the
reset at time 1 violated the specification and b. the hardware
doesn't handle multiple resets reliably.

It would be good to get more detail about what exactly makes the
hardware fail to initialize registers from the EEPROM.

I don't think there's such a thing as "best practise" on a bus.
Either the spec is followed (by everyone) or it isn't. :)


//Peter

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

On 27 March 2013 16:04, Peter Stuge <peter@stuge.se> wrote:
> Adrian Chadd wrote:

> If something (the reset at time 1) is able to screw up hardware so
> badly that even a correct reset (time 2) does not *actually* reset
> the hardware then I would consider that a very serious bus IP
> problem in the hardware.

Hey, I'm just a programmer. :-) I'm just saying what I've seen and read.


> Enumeration comes much later. The only two possibilities are a. the
> reset at time 1 violated the specification and b. the hardware
> doesn't handle multiple resets reliably.

It's not handling the back-to-back resets well.

> It would be good to get more detail about what exactly makes the
> hardware fail to initialize registers from the EEPROM.

Well, for failing units I would like to know if they hvae EEPROM or
not. There's a small amount of one-time programmable (OTP) PROM that
we can store configuration bits in. I'd be interested to know if the
failing setup occurs with units that _don't_ have EEPROM and are just
using the OTP. And yes, the OTP controller AFAIK is also connected via
some kind of shifting interface; it's not directly memory mapped. So I
guess it's plausible that it's also failing.

And thanks for the more thorough description. I'll poke the hardware
people and see what the story is. I'm kinda surprised that this hasn't
been fixed in subsequent chips but chances are it boils down to "noone
expects such unpredictable system hardware." :-)



adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Daniel Smith]

On Wed, Mar 27, 2013 at 7:04 PM, Peter Stuge <peter@stuge.se> wrote:

> Adrian Chadd wrote:
> > the "quick" fix is to re-reset the PCI slot or the PCI bus.
>
> Read the quote from Daniel's email again. It explains how that caused
> the problem.
>
> In his bad case there was a reset at time 1 and another reset at time 2.
>
> Removing the reset at time 1 and keeping an unchanged reset at time 2
> made the problem disappear.
>
> It seems that the hardware could not handle the reset at time 1,
> presumably because the reset was incorrect per the specification.
>

It wasn't that it could not handle the reset a time 1 but that the reset at
time 2 was causing the issue that Michael explained with hanging the
EEPROM. So it is not that either reset was more appropriate than the other
but that for this BIOS implementation it was better to remove time 1 and
keep time 2 since one reset really was needed.


> The reset at time 2 is presumably correct, since things work with it.
>
> If something (the reset at time 1) is able to screw up hardware so
> badly that even a correct reset (time 2) does not *actually* reset
> the hardware then I would consider that a very serious bus IP
> problem in the hardware.
>
> It would be interesting to know if this is *really* the problem. I'm
> not at all sure.
>
>
> > PCI device resource allocation and enumeration; which the Linux
> > kernel may or may not do.
>
> It does not.
>
>
> > The real fix is to smack the heck out of BIOS writers who do
> > strange and wonderful crap in their BIOS when resetting
>
> Enumeration comes much later. The only two possibilities are a. the
> reset at time 1 violated the specification and b. the hardware
> doesn't handle multiple resets reliably.
>

The vendor never mentioned whether this was out of spec or if the card was
not compliant but I can say that this was not the first issue we had run
into with a BIOS. Another instance was making assumptions that no one would
ever have more than 20 PCIe devices connected to the bus. This was an
artificial limit imposed by the BIOS writter that did technically violate
the spec.

It would be good to get more detail about what exactly makes the
> hardware fail to initialize registers from the EEPROM.
>
> I don't think there's such a thing as "best practise" on a bus.
> Either the spec is followed (by everyone) or it isn't. :)
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130401/77c3fb90/attachment.htm 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Steffen Dettmer]

Hi all,

thanks for all your replies. Let me tell my findings just in case
it helps.

* adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] wrote:
> The general consensus at work is - BIOSes are buggy and don't
> necessarily reset the PCI bus correctly.
> 
> So either you can do your own PCI bus reset post-boot (and
> re-enumerate all the PCI devices, including initialising their
> BARs) or smack your vendor to fix their BIOSes. I can't really
> make any further suggestions besides that.

I talked with an expert of my unit about "resetting PCI express
cards". The units have a special controller (I^2C) able to power
off and power on the card slots. I was told that this does not
handle the PCI reset line correctly ("leaves it open"), but makes
"a hard cut to the 3 volts" (I hope I repeat it correctly).

For my WPEA-121N cards, such a power cycle in my tests so far
worked around the issue.

I tested ~30 main unit power cycles where I had 4 occurrences of
the issue. No extra steps were needed (Linux 3.2 automatically
detected the correctly after each slot power on, hundreds of
slot power cycles tested). So fine for me.

root at nomad:~# lspci|grep -i ath
01:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01)
root at nomad:~# i2cset -y 14 0x20 0x0
root at nomad:~# sleep 1
root at nomad:~# i2cset -y 14 0x20 0x1f
root at nomad:~# lspci|grep -i ath
01:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01)

I also tried :

root at nomad:~# echo "0" > /sys/bus/pci/slots/1/power
root at nomad:~# echo "1" > /sys/bus/pci/slots/1/power

this makes the device disappearing temporarily but does not have
the desired effect of "fixing" the vendor ID.

Happy Easter!

Regards
Steffen

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Michael Schwingen]

On 03/28/2013 04:04 PM, Steffen Dettmer wrote:
>
> I talked with an expert of my unit about "resetting PCI express
> cards". The units have a special controller (I^2C) able to power
> off and power on the card slots. I was told that this does not
> handle the PCI reset line correctly ("leaves it open"), but makes
> "a hard cut to the 3 volts" (I hope I repeat it correctly).
>
> For my WPEA-121N cards, such a power cycle in my tests so far
> worked around the issue.
Even if it works, it is not PCI(e) compliant. When physically powering 
up a PCI device, you *have* to assert the reset signal to the slot.

cu
Michael

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

Hello All,
 
I recently purchased a Sparklan WPEA-121N, it uses the AR9382 chipset.
It is mentioned as supported on the device list, however, when I load
that ath9k modules nothing comes up. 
 
Does ath9k support this chipset? I compiled compat-wirless on Ubuntu
10.10 on an x86 Core2Duo machine.
 
lspci -vvvnn returns the following:
 

02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Device
[168c:abcd] (rev 01)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 15
        Region 0: Memory at fc8e0000 (64-bit, non-prefetchable)
[size=128K]
        Expansion ROM@fc8d0000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
PME(D0+,D1+,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
                Address: 0000000000000000  Data: 0000
                Masking: 00000000  Pending: 00000000
        Capabilities: [70] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
<1us, L1 <8us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 <2us, L1 <64us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
SpeedDis-, Selectable De-emphasis: -6dB
                         Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap-
ChkEn-
        Capabilities: [140 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1
RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128-
WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
                        Status: NegoPending- InProgress-
        Capabilities: [300 v1] Device Serial Number
00-00-00-00-00-00-00-00

 
Hasan R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110408/44ed6a26/attachment.htm 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
> Hello All,
>
> I recently purchased a Sparklan WPEA-121N, it uses the AR9382 chipset.?It is
> mentioned as supported on the device list, however, when I load that ath9k
> modules nothing comes up.
>
> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu 10.10
> on an x86 Core2Duo machine.
>
> lspci -vvvnn returns the following:
>
> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Device
> [168c:abcd] (rev 01)

Yes AR9382 is supported in ath9k, your device id 'abcd' ?
Did you check with the latest compat wireless?


> ??????? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> ??????? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> ??????? Latency: 0, Cache Line Size: 32 bytes
> ??????? Interrupt: pin A routed to IRQ 15
> ??????? Region 0: Memory at fc8e0000 (64-bit, non-prefetchable) [size=128K]
> ??????? Expansion ROM at fc8d0000 [disabled] [size=64K]
> ??????? Capabilities: [40] Power Management version 3
> ??????????????? Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
> PME(D0+,D1+,D2-,D3hot+,D3cold-)
> ??????????????? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> ??????? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??????????????? Address: 0000000000000000? Data: 0000
> ??????????????? Masking: 00000000? Pending: 00000000
> ??????? Capabilities: [70] Express (v2) Endpoint, MSI 00
> ??????????????? DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us,
> L1 <8us
> ??????????????????????? ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> ??????????????? DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> ??????????????????????? RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> ??????????????????????? MaxPayload 128 bytes, MaxReadReq 512 bytes
> ??????????????? DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
> TransPend-
> ??????????????? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0 <2us, L1 <64us
> ??????????????????????? ClockPM- Surprise- LLActRep- BwNot-
> ??????????????? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
> CommClk+
> ??????????????????????? ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> ??????????????? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> ??????????????? DevCap2: Completion Timeout: Not Supported, TimeoutDis+
> ??????????????? DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
> ??????????????? LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> SpeedDis-, Selectable De-emphasis: -6dB
> ???????????????????????? Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> ???????????????????????? Compliance De-emphasis: -6dB
> ??????????????? LnkSta2: Current De-emphasis Level: -6dB
> ??????? Capabilities: [100 v1] Advanced Error Reporting
> ??????????????? UESta:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> ??????????????? UEMsk:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> ??????????????? UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> ??????????????? CESta:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr+
> ??????????????? CEMsk:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr+
> ??????????????? AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap-
> ChkEn-
> ??????? Capabilities: [140 v1] Virtual Channel
> ??????????????? Caps:?? LPEVC=0 RefClk=100ns PATEntryBits=1
> ??????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
> ??????????????? Ctrl:?? ArbSelect=Fixed
> ??????????????? Status: InProgress-
> ??????????????? VC0:??? Caps:?? PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> ??????????????????????? Arb:??? Fixed- WRR32- WRR64- WRR128- TWRR128-
> WRR256-
> ??????????????????????? Ctrl:?? Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> ??????????????????????? Status: NegoPending- InProgress-
> ??????? Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
>
> Hasan R.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
>> Hello All,
>>
>> I recently purchased a Sparklan WPEA-121N, it uses the AR9382 chipset.?It is
>> mentioned as supported on the device list, however, when I load that ath9k
>> modules nothing comes up.
>>
>> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu 10.10
>> on an x86 Core2Duo machine.
>>
>> lspci -vvvnn returns the following:
>>
>> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Device
>> [168c:abcd] (rev 01)
>
> Yes AR9382 is supported in ath9k, your device id 'abcd' ?
> Did you check with the latest compat wireless?

I doubt the vendor id, if you get you vendor id some thing like this might help
diff --git a/drivers/net/wireless/ath/ath9k/pci.c
b/drivers/net/wireless/ath/ath9k/pci.c
index e83128c..594336a 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
        { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI   */
        { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
        { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E  AR9300 */
+       { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E  AR9300 */
        { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E  AR9485 */
        { 0 }
 };


>
>
>> ??????? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx-
>> ??????? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> ??????? Latency: 0, Cache Line Size: 32 bytes
>> ??????? Interrupt: pin A routed to IRQ 15
>> ??????? Region 0: Memory at fc8e0000 (64-bit, non-prefetchable) [size=128K]
>> ??????? Expansion ROM at fc8d0000 [disabled] [size=64K]
>> ??????? Capabilities: [40] Power Management version 3
>> ??????????????? Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>> PME(D0+,D1+,D2-,D3hot+,D3cold-)
>> ??????????????? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> ??????? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>> ??????????????? Address: 0000000000000000? Data: 0000
>> ??????????????? Masking: 00000000? Pending: 00000000
>> ??????? Capabilities: [70] Express (v2) Endpoint, MSI 00
>> ??????????????? DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us,
>> L1 <8us
>> ??????????????????????? ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>> ??????????????? DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
>> Unsupported-
>> ??????????????????????? RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>> ??????????????????????? MaxPayload 128 bytes, MaxReadReq 512 bytes
>> ??????????????? DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
>> TransPend-
>> ??????????????? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
>> Latency L0 <2us, L1 <64us
>> ??????????????????????? ClockPM- Surprise- LLActRep- BwNot-
>> ??????????????? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>> CommClk+
>> ??????????????????????? ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> ??????????????? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
>> DLActive- BWMgmt- ABWMgmt-
>> ??????????????? DevCap2: Completion Timeout: Not Supported, TimeoutDis+
>> ??????????????? DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>> ??????????????? LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
>> SpeedDis-, Selectable De-emphasis: -6dB
>> ???????????????????????? Transmit Margin: Normal Operating Range,
>> EnterModifiedCompliance- ComplianceSOS-
>> ???????????????????????? Compliance De-emphasis: -6dB
>> ??????????????? LnkSta2: Current De-emphasis Level: -6dB
>> ??????? Capabilities: [100 v1] Advanced Error Reporting
>> ??????????????? UESta:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> ??????????????? UEMsk:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> ??????????????? UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>> ??????????????? CESta:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr+
>> ??????????????? CEMsk:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr+
>> ??????????????? AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap-
>> ChkEn-
>> ??????? Capabilities: [140 v1] Virtual Channel
>> ??????????????? Caps:?? LPEVC=0 RefClk=100ns PATEntryBits=1
>> ??????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
>> ??????????????? Ctrl:?? ArbSelect=Fixed
>> ??????????????? Status: InProgress-
>> ??????????????? VC0:??? Caps:?? PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>> ??????????????????????? Arb:??? Fixed- WRR32- WRR64- WRR128- TWRR128-
>> WRR256-
>> ??????????????????????? Ctrl:?? Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>> ??????????????????????? Status: NegoPending- InProgress-
>> ??????? Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
>>
>> Hasan R.
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>
>

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

Mohammed,

Mohammed Shafi wrote:
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
>         { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI   */
>         { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
>         { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E  AR9300 */
> +       { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E  AR9300 */

Is this a serious proposal from Atheros, or just your attempt at
a quick fix?

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.

I fear this will be another case of "we can not reproduce" which I
will not bother commenting on again. Everyone knows why that's not a
helpful approach by now. Hopefully I'm wrong and this time we will
actually learn what the problem was after some investigation.

Since this card should work fine in principle, maybe it's some issue
with missing, or wrong, firmware stored on the Linux system.


//Peter

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Sun, Apr 10, 2011 at 8:02 PM, Peter Stuge <peter@stuge.se> wrote:
> Mohammed,
>
> Mohammed Shafi wrote:
>> +++ b/drivers/net/wireless/ath/ath9k/pci.c
>> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
>> ? ? ? ? { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI ? */
>> ? ? ? ? { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
>> ? ? ? ? { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E ?AR9300 */
>> + ? ? ? { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E ?AR9300 */
>
> 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.

>
> 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.

>
> I fear this will be another case of "we can not reproduce" which I
> will not bother commenting on again. Everyone knows why that's not a
> helpful approach by now. Hopefully I'm wrong and this time we will
> actually learn what the problem was after some investigation.

Yes, I do have the AR9382 card and  the device ID seems to make more
sense and its there in the PCI table.

>
> 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 and you have any idea what
might went wrong.
Also why its detected as Ethernet Controller rather than Network controller.
Thanks for your suggestions!
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

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. :\


> > 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.


> > 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.


> and you have any idea what might went wrong.

Sorry, I don't understand what you mean here.


> 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.

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] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

Incorrect or misplaced EEPROM/OTP data, perhaps?

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Sun, Apr 10, 2011 at 9:04 PM, Adrian Chadd <adrian@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.ath9k@gmail.com> wrote:
>>
>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@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 at lists.ath9k.org
>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>> >
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

 
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.

Hasan R.
 

-----Original Message-----
From: ath9k-devel-bounces@lists.ath9k.org [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed Shafi
Sent: Sunday, April 10, 2011 11:41 AM
To: Adrian Chadd
Cc: ath9k-devel at 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 <adrian@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.ath9k@gmail.com> wrote:
>>
>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@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 at lists.ath9k.org
>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>> >
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
_______________________________________________
ath9k-devel mailing list
ath9k-devel at 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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iw_ar9382_sparklan.txt
Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110410/6a59e962/attachment.txt 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

Hasan Rashid wrote:
> The only problem now is that the driver transmit at non-HT rates only.

I guess that is the best it can do with a bogus EEPROM.


//Peter

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Mon, Apr 11, 2011 at 6:58 AM, Hasan Rashid <hrashad@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-bounces at lists.ath9k.org [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed Shafi
> Sent: Sunday, April 10, 2011 11:41 AM
> To: Adrian Chadd
> Cc: ath9k-devel at 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 <adrian@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.ath9k@gmail.com> wrote:
>>>
>>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@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 at lists.ath9k.org
>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>> >
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at 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.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

 
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.

Hasan R. 

-----Original Message-----
From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com] 
Sent: Monday, April 11, 2011 12:05 PM
To: Hasan Rashid
Cc: Adrian Chadd; ath9k-devel at 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 <hrashad@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-bounces at lists.ath9k.org 
> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed 
> Shafi
> Sent: Sunday, April 10, 2011 11:41 AM
> To: Adrian Chadd
> Cc: ath9k-devel at 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 <adrian@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.ath9k@gmail.com> wrote:
>>>
>>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@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 at lists.ath9k.org
>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>> >
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at 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] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Mon, Apr 11, 2011 at 9:40 PM, Hasan Rashid <hrashad@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.ath9k at gmail.com]
> Sent: Monday, April 11, 2011 12:05 PM
> To: Hasan Rashid
> Cc: Adrian Chadd; ath9k-devel at 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 <hrashad@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-bounces at lists.ath9k.org
>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed
>> Shafi
>> Sent: Sunday, April 10, 2011 11:41 AM
>> To: Adrian Chadd
>> Cc: ath9k-devel at 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 <adrian@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.ath9k@gmail.com> wrote:
>>>>
>>>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@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 at lists.ath9k.org
>>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>> >
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

Mohammed Shafi wrote:
> 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;
> +

The indentation is off, or do you mean to include the added line only
within the else block? If so, remember to add braces.


//Peter

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

 
I have attached the driver load output in dmesg.

By the way why does AR9382 require Kernel 2.6.36 or higher? Can you list
the major requirements?

Hasan R.

-----Original Message-----
From: ath9k-devel-bounces@lists.ath9k.org
[mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
Sent: Monday, April 11, 2011 12:20 PM
To: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

Mohammed Shafi wrote:
> 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;
> +

The indentation is off, or do you mean to include the added line only
within the else block? If so, remember to add braces.


//Peter
_______________________________________________
ath9k-devel mailing list
ath9k-devel at 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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: driver load.txt
Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110411/d6d41cec/attachment.txt 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>
> I have attached the driver load output in dmesg.
>
> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you list
> the major requirements?

because the hardware code(HAL) will be present from that kernel version only.
>
> Hasan R.
>
> -----Original Message-----
> From: ath9k-devel-bounces at lists.ath9k.org
> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
> Sent: Monday, April 11, 2011 12:20 PM
> To: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> Mohammed Shafi wrote:
>> 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;
>> +
>
> The indentation is off, or do you mean to include the added line only
> within the else block? If so, remember to add braces.
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at 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.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

I put another Sparklan card in a Windows XP machine and following are the device ids reported by the Atheros driver on Windows. It seems it is reporting the correct 0x168c, and 0x0030. 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

It sounds like perhaps there's some initialization issues, maybe the PCI bus
isn't being fondled correctly, or the card/slot isn't being woken up
correctly.

It may not be an ath9k issue but it certainly sounds like something which
should be investigated.


Adrian

On 12 April 2011 23:04, Hasan Rashid <hrashad@avionica.com> wrote:

>  I put another Sparklan card in a Windows XP machine and following are the
> device ids reported by the Atheros driver on Windows. It seems it is
> reporting the correct 0x168c, and 0x0030.
>
> From Windows XP Device Manager
> -------------------------------
> Device Instance Id:
> PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&0&00E2
>
> Hardware Ids:
> PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01
> PCI\VEN_168C&DEV_0030&SUBSYS_3116168C
> PCI\VEN_168C&DEV_0030&CC_028000
> PCI\VEN_168C&DEV_0030&CC_0280
>
> Compatible Ids:
> PCI\VEN_168C&DEV_0030&REV_01
> PCI\VEN_168C&DEV_0030
> PCI\VEN_168C&CC_028000
> PCI\VEN_168C&CC_0280
> PCI\VEN_168C
> PCI\CC_028000
> PCI\CC_0280
>
> Matching Device Id:
> pci\ven_168c&dev_0030&subsys_3116168c
>
>
> Here is the interesting bit, when I first hooked this card I booted my
> machine in Ubuntu I saw the same 168c:ABCD. After using it under Windows, I
> booted in to Linux today and found that it is reporting the expected IDs.
> Now ath9k works right out of the box, no Vendor ID hacking required. I am
> using it as station right now. The other card is in a different machine. I
> will try to swap the cards to verify my theory. I am thinking the Windows
> driver applied a firmware update to the card. Or, the other card skipped
> quality checks and has bogus EEPROM data. Any thoughts?
>
> 0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300
> Wireless LAN adaptor [168c:0030] (rev 01)
>
> lspci -vvvnn returns
>
> 0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300
> Wireless LAN adaptor [168c:0030] (rev 01)
>         Subsystem: Atheros Communications Inc. Device [168c:3116]
>
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Interrupt: pin A routed to IRQ 18
>         Region 0: Memory at fa000000 (64-bit, non-prefetchable) [size=128K]
>         [virtual] Expansion ROM at f2000000 [disabled] [size=64K]
>         Capabilities: <access denied>
>         Kernel driver in use: ath9k
>         Kernel modules: ath9k
>
>
> Hasan R.
>
>
> -----Original Message-----
> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com <shafi.ath9k@gmail.com>
> ]
> Sent: Tuesday, April 12, 2011 7:47 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com>
> wrote:
> >
> > I have attached the driver load output in dmesg.
> >
> > By the way why does AR9382 require Kernel 2.6.36 or higher? Can you
> > list the major requirements?
>
> because the hardware code(HAL) will be present from that kernel version
> only.
> >
> > Hasan R.
> >
> > -----Original Message-----
> > From: ath9k-devel-bounces at lists.ath9k.org
> > [mailto:ath9k-devel-bounces at lists.ath9k.org<ath9k-devel-bounces@lists.ath9k.org>]
> On Behalf Of Peter Stuge
> > Sent: Monday, April 11, 2011 12:20 PM
> > To: ath9k-devel at lists.ath9k.org
> > Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
> >
> > Mohammed Shafi wrote:
> >> 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;
> >> +
> >
> > The indentation is off, or do you mean to include the added line only
> > within the else block? If so, remember to add braces.
> >
> >
> > //Peter
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at 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.
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at 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.
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110413/5a8464e1/attachment.htm 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

I found out the issue is not with the hardware or ath9k. It is with the tablet that I am using. On my Dell Vostro 1520 the pci device ID is reported correctly without any issues. On the tablet the same card is reported as an Ethernet Controller and the bogus vendor id. 

On another note, even with the correct vendor id, regardless of AP or Station mode, the transmit rate is still limited 54MBit/sec. 

For now, I think we can close this thread on the note that the bogus vendor id is not an ath9k issue.

Thanks for all the help.

-----Original Message-----
From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
Sent: Tue 4/12/2011 7:46 AM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
 
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>
> I have attached the driver load output in dmesg.
>
> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you list
> the major requirements?

because the hardware code(HAL) will be present from that kernel version only.
>
> Hasan R.
>
> -----Original Message-----
> From: ath9k-devel-bounces at lists.ath9k.org
> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
> Sent: Monday, April 11, 2011 12:20 PM
> To: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> Mohammed Shafi wrote:
>> 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;
>> +
>
> The indentation is off, or do you mean to include the added line only
> within the else block? If so, remember to add braces.
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at 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.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110412/e0b4988b/attachment.htm 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Tue, Apr 12, 2011 at 10:02 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>
> I found out the issue is not with the hardware or ath9k. It is with the
> tablet that I am using. On my Dell Vostro 1520 the pci device ID is reported
> correctly without any issues. On the tablet the same card is reported as an
> Ethernet Controller and the bogus vendor id.

good that you found it out!

>
> On another note, even with the correct vendor id, regardless of AP or
> Station mode, the transmit rate is still limited 54MBit/sec.

does this behaviour is still happening with the Windows driver?

>
> For now, I think we can close this thread on the note that the bogus vendor
> id is not an ath9k issue.
>
> Thanks for all the help.
>
> -----Original Message-----
> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
> Sent: Tue 4/12/2011 7:46 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>>
>> I have attached the driver load output in dmesg.
>>
>> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you list
>> the major requirements?
>
> because the hardware code(HAL) will be present from that kernel version
> only.
>>
>> Hasan R.
>>
>> -----Original Message-----
>> From: ath9k-devel-bounces at lists.ath9k.org
>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
>> Sent: Monday, April 11, 2011 12:20 PM
>> To: ath9k-devel at lists.ath9k.org
>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>> Mohammed Shafi wrote:
>>> 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;
>>> +
>>
>> The indentation is off, or do you mean to include the added line only
>> within the else block? If so, remember to add braces.
>>
>>
>> //Peter
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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.
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

 
> does this behaviour is still happening with the Windows driver?
No not under Windows.

The 802.11n rates with hostapd worked after playing with ht_capab in the hostapd.conf file. I am not so sure what really made the difference but for my prototype testing it did the job.

Thank you everyone for all your help!

Hasan R.

-----Original Message-----
From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com] 
Sent: Tuesday, April 19, 2011 12:21 AM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Tue, Apr 12, 2011 at 10:02 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>
> I found out the issue is not with the hardware or ath9k. It is with 
> the tablet that I am using. On my Dell Vostro 1520 the pci device ID 
> is reported correctly without any issues. On the tablet the same card 
> is reported as an Ethernet Controller and the bogus vendor id.

good that you found it out!

>
> On another note, even with the correct vendor id, regardless of AP or 
> Station mode, the transmit rate is still limited 54MBit/sec.

does this behaviour is still happening with the Windows driver?

>
> For now, I think we can close this thread on the note that the bogus 
> vendor id is not an ath9k issue.
>
> Thanks for all the help.
>
> -----Original Message-----
> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
> Sent: Tue 4/12/2011 7:46 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>>
>> I have attached the driver load output in dmesg.
>>
>> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you 
>> list the major requirements?
>
> because the hardware code(HAL) will be present from that kernel 
> version only.
>>
>> Hasan R.
>>
>> -----Original Message-----
>> From: ath9k-devel-bounces at lists.ath9k.org
>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
>> Sent: Monday, April 11, 2011 12:20 PM
>> To: ath9k-devel at lists.ath9k.org
>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>> Mohammed Shafi wrote:
>>> 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;
>>> +
>>
>> The indentation is off, or do you mean to include the added line only 
>> within the else block? If so, remember to add braces.
>>
>>
>> //Peter
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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.
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

On Tue, Apr 19, 2011 at 8:54 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>
>> does this behaviour is still happening with the Windows driver?
> No not under Windows.

ok.
>
> The 802.11n rates with hostapd worked after playing with ht_capab in the hostapd.conf file. I am not so sure what really made the difference but for my prototype testing it did the job.

Great!

>
> Thank you everyone for all your help!
>
> Hasan R.
>
> -----Original Message-----
> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
> Sent: Tuesday, April 19, 2011 12:21 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Tue, Apr 12, 2011 at 10:02 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>>
>> I found out the issue is not with the hardware or ath9k. It is with
>> the tablet that I am using. On my Dell Vostro 1520 the pci device ID
>> is reported correctly without any issues. On the tablet the same card
>> is reported as an Ethernet Controller and the bogus vendor id.
>
> good that you found it out!
>
>>
>> On another note, even with the correct vendor id, regardless of AP or
>> Station mode, the transmit rate is still limited 54MBit/sec.
>
> does this behaviour is still happening with the Windows driver?
>
>>
>> For now, I think we can close this thread on the note that the bogus
>> vendor id is not an ath9k issue.
>>
>> Thanks for all the help.
>>
>> -----Original Message-----
>> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
>> Sent: Tue 4/12/2011 7:46 AM
>> To: Hasan Rashid
>> Cc: ath9k-devel at lists.ath9k.org
>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>> On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>>>
>>> I have attached the driver load output in dmesg.
>>>
>>> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you
>>> list the major requirements?
>>
>> because the hardware code(HAL) will be present from that kernel
>> version only.
>>>
>>> Hasan R.
>>>
>>> -----Original Message-----
>>> From: ath9k-devel-bounces at lists.ath9k.org
>>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
>>> Sent: Monday, April 11, 2011 12:20 PM
>>> To: ath9k-devel at lists.ath9k.org
>>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>>
>>> Mohammed Shafi wrote:
>>>> 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;
>>>> +
>>>
>>> The indentation is off, or do you mean to include the added line only
>>> within the else block? If so, remember to add braces.
>>>
>>>
>>> //Peter
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at 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.
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at 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] Sparklan WPEA-121N AR9382 168c:abcd

[Manuel Sáez]

Hi,

I am having the same problem with two devices.  Sparklan WPA-127N
(AR9380) and WLE300NX 6B (AR9390).

I added the line

{ PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E  AR9300 */

in pci.c but it did not work. This is the output of dmesg:

[17464.277232] ath9k 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[17464.277258] ath9k 0000:01:00.0: setting latency timer to 64
[17464.277408] ath: Hardware device ID 0xabcd not supported
[17464.277426] ath9k 0000:01:00.0: Failed to initialize device
[17464.277738] ath9k 0000:01:00.0: PCI INT A disabled
[17464.277770] ath9k: probe of 0000:01:00.0 failed with error -95

Did you solved the problem?

Thank you and best regards

2011/4/12, Hasan Rashid <hrashad@avionica.com>:
>
> I found out the issue is not with the hardware or ath9k. It is with the
> tablet that I am using. On my Dell Vostro 1520 the pci device ID is reported
> correctly without any issues. On the tablet the same card is reported as an
> Ethernet Controller and the bogus vendor id.
>
> On another note, even with the correct vendor id, regardless of AP or
> Station mode, the transmit rate is still limited 54MBit/sec.
>
> For now, I think we can close this thread on the note that the bogus vendor
> id is not an ath9k issue.
>
> Thanks for all the help.
>
> -----Original Message-----
> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
> Sent: Tue 4/12/2011 7:46 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com> wrote:
>>
>> I have attached the driver load output in dmesg.
>>
>> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you list
>> the major requirements?
>
> because the hardware code(HAL) will be present from that kernel version
> only.
>>
>> Hasan R.
>>
>> -----Original Message-----
>> From: ath9k-devel-bounces at lists.ath9k.org
>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
>> Sent: Monday, April 11, 2011 12:20 PM
>> To: ath9k-devel at lists.ath9k.org
>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>> Mohammed Shafi wrote:
>>> 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;
>>> +
>>
>> The indentation is off, or do you mean to include the added line only
>> within the else block? If so, remember to add braces.
>>
>>
>> //Peter
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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.
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

Manuel,

I figured out that the problem is with the BIOS on the motherboard of the host device. Some BIOS do not fully read the EPROM contents on the Sparklan radio. I have used the Sparklan PCIe express card on the same embedded baseboard with Intel Atom Q7 modules and it seems to be properly recognized by one and not the other from a different manufacturer. The BIOS was on the Q7 modules and not the baseboard so each module had a different BIOS.

Apart from that if lspci is showing you 168c:abcd then you have the correct line added in pci.c. From your dmesg log it appears you force it to load a hardware with that subvendor id but upon scanning the bus its unable to find the physical device. I'd say start from making sure, you have it properly inserted in the PCIe slot, and then work your way up.


- Hasan R.
 
 

>-----Original Message-----
>From: Manuel S?ez [mailto:manuelsaezr at gmail.com] 
>Sent: Tuesday, January 10, 2012 11:20 AM
>To: Hasan Rashid
>Cc: Mohammed Shafi; ath9k-devel at lists.ath9k.org
>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
>Hi,
>
>I am having the same problem with two devices.  Sparklan WPA-127N
>(AR9380) and WLE300NX 6B (AR9390).
>
>I added the line
>
>{ PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E  AR9300 */
>
>in pci.c but it did not work. This is the output of dmesg:
>
>[17464.277232] ath9k 0000:01:00.0: PCI INT A -> GSI 16 (level, 
>low) -> IRQ 16
>[17464.277258] ath9k 0000:01:00.0: setting latency timer to 64
>[17464.277408] ath: Hardware device ID 0xabcd not supported
>[17464.277426] ath9k 0000:01:00.0: Failed to initialize device
>[17464.277738] ath9k 0000:01:00.0: PCI INT A disabled
>[17464.277770] ath9k: probe of 0000:01:00.0 failed with error -95
>
>Did you solved the problem?
>
>Thank you and best regards
>
>2011/4/12, Hasan Rashid <hrashad@avionica.com>:
>>
>> I found out the issue is not with the hardware or ath9k. It 
>is with the
>> tablet that I am using. On my Dell Vostro 1520 the pci 
>device ID is reported
>> correctly without any issues. On the tablet the same card is 
>reported as an
>> Ethernet Controller and the bogus vendor id.
>>
>> On another note, even with the correct vendor id, regardless of AP or
>> Station mode, the transmit rate is still limited 54MBit/sec.
>>
>> For now, I think we can close this thread on the note that 
>the bogus vendor
>> id is not an ath9k issue.
>>
>> Thanks for all the help.
>>
>> -----Original Message-----
>> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
>> Sent: Tue 4/12/2011 7:46 AM
>> To: Hasan Rashid
>> Cc: ath9k-devel at lists.ath9k.org
>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>> On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid 
><hrashad@avionica.com> wrote:
>>>
>>> I have attached the driver load output in dmesg.
>>>
>>> By the way why does AR9382 require Kernel 2.6.36 or higher? 
>Can you list
>>> the major requirements?
>>
>> because the hardware code(HAL) will be present from that 
>kernel version
>> only.
>>>
>>> Hasan R.
>>>
>>> -----Original Message-----
>>> From: ath9k-devel-bounces at lists.ath9k.org
>>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of 
>Peter Stuge
>>> Sent: Monday, April 11, 2011 12:20 PM
>>> To: ath9k-devel at lists.ath9k.org
>>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>>
>>> Mohammed Shafi wrote:
>>>> 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;
>>>> +
>>>
>>> The indentation is off, or do you mean to include the added 
>line only
>>> within the else block? If so, remember to add braces.
>>>
>>>
>>> //Peter
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at 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.
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at 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.
>

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

Hi,

The BIOS doesn't "read" the EEPROM on the NIC.  The NIC is supposed to
read the EEPROM upon powerup (and on PCI bus reset?) and setup the
initial PCI/register contents from that.

I've seen this before:

* sometimes the NIC itself is damaged;
* sometimes the type of board it's on is the only difference.

So the question really is - what's that BIOS doing that is stopping
the NIC from successfully bootstrapping the initial register values
from EEPROM? It likely would be solved with the application of a
PCI/PCIe bus analyser..


Adrian

On 10 January 2012 08:36, Hasan Rashid <hrashid@avionica.com> wrote:
> Manuel,
>
> I figured out that the problem is with the BIOS on the motherboard of the host device. Some BIOS do not fully read the EPROM contents on the Sparklan radio. I have used the Sparklan PCIe express card on the same embedded baseboard with Intel Atom Q7 modules and it seems to be properly recognized by one and not the other from a different manufacturer. The BIOS was on the Q7 modules and not the baseboard so each module had a different BIOS.
>
> Apart from that if lspci is showing you 168c:abcd then you have the correct line added in pci.c. From your dmesg log it appears you force it to load a hardware with that subvendor id but upon scanning the bus its unable to find the physical device. I'd say start from making sure, you have it properly inserted in the PCIe slot, and then work your way up.
>
>
> - Hasan R.
>
>
>
>>-----Original Message-----
>>From: Manuel S?ez [mailto:manuelsaezr at gmail.com]
>>Sent: Tuesday, January 10, 2012 11:20 AM
>>To: Hasan Rashid
>>Cc: Mohammed Shafi; ath9k-devel at lists.ath9k.org
>>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>>Hi,
>>
>>I am having the same problem with two devices. ?Sparklan WPA-127N
>>(AR9380) and WLE300NX 6B (AR9390).
>>
>>I added the line
>>
>>{ PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E ?AR9300 */
>>
>>in pci.c but it did not work. This is the output of dmesg:
>>
>>[17464.277232] ath9k 0000:01:00.0: PCI INT A -> GSI 16 (level,
>>low) -> IRQ 16
>>[17464.277258] ath9k 0000:01:00.0: setting latency timer to 64
>>[17464.277408] ath: Hardware device ID 0xabcd not supported
>>[17464.277426] ath9k 0000:01:00.0: Failed to initialize device
>>[17464.277738] ath9k 0000:01:00.0: PCI INT A disabled
>>[17464.277770] ath9k: probe of 0000:01:00.0 failed with error -95
>>
>>Did you solved the problem?
>>
>>Thank you and best regards
>>
>>2011/4/12, Hasan Rashid <hrashad@avionica.com>:
>>>
>>> I found out the issue is not with the hardware or ath9k. It
>>is with the
>>> tablet that I am using. On my Dell Vostro 1520 the pci
>>device ID is reported
>>> correctly without any issues. On the tablet the same card is
>>reported as an
>>> Ethernet Controller and the bogus vendor id.
>>>
>>> On another note, even with the correct vendor id, regardless of AP or
>>> Station mode, the transmit rate is still limited 54MBit/sec.
>>>
>>> For now, I think we can close this thread on the note that
>>the bogus vendor
>>> id is not an ath9k issue.
>>>
>>> Thanks for all the help.
>>>
>>> -----Original Message-----
>>> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
>>> Sent: Tue 4/12/2011 7:46 AM
>>> To: Hasan Rashid
>>> Cc: ath9k-devel at lists.ath9k.org
>>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>>
>>> On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid
>><hrashad@avionica.com> wrote:
>>>>
>>>> I have attached the driver load output in dmesg.
>>>>
>>>> By the way why does AR9382 require Kernel 2.6.36 or higher?
>>Can you list
>>>> the major requirements?
>>>
>>> because the hardware code(HAL) will be present from that
>>kernel version
>>> only.
>>>>
>>>> Hasan R.
>>>>
>>>> -----Original Message-----
>>>> From: ath9k-devel-bounces at lists.ath9k.org
>>>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of
>>Peter Stuge
>>>> Sent: Monday, April 11, 2011 12:20 PM
>>>> To: ath9k-devel at lists.ath9k.org
>>>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>>>
>>>> Mohammed Shafi wrote:
>>>>> 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;
>>>>> +
>>>>
>>>> The indentation is off, or do you mean to include the added
>>line only
>>>> within the else block? If so, remember to add braces.
>>>>
>>>>
>>>> //Peter
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at 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.
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at 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.
>>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

Adrian,

I have only been able to narrow it down to the BIOS and unfortunately I do not have a PCI bus analyzer at my disposal.

- Hasan R. 
 
 

>-----Original Message-----
From: adrian.chadd@gmail.com [mailto:adrian.chadd at gmail.com] 
>On Behalf Of Adrian Chadd
>Sent: Tuesday, January 10, 2012 12:37 PM
>To: Hasan Rashid
>Cc: Manuel S?ez; ath9k-devel at lists.ath9k.org
>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
>Hi,
>
>The BIOS doesn't "read" the EEPROM on the NIC.  The NIC is supposed to
>read the EEPROM upon powerup (and on PCI bus reset?) and setup the
>initial PCI/register contents from that.
>
>I've seen this before:
>
>* sometimes the NIC itself is damaged;
>* sometimes the type of board it's on is the only difference.
>
>So the question really is - what's that BIOS doing that is stopping
>the NIC from successfully bootstrapping the initial register values
>from EEPROM? It likely would be solved with the application of a
>PCI/PCIe bus analyser..
>
>
>Adrian
>
>On 10 January 2012 08:36, Hasan Rashid <hrashid@avionica.com> wrote:
>> Manuel,
>>
>> I figured out that the problem is with the BIOS on the 
>motherboard of the host device. Some BIOS do not fully read 
>the EPROM contents on the Sparklan radio. I have used the 
>Sparklan PCIe express card on the same embedded baseboard with 
>Intel Atom Q7 modules and it seems to be properly recognized 
>by one and not the other from a different manufacturer. The 
>BIOS was on the Q7 modules and not the baseboard so each 
>module had a different BIOS.
>>
>> Apart from that if lspci is showing you 168c:abcd then you 
>have the correct line added in pci.c. From your dmesg log it 
>appears you force it to load a hardware with that subvendor id 
>but upon scanning the bus its unable to find the physical 
>device. I'd say start from making sure, you have it properly 
>inserted in the PCIe slot, and then work your way up.
>>
>>
>> - Hasan R.
>>
>>
>>
>>>-----Original Message-----
>>>From: Manuel S?ez [mailto:manuelsaezr at gmail.com]
>>>Sent: Tuesday, January 10, 2012 11:20 AM
>>>To: Hasan Rashid
>>>Cc: Mohammed Shafi; ath9k-devel at lists.ath9k.org
>>>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>>
>>>Hi,
>>>
>>>I am having the same problem with two devices. ?Sparklan WPA-127N
>>>(AR9380) and WLE300NX 6B (AR9390).
>>>
>>>I added the line
>>>
>>>{ PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E ?AR9300 */
>>>
>>>in pci.c but it did not work. This is the output of dmesg:
>>>
>>>[17464.277232] ath9k 0000:01:00.0: PCI INT A -> GSI 16 (level,
>>>low) -> IRQ 16
>>>[17464.277258] ath9k 0000:01:00.0: setting latency timer to 64
>>>[17464.277408] ath: Hardware device ID 0xabcd not supported
>>>[17464.277426] ath9k 0000:01:00.0: Failed to initialize device
>>>[17464.277738] ath9k 0000:01:00.0: PCI INT A disabled
>>>[17464.277770] ath9k: probe of 0000:01:00.0 failed with error -95
>>>
>>>Did you solved the problem?
>>>
>>>Thank you and best regards
>>>
>>>2011/4/12, Hasan Rashid <hrashad@avionica.com>:
>>>>
>>>> I found out the issue is not with the hardware or ath9k. It
>>>is with the
>>>> tablet that I am using. On my Dell Vostro 1520 the pci
>>>device ID is reported
>>>> correctly without any issues. On the tablet the same card is
>>>reported as an
>>>> Ethernet Controller and the bogus vendor id.
>>>>
>>>> On another note, even with the correct vendor id, 
>regardless of AP or
>>>> Station mode, the transmit rate is still limited 54MBit/sec.
>>>>
>>>> For now, I think we can close this thread on the note that
>>>the bogus vendor
>>>> id is not an ath9k issue.
>>>>
>>>> Thanks for all the help.
>>>>
>>>> -----Original Message-----
>>>> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
>>>> Sent: Tue 4/12/2011 7:46 AM
>>>> To: Hasan Rashid
>>>> Cc: ath9k-devel at lists.ath9k.org
>>>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>>>
>>>> On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid
>>><hrashad@avionica.com> wrote:
>>>>>
>>>>> I have attached the driver load output in dmesg.
>>>>>
>>>>> By the way why does AR9382 require Kernel 2.6.36 or higher?
>>>Can you list
>>>>> the major requirements?
>>>>
>>>> because the hardware code(HAL) will be present from that
>>>kernel version
>>>> only.
>>>>>
>>>>> Hasan R.
>>>>>
>>>>> -----Original Message-----
>>>>> From: ath9k-devel-bounces at lists.ath9k.org
>>>>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of
>>>Peter Stuge
>>>>> Sent: Monday, April 11, 2011 12:20 PM
>>>>> To: ath9k-devel at lists.ath9k.org
>>>>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>>>>
>>>>> Mohammed Shafi wrote:
>>>>>> 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;
>>>>>> +
>>>>>
>>>>> The indentation is off, or do you mean to include the added
>>>line only
>>>>> within the else block? If so, remember to add braces.
>>>>>
>>>>>
>>>>> //Peter
>>>>> _______________________________________________
>>>>> ath9k-devel mailing list
>>>>> ath9k-devel at 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.
>>>>> _______________________________________________
>>>>> ath9k-devel mailing list
>>>>> ath9k-devel at 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.
>>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

On 10 January 2012 10:17, Hasan Rashid <hrashid@avionica.com> wrote:
> Adrian,
>
> I have only been able to narrow it down to the BIOS and unfortunately I do not have a PCI bus analyzer at my disposal.

Right, so it's likely something like:

* what power states the BIOS tries to place the NIC into at poweron;
* what the power state / reset timing looks like;
* Maybe APSM related stuff?

It could also be something weird with how Linux/BSD/other handle
things. There may be some workarounds that can be done in the PCI bus
setup code.

Are you able to provide me with exactly the board + BIOS details?
Maybe it's something I can kick to the guys in the lab to check.




Adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

Adrian,

This is not an OS issue as I see similar results in Windows, it is definitely a low-level hardware issue.

I am using a Portwell PQ7-C100XL carrier board with a Portwell PQ7-M105 Q7 module. The radio is initialized properly without any driver hacks with that cpu+board pair. 

Portwell Q7 M105 has AMI BIOS v2.14.1219 on it.

Regards, Hasan R. 
 
 

>-----Original Message-----
From: adrian.chadd@gmail.com [mailto:adrian.chadd at gmail.com] 
>On Behalf Of Adrian Chadd
>Sent: Tuesday, January 10, 2012 1:37 PM
>To: Hasan Rashid
>Cc: Manuel S?ez; ath9k-devel at lists.ath9k.org
>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
>On 10 January 2012 10:17, Hasan Rashid <hrashid@avionica.com> wrote:
>> Adrian,
>>
>> I have only been able to narrow it down to the BIOS and 
>unfortunately I do not have a PCI bus analyzer at my disposal.
>
>Right, so it's likely something like:
>
>* what power states the BIOS tries to place the NIC into at poweron;
>* what the power state / reset timing looks like;
>* Maybe APSM related stuff?
>
>It could also be something weird with how Linux/BSD/other handle
>things. There may be some workarounds that can be done in the PCI bus
>setup code.
>
>Are you able to provide me with exactly the board + BIOS details?
>Maybe it's something I can kick to the guys in the lab to check.
>
>
>
>
>Adrian
>
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] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

On 10 January 2012 12:45, Hasan Rashid <hrashid@avionica.com> wrote:
>
> Adrian,
>
> This is not an OS issue as I see similar results in Windows, it is definitely a low-level hardware issue.

Right, but as I said, it could be something that is worked around in softwar.e

> I am using a Portwell PQ7-C100XL carrier board with a Portwell PQ7-M105 Q7 module. The radio is initialized properly without any driver hacks with that cpu+board pair.
>
> Portwell Q7 M105 has AMI BIOS v2.14.1219 on it.

Ok.

I'd be cautious about using the NIC if it's reporting an ID of 0xabcd
- that means a bunch of the registers being setup during initial
power-on aren't being written. This involves more than just the
vendor/subvendor IDs.


Adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

>I'd be cautious about using the NIC if it's reporting an ID of 0xabcd
>- that means a bunch of the registers being setup during initial
>power-on aren't being written. This involves more than just the
>vendor/subvendor IDs.

You would think so, but it actually performs really well. I have used the radio in a 50+ client video streaming scenario and I didn't encounter any performance related issues. 
What is most annoying is that only Sparklan's modules exhibit this behavior. Well I hope you're able to figure out a root cause.


Hasan R.
 
 
 

>-----Original Message-----
From: adrian.chadd@gmail.com [mailto:adrian.chadd at gmail.com] 
>On Behalf Of Adrian Chadd
>Sent: Tuesday, January 10, 2012 4:11 PM
>To: Hasan Rashid
>Cc: Manuel S?ez; ath9k-devel at lists.ath9k.org
>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
>On 10 January 2012 12:45, Hasan Rashid <hrashid@avionica.com> wrote:
>>
>> Adrian,
>>
>> This is not an OS issue as I see similar results in Windows, 
>it is definitely a low-level hardware issue.
>
>Right, but as I said, it could be something that is worked 
>around in softwar.e
>
>> I am using a Portwell PQ7-C100XL carrier board with a 
>Portwell PQ7-M105 Q7 module. The radio is initialized properly 
>without any driver hacks with that cpu+board pair.
>>
>> Portwell Q7 M105 has AMI BIOS v2.14.1219 on it.
>
>Ok.
>
>I'd be cautious about using the NIC if it's reporting an ID of 0xabcd
>- that means a bunch of the registers being setup during initial
>power-on aren't being written. This involves more than just the
>vendor/subvendor IDs.
>
>
>Adrian
>
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] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

On 10 January 2012 13:23, Hasan Rashid <hrashid@avionica.com> wrote:

> You would think so, but it actually performs really well. I have used the radio in a 50+ client video streaming scenario and I didn't encounter any performance related issues.
> What is most annoying is that only Sparklan's modules exhibit this behavior. Well I hope you're able to figure out a root cause.

:-)

I guess I'm just saying "be careful". Who knows what weird corner case
stuff may pop up..


Adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Daniel Smith]

On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid <hrashid@avionica.com> wrote:
>
> Adrian,
>
> This is not an OS issue as I see similar results in Windows, it is definitely a low-level hardware issue.
>
> I am using a Portwell PQ7-C100XL carrier board with a Portwell PQ7-M105 Q7 module. The radio is initialized properly without any driver hacks with that cpu+board pair.
>
> Portwell Q7 M105 has AMI BIOS v2.14.1219 on it.
>
> Regards, Hasan R.
>

Hey All,

We actually had the exact same problem with a board we were
prototyping on. Working with the manufacturer it turned out to be a
"feature" of the AMI BIOS they were using on the card (sorry I don't
have the version right off hand). What happens is that the AMI BIOS
does a Root Bridge reset on all the PCI-e buses upon power on. This
reset can interfere with the initialization of certain types of cards
that have serial eeprom that are based off an R-C time constant
circuit at Power-On. Luckily for us the manufacturer was willing to
patch the BIOS and resolved our issue. Perhaps you can contact
Portwell with this info and see if they are willing to help.

Daniel

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

Daniel,

Portwell's Q7 BIOS works without any issues. On the list of board's that
did not detect the subvendor id are as follows:

CongaTec QA Q7 module
KaRo Q7 with uBoot boot loader.

At the same time I have ordered some DNXA-116 AR9382 chip radios, it
would be interesting to see how they fare.

At any rate, that's valuable information and I will contact the
manufacturer of the board. Thank you.

Best Regards, Hasan R.
 
 

>-----Original Message-----
>From: Daniel Smith [mailto:viscous.liquid at gmail.com] 
>Sent: Tuesday, January 10, 2012 4:26 PM
>To: Hasan Rashid
>Cc: Adrian Chadd; ath9k-devel at lists.ath9k.org
>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
>On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid 
><hrashid@avionica.com> wrote:
>>
>> Adrian,
>>
>> This is not an OS issue as I see similar results in Windows, 
>it is definitely a low-level hardware issue.
>>
>> I am using a Portwell PQ7-C100XL carrier board with a 
>Portwell PQ7-M105 Q7 module. The radio is initialized properly 
>without any driver hacks with that cpu+board pair.
>>
>> Portwell Q7 M105 has AMI BIOS v2.14.1219 on it.
>>
>> Regards, Hasan R.
>>
>
>Hey All,
>
>We actually had the exact same problem with a board we were
>prototyping on. Working with the manufacturer it turned out to be a
>"feature" of the AMI BIOS they were using on the card (sorry I don't
>have the version right off hand). What happens is that the AMI BIOS
>does a Root Bridge reset on all the PCI-e buses upon power on. This
>reset can interfere with the initialization of certain types of cards
>that have serial eeprom that are based off an R-C time constant
>circuit at Power-On. Luckily for us the manufacturer was willing to
>patch the BIOS and resolved our issue. Perhaps you can contact
>Portwell with this info and see if they are willing to help.
>
>Daniel
>
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] Sparklan WPEA-121N AR9382 168c:abcd

[Manuel Sáez]

Hi,

I am using a kontron nanoetxexpress-sp board with atom processor. I
just update the BIOS with the lastest version of 07/August/2011 but it
did not fix the problem.

I will contact the manufacture of the board too.

Thank you very much for your help.
Manuel


2012/1/10 Hasan Rashid <hrashid@avionica.com>:
> Daniel,
>
> Portwell's Q7 BIOS works without any issues. On the list of board's that
> did not detect the subvendor id are as follows:
>
> CongaTec QA Q7 module
> KaRo Q7 with uBoot boot loader.
>
> At the same time I have ordered some DNXA-116 AR9382 chip radios, it
> would be interesting to see how they fare.
>
> At any rate, that's valuable information and I will contact the
> manufacturer of the board. Thank you.
>
> Best Regards, Hasan R.
>
>
>
>>-----Original Message-----
>>From: Daniel Smith [mailto:viscous.liquid at gmail.com]
>>Sent: Tuesday, January 10, 2012 4:26 PM
>>To: Hasan Rashid
>>Cc: Adrian Chadd; ath9k-devel at lists.ath9k.org
>>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>>On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid
>><hrashid@avionica.com> wrote:
>>>
>>> Adrian,
>>>
>>> This is not an OS issue as I see similar results in Windows,
>>it is definitely a low-level hardware issue.
>>>
>>> I am using a Portwell PQ7-C100XL carrier board with a
>>Portwell PQ7-M105 Q7 module. The radio is initialized properly
>>without any driver hacks with that cpu+board pair.
>>>
>>> Portwell Q7 M105 has AMI BIOS v2.14.1219 on it.
>>>
>>> Regards, Hasan R.
>>>
>>
>>Hey All,
>>
>>We actually had the exact same problem with a board we were
>>prototyping on. Working with the manufacturer it turned out to be a
>>"feature" of the AMI BIOS they were using on the card (sorry I don't
>>have the version right off hand). What happens is that the AMI BIOS
>>does a Root Bridge reset on all the PCI-e buses upon power on. This
>>reset can interfere with the initialization of certain types of cards
>>that have serial eeprom that are based off an R-C time constant
>>circuit at Power-On. Luckily for us the manufacturer was willing to
>>patch the BIOS and resolved our issue. Perhaps you can contact
>>Portwell with this info and see if they are willing to help.
>>
>>Daniel
>>
> 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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

Since bugzilla.kernel.org is again live, would you please create a bug
report there so we can attach all of this information to it?

That way future people can benefit from our debugging. :)

Thanks!


Adrian

On 10 January 2012 13:37, Hasan Rashid <hrashid@avionica.com> wrote:
> Daniel,
>
> Portwell's Q7 BIOS works without any issues. On the list of board's that
> did not detect the subvendor id are as follows:
>
> CongaTec QA Q7 module
> KaRo Q7 with uBoot boot loader.
>
> At the same time I have ordered some DNXA-116 AR9382 chip radios, it
> would be interesting to see how they fare.
>
> At any rate, that's valuable information and I will contact the
> manufacturer of the board. Thank you.
>
> Best Regards, Hasan R.
>
>
>
>>-----Original Message-----
>>From: Daniel Smith [mailto:viscous.liquid at gmail.com]
>>Sent: Tuesday, January 10, 2012 4:26 PM
>>To: Hasan Rashid
>>Cc: Adrian Chadd; ath9k-devel at lists.ath9k.org
>>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>>On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid
>><hrashid@avionica.com> wrote:
>>>
>>> Adrian,
>>>
>>> This is not an OS issue as I see similar results in Windows,
>>it is definitely a low-level hardware issue.
>>>
>>> I am using a Portwell PQ7-C100XL carrier board with a
>>Portwell PQ7-M105 Q7 module. The radio is initialized properly
>>without any driver hacks with that cpu+board pair.
>>>
>>> Portwell Q7 M105 has AMI BIOS v2.14.1219 on it.
>>>
>>> Regards, Hasan R.
>>>
>>
>>Hey All,
>>
>>We actually had the exact same problem with a board we were
>>prototyping on. Working with the manufacturer it turned out to be a
>>"feature" of the AMI BIOS they were using on the card (sorry I don't
>>have the version right off hand). What happens is that the AMI BIOS
>>does a Root Bridge reset on all the PCI-e buses upon power on. This
>>reset can interfere with the initialization of certain types of cards
>>that have serial eeprom that are based off an R-C time constant
>>circuit at Power-On. Luckily for us the manufacturer was willing to
>>patch the BIOS and resolved our issue. Perhaps you can contact
>>Portwell with this info and see if they are willing to help.
>>
>>Daniel
>>
> 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] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

Adrian,

If you don't mind can you take the lead on that? I will contribute to
testing and verification.

Thank you.

Hasan R.


>-----Original Message-----
From: adrian.chadd@gmail.com [mailto:adrian.chadd at gmail.com] 
>On Behalf Of Adrian Chadd
>Sent: Wednesday, January 11, 2012 11:33 AM
>To: Hasan Rashid
>Cc: Daniel Smith; ath9k-devel at lists.ath9k.org
>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
>Since bugzilla.kernel.org is again live, would you please create a bug
>report there so we can attach all of this information to it?
>
>That way future people can benefit from our debugging. :)
>
>Thanks!
>
>
>Adrian
>
>On 10 January 2012 13:37, Hasan Rashid <hrashid@avionica.com> wrote:
>> Daniel,
>>
>> Portwell's Q7 BIOS works without any issues. On the list of 
>board's that
>> did not detect the subvendor id are as follows:
>>
>> CongaTec QA Q7 module
>> KaRo Q7 with uBoot boot loader.
>>
>> At the same time I have ordered some DNXA-116 AR9382 chip radios, it
>> would be interesting to see how they fare.
>>
>> At any rate, that's valuable information and I will contact the
>> manufacturer of the board. Thank you.
>>
>> Best Regards, Hasan R.
>>
>>
>>
>>>-----Original Message-----
>>>From: Daniel Smith [mailto:viscous.liquid at gmail.com]
>>>Sent: Tuesday, January 10, 2012 4:26 PM
>>>To: Hasan Rashid
>>>Cc: Adrian Chadd; ath9k-devel at lists.ath9k.org
>>>Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>>
>>>On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid
>>><hrashid@avionica.com> wrote:
>>>>
>>>> Adrian,
>>>>
>>>> This is not an OS issue as I see similar results in Windows,
>>>it is definitely a low-level hardware issue.
>>>>
>>>> I am using a Portwell PQ7-C100XL carrier board with a
>>>Portwell PQ7-M105 Q7 module. The radio is initialized properly
>>>without any driver hacks with that cpu+board pair.
>>>>
>>>> Portwell Q7 M105 has AMI BIOS v2.14.1219 on it.
>>>>
>>>> Regards, Hasan R.
>>>>
>>>
>>>Hey All,
>>>
>>>We actually had the exact same problem with a board we were
>>>prototyping on. Working with the manufacturer it turned out to be a
>>>"feature" of the AMI BIOS they were using on the card (sorry I don't
>>>have the version right off hand). What happens is that the AMI BIOS
>>>does a Root Bridge reset on all the PCI-e buses upon power on. This
>>>reset can interfere with the initialization of certain types of cards
>>>that have serial eeprom that are based off an R-C time constant
>>>circuit at Power-On. Luckily for us the manufacturer was willing to
>>>patch the BIOS and resolved our issue. Perhaps you can contact
>>>Portwell with this info and see if they are willing to help.
>>>
>>>Daniel
>>>
>> 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] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

On 11 January 2012 09:39, Hasan Rashid <hrashid@avionica.com> wrote:
> Adrian,
>
> If you don't mind can you take the lead on that? I will contribute to
> testing and verification.

Hm, seems I can't find my bugzilla account and it won't let me recover
the password without knowing hte password.

Sigh. :)


Adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

On 10 January 2012 13:25, Daniel Smith <viscous.liquid@gmail.com> wrote:

> We actually had the exact same problem with a board we were
> prototyping on. Working with the manufacturer it turned out to be a
> "feature" of the AMI BIOS they were using on the card (sorry I don't
> have the version right off hand). What happens is that the AMI BIOS
> does a Root Bridge reset on all the PCI-e buses upon power on. This
> reset can interfere with the initialization of certain types of cards
> that have serial eeprom that are based off an R-C time constant
> circuit at Power-On. Luckily for us the manufacturer was willing to
> patch the BIOS and resolved our issue. Perhaps you can contact
> Portwell with this info and see if they are willing to help.

Hi,

So how exactly did it interfere with it?


Adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Daniel Smith]

On Tue, Jan 10, 2012 at 4:54 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 10 January 2012 13:25, Daniel Smith <viscous.liquid@gmail.com> wrote:
>
>> We actually had the exact same problem with a board we were
>> prototyping on. Working with the manufacturer it turned out to be a
>> "feature" of the AMI BIOS they were using on the card (sorry I don't
>> have the version right off hand). What happens is that the AMI BIOS
>> does a Root Bridge reset on all the PCI-e buses upon power on. This
>> reset can interfere with the initialization of certain types of cards
>> that have serial eeprom that are based off an R-C time constant
>> circuit at Power-On. Luckily for us the manufacturer was willing to
>> patch the BIOS and resolved our issue. Perhaps you can contact
>> Portwell with this info and see if they are willing to help.
>
> Hi,
>
> So how exactly did it interfere with it?
>
>
> Adrian

IANAEE, but as I understand the explanation it was that a typically
Root Bridge reset is not supposed to occur until later in the
initialization. In this case, the version of AMI that was on this
board did a reset at power-on and then the required one later. This
first reset interferes with serial eeprom loader and causes it to stop
in the middle of initialization. So when the second reset comes along
the cards do not properly enumerate on the bus properly and you end up
with cards in the reported state. The fix the manufacturer did was to
remove the first Root Bridge reset from the BIOS code, after that our
cards would initialize and enumerate onto the bus properly.

Daniel

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

On 11 January 2012 04:57, Daniel Smith <viscous.liquid@gmail.com> wrote:
>> So how exactly did it interfere with it?
>>
>>
>> Adrian
>
> IANAEE, but as I understand the explanation it was that a typically
> Root Bridge reset is not supposed to occur until later in the
> initialization. In this case, the version of AMI that was on this
> board did a reset at power-on and then the required one later. This
> first reset interferes with serial eeprom loader and causes it to stop
> in the middle of initialization. So when the second reset comes along
> the cards do not properly enumerate on the bus properly and you end up
> with cards in the reported state. The fix the manufacturer did was to
> remove the first Root Bridge reset from the BIOS code, after that our
> cards would initialize and enumerate onto the bus properly.

Ok, cool.

Let me see if there's a reliable way to "hard kick" the device so it
sucks in the EEPROM settings again. There may be a work around we can
do in the OS.


Adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

Daniel Smith wrote:
> as I understand the explanation it was that a typically
> Root Bridge reset is not supposed to occur until later in the
> initialization. In this case, the version of AMI that was on this
> board did a reset at power-on and then the required one later. This
> first reset interferes with serial eeprom loader and causes it to stop
> in the middle of initialization. So when the second reset comes along
> the cards do not properly enumerate on the bus properly and you end up
> with cards in the reported state. The fix the manufacturer did was to
> remove the first Root Bridge reset from the BIOS code, after that our
> cards would initialize and enumerate onto the bus properly.

Peter Stuge wrote:
> What *exactly* is meant by "PCI bus reset" here?

So it's PCIe and not PCI. This is an important distinction. I should
have figured from the AR93xx.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

On 27 March 2013 15:10, Peter Stuge <peter@stuge.se> wrote:
> Peter Stuge wrote:
>> What *exactly* is meant by "PCI bus reset" here?
>
> So it's PCIe and not PCI. This is an important distinction. I should
> have figured from the AR93xx.

same deal holds for PCIE. Read my other reply.

> From Daniel's description above, it seems that the hardware has a
> limitation in that it must not be reset more than once. That seems
> like not so reliable PCIe IP, as long as the issue really is well
> understood, but I'm not sure?
>
> I would really like to hear the exact details about what the hardware
> requires.

It handles multiple resets fine. It doesn't handle BIOS writers doing
weird crap.



Adrian

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

 
I see what you were trying to do here. However, it didn't make a difference. The iw tool still reported non-HT data rates.

Hasan R. 

-----Original Message-----
From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com] 
Sent: Monday, April 11, 2011 12:19 PM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Mon, Apr 11, 2011 at 9:40 PM, Hasan Rashid <hrashad@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.ath9k at gmail.com]
> Sent: Monday, April 11, 2011 12:05 PM
> To: Hasan Rashid
> Cc: Adrian Chadd; ath9k-devel at 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 <hrashad@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-bounces at lists.ath9k.org
>> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed 
>> Shafi
>> Sent: Sunday, April 10, 2011 11:41 AM
>> To: Adrian Chadd
>> Cc: ath9k-devel at 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 <adrian@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.ath9k@gmail.com> wrote:
>>>>
>>>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@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 at lists.ath9k.org
>>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>> >
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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 at 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.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

That's exactly what I did, also, I had to add the vendor ID in the hw_init function for the driver to fully load. I got it to work after making these changes in the ath9k driver.
 
Now I have a different problem. In AP mode using hostapd, the driver doesn't transmit at a higher rate than 54Mbit. The iw tool reports only non-HT data rates. Does the vendor id need to be added somewhere else as well for the rate control algorithm to load 802.11n HT rates? Using iperf I can only get a transmit rate up to 29Mbps. However, when I transmit from an 802.11n station, it works like you would expect, a throughput of 70-80 Mbps. 
 
Thank you!
 
Regards, Hasan R.

________________________________

From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
Sent: ????? 10/04/2011 8:14 AM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd



On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
>> Hello All,
>>
>> I recently purchased a Sparklan WPEA-121N, it uses the AR9382 chipset. It is
>> mentioned as supported on the device list, however, when I load that ath9k
>> modules nothing comes up.
>>
>> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu 10.10
>> on an x86 Core2Duo machine.
>>
>> lspci -vvvnn returns the following:
>>
>> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Device
>> [168c:abcd] (rev 01)
>
> Yes AR9382 is supported in ath9k, your device id 'abcd' ?
> Did you check with the latest compat wireless?

I doubt the vendor id, if you get you vendor id some thing like this might help
diff --git a/drivers/net/wireless/ath/ath9k/pci.c
b/drivers/net/wireless/ath/ath9k/pci.c
index e83128c..594336a 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
        { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI   */
        { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
        { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E  AR9300 */
+       { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E  AR9300 */
        { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E  AR9485 */
        { 0 }
 };


>
>
>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx-
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 0, Cache Line Size: 32 bytes
>>         Interrupt: pin A routed to IRQ 15
>>         Region 0: Memory at fc8e0000 (64-bit, non-prefetchable) [size=128K]
>>         Expansion ROM at fc8d0000 [disabled] [size=64K]
>>         Capabilities: [40] Power Management version 3
>>                 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>> PME(D0+,D1+,D2-,D3hot+,D3cold-)
>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>         Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>>                 Address: 0000000000000000  Data: 0000
>>                 Masking: 00000000  Pending: 00000000
>>         Capabilities: [70] Express (v2) Endpoint, MSI 00
>>                 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us,
>> L1 <8us
>>                         ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
>> Unsupported-
>>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
>>                 DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
>> TransPend-
>>                 LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
>> Latency L0 <2us, L1 <64us
>>                         ClockPM- Surprise- LLActRep- BwNot-
>>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>> CommClk+
>>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>                 LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
>> DLActive- BWMgmt- ABWMgmt-
>>                 DevCap2: Completion Timeout: Not Supported, TimeoutDis+
>>                 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>>                 LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
>> SpeedDis-, Selectable De-emphasis: -6dB
>>                          Transmit Margin: Normal Operating Range,
>> EnterModifiedCompliance- ComplianceSOS-
>>                          Compliance De-emphasis: -6dB
>>                 LnkSta2: Current De-emphasis Level: -6dB
>>         Capabilities: [100 v1] Advanced Error Reporting
>>                 UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>                 UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>                 UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>                 CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr+
>>                 CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr+
>>                 AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap-
>> ChkEn-
>>         Capabilities: [140 v1] Virtual Channel
>>                 Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>>                 Arb:    Fixed- WRR32- WRR64- WRR128-
>>                 Ctrl:   ArbSelect=Fixed
>>                 Status: InProgress-
>>                 VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>>                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128-
>> WRR256-
>>                         Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>>                         Status: NegoPending- InProgress-
>>         Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
>>
>> Hasan R.
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110410/1ab5e724/attachment-0001.htm 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Adrian Chadd]

Is there an easy way to get an EEPROM/OTP contents dump in ath9k?


Adrian

2011/4/11 Hasan Rashid <hrashad@avionica.com>

>  That's exactly what I did, also, I had to add the vendor ID in the
> hw_init function for the driver to fully load. I got it to work after making
> these changes in the ath9k driver.
>
> Now I have a different problem. In AP mode using hostapd, the driver
> doesn't transmit at a higher rate than 54Mbit. The iw tool reports only
> non-HT data rates. Does the vendor id need to be added somewhere else as
> well for the rate control algorithm to load 802.11n HT rates? Using iperf I
> can only get a transmit rate up to 29Mbps. However, when I transmit from an
> 802.11n station, it works like you would expect, a throughput of 70-80 Mbps.
>
>
> Thank you!
>
> Regards, Hasan R.
>  ------------------------------
>  *From:* Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
> *Sent:* ????? 10/04/2011 8:14 AM
> *To:* Hasan Rashid
> *Cc:* ath9k-devel at lists.ath9k.org
> *Subject:* Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
>  On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi <shafi.ath9k@gmail.com>
> wrote:
> > On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com>
> wrote:
> >> Hello All,
> >>
> >> I recently purchased a Sparklan WPEA-121N, it uses the AR9382
> chipset. It is
> >> mentioned as supported on the device list, however, when I load that
> ath9k
> >> modules nothing comes up.
> >>
> >> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu
> 10.10
> >> on an x86 Core2Duo machine.
> >>
> >> lspci -vvvnn returns the following:
> >>
> >> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Device
> >> [168c:abcd] (rev 01)
> >
> > Yes AR9382 is supported in ath9k, your device id 'abcd' ?
> > Did you check with the latest compat wireless?
>
> I doubt the vendor id, if you get you vendor id some thing like this might
> help
> diff --git a/drivers/net/wireless/ath/ath9k/pci.c
> b/drivers/net/wireless/ath/ath9k/pci.c
> index e83128c..594336a 100644
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
>         { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI   */
>         { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
>         { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E  AR9300 */
> +       { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E  AR9300 */
>         { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E  AR9485 */
>         { 0 }
>  };
>
>
> >
> >
> >>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr-
> >> Stepping- SERR- FastB2B- DisINTx-
> >>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> >> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >>         Latency: 0, Cache Line Size: 32 bytes
> >>         Interrupt: pin A routed to IRQ 15
> >>         Region 0: Memory at fc8e0000 (64-bit, non-prefetchable)
> [size=128K]
> >>         Expansion ROM at fc8d0000 [disabled] [size=64K]
> >>         Capabilities: [40] Power Management version 3
> >>                 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
> >> PME(D0+,D1+,D2-,D3hot+,D3cold-)
> >>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> >>         Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> >>                 Address: 0000000000000000  Data: 0000
> >>                 Masking: 00000000  Pending: 00000000
> >>         Capabilities: [70] Express (v2) Endpoint, MSI 00
> >>                 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
> <1us,
> >> L1 <8us
> >>                         ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> >>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> >> Unsupported-
> >>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> >>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
> >>                 DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
> >> TransPend-
> >>                 LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> >> Latency L0 <2us, L1 <64us
> >>                         ClockPM- Surprise- LLActRep- BwNot-
> >>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
> >> CommClk+
> >>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >>                 LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> >> DLActive- BWMgmt- ABWMgmt-
> >>                 DevCap2: Completion Timeout: Not Supported, TimeoutDis+
> >>                 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
> >>                 LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> >> SpeedDis-, Selectable De-emphasis: -6dB
> >>                          Transmit Margin: Normal Operating Range,
> >> EnterModifiedCompliance- ComplianceSOS-
> >>                          Compliance De-emphasis: -6dB
> >>                 LnkSta2: Current De-emphasis Level: -6dB
> >>         Capabilities: [100 v1] Advanced Error Reporting
> >>                 UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt-
> >> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> >>                 UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt-
> >> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> >>                 UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
> UnxCmplt-
> >> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> >>                 CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> >> NonFatalErr+
> >>                 CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> >> NonFatalErr+
> >>                 AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap-
> >> ChkEn-
> >>         Capabilities: [140 v1] Virtual Channel
> >>                 Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
> >>                 Arb:    Fixed- WRR32- WRR64- WRR128-
> >>                 Ctrl:   ArbSelect=Fixed
> >>                 Status: InProgress-
> >>                 VC0:    Caps:   PATOffset=00 MaxTimeSlots=1
> RejSnoopTrans-
> >>                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128-
> >> WRR256-
> >>                         Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> >>                         Status: NegoPending- InProgress-
> >>         Capabilities: [300 v1] Device Serial Number
> 00-00-00-00-00-00-00-00
> >>
> >> Hasan R.
> >> _______________________________________________
> >> ath9k-devel mailing list
> >> ath9k-devel at 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.
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110411/0084e657/attachment-0001.htm 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

cat /sys/kernel/debug/ieee80211/phy0/ath9k/regdump output is attached. 
 
Hasan R.

________________________________

From: adrian.chadd@gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Sunday, April 10, 2011 10:19 PM
To: Hasan Rashid
Cc: Mohammed Shafi; ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd


Is there an easy way to get an EEPROM/OTP contents dump in ath9k? 


Adrian


2011/4/11 Hasan Rashid <hrashad@avionica.com>


	That's exactly what I did, also, I had to add the vendor ID in the hw_init function for the driver to fully load. I got it to work after making these changes in the ath9k driver.
	 
	Now I have a different problem. In AP mode using hostapd, the driver doesn't transmit at a higher rate than 54Mbit. The iw tool reports only non-HT data rates. Does the vendor id need to be added somewhere else as well for the rate control algorithm to load 802.11n HT rates? Using iperf I can only get a transmit rate up to 29Mbps. However, when I transmit from an 802.11n station, it works like you would expect, a throughput of 70-80 Mbps. 
	 
	Thank you!
	 
	Regards, Hasan R.
	
________________________________

	From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
	Sent: ????? 10/04/2011 8:14 AM
	To: Hasan Rashid
	Cc: ath9k-devel at lists.ath9k.org
	Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
	
	

	On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
	> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
	>> Hello All,
	>>
	>> I recently purchased a Sparklan WPEA-121N, it uses the AR9382 chipset. It is
	>> mentioned as supported on the device list, however, when I load that ath9k
	>> modules nothing comes up.
	>>
	>> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu 10.10
	>> on an x86 Core2Duo machine.
	>>
	>> lspci -vvvnn returns the following:
	>>
	>> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Device
	>> [168c:abcd] (rev 01)
	>
	> Yes AR9382 is supported in ath9k, your device id 'abcd' ?
	> Did you check with the latest compat wireless?
	
	I doubt the vendor id, if you get you vendor id some thing like this might help
	diff --git a/drivers/net/wireless/ath/ath9k/pci.c
	b/drivers/net/wireless/ath/ath9k/pci.c
	index e83128c..594336a 100644
	--- a/drivers/net/wireless/ath/ath9k/pci.c
	+++ b/drivers/net/wireless/ath/ath9k/pci.c
	@@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
	        { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI   */
	        { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
	        { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E  AR9300 */
	+       { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E  AR9300 */
	        { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E  AR9485 */
	        { 0 }
	 };
	
	
	>
	>
	>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
	>> Stepping- SERR- FastB2B- DisINTx-
	>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
	>> <TAbort- <MAbort- >SERR- <PERR- INTx-
	>>         Latency: 0, Cache Line Size: 32 bytes
	>>         Interrupt: pin A routed to IRQ 15
	>>         Region 0: Memory at fc8e0000 (64-bit, non-prefetchable) [size=128K]
	>>         Expansion ROM at fc8d0000 [disabled] [size=64K]
	>>         Capabilities: [40] Power Management version 3
	>>                 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
	>> PME(D0+,D1+,D2-,D3hot+,D3cold-)
	>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	>>         Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
	>>                 Address: 0000000000000000  Data: 0000
	>>                 Masking: 00000000  Pending: 00000000
	>>         Capabilities: [70] Express (v2) Endpoint, MSI 00
	>>                 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us,
	>> L1 <8us
	>>                         ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
	>>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
	>> Unsupported-
	>>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
	>>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
	>>                 DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
	>> TransPend-
	>>                 LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
	>> Latency L0 <2us, L1 <64us
	>>                         ClockPM- Surprise- LLActRep- BwNot-
	>>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
	>> CommClk+
	>>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
	>>                 LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
	>> DLActive- BWMgmt- ABWMgmt-
	>>                 DevCap2: Completion Timeout: Not Supported, TimeoutDis+
	>>                 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
	>>                 LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
	>> SpeedDis-, Selectable De-emphasis: -6dB
	>>                          Transmit Margin: Normal Operating Range,
	>> EnterModifiedCompliance- ComplianceSOS-
	>>                          Compliance De-emphasis: -6dB
	>>                 LnkSta2: Current De-emphasis Level: -6dB
	>>         Capabilities: [100 v1] Advanced Error Reporting
	>>                 UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
	>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
	>>                 UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
	>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
	>>                 UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
	>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
	>>                 CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
	>> NonFatalErr+
	>>                 CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
	>> NonFatalErr+
	>>                 AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap-
	>> ChkEn-
	>>         Capabilities: [140 v1] Virtual Channel
	>>                 Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
	>>                 Arb:    Fixed- WRR32- WRR64- WRR128-
	>>                 Ctrl:   ArbSelect=Fixed
	>>                 Status: InProgress-
	>>                 VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
	>>                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128-
	>> WRR256-
	>>                         Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
	>>                         Status: NegoPending- InProgress-
	>>         Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
	>>
	>> Hasan R.
	>> _______________________________________________
	>> ath9k-devel mailing list
	>> ath9k-devel at 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. 

	_______________________________________________
	ath9k-devel mailing list
	ath9k-devel at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110411/f6e0ef73/attachment-0001.htm 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ar9382_sparklan_regdump.txt
Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110411/f6e0ef73/attachment-0001.txt 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Peter Stuge]

Adrian Chadd wrote:
> Is there an easy way to get an EEPROM/OTP contents dump in ath9k?

No. I have some PCI problem, so no progress in the EEPROM direction
from me.


//Peter

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

2011/4/11 Hasan Rashid <hrashad@avionica.com>:
> That's exactly what I did, also, I had to add the vendor?ID in the hw_init
> function for the driver to fully load. I got it to work after making these
> changes in the ath9k driver.
>
yes i missed it, you could got in debug messages.

> Now I have a different problem. In AP mode using hostapd, the driver doesn't
> transmit at a higher rate than 54Mbit. The iw tool reports only non-HT data
> rates. Does the vendor id?need to be added somewhere else as well for the
> rate control algorithm to load 802.11n HT rates? Using iperf I can only
> get?a transmit?rate up to?29Mbps. However, when I transmit from an 802.11n
> station, it works like you would expect, a throughput of 70-80 Mbps.

you need enable  in .config
IEEE 802.11n (High Throughput) support
CONFIG_IEEE80211N=y
and also in hostapd.conf

 Note: You will also need to enable WMM for full HT functionality.
#ieee80211n=1


>
> Thank you!
>
> Regards, Hasan R.
> ________________________________
> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
> Sent: ????? 10/04/2011 8:14 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi <shafi.ath9k@gmail.com>
> wrote:
>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
>>> Hello All,
>>>
>>> I recently purchased a Sparklan WPEA-121N, it uses the AR9382 chipset.?It
>>> is
>>> mentioned as supported on the device list, however, when I load that
>>> ath9k
>>> modules nothing comes up.
>>>
>>> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu
>>> 10.10
>>> on an x86 Core2Duo machine.
>>>
>>> lspci -vvvnn returns the following:
>>>
>>> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Device
>>> [168c:abcd] (rev 01)
>>
>> Yes AR9382 is supported in ath9k, your device id 'abcd' ?
>> Did you check with the latest compat wireless?
>
> I doubt the vendor id, if you get you vendor id some thing like this might
> help
> diff --git a/drivers/net/wireless/ath/ath9k/pci.c
> b/drivers/net/wireless/ath/ath9k/pci.c
> index e83128c..594336a 100644
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
> ??????? { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI?? */
> ??????? { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
> ??????? { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E? AR9300 */
> +?????? { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E? AR9300 */
> ??????? { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E? AR9485 */
> ??????? { 0 }
> ?};
>
>
>>
>>
>>> ??????? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr-
>>> Stepping- SERR- FastB2B- DisINTx-
>>> ??????? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> ??????? Latency: 0, Cache Line Size: 32 bytes
>>> ??????? Interrupt: pin A routed to IRQ 15
>>> ??????? Region 0: Memory at fc8e0000 (64-bit, non-prefetchable)
>>> [size=128K]
>>> ??????? Expansion ROM at fc8d0000 [disabled] [size=64K]
>>> ??????? Capabilities: [40] Power Management version 3
>>> ??????????????? Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>>> PME(D0+,D1+,D2-,D3hot+,D3cold-)
>>> ??????????????? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>> ??????? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>>> ??????????????? Address: 0000000000000000? Data: 0000
>>> ??????????????? Masking: 00000000? Pending: 00000000
>>> ??????? Capabilities: [70] Express (v2) Endpoint, MSI 00
>>> ??????????????? DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
>>> <1us,
>>> L1 <8us
>>> ??????????????????????? ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>>> ??????????????? DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
>>> Unsupported-
>>> ??????????????????????? RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>> ??????????????????????? MaxPayload 128 bytes, MaxReadReq 512 bytes
>>> ??????????????? DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
>>> TransPend-
>>> ??????????????? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
>>> Latency L0 <2us, L1 <64us
>>> ??????????????????????? ClockPM- Surprise- LLActRep- BwNot-
>>> ??????????????? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>>> CommClk+
>>> ??????????????????????? ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>> ??????????????? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
>>> DLActive- BWMgmt- ABWMgmt-
>>> ??????????????? DevCap2: Completion Timeout: Not Supported, TimeoutDis+
>>> ??????????????? DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>>> ??????????????? LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
>>> SpeedDis-, Selectable De-emphasis: -6dB
>>> ???????????????????????? Transmit Margin: Normal Operating Range,
>>> EnterModifiedCompliance- ComplianceSOS-
>>> ???????????????????????? Compliance De-emphasis: -6dB
>>> ??????????????? LnkSta2: Current De-emphasis Level: -6dB
>>> ??????? Capabilities: [100 v1] Advanced Error Reporting
>>> ??????????????? UESta:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> ??????????????? UEMsk:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> ??????????????? UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>> ??????????????? CESta:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>> NonFatalErr+
>>> ??????????????? CEMsk:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>> NonFatalErr+
>>> ??????????????? AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap-
>>> ChkEn-
>>> ??????? Capabilities: [140 v1] Virtual Channel
>>> ??????????????? Caps:?? LPEVC=0 RefClk=100ns PATEntryBits=1
>>> ??????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
>>> ??????????????? Ctrl:?? ArbSelect=Fixed
>>> ??????????????? Status: InProgress-
>>> ??????????????? VC0:??? Caps:?? PATOffset=00 MaxTimeSlots=1
>>> RejSnoopTrans-
>>> ??????????????????????? Arb:??? Fixed- WRR32- WRR64- WRR128- TWRR128-
>>> WRR256-
>>> ??????????????????????? Ctrl:?? Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>>> ??????????????????????? Status: NegoPending- InProgress-
>>> ??????? Capabilities: [300 v1] Device Serial Number
>>> 00-00-00-00-00-00-00-00
>>>
>>> Hasan R.
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at 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.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

 
Which .config? Are you speaking of buildin hostapd with 802.11n support?

I do have ieee80211n set to 1 in hostapd.conf. I have used the same hostapd.conf with other 802.11n cards and it worked just fine, I will attach it nonetheless.

Hasan R.

-----Original Message-----
From: ath9k-devel-bounces@lists.ath9k.org [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed Shafi
Sent: Monday, April 11, 2011 10:13 AM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

2011/4/11 Hasan Rashid <hrashad@avionica.com>:
> That's exactly what I did, also, I had to add the vendor?ID in the 
> hw_init function for the driver to fully load. I got it to work after 
> making these changes in the ath9k driver.
>
yes i missed it, you could got in debug messages.

> Now I have a different problem. In AP mode using hostapd, the driver 
> doesn't transmit at a higher rate than 54Mbit. The iw tool reports 
> only non-HT data rates. Does the vendor id?need to be added somewhere 
> else as well for the rate control algorithm to load 802.11n HT rates? 
> Using iperf I can only get?a transmit?rate up to?29Mbps. However, when 
> I transmit from an 802.11n station, it works like you would expect, a throughput of 70-80 Mbps.

you need enable  in .config
IEEE 802.11n (High Throughput) support
CONFIG_IEEE80211N=y
and also in hostapd.conf

 Note: You will also need to enable WMM for full HT functionality.
#ieee80211n=1


>
> Thank you!
>
> Regards, Hasan R.
> ________________________________
> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
> Sent: ????? 10/04/2011 8:14 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi 
> <shafi.ath9k@gmail.com>
> wrote:
>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
>>> Hello All,
>>>
>>> I recently purchased a Sparklan WPEA-121N, it uses the AR9382 
>>> chipset.?It is mentioned as supported on the device list, however, 
>>> when I load that ath9k modules nothing comes up.
>>>
>>> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu 
>>> 10.10 on an x86 Core2Duo machine.
>>>
>>> lspci -vvvnn returns the following:
>>>
>>> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. 
>>> Device [168c:abcd] (rev 01)
>>
>> Yes AR9382 is supported in ath9k, your device id 'abcd' ?
>> Did you check with the latest compat wireless?
>
> I doubt the vendor id, if you get you vendor id some thing like this 
> might help diff --git a/drivers/net/wireless/ath/ath9k/pci.c
> b/drivers/net/wireless/ath/ath9k/pci.c
> index e83128c..594336a 100644
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
> ??????? { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI?? */
> ??????? { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
> ??????? { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E? AR9300 */
> +?????? { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E? AR9300 */
> ??????? { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E? AR9485 */
> ??????? { 0 }
> ?};
>
>
>>
>>
>>> ??????? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr-
>>> Stepping- SERR- FastB2B- DisINTx-
>>> ??????? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast 
>>> >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> ??????? Latency: 0, Cache Line Size: 32 bytes
>>> ??????? Interrupt: pin A routed to IRQ 15
>>> ??????? Region 0: Memory at fc8e0000 (64-bit, non-prefetchable) 
>>> [size=128K]
>>> ??????? Expansion ROM at fc8d0000 [disabled] [size=64K]
>>> ??????? Capabilities: [40] Power Management version 3
>>> ??????????????? Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>>> PME(D0+,D1+,D2-,D3hot+,D3cold-)
>>> ??????????????? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 
>>> PME-
>>> ??????? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>>> ??????????????? Address: 0000000000000000? Data: 0000
>>> ??????????????? Masking: 00000000? Pending: 00000000
>>> ??????? Capabilities: [70] Express (v2) Endpoint, MSI 00
>>> ??????????????? DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency 
>>> L0s <1us,
>>> L1 <8us
>>> ??????????????????????? ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ 
>>> FLReset-
>>> ??????????????? DevCtl: Report errors: Correctable- Non-Fatal- 
>>> Fatal-
>>> Unsupported-
>>> ??????????????????????? RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>> ??????????????????????? MaxPayload 128 bytes, MaxReadReq 512 bytes
>>> ??????????????? DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ 
>>> AuxPwr-
>>> TransPend-
>>> ??????????????? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s 
>>> L1, Latency L0 <2us, L1 <64us
>>> ??????????????????????? ClockPM- Surprise- LLActRep- BwNot-
>>> ??????????????? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- 
>>> Retrain-
>>> CommClk+
>>> ??????????????????????? ExtSynch- ClockPM- AutWidDis- BWInt- 
>>> AutBWInt-
>>> ??????????????? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- 
>>> SlotClk+
>>> DLActive- BWMgmt- ABWMgmt-
>>> ??????????????? DevCap2: Completion Timeout: Not Supported, 
>>> TimeoutDis+
>>> ??????????????? DevCtl2: Completion Timeout: 50us to 50ms, 
>>> TimeoutDis-
>>> ??????????????? LnkCtl2: Target Link Speed: 2.5GT/s, 
>>> EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>>> ???????????????????????? Transmit Margin: Normal Operating Range,
>>> EnterModifiedCompliance- ComplianceSOS-
>>> ???????????????????????? Compliance De-emphasis: -6dB
>>> ??????????????? LnkSta2: Current De-emphasis Level: -6dB
>>> ??????? Capabilities: [100 v1] Advanced Error Reporting
>>> ??????????????? UESta:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> ??????????????? UEMsk:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> ??????????????? UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>> ??????????????? CESta:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>> NonFatalErr+
>>> ??????????????? CEMsk:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>> NonFatalErr+
>>> ??????????????? AERCap: First Error Pointer: 00, GenCap- CGenEn- 
>>> ChkCap-
>>> ChkEn-
>>> ??????? Capabilities: [140 v1] Virtual Channel
>>> ??????????????? Caps:?? LPEVC=0 RefClk=100ns PATEntryBits=1
>>> ??????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
>>> ??????????????? Ctrl:?? ArbSelect=Fixed
>>> ??????????????? Status: InProgress-
>>> ??????????????? VC0:??? Caps:?? PATOffset=00 MaxTimeSlots=1
>>> RejSnoopTrans-
>>> ??????????????????????? Arb:??? Fixed- WRR32- WRR64- WRR128- 
>>> TWRR128-
>>> WRR256-
>>> ??????????????????????? Ctrl:?? Enable+ ID=0 ArbSelect=Fixed 
>>> TC/VC=01
>>> ??????????????????????? Status: NegoPending- InProgress-
>>> ??????? Capabilities: [300 v1] Device Serial Number 
>>> 00-00-00-00-00-00-00-00
>>>
>>> Hasan R.
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at 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.
_______________________________________________
ath9k-devel mailing list
ath9k-devel at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostapd.conf
Type: application/octet-stream
Size: 33619 bytes
Desc: hostapd.conf
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110411/b38dca68/attachment-0001.obj 

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

2011/4/11 Hasan Rashid <hrashad@avionica.com>:
>
> Which .config? Are you speaking of buildin hostapd with 802.11n support?
>
> I do have ieee80211n set to 1 in hostapd.conf. I have used the same hostapd.conf with other 802.11n cards and it worked just fine, I will attach it nonetheless

no problem, the problem is some where else

>
> Hasan R.
>
> -----Original Message-----
> From: ath9k-devel-bounces at lists.ath9k.org [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed Shafi
> Sent: Monday, April 11, 2011 10:13 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> 2011/4/11 Hasan Rashid <hrashad@avionica.com>:
>> That's exactly what I did, also, I had to add the vendor?ID in the
>> hw_init function for the driver to fully load. I got it to work after
>> making these changes in the ath9k driver.
>>
> yes i missed it, you could got in debug messages.
>
>> Now I have a different problem. In AP mode using hostapd, the driver
>> doesn't transmit at a higher rate than 54Mbit. The iw tool reports
>> only non-HT data rates. Does the vendor id?need to be added somewhere
>> else as well for the rate control algorithm to load 802.11n HT rates?
>> Using iperf I can only get?a transmit?rate up to?29Mbps. However, when
>> I transmit from an 802.11n station, it works like you would expect, a throughput of 70-80 Mbps.
>
> you need enable ?in .config
> IEEE 802.11n (High Throughput) support
> CONFIG_IEEE80211N=y
> and also in hostapd.conf
>
> ?Note: You will also need to enable WMM for full HT functionality.
> #ieee80211n=1
>
>
>>
>> Thank you!
>>
>> Regards, Hasan R.
>> ________________________________
>> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
>> Sent: ????? 10/04/2011 8:14 AM
>> To: Hasan Rashid
>> Cc: ath9k-devel at lists.ath9k.org
>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>> On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi
>> <shafi.ath9k@gmail.com>
>> wrote:
>>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
>>>> Hello All,
>>>>
>>>> I recently purchased a Sparklan WPEA-121N, it uses the AR9382
>>>> chipset.?It is mentioned as supported on the device list, however,
>>>> when I load that ath9k modules nothing comes up.
>>>>
>>>> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu
>>>> 10.10 on an x86 Core2Duo machine.
>>>>
>>>> lspci -vvvnn returns the following:
>>>>
>>>> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc.
>>>> Device [168c:abcd] (rev 01)
>>>
>>> Yes AR9382 is supported in ath9k, your device id 'abcd' ?
>>> Did you check with the latest compat wireless?
>>
>> I doubt the vendor id, if you get you vendor id some thing like this
>> might help diff --git a/drivers/net/wireless/ath/ath9k/pci.c
>> b/drivers/net/wireless/ath/ath9k/pci.c
>> index e83128c..594336a 100644
>> --- a/drivers/net/wireless/ath/ath9k/pci.c
>> +++ b/drivers/net/wireless/ath/ath9k/pci.c
>> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
>> ??????? { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI?? */
>> ??????? { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
>> ??????? { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E? AR9300 */
>> +?????? { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E? AR9300 */
>> ??????? { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E? AR9485 */
>> ??????? { 0 }
>> ?};
>>
>>
>>>
>>>
>>>> ??????? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>>> ParErr-
>>>> Stepping- SERR- FastB2B- DisINTx-
>>>> ??????? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
>>>> >TAbort-
>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>> ??????? Latency: 0, Cache Line Size: 32 bytes
>>>> ??????? Interrupt: pin A routed to IRQ 15
>>>> ??????? Region 0: Memory at fc8e0000 (64-bit, non-prefetchable)
>>>> [size=128K]
>>>> ??????? Expansion ROM at fc8d0000 [disabled] [size=64K]
>>>> ??????? Capabilities: [40] Power Management version 3
>>>> ??????????????? Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>>>> PME(D0+,D1+,D2-,D3hot+,D3cold-)
>>>> ??????????????? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0
>>>> PME-
>>>> ??????? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>>>> ??????????????? Address: 0000000000000000? Data: 0000
>>>> ??????????????? Masking: 00000000? Pending: 00000000
>>>> ??????? Capabilities: [70] Express (v2) Endpoint, MSI 00
>>>> ??????????????? DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency
>>>> L0s <1us,
>>>> L1 <8us
>>>> ??????????????????????? ExtTag- AttnBtn- AttnInd- PwrInd- RBE+
>>>> FLReset-
>>>> ??????????????? DevCtl: Report errors: Correctable- Non-Fatal-
>>>> Fatal-
>>>> Unsupported-
>>>> ??????????????????????? RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>>> ??????????????????????? MaxPayload 128 bytes, MaxReadReq 512 bytes
>>>> ??????????????? DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
>>>> AuxPwr-
>>>> TransPend-
>>>> ??????????????? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s
>>>> L1, Latency L0 <2us, L1 <64us
>>>> ??????????????????????? ClockPM- Surprise- LLActRep- BwNot-
>>>> ??????????????? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled-
>>>> Retrain-
>>>> CommClk+
>>>> ??????????????????????? ExtSynch- ClockPM- AutWidDis- BWInt-
>>>> AutBWInt-
>>>> ??????????????? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
>>>> SlotClk+
>>>> DLActive- BWMgmt- ABWMgmt-
>>>> ??????????????? DevCap2: Completion Timeout: Not Supported,
>>>> TimeoutDis+
>>>> ??????????????? DevCtl2: Completion Timeout: 50us to 50ms,
>>>> TimeoutDis-
>>>> ??????????????? LnkCtl2: Target Link Speed: 2.5GT/s,
>>>> EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>>>> ???????????????????????? Transmit Margin: Normal Operating Range,
>>>> EnterModifiedCompliance- ComplianceSOS-
>>>> ???????????????????????? Compliance De-emphasis: -6dB
>>>> ??????????????? LnkSta2: Current De-emphasis Level: -6dB
>>>> ??????? Capabilities: [100 v1] Advanced Error Reporting
>>>> ??????????????? UESta:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>>> UnxCmplt-
>>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>>> ??????????????? UEMsk:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>>> UnxCmplt-
>>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>>> ??????????????? UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
>>>> UnxCmplt-
>>>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>>> ??????????????? CESta:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>>> NonFatalErr+
>>>> ??????????????? CEMsk:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>>> NonFatalErr+
>>>> ??????????????? AERCap: First Error Pointer: 00, GenCap- CGenEn-
>>>> ChkCap-
>>>> ChkEn-
>>>> ??????? Capabilities: [140 v1] Virtual Channel
>>>> ??????????????? Caps:?? LPEVC=0 RefClk=100ns PATEntryBits=1
>>>> ??????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
>>>> ??????????????? Ctrl:?? ArbSelect=Fixed
>>>> ??????????????? Status: InProgress-
>>>> ??????????????? VC0:??? Caps:?? PATOffset=00 MaxTimeSlots=1
>>>> RejSnoopTrans-
>>>> ??????????????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
>>>> TWRR128-
>>>> WRR256-
>>>> ??????????????????????? Ctrl:?? Enable+ ID=0 ArbSelect=Fixed
>>>> TC/VC=01
>>>> ??????????????????????? Status: NegoPending- InProgress-
>>>> ??????? Capabilities: [300 v1] Device Serial Number
>>>> 00-00-00-00-00-00-00-00
>>>>
>>>> Hasan R.
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at 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.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at 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.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Hasan Rashid]

 
Do I absolutely need Kernel 2.6.36 for AR9382? I am running 2.6.35 at the moment. 

One of the AR9382 based radio's vendors got back to me and mentioned that I need that for the driver work right.

I did compile http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2011-03-31.tar.bz2 on Ubuntu Natty 2.6.38 and it had the same issue.

Hasan R.

-----Original Message-----
From: ath9k-devel-bounces@lists.ath9k.org [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed Shafi
Sent: Monday, April 11, 2011 10:13 AM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

2011/4/11 Hasan Rashid <hrashad@avionica.com>:
> That's exactly what I did, also, I had to add the vendor?ID in the 
> hw_init function for the driver to fully load. I got it to work after 
> making these changes in the ath9k driver.
>
yes i missed it, you could got in debug messages.

> Now I have a different problem. In AP mode using hostapd, the driver 
> doesn't transmit at a higher rate than 54Mbit. The iw tool reports 
> only non-HT data rates. Does the vendor id?need to be added somewhere 
> else as well for the rate control algorithm to load 802.11n HT rates? 
> Using iperf I can only get?a transmit?rate up to?29Mbps. However, when 
> I transmit from an 802.11n station, it works like you would expect, a throughput of 70-80 Mbps.

you need enable  in .config
IEEE 802.11n (High Throughput) support
CONFIG_IEEE80211N=y
and also in hostapd.conf

 Note: You will also need to enable WMM for full HT functionality.
#ieee80211n=1


>
> Thank you!
>
> Regards, Hasan R.
> ________________________________
> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
> Sent: ????? 10/04/2011 8:14 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi 
> <shafi.ath9k@gmail.com>
> wrote:
>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
>>> Hello All,
>>>
>>> I recently purchased a Sparklan WPEA-121N, it uses the AR9382 
>>> chipset.?It is mentioned as supported on the device list, however, 
>>> when I load that ath9k modules nothing comes up.
>>>
>>> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu 
>>> 10.10 on an x86 Core2Duo machine.
>>>
>>> lspci -vvvnn returns the following:
>>>
>>> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. 
>>> Device [168c:abcd] (rev 01)
>>
>> Yes AR9382 is supported in ath9k, your device id 'abcd' ?
>> Did you check with the latest compat wireless?
>
> I doubt the vendor id, if you get you vendor id some thing like this 
> might help diff --git a/drivers/net/wireless/ath/ath9k/pci.c
> b/drivers/net/wireless/ath/ath9k/pci.c
> index e83128c..594336a 100644
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
> ??????? { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI?? */
> ??????? { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
> ??????? { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E? AR9300 */
> +?????? { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E? AR9300 */
> ??????? { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E? AR9485 */
> ??????? { 0 }
> ?};
>
>
>>
>>
>>> ??????? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr-
>>> Stepping- SERR- FastB2B- DisINTx-
>>> ??????? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast 
>>> >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> ??????? Latency: 0, Cache Line Size: 32 bytes
>>> ??????? Interrupt: pin A routed to IRQ 15
>>> ??????? Region 0: Memory at fc8e0000 (64-bit, non-prefetchable) 
>>> [size=128K]
>>> ??????? Expansion ROM at fc8d0000 [disabled] [size=64K]
>>> ??????? Capabilities: [40] Power Management version 3
>>> ??????????????? Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>>> PME(D0+,D1+,D2-,D3hot+,D3cold-)
>>> ??????????????? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 
>>> PME-
>>> ??????? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>>> ??????????????? Address: 0000000000000000? Data: 0000
>>> ??????????????? Masking: 00000000? Pending: 00000000
>>> ??????? Capabilities: [70] Express (v2) Endpoint, MSI 00
>>> ??????????????? DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency 
>>> L0s <1us,
>>> L1 <8us
>>> ??????????????????????? ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ 
>>> FLReset-
>>> ??????????????? DevCtl: Report errors: Correctable- Non-Fatal- 
>>> Fatal-
>>> Unsupported-
>>> ??????????????????????? RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>> ??????????????????????? MaxPayload 128 bytes, MaxReadReq 512 bytes
>>> ??????????????? DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ 
>>> AuxPwr-
>>> TransPend-
>>> ??????????????? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s 
>>> L1, Latency L0 <2us, L1 <64us
>>> ??????????????????????? ClockPM- Surprise- LLActRep- BwNot-
>>> ??????????????? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- 
>>> Retrain-
>>> CommClk+
>>> ??????????????????????? ExtSynch- ClockPM- AutWidDis- BWInt- 
>>> AutBWInt-
>>> ??????????????? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- 
>>> SlotClk+
>>> DLActive- BWMgmt- ABWMgmt-
>>> ??????????????? DevCap2: Completion Timeout: Not Supported, 
>>> TimeoutDis+
>>> ??????????????? DevCtl2: Completion Timeout: 50us to 50ms, 
>>> TimeoutDis-
>>> ??????????????? LnkCtl2: Target Link Speed: 2.5GT/s, 
>>> EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>>> ???????????????????????? Transmit Margin: Normal Operating Range,
>>> EnterModifiedCompliance- ComplianceSOS-
>>> ???????????????????????? Compliance De-emphasis: -6dB
>>> ??????????????? LnkSta2: Current De-emphasis Level: -6dB
>>> ??????? Capabilities: [100 v1] Advanced Error Reporting
>>> ??????????????? UESta:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> ??????????????? UEMsk:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> ??????????????? UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
>>> UnxCmplt-
>>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>> ??????????????? CESta:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>> NonFatalErr+
>>> ??????????????? CEMsk:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>> NonFatalErr+
>>> ??????????????? AERCap: First Error Pointer: 00, GenCap- CGenEn- 
>>> ChkCap-
>>> ChkEn-
>>> ??????? Capabilities: [140 v1] Virtual Channel
>>> ??????????????? Caps:?? LPEVC=0 RefClk=100ns PATEntryBits=1
>>> ??????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
>>> ??????????????? Ctrl:?? ArbSelect=Fixed
>>> ??????????????? Status: InProgress-
>>> ??????????????? VC0:??? Caps:?? PATOffset=00 MaxTimeSlots=1
>>> RejSnoopTrans-
>>> ??????????????????????? Arb:??? Fixed- WRR32- WRR64- WRR128- 
>>> TWRR128-
>>> WRR256-
>>> ??????????????????????? Ctrl:?? Enable+ ID=0 ArbSelect=Fixed 
>>> TC/VC=01
>>> ??????????????????????? Status: NegoPending- InProgress-
>>> ??????? Capabilities: [300 v1] Device Serial Number 
>>> 00-00-00-00-00-00-00-00
>>>
>>> Hasan R.
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at 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.
_______________________________________________
ath9k-devel mailing list
ath9k-devel at 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.

[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Mohammed Shafi]

2011/4/11 Hasan Rashid <hrashad@avionica.com>:
>
> Do I absolutely need Kernel 2.6.36 for AR9382? I am running 2.6.35 at the moment.

you need >=2.6.36 as mentioned in
http://linuxwireless.org/en/users/Drivers/ath9k

>
> One of the AR9382 based radio's vendors got back to me and mentioned that I need that for the driver work right.

he should have meant that >=2.6.36

>
> I did compile http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2011-03-31.tar.bz2 on Ubuntu Natty 2.6.38 and it had the same issue.

but i have 2.6.32-25-generic ubuntu and used the same compat-wireless.
so for compat wireless, 2.6.36 is not a constraint.

>
> Hasan R.
>
> -----Original Message-----
> From: ath9k-devel-bounces at lists.ath9k.org [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Mohammed Shafi
> Sent: Monday, April 11, 2011 10:13 AM
> To: Hasan Rashid
> Cc: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> 2011/4/11 Hasan Rashid <hrashad@avionica.com>:
>> That's exactly what I did, also, I had to add the vendor?ID in the
>> hw_init function for the driver to fully load. I got it to work after
>> making these changes in the ath9k driver.
>>
> yes i missed it, you could got in debug messages.
>
>> Now I have a different problem. In AP mode using hostapd, the driver
>> doesn't transmit at a higher rate than 54Mbit. The iw tool reports
>> only non-HT data rates. Does the vendor id?need to be added somewhere
>> else as well for the rate control algorithm to load 802.11n HT rates?
>> Using iperf I can only get?a transmit?rate up to?29Mbps. However, when
>> I transmit from an 802.11n station, it works like you would expect, a throughput of 70-80 Mbps.
>
> you need enable ?in .config
> IEEE 802.11n (High Throughput) support
> CONFIG_IEEE80211N=y
> and also in hostapd.conf
>
> ?Note: You will also need to enable WMM for full HT functionality.
> #ieee80211n=1
>
>
>>
>> Thank you!
>>
>> Regards, Hasan R.
>> ________________________________
>> From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]
>> Sent: ????? 10/04/2011 8:14 AM
>> To: Hasan Rashid
>> Cc: ath9k-devel at lists.ath9k.org
>> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>>
>> On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi
>> <shafi.ath9k@gmail.com>
>> wrote:
>>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid <hrashad@avionica.com> wrote:
>>>> Hello All,
>>>>
>>>> I recently purchased a Sparklan WPEA-121N, it uses the AR9382
>>>> chipset.?It is mentioned as supported on the device list, however,
>>>> when I load that ath9k modules nothing comes up.
>>>>
>>>> Does ath9k support this chipset? I compiled compat-wirless on Ubuntu
>>>> 10.10 on an x86 Core2Duo machine.
>>>>
>>>> lspci -vvvnn returns the following:
>>>>
>>>> 02:00.0 Ethernet controller [0200]: Atheros Communications Inc.
>>>> Device [168c:abcd] (rev 01)
>>>
>>> Yes AR9382 is supported in ath9k, your device id 'abcd' ?
>>> Did you check with the latest compat wireless?
>>
>> I doubt the vendor id, if you get you vendor id some thing like this
>> might help diff --git a/drivers/net/wireless/ath/ath9k/pci.c
>> b/drivers/net/wireless/ath/ath9k/pci.c
>> index e83128c..594336a 100644
>> --- a/drivers/net/wireless/ath/ath9k/pci.c
>> +++ b/drivers/net/wireless/ath/ath9k/pci.c
>> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
>> ??????? { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI?? */
>> ??????? { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
>> ??????? { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E? AR9300 */
>> +?????? { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E? AR9300 */
>> ??????? { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E? AR9485 */
>> ??????? { 0 }
>> ?};
>>
>>
>>>
>>>
>>>> ??????? Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>>> ParErr-
>>>> Stepping- SERR- FastB2B- DisINTx-
>>>> ??????? Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
>>>> >TAbort-
>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>> ??????? Latency: 0, Cache Line Size: 32 bytes
>>>> ??????? Interrupt: pin A routed to IRQ 15
>>>> ??????? Region 0: Memory at fc8e0000 (64-bit, non-prefetchable)
>>>> [size=128K]
>>>> ??????? Expansion ROM at fc8d0000 [disabled] [size=64K]
>>>> ??????? Capabilities: [40] Power Management version 3
>>>> ??????????????? Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>>>> PME(D0+,D1+,D2-,D3hot+,D3cold-)
>>>> ??????????????? Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0
>>>> PME-
>>>> ??????? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>>>> ??????????????? Address: 0000000000000000? Data: 0000
>>>> ??????????????? Masking: 00000000? Pending: 00000000
>>>> ??????? Capabilities: [70] Express (v2) Endpoint, MSI 00
>>>> ??????????????? DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency
>>>> L0s <1us,
>>>> L1 <8us
>>>> ??????????????????????? ExtTag- AttnBtn- AttnInd- PwrInd- RBE+
>>>> FLReset-
>>>> ??????????????? DevCtl: Report errors: Correctable- Non-Fatal-
>>>> Fatal-
>>>> Unsupported-
>>>> ??????????????????????? RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>>> ??????????????????????? MaxPayload 128 bytes, MaxReadReq 512 bytes
>>>> ??????????????? DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
>>>> AuxPwr-
>>>> TransPend-
>>>> ??????????????? LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s
>>>> L1, Latency L0 <2us, L1 <64us
>>>> ??????????????????????? ClockPM- Surprise- LLActRep- BwNot-
>>>> ??????????????? LnkCtl: ASPM Disabled; RCB 64 bytes Disabled-
>>>> Retrain-
>>>> CommClk+
>>>> ??????????????????????? ExtSynch- ClockPM- AutWidDis- BWInt-
>>>> AutBWInt-
>>>> ??????????????? LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
>>>> SlotClk+
>>>> DLActive- BWMgmt- ABWMgmt-
>>>> ??????????????? DevCap2: Completion Timeout: Not Supported,
>>>> TimeoutDis+
>>>> ??????????????? DevCtl2: Completion Timeout: 50us to 50ms,
>>>> TimeoutDis-
>>>> ??????????????? LnkCtl2: Target Link Speed: 2.5GT/s,
>>>> EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>>>> ???????????????????????? Transmit Margin: Normal Operating Range,
>>>> EnterModifiedCompliance- ComplianceSOS-
>>>> ???????????????????????? Compliance De-emphasis: -6dB
>>>> ??????????????? LnkSta2: Current De-emphasis Level: -6dB
>>>> ??????? Capabilities: [100 v1] Advanced Error Reporting
>>>> ??????????????? UESta:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>>> UnxCmplt-
>>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>>> ??????????????? UEMsk:? DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>>> UnxCmplt-
>>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>>> ??????????????? UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
>>>> UnxCmplt-
>>>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>>> ??????????????? CESta:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>>> NonFatalErr+
>>>> ??????????????? CEMsk:? RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>>>> NonFatalErr+
>>>> ??????????????? AERCap: First Error Pointer: 00, GenCap- CGenEn-
>>>> ChkCap-
>>>> ChkEn-
>>>> ??????? Capabilities: [140 v1] Virtual Channel
>>>> ??????????????? Caps:?? LPEVC=0 RefClk=100ns PATEntryBits=1
>>>> ??????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
>>>> ??????????????? Ctrl:?? ArbSelect=Fixed
>>>> ??????????????? Status: InProgress-
>>>> ??????????????? VC0:??? Caps:?? PATOffset=00 MaxTimeSlots=1
>>>> RejSnoopTrans-
>>>> ??????????????????????? Arb:??? Fixed- WRR32- WRR64- WRR128-
>>>> TWRR128-
>>>> WRR256-
>>>> ??????????????????????? Ctrl:?? Enable+ ID=0 ArbSelect=Fixed
>>>> TC/VC=01
>>>> ??????????????????????? Status: NegoPending- InProgress-
>>>> ??????? Capabilities: [300 v1] Device Serial Number
>>>> 00-00-00-00-00-00-00-00
>>>>
>>>> Hasan R.
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at 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.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at 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.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>