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

2013-04-01 Thread Daniel Smith
On Wed, Mar 27, 2013 at 7:04 PM, Peter Stuge pe...@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@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-28 Thread Steffen Dettmer
Hi all,

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

* adrian.ch...@gmail.com [mailto:adrian.ch...@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@nomad:~# lspci|grep -i ath
01:00.0 Ethernet controller: Atheros Communications Inc. Device abcd (rev 01)
root@nomad:~# i2cset -y 14 0x20 0x0
root@nomad:~# sleep 1
root@nomad:~# i2cset -y 14 0x20 0x1f
root@nomad:~# lspci|grep -i ath
01:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN 
adaptor (rev 01)

I also tried :

root@nomad:~# echo 0  /sys/bus/pci/slots/1/power
root@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-28 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-27 Thread 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.dett...@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@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@nomad:~# grep '' 
 /sys/devices/pci:00/:00:1c.*/:0{1,7}:00.0/{vendor,device}
 /sys/devices/pci:00/:00:1c.0/:01:00.0/vendor:0x168c
 /sys/devices/pci:00/:00:1c.0/:01:00.0/device:0xabcd
 /sys/devices/pci:00/:00:1c.2/:07:00.0/vendor:0x168c
 /sys/devices/pci:00/:00:1c.2/:07:00.0/device:0xabcd
 root@nomad:~# reboot
 [ssh...]
 root@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@nomad:~# grep '' 
 /sys/devices/pci:00/:00:1c.*/:0{1,7}:00.0/{vendor,device}
 /sys/devices/pci:00/:00:1c.0/:01:00.0/vendor:0x168c
 /sys/devices/pci:00/:00:1c.0/:01:00.0/device:0x0030
 /sys/devices/pci:00/:00:1c.2/:07:00.0/vendor:0x168c
 /sys/devices/pci:00/:00:1c.2/:07:00.0/device:0x0030


 root@nomad:/sys/devices/pci:00/:00:1c.0/:01:00.0# grep '' *
 broken_parity_status:0
 class:0x02
 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:
 modalias:pci:v168CdABCDsvsdbc02sc00i00
 grep: power: Is a directory
 grep: remove: Permission denied
 grep: rescan: Permission denied
 grep: reset: Permission denied
 resource:0xfdfe 0xfdff 0x00140204
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0xfdfd 0xfdfd 0x0004e200
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0x 0x 0x
 resource:0x 0x 0x
 grep: resource0: Input/output error
 grep: rom: Invalid argument
 grep: subsystem: Is a directory
 subsystem_device:0x
 subsystem_vendor:0x
 uevent:PCI_CLASS=2
 uevent:PCI_ID=168C:ABCD
 uevent:PCI_SUBSYS_ID=:
 uevent:PCI_SLOT_NAME=:01:00.0
 uevent:MODALIAS=pci:v168CdABCDsvsdbc02sc00i00
 vendor:0x168c

 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel
___
ath9k-devel mailing list

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

2013-03-27 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-27 Thread 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.

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.


//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-27 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-27 Thread Adrian Chadd
On 27 March 2013 15:10, Peter Stuge pe...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-27 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-27 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-27 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2013-03-27 Thread Adrian Chadd
On 27 March 2013 16:04, Peter Stuge pe...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-11 Thread Daniel Smith
On Tue, Jan 10, 2012 at 4:54 PM, Adrian Chadd adr...@freebsd.org wrote:
 On 10 January 2012 13:25, Daniel Smith viscous.liq...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-11 Thread 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 hras...@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.liq...@gmail.com]
Sent: Tuesday, January 10, 2012 4:26 PM
To: Hasan Rashid
Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid
hras...@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@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-11 Thread Adrian Chadd
On 11 January 2012 04:57, Daniel Smith viscous.liq...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-11 Thread 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 hras...@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.liq...@gmail.com]
Sent: Tuesday, January 10, 2012 4:26 PM
To: Hasan Rashid
Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid
hras...@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@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-11 Thread 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.ch...@gmail.com [mailto:adrian.ch...@gmail.com] 
On Behalf Of Adrian Chadd
Sent: Wednesday, January 11, 2012 11:33 AM
To: Hasan Rashid
Cc: Daniel Smith; ath9k-devel@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 hras...@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.liq...@gmail.com]
Sent: Tuesday, January 10, 2012 4:26 PM
To: Hasan Rashid
Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid
hras...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-11 Thread Adrian Chadd
On 11 January 2012 09:39, Hasan Rashid hras...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-10 Thread 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:manuelsa...@gmail.com] 
Sent: Tuesday, January 10, 2012 11:20 AM
To: Hasan Rashid
Cc: Mohammed Shafi; ath9k-devel@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 :01:00.0: PCI INT A - GSI 16 (level, 
low) - IRQ 16
[17464.277258] ath9k :01:00.0: setting latency timer to 64
[17464.277408] ath: Hardware device ID 0xabcd not supported
[17464.277426] ath9k :01:00.0: Failed to initialize device
[17464.277738] ath9k :01:00.0: PCI INT A disabled
[17464.20] ath9k: probe of :01:00.0 failed with error -95

Did you solved the problem?

Thank you and best regards

