Re: [PATCH] ath9k: Reduce max roc duration
On 15/10/14 3:59 am, "Sujith Manoharan" wrote: >MCC is currently used in CUS227, an Allplay >device. Since audio streaming will be affected >with long offchannel periods, reduce the max. >offchannel duration to 200ms. >diff --git a/drivers/net/wireless/ath/ath9k/init.c >b/drivers/net/wireless/ath/ath9k/init.c >@@ -789,7 +789,7 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, >struct ieee80211_hw *hw) >- hw->wiphy->max_remain_on_channel_duration = 1; >+ hw->wiphy->max_remain_on_channel_duration = 200; This looks like a bad idea as the default value. Wouldn't this break a lot of use cases where longer wait is needed? Please keep in mind that remain-on-channel is used for non-P2P use cases as well and there are known P2P devices that won't be able to reply in 200 ms to messages in many cases. I would not reduce this value below 1000 ms and really, if there is need to reduce remain-on-channel operations while there is a concurrent connection, that should be done dynamically at runtime, e.g., in wpa_supplicant, rather than the driver hardcoding a very small maximum value. - Jouni -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcma: add another PCI ID of device with BCM43228
It was found attached to the BCM47081A0 SoC. Log:
bcma: bus0: Found chip with id 43228, rev 0x00 and package 0x08
Signed-off-by: Rafał Miłecki
---
drivers/bcma/host_pci.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index 1e5ac0a..cd9161a 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -275,7 +275,7 @@ static SIMPLE_DEV_PM_OPS(bcma_pm_ops, bcma_host_pci_suspend,
static const struct pci_device_id bcma_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x0576) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4313) },
- { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 43224) },
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 43224) }, /* 0xa8d8 */
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4331) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4353) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4357) },
@@ -285,7 +285,8 @@ static const struct pci_device_id bcma_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a9) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43aa) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4727) },
- { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 43227) }, /* 0xA8DB */
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 43227) }, /* 0xa8db, BCM43217
(sic!) */
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 43228) }, /* 0xa8dc */
{ 0, },
};
MODULE_DEVICE_TABLE(pci, bcma_pci_bridge_tbl);
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RTL8188SU(rtl8192su) & rtl8192sufw-ap.bin
On 14.10.2014 22:22, Dan Williams wrote: > On Tue, 2014-10-14 at 02:59 +0200, poma wrote: >> Realtek RTL8188SU/RTL8191SU/RTL8192SU driver >> https://github.com/chunkeey/rtl8192su >> & >> RTL8188SU >> > > It looks like everything worked correctly here for AP mode, at least > from the NM logs. Is that correct? > > Dan > If you don't hit something like this [ 19.021232] rtlwifi: module verification failed: signature and/or required key missing - tainting kernel [ 19.304159] rtl8192s_common: Chip version 0x3 [ 19.472156] rtl_usb: rx_max_size 9100, rx_urb_num 8, in_ep 3 [ 19.472765] BUG: unable to handle kernel paging request at 8800c8f3a3cc [ 19.473348] IP: [] rtl_usb_probe+0x64e/0x8f0 [rtl_usb] [ 19.473937] PGD 202e067 PUD 12067 PMD c8f65063 PTE 8000c8f3a161 [ 19.474516] Oops: 0003 [#1] SMP [ 19.475083] Modules linked in: rtl8192su(OE+) rtl8192s_common(OE) rtl_usb(OE) rtlwifi(OE) mac80211 cfg80211 rfkill ... [ 19.478188] CPU: 0 PID: 470 Comm: systemd-udevd Tainted: G OE 3.17.0-301.fc21.x86_64 #1 [ 19.479373] task: 8800c9313ae0 ti: 8800c9828000 task.ti: 8800c9828000 [ 19.479962] RIP: 0010:[] [] rtl_usb_probe+0x64e/0x8f0 [rtl_usb] [ 19.480558] RSP: 0018:8800c982bb38 EFLAGS: 00010246 [ 19.481146] RAX: 8800c8f31a80 RBX: 8800c8f31a80 RCX: [ 19.481735] RDX: a05032e0 RSI: a05020c8 RDI: 8800c8f30680 [ 19.482317] RBP: 8800c982bb80 R08: 8800c8f36050 R09: 8800c8f35f18 [ 19.482897] R10: 8800c8f36058 R11: 03f6 R12: 8800c8f31a80 [ 19.483476] R13: 8800c8f30680 R14: 88007f53f800 R15: [ 19.484066] FS: 7fe3393cb880() GS:88012fc0() knlGS: [ 19.484662] CS: 0010 DS: ES: CR0: 8005003b [ 19.485253] CR2: 8800c8f3a3cc CR3: c9ed2000 CR4: 07f0 [ 19.485843] Stack: [ 19.486431] 8800c8f35f18 8800c8f36050 8800c8f36058 [ 19.487032] 88007f53f890 88007f53f800 a050a068 8801297d3c30 [ 19.487633] a050a100 8800c982bb90 a0507b55 8800c982bbd8 [ 19.488233] Call Trace: [ 19.488835] [] rtl8192su_probe+0x15/0x20 [rtl8192su] [ 19.489433] [] usb_probe_interface+0x1cb/0x340 [ 19.490022] [] driver_probe_device+0xa3/0x400 [ 19.490596] [] __driver_attach+0x8b/0x90 [ 19.491171] [] ? __device_attach+0x40/0x40 [ 19.491746] [] bus_for_each_dev+0x73/0xc0 [ 19.492303] [] driver_attach+0x1e/0x20 [ 19.492859] [] bus_add_driver+0x180/0x250 [ 19.493418] [] driver_register+0x64/0xf0 [ 19.493971] [] usb_register_driver+0x82/0x160 [ 19.494523] [] ? 0xa036b000 [ 19.495081] [] rtl92su_driver_init+0x1e/0x1000 [rtl8192su] [ 19.495638] [] do_one_initcall+0xd8/0x210 [ 19.496201] [] ? __vunmap+0xa2/0x100 [ 19.496760] [] load_module+0x1ebf/0x2640 [ 19.497320] [] ? store_uevent+0x70/0x70 [ 19.497877] [] ? kernel_read+0x57/0x90 [ 19.498433] [] SyS_finit_module+0xa6/0xe0 [ 19.498982] [] system_call_fastpath+0x16/0x1b [ 19.499523] Code: af 39 00 00 03 c7 80 b0 08 00 00 64 00 00 00 c6 80 b4 08 00 00 00 c6 80 b5 08 00 00 00 c6 80 b7 08 00 00 07 c6 80 b6 08 00 00 03 80 4c 89 00 00 02 00 00 00 c7 80 50 89 00 00 ff ff ff ff c7 [ 19.500890] RIP [] rtl_usb_probe+0x64e/0x8f0 [rtl_usb] [ 19.501483] RSP [ 19.502064] CR2: 8800c8f3a3cc [ 19.502651] ---[ end trace a2f95d6ce906062b ]--- and if you don't take into account the measured bandwidth is relatively low comparing the actual possible speed, see http://goo.gl/3O3Tz4 (speedof.me/m), you can say it is good to go. >> - lsusb >> >> Bus 002 Device 003: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU >> 802.11n WLAN Adapter >> >> ~~ >> >> - lsusb -t >> >> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M >> ... >> |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtl8192su, >> 480M >> >> ~~~ >> >> - ethtool -i wlp0s4f1u3 >> >> driver: rtl8192su >> ... >> >> ~~~ >> >> - /usr/lib/firmware/rtlwifi/rtl8192sufw.bin >> eq >> >> https://github.com/chunkeey/rtl8192su/raw/master/firmwares/rtl8192sufw-ap.bin >> >> ~ >> >> - iwconfig wlp0s4f1u3 >> >> wlp0s4f1u3 IEEE 802.11bgn Mode:Master Tx-Power=20 dBm >> Retry short limit:7 RTS thr=2347 B Fragment thr:off >> Power Management:off >> >> ~ >> >> - ifconfig wlp0s4f1u3 >> >> wlp0s4f1u3: flags=4163 mtu 1500 >> inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255 >> inet6 fe80::201:2ff:fe03:405 prefixlen 64 scopeid 0x20 >> ether 00:01:02:03:04:05 txqueuelen 1000 (Ethernet) >> RX packets 77 bytes 7421 (7.2 KiB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 126 bytes 27469 (26.8 KiB) >> TX errors 0
[PATCH] ath9k: Reduce max roc duration
From: Sujith Manoharan MCC is currently used in CUS227, an Allplay device. Since audio streaming will be affected with long offchannel periods, reduce the max. offchannel duration to 200ms. Signed-off-by: Sujith Manoharan --- drivers/net/wireless/ath/ath9k/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index 156a944..8857d9c 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -789,7 +789,7 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw) hw->wiphy->n_iface_combinations = ARRAY_SIZE(if_comb_multi); hw->wiphy->max_scan_ssids = 255; hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN; - hw->wiphy->max_remain_on_channel_duration = 1; + hw->wiphy->max_remain_on_channel_duration = 200; hw->chanctx_data_size = sizeof(void *); hw->extra_beacon_tailroom = sizeof(struct ieee80211_p2p_noa_attr) + 9; -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz
On Tue, Oct 14, 2014 at 12:48:07PM +0200, Belisko Marek wrote: > Dear James Cameron, > > On Tue, Oct 14, 2014 at 12:20 PM, James Cameron wrote: > > On Tue, Oct 14, 2014 at 10:25:01AM +0200, Belisko Marek wrote: > >> Hi Amitkumar, > >> > >> On Tue, Oct 14, 2014 at 9:08 AM, Amitkumar Karwar > >> wrote: > >> > Hi Marek, > >> > > >> > > I tried both (slightly modified as we're in 3.9 kernel) but > >> > > issue is still reproducible. My patch against 3.9 sources: > >> > > >> > Thanks a lot for the tests. > >> > > >> > > One thing which is not yet still clear to me why kernel console > >> > > is completely unresponsive when receiving packets in high > >> > > rates. When use iperf (on client) with -b40m it is OK but when > >> > > increase to -b100m then console is completely unresponsive until > >> > > iperf finish. > >> > > >> > Does the system recover when "-b100M" iperf is finished? Can we > >> > run iperf with "-b40M" later? Do you see "dev_alloc_skb failed" > >> > messages in dmesg when console is unresponsive? > >> When we get "dev_alloc_skb failed" then interface is dead (cannot > >> ping ...) so no recovery is possible only system reboot. > > > > This symptom was familiar to me, but on sdio.c, which is very > > different code. > > > > I've had a brief look at usb.c and offer the following comments: > > > > - a list of six data endpoint urb is allocated in mwifiex_usb_rx_init, > > because MWIFIEX_RX_DATA_URB is 6, > > > > - when data endpoint urb is submitted, a new skb is allocated, in > > mwifiex_usb_submit_rx_urb, and this is the only source of > > "dev_alloc_skb failed" message, > > > > - in normal situation, when data endpoint urb is complete, skb is > > either freed or handed up to mwifiex_usb_recv, and the urb is > > resubmitted, which causes a new skb to be allocated. > > > > - if "dev_alloc_skb failed" message appears, one data endpoint urb has > > been lost and is not re-used, > > > > - if six "dev_alloc_skb failed" messages appear, the interface should > > be dead for data receive only. > > > > Amitkumar mentioned this on 9th October; "corresponding URB won't get > > submitted". I think this should be fixed; dev_alloc_skb should be > > harmless failure, please retry. > > > > I don't see why interface is dead with only one "dev_alloc_skb > > failed" message. > Maybe my description wasn't not correct. I see 6 "dev_alloc_skb > failed" messages and then interface is dead > as you wrote. Thanks. That is what I expected. > >> I don't see dev_alloc_skb failed when console is unresponsive. > >> > > >> > > Any other ideas > >> > > what to change to check? Thanks. > >> > > >> > Could you please share dmesg log with dynamic debug enabled (using > >> > attached script) captured when the problem occurs? > >> I tried to capture logs but when enable DYNAMIC_DEBUG I cannot > >> reproduce issue (running test > 30 minutes without allocation > >> failure). > > > > Yes, I've seen similar; turn on debugging, and timing critical bug > > goes away. > > > > Serial console? If so, try turning it off, and logging to dmesg > > buffer only. > When turning off serial console how then I get kernel messages from > dmesg buffer? I use three techniques depending on how usable the system is afterwards: 0. capture kernel messages to disk, using rsyslog or other user space assistance; often there is enough information saved before the system is unresponsive, 1. type dmesg at a console shell prompt, 2. watchdog trigger system reset, and in firmware locate the dmesg buffer structures in memory, and dump them to serial. http://lists.laptop.org/pipermail/devel/2012-January/034253.html -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RTL8188SU(rtl8192su) & rtl8192sufw-ap.bin
On Tue, 2014-10-14 at 02:59 +0200, poma wrote: > Realtek RTL8188SU/RTL8191SU/RTL8192SU driver > https://github.com/chunkeey/rtl8192su > & > RTL8188SU > It looks like everything worked correctly here for AP mode, at least from the NM logs. Is that correct? Dan > - lsusb > > Bus 002 Device 003: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU > 802.11n WLAN Adapter > > ~~ > > - lsusb -t > > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M > ... > |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtl8192su, > 480M > > ~~~ > > - ethtool -i wlp0s4f1u3 > > driver: rtl8192su > ... > > ~~~ > > - /usr/lib/firmware/rtlwifi/rtl8192sufw.bin > eq > > https://github.com/chunkeey/rtl8192su/raw/master/firmwares/rtl8192sufw-ap.bin > > ~ > > - iwconfig wlp0s4f1u3 > > wlp0s4f1u3 IEEE 802.11bgn Mode:Master Tx-Power=20 dBm > Retry short limit:7 RTS thr=2347 B Fragment thr:off > Power Management:off > > ~ > > - ifconfig wlp0s4f1u3 > > wlp0s4f1u3: flags=4163 mtu 1500 > inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255 > inet6 fe80::201:2ff:fe03:405 prefixlen 64 scopeid 0x20 > ether 00:01:02:03:04:05 txqueuelen 1000 (Ethernet) > RX packets 77 bytes 7421 (7.2 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 126 bytes 27469 (26.8 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > > > - iw wlp0s4f1u3 info > > Interface wlp0s4f1u3 > ifindex 5 > wdev 0x10001 > addr 00:01:02:03:04:05 > ssid RTL8188SU(rtl8192su) > type AP > wiphy 1 > channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz > > ~ > > - iw list > > Wiphy phy1 > max # scan SSIDs: 4 > max scan IEs length: 2257 bytes > RTS threshold: 2347 > Coverage class: 0 (up to 0m) > Device supports RSN-IBSS. > Supported Ciphers: > * WEP40 (00-0f-ac:1) > * WEP104 (00-0f-ac:5) > * TKIP (00-0f-ac:2) > * CCMP (00-0f-ac:4) > * CMAC (00-0f-ac:6) > Available Antennas: TX 0 RX 0 > Supported interface modes: >* IBSS >* managed >* AP >* AP/VLAN >* monitor >* mesh point >* P2P-client >* P2P-GO > Band 1: > Capabilities: 0x1862 > HT20/HT40 > Static SM Power Save > RX HT20 SGI > RX HT40 SGI > No RX STBC > Max AMSDU length: 7935 bytes > DSSS/CCK HT40 > Maximum RX AMPDU length 65535 bytes (exponent: 0x003) > Minimum RX AMPDU time spacing: 16 usec (0x07) > HT TX/RX MCS rate indexes supported: 0-7, 32 > Bitrates (non-HT): > * 1.0 Mbps > * 2.0 Mbps > * 5.5 Mbps > * 11.0 Mbps > * 6.0 Mbps > * 9.0 Mbps > * 12.0 Mbps > * 18.0 Mbps > * 24.0 Mbps > * 36.0 Mbps > * 48.0 Mbps > * 54.0 Mbps > Frequencies: > * 2412 MHz [1] (20.0 dBm) > * 2417 MHz [2] (20.0 dBm) > * 2422 MHz [3] (20.0 dBm) > * 2427 MHz [4] (20.0 dBm) > * 2432 MHz [5] (20.0 dBm) > * 2437 MHz [6] (20.0 dBm) > * 2442 MHz [7] (20.0 dBm) > * 2447 MHz [8] (20.0 dBm) > * 2452 MHz [9] (20.0 dBm) > * 2457 MHz [10] (20.0 dBm) > * 2462 MHz [11] (20.0 dBm) > * 2467 MHz [12] (20.0 dBm) > * 2472 MHz [13] (20.0 dBm) > * 2484 MHz [14] (disabled) > Supported commands: >* new_interface >* set_interface >* new_key >* start_ap >* new_station >* new_mpath >* set_mesh_config >* set_bss >* authenticate >* associate >* deauthenticate >* disassociate >* join_ibss >* join_mesh >* set_tx_bitrate_mask >* frame >* frame_wait_cancel >* set_wiphy_netns >* set_channel >* set_wds_peer >* probe_client >
[PATCH] ath9k: do not overwrite AR_PHY_RADAR_1 MSB
Do not overwrite AR_PHY_RADAR_1 most significant byte default value
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 5 -
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index b72d0be..ba3d788 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -1190,7 +1190,7 @@ static void ar5008_hw_set_nf_limits(struct ath_hw *ah)
static void ar5008_hw_set_radar_params(struct ath_hw *ah,
struct ath_hw_radar_conf *conf)
{
- u32 radar_0 = 0, radar_1 = 0;
+ u32 radar_0 = 0, radar_1;
if (!conf) {
REG_CLR_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_ENA);
@@ -1204,6 +1204,9 @@ static void ar5008_hw_set_radar_params(struct ath_hw *ah,
radar_0 |= SM(conf->pulse_rssi, AR_PHY_RADAR_0_PRSSI);
radar_0 |= SM(conf->pulse_inband, AR_PHY_RADAR_0_INBAND);
+ radar_1 = REG_READ(ah, AR_PHY_RADAR_1);
+ radar_1 &= ~(AR_PHY_RADAR_1_MAXLEN | AR_PHY_RADAR_1_RELSTEP_THRESH |
+AR_PHY_RADAR_1_RELPWR_THRESH);
radar_1 |= AR_PHY_RADAR_1_MAX_RRSSI;
radar_1 |= AR_PHY_RADAR_1_BLOCK_CHECK;
radar_1 |= SM(conf->pulse_maxlen, AR_PHY_RADAR_1_MAXLEN);
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 697c4ae..30b2f95 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1348,7 +1348,7 @@ static void ar9003_hw_set_radar_params(struct ath_hw *ah,
struct ath_hw_radar_conf *conf)
{
unsigned int regWrites = 0;
- u32 radar_0 = 0, radar_1 = 0;
+ u32 radar_0 = 0, radar_1;
if (!conf) {
REG_CLR_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_ENA);
@@ -1362,6 +1362,9 @@ static void ar9003_hw_set_radar_params(struct ath_hw *ah,
radar_0 |= SM(conf->pulse_rssi, AR_PHY_RADAR_0_PRSSI);
radar_0 |= SM(conf->pulse_inband, AR_PHY_RADAR_0_INBAND);
+ radar_1 = REG_READ(ah, AR_PHY_RADAR_1);
+ radar_1 &= ~(AR_PHY_RADAR_1_MAXLEN | AR_PHY_RADAR_1_RELSTEP_THRESH |
+AR_PHY_RADAR_1_RELPWR_THRESH);
radar_1 |= AR_PHY_RADAR_1_MAX_RRSSI;
radar_1 |= AR_PHY_RADAR_1_BLOCK_CHECK;
radar_1 |= SM(conf->pulse_maxlen, AR_PHY_RADAR_1_MAXLEN);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iwlwif: traces and microcode sw error on 3.16.5, Intel Corporation Centrino Advanced-N 6205
Hi, On Tue, Oct 14, 2014 at 7:52 PM, Julian Wollrath wrote: > Hi, > > I got several microcode sw errors and traces with 3.16.5. I attached > the log and the output of lspci. In the traces it is mentioned, that > the kernel version is 3.16.5+, but I can assure you, that it is plain > 3.16.5 but somehow a false version got assigned, when I compiled from > git. > > If you need more information, please do not hesitate to ask. > This is clearly a firmware issue - the firmware doesn't reply to a command sent by the driver. Unfortunately, we don't have firmware support for this type of devices. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 linux-next] zd1201: replace kmalloc/memset by kzalloc
Joe Perches writes: > And does this really need to be alloc'd? Yes, it does. It is used as a transfer_buffer in usb_fill_bulk_urb() and must be "suitable for DMA". From include/linux/usb.h: /** * struct urb - USB Request Block .. * @transfer_buffer: This identifies the buffer to (or from) which the I/O * request will be performed unless URB_NO_TRANSFER_DMA_MAP is set * (however, do not leave garbage in transfer_buffer even then). * This buffer must be suitable for DMA; allocate it with * kmalloc() or equivalent. For transfers to "in" endpoints, contents * of this buffer will be modified. This buffer is used for the data * stage of control transfers. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 linux-next] zd1201: replace kmalloc/memset by kzalloc
On Tue, 2014-10-14 at 18:40 +0200, Fabian Frederick wrote:
> Signed-off-by: Fabian Frederick
It might be clearer to use a structure for this 16 byte thing.
There's a comment bit in the code:
/* cmdreq message:
u32 type
u16 cmd
u16 parm0
u16 parm1
u16 parm2
u8 pad[4]
total: 4 + 2 + 2 + 2 + 2 + 4 = 16
*/
It seems thought that this first u32 is actually
a series of u8s.
Maybe:
struct zd1201_cmdreq {
u8 type;
u8 seq;
u8 a;
u8 b;
__le16 cmd;
__le16 parm0;
__le16 parm1;
__le16 parm2;
u8 pad[4];
};
And does this really need to be alloc'd?
maybe
struct zd1202_cmdreq request = {};
etc...
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1 linux-next] zd1201: replace kmalloc/memset by kzalloc
Signed-off-by: Fabian Frederick
---
drivers/net/wireless/zd1201.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
index 6f5c793..4630b26 100644
--- a/drivers/net/wireless/zd1201.c
+++ b/drivers/net/wireless/zd1201.c
@@ -525,7 +525,7 @@ static int zd1201_setconfig(struct zd1201 *zd, int rid,
void *buf, int len, int
zd->rxdatas = 0;
zd->rxlen = 0;
for (seq=0; len > 0; seq++) {
- request = kmalloc(16, gfp_mask);
+ request = kzalloc(16, gfp_mask);
if (!request)
return -ENOMEM;
urb = usb_alloc_urb(0, gfp_mask);
@@ -533,7 +533,6 @@ static int zd1201_setconfig(struct zd1201 *zd, int rid,
void *buf, int len, int
kfree(request);
return -ENOMEM;
}
- memset(request, 0, 16);
reqlen = len>12 ? 12 : len;
request[0] = ZD1201_USB_RESREQ;
request[1] = seq;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wireless-regdb: add regulatory rule for ETSI members on 60GHz band
Hi, related to 623d8438b724afb7c4818cb9b129a552ef2b518b at wireless-regdb. On 12/10/2012, Vladimir Kondratiev wrote: > Purpose is to serve for 802.11ad specification that introduces operation > on the 60GHz band, using bandwidth 2160MHz. > > For the 60GHz band, regulation defined in the "Etsi En 302 567" > http://docsfiles.com/pdf_final_draft_etsi_en_302_567.html > > It defines for the frequency range 57 GHz to 66 GHz, > Max. power level (EIRP) for > indoor only: 40 dBm, and indoor/outdoor: 25 dBm > Also, there is spectral power density limit > 13 dBm/MHz for indoor and -2 dBm/MHz indoor/outdoor I don't know where you did get this information. ETSI EN 302 567 V1.2.1 (2012-01) http://www.etsi.org/deliver/etsi_en/302500_302599/302567/01.02.01_60/en_302567v010201p.pdf doesn't handle in different way indoor/outdoor. And also 57000 - 66000 is allowed. So that: "(57240 - 65880 @ 2160), (40), NO-OUTDOOR" should(must) be replaced by: "(57000 - 66000 @ 2160), (40)" > Only indoor part specified, as kernel can't use multiple > rules per frequency at the moment. Also, standard do not set bandwidth > limitation; > for purpose of 802.11ad this patch specifies bandwidth 2160 MHz, > in this case gross EIRP limit applies. Frequency limits also set accordingly > to the 802.11ad channel allocation. > > This patch apply this to the full ETSI member countries: > [...] > > diff --git a/db.txt b/db.txt > index c00602c..848c985 100644 > --- a/db.txt > +++ b/db.txt > @@ -12,6 +12,10 @@ country 00: > (5735 - 5835 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS > > > +country AD: > +# 60 gHz band channels 1-4, ref: Etsi En 302 567 > +(57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOOR > [...] -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] Allow to set net namespace for wireless device via RTM_LINK
On Thu, Sep 18, 2014 at 11:25:35PM +0200, Johannes Berg wrote: > On Thu, 2014-09-11 at 23:35 +0300, Vadim Kochan wrote: > > Added new netdev_ops callback for setting namespace in specific > > for this device way > > > +++ b/include/linux/netdevice.h > > @@ -997,6 +997,8 @@ typedef u16 (*select_queue_fallback_t)(struct > > net_device *dev, > > * Callback to use for xmit over the accelerated station. This > > * is used in place of ndo_start_xmit on accelerated net > > * devices. > > + * int (*ndo_set_netns)(struct net_device *dev, struct net *net); > > + * Callback to set net namespace in specific way for this device. > > For the record, I don't consider it appropriate to set the net namespace > on one netdev and end up with multiple netdevs switching namespaces ... > > As a result, I don't think this should done. > > johannes > The reason for this was to make possible to change netns for wireless dev via 'ip link' too like for 'iw' util. I just think that changing namespace for netdev should have the generic way. May be you can suggest a better way Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz
Dear James Cameron, On Tue, Oct 14, 2014 at 12:20 PM, James Cameron wrote: > On Tue, Oct 14, 2014 at 10:25:01AM +0200, Belisko Marek wrote: >> Hi Amitkumar, >> >> On Tue, Oct 14, 2014 at 9:08 AM, Amitkumar Karwar >> wrote: >> > Hi Marek, >> > >> > > I tried both (slightly modified as we're in 3.9 kernel) but >> > > issue is still reproducible. My patch against 3.9 sources: >> > >> > Thanks a lot for the tests. >> > >> > > One thing which is not yet still clear to me why kernel console >> > > is completely unresponsive when receiving packets in high >> > > rates. When use iperf (on client) with -b40m it is OK but when >> > > increase to -b100m then console is completely unresponsive until >> > > iperf finish. >> > >> > Does the system recover when "-b100M" iperf is finished? Can we >> > run iperf with "-b40M" later? Do you see "dev_alloc_skb failed" >> > messages in dmesg when console is unresponsive? >> When we get "dev_alloc_skb failed" then interface is dead (cannot >> ping ...) so no recovery is possible only system reboot. > > This symptom was familiar to me, but on sdio.c, which is very > different code. > > I've had a brief look at usb.c and offer the following comments: > > - a list of six data endpoint urb is allocated in mwifiex_usb_rx_init, > because MWIFIEX_RX_DATA_URB is 6, > > - when data endpoint urb is submitted, a new skb is allocated, in > mwifiex_usb_submit_rx_urb, and this is the only source of > "dev_alloc_skb failed" message, > > - in normal situation, when data endpoint urb is complete, skb is > either freed or handed up to mwifiex_usb_recv, and the urb is > resubmitted, which causes a new skb to be allocated. > > - if "dev_alloc_skb failed" message appears, one data endpoint urb has > been lost and is not re-used, > > - if six "dev_alloc_skb failed" messages appear, the interface should > be dead for data receive only. > > Amitkumar mentioned this on 9th October; "corresponding URB won't get > submitted". I think this should be fixed; dev_alloc_skb should be > harmless failure, please retry. > > I don't see why interface is dead with only one "dev_alloc_skb > failed" message. Maybe my description wasn't not correct. I see 6 "dev_alloc_skb failed" messages and then interface is dead as you wrote. > >> I don't see dev_alloc_skb failed when console is unresponsive. >> > >> > > Any other ideas >> > > what to change to check? Thanks. >> > >> > Could you please share dmesg log with dynamic debug enabled (using >> > attached script) captured when the problem occurs? >> I tried to capture logs but when enable DYNAMIC_DEBUG I cannot >> reproduce issue (running test > 30 minutes without allocation >> failure). > > Yes, I've seen similar; turn on debugging, and timing critical bug > goes away. > > Serial console? If so, try turning it off, and logging to dmesg > buffer only. When turning off serial console how then I get kernel messages from dmesg buffer? > > -- > James Cameron > http://quozl.linux.org.au/ BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz
On Tue, Oct 14, 2014 at 10:25:01AM +0200, Belisko Marek wrote: > Hi Amitkumar, > > On Tue, Oct 14, 2014 at 9:08 AM, Amitkumar Karwar wrote: > > Hi Marek, > > > > > I tried both (slightly modified as we're in 3.9 kernel) but > > > issue is still reproducible. My patch against 3.9 sources: > > > > Thanks a lot for the tests. > > > > > One thing which is not yet still clear to me why kernel console > > > is completely unresponsive when receiving packets in high > > > rates. When use iperf (on client) with -b40m it is OK but when > > > increase to -b100m then console is completely unresponsive until > > > iperf finish. > > > > Does the system recover when "-b100M" iperf is finished? Can we > > run iperf with "-b40M" later? Do you see "dev_alloc_skb failed" > > messages in dmesg when console is unresponsive? > When we get "dev_alloc_skb failed" then interface is dead (cannot > ping ...) so no recovery is possible only system reboot. This symptom was familiar to me, but on sdio.c, which is very different code. I've had a brief look at usb.c and offer the following comments: - a list of six data endpoint urb is allocated in mwifiex_usb_rx_init, because MWIFIEX_RX_DATA_URB is 6, - when data endpoint urb is submitted, a new skb is allocated, in mwifiex_usb_submit_rx_urb, and this is the only source of "dev_alloc_skb failed" message, - in normal situation, when data endpoint urb is complete, skb is either freed or handed up to mwifiex_usb_recv, and the urb is resubmitted, which causes a new skb to be allocated. - if "dev_alloc_skb failed" message appears, one data endpoint urb has been lost and is not re-used, - if six "dev_alloc_skb failed" messages appear, the interface should be dead for data receive only. Amitkumar mentioned this on 9th October; "corresponding URB won't get submitted". I think this should be fixed; dev_alloc_skb should be harmless failure, please retry. I don't see why interface is dead with only one "dev_alloc_skb failed" message. > I don't see dev_alloc_skb failed when console is unresponsive. > > > > > Any other ideas > > > what to change to check? Thanks. > > > > Could you please share dmesg log with dynamic debug enabled (using > > attached script) captured when the problem occurs? > I tried to capture logs but when enable DYNAMIC_DEBUG I cannot > reproduce issue (running test > 30 minutes without allocation > failure). Yes, I've seen similar; turn on debugging, and timing critical bug goes away. Serial console? If so, try turning it off, and logging to dmesg buffer only. -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] cfg80211: Specify frame and reason code for NL80211_CMD_DEL_STATION
On 14/10/14 11:21 am, "Johannes Berg" wrote:
>On Fri, 2014-10-10 at 20:55 +0300, Jouni Malinen wrote:
>
>>+ * @reason_code: Reason code for the Disassociation/Deauthentication
>>frame
>> */
>> struct station_del_parameters {
>> const u8 *mac;
>> +u8 subtype;
>> +u16 reason_code;
>
>the reason_code could end up being zero right now, if userspace doesn't
>specify the attribute.
That was more or less by design, but not really fully documented and not
really supposed to be used if the subtype is not provided.
>I think you should probably force a reason code to be given when
>specifying the subtype. And I'm thinking that defaulting to deauth/3
>would be better than leaving it up to the driver(s)?
I guess we could do that in cfg80211. I was trying to follow the current
behavior for this (i.e., not telling the driver what to do if user space
does not require something). As an example, ath6kl uses Deauthentication
with reason code 2. I don't think reason code 3 would be a good default,
though, since it has a special meaning for P2P groups (GO indicates group
is being terminated). That specific use case is one of the main reasons
for making sure that user space can specify that Deauthentication with a
specific reason code is used.
I think I would be fine with cfg80211 default being Deauthentication frame
with reason code 2, so if that is what you would like to see here (rather
than leaving this to the drivers), I can update the patch to behave in
that way.
- Jouni
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] cfg80211: Specify frame and reason code for NL80211_CMD_DEL_STATION
On Fri, 2014-10-10 at 20:55 +0300, Jouni Malinen wrote:
> * @mac: MAC address of the station to remove or NULL to remove all stations
> + * @subtype: Management frame subtype to use for indicating removal
> + * (0 = no guidance on whether to indicate the removal to the station is
> + * provided, 10 = Disassociation, 12 = Deauthentication)
> + * @reason_code: Reason code for the Disassociation/Deauthentication frame
> */
> struct station_del_parameters {
> const u8 *mac;
> + u8 subtype;
> + u16 reason_code;
the reason_code could end up being zero right now, if userspace doesn't
specify the attribute.
> + if (info->attrs[NL80211_ATTR_MGMT_SUBTYPE]) {
> + params.subtype =
> + nla_get_u8(info->attrs[NL80211_ATTR_MGMT_SUBTYPE]);
> + if (params.subtype != IEEE80211_STYPE_DISASSOC >> 4 &&
> + params.subtype != IEEE80211_STYPE_DEAUTH >> 4)
> + return -EINVAL;
> + }
> +
> + if (info->attrs[NL80211_ATTR_REASON_CODE]) {
> + params.reason_code =
> + nla_get_u16(info->attrs[NL80211_ATTR_REASON_CODE]);
> + if (params.reason_code == 0)
> + return -EINVAL; /* 0 is reserved */
> + }
I think you should probably force a reason code to be given when
specifying the subtype. And I'm thinking that defaulting to deauth/3
would be better than leaving it up to the driver(s)?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cfg80211: Convert del_station() callback to use a param struct
On Fri, 2014-10-10 at 20:52 +0300, Jouni Malinen wrote: > This makes it easier to add new parameters for the del_station calls > without having to modify all drivers that use this. Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: fix typo in starting baserate for rts_cts_rate_idx
On Mon, 2014-10-13 at 14:34 +0200, Karl Beldan wrote: > From: Karl Beldan > > It affects non-(V)HT rates and can lead to selecting an rts_cts rate > that is not a basic rate or way superior to the reference rate (ATM > rates[0] used for the 1st attempt of the protected frame data). Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz
Hi Amitkumar, On Tue, Oct 14, 2014 at 9:08 AM, Amitkumar Karwar wrote: > Hi Marek, > >>I tried both (slightly modified as we're in 3.9 kernel) but issue is >>still reproducible. My patch against 3.9 sources: > > Thanks a lot for the tests. > >>One thing which is not yet still clear to me why kernel console is >>completely unresponsive when receiving packets in high rates. When use >>iperf (on client) with -b40m it is OK but when increase to -b100m then >>console is completely unresponsive until iperf finish. > > Does the system recover when "-b100M" iperf is finished? Can we run iperf > with "-b40M" later? > Do you see "dev_alloc_skb failed" messages in dmesg when console is > unresponsive? When we get "dev_alloc_skb failed" then interface is dead (cannot ping ...) so no recovery is possible only system reboot. I don't see dev_alloc_skb failed when console is unresponsive. > >>Any other ideas >>what to change to check? Thanks. > > Could you please share dmesg log with dynamic debug enabled (using attached > script) captured when the problem occurs? I tried to capture logs but when enable DYNAMIC_DEBUG I cannot reproduce issue (running test > 30 minutes without allocation failure). > > Best regards, > Amit BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8723au module
Sir l33tname writes: > Hey, > > > Since r8723au is out I have tried it with every kernel version. > But every time the connection is flaky, it works fine in the beginning > but after ~2 - 5 minutes it stops routing packages get slow, but > it shows all the time connected (on my wlan widget). With 8723au build > from github, none of this problems exist. (Probably because I build > with out Bluetooth?) > > > Output of modinfo > https://gist.github.com/flx/f32d8be6c7759e318088 > > Since I have no idea what you need to debug this, please just > ask for what I should try or what output do you like to see. Hi, Can you provide some information about the wireless access point you are connected to? Speeds, crypto used, etc. Jes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz
Hi Marek, >I tried both (slightly modified as we're in 3.9 kernel) but issue is >still reproducible. My patch against 3.9 sources: Thanks a lot for the tests. >One thing which is not yet still clear to me why kernel console is >completely unresponsive when receiving packets in high rates. When use >iperf (on client) with -b40m it is OK but when increase to -b100m then >console is completely unresponsive until iperf finish. Does the system recover when "-b100M" iperf is finished? Can we run iperf with "-b40M" later? Do you see "dev_alloc_skb failed" messages in dmesg when console is unresponsive? >Any other ideas >what to change to check? Thanks. Could you please share dmesg log with dynamic debug enabled (using attached script) captured when the problem occurs? Best regards, Amit mwifiex_dynamic_debug.sh Description: mwifiex_dynamic_debug.sh
