[ath9k-devel] Athk9 bluetooth issue
Hi to all I've installed a GC-WB150 wireless+bluetooth card ( http://www.gigabyte.com/microsite/306/images/wifi.html) on a linux server running Ubuntu 12.04 kernel 3.2.0-34. Both adapters are detected: wireless over pci (athk9 modules): 02:00.0 Network controller: Atheros Communications Inc. Device 0037 (rev 01) and bluetooth over usb (btusb module): Bus 002 Device 003: ID 0cf3:3008 Atheros Communications, Inc. Wireless works good but BT devices is unable to scan and detect devices (the bt led on the card appears off, instead wifi led blinks): root@entest:~# hcitool scan Scanning ... root@entest:~# Following some additional info: hciconfig -a hci0:Type: BR/EDR Bus: USB BD Address: DC:85:DE:09:92:1A ACL MTU: 1022:8 SCO MTU: 183:5 UP RUNNING PSCAN RX bytes:865 acl:0 sco:0 events:38 errors:0 TX bytes:894 acl:0 sco:0 commands:37 errors:0 Features: 0xff 0xfe 0x0d 0xfe 0xd8 0x7f 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF Link mode: SLAVE ACCEPT Name: 'entest-0' Class: 0x6e0100 Service Classes: Networking, Rendering, Capturing, Audio, Telephony Device Class: Computer, Uncategorized HCI Version: 3.0 (0x5) Revision: 0x102 LMP Version: 4.0 (0x6) Subversion: 0x1 Manufacturer: Atheros Communications, Inc. (69) rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no Can anybody help me please? Thank you very much Sergio Sagliocco ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
-Original Message- From: ath9k-devel-boun...@lists.ath9k.org [mailto:ath9k-devel- boun...@lists.ath9k.org] On Behalf Of Adrian Chadd Sent: Wednesday, February 06, 2013 11:06 PM To: Robert Shade Cc: ath9k-devel@lists.ath9k.org; linux-wirel...@vger.kernel.org Subject: Re: [ath9k-devel] Auth Packet TX Delay Okay. Then the radio is truely confused. :-( Which chipset is this again? I'm getting similar behavior using hostapd and an AR5BHB116. The driver identifies this as an AR9300 but I've seen AR9382 associated with AR5BHB116 online. (The PCI ID is 168c:0030, for what it's worth.) Thanks, Dave This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
AR9160 / AR9106 On Thu, Feb 7, 2013 at 12:06 AM, Adrian Chadd adr...@freebsd.org wrote: Okay. Then the radio is truely confused. :-( Which chipset is this again? Adrian On 6 February 2013 14:58, Robert Shade robert.sh...@gmail.com wrote: I tested this all the way up to 1s and am still able to replicate the timeout. Out of curiosity I collected how long the calibration usually takes: avg 825.829us, min 620us, max 830us (16k+ samples) On Wed, Feb 6, 2013 at 7:53 AM, Robert Shade robert.sh...@gmail.com wrote: The 1ms in the message is hard coded. The actual timeout on the register poll is 100ms. On Tue, Feb 5, 2013 at 10:08 PM, Adrian Chadd adr...@freebsd.org wrote: Try bumping that up to 10ms. adrian On 5 February 2013 18:51, Robert Shade robert.sh...@gmail.com wrote: I was finally able to do some additional testing on this. I disabled the one and only block that calls ath9k_hw_do_fastcc. The issue is still reproducible[1], starting with a timeout on AR_PHY_AGC_CONTROL kernel: ath: phy1: timeout (10 us) on reg 0x9860: 0x00048d21 0x0001 != 0x kernel: ath: phy1: offset calibration failed to complete in 1ms; noisy environment? kernel: ath: phy1: Unable to reset channel, reset status -5 kernel: ath: phy1: Unable to set channel It fails to change channel a number of times as it tries to scan, then auth. After it gives up on the auth it goes through a AWAKE - FULL-SLEEP, FULL-SLEEP - AWAKE, AWAKE - FULL-SLEEP, FULL-SLEEP - AWAKE cycle. Afterward, it's able to change channel to the channel the SSID is on and xmit the auth requests, however by that time it's too late. It continues to scan and re-auth, however the auth packets are not sent until it gives up and goes through another AWAKE/FULL-SLEEP cycle after the auth times out. The radio seems to actually be transmitting because I see the SSID probe requests going out and I see my non-broadcasted SSID in the scan logs. [1] It happens randomly on my devices in the field, but I'm able to make it happen pretty quickly if I start a flood ping to my wireless gw and do continuous scans with iw. On Wed, Jan 16, 2013 at 10:12 PM, Adrian Chadd adr...@freebsd.org wrote: Find where the fast channel change code is (maybe) called, and just disable it so it always calls the full channel change? Adrian On 16 January 2013 17:00, Robert Shade robert.sh...@gmail.com wrote: I was able to grab a log with debugging on when the issue started all the way to when it started timing out association due to TX delay: https://dl.dropbox.com/u/12121487/delay-messages.gz On Wed, Jan 16, 2013 at 6:09 PM, Adrian Chadd adr...@freebsd.org wrote: Hm, that register is AR_PHY_RFBUS_GNT, which iirc is only involved in fast channel change. Maybe ath9k's fast channel change code isn't working right, and it's not trying a full channel change afterwards? Adrian On 15 January 2013 14:06, Robert Shade robert.sh...@gmail.com wrote: I'm seeing a periodic issue where the device seems to get stuck in a state where the TX of authentication packets is delayed so that authentication fails. The log snippet below shows the auth packets getting queued after each wlan0: send auth to XX, but they're not actually sent until after it gives up and restarts scanning. Once the device gets into this state, it stays in a SCAN-AUTH-AUTH FAILED-SCAN cycle indefinitely. However, if I do a ifconfig wlan0 down, the device usually recovers and works correctly for a few minutes to hours. This is with the latest compat-drivers. The authentication is EAP-TLS and it's in an environment where it periodically roams using wpa_supplicant's bgscan. Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TX queue: 0 Nov 20 11:24:33 MR89253 kernel: ath: phy0: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TX queue: 1 Nov 20 11:24:33 MR89253 kernel: ath: phy0: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TX queue: 2 Nov 20 11:24:33 MR89253 kernel: ath: phy0: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TX queue: 3 Nov 20 11:24:33 MR89253 kernel: ath: phy0: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TXQ, inactive queue: 4 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TXQ, inactive queue: 5 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TXQ, inactive queue: 6 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TXQ, inactive queue: 7 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TX queue: 8 Nov 20 11:24:33 MR89253 kernel: ath: phy0: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 Nov 20 11:24:33 MR89253 kernel: ath: phy0: Reset TX queue: 9 Nov 20 11:24:33 MR89253 kernel: ath: phy0: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 Nov 20 11:24:33 MR89253 kernel: ath: phy0: ver 64.1 opmode 2
Re: [ath9k-devel] Auth Packet TX Delay
On 7 February 2013 11:43, Robert Shade robert.sh...@gmail.com wrote: AR9160 / AR9106 Things are getting into a really odd state if that particular initial calibration isn't finishing... Things I can think of: * There's some kind of noise going on that's angering the PHY (eg a spur); * We should be doing a cold reset instead of a warm reset, upon a channel change; (That fixes some issues I've seen on the AR9280 in some environments); * Bad/incorrectly hooked up antenans. From a software side, nothing much can be going wrong. as long as the driver isn't doing something stupid like running multiple copies of the reset / setup path on different CPUs/threads, it should be reliable. HTH, Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] drivers: net: Remove remaining alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
For the affected mallocs around these OOM messages:
Converted kmallocs with multiplies to kmalloc_array.
Converted a kmalloc/memcpy to kmemdup.
Removed now unused stack variables.
Removed unnecessary parentheses.
Neatened alignment.
Signed-off-by: Joe Perches j...@perches.com
---
Let me know if you want multiple small patches instead.
drivers/net/can/usb/ems_usb.c | 4 +-
drivers/net/ethernet/amd/pcnet32.c | 47 +++---
drivers/net/ethernet/freescale/gianfar.c | 25 +---
drivers/net/ethernet/intel/e1000/e1000_main.c | 14 ++-
drivers/net/ethernet/intel/ixgb/ixgb_main.c| 10 +
drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c| 2 -
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 11 ++---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +--
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 22 --
drivers/net/ethernet/smsc/smsc9420.c | 9 ++---
drivers/net/usb/pegasus.c | 6 +--
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 11 ++---
drivers/net/wireless/ath/ath9k/hw.c| 7 +---
drivers/net/wireless/ath/ath9k/rc.c| 12 +-
drivers/net/wireless/ath/wil6210/txrx.c| 2 -
drivers/net/wireless/ath/wil6210/wmi.c | 10 ++---
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 5 +--
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 7 ++--
drivers/net/wireless/mwl8k.c | 2 -
20 files changed, 66 insertions(+), 150 deletions(-)
diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
index 0e7bde7..5f9a7ad 100644
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -1019,10 +1019,8 @@ static int ems_usb_probe(struct usb_interface *intf,
dev-tx_msg_buffer = kzalloc(CPC_HEADER_SIZE +
sizeof(struct ems_cpc_msg), GFP_KERNEL);
- if (!dev-tx_msg_buffer) {
- dev_err(intf-dev, Couldn't alloc Tx buffer\n);
+ if (!dev-tx_msg_buffer)
goto cleanup_intr_in_buffer;
- }
usb_set_intfdata(intf, dev);
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet/amd/pcnet32.c
index 74cfc01..797f847 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -494,19 +494,15 @@ static void pcnet32_realloc_tx_ring(struct net_device
*dev,
}
memset(new_tx_ring, 0, sizeof(struct pcnet32_tx_head) * (1 size));
- new_dma_addr_list = kcalloc((1 size), sizeof(dma_addr_t),
- GFP_ATOMIC);
- if (!new_dma_addr_list) {
- netif_err(lp, drv, dev, Memory allocation failed\n);
+ new_dma_addr_list = kcalloc(1 size, sizeof(dma_addr_t),
+ GFP_ATOMIC);
+ if (!new_dma_addr_list)
goto free_new_tx_ring;
- }
- new_skb_list = kcalloc((1 size), sizeof(struct sk_buff *),
- GFP_ATOMIC);
- if (!new_skb_list) {
- netif_err(lp, drv, dev, Memory allocation failed\n);
+ new_skb_list = kcalloc(1 size, sizeof(struct sk_buff *),
+ GFP_ATOMIC);
+ if (!new_skb_list)
goto free_new_lists;
- }
kfree(lp-tx_skbuff);
kfree(lp-tx_dma_addr);
@@ -564,19 +560,14 @@ static void pcnet32_realloc_rx_ring(struct net_device
*dev,
}
memset(new_rx_ring, 0, sizeof(struct pcnet32_rx_head) * (1 size));
- new_dma_addr_list = kcalloc((1 size), sizeof(dma_addr_t),
- GFP_ATOMIC);
- if (!new_dma_addr_list) {
- netif_err(lp, drv, dev, Memory allocation failed\n);
+ new_dma_addr_list = kcalloc(1 size, sizeof(dma_addr_t), GFP_ATOMIC);
+ if (!new_dma_addr_list)
goto free_new_rx_ring;
- }
- new_skb_list = kcalloc((1 size), sizeof(struct sk_buff *),
- GFP_ATOMIC);
- if (!new_skb_list) {
- netif_err(lp, drv, dev, Memory allocation failed\n);
+ new_skb_list = kcalloc(1 size, sizeof(struct sk_buff *),
+ GFP_ATOMIC);
+ if (!new_skb_list)
goto free_new_lists;
- }
/* first copy the current receive buffers */
overlap = min(size, lp-rx_ring_size);
@@ -1933,31 +1924,23 @@ static int pcnet32_alloc_ring(struct net_device *dev,
const char *name)
lp-tx_dma_addr = kcalloc(lp-tx_ring_size, sizeof(dma_addr_t),
GFP_ATOMIC);
- if (!lp-tx_dma_addr) {
- netif_err(lp, drv, dev, Memory allocation failed\n);
+ if (!lp-tx_dma_addr)
return
Re: [ath9k-devel] [PATCH] drivers: net: Remove remaining alloc/OOM messages
On 02/07/2013 10:46 PM, Joe Perches wrote: alloc failures already get standardized OOM messages and a dump_stack. For the affected mallocs around these OOM messages: Converted kmallocs with multiplies to kmalloc_array. Converted a kmalloc/memcpy to kmemdup. Removed now unused stack variables. Removed unnecessary parentheses. Neatened alignment. for brcm80211 driver files listed below: Acked-by: Arend van Spriel ar...@broadcom.com Signed-off-by: Joe Perches j...@perches.com --- Let me know if you want multiple small patches instead. drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 5 +-- drivers/net/wireless/brcm80211/brcmfmac/usb.c | 7 ++-- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] drivers: net: Remove remaining alloc/OOM messages
On 02/07/2013 10:46 PM, Joe Perches wrote: alloc failures already get standardized OOM messages and a dump_stack. For the affected mallocs around these OOM messages: Converted kmallocs with multiplies to kmalloc_array. Converted a kmalloc/memcpy to kmemdup. Removed now unused stack variables. Removed unnecessary parentheses. Neatened alignment. Signed-off-by: Joe Perches j...@perches.com --- Let me know if you want multiple small patches instead. drivers/net/can/usb/ems_usb.c | 4 +- For ems_usb.c Acked-by: Marc Kleine-Budde m...@pengutronix.de regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