2011/4/12, Hasan Rashid hras...@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.at...@gmail.com]
 Sent: Tue 4/12/2011 7:46 AM
 To: Hasan Rashid
 Cc: ath9k-devel@lists.ath9k.org
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid 
hras...@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-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of 
Peter Stuge
 Sent: Monday, April 11, 2011 12:20 PM
 To: ath9k-devel@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@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@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

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

2012-01-10 Thread 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 hras...@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:manuelsa...@gmail.com]
Sent: Tuesday, January 10, 2012 11:20 AM
To: Hasan Rashid
Cc: Mohammed Shafi; ath9k-devel@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 :01:00.0: PCI INT A - GSI 16 (level,
low) - IRQ 16
[17464.277258] ath9k :01:00.0: setting latency timer to 64
[17464.277408] ath: Hardware device ID 0xabcd not supported
[17464.277426] ath9k :01:00.0: Failed to initialize device
[17464.277738] ath9k :01:00.0: PCI INT A disabled
[17464.20] ath9k: probe of :01:00.0 failed with error -95

Did you solved the problem?

Thank you and best regards

2011/4/12, Hasan Rashid hras...@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.at...@gmail.com]
 Sent: Tue 4/12/2011 7:46 AM
 To: Hasan Rashid
 Cc: ath9k-devel@lists.ath9k.org
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid
hras...@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-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of
Peter Stuge
 Sent: Monday, April 11, 2011 12:20 PM
 To: ath9k-devel@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@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

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

2012-01-10 Thread 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.ch...@gmail.com [mailto:adrian.ch...@gmail.com] 
On Behalf Of Adrian Chadd
Sent: Tuesday, January 10, 2012 12:37 PM
To: Hasan Rashid
Cc: Manuel Sáez; ath9k-devel@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 hras...@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:manuelsa...@gmail.com]
Sent: Tuesday, January 10, 2012 11:20 AM
To: Hasan Rashid
Cc: Mohammed Shafi; ath9k-devel@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 :01:00.0: PCI INT A - GSI 16 (level,
low) - IRQ 16
[17464.277258] ath9k :01:00.0: setting latency timer to 64
[17464.277408] ath: Hardware device ID 0xabcd not supported
[17464.277426] ath9k :01:00.0: Failed to initialize device
[17464.277738] ath9k :01:00.0: PCI INT A disabled
[17464.20] ath9k: probe of :01:00.0 failed with error -95

Did you solved the problem?

Thank you and best regards

2011/4/12, Hasan Rashid hras...@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.at...@gmail.com]
 Sent: Tue 4/12/2011 7:46 AM
 To: Hasan Rashid
 Cc: ath9k-devel@lists.ath9k.org
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid
hras...@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-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of
Peter Stuge
 Sent: Monday, April 11, 2011 12:20 PM
 To: ath9k-devel@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@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel

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

2012-01-10 Thread Adrian Chadd
On 10 January 2012 10:17, Hasan Rashid hras...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-10 Thread 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.ch...@gmail.com [mailto:adrian.ch...@gmail.com] 
On Behalf Of Adrian Chadd
Sent: Tuesday, January 10, 2012 1:37 PM
To: Hasan Rashid
Cc: Manuel Sáez; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On 10 January 2012 10:17, Hasan Rashid hras...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-10 Thread Adrian Chadd
On 10 January 2012 12:45, Hasan Rashid hras...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-10 Thread 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.ch...@gmail.com [mailto:adrian.ch...@gmail.com] 
On Behalf Of Adrian Chadd
Sent: Tuesday, January 10, 2012 4:11 PM
To: Hasan Rashid
Cc: Manuel Sáez; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On 10 January 2012 12:45, Hasan Rashid hras...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-10 Thread Daniel Smith
On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid hras...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-10 Thread 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.liq...@gmail.com] 
Sent: Tuesday, January 10, 2012 4:26 PM
To: Hasan Rashid
Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid 
hras...@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@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-10 Thread Adrian Chadd
On 10 January 2012 13:23, Hasan Rashid hras...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2012-01-10 Thread Adrian Chadd
On 10 January 2012 13:25, Daniel Smith viscous.liq...@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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-19 Thread 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.at...@gmail.com] 
Sent: Tuesday, April 19, 2011 12:21 AM
To: Hasan Rashid
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Tue, Apr 12, 2011 at 10:02 PM, Hasan Rashid hras...@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.at...@gmail.com]
 Sent: Tue 4/12/2011 7:46 AM
 To: Hasan Rashid
 Cc: ath9k-devel@lists.ath9k.org
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid hras...@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-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Peter Stuge
 Sent: Monday, April 11, 2011 12:20 PM
 To: ath9k-devel@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@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@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel



 This communication contains information that may be confidential or 
 privileged. The information is solely intended for the use of the addressee.
 If you are not the intended recipient, be advised that any disclosure, 
 copy, distribution, or use of the contents of this communication is 
 prohibited. If you have received this communication in error, please 
 immediately notify the sender by telephone or by electronic mail.
