Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/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
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
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
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
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/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
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
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
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
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
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
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
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
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
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
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
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
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
