Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Wed, Mar 27, 2013 at 7:04 PM, Peter Stuge 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
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 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 27 March 2013 16:04, Peter Stuge 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
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
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
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
On 27 March 2013 15:10, Peter Stuge wrote: > Peter Stuge wrote: >> What *exactly* is meant by "PCI bus reset" here? > > So it's PCIe and not PCI. This is an important distinction. I should > have figured from the AR93xx. same deal holds for PCIE. Read my other reply. > From Daniel's description above, it seems that the hardware has a > limitation in that it must not be reset more than once. That seems > like not so reliable PCIe IP, as long as the issue really is well > understood, but I'm not sure? > > I would really like to hear the exact details about what the hardware > requires. It handles multiple resets fine. It doesn't handle BIOS writers doing weird crap. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
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
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
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
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 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] Sparklan WPEA-121N AR9382 168c:abcd
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
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On 11 January 2012 09:39, Hasan Rashid 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
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 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 >>> 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
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 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 >> 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 11 January 2012 04:57, Daniel Smith 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
Hi, I am using a kontron nanoetxexpress-sp board with atom processor. I just update the BIOS with the lastest version of 07/August/2011 but it did not fix the problem. I will contact the manufacture of the board too. Thank you very much for your help. Manuel 2012/1/10 Hasan Rashid : > 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 >> wrote: >>> >>> Adrian, >>> >>> This is not an OS issue as I see similar results in Windows, >>it is definitely a low-level hardware issue. >>> >>> I am using a Portwell PQ7-C100XL carrier board with a >>Portwell PQ7-M105 Q7 module. The radio is initialized properly >>without any driver hacks with that cpu+board pair. >>> >>> Portwell Q7 M105 has AMI BIOS v2.14.1219 on it. >>> >>> Regards, Hasan R. >>> >> >>Hey All, >> >>We actually had the exact same problem with a board we were >>prototyping on. Working with the manufacturer it turned out to be a >>"feature" of the AMI BIOS they were using on the card (sorry I don't >>have the version right off hand). What happens is that the AMI BIOS >>does a Root Bridge reset on all the PCI-e buses upon power on. This >>reset can interfere with the initialization of certain types of cards >>that have serial eeprom that are based off an R-C time constant >>circuit at Power-On. Luckily for us the manufacturer was willing to >>patch the BIOS and resolved our issue. Perhaps you can contact >>Portwell with this info and see if they are willing to help. >> >>Daniel >> > This communication contains information that may be confidential or > privileged. The information is solely intended for the use of the addressee. > If you are not the intended recipient, be advised that any disclosure, copy, > distribution, or use of the contents of this communication is prohibited. If > you have received this communication in > error, please immediately notify the sender by telephone or by electronic > mail. > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Tue, Jan 10, 2012 at 4:54 PM, Adrian Chadd wrote: > On 10 January 2012 13:25, Daniel Smith 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 10 January 2012 13:25, Daniel Smith 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
On 10 January 2012 13:23, Hasan Rashid 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
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 > 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 Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid 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
>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 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 10 January 2012 12:45, Hasan Rashid 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
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 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 10:17, Hasan Rashid 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,
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 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 :
>>>>
>>>> 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
>>> 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?
>>&
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 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 :
>>>
>>> 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
>> 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
>>>
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 :
>>
>> 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
> 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 t
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 :
>
> 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 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
On Tue, Apr 19, 2011 at 8:54 PM, Hasan Rashid wrote: > >> does this behaviour is still happening with the Windows driver? > No not under Windows. ok. > > The 802.11n rates with hostapd worked after playing with ht_capab in the > hostapd.conf file. I am not so sure what really made the difference but for > my prototype testing it did the job. Great! > > Thank you everyone for all your help! > > Hasan R. > > -Original Message- > From: Mohammed Shafi [mailto:shafi.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 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 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
> 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 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 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 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 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 wrote: > I put another Sparklan card in a Windows XP machine and following are the > device ids reported by the Atheros driver on Windows. It seems it is > reporting the correct 0x168c, and 0x0030. > > From Windows XP Device Manager > --- > Device Instance Id: > PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&0&00E2 > > Hardware Ids: > PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01 > PCI\VEN_168C&DEV_0030&SUBSYS_3116168C > PCI\VEN_168C&DEV_0030&CC_028000 > PCI\VEN_168C&DEV_0030&CC_0280 > > Compatible Ids: > PCI\VEN_168C&DEV_0030&REV_01 > PCI\VEN_168C&DEV_0030 > PCI\VEN_168C&CC_028000 > PCI\VEN_168C&CC_0280 > PCI\VEN_168C > PCI\CC_028000 > PCI\CC_0280 > > Matching Device Id: > pci\ven_168c&dev_0030&subsys_3116168c > > > Here is the interesting bit, when I first hooked this card I booted my > machine in Ubuntu I saw the same 168c:ABCD. After using it under Windows, I > booted in to Linux today and found that it is reporting the expected IDs. > Now ath9k works right out of the box, no Vendor ID hacking required. I am > using it as station right now. The other card is in a different machine. I > will try to swap the cards to verify my theory. I am thinking the Windows > driver applied a firmware update to the card. Or, the other card skipped > quality checks and has bogus EEPROM data. Any thoughts? > > 0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300 > Wireless LAN adaptor [168c:0030] (rev 01) > > lspci -vvvnn returns > > 0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300 > Wireless LAN adaptor [168c:0030] (rev 01) > Subsystem: Atheros Communications Inc. Device [168c:3116] > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- 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: > 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 > 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
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 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 put another Sparklan card in a Windows XP machine and following are the device ids reported by the Atheros driver on Windows. It seems it is reporting the correct 0x168c, and 0x0030. >From Windows XP Device Manager --- Device Instance Id: PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&0&00E2 Hardware Ids: PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01 PCI\VEN_168C&DEV_0030&SUBSYS_3116168C PCI\VEN_168C&DEV_0030&CC_028000 PCI\VEN_168C&DEV_0030&CC_0280 Compatible Ids: PCI\VEN_168C&DEV_0030&REV_01 PCI\VEN_168C&DEV_0030 PCI\VEN_168C&CC_028000 PCI\VEN_168C&CC_0280 PCI\VEN_168C PCI\CC_028000 PCI\CC_0280 Matching Device Id: pci\ven_168c&dev_0030&subsys_3116168c Here is the interesting bit, when I first hooked this card I booted my machine in Ubuntu I saw the same 168c:ABCD. After using it under Windows, I booted in to Linux today and found that it is reporting the expected IDs. Now ath9k works right out of the box, no Vendor ID hacking required. I am using it as station right now. The other card is in a different machine. I will try to swap the cards to verify my theory. I am thinking the Windows driver applied a firmware update to the card. Or, the other card skipped quality checks and has bogus EEPROM data. Any thoughts? 0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300 Wireless LAN adaptor [168c:0030] (rev 01) lspci -vvvnn returns 0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300 Wireless LAN adaptor [168c:0030] (rev 01) Subsystem: Atheros Communications Inc. Device [168c:3116] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 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 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
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid 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
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 = ;
$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
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) [23986
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
I see what you were trying to do here. However, it didn't make a difference. The iw tool still reported non-HT data rates. Hasan R. -Original Message- From: Mohammed Shafi [mailto:shafi.at...@gmail.com] Sent: Monday, April 11, 2011 12:19 PM To: Hasan Rashid Cc: ath9k-devel@lists.ath9k.org Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd On Mon, Apr 11, 2011 at 9:40 PM, Hasan Rashid wrote: > > The throughput results are consistent regardless of mixed or purely 802.11n > clients. If you notice the iw phy info shows only non-HT data rates. This > wasn't the case when I used a Ralink 2860 chipset based card. to make sure that HT is configured in driver please do this diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index 1b5bd13..720a866 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah) else pCap->hw_caps &= ~ATH9K_HW_CAP_HT; + pCap->hw_caps |= ATH9K_HW_CAP_HT; + if (AR_SREV_9271(ah)) pCap->num_gpio_pins = AR9271_NUM_GPIO; else if (AR_DEVID_7010(ah)) > > Hasan R. > > -Original Message- > From: Mohammed Shafi [mailto:shafi.at...@gmail.com] > Sent: Monday, April 11, 2011 12:05 PM > To: Hasan Rashid > Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org; Peter Stuge > Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd > > On Mon, Apr 11, 2011 at 6:58 AM, Hasan Rashid 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 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 wrote: >>>> >>>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge 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. >>>&
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
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
On Mon, Apr 11, 2011 at 9:40 PM, Hasan Rashid wrote: > > The throughput results are consistent regardless of mixed or purely 802.11n > clients. If you notice the iw phy info shows only non-HT data rates. This > wasn't the case when I used a Ralink 2860 chipset based card. to make sure that HT is configured in driver please do this diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index 1b5bd13..720a866 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah) else pCap->hw_caps &= ~ATH9K_HW_CAP_HT; + pCap->hw_caps |= ATH9K_HW_CAP_HT; + if (AR_SREV_9271(ah)) pCap->num_gpio_pins = AR9271_NUM_GPIO; else if (AR_DEVID_7010(ah)) > > Hasan R. > > -Original Message- > From: Mohammed Shafi [mailto:shafi.at...@gmail.com] > Sent: Monday, April 11, 2011 12:05 PM > To: Hasan Rashid > Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org; Peter Stuge > Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd > > On Mon, Apr 11, 2011 at 6:58 AM, Hasan Rashid 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 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 wrote: >>>> >>>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge 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 >>>&
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
2011/4/11 Hasan Rashid :
>
> 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 :
>> 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
>>
>> wrote:
>>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid 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-
>>>> SERR- >>> 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-
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 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 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 wrote: >>> >>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge 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 easil
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Mon, Apr 11, 2011 at 6:58 AM, Hasan Rashid 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 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 wrote: >>> >>> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge 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. >>> > >>> > >>> > //Pete
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 :
> 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
>
> wrote:
>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid 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-
>>> SERR- >> 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
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
2011/4/11 Hasan Rashid :
>
> Which .config? Are you speaking of buildin hostapd with 802.11n support?
>
> I do have ieee80211n set to 1 in hostapd.conf. I have used the same
> hostapd.conf with other 802.11n cards and it worked just fine, I will attach
> it nonetheless
no problem, the problem is some where else
>
> 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 :
>> 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
>>
>> wrote:
>>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid 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-
>>>> SERR- >>> 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:
>>>>
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 :
> 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
>
> wrote:
>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid 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-
>>> SERR- >> 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- PhantF
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
2011/4/11 Hasan Rashid :
> That's exactly what I did, also, I had to add the vendor ID in the hw_init
> function for the driver to fully load. I got it to work after making these
> changes in the ath9k driver.
>
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
> wrote:
>> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid 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-
>>> SERR- >> 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- Cloc
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
> 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
> wrote:
> > On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid
> 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-
> >> SERR- >> 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-
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
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 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 wrote: >> >> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge 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 communica
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 wrote:
> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid 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-
>> SERR- > 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] Advanc
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Sun, Apr 10, 2011 at 9:04 PM, Adrian Chadd 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 wrote: >> >> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge 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
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 wrote: > On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge 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 8:41 PM, Peter Stuge 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
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:02 PM, Peter Stuge wrote:
> Mohammed,
>
> Mohammed Shafi wrote:
>> +++ b/drivers/net/wireless/ath/ath9k/pci.c
>> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
>> { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI */
>> { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
>> { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E AR9300 */
>> + { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E AR9300 */
>
> Is this a serious proposal from Atheros, or just your attempt at
> a quick fix?
No! its purely a personal idea (am completely responsible for the
mistake),and I will take a look at it carefully to fix this.
>
> A device having an unexpected PCI id means that something is really
> wrong in the device or on the bus, and the solution is rarely to
> pretend that it didn't happen.]
Yeah I can see that, hoping that I may get a correct Device ID from
the reporter. I dont think 'abcd' is a proper vendor id.
>
> I fear this will be another case of "we can not reproduce" which I
> will not bother commenting on again. Everyone knows why that's not a
> helpful approach by now. Hopefully I'm wrong and this time we will
> actually learn what the problem was after some investigation.
Yes, I do have the AR9382 card and the device ID seems to make more
sense and its there in the PCI table.
>
> Since this card should work fine in principle, maybe it's some issue
> with missing, or wrong, firmware stored on the Linux system.
AR9382 does not seems to have firmware and you have any idea what
might went wrong.
Also why its detected as Ethernet Controller rather than Network controller.
Thanks for your suggestions!
>
>
> //Peter
> ___
> ath9k-devel mailing list
> ath9k-devel@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,
Mohammed Shafi wrote:
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -30,6 +30,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_id_table) = {
> { PCI_VDEVICE(ATHEROS, 0x002D) }, /* PCI */
> { PCI_VDEVICE(ATHEROS, 0x002E) }, /* PCI-E */
> { PCI_VDEVICE(ATHEROS, 0x0030) }, /* PCI-E AR9300 */
> + { PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E AR9300 */
Is this a serious proposal from Atheros, or just your attempt at
a quick fix?
A device having an unexpected PCI id means that something is really
wrong in the device or on the bus, and the solution is rarely to
pretend that it didn't happen.
I fear this will be another case of "we can not reproduce" which I
will not bother commenting on again. Everyone knows why that's not a
helpful approach by now. Hopefully I'm wrong and this time we will
actually learn what the problem was after some investigation.
Since this card should work fine in principle, maybe it's some issue
with missing, or wrong, firmware stored on the Linux system.
//Peter
___
ath9k-devel 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 5:39 PM, Mohammed Shafi wrote:
> On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid 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-
>> SERR- > 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.
>> _
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Sat, Apr 9, 2011 at 2:00 AM, Hasan Rashid 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- > SERR- 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
[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Hello All, I recently purchased a Sparklan WPEA-121N, it uses the AR9382 chipset. It is mentioned as supported on the device list, however, when I load that ath9k modules nothing comes up. Does ath9k support this chipset? I compiled compat-wirless on Ubuntu 10.10 on an x86 Core2Duo machine. lspci -vvvnn returns the following: 02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Device [168c:abcd] (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