This communication contains information that may be confidential or privileged. 
The information is solely intended for the use of the addressee. If you are not 
the intended recipient, be advised that any disclosure, copy, distribution, or 
use of the contents of this communication is prohibited. If you have received 
this communication in
error, please immediately notify the sender by telephone or by electronic mail.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-18 Thread Mohammed Shafi
On Tue, Apr 12, 2011 at 10:02 PM, Hasan Rashid hras...@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.at...@gmail.com]
 Sent: Tue 4/12/2011 7:46 AM
 To: Hasan Rashid
 Cc: ath9k-devel@lists.ath9k.org
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid hras...@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-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Peter Stuge
 Sent: Monday, April 11, 2011 12:20 PM
 To: ath9k-devel@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@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@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@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-12 Thread 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)  0x5) != 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-12 Thread Mohammed Shafi
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid hras...@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-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Peter Stuge
 Sent: Monday, April 11, 2011 12:20 PM
 To: ath9k-devel@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@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@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-12 Thread 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. 

From Windows XP Device Manager
---
Device Instance Id:
PCI\VEN_168CDEV_0030SUBSYS_3116168CREV_01\4492937F000E2

Hardware Ids:
PCI\VEN_168CDEV_0030SUBSYS_3116168CREV_01
PCI\VEN_168CDEV_0030SUBSYS_3116168C
PCI\VEN_168CDEV_0030CC_028000
PCI\VEN_168CDEV_0030CC_0280

Compatible Ids:
PCI\VEN_168CDEV_0030REV_01
PCI\VEN_168CDEV_0030
PCI\VEN_168CCC_028000
PCI\VEN_168CCC_0280
PCI\VEN_168C
PCI\CC_028000
PCI\CC_0280

Matching Device Id:
pci\ven_168cdev_0030subsys_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 fa00 (64-bit, non-prefetchable) [size=128K]
[virtual] Expansion ROM at f200 [disabled] [size=64K]
Capabilities: access denied
Kernel driver in use: ath9k
Kernel modules: ath9k


Hasan R.

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

On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid hras...@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-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Peter Stuge
 Sent: Monday, April 11, 2011 12:20 PM
 To: ath9k-devel@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@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@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@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-12 Thread 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.at...@gmail.com]
Sent: Tue 4/12/2011 7:46 AM
To: Hasan Rashid
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
 
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid hras...@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-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Peter Stuge
 Sent: Monday, April 11, 2011 12:20 PM
 To: ath9k-devel@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@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@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@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-12 Thread 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 hras...@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_168CDEV_0030SUBSYS_3116168CREV_01\4492937F000E2

 Hardware Ids:
 PCI\VEN_168CDEV_0030SUBSYS_3116168CREV_01
 PCI\VEN_168CDEV_0030SUBSYS_3116168C
 PCI\VEN_168CDEV_0030CC_028000
 PCI\VEN_168CDEV_0030CC_0280

 Compatible Ids:
 PCI\VEN_168CDEV_0030REV_01
 PCI\VEN_168CDEV_0030
 PCI\VEN_168CCC_028000
 PCI\VEN_168CCC_0280
 PCI\VEN_168C
 PCI\CC_028000
 PCI\CC_0280

 Matching Device Id:
 pci\ven_168cdev_0030subsys_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 fa00 (64-bit, non-prefetchable) [size=128K]
 [virtual] Expansion ROM at f200 [disabled] [size=64K]
 Capabilities: access denied
 Kernel driver in use: ath9k
 Kernel modules: ath9k


 Hasan R.


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

 On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid hras...@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-boun...@lists.ath9k.org
  [mailto:ath9k-devel-boun...@lists.ath9k.orgath9k-devel-boun...@lists.ath9k.org]
 On Behalf Of Peter Stuge
  Sent: Monday, April 11, 2011 12:20 PM
  To: ath9k-devel@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@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@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

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

