Re: [ath9k-devel] Kernel panic with AR9485 and kernel 3.1.6
On Tue, Jan 10, 2012 at 6:24 AM, Kim Lidström dex...@lacto.se wrote:
hi, also did you get some trace with netconsole
No I didn't. netconsole didn't want to sent any messages related to
ath. But if you wish to elaborate what you said about typing out the
dmesg levels I can definitely try that!
I got my USB to Serial adapters today! I'm just waiting for the null
modem now :)
And I will try that patch too!
if we very much suspect the rx path, attache is a debug patch where
we can find out why bf is NULL. we should not get 'b'f NULL when are
doing a good amount of rx, other wise not an issue
--
shafi
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 0e666fb..508f611 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -145,8 +145,10 @@ static bool ath_rx_edma_buf_link(struct ath_softc *sc,
struct ath_buf *bf;
rx_edma = sc-rx.rx_edma[qtype];
- if (skb_queue_len(rx_edma-rx_fifo) = rx_edma-rx_fifo_hwsize)
+ if (skb_queue_len(rx_edma-rx_fifo) = rx_edma-rx_fifo_hwsize) {
+ printk(\nrx_fifo rx_fifo_hwsize!! %s, __func__);
return false;
+ }
bf = list_first_entry(sc-rx.rxbuf, struct ath_buf, list);
list_del_init(bf-list);
@@ -172,7 +174,7 @@ static void ath_rx_addbuffer_edma(struct ath_softc *sc,
u32 nbuf = 0;
if (list_empty(sc-rx.rxbuf)) {
- ath_dbg(common, QUEUE, No free rx buf available\n);
+ printk(\nNo free rx buf available %s, __func__);
return;
}
@@ -668,8 +670,10 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
int ret;
skb = skb_peek(rx_edma-rx_fifo);
- if (!skb)
+ if (!skb) {
+ printk(\nskb_peek returns NULL skb %s, __func__);
return false;
+ }
bf = SKB_CB_ATHBUF(skb);
BUG_ON(!bf);
@@ -679,6 +683,8 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
ret = ath9k_hw_process_rxdesc_edma(ah, NULL, skb-data);
if (ret == -EINPROGRESS) {
+
+ printk(\ndescriptor status info not yet updated %s, __func__);
/*let device gain the buffer again*/
dma_sync_single_for_device(sc-dev, bf-bf_buf_addr,
common-rx_bufsize, DMA_FROM_DEVICE);
@@ -687,6 +693,8 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
__skb_unlink(skb, rx_edma-rx_fifo);
if (ret == -EINVAL) {
+
+ printk(\ncorrupt descriptor %s, __func__);
/* corrupt descriptor, skip this one and the following one */
list_add_tail(bf-list, sc-rx.rxbuf);
ath_rx_edma_buf_link(sc, qtype);
@@ -717,8 +725,11 @@ static struct ath_buf *ath_edma_get_next_rx_buf(struct ath_softc *sc,
while (ath_edma_get_buffers(sc, qtype));
skb = __skb_dequeue(rx_edma-rx_buffers);
- if (!skb)
+
+ if (!skb) {
+ printk(\nskb is NULL dequeued from rx_buffers %s, __func__);
return NULL;
+ }
bf = SKB_CB_ATHBUF(skb);
ath9k_hw_process_rxdesc_edma(sc-sc_ah, rs, skb-data);
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k_htc makes my TL-WN821N get too hot to hang
Hi, I am using ath9k_htc with my TL-WN821N. The problem is when it transfers with max speed (should be 300Mbps but not with ath9k_htc, this could be another story) for some while (eg. 10 mins), the dongle gets really hot and it hangs with no blinked LED. At this time, there is no response from the dongle anymore. I have to plug in/out to make it get normal. But everything under windows is just fine. With max speed (300 Mbps) do some ftp for 1 or 2 hours, everything is just fine. I am so sure that the hang is because of the chips getting too hot. I bought 2 pieces of heat sink and attached them on the two chips. And the transftering lasted almost 1 hours till now (normal case it would die in 15 mins.), even the heat sink is really really hot. lsusb Bus 002 Device 006: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287] kernel version Linux CC 3.1.8-1-ARCH Regards, Beeender ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Manuel,
I figured out that the problem is with the BIOS on the motherboard of the host
device. Some BIOS do not fully read the EPROM contents on the Sparklan radio. I
have used the Sparklan PCIe express card on the same embedded baseboard with
Intel Atom Q7 modules and it seems to be properly recognized by one and not the
other from a different manufacturer. The BIOS was on the Q7 modules and not the
baseboard so each module had a different BIOS.
Apart from that if lspci is showing you 168c:abcd then you have the correct
line added in pci.c. From your dmesg log it appears you force it to load a
hardware with that subvendor id but upon scanning the bus its unable to find
the physical device. I'd say start from making sure, you have it properly
inserted in the PCIe slot, and then work your way up.
- Hasan R.
-Original Message-
From: Manuel Sáez [mailto:manuelsa...@gmail.com]
Sent: Tuesday, January 10, 2012 11:20 AM
To: Hasan Rashid
Cc: Mohammed Shafi; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Hi,
I am having the same problem with two devices. Sparklan WPA-127N
(AR9380) and WLE300NX 6B (AR9390).
I added the line
{ PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E AR9300 */
in pci.c but it did not work. This is the output of dmesg:
[17464.277232] ath9k :01:00.0: PCI INT A - GSI 16 (level,
low) - IRQ 16
[17464.277258] ath9k :01:00.0: setting latency timer to 64
[17464.277408] ath: Hardware device ID 0xabcd not supported
[17464.277426] ath9k :01:00.0: Failed to initialize device
[17464.277738] ath9k :01:00.0: PCI INT A disabled
[17464.20] ath9k: probe of :01:00.0 failed with error -95
Did you solved the problem?
Thank you and best regards
2011/4/12, Hasan Rashid hras...@avionica.com:
I found out the issue is not with the hardware or ath9k. It
is with the
tablet that I am using. On my Dell Vostro 1520 the pci
device ID is reported
correctly without any issues. On the tablet the same card is
reported as an
Ethernet Controller and the bogus vendor id.
On another note, even with the correct vendor id, regardless of AP or
Station mode, the transmit rate is still limited 54MBit/sec.
For now, I think we can close this thread on the note that
the bogus vendor
id is not an ath9k issue.
Thanks for all the help.
-Original Message-
From: Mohammed Shafi [mailto:shafi.at...@gmail.com]
Sent: Tue 4/12/2011 7:46 AM
To: Hasan Rashid
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid
hras...@avionica.com wrote:
I have attached the driver load output in dmesg.
By the way why does AR9382 require Kernel 2.6.36 or higher?
Can you list
the major requirements?
because the hardware code(HAL) will be present from that
kernel version
only.
Hasan R.
-Original Message-
From: ath9k-devel-boun...@lists.ath9k.org
[mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of
Peter Stuge
Sent: Monday, April 11, 2011 12:20 PM
To: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Mohammed Shafi wrote:
to make sure that HT is configured in driver please do this
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 1b5bd13..720a866 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
else
pCap-hw_caps = ~ATH9K_HW_CAP_HT;
+ pCap-hw_caps |= ATH9K_HW_CAP_HT;
+
The indentation is off, or do you mean to include the added
line only
within the else block? If so, remember to add braces.
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
This communication contains information that may be confidential or
privileged. The information is solely intended for the use of the
addressee. If you are not the intended recipient, be
advised that any
disclosure, copy, distribution, or use of the contents of this
communication is prohibited. If you have received this
communication in
error, please immediately notify the sender by telephone or
by electronic
mail.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
This communication contains information that may be confidential or
privileged. The information is solely intended for the use
of the addressee.
If you are not the intended recipient, be advised that any
disclosure, copy,
distribution, or use of the contents of this communication
is prohibited. If
you have received this communication in
error, please immediately notify the sender by telephone or
by electronic
mail.
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Hi,
The BIOS doesn't read the EEPROM on the NIC. The NIC is supposed to
read the EEPROM upon powerup (and on PCI bus reset?) and setup the
initial PCI/register contents from that.
I've seen this before:
* sometimes the NIC itself is damaged;
* sometimes the type of board it's on is the only difference.
So the question really is - what's that BIOS doing that is stopping
the NIC from successfully bootstrapping the initial register values
from EEPROM? It likely would be solved with the application of a
PCI/PCIe bus analyser..
Adrian
On 10 January 2012 08:36, Hasan Rashid hras...@avionica.com wrote:
Manuel,
I figured out that the problem is with the BIOS on the motherboard of the
host device. Some BIOS do not fully read the EPROM contents on the Sparklan
radio. I have used the Sparklan PCIe express card on the same embedded
baseboard with Intel Atom Q7 modules and it seems to be properly recognized
by one and not the other from a different manufacturer. The BIOS was on the
Q7 modules and not the baseboard so each module had a different BIOS.
Apart from that if lspci is showing you 168c:abcd then you have the correct
line added in pci.c. From your dmesg log it appears you force it to load a
hardware with that subvendor id but upon scanning the bus its unable to find
the physical device. I'd say start from making sure, you have it properly
inserted in the PCIe slot, and then work your way up.
- Hasan R.
-Original Message-
From: Manuel Sáez [mailto:manuelsa...@gmail.com]
Sent: Tuesday, January 10, 2012 11:20 AM
To: Hasan Rashid
Cc: Mohammed Shafi; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Hi,
I am having the same problem with two devices. Sparklan WPA-127N
(AR9380) and WLE300NX 6B (AR9390).
I added the line
{ PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E AR9300 */
in pci.c but it did not work. This is the output of dmesg:
[17464.277232] ath9k :01:00.0: PCI INT A - GSI 16 (level,
low) - IRQ 16
[17464.277258] ath9k :01:00.0: setting latency timer to 64
[17464.277408] ath: Hardware device ID 0xabcd not supported
[17464.277426] ath9k :01:00.0: Failed to initialize device
[17464.277738] ath9k :01:00.0: PCI INT A disabled
[17464.20] ath9k: probe of :01:00.0 failed with error -95
Did you solved the problem?
Thank you and best regards
2011/4/12, Hasan Rashid hras...@avionica.com:
I found out the issue is not with the hardware or ath9k. It
is with the
tablet that I am using. On my Dell Vostro 1520 the pci
device ID is reported
correctly without any issues. On the tablet the same card is
reported as an
Ethernet Controller and the bogus vendor id.
On another note, even with the correct vendor id, regardless of AP or
Station mode, the transmit rate is still limited 54MBit/sec.
For now, I think we can close this thread on the note that
the bogus vendor
id is not an ath9k issue.
Thanks for all the help.
-Original Message-
From: Mohammed Shafi [mailto:shafi.at...@gmail.com]
Sent: Tue 4/12/2011 7:46 AM
To: Hasan Rashid
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid
hras...@avionica.com wrote:
I have attached the driver load output in dmesg.
By the way why does AR9382 require Kernel 2.6.36 or higher?
Can you list
the major requirements?
because the hardware code(HAL) will be present from that
kernel version
only.
Hasan R.
-Original Message-
From: ath9k-devel-boun...@lists.ath9k.org
[mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of
Peter Stuge
Sent: Monday, April 11, 2011 12:20 PM
To: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Mohammed Shafi wrote:
to make sure that HT is configured in driver please do this
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 1b5bd13..720a866 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
else
pCap-hw_caps = ~ATH9K_HW_CAP_HT;
+ pCap-hw_caps |= ATH9K_HW_CAP_HT;
+
The indentation is off, or do you mean to include the added
line only
within the else block? If so, remember to add braces.
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
This communication contains information that may be confidential or
privileged. The information is solely intended for the use of the
addressee. If you are not the intended recipient, be
advised that any
disclosure, copy, distribution, or use of the contents of this
communication is prohibited. If you have received this
communication in
error, please immediately notify the sender by telephone or
by electronic
mail.
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Adrian,
I have only been able to narrow it down to the BIOS and unfortunately I do not
have a PCI bus analyzer at my disposal.
- Hasan R.
-Original Message-
From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com]
On Behalf Of Adrian Chadd
Sent: Tuesday, January 10, 2012 12:37 PM
To: Hasan Rashid
Cc: Manuel Sáez; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Hi,
The BIOS doesn't read the EEPROM on the NIC. The NIC is supposed to
read the EEPROM upon powerup (and on PCI bus reset?) and setup the
initial PCI/register contents from that.
I've seen this before:
* sometimes the NIC itself is damaged;
* sometimes the type of board it's on is the only difference.
So the question really is - what's that BIOS doing that is stopping
the NIC from successfully bootstrapping the initial register values
from EEPROM? It likely would be solved with the application of a
PCI/PCIe bus analyser..
Adrian
On 10 January 2012 08:36, Hasan Rashid hras...@avionica.com wrote:
Manuel,
I figured out that the problem is with the BIOS on the
motherboard of the host device. Some BIOS do not fully read
the EPROM contents on the Sparklan radio. I have used the
Sparklan PCIe express card on the same embedded baseboard with
Intel Atom Q7 modules and it seems to be properly recognized
by one and not the other from a different manufacturer. The
BIOS was on the Q7 modules and not the baseboard so each
module had a different BIOS.
Apart from that if lspci is showing you 168c:abcd then you
have the correct line added in pci.c. From your dmesg log it
appears you force it to load a hardware with that subvendor id
but upon scanning the bus its unable to find the physical
device. I'd say start from making sure, you have it properly
inserted in the PCIe slot, and then work your way up.
- Hasan R.
-Original Message-
From: Manuel Sáez [mailto:manuelsa...@gmail.com]
Sent: Tuesday, January 10, 2012 11:20 AM
To: Hasan Rashid
Cc: Mohammed Shafi; ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Hi,
I am having the same problem with two devices. Sparklan WPA-127N
(AR9380) and WLE300NX 6B (AR9390).
I added the line
{ PCI_VDEVICE(ATHEROS, 0xabcd) }, /* PCI-E AR9300 */
in pci.c but it did not work. This is the output of dmesg:
[17464.277232] ath9k :01:00.0: PCI INT A - GSI 16 (level,
low) - IRQ 16
[17464.277258] ath9k :01:00.0: setting latency timer to 64
[17464.277408] ath: Hardware device ID 0xabcd not supported
[17464.277426] ath9k :01:00.0: Failed to initialize device
[17464.277738] ath9k :01:00.0: PCI INT A disabled
[17464.20] ath9k: probe of :01:00.0 failed with error -95
Did you solved the problem?
Thank you and best regards
2011/4/12, Hasan Rashid hras...@avionica.com:
I found out the issue is not with the hardware or ath9k. It
is with the
tablet that I am using. On my Dell Vostro 1520 the pci
device ID is reported
correctly without any issues. On the tablet the same card is
reported as an
Ethernet Controller and the bogus vendor id.
On another note, even with the correct vendor id,
regardless of AP or
Station mode, the transmit rate is still limited 54MBit/sec.
For now, I think we can close this thread on the note that
the bogus vendor
id is not an ath9k issue.
Thanks for all the help.
-Original Message-
From: Mohammed Shafi [mailto:shafi.at...@gmail.com]
Sent: Tue 4/12/2011 7:46 AM
To: Hasan Rashid
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid
hras...@avionica.com wrote:
I have attached the driver load output in dmesg.
By the way why does AR9382 require Kernel 2.6.36 or higher?
Can you list
the major requirements?
because the hardware code(HAL) will be present from that
kernel version
only.
Hasan R.
-Original Message-
From: ath9k-devel-boun...@lists.ath9k.org
[mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of
Peter Stuge
Sent: Monday, April 11, 2011 12:20 PM
To: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Mohammed Shafi wrote:
to make sure that HT is configured in driver please do this
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 1b5bd13..720a866 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct
ath_hw *ah)
else
pCap-hw_caps = ~ATH9K_HW_CAP_HT;
+ pCap-hw_caps |= ATH9K_HW_CAP_HT;
+
The indentation is off, or do you mean to include the added
line only
within the else block? If so, remember to add braces.
//Peter
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On 10 January 2012 10:17, Hasan Rashid hras...@avionica.com wrote: Adrian, I have only been able to narrow it down to the BIOS and unfortunately I do not have a PCI bus analyzer at my disposal. Right, so it's likely something like: * what power states the BIOS tries to place the NIC into at poweron; * what the power state / reset timing looks like; * Maybe APSM related stuff? It could also be something weird with how Linux/BSD/other handle things. There may be some workarounds that can be done in the PCI bus setup code. Are you able to provide me with exactly the board + BIOS details? Maybe it's something I can kick to the guys in the lab to check. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Adrian, This is not an OS issue as I see similar results in Windows, it is definitely a low-level hardware issue. I am using a Portwell PQ7-C100XL carrier board with a Portwell PQ7-M105 Q7 module. The radio is initialized properly without any driver hacks with that cpu+board pair. Portwell Q7 M105 has AMI BIOS v2.14.1219 on it. Regards, Hasan R. -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Tuesday, January 10, 2012 1:37 PM To: Hasan Rashid Cc: Manuel Sáez; ath9k-devel@lists.ath9k.org Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd On 10 January 2012 10:17, Hasan Rashid hras...@avionica.com wrote: Adrian, I have only been able to narrow it down to the BIOS and unfortunately I do not have a PCI bus analyzer at my disposal. Right, so it's likely something like: * what power states the BIOS tries to place the NIC into at poweron; * what the power state / reset timing looks like; * Maybe APSM related stuff? It could also be something weird with how Linux/BSD/other handle things. There may be some workarounds that can be done in the PCI bus setup code. Are you able to provide me with exactly the board + BIOS details? Maybe it's something I can kick to the guys in the lab to check. Adrian This communication contains information that may be confidential or privileged. The information is solely intended for the use of the addressee. If you are not the intended recipient, be advised that any disclosure, copy, distribution, or use of the contents of this communication is prohibited. If you have received this communication in error, please immediately notify the sender by telephone or by electronic mail. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On 10 January 2012 12:45, Hasan Rashid hras...@avionica.com wrote: Adrian, This is not an OS issue as I see similar results in Windows, it is definitely a low-level hardware issue. Right, but as I said, it could be something that is worked around in softwar.e I am using a Portwell PQ7-C100XL carrier board with a Portwell PQ7-M105 Q7 module. The radio is initialized properly without any driver hacks with that cpu+board pair. Portwell Q7 M105 has AMI BIOS v2.14.1219 on it. Ok. I'd be cautious about using the NIC if it's reporting an ID of 0xabcd - that means a bunch of the registers being setup during initial power-on aren't being written. This involves more than just the vendor/subvendor IDs. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
I'd be cautious about using the NIC if it's reporting an ID of 0xabcd - that means a bunch of the registers being setup during initial power-on aren't being written. This involves more than just the vendor/subvendor IDs. You would think so, but it actually performs really well. I have used the radio in a 50+ client video streaming scenario and I didn't encounter any performance related issues. What is most annoying is that only Sparklan's modules exhibit this behavior. Well I hope you're able to figure out a root cause. Hasan R. -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Tuesday, January 10, 2012 4:11 PM To: Hasan Rashid Cc: Manuel Sáez; ath9k-devel@lists.ath9k.org Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd On 10 January 2012 12:45, Hasan Rashid hras...@avionica.com wrote: Adrian, This is not an OS issue as I see similar results in Windows, it is definitely a low-level hardware issue. Right, but as I said, it could be something that is worked around in softwar.e I am using a Portwell PQ7-C100XL carrier board with a Portwell PQ7-M105 Q7 module. The radio is initialized properly without any driver hacks with that cpu+board pair. Portwell Q7 M105 has AMI BIOS v2.14.1219 on it. Ok. I'd be cautious about using the NIC if it's reporting an ID of 0xabcd - that means a bunch of the registers being setup during initial power-on aren't being written. This involves more than just the vendor/subvendor IDs. Adrian This communication contains information that may be confidential or privileged. The information is solely intended for the use of the addressee. If you are not the intended recipient, be advised that any disclosure, copy, distribution, or use of the contents of this communication is prohibited. If you have received this communication in error, please immediately notify the sender by telephone or by electronic mail. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid hras...@avionica.com wrote: Adrian, This is not an OS issue as I see similar results in Windows, it is definitely a low-level hardware issue. I am using a Portwell PQ7-C100XL carrier board with a Portwell PQ7-M105 Q7 module. The radio is initialized properly without any driver hacks with that cpu+board pair. Portwell Q7 M105 has AMI BIOS v2.14.1219 on it. Regards, Hasan R. Hey All, We actually had the exact same problem with a board we were prototyping on. Working with the manufacturer it turned out to be a feature of the AMI BIOS they were using on the card (sorry I don't have the version right off hand). What happens is that the AMI BIOS does a Root Bridge reset on all the PCI-e buses upon power on. This reset can interfere with the initialization of certain types of cards that have serial eeprom that are based off an R-C time constant circuit at Power-On. Luckily for us the manufacturer was willing to patch the BIOS and resolved our issue. Perhaps you can contact Portwell with this info and see if they are willing to help. Daniel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Daniel, Portwell's Q7 BIOS works without any issues. On the list of board's that did not detect the subvendor id are as follows: CongaTec QA Q7 module KaRo Q7 with uBoot boot loader. At the same time I have ordered some DNXA-116 AR9382 chip radios, it would be interesting to see how they fare. At any rate, that's valuable information and I will contact the manufacturer of the board. Thank you. Best Regards, Hasan R. -Original Message- From: Daniel Smith [mailto:viscous.liq...@gmail.com] Sent: Tuesday, January 10, 2012 4:26 PM To: Hasan Rashid Cc: Adrian Chadd; ath9k-devel@lists.ath9k.org Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd On Tue, Jan 10, 2012 at 3:45 PM, Hasan Rashid hras...@avionica.com wrote: Adrian, This is not an OS issue as I see similar results in Windows, it is definitely a low-level hardware issue. I am using a Portwell PQ7-C100XL carrier board with a Portwell PQ7-M105 Q7 module. The radio is initialized properly without any driver hacks with that cpu+board pair. Portwell Q7 M105 has AMI BIOS v2.14.1219 on it. Regards, Hasan R. Hey All, We actually had the exact same problem with a board we were prototyping on. Working with the manufacturer it turned out to be a feature of the AMI BIOS they were using on the card (sorry I don't have the version right off hand). What happens is that the AMI BIOS does a Root Bridge reset on all the PCI-e buses upon power on. This reset can interfere with the initialization of certain types of cards that have serial eeprom that are based off an R-C time constant circuit at Power-On. Luckily for us the manufacturer was willing to patch the BIOS and resolved our issue. Perhaps you can contact Portwell with this info and see if they are willing to help. Daniel This communication contains information that may be confidential or privileged. The information is solely intended for the use of the addressee. If you are not the intended recipient, be advised that any disclosure, copy, distribution, or use of the contents of this communication is prohibited. If you have received this communication in error, please immediately notify the sender by telephone or by electronic mail. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On 10 January 2012 13:23, Hasan Rashid hras...@avionica.com wrote: You would think so, but it actually performs really well. I have used the radio in a 50+ client video streaming scenario and I didn't encounter any performance related issues. What is most annoying is that only Sparklan's modules exhibit this behavior. Well I hope you're able to figure out a root cause. :-) I guess I'm just saying be careful. Who knows what weird corner case stuff may pop up.. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On 10 January 2012 13:25, Daniel Smith viscous.liq...@gmail.com wrote: We actually had the exact same problem with a board we were prototyping on. Working with the manufacturer it turned out to be a feature of the AMI BIOS they were using on the card (sorry I don't have the version right off hand). What happens is that the AMI BIOS does a Root Bridge reset on all the PCI-e buses upon power on. This reset can interfere with the initialization of certain types of cards that have serial eeprom that are based off an R-C time constant circuit at Power-On. Luckily for us the manufacturer was willing to patch the BIOS and resolved our issue. Perhaps you can contact Portwell with this info and see if they are willing to help. Hi, So how exactly did it interfere with it? Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k_htc: power control features
Dear all, I was checking the ath9k_htc support concerning the power control issues in LinuxWireless.org ( http://linuxwireless.org/en/users/Drivers/ath9k_htc#Supported_Devices), but I cannot understand the current development status. Where can I find more information regarding the power control support? Is it possible to use Power-Save Mode and/or Power Management Quality of Service (pm-qos) ? Thanks in advance, Vitor Bernardo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: power control features
On Wed, Jan 11, 2012 at 4:46 AM, Vitor Bernardo vitor.sahkopo...@gmail.com wrote: Dear all, I was checking the ath9k_htc support concerning the power control issues in LinuxWireless.org (http://linuxwireless.org/en/users/Drivers/ath9k_htc#Supported_Devices), but I cannot understand the current development status. Where can I find more information regarding the power control support? Is it possible to use Power-Save Mode and/or Power Management Quality of Service (pm-qos) ? PS disabled by default http://linuxwireless.org/en/users/Drivers/ath9k_htc Thanks in advance, Vitor Bernardo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k_htc makes my TL-WN821N get too hot to hang
Mulong Chen wrote: I am using ath9k_htc with my TL-WN821N. The problem is when it transfers with max speed (should be 300Mbps but not with ath9k_htc, this could be another story) for some while (eg. 10 mins), the dongle gets really hot and it hangs with no blinked LED. At this time, there is no response from the dongle anymore. I have to plug in/out to make it get normal. But everything under windows is just fine. With max speed (300 Mbps) do some ftp for 1 or 2 hours, everything is just fine. I am so sure that the hang is because of the chips getting too hot. I bought 2 pieces of heat sink and attached them on the two chips. And the transftering lasted almost 1 hours till now (normal case it would die in 15 mins.), even the heat sink is really really hot. lsusb Bus 002 Device 006: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287] kernel version Linux CC 3.1.8-1-ARCH Can you install the latest compat-wireless package from: http://linuxwireless.org/en/users/Download ? Debugging has to be enabled by using these flags in config.mk: CONFIG_ATH9K_HTC_DEBUGFS=y CONFIG_ATH_DEBUG=y For generic instructions, please see: http://linuxwireless.org/en/users/Drivers/ath9k/debug And then, please post the output of: cat /sys/kernel/debug/ieee80211/phy#/ath9k_htc/modal_eeprom cat /sys/kernel/debug/ieee80211/phy#/ath9k_htc/base_eeprom Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc makes my TL-WN821N get too hot to hang
I've got the same Problem with the same device used as a Access-Point with HostAPD. I will provide the Information you requested in a few days! Markus Sujith Manoharan schrieb: Mulong Chen wrote: I am using ath9k_htc with my TL-WN821N. The problem is when it transfers with max speed (should be 300Mbps but not with ath9k_htc, this could be another story) for some while (eg. 10 mins), the dongle gets really hot and it hangs with no blinked LED. At this time, there is no response from the dongle anymore. I have to plug in/out to make it get normal. But everything under windows is just fine. With max speed (300 Mbps) do some ftp for 1 or 2 hours, everything is just fine. I am so sure that the hang is because of the chips getting too hot. I bought 2 pieces of heat sink and attached them on the two chips. And the transftering lasted almost 1 hours till now (normal case it would die in 15 mins.), even the heat sink is really really hot. lsusb Bus 002 Device 006: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287] kernel version Linux CC 3.1.8-1-ARCH Can you install the latest compat-wireless package from: http://linuxwireless.org/en/users/Download ? Debugging has to be enabled by using these flags in config.mk: CONFIG_ATH9K_HTC_DEBUGFS=y CONFIG_ATH_DEBUG=y For generic instructions, please see: http://linuxwireless.org/en/users/Drivers/ath9k/debug And then, please post the output of: cat /sys/kernel/debug/ieee80211/phy#/ath9k_htc/modal_eeprom cat /sys/kernel/debug/ieee80211/phy#/ath9k_htc/base_eeprom Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel signature.asc Description: OpenPGP digital signature ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
