Re: Throughput regression with `tcp: refine TSO autosizing`
On Tue, 2015-02-10 at 15:19 +0100, Johannes Berg wrote:
On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote:
+ if (msdu-sk) {
+ ewma_add(ar-tx_delay_us,
+ktime_to_ns(ktime_sub(ktime_get(), skb_cb-stamp))
/
+NSEC_PER_USEC);
+
+ ACCESS_ONCE(msdu-sk-sk_tx_completion_delay_cushion) =
+ (ewma_read(ar-tx_delay_us) *
+msdu-sk-sk_pacing_rate) 20;
+ }
To some extent, every wifi driver is going to have this problem. Perhaps
we should do this in mac80211?
I'll provide the TCP patch.
sk-sk_tx_completion_delay_cushion is probably a wrong name, as the
units here are in bytes, since it is really number of bytes in the
network driver that accommodate for tx completions delays.
tx_completion_delay * pacing_rate
sk_tx_completion_cushion maybe.
--
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
NetDev 0.1 online registration deadline Feb 12 (Thursday)
Fellow netheads: NetDev 0.1 starts in 4 days. Registration: == Online registration ends Thursday the 12th at midnight. Registration is possible on site, but may incur a late registration fee. https://onlineregistrations.ca/netdev01/ $100/day, or $350 for 4 days (Cdn dollars). There have been additions made to the travel section of the web site concerning local transit details, weather and clothing. Please check it before travelling so you know what to expect. Travel/hotel/weather/clothing: https://www.netdev01.org/travel Hotel: == The Westin Hotel may still have rooms for Netdev01 available. There are lots of big and small hotels in Ottawa, but they will fill up fast as Winterlude approaches, so book something soon. There may be some possibilities to billet locally, but don't leave it last minute. Make your reservations at: https://www.starwoodmeeting.com/StarGroupsWeb/res?id=1412035802key=1AC9C1F8 Schedule: == The final schedule is out coded with session links. https://www.netdev01.org/schedule Sponsors: = NetDev 0.1 would like to gratefully acknowledge all our sponsors: https://netdev01.org/sponsors Intel http://www.intel.com/ CENGN http://www.cengn.ca/ Google https://www.google.ca Qualcommhttps://www.qualcomm.com/ Verizon http://www.verizon.com/ Cumulus Networkshttp://cumulusnetworks.com/ Mojatatu Networks http://mojatatu.com/ --- THE Technical Conference on Linux Networking, February 14-17, 2015, Ottawa, Canada https://netdev01.org/ Contact:i...@netdev01.info Main site: https://www.netdev01.org/ Travel/hotel/weather/clothing: https://www.netdev01.org/travel RSS feed: https://netdev01.org/atom Follow us on Twitter: @netdev01 https://twitter.com/netdev01 slainte mhath, RGB -- Richard Guy Briggs -- ~\-- ~\ hpv.tricolour.ca www.TriColour.ca -- \___ o \@ @Ride yer bike! Ottawa, ON, CANADA -- Lo___M__\\/\%__\\/\% Vote! -- greenparty.ca_GTVS6#790__(*)__(*)(*)(*)_ -- 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] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode
The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
chance to excute than
ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
always full,
and the do {}while(true) loop will not be break. The kernel get a soft lockup
panic.
[59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
[kworker/0:0:30609]
[59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.858522] Kernel panic - not syncing: softlockup: hung tasks
[59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
[59014.046834] bc20:
de57b950 6113
[59014.059579] bc40: bb32bb32 6113 de57b948 de57b500 dc7bb440
df4bbcd0
[59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0
6133
[59014.085233] [c04c28db] (__irq_svc+0x3b/0x5c) from [c04c25a0]
(_raw_spin_unlock_irqrestore+0xc/0x10)
[59014.100437] [c04c25a0] (_raw_spin_unlock_irqrestore+0xc/0x10) from
[bf9c2089] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
[59014.118267] [bf9c2089] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from
[c0036d23] (tasklet_action+0x3b/0x98)
[59014.134132] [c0036d23] (tasklet_action+0x3b/0x98) from [c0036709]
(__do_softirq+0x99/0x16c)
[59014.147784] [c0036709] (__do_softirq+0x99/0x16c) from [c00369f7]
(irq_exit+0x5b/0x5c)
[59014.160653] [c00369f7] (irq_exit+0x5b/0x5c) from [c000cfc3]
(handle_IRQ+0x37/0x78)
[59014.173124] [c000cfc3] (handle_IRQ+0x37/0x78) from [c00085df]
(omap3_intc_handle_irq+0x5f/0x68)
[59014.187225] [c00085df] (omap3_intc_handle_irq+0x5f/0x68) from
[c04c28db](__irq_svc+0x3b/0x5c)
This bug can be see with low performance board, such as uniprocessor beagle
bone board. Add some debug message in the ath9k_hif_usb_rx_cb
function may trigger this bug quickly.
Signed-off-by: Yuwei Zheng yuweizh...@139.com
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 78 +++---
drivers/net/wireless/ath/ath9k/hif_usb.h | 13 +
drivers/net/wireless/ath/ath9k/htc.h | 19 +++
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 53 +
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 58 +++
5 files changed, 214 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 8e7153b..2e73e19 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
struct hif_device_usb *hif_dev =
usb_get_intfdata(usb_ifnum_to_if(urb-dev, 0));
int ret;
+ int delay;
if (!skb)
return;
@@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
default:
goto resubmit;
}
-
if (likely(urb-actual_length != 0)) {
skb_put(skb, urb-actual_length);
ath9k_hif_usb_rx_stream(hif_dev, skb);
@@ -667,12 +667,23 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
resubmit:
skb_reset_tail_pointer(skb);
skb_trim(skb, 0);
-
- usb_anchor_urb(urb, hif_dev-rx_submitted);
- ret = usb_submit_urb(urb, GFP_ATOMIC);
- if (ret) {
- usb_unanchor_urb(urb);
- goto free;
+ spin_lock(hif_dev-aurfc_lock);
+ /* submit the urb more slowly for flow control */
+ if (atomic_read(hif_dev-aurfc_submit_delay) 0
+ hif_dev-aurfc_active == 1) {
+ usb_anchor_urb(urb, hif_dev-rx_delayed_submitted);
+ delay = atomic_read(hif_dev-aurfc_submit_delay);
+ schedule_delayed_work(hif_dev-aurfc_delayed_work,
+ msecs_to_jiffies(delay));
+ spin_unlock(hif_dev-aurfc_lock);
+ } else {
+ spin_unlock(hif_dev-aurfc_lock);
+ usb_anchor_urb(urb, hif_dev-rx_submitted);
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret) {
+ usb_unanchor_urb(urb);
+ goto free;
+ }
}
return;
@@ -818,9 +829,53 @@ err:
return -ENOMEM;
}
+static void aurfc_submit_handler(struct work_struct *work)
+{
+ struct hif_device_usb *hif_dev =
+ container_of(work,
+struct hif_device_usb,
+aurfc_delayed_work.work);
+ struct urb *urb = NULL;
+ struct sk_buff *skb = NULL;
+ int ret;
+ int loop_times = 0;
+
+ AURFC_STAT_INC(aurfc_called);
+ while (true) {
+ loop_times++;
+ if (loop_times MAX_RX_URB_NUM)
+ atomic_add(AURFC_STEP,
+
[PATCH] rtlwifi: Modify some USB de-initialize code.
Delete SET_USB_STOP macro and rtl_usb_deinit because
those are called twice in USB de-initialize routine.
Add some de-initialize workqueue function in USB disconnect routine.
Signed-off-by: Taehee Yoo ap420...@gmail.com
---
drivers/net/wireless/rtlwifi/usb.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/usb.c
b/drivers/net/wireless/rtlwifi/usb.c
index 46ee956..f0188c8 100644
--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -701,12 +701,18 @@ free:
static void _rtl_usb_cleanup_rx(struct ieee80211_hw *hw)
{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
struct urb *urb;
usb_kill_anchored_urbs(rtlusb-rx_submitted);
tasklet_kill(rtlusb-rx_work_tasklet);
+ cancel_work_sync(rtlpriv-works.lps_change_work);
+
+ flush_workqueue(rtlpriv-works.rtl_wq);
+ destroy_workqueue(rtlpriv-works.rtl_wq);
+
skb_queue_purge(rtlusb-rx_queue);
while ((urb = usb_get_from_anchor(rtlusb-rx_cleanup_urbs))) {
@@ -794,8 +800,6 @@ static void rtl_usb_cleanup(struct ieee80211_hw *hw)
struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
struct ieee80211_tx_info *txinfo;
- SET_USB_STOP(rtlusb);
-
/* clean up rx stuff. */
_rtl_usb_cleanup_rx(hw);
@@ -834,7 +838,6 @@ static void rtl_usb_stop(struct ieee80211_hw *hw)
cancel_work_sync(rtlpriv-works.fill_h2c_cmd);
/* Enable software */
SET_USB_STOP(rtlusb);
- rtl_usb_deinit(hw);
rtlpriv-cfg-ops-hw_disable(hw);
}
@@ -1147,9 +1150,9 @@ void rtl_usb_disconnect(struct usb_interface *intf)
if (unlikely(!rtlpriv))
return;
-
/* just in case driver is removed before firmware callback */
wait_for_completion(rtlpriv-firmware_loading_complete);
+ clear_bit(RTL_STATUS_INTERFACE_START, rtlpriv-status);
/*ieee80211_unregister_hw will call ops_stop */
if (rtlmac-mac80211_registered == 1) {
ieee80211_unregister_hw(hw);
--
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: brcmfmac + AP6120 (brcm43362) doesn't connect to WPA2 AP (unprotected ok)
On 02/10/15 02:37, Steeve Morin wrote: I've managed to get a lease via udhcpc, over and over again, but as soon as a scan operation comes along, I am now unable to get a lease. If you can provide a kernel log running into this situation I might get a clue about what is happening. Regards, Arend On 10 February 2015 at 01:34, Steeve Morinsteeve.mo...@gmail.com wrote: Also, using udhcpc fails to retrieve an IP with a rather strange error udhcpc (v1.22.1) started Sending discover... Sending select for 192.168.1.89... Sending select for 192.168.1.89... Sending select for 192.168.1.89... Sending discover... Sending discover... Which leads me to believe this might be due to data being lost somewhere... However, the rare times I managed to make it connect, SSH was functionning normally. Let me know if you need more log. Thanks On 10 February 2015 at 00:06, Steeve Morinsteeve.mo...@gmail.com wrote: The weird thing is that wpa_supplicant apparently manages to associate with the AP (but i'm not really sure about that) [1] [1] https://gist.github.com/steeve/10a9a643476cea99abf4#file-005-wpa-supplicant-conf On 9 February 2015 at 23:17, Steeve Morinsteeve.mo...@gmail.com wrote: Thanks for answering. I'm using connmanctl [1] The funny thing is trying to make this gist, I tried and it connected succesfully Could it be a race somewhere? [1] https://gist.github.com/steeve/10a9a643476cea99abf4#file-004-connmanctl On 9 February 2015 at 23:00, Arend van Sprielar...@broadcom.com wrote: On 02/09/15 18:57, Steeve Morin wrote: Hi linux-wireless, I'm running brcmfmac from backports-3.19-rc1-1 on linux 3.10. running on an arm Amlogic S805 (cortex-a5, arm7) board (CX-S859). I had to apply multiple custom patches [1]: - Make sure the wifi chip is on via custom GPIO [1] - Remove a problematic piece of code related to power manager (will look into it later) [1] - Mix the mmc-max_blk_count on the host (would cause a BUG_ON assertion later on) [2] [3] After that, I am able to modprobe brcmfmac see wlan0. The interface correctly scans for wifi aps, and I can connect to unprotected ones. It fails, however, to connect to WPA/WPA2 protected aps. I have attached a debug log obtained with debug=0xff [4] I don't see any errors in it though... Would anyone of you guys have any idea why ? In the log I don't see any connect attempt. Only seeing a scan completing. So how do you try to connect? Regards, Arend Thanks a lot, [1] https://gist.github.com/steeve/10a9a643476cea99abf4#file-backports-power-on-wifi-sdio-patch [2] https://gist.github.com/steeve/10a9a643476cea99abf4#file-fix-block-size-patch [3] https://github.com/codesnake/linux-amlogic/blob/master/drivers/amlogic/mmc/aml_sdio.c#L317 [4] https://gist.github.com/steeve/10a9a643476cea99abf4#file-003-dmesg-log -- Steeve Morin twitter.com/steeve github.com/steeve linkd.in/smorin -- Steeve Morin twitter.com/steeve github.com/steeve linkd.in/smorin -- Steeve Morin twitter.com/steeve github.com/steeve linkd.in/smorin -- 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: [RFT] ath10k: restart fw on tx-credit timeout
On 02/09/2015 10:09 PM, Michal Kazior wrote: On 9 February 2015 at 17:03, Ben Greear gree...@candelatech.com wrote: On 02/08/2015 10:24 PM, Michal Kazior wrote: On 6 February 2015 at 17:15, Ben Greear gree...@candelatech.com wrote: [...] At least in my tests, I could continue to receive network traffic while WMI was blocked. Yeah. Traffic works with the tx-credit starvation as well but what good is this if you have inconsistent driver-firmware state after failing to send a few commands? I just mention it because someone debugging the system might wonder why the firmware is 'locked up' while it is still passing traffic. I might as well include this info in the commit log. If it is just powersave issue, could you force (overriding wmi tx-credits limit) a flush at the 1 second mark and hope it recovers by 3 second timeout? Well, there's a couple of problems with that. 1) you suggest to call wmi_flush() which calls wmi_cmd_send() *while* in wmi_cmd_send(), 2) you're out of credits, how do you intend to submit a frame, 3) yes, you can force it, but that's super ugly, 4) and this still doesn't guarantee you'll get your tx-credit due to firmware quirkiness. If you do force the wmi send, ignoring credits, and even if you are running stock firmware with wmi credits replenishment issues, then you at least have a chance of recovering. (Upstream firmware requires lots of WMI messages to flush, I think..like you can only flush per peer or something like that, so maybe there is no realistic way to flush with small number of WMI messages.) I've hacked CT firmware to do a flush of all vdevs itself when it detects WMI hang. I don't have a good test bed to reproduce the problem reliably, but I should know after a few days if the flush works at all. If not, then it's a moot point anyway. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.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
[PATCH] rtlwifi: ratelimit skb allocation failure message
From: Colin Ian King colin.k...@canonical.com
when running low on memory I noticed rtlwifi was producing a large
quantity of repeated skb allocation failures messages. This should
be ratelimited to reduce the noise.
Signed-off-by: Colin Ian King colin.k...@canonical.com
---
drivers/net/wireless/rtlwifi/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c
b/drivers/net/wireless/rtlwifi/pci.c
index c70efb9..ca0fd50 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -817,7 +817,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
/* get a new skb - if fail, old one will be reused */
new_skb = dev_alloc_skb(rtlpci-rxbuffersize);
if (unlikely(!new_skb)) {
- pr_err(Allocation of new skb failed in %s\n,
+ pr_err_ratelimited(Allocation of new skb failed in
%s\n,
__func__);
goto no_new;
}
--
2.1.4
--
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] ath10k: fix wmm params per vdev
On 6 February 2015 at 14:41, Marek Puzyniak marek.puzyn...@tieto.com wrote: During wmm tests changing wmm parameters did not change anything. This was because of mismatch in WMM params per vdev command. WMM params per vdev uses different command structure than wmm params per pdev command. Also txop for per vdev settings has the same units as provided by mac80211. Patch concerns qca6174. Signed-off-by: Marek Puzyniak marek.puzyn...@tieto.com Kalle, Please do not merge this patch yet. I need to clarify some side effects. I will inform you about next steps. Thanks, Marek -- 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: NFC: st21nfca: Add HCI transaction event support
Hello Christophe Ricard,
The patch 26fc6c7f02cb: NFC: st21nfca: Add HCI transaction event
support from Feb 1, 2015, leads to the following static checker
warning:
drivers/nfc/st21nfca/st21nfca_se.c:321
st21nfca_connectivity_event_received()
error: 'skb-data[1]' from user is not capped properly
drivers/nfc/st21nfca/st21nfca_se.c
300 int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8
host,
301 u8 event, struct sk_buff *skb)
302 {
303 int r = 0;
304 struct device *dev = hdev-ndev-dev;
305 struct nfc_evt_transaction *transaction;
306
307 pr_debug(connectivity gate event: %x\n, event);
308
309 switch (event) {
310 case ST21NFCA_EVT_CONNECTIVITY:
311 break;
312 case ST21NFCA_EVT_TRANSACTION:
313 if (skb-len NFC_MIN_AID_LENGTH + 2
314 skb-data[0] != NFC_EVT_TRANSACTION_AID_TAG)
315 return -EPROTO;
Here we don't trust skb-data[0].
316
317 transaction = (struct nfc_evt_transaction
*)devm_kzalloc(dev,
318 skb-len - 2,
GFP_KERNEL);
319
320 transaction-aid_len = skb-data[1];
321 memcpy(transaction-aid, skb-data[2], skb-data[1]);
But here we trust skb-data[1].
NFC code is hard to analyze because sometimes skb-data[] comes from the
firmware and holds trusted values. But sometimes it comes from the
network and can overflow. Smatch marks it all as untrusted so it causes
a lot of false postives.
Some of them have comments like:
net/nfc/hci/core.c:218 nfc_hci_cmd_received()
error: buffer overflow 'hdev-pipes' 127 = 255
But this one doesn't have a comment so it's hard for me as an outsider
to say if this is a bug or not.
322
regards,
dan carpenter
--
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: Ralink 6570 / Mediatek MT7601STA (was Re: Addition of a wifi kernel module to the linux source tree)
Hello everone! A few months earlier I had requested addition of the MT7601 WiFi dongle module into the kernel. I was told that the needful would be done in the rt2x00 driver. Could you guys update me with the status? Thanks a lot! -Parth Sane On 4 December 2014 at 20:06, Stanislaw Gruszka sgrus...@redhat.com wrote: On Thu, Dec 04, 2014 at 09:49:53AM +0100, Oleksij Rempel wrote: So far i know, Felix is working on abgn+ac (MT7662 and MT7612) devices. MT7601STA is (a)bgn. Are there similar regs? All Mediatek/Ralink devices I know have the same MAC registers, but different BBP and RF registers. In mt7601 code i see parts like if (IS_RT3290(pAd) || IS_RT65XX(pAd) || IS_MT7601(pAd)). RT3290 is supported by rt2x00. Hence looks that support for this devices should be added to rt2x00. Stanislaw -- 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: Throughput regression with `tcp: refine TSO autosizing`
On 9 February 2015 at 16:11, Eric Dumazet eric.duma...@gmail.com wrote:
On Mon, 2015-02-09 at 14:47 +0100, Michal Kazior wrote:
[...]
This is not what I suggested.
If you test this on any other network device, you'll have
sk-sk_tx_completion_delay_us == 0
amount = 0 * (sk-sk_pacing_rate 10); -- 0
limit = max(2 * skb-truesize, amount 10); -- 2 * skb-truesize
You're right. Sorry for mixing up.
So non TSO/GSO NIC will not be able to queue more than 2 MSS (one MSS
per skb)
Then if you store only the last tx completion, you have the possibility
of having a last packet of a train (say a retransmit) to make it very
low.
Ideally the formula would be in TCP something very fast to compute :
amount = (sk-sk_pacing_rate 10) + sk-tx_completion_delay_cushion;
limit = max(2 * skb-truesize, amount);
limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
So a 'problematic' driver would have to do the math (64 bit maths) like
this :
sk-tx_completion_delay_cushion = ewma_tx_delay * sk-sk_pacing_rate;
Hmm. So I've done like you suggested (hopefully I didn't mix anything
up this time around).
I now get pre-regression performance, ~250mbps on 1 flow, 600mbps on 5
flows (vs 250mbps whatever number of flows).
Michał
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 367e896..a29111c 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/firmware.h
#include linux/of.h
+#include linux/average.h
#include core.h
#include mac.h
@@ -1423,6 +1424,7 @@ struct ath10k *ath10k_core_create(size_t
priv_size, struct device *dev,
init_dummy_netdev(ar-napi_dev);
ieee80211_napi_add(ar-hw, ar-napi, ar-napi_dev,
ath10k_core_napi_dummy_poll, 64);
+ ewma_init(ar-tx_delay_us, 16384, 8);
ret = ath10k_debug_create(ar);
if (ret)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 3be3a59..34f6d78 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -24,6 +24,7 @@
#include linux/pci.h
#include linux/uuid.h
#include linux/time.h
+#include linux/average.h
#include htt.h
#include htc.h
@@ -82,6 +83,7 @@ struct ath10k_skb_cb {
dma_addr_t paddr;
u8 eid;
u8 vdev_id;
+ ktime_t stamp;
struct {
u8 tid;
@@ -625,6 +627,7 @@ struct ath10k {
struct net_device napi_dev;
struct napi_struct napi;
+ struct ewma tx_delay_us;
#ifdef CONFIG_ATH10K_DEBUGFS
struct ath10k_debug debug;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 15e47f4..5efb2a7 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2620,6 +2620,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
if (info-flags IEEE80211_TX_CTL_NO_CCK_RATE)
ath10k_dbg(ar, ATH10K_DBG_MAC,
IEEE80211_TX_CTL_NO_CCK_RATE\n);
+ ATH10K_SKB_CB(skb)-stamp = ktime_get();
ATH10K_SKB_CB(skb)-htt.is_offchan = false;
ATH10K_SKB_CB(skb)-htt.tid = ath10k_tx_h_get_tid(hdr);
ATH10K_SKB_CB(skb)-vdev_id = ath10k_tx_h_get_vdev_id(ar, vif);
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c
b/drivers/net/wireless/ath/ath10k/txrx.c
index 3f00cec..0f5f0f2 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -15,6 +15,8 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include net/sock.h
+#include linux/average.h
#include core.h
#include txrx.h
#include htt.h
@@ -82,6 +84,16 @@ void ath10k_txrx_tx_unref(struct ath10k_htt *htt,
ath10k_report_offchan_tx(htt-ar, msdu);
+ if (msdu-sk) {
+ ewma_add(ar-tx_delay_us,
+ktime_to_ns(ktime_sub(ktime_get(), skb_cb-stamp)) /
+NSEC_PER_USEC);
+
+ ACCESS_ONCE(msdu-sk-sk_tx_completion_delay_cushion) =
+ (ewma_read(ar-tx_delay_us) *
+msdu-sk-sk_pacing_rate) 20;
+ }
+
info = IEEE80211_SKB_CB(msdu);
memset(info-status, 0, sizeof(info-status));
trace_ath10k_txrx_tx_unref(ar, tx_done-msdu_id);
diff --git a/include/net/sock.h b/include/net/sock.h
index 2210fec..6772543 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -391,6 +391,7 @@ struct sock {
gfp_t sk_allocation;
u32 sk_pacing_rate; /* bytes per second */
u32 sk_max_pacing_rate;
+ u32 sk_tx_completion_delay_cushion;
netdev_features_t sk_route_caps;
netdev_features_t sk_route_nocaps;
int sk_gso_type;
diff --git a/net/ipv4/tcp_output.c
Re: [PATCH] ath10k: fix wmm params per vdev
Marek Puzyniak marek.puzyn...@tieto.com writes: On 6 February 2015 at 14:41, Marek Puzyniak marek.puzyn...@tieto.com wrote: During wmm tests changing wmm parameters did not change anything. This was because of mismatch in WMM params per vdev command. WMM params per vdev uses different command structure than wmm params per pdev command. Also txop for per vdev settings has the same units as provided by mac80211. Patch concerns qca6174. Signed-off-by: Marek Puzyniak marek.puzyn...@tieto.com Kalle, Please do not merge this patch yet. I need to clarify some side effects. I will inform you about next steps. Ok, I have dropped the patch. Please resend if it's ok to apply. -- Kalle Valo -- 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 v2] ath10k: fix wmm params per vdev
During wmm tests changing wmm parameters did not change anything.
This was because of mismatch in WMM params per vdev command.
WMM params per vdev uses different command structure than wmm params
per pdev command.
Patch concerns qca6174.
Signed-off-by: Marek Puzyniak marek.puzyn...@tieto.com
---
v2:
* removed txop units modification
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 15 +--
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 6 ++
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 71614ba..bdb3673 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1604,14 +1604,12 @@ ath10k_wmi_tlv_op_gen_vdev_wmm_conf(struct ath10k *ar,
u32 vdev_id,
const struct wmi_wmm_params_all_arg *arg)
{
struct wmi_tlv_vdev_set_wmm_cmd *cmd;
- struct wmi_wmm_params *wmm;
struct wmi_tlv *tlv;
struct sk_buff *skb;
size_t len;
void *ptr;
- len = (sizeof(*tlv) + sizeof(*cmd)) +
- (4 * (sizeof(*tlv) + sizeof(*wmm)));
+ len = sizeof(*tlv) + sizeof(*cmd);
skb = ath10k_wmi_alloc_skb(ar, len);
if (!skb)
return ERR_PTR(-ENOMEM);
@@ -1623,13 +1621,10 @@ ath10k_wmi_tlv_op_gen_vdev_wmm_conf(struct ath10k *ar,
u32 vdev_id,
cmd = (void *)tlv-value;
cmd-vdev_id = __cpu_to_le32(vdev_id);
- ptr += sizeof(*tlv);
- ptr += sizeof(*cmd);
-
- ptr = ath10k_wmi_tlv_put_wmm(ptr, arg-ac_be);
- ptr = ath10k_wmi_tlv_put_wmm(ptr, arg-ac_bk);
- ptr = ath10k_wmi_tlv_put_wmm(ptr, arg-ac_vi);
- ptr = ath10k_wmi_tlv_put_wmm(ptr, arg-ac_vo);
+ ath10k_wmi_set_wmm_param(cmd-vdev_wmm_params[0].params, arg-ac_be);
+ ath10k_wmi_set_wmm_param(cmd-vdev_wmm_params[1].params, arg-ac_bk);
+ ath10k_wmi_set_wmm_param(cmd-vdev_wmm_params[2].params, arg-ac_vi);
+ ath10k_wmi_set_wmm_param(cmd-vdev_wmm_params[3].params, arg-ac_vo);
ath10k_dbg(ar, ATH10K_DBG_WMI, wmi tlv vdev wmm conf\n);
return skb;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index de68fe7..c54de47 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1302,8 +1302,14 @@ struct wmi_tlv_pdev_set_wmm_cmd {
__le32 dg_type; /* no idea.. */
} __packed;
+struct wmi_tlv_vdev_wmm_params {
+ __le32 dummy;
+ struct wmi_wmm_params params;
+} __packed;
+
struct wmi_tlv_vdev_set_wmm_cmd {
__le32 vdev_id;
+ struct wmi_tlv_vdev_wmm_params vdev_wmm_params[4];
} __packed;
struct wmi_tlv_phyerr_ev {
--
2.1.4
--
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: pull-request: wireless-drivers-next 2015-02-07
David Miller da...@davemloft.net writes:
From: Kalle Valo kv...@codeaurora.org
Date: Sat, 07 Feb 2015 13:40:51 +0200
There's a small conflict in drivers/net/wireless/rtlwifi/pci.c, the fix
is to leave the two labels like this:
schedule_work(rtlpriv-works.lps_change_work);
}
end:
skb = new_skb;
no_new:
if (rtlpriv-use_new_trx_flow) {
That can't be the correct resolution:
drivers/net/wireless/rtlwifi/pci.c: In function ‘_rtl_pci_rx_interrupt’:
drivers/net/wireless/rtlwifi/pci.c:934:1: warning: label ‘end’ defined but
not used [-Wunused-label]
So I've removed that label in the merge commit.
Sorry about that, but great that you catched my mistake.
--
Kalle Valo
--
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] rtlwifi: ratelimit skb allocation failure message
On 10/02/15 13:48, Kalle Valo wrote:
Eric Dumazet eric.duma...@gmail.com writes:
On Tue, 2015-02-10 at 08:54 +, Colin King wrote:
From: Colin Ian King colin.k...@canonical.com
when running low on memory I noticed rtlwifi was producing a large
quantity of repeated skb allocation failures messages. This should
be ratelimited to reduce the noise.
Signed-off-by: Colin Ian King colin.k...@canonical.com
---
drivers/net/wireless/rtlwifi/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c
b/drivers/net/wireless/rtlwifi/pci.c
index c70efb9..ca0fd50 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -817,7 +817,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw
*hw)
/* get a new skb - if fail, old one will be reused */
new_skb = dev_alloc_skb(rtlpci-rxbuffersize);
if (unlikely(!new_skb)) {
- pr_err(Allocation of new skb failed in %s\n,
+ pr_err_ratelimited(Allocation of new skb failed in
%s\n,
__func__);
Or even better, remove the message.
There's actually a pending patch for that, I'll send it to Dave ASAP:
https://patchwork.kernel.org/patch/5671121/
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: brcmfmac + AP6120 (brcm43362) doesn't connect to WPA2 AP (unprotected ok)
On 02/10/15 21:03, Steeve Morin wrote: Okay I've managed to fix it, it was due to a faulty mmc setting in the kernel driver from the chip maker. Basically it was setting a wrong max_blk_count and max_blk_size for the MMC host. Basically, max_blk_count was set wrong, causing a BUG_ON assertion, and when patched, because the max_blk_size was wrong, it was overflowing the MMC buffer (this is 128k according to the device tree). Thank you for your time, actually talking about it and laying it out made me look in the right direction. Glad to help. Did not expect I would get off that easy ;-) Regards, Arend Here is the fix. From 6c92e578748e039dfcfd8e737efdead6cd3e7568 Mon Sep 17 00:00:00 2001 From: Steeve Morinsteeve.mo...@gmail.com Date: Mon, 9 Feb 2015 16:25:49 +0100 Subject: [PATCH 4/4] Properly set max_blk_count and max_blk_size for the host mmc Signed-off-by: Steeve Morinsteeve.mo...@gmail.com --- drivers/amlogic/mmc/aml_sdio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/amlogic/mmc/aml_sdio.c b/drivers/amlogic/mmc/aml_sdio.c index 680b95a..8b42f0e 100755 --- a/drivers/amlogic/mmc/aml_sdio.c +++ b/drivers/amlogic/mmc/aml_sdio.c @@ -1322,10 +1322,10 @@ static int aml_sdio_probe(struct platform_device *pdev) mmc-alldev_claim =aml_sdio_claim; mmc-ios.clock = 40; mmc-ios.bus_width = MMC_BUS_WIDTH_1; -mmc-max_blk_count = 4095; -mmc-max_blk_size = 4095; +mmc-max_blk_count = 256; mmc-max_req_size = pdata-max_req_size; mmc-max_seg_size = mmc-max_req_size; +mmc-max_blk_size = mmc-max_req_size / mmc-max_blk_count; mmc-max_segs = 1024; mmc-ocr_avail = pdata-ocr_avail; mmc-ocr = pdata-ocr_avail; -- 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: brcmfmac + AP6120 (brcm43362) doesn't connect to WPA2 AP (unprotected ok)
Okay I've managed to fix it, it was due to a faulty mmc setting in the kernel driver from the chip maker. Basically it was setting a wrong max_blk_count and max_blk_size for the MMC host. Basically, max_blk_count was set wrong, causing a BUG_ON assertion, and when patched, because the max_blk_size was wrong, it was overflowing the MMC buffer (this is 128k according to the device tree). Thank you for your time, actually talking about it and laying it out made me look in the right direction. Here is the fix. From 6c92e578748e039dfcfd8e737efdead6cd3e7568 Mon Sep 17 00:00:00 2001 From: Steeve Morin steeve.mo...@gmail.com Date: Mon, 9 Feb 2015 16:25:49 +0100 Subject: [PATCH 4/4] Properly set max_blk_count and max_blk_size for the host mmc Signed-off-by: Steeve Morin steeve.mo...@gmail.com --- drivers/amlogic/mmc/aml_sdio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/amlogic/mmc/aml_sdio.c b/drivers/amlogic/mmc/aml_sdio.c index 680b95a..8b42f0e 100755 --- a/drivers/amlogic/mmc/aml_sdio.c +++ b/drivers/amlogic/mmc/aml_sdio.c @@ -1322,10 +1322,10 @@ static int aml_sdio_probe(struct platform_device *pdev) mmc-alldev_claim = aml_sdio_claim; mmc-ios.clock = 40; mmc-ios.bus_width = MMC_BUS_WIDTH_1; -mmc-max_blk_count = 4095; -mmc-max_blk_size = 4095; +mmc-max_blk_count = 256; mmc-max_req_size = pdata-max_req_size; mmc-max_seg_size = mmc-max_req_size; +mmc-max_blk_size = mmc-max_req_size / mmc-max_blk_count; mmc-max_segs = 1024; mmc-ocr_avail = pdata-ocr_avail; mmc-ocr = pdata-ocr_avail; -- 2.2.1 On 10 February 2015 at 18:31, Arend van Spriel ar...@broadcom.com wrote: On 02/10/15 02:37, Steeve Morin wrote: I've managed to get a lease via udhcpc, over and over again, but as soon as a scan operation comes along, I am now unable to get a lease. If you can provide a kernel log running into this situation I might get a clue about what is happening. Regards, Arend On 10 February 2015 at 01:34, Steeve Morinsteeve.mo...@gmail.com wrote: Also, using udhcpc fails to retrieve an IP with a rather strange error udhcpc (v1.22.1) started Sending discover... Sending select for 192.168.1.89... Sending select for 192.168.1.89... Sending select for 192.168.1.89... Sending discover... Sending discover... Which leads me to believe this might be due to data being lost somewhere... However, the rare times I managed to make it connect, SSH was functionning normally. Let me know if you need more log. Thanks On 10 February 2015 at 00:06, Steeve Morinsteeve.mo...@gmail.com wrote: The weird thing is that wpa_supplicant apparently manages to associate with the AP (but i'm not really sure about that) [1] [1] https://gist.github.com/steeve/10a9a643476cea99abf4#file-005-wpa-supplicant-conf On 9 February 2015 at 23:17, Steeve Morinsteeve.mo...@gmail.com wrote: Thanks for answering. I'm using connmanctl [1] The funny thing is trying to make this gist, I tried and it connected succesfully Could it be a race somewhere? [1] https://gist.github.com/steeve/10a9a643476cea99abf4#file-004-connmanctl On 9 February 2015 at 23:00, Arend van Sprielar...@broadcom.com wrote: On 02/09/15 18:57, Steeve Morin wrote: Hi linux-wireless, I'm running brcmfmac from backports-3.19-rc1-1 on linux 3.10. running on an arm Amlogic S805 (cortex-a5, arm7) board (CX-S859). I had to apply multiple custom patches [1]: - Make sure the wifi chip is on via custom GPIO [1] - Remove a problematic piece of code related to power manager (will look into it later) [1] - Mix the mmc-max_blk_count on the host (would cause a BUG_ON assertion later on) [2] [3] After that, I am able to modprobe brcmfmac see wlan0. The interface correctly scans for wifi aps, and I can connect to unprotected ones. It fails, however, to connect to WPA/WPA2 protected aps. I have attached a debug log obtained with debug=0xff [4] I don't see any errors in it though... Would anyone of you guys have any idea why ? In the log I don't see any connect attempt. Only seeing a scan completing. So how do you try to connect? Regards, Arend Thanks a lot, [1] https://gist.github.com/steeve/10a9a643476cea99abf4#file-backports-power-on-wifi-sdio-patch [2] https://gist.github.com/steeve/10a9a643476cea99abf4#file-fix-block-size-patch [3] https://github.com/codesnake/linux-amlogic/blob/master/drivers/amlogic/mmc/aml_sdio.c#L317 [4] https://gist.github.com/steeve/10a9a643476cea99abf4#file-003-dmesg-log -- Steeve Morin twitter.com/steeve github.com/steeve linkd.in/smorin -- Steeve Morin twitter.com/steeve github.com/steeve linkd.in/smorin -- Steeve Morin twitter.com/steeve github.com/steeve linkd.in/smorin -- Steeve Morin twitter.com/steeve github.com/steeve linkd.in/smorin -- To unsubscribe from this list: send the line unsubscribe
Re: Throughput regression with `tcp: refine TSO autosizing`
On Tue, 2015-02-10 at 04:54 -0800, Eric Dumazet wrote: Hi Michal This is almost it ;) As I said you must do this using u64 arithmetics, we still support 32bit kernels. Also, 20 instead of / 100 introduces a 5% error, I would use a plain divide, as the compiler will use a reciprocal divide (ie : a multiply) We use 10 instead of /1000 because a 2.4 % error is probably okay. ewma_add(ar-tx_delay_us, ktime_to_ns(ktime_sub(ktime_get(), skb_cb-stamp)) / NSEC_PER_USEC); btw I suspect this wont compile on 32 bit kernel You need to use do_div() as well : u64 val = ktime_to_ns(ktime_sub(ktime_get(), skb_cb-stamp)); do_div(val, NSEC_PER_USEC); ewma_add(ar-tx_delay_us, val); -- 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] rtlwifi: ratelimit skb allocation failure message
On Tue, 2015-02-10 at 08:54 +, Colin King wrote:
From: Colin Ian King colin.k...@canonical.com
when running low on memory I noticed rtlwifi was producing a large
quantity of repeated skb allocation failures messages. This should
be ratelimited to reduce the noise.
Signed-off-by: Colin Ian King colin.k...@canonical.com
---
drivers/net/wireless/rtlwifi/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c
b/drivers/net/wireless/rtlwifi/pci.c
index c70efb9..ca0fd50 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -817,7 +817,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
/* get a new skb - if fail, old one will be reused */
new_skb = dev_alloc_skb(rtlpci-rxbuffersize);
if (unlikely(!new_skb)) {
- pr_err(Allocation of new skb failed in %s\n,
+ pr_err_ratelimited(Allocation of new skb failed in
%s\n,
__func__);
Or even better, remove the message.
--
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: Throughput regression with `tcp: refine TSO autosizing`
On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote:
+ if (msdu-sk) {
+ ewma_add(ar-tx_delay_us,
+ktime_to_ns(ktime_sub(ktime_get(), skb_cb-stamp)) /
+NSEC_PER_USEC);
+
+ ACCESS_ONCE(msdu-sk-sk_tx_completion_delay_cushion) =
+ (ewma_read(ar-tx_delay_us) *
+msdu-sk-sk_pacing_rate) 20;
+ }
+
Hi Michal
This is almost it ;)
As I said you must do this using u64 arithmetics, we still support 32bit
kernels.
Also, 20 instead of / 100 introduces a 5% error, I would use a
plain divide, as the compiler will use a reciprocal divide (ie : a
multiply)
We use 10 instead of /1000 because a 2.4 % error is probably okay.
ewma_add(ar-tx_delay_us,
ktime_to_ns(ktime_sub(ktime_get(),
skb_cb-stamp)) /
NSEC_PER_USEC);
u64 val = (u64)ewma_read(ar-tx_delay_us) *
msdu-sk-sk_pacing_rate;
do_div(val, USEC_PER_SEC);
ACCESS_ONCE(msdu-sk-sk_tx_completion_delay_cushion) =
(u32)val;
(WRITE_ONCE() would be better for new kernels, but ACCESS_ONCE() is ok
since we probably want to backport to stable kernels)
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: [V2, for, 3.19, 1/7] rtlwifi: Remove logging statement that is no longer needed
In commit e9538cf4f907 (rtlwifi: Fix error when accessing unmapped memory in skb), a printk was included to indicate that the condition had been reached. There is now enough evidence from other users that the fix is working. That logging statement can now be removed. Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@vger.kernel.org [V3.18] Thanks, applied to wireless-drivers.git. Kalle Valo -- 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/5] mwifiex: more_task flag for main_process
Avinash Patil pat...@marvell.com writes: Please drop this series as we are seeing issue with DMA alignment patch. I will resend v2 after fixing this. Ok, dropped. -- Kalle Valo -- 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