2011-04-11 Thread Mohammed Shafi
2011/4/11 Hasan Rashid hras...@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.at...@gmail.com]
 Sent: اتوار 10/04/2011 8:14 AM
 To: Hasan Rashid
 Cc: ath9k-devel@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.at...@gmail.com
 wrote:
 On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid hras...@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 fc8e (64-bit, non-prefetchable)
 [size=128K]
     Expansion ROM at fc8d [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:   Data: 
     Masking:   Pending: 
     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

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

2011-04-11 Thread 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-boun...@lists.ath9k.org 
[mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Mohammed Shafi
Sent: Monday, April 11, 2011 10:13 AM
To: Hasan Rashid
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

2011/4/11 Hasan Rashid hras...@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.at...@gmail.com]
 Sent: اتوار 10/04/2011 8:14 AM
 To: Hasan Rashid
 Cc: ath9k-devel@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.at...@gmail.com
 wrote:
 On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid hras...@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 fc8e (64-bit, non-prefetchable) 
 [size=128K]
     Expansion ROM at fc8d [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:   Data: 
     Masking:   Pending: 
     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

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

2011-04-11 Thread 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-boun...@lists.ath9k.org 
[mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Mohammed Shafi
Sent: Monday, April 11, 2011 10:13 AM
To: Hasan Rashid
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

2011/4/11 Hasan Rashid hras...@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.at...@gmail.com]
 Sent: اتوار 10/04/2011 8:14 AM
 To: Hasan Rashid
 Cc: ath9k-devel@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.at...@gmail.com
 wrote:
 On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid hras...@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 fc8e (64-bit, non-prefetchable) 
 [size=128K]
     Expansion ROM at fc8d [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:   Data: 
     Masking:   Pending: 
     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

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

2011-04-11 Thread Mohammed Shafi
On Mon, Apr 11, 2011 at 6:58 AM, Hasan Rashid hras...@avionica.com wrote:

 I have contacted the manufacturer of the card as well. The correspondent 
 claimed to have used ath9k without any issues. When I first rant lspci the 
 output looked suspiciously bogus to me as well for this card.

 I am using a Ubuntu 10.10 x86 distro and I have little reason to believe 
 lspci has a bug in it. It's most likely that card's eeprom has a bogus vendor 
 id in it. Any how, I was able to modify the code to load the driver for this 
 vendor id. The only problem now is that the driver transmit at non-HT rates 
 only.

 The iw phy info output is attached. I have about 29 clients associated with 
 this AP.

if you have 29 clients and incase you run the traffic surely the rate
will be low and what about the legacy stations.


 Hasan R.


 -Original Message-
 From: ath9k-devel-boun...@lists.ath9k.org 
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Mohammed Shafi
 Sent: Sunday, April 10, 2011 11:41 AM
 To: Adrian Chadd
 Cc: ath9k-devel@lists.ath9k.org; Peter Stuge
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 On Sun, Apr 10, 2011 at 9:04 PM, Adrian Chadd adr...@freebsd.org wrote:
 Incorrect or misplaced EEPROM/OTP data, perhaps?
 From what I gather, the PCI ID on earlier devices is loaded out of
 EEPROM by the silicon itself at power-on. 'abcd' sounds a bit too
 convenient to be what's in EEPROM/OTP; so maybe it's a default value in the 
 silicon?
 (All just conjecture here at this point.)

 Yes, 'abcd' surely looks like a default value stored.


 Adrian
 On 10 April 2011 23:17, Mohammed Shafi shafi.at...@gmail.com wrote:

 On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge pe...@stuge.se wrote:
  Mohammed Shafi wrote:
   Is this a serious proposal from Atheros, or just your attempt at
   a quick fix?
 
  No! its purely a personal idea (am completely responsible for the
  mistake),and I will take a look at it carefully to fix this.
 
  Sorry, I didn't mean that you made a mistake, just that the
  suggestion probably would not get us closer to the actual issue.
 
  Bus level issues are indeed difficult. :\

 thanks, i did not know that. thought simple as adding another device id.
 
 
   A device having an unexpected PCI id means that something is
   really wrong in the device or on the bus, and the solution is
   rarely to pretend that it didn't happen.]
 
  Yeah I can see that, hoping that I may get a correct Device ID
  from the reporter. I dont think 'abcd' is a proper vendor id.
 
  Yes, it's easy to spot. The question is how we can find out *why*
  this happened, so that this error case can be prevented.

 Yes sure.
 
 
   Since this card should work fine in principle, maybe it's some
   issue with missing, or wrong, firmware stored on the Linux system.
 
  AR9382 does not seems to have firmware
 
  Aha! That's only for the USB devices maybe. I don't know much
  detail for these latest devices.
 
 currently only  ath9k_htc needs firmware.

 
  and you have any idea what might went wrong.
 
  Sorry, I don't understand what you mean here.

 Your suggestions about what might have went wrong, as you had already
 told it might be a bus level issue.

 
 
  Also why its detected as Ethernet Controller rather than Network
  controller.
 
  This string comes from the pciutils package and could easily have
  changed. Better look at the numerical device class code, which is
  what is read from hardware.

 thanks, I will look into that.

 
  But I expect that when one thing in config space (device id) is
  bogus then the rest of config space is also quite possibly bogus,
  for the same reason, whatever it is.
 
 
  //Peter
  ___
  ath9k-devel mailing list
  ath9k-devel@lists.ath9k.org
  https://lists.ath9k.org/mailman/listinfo/ath9k-devel
 
 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel


 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel

 This communication contains information that may be confidential or 
 privileged. The information is solely intended for the use of the addressee. 
 If you are not the intended recipient, be advised that any disclosure, copy, 
 distribution, or use of the contents of this communication is prohibited. If 
 you have received this communication in
 error, please immediately notify the sender by telephone or by electronic 
 mail.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-11 Thread 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.at...@gmail.com] 
Sent: Monday, April 11, 2011 12:05 PM
To: Hasan Rashid
Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org; Peter Stuge
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Mon, Apr 11, 2011 at 6:58 AM, Hasan Rashid hras...@avionica.com wrote:

 I have contacted the manufacturer of the card as well. The correspondent 
 claimed to have used ath9k without any issues. When I first rant lspci the 
 output looked suspiciously bogus to me as well for this card.

 I am using a Ubuntu 10.10 x86 distro and I have little reason to believe 
 lspci has a bug in it. It's most likely that card's eeprom has a bogus vendor 
 id in it. Any how, I was able to modify the code to load the driver for this 
 vendor id. The only problem now is that the driver transmit at non-HT rates 
 only.

 The iw phy info output is attached. I have about 29 clients associated with 
 this AP.

if you have 29 clients and incase you run the traffic surely the rate will be 
low and what about the legacy stations.


 Hasan R.


 -Original Message-
 From: ath9k-devel-boun...@lists.ath9k.org 
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Mohammed 
 Shafi
 Sent: Sunday, April 10, 2011 11:41 AM
 To: Adrian Chadd
 Cc: ath9k-devel@lists.ath9k.org; Peter Stuge
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 On Sun, Apr 10, 2011 at 9:04 PM, Adrian Chadd adr...@freebsd.org wrote:
 Incorrect or misplaced EEPROM/OTP data, perhaps?
 From what I gather, the PCI ID on earlier devices is loaded out of 
 EEPROM by the silicon itself at power-on. 'abcd' sounds a bit too 
 convenient to be what's in EEPROM/OTP; so maybe it's a default value in the 
 silicon?
 (All just conjecture here at this point.)

 Yes, 'abcd' surely looks like a default value stored.


 Adrian
 On 10 April 2011 23:17, Mohammed Shafi shafi.at...@gmail.com wrote:

 On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge pe...@stuge.se wrote:
  Mohammed Shafi wrote:
   Is this a serious proposal from Atheros, or just your attempt 
   at a quick fix?
 
  No! its purely a personal idea (am completely responsible for the 
  mistake),and I will take a look at it carefully to fix this.
 
  Sorry, I didn't mean that you made a mistake, just that the 
  suggestion probably would not get us closer to the actual issue.
 
  Bus level issues are indeed difficult. :\

 thanks, i did not know that. thought simple as adding another device id.
 
 
   A device having an unexpected PCI id means that something is 
   really wrong in the device or on the bus, and the solution is 
   rarely to pretend that it didn't happen.]
 
  Yeah I can see that, hoping that I may get a correct Device ID 
  from the reporter. I dont think 'abcd' is a proper vendor id.
 
  Yes, it's easy to spot. The question is how we can find out *why* 
  this happened, so that this error case can be prevented.

 Yes sure.
 
 
   Since this card should work fine in principle, maybe it's some 
   issue with missing, or wrong, firmware stored on the Linux system.
 
  AR9382 does not seems to have firmware
 
  Aha! That's only for the USB devices maybe. I don't know much 
  detail for these latest devices.
 
 currently only  ath9k_htc needs firmware.

 
  and you have any idea what might went wrong.
 
  Sorry, I don't understand what you mean here.

 Your suggestions about what might have went wrong, as you had 
 already told it might be a bus level issue.

 
 
  Also why its detected as Ethernet Controller rather than Network 
  controller.
 
  This string comes from the pciutils package and could easily have 
  changed. Better look at the numerical device class code, which is 
  what is read from hardware.

 thanks, I will look into that.

 
  But I expect that when one thing in config space (device id) is 
  bogus then the rest of config space is also quite possibly bogus, 
  for the same reason, whatever it is.
 
 
  //Peter
  ___
  ath9k-devel mailing list
  ath9k-devel@lists.ath9k.org
  https://lists.ath9k.org/mailman/listinfo/ath9k-devel
 
 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel


 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel

 This communication contains information that may be confidential or 
 privileged. The information is solely intended for the use of the addressee. 
 If you are not the intended recipient, be advised that any disclosure, copy, 
 distribution, or use of the contents of this communication is prohibited. If 
 you

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

2011-04-11 Thread Mohammed Shafi
2011/4/11 Hasan Rashid hras...@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-boun...@lists.ath9k.org 
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Mohammed Shafi
 Sent: Monday, April 11, 2011 10:13 AM
 To: Hasan Rashid
 Cc: ath9k-devel@lists.ath9k.org
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 2011/4/11 Hasan Rashid hras...@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.at...@gmail.com]
 Sent: اتوار 10/04/2011 8:14 AM
 To: Hasan Rashid
 Cc: ath9k-devel@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.at...@gmail.com
 wrote:
 On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid hras...@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 fc8e (64-bit, non-prefetchable)
 [size=128K]
     Expansion ROM at fc8d [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:   Data: 
     Masking:   Pending: 
     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

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

2011-04-11 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-11 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-11 Thread 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.at...@gmail.com] 
Sent: Monday, April 11, 2011 12:19 PM
To: Hasan Rashid
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Mon, Apr 11, 2011 at 9:40 PM, Hasan Rashid hras...@avionica.com wrote:

 The throughput results are consistent regardless of mixed or purely 802.11n 
 clients. If you notice the iw phy info shows only non-HT data rates. This 
 wasn't the case when I used a Ralink 2860 chipset based card.

to make sure that HT is configured in driver please do this

diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 1b5bd13..720a866 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
else
pCap-hw_caps = ~ATH9K_HW_CAP_HT;

+   pCap-hw_caps |= ATH9K_HW_CAP_HT;
+
if (AR_SREV_9271(ah))
pCap-num_gpio_pins = AR9271_NUM_GPIO;
else if (AR_DEVID_7010(ah))



 Hasan R.

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

 On Mon, Apr 11, 2011 at 6:58 AM, Hasan Rashid hras...@avionica.com wrote:

 I have contacted the manufacturer of the card as well. The correspondent 
 claimed to have used ath9k without any issues. When I first rant lspci the 
 output looked suspiciously bogus to me as well for this card.

 I am using a Ubuntu 10.10 x86 distro and I have little reason to believe 
 lspci has a bug in it. It's most likely that card's eeprom has a bogus 
 vendor id in it. Any how, I was able to modify the code to load the driver 
 for this vendor id. The only problem now is that the driver transmit at 
 non-HT rates only.

 The iw phy info output is attached. I have about 29 clients associated with 
 this AP.

 if you have 29 clients and incase you run the traffic surely the rate will be 
 low and what about the legacy stations.


 Hasan R.


 -Original Message-
 From: ath9k-devel-boun...@lists.ath9k.org
 [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Mohammed 
 Shafi
 Sent: Sunday, April 10, 2011 11:41 AM
 To: Adrian Chadd
 Cc: ath9k-devel@lists.ath9k.org; Peter Stuge
 Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

 On Sun, Apr 10, 2011 at 9:04 PM, Adrian Chadd adr...@freebsd.org wrote:
 Incorrect or misplaced EEPROM/OTP data, perhaps?
 From what I gather, the PCI ID on earlier devices is loaded out of 
 EEPROM by the silicon itself at power-on. 'abcd' sounds a bit too 
 convenient to be what's in EEPROM/OTP; so maybe it's a default value in the 
 silicon?
 (All just conjecture here at this point.)

 Yes, 'abcd' surely looks like a default value stored.


 Adrian
 On 10 April 2011 23:17, Mohammed Shafi shafi.at...@gmail.com wrote:

 On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge pe...@stuge.se wrote:
  Mohammed Shafi wrote:
   Is this a serious proposal from Atheros, or just your attempt 
   at a quick fix?
 
  No! its purely a personal idea (am completely responsible for 
  the mistake),and I will take a look at it carefully to fix this.
 
  Sorry, I didn't mean that you made a mistake, just that the 
  suggestion probably would not get us closer to the actual issue.
 
  Bus level issues are indeed difficult. :\

 thanks, i did not know that. thought simple as adding another device id.
 
 
   A device having an unexpected PCI id means that something is 
   really wrong in the device or on the bus, and the solution is 
   rarely to pretend that it didn't happen.]
 
  Yeah I can see that, hoping that I may get a correct Device ID 
  from the reporter. I dont think 'abcd' is a proper vendor id.
 
  Yes, it's easy to spot. The question is how we can find out *why* 
  this happened, so that this error case can be prevented.

 Yes sure.
 
 
   Since this card should work fine in principle, maybe it's some 
   issue with missing, or wrong, firmware stored on the Linux system.
 
  AR9382 does not seems to have firmware
 
  Aha! That's only for the USB devices maybe. I don't know much 
  detail for these latest devices.
 
 currently only  ath9k_htc needs firmware.

 
  and you have any idea what might went wrong.
 
  Sorry, I don't understand what you mean here.

 Your suggestions about what might have went wrong, as you had 
 already told it might be a bus level issue.

 
 
  Also why its detected as Ethernet Controller rather than Network 
  controller.
 
  This string comes from the pciutils package and could easily have 
  changed. Better look at the numerical device class code, which is 
  what is read from hardware

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

2011-04-11 Thread 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-boun...@lists.ath9k.org
[mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Peter Stuge
Sent: Monday, April 11, 2011 12:20 PM
To: ath9k-devel@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@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.[239836.321983] ath9k: Driver unloaded
[239866.470591] Compat-wireless backport release: 
compat-wireless-2011-03-30-1-g7b4debf
[239866.470597] Backport based on linux-next.git next-20110331
[239866.504285] cfg80211: Calling CRDA to update world regulatory domain
[239866.615488] ath9k :02:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17
[239866.615508] ath9k :02:00.0: setting latency timer to 64
[239866.615655] ath9k_hw_init: ah-hw_version.devid 43981
[239866.618241] cfg80211: World regulatory domain updated:
[239866.618247] cfg80211: (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[239866.618254] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 
mBi, 2000 mBm)
[239866.618260] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 
mBi, 2000 mBm)
[239866.618265] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 
mBi, 2000 mBm)
[239866.618271] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 
mBi, 2000 mBm)
[239866.618276] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 
mBi, 2000 mBm)
[239866.624382] ath: EEPROM regdomain: 0x6a
[239866.624385] ath: EEPROM indicates we should expect a direct regpair map
[239866.624392] ath: Country alpha2 being used: 00
[239866.624395] ath: Regpair used: 0x6a
[239866.624401] cfg80211: Updating information on frequency 2412 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624407] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624412] cfg80211: Updating information on frequency 2417 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624418] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624423] cfg80211: Updating information on frequency 2422 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624428] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624433] cfg80211: Updating information on frequency 2427 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624439] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.62] cfg80211: Updating information on frequency 2432 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624449] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624454] cfg80211: Updating information on frequency 2437 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624460] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624465] cfg80211: Updating information on frequency 2442 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624471] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624475] cfg80211: Updating information on frequency 2447 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624481] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624486] cfg80211: Updating information on frequency 2452 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624492] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624496] cfg80211: Updating information on frequency 2457 MHz for a 20 
MHz width channel with regulatory rule:
[239866.624502] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (N/A mBi, 2000 mBm)
[239866.624507] cfg80211: Updating information on frequency 2462 MHz for a 20 
MHz

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

2011-04-10 Thread Mohammed Shafi
On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid hras...@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 fc8e (64-bit, non-prefetchable) [size=128K]
     Expansion ROM at fc8d [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:   Data: 
     Masking:   Pending: 
     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@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-10 Thread Mohammed Shafi
On Sun, Apr 10, 2011 at 5:39 PM, Mohammed Shafi shafi.at...@gmail.com wrote:
 On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid hras...@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 fc8e (64-bit, non-prefetchable) [size=128K]
     Expansion ROM at fc8d [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:   Data: 
     Masking:   Pending: 
     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@lists.ath9k.org
 

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

2011-04-10 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-10 Thread Mohammed Shafi
On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge pe...@stuge.se wrote:
 Mohammed Shafi wrote:
  Is this a serious proposal from Atheros, or just your attempt at
  a quick fix?

 No! its purely a personal idea (am completely responsible for the
 mistake),and I will take a look at it carefully to fix this.

 Sorry, I didn't mean that you made a mistake, just that the
 suggestion probably would not get us closer to the actual issue.

 Bus level issues are indeed difficult. :\

thanks, i did not know that. thought simple as adding another device id.


  A device having an unexpected PCI id means that something is really
  wrong in the device or on the bus, and the solution is rarely to
  pretend that it didn't happen.]

 Yeah I can see that, hoping that I may get a correct Device ID from
 the reporter. I dont think 'abcd' is a proper vendor id.

 Yes, it's easy to spot. The question is how we can find out *why*
 this happened, so that this error case can be prevented.

Yes sure.


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

 AR9382 does not seems to have firmware

 Aha! That's only for the USB devices maybe. I don't know much detail
 for these latest devices.

currently only  ath9k_htc needs firmware.


 and you have any idea what might went wrong.

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

Your suggestions about what might have went wrong, as you had already
told it might be a bus level issue.



 Also why its detected as Ethernet Controller rather than
 Network controller.

 This string comes from the pciutils package and could easily have
 changed. Better look at the numerical device class code, which is
 what is read from hardware.

thanks, I will look into that.


 But I expect that when one thing in config space (device id) is bogus
 then the rest of config space is also quite possibly bogus, for the
 same reason, whatever it is.


 //Peter
 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-10 Thread Adrian Chadd
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.)


Adrian

On 10 April 2011 23:17, Mohammed Shafi shafi.at...@gmail.com wrote:

 On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge pe...@stuge.se wrote:
  Mohammed Shafi wrote:
   Is this a serious proposal from Atheros, or just your attempt at
   a quick fix?
 
  No! its purely a personal idea (am completely responsible for the
  mistake),and I will take a look at it carefully to fix this.
 
  Sorry, I didn't mean that you made a mistake, just that the
  suggestion probably would not get us closer to the actual issue.
 
  Bus level issues are indeed difficult. :\

 thanks, i did not know that. thought simple as adding another device id.
 
 
   A device having an unexpected PCI id means that something is really
   wrong in the device or on the bus, and the solution is rarely to
   pretend that it didn't happen.]
 
  Yeah I can see that, hoping that I may get a correct Device ID from
  the reporter. I dont think 'abcd' is a proper vendor id.
 
  Yes, it's easy to spot. The question is how we can find out *why*
  this happened, so that this error case can be prevented.

 Yes sure.
 
 
   Since this card should work fine in principle, maybe it's some issue
   with missing, or wrong, firmware stored on the Linux system.
 
  AR9382 does not seems to have firmware
 
  Aha! That's only for the USB devices maybe. I don't know much detail
  for these latest devices.
 
 currently only  ath9k_htc needs firmware.

 
  and you have any idea what might went wrong.
 
  Sorry, I don't understand what you mean here.

 Your suggestions about what might have went wrong, as you had already
 told it might be a bus level issue.

 
 
  Also why its detected as Ethernet Controller rather than
  Network controller.
 
  This string comes from the pciutils package and could easily have
  changed. Better look at the numerical device class code, which is
  what is read from hardware.

 thanks, I will look into that.

 
  But I expect that when one thing in config space (device id) is bogus
  then the rest of config space is also quite possibly bogus, for the
  same reason, whatever it is.
 
 
  //Peter
  ___
  ath9k-devel mailing list
  ath9k-devel@lists.ath9k.org
  https://lists.ath9k.org/mailman/listinfo/ath9k-devel
 
 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-10 Thread Mohammed Shafi
On Sun, Apr 10, 2011 at 9:04 PM, Adrian Chadd adr...@freebsd.org wrote:
 Incorrect or misplaced EEPROM/OTP data, perhaps?
 From what I gather, the PCI ID on earlier devices is loaded out of EEPROM by
 the silicon itself at power-on. 'abcd' sounds a bit too convenient to be
 what's in EEPROM/OTP; so maybe it's a default value in the silicon?
 (All just conjecture here at this point.)

Yes, 'abcd' surely looks like a default value stored.


 Adrian
 On 10 April 2011 23:17, Mohammed Shafi shafi.at...@gmail.com wrote:

 On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge pe...@stuge.se wrote:
  Mohammed Shafi wrote:
   Is this a serious proposal from Atheros, or just your attempt at
   a quick fix?
 
  No! its purely a personal idea (am completely responsible for the
  mistake),and I will take a look at it carefully to fix this.
 
  Sorry, I didn't mean that you made a mistake, just that the
  suggestion probably would not get us closer to the actual issue.
 
  Bus level issues are indeed difficult. :\

 thanks, i did not know that. thought simple as adding another device id.
 
 
   A device having an unexpected PCI id means that something is really
   wrong in the device or on the bus, and the solution is rarely to
   pretend that it didn't happen.]
 
  Yeah I can see that, hoping that I may get a correct Device ID from
  the reporter. I dont think 'abcd' is a proper vendor id.
 
  Yes, it's easy to spot. The question is how we can find out *why*
  this happened, so that this error case can be prevented.

 Yes sure.
 
 
   Since this card should work fine in principle, maybe it's some issue
   with missing, or wrong, firmware stored on the Linux system.
 
  AR9382 does not seems to have firmware
 
  Aha! That's only for the USB devices maybe. I don't know much detail
  for these latest devices.
 
 currently only  ath9k_htc needs firmware.

 
  and you have any idea what might went wrong.
 
  Sorry, I don't understand what you mean here.

 Your suggestions about what might have went wrong, as you had already
 told it might be a bus level issue.

 
 
  Also why its detected as Ethernet Controller rather than
  Network controller.
 
  This string comes from the pciutils package and could easily have
  changed. Better look at the numerical device class code, which is
  what is read from hardware.

 thanks, I will look into that.

 
  But I expect that when one thing in config space (device id) is bogus
  then the rest of config space is also quite possibly bogus, for the
  same reason, whatever it is.
 
 
  //Peter
  ___
  ath9k-devel mailing list
  ath9k-devel@lists.ath9k.org
  https://lists.ath9k.org/mailman/listinfo/ath9k-devel
 
 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-10 Thread 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.at...@gmail.com]
Sent: اتوار 10/04/2011 8:14 AM
To: Hasan Rashid
Cc: ath9k-devel@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.at...@gmail.com wrote:
 On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid hras...@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 fc8e (64-bit, non-prefetchable) [size=128K]
 Expansion ROM at fc8d [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:   Data: 
 Masking:   Pending: 
 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

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

2011-04-10 Thread 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-boun...@lists.ath9k.org 
[mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Mohammed Shafi
Sent: Sunday, April 10, 2011 11:41 AM
To: Adrian Chadd
Cc: ath9k-devel@lists.ath9k.org; Peter Stuge
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

On Sun, Apr 10, 2011 at 9:04 PM, Adrian Chadd adr...@freebsd.org wrote:
 Incorrect or misplaced EEPROM/OTP data, perhaps?
 From what I gather, the PCI ID on earlier devices is loaded out of 
 EEPROM by the silicon itself at power-on. 'abcd' sounds a bit too 
 convenient to be what's in EEPROM/OTP; so maybe it's a default value in the 
 silicon?
 (All just conjecture here at this point.)

Yes, 'abcd' surely looks like a default value stored.


 Adrian
 On 10 April 2011 23:17, Mohammed Shafi shafi.at...@gmail.com wrote:

 On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge pe...@stuge.se wrote:
  Mohammed Shafi wrote:
   Is this a serious proposal from Atheros, or just your attempt at 
   a quick fix?
 
  No! its purely a personal idea (am completely responsible for the 
  mistake),and I will take a look at it carefully to fix this.
 
  Sorry, I didn't mean that you made a mistake, just that the 
  suggestion probably would not get us closer to the actual issue.
 
  Bus level issues are indeed difficult. :\

 thanks, i did not know that. thought simple as adding another device id.
 
 
   A device having an unexpected PCI id means that something is 
   really wrong in the device or on the bus, and the solution is 
   rarely to pretend that it didn't happen.]
 
  Yeah I can see that, hoping that I may get a correct Device ID 
  from the reporter. I dont think 'abcd' is a proper vendor id.
 
  Yes, it's easy to spot. The question is how we can find out *why* 
  this happened, so that this error case can be prevented.

 Yes sure.
 
 
   Since this card should work fine in principle, maybe it's some 
   issue with missing, or wrong, firmware stored on the Linux system.
 
  AR9382 does not seems to have firmware
 
  Aha! That's only for the USB devices maybe. I don't know much 
  detail for these latest devices.
 
 currently only  ath9k_htc needs firmware.

 
  and you have any idea what might went wrong.
 
  Sorry, I don't understand what you mean here.

 Your suggestions about what might have went wrong, as you had already 
 told it might be a bus level issue.

 
 
  Also why its detected as Ethernet Controller rather than Network 
  controller.
 
  This string comes from the pciutils package and could easily have 
  changed. Better look at the numerical device class code, which is 
  what is read from hardware.

 thanks, I will look into that.

 
  But I expect that when one thing in config space (device id) is 
  bogus then the rest of config space is also quite possibly bogus, 
  for the same reason, whatever it is.
 
 
  //Peter
  ___
  ath9k-devel mailing list
  ath9k-devel@lists.ath9k.org
  https://lists.ath9k.org/mailman/listinfo/ath9k-devel
 
 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

This communication contains information that may be confidential or privileged. 
The information is solely intended for the use of the addressee. If you are not 
the intended recipient, be advised that any disclosure, copy, distribution, or 
use of the contents of this communication is prohibited. If you have received 
this communication in
error, please immediately notify the sender by telephone or by electronic mail.Wiphy phy0
Band 1:
Capabilities: 0x11ef
RX LDCP
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported

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

2011-04-10 Thread 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 mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


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

2011-04-10 Thread Adrian Chadd
Is there an easy way to get an EEPROM/OTP contents dump in ath9k?


Adrian

2011/4/11 Hasan Rashid hras...@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.at...@gmail.com]
 *Sent:* اتوار 10/04/2011 8:14 AM
 *To:* Hasan Rashid
 *Cc:* ath9k-devel@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.at...@gmail.com
 wrote:
  On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid hras...@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 fc8e (64-bit, non-prefetchable)
 [size=128K]
  Expansion ROM at fc8d [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:   Data: 
  Masking:   Pending: 
  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