* [PATCH 0/3] virtio and vhost-net performance enhancements
From: Michael S. Tsirkin @ 2011-05-05 15:07 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky, Heiko Carstens, Shirley Ma, lguest,
linux-kernel, virtualization, netdev, linux-s390, kvm,
Krishna Kumar, Tom Lendacky, steved, habanero
In-Reply-To: <cover.1304541918.git.mst@redhat.com>
Here are a couple of minor fixes suggested on list.
Applies on top of the previous patchset.
As before result pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next-event-idx-v1
Michael S. Tsirkin (3):
virtio: fix avail event support
virtio_ring: check used_event offset
virtio_ring: need_event api comment fix
drivers/virtio/virtio_ring.c | 2 +-
include/linux/virtio_ring.h | 10 ++++++++--
2 files changed, 9 insertions(+), 3 deletions(-)
--
1.7.5.53.gc233e
^ permalink raw reply
* [PATCH 1/3] virtio: fix avail event support
From: Michael S. Tsirkin @ 2011-05-05 15:08 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky, Heiko Carstens, Shirley Ma, lguest,
linux-kernel, virtualization, netdev, linux-s390, kvm,
Krishna Kumar, Tom Lendacky, steved, habanero
In-Reply-To: <cover.1304605816.git.mst@redhat.com>
make valid flag false, not true, on overrun
Reported-by: Tom Lendacky <tahm@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/virtio/virtio_ring.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 57bf9d5..0ea0781 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -242,7 +242,7 @@ add_head:
* kicked_avail index we stored. TODO: make sure all drivers
* kick at least once in 2^16 and remove this. */
if (unlikely(vq->vring.avail->idx == vq->kicked_avail))
- vq->kicked_avail_valid = true;
+ vq->kicked_avail_valid = false;
pr_debug("Added buffer head %i to %p\n", head, vq);
END_USE(vq);
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH 2/3] virtio_ring: check used_event offset
From: Michael S. Tsirkin @ 2011-05-05 15:08 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky, Heiko Carstens, Shirley Ma, lguest,
linux-kernel, virtualization, netdev, linux-s390, kvm,
Krishna Kumar, Tom Lendacky, steved, habanero
In-Reply-To: <cover.1304605816.git.mst@redhat.com>
Nothing's wrong with vring_size as is, but it's nice
to check that the new field in the avail ring
won't overlow into the used ring.
Reported-by: Tom Lendacky <tahm@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/linux/virtio_ring.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 2a3b0ea..089cbf2 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -119,7 +119,13 @@ static inline void vring_init(struct vring *vr, unsigned int num, void *p,
static inline unsigned vring_size(unsigned int num, unsigned long align)
{
- return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (2 + num)
+#ifdef __KERNEL__
+ /* Older versions did not have used_event field at the end of the
+ * avail ring. Used ring offset must be compatible with such devices. */
+ size_t s = sizeof(struct vring_desc) * num + sizeof(__u16) * (2 + num);
+ BUG_ON(ALIGN(s, align) != ALIGN(s + sizeof(__u16), align));
+#endif
+ return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (3 + num)
+ align - 1) & ~(align - 1))
+ sizeof(__u16) * 3 + sizeof(struct vring_used_elem) * num;
}
--
1.7.5.53.gc233e
^ permalink raw reply related
* [PATCH 3/3] virtio_ring: need_event api comment fix
From: Michael S. Tsirkin @ 2011-05-05 15:08 UTC (permalink / raw)
To: linux-kernel
Cc: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky, Heiko Carstens, Shirley Ma, lguest,
linux-kernel, virtualization, netdev, linux-s390, kvm,
Krishna Kumar, Tom Lendacky, steved, habanero
In-Reply-To: <cover.1304605816.git.mst@redhat.com>
fix typo in a comment: size -> side
Reported-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/linux/virtio_ring.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 089cbf2..0a45c6e 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -131,7 +131,7 @@ static inline unsigned vring_size(unsigned int num, unsigned long align)
}
/* The following is used with USED_EVENT_IDX and AVAIL_EVENT_IDX */
-/* Assuming a given event_idx value from the other size, if
+/* Assuming a given event_idx value from the other side, if
* we have just incremented index from old to new_idx,
* should we trigger an event? */
static inline int vring_need_event(__u16 event_idx, __u16 new_idx, __u16 old)
--
1.7.5.53.gc233e
^ permalink raw reply related
* Re: ath5k regression associating with APs in 2.6.38
From: Nick Kossifidis @ 2011-05-05 15:15 UTC (permalink / raw)
To: Justin P. Mattock
Cc: John W. Linville, Jiri Slaby, Luis R. Rodriguez, Bob Copeland,
linux-wireless, ath5k-devel, netdev, linux-kernel
In-Reply-To: <4DC2BBBE.1090607@gmail.com>
2011/5/5 Justin P. Mattock <justinmattock@gmail.com>:
> On 05/05/2011 07:30 AM, Nick Kossifidis wrote:
>>
>> 2011/5/5 Seth Forshee<seth.forshee@canonical.com>:
>>>
>>> On Wed, May 04, 2011 at 11:09:03PM +0300, Nick Kossifidis wrote:
>>>>
>>>> 2011/5/4 Seth Forshee<seth.forshee@canonical.com>:
>>>>>
>>>>> On Wed, May 04, 2011 at 01:27:17PM -0400, John W. Linville wrote:
>>>>>>
>>>>>> On Wed, May 04, 2011 at 10:38:19AM -0500, Seth Forshee wrote:
>>>>>>>
>>>>>>> I've been investigating some reports of a regression in associating
>>>>>>> with
>>>>>>> APs with AR2413 in 2.6.38. Association repeatedly fails with some
>>>>>>> "direct probe to x timed out" messages (see syslog excerpt below),
>>>>>>> although it will generally associate eventually, after many tries.
>>>>>>>
>>>>>>> Bisection identifies 8aec7af (ath5k: Support synth-only channel
>>>>>>> change
>>>>>>> for AR2413/AR5413) as offending commit. Prior to this commit there
>>>>>>> are
>>>>>>> no direct probe messages at all in the logs. I've also found that
>>>>>>> forcing fast to false at the top of ath5k_hw_reset() fixes the issue.
>>>>>>> I'm not sure what the connection is between this commit and the
>>>>>>> timeouts. Any suggestions?
>>>>>>
>>>>>> Have you tried reverting that commit on top of 2.6.38? Can you
>>>>>> recreate the issue with 2.6.39-rc6 (or later)?
>>>>>
>>>>> I started to revert that commit, but it wasn't straight-forward due to
>>>>> later changes. Forcing fast to false in ath5k_hw_reset() acts as a
>>>>> functional revert of sorts since that should force it back to a full
>>>>> reset for all channel changes, and it's much simpler than working out
>>>>> the right way to revert the commit. I think the results suggest
>>>>> strongly
>>>>> that a revert is likely to fix the problem. I can finish the work to
>>>>> revert if you'd still like to see the results.
>>>>>
>>>>> Testing a previous .39-rc kernel still exhibited the failure. I don't
>>>>> recall which one it was and apparently forgot to make note of it. I'll
>>>>> request testing against rc6.
>>>>>
>>>>> Thanks,
>>>>> Seth
>>>>>
>>>>
>>>> Do you get scan results ?
>>>> Can you enable ATH5K_DEBUG_RESET and see what you get ?
>>>
>>> 2.6.39-rc6 still fails. A more comprehensive log with ATH5K_DEBUG_RESET
>>> enabled is below.
>>>
>>> Scanning looks to be failing according to this log. I was thinking that
>>> I saw successfull scans in some of the previous logs, but I'll have to
>>> go back and check to be sure.
>>>
>>> Thanks,
>>> Seth
>>>
>>>
>>> kernel: [ 23.421242] ath5k 0000:06:02.0: PCI INT A -> GSI 22 (level,
>>> low) -> IRQ 22
>>> kernel: [ 23.421312] ath5k 0000:06:02.0: registered as 'phy0'
>>> kernel: [ 24.132959] ath: EEPROM regdomain: 0x63
>>> kernel: [ 24.132962] ath: EEPROM indicates we should expect a direct
>>> regpair map
>>> kernel: [ 24.132967] ath: Country alpha2 being used: 00
>>> kernel: [ 24.132969] ath: Regpair used: 0x63
>>> kernel: [ 24.136125] cfg80211: Updating information on frequency 2412
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136131] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136134] cfg80211: Updating information on frequency 2417
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136137] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136140] cfg80211: Updating information on frequency 2422
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136143] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136146] cfg80211: Updating information on frequency 2427
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136149] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136151] cfg80211: Updating information on frequency 2432
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136155] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136157] cfg80211: Updating information on frequency 2437
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136160] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136163] cfg80211: Updating information on frequency 2442
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136166] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136168] cfg80211: Updating information on frequency 2447
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136172] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136174] cfg80211: Updating information on frequency 2452
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136177] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136180] cfg80211: Updating information on frequency 2457
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136183] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136186] cfg80211: Updating information on frequency 2462
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136189] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136191] cfg80211: Updating information on frequency 2467
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136195] cfg80211: 2457000 KHz - 2482000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136197] cfg80211: Updating information on frequency 2472
>>> MHz for a 20 MHz width channel with regulatory rule:
>>> kernel: [ 24.136200] cfg80211: 2457000 KHz - 2482000 KHz @ KHz), (N/A
>>> mBi, 2000 mBm)
>>> kernel: [ 24.136203] cfg80211: Disabling freq 2484 MHz as custom regd
>>> has no rule that fits a 20 MHz wide channel
>>> kernel: [ 24.136404] cfg80211: Ignoring regulatory request Set by core
>>> since the driver uses its own custom regulatory domain
>>> kernel: [ 24.393924] ieee80211 phy0: Selected rate control algorithm
>>> 'minstrel_ht'
>>> kernel: [ 24.394588] ath5k phy0: Atheros AR2413 chip found (MAC: 0x78,
>>> PHY: 0x45)
>>> ...
>>> NetworkManager[725]:<info> (wlan0): driver supports SSID scans
>>> (scan_capa 0x01).
>>> NetworkManager[725]:<info> (wlan0): new 802.11 WiFi device (driver:
>>> 'ath5k' ifindex: 3)
>>> NetworkManager[725]:<info> (wlan0): exported as
>>> /org/freedesktop/NetworkManager/Devices/1
>>> NetworkManager[725]:<info> (wlan0): now managed
>>> NetworkManager[725]:<info> (wlan0): device state change: 1 -> 2 (reason
>>> 2)
>>> NetworkManager[725]:<info> (wlan0): bringing up device.
>>> NetworkManager[725]:<info> (wlan0): preparing device.
>>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 2).
>>> NetworkManager[725]: supplicant_interface_acquire: assertion `mgr_state
>>> == NM_SUPPLICANT_MANAGER_STATE_IDLE' failed
>>> kernel: [ 25.149294] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>> ...
>>> NetworkManager[725]:<info> Trying to start the supplicant...
>>> ...
>>> NetworkManager[725]:<info> (wlan0): supplicant manager state: down ->
>>> idle
>>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason
>>> 0)
>>> NetworkManager[725]:<info> (wlan0): supplicant interface state:
>>> starting -> ready
>>> ...
>>> NetworkManager[725]:<info> (wlan0): device state change: 3 -> 2 (reason
>>> 0)
>>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 0).
>>> NetworkManager[725]:<info> (wlan0): taking down device.
>>> NetworkManager[725]:<info> (wlan0): bringing up device.
>>> kernel: [ 104.430292] ath5k phy0: (ath5k_init_hw:2522): mode 2
>>> kernel: [ 104.430297] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>>> kernel: [ 104.431000] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 104.434475] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 104.434683] ath5k phy0: (ath5k_rfkill_disable:42): rfkill
>>> disable (gpio:0 polarity:0)
>>> kernel: [ 104.435759] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2412 MHz)
>>> kernel: [ 104.435762] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 104.436845] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 104.437191] ath5k phy0: (ath5k_conf_tx:602): Configure tx
>>> [queue 0], aifs: 2, cw_min: 7, cw_max: 15, txop: 102
>>> kernel: [ 104.437212] ath5k phy0: (ath5k_conf_tx:602): Configure tx
>>> [queue 1], aifs: 2, cw_min: 15, cw_max: 31, txop: 188
>>> kernel: [ 104.438337] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>> NetworkManager[725]:<info> (wlan0): supplicant interface state:
>>> starting -> ready
>>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason
>>> 42)
>>> wpa_supplicant[745]: Failed to initiate AP scan.
>>> kernel: [ 125.188087] net_ratelimit: 41 callbacks suppressed
>>> kernel: [ 125.188100] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 125.188109] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 125.291007] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 125.344076] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 125.344090] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 125.447014] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 125.500078] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 125.500091] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 125.602999] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 125.656070] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 155.188052] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 155.188058] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 155.188061] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 155.290844] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 155.344032] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 155.344038] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 155.446810] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 155.500031] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 155.500036] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 155.602811] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 155.656033] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 195.184088] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 195.184102] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 195.184110] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 195.287022] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 195.340066] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 195.340079] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 195.442967] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 195.496076] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 195.496088] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 195.599009] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 195.652078] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 245.188077] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 245.188091] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 245.188100] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 245.290997] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 245.344084] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 245.344092] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 245.446882] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 245.500053] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 245.500058] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 245.602808] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 245.656046] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 305.188050] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 305.188063] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 305.188071] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 305.290945] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 305.344070] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 305.344082] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 305.446943] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 305.500047] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 305.500058] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 305.602967] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 305.656090] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> NetworkManager[725]:<info> (wlan0): device state change: 3 -> 2 (reason
>>> 0)
>>> NetworkManager[725]:<info> (wlan0): deactivating device (reason: 0).
>>> NetworkManager[725]:<info> (wlan0): taking down device.
>>> kernel: [ 310.887530] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 310.887535] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>>> kernel: [ 310.990264] ath5k phy0: (ath5k_stop_hw:2619): putting device
>>> to sleep
>>> kernel: [ 310.990554] ath5k phy0: (ath5k_rfkill_enable:51): rfkill
>>> enable (gpio:0 polarity:0)
>>> NetworkManager[725]:<info> (wlan0): bringing up device.
>>> kernel: [ 315.755891] ath5k phy0: (ath5k_init_hw:2522): mode 2
>>> kernel: [ 315.755903] ath5k phy0: (ath5k_stop_locked:2481): invalid 0
>>> kernel: [ 315.756624] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 315.760236] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 315.760474] ath5k phy0: (ath5k_rfkill_disable:42): rfkill
>>> disable (gpio:0 polarity:0)
>>> kernel: [ 315.762566] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2412 MHz)
>>> kernel: [ 315.762574] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 315.764972] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>> NetworkManager[725]:<info> (wlan0): supplicant interface state:
>>> starting -> ready
>>> NetworkManager[725]:<info> (wlan0): device state change: 2 -> 3 (reason
>>> 42)
>>> wpa_supplicant[745]: Failed to initiate AP scan.
>>> kernel: [ 316.036068] net_ratelimit: 8 callbacks suppressed
>>> kernel: [ 316.036080] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 316.036089] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 316.140039] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 316.196067] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 316.196079] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 316.298940] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 316.352063] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 316.352071] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 316.455003] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 316.508080] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2432 -> 2437 MHz)
>>> kernel: [ 336.188067] net_ratelimit: 26 callbacks suppressed
>>> kernel: [ 336.188080] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 336.188088] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 336.290966] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 336.344059] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 336.344068] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 336.446912] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 336.500068] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 336.500077] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 336.602937] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 336.656058] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>> kernel: [ 366.188084] net_ratelimit: 29 callbacks suppressed
>>> kernel: [ 366.188097] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2412 -> 2417 MHz)
>>> kernel: [ 366.188105] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 366.290999] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 366.344099] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2417 -> 2422 MHz)
>>> kernel: [ 366.344112] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 366.447030] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 366.500094] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2422 -> 2427 MHz)
>>> kernel: [ 366.500106] ath5k phy0: (ath5k_reset:2648): resetting
>>> kernel: [ 366.603008] ath5k phy0: (ath5k_rx_start:1099): cachelsz 32
>>> rx_bufsize 2368
>>> kernel: [ 366.656103] ath5k phy0: (ath5k_chan_set:434): channel set,
>>> resetting (2427 -> 2432 MHz)
>>>
>>>
>>
>> Hmm I don't see any errors from reset/phy code, can you disable
>> Network Manager/wpa-supplicant and test connection on an open network
>> using iw ? It 'll give us a better picture...
>>
>> If iw doesn't return any scan results we are probably hitting a PHY/RF
>> error specific to your device (not all vendors follow the reference
>> design). Maybe we should follow a blacklist/whitelist approach for
>> this feature.
>>
>
> yeah Im getting this over here with my macbook pro. all of a sudden internet
> craps out, unable to reconnect.. reboot is the only way to get back online.
> dmesg here:
> http://fpaste.org/mwGn/
>
> I can try bisecting, but might take a while due to this occuring every few
> days or so.
>
> Justin P. Mattock
>
[ 26.219909] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Different card, different driver...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Krishna Kumar2 @ 2011-05-05 15:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <20110505090439.GD17647@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote on 05/05/2011 02:34:39 PM:
> > Do I need to apply all the patches and simply test?
> >
> > Thanks,
> >
> > - KK
>
> Exactly. You can also try to tune the threshold
> for interrupts as well.
I haven't tuned the threshhold, it is left it at 3/4. I ran
the new qemu/vhost/guest, and the results for 1K, 2K and 16K
are below. Note this is a different kernel version from my
earlier test results. So, f.e., BW1 represents 2.6.39-rc2,
the original kernel; while BW2 represents 2.6.37-rc5 (MST's
kernel). This also isn't with the fixes you have sent just
now. I will get a run with that either late tonight or
tomorrow.
________________________________________________________
I/O size: 1K
# BW1 BW2 (%) SD1 SD2 (%)
________________________________________________________
1 1723 3016 (75.0) 4.7 2.6 (-44.6)
2 3223 6712 (108.2) 18.0 7.1 (-60.5)
4 7223 8258 (14.3) 36.5 24.3 (-33.4)
8 8689 7943 (-8.5) 131.5 101.6 (-22.7)
16 8059 7398 (-8.2) 578.3 406.4 (-29.7)
32 7758 7208 (-7.0) 2281.4 1574.7 (-30.9)
64 7503 7155 (-4.6) 9734.0 6368.0 (-34.5)
96 7496 7078 (-5.5) 21980.9 15477.6 (-29.5)
128 7389 6900 (-6.6) 40467.5 26031.9 (-35.6)
________________________________________________________
Summary: BW: (4.4) SD: (-33.5)
________________________________________________________
I/O size: 2K
# BW1 BW2 (%) SD1 SD2 (%)
________________________________________________________
1 1608 4968 (208.9) 5.0 1.3 (-74.0)
2 3354 6974 (107.9) 18.6 4.9 (-73.6)
4 8234 8344 (1.3) 35.6 17.9 (-49.7)
8 8427 7818 (-7.2) 103.5 71.2 (-31.2)
16 7995 7491 (-6.3) 410.1 273.9 (-33.2)
32 7863 7149 (-9.0) 1678.6 1080.4 (-35.6)
64 7661 7092 (-7.4) 7245.3 4717.2 (-34.8)
96 7517 6984 (-7.0) 15711.2 9838.9 (-37.3)
128 7389 6851 (-7.2) 27121.6 18255.7 (-32.6)
________________________________________________________
Summary: BW: (6.0) SD: (-34.5)
________________________________________________________
I/O size: 16K
# BW1 BW2 (%) SD1 SD2 (%)
________________________________________________________
1 6684 7019 (5.0) 1.1 1.1 (0)
2 7674 7196 (-6.2) 5.0 4.8 (-4.0)
4 7358 8032 (9.1) 21.3 20.4 (-4.2)
8 7393 8015 (8.4) 82.7 82.0 (-.8)
16 7958 8366 (5.1) 283.2 310.7 (9.7)
32 7792 8113 (4.1) 1257.5 1363.0 (8.3)
64 7673 8040 (4.7) 5723.1 5812.4 (1.5)
96 7462 7883 (5.6) 12731.8 12119.8 (-4.8)
128 7338 7800 (6.2) 21331.7 21094.7 (-1.1)
________________________________________________________
Summary: BW: (4.6) SD: (-1.5)
Thanks,
- KK
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michał Mirosław @ 2011-05-05 15:26 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, Ben Hutchings, herbert
In-Reply-To: <20110504181813.GA17547@redhat.com>
On Wed, May 04, 2011 at 09:18:14PM +0300, Michael S. Tsirkin wrote:
> BTW, I just noticed that net-next spits out
> many of the following when I run any VMs:
[...]
> tap0: Features changed: 0x40004040 -> 0x401b4849
Before this message, userspace called ioctl(TIOCSETOFFLOAD)
turning offloads on.
> tap0: Dropping NETIF_F_SG since no checksum feature.
> tap0: Dropping NETIF_F_GSO since no SG feature.
> tap0: Features changed: 0x401b4849 -> 0x40004040
And then it probably called ioctl(TIOCSETOFFLOAD) again, disabling them.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Krishna Kumar2 @ 2011-05-05 15:36 UTC (permalink / raw)
To: Krishna Kumar2
Cc: davem, eric.dumazet, kvm, Michael S. Tsirkin, netdev,
netdev-owner, rusty
In-Reply-To: <OFB1ACC9EB.4567C1B1-ON65257887.0050044B-65257887.0054A5CE@in.ibm.com>
Krishna Kumar wrote on 05/05/2011 08:57:13 PM:
Oops, I sent my patch's test results for the 16K case.
The correct one is:
________________________________________________________
I/O size: 16K
# BW1 BW2 (%) SD1 SD2 (%)
________________________________________________________
1 6684 6670 (-.2) 1.1 .6 (-45.4)
2 7674 7859 (2.4) 5.0 2.6 (-48.0)
4 7358 7421 (.8) 21.3 11.6 (-45.5)
8 7393 7289 (-1.4) 82.7 44.8 (-45.8)
16 7958 7280 (-8.5) 283.2 166.3 (-41.2)
32 7792 7163 (-8.0) 1257.5 692.4 (-44.9)
64 7673 7096 (-7.5) 5723.1 2870.3 (-49.8)
96 7462 6963 (-6.6) 12731.8 6475.6 (-49.1)
128 7338 6919 (-5.7) 21331.7 12345.7 (-42.1)
________________________________________________________
Summary: BW: (-3.9) SD: (-45.4)
Sorry for the confusion.
Regards,
- KK
> ________________________________________________________
> I/O size: 16K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 6684 7019 (5.0) 1.1 1.1 (0)
> 2 7674 7196 (-6.2) 5.0 4.8 (-4.0)
> 4 7358 8032 (9.1) 21.3 20.4 (-4.2)
> 8 7393 8015 (8.4) 82.7 82.0 (-.8)
> 16 7958 8366 (5.1) 283.2 310.7 (9.7)
> 32 7792 8113 (4.1) 1257.5 1363.0 (8.3)
> 64 7673 8040 (4.7) 5723.1 5812.4 (1.5)
> 96 7462 7883 (5.6) 12731.8 12119.8 (-4.8)
> 128 7338 7800 (6.2) 21331.7 21094.7 (-1.1)
> ________________________________________________________
> Summary: BW: (4.6) SD: (-1.5)
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Michael S. Tsirkin @ 2011-05-05 15:34 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <OFB1ACC9EB.4567C1B1-ON65257887.0050044B-65257887.0054A5CE@in.ibm.com>
On Thu, May 05, 2011 at 08:57:13PM +0530, Krishna Kumar2 wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 05/05/2011 02:34:39 PM:
>
> > > Do I need to apply all the patches and simply test?
> > >
> > > Thanks,
> > >
> > > - KK
> >
> > Exactly. You can also try to tune the threshold
> > for interrupts as well.
>
> I haven't tuned the threshhold, it is left it at 3/4. I ran
> the new qemu/vhost/guest, and the results for 1K, 2K and 16K
> are below. Note this is a different kernel version from my
> earlier test results. So, f.e., BW1 represents 2.6.39-rc2,
> the original kernel; while BW2 represents 2.6.37-rc5 (MST's
> kernel).
Weird. My kernel is actually 2.6.39-rc2. So which is which?
> This also isn't with the fixes you have sent just
> now. I will get a run with that either late tonight or
> tomorrow.
Shouldn't affect anything performance-wise.
> ________________________________________________________
> I/O size: 1K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 1723 3016 (75.0) 4.7 2.6 (-44.6)
> 2 3223 6712 (108.2) 18.0 7.1 (-60.5)
> 4 7223 8258 (14.3) 36.5 24.3 (-33.4)
> 8 8689 7943 (-8.5) 131.5 101.6 (-22.7)
> 16 8059 7398 (-8.2) 578.3 406.4 (-29.7)
> 32 7758 7208 (-7.0) 2281.4 1574.7 (-30.9)
> 64 7503 7155 (-4.6) 9734.0 6368.0 (-34.5)
> 96 7496 7078 (-5.5) 21980.9 15477.6 (-29.5)
> 128 7389 6900 (-6.6) 40467.5 26031.9 (-35.6)
> ________________________________________________________
> Summary: BW: (4.4) SD: (-33.5)
>
> ________________________________________________________
> I/O size: 2K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 1608 4968 (208.9) 5.0 1.3 (-74.0)
> 2 3354 6974 (107.9) 18.6 4.9 (-73.6)
> 4 8234 8344 (1.3) 35.6 17.9 (-49.7)
> 8 8427 7818 (-7.2) 103.5 71.2 (-31.2)
> 16 7995 7491 (-6.3) 410.1 273.9 (-33.2)
> 32 7863 7149 (-9.0) 1678.6 1080.4 (-35.6)
> 64 7661 7092 (-7.4) 7245.3 4717.2 (-34.8)
> 96 7517 6984 (-7.0) 15711.2 9838.9 (-37.3)
> 128 7389 6851 (-7.2) 27121.6 18255.7 (-32.6)
> ________________________________________________________
> Summary: BW: (6.0) SD: (-34.5)
>
> ________________________________________________________
> I/O size: 16K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 6684 7019 (5.0) 1.1 1.1 (0)
> 2 7674 7196 (-6.2) 5.0 4.8 (-4.0)
> 4 7358 8032 (9.1) 21.3 20.4 (-4.2)
> 8 7393 8015 (8.4) 82.7 82.0 (-.8)
> 16 7958 8366 (5.1) 283.2 310.7 (9.7)
> 32 7792 8113 (4.1) 1257.5 1363.0 (8.3)
> 64 7673 8040 (4.7) 5723.1 5812.4 (1.5)
> 96 7462 7883 (5.6) 12731.8 12119.8 (-4.8)
> 128 7338 7800 (6.2) 21331.7 21094.7 (-1.1)
> ________________________________________________________
> Summary: BW: (4.6) SD: (-1.5)
>
> Thanks,
>
> - KK
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Michael S. Tsirkin @ 2011-05-05 15:37 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: davem, eric.dumazet, kvm, netdev, netdev-owner, rusty
In-Reply-To: <OF32D1B981.C4616456-ON65257887.00552498-65257887.00555A3C@in.ibm.com>
On Thu, May 05, 2011 at 09:06:00PM +0530, Krishna Kumar2 wrote:
> Krishna Kumar wrote on 05/05/2011 08:57:13 PM:
>
> Oops, I sent my patch's test results for the 16K case.
> The correct one is:
>
> ________________________________________________________
> I/O size: 16K
> # BW1 BW2 (%) SD1 SD2 (%)
> ________________________________________________________
> 1 6684 6670 (-.2) 1.1 .6 (-45.4)
> 2 7674 7859 (2.4) 5.0 2.6 (-48.0)
> 4 7358 7421 (.8) 21.3 11.6 (-45.5)
> 8 7393 7289 (-1.4) 82.7 44.8 (-45.8)
> 16 7958 7280 (-8.5) 283.2 166.3 (-41.2)
> 32 7792 7163 (-8.0) 1257.5 692.4 (-44.9)
> 64 7673 7096 (-7.5) 5723.1 2870.3 (-49.8)
> 96 7462 6963 (-6.6) 12731.8 6475.6 (-49.1)
> 128 7338 6919 (-5.7) 21331.7 12345.7 (-42.1)
> ________________________________________________________
> Summary: BW: (-3.9) SD: (-45.4)
>
> Sorry for the confusion.
>
> Regards,
>
> - KK
Interesting. So which is which?
> > ________________________________________________________
> > I/O size: 16K
> > # BW1 BW2 (%) SD1 SD2 (%)
> > ________________________________________________________
> > 1 6684 7019 (5.0) 1.1 1.1 (0)
> > 2 7674 7196 (-6.2) 5.0 4.8 (-4.0)
> > 4 7358 8032 (9.1) 21.3 20.4 (-4.2)
> > 8 7393 8015 (8.4) 82.7 82.0 (-.8)
> > 16 7958 8366 (5.1) 283.2 310.7 (9.7)
> > 32 7792 8113 (4.1) 1257.5 1363.0 (8.3)
> > 64 7673 8040 (4.7) 5723.1 5812.4 (1.5)
> > 96 7462 7883 (5.6) 12731.8 12119.8 (-4.8)
> > 128 7338 7800 (6.2) 21331.7 21094.7 (-1.1)
> > ________________________________________________________
> > Summary: BW: (4.6) SD: (-1.5)
^ permalink raw reply
* Re: [PATCH 0/4] [RFC] virtio-net: Improve small packet performance
From: Michael S. Tsirkin @ 2011-05-05 15:42 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <OFB1ACC9EB.4567C1B1-ON65257887.0050044B-65257887.0054A5CE@in.ibm.com>
On Thu, May 05, 2011 at 08:57:13PM +0530, Krishna Kumar2 wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 05/05/2011 02:34:39 PM:
>
> > > Do I need to apply all the patches and simply test?
> > >
> > > Thanks,
> > >
> > > - KK
> >
> > Exactly. You can also try to tune the threshold
> > for interrupts as well.
>
> I haven't tuned the threshhold, it is left it at 3/4. I ran
> the new qemu/vhost/guest, and the results for 1K, 2K and 16K
> are below. Note this is a different kernel version from my
> earlier test results. So, f.e., BW1 represents 2.6.39-rc2,
> the original kernel; while BW2 represents 2.6.37-rc5 (MST's
> kernel). This also isn't with the fixes you have sent just
> now. I will get a run with that either late tonight or
> tomorrow.
One thing I'd suggest is merging v2.6.39-rc6 into that tree.
rc2 is still pretty early, reason I use it is because that is
what net-next is.
--
MST
^ permalink raw reply
* Re: [PATCH] mlx4_en: Setting RSS hash result to skb->rxhash field
From: David Miller @ 2011-05-05 17:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: yevgenyp, bhutchings, netdev
In-Reply-To: <1304578518.32152.794.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 05 May 2011 08:55:18 +0200
> Really, we better use the linux/software full 32bit rxhash in this case,
> and wait for your 32bit full support.
Agreed.
^ permalink raw reply
* Re: [PATCH] usbnet: runtime pm: fix out of memory
From: David Miller @ 2011-05-05 17:39 UTC (permalink / raw)
To: oneukum-l3A5Bk7waGM
Cc: tom.leiming-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201105040926.12355.oneukum-l3A5Bk7waGM@public.gmane.org>
From: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Date: Wed, 4 May 2011 09:26:12 +0200
> Am Mittwoch, 4. Mai 2011, 08:59:41 schrieb Ming Lei:
>> Hi,
>>
>> 2011/5/3 Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>:
>>
>> > Do the devices in question use cdc_ether?
>>
>> No, the device is smsc95xx, which is compound device and is
>> integrated into pandaboard.
>
> OK,
>
> in this case:
>
> Acked-by: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] stmmac: removed not used definitions
From: David Miller @ 2011-05-05 17:43 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1304590250-9434-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Thu, 5 May 2011 12:10:50 +0200
> Reported-by: Karim Hamiti <karim.hamiti@st.com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [net-next v3 0/6] bnx2x enhancements and date update
From: David Miller @ 2011-05-05 17:45 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong, vladz, bhutchings
In-Reply-To: <1304589516.17528.11.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Thu, 5 May 2011 12:58:36 +0300
> Another re-spin with format fixes as reported by Ben Hutchings
> <bhutchings@solarflare.com>
All applied, thanks for fixing things up.
^ permalink raw reply
* Re: [PATCHv4 2/2] tg3: Allow ethtool to enable/disable loopback.
From: Mahesh Bandewar @ 2011-05-05 17:47 UTC (permalink / raw)
To: Michał Mirosław
Cc: Matt Carlson, David Miller, netdev, Michael Chan, Tom Herbert
In-Reply-To: <BANLkTi=1Nw6A8cMNyVGnASOA_VF018ooxA@mail.gmail.com>
On Wed, May 4, 2011 at 11:59 PM, Michał Mirosław <mirqus@gmail.com> wrote:
> 2011/5/5 Mahesh Bandewar <maheshb@google.com>:
>> This patch adds tg3_set_features() to handle loopback mode. Currently the
>> capability is added for the devices which support internal MAC loopback mode.
>> So when enabled, it enables internal-MAC loopback.
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>> ---
>> Changes since v3:
>> (a) Corrected the condition (|| => &&) where loopback capability is added.
>> (b) set_features() always returns 0.
>> (c) Clear the loopback bit in ndo_open callback to avoid discrepancy.
>>
>> Changes since v2:
>> Implemtned Joe Perches's style change.
>>
>> Changes since v1:
>> Implemented Matt Carlson's suggestions.
>> (a) Enable this capability on the devices which are capable of MAC-loopback
>> mode.
>> (b) check if the device is running before making changes.
>> (c) check bits before making changes.
>>
>> drivers/net/tg3.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 69 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
>> index 7c7c9a8..7f7a290 100644
>> --- a/drivers/net/tg3.c
>> +++ b/drivers/net/tg3.c
>> @@ -6309,6 +6309,44 @@ dma_error:
>> return NETDEV_TX_OK;
>> }
>>
>> +static int tg3_set_loopback(struct net_device *dev, u32 features)
>> +{
>> + struct tg3 *tp = netdev_priv(dev);
>> + u32 cur_mode = 0;
>> + int retval = 0;
>
> void? You always return zero and don't check it in callers.
>
> [...]
>> @@ -9485,6 +9533,15 @@ static int tg3_open(struct net_device *dev)
>>
>> netif_tx_start_all_queues(dev);
>>
>> + /*
>> + * Reset loopback feature if it was turned on while the device was down
>> + * to avoid and any discrepancy in features reporting.
>> + */
>> + if (dev->features & NETIF_F_LOOPBACK) {
>> + dev->features &= ~NETIF_F_LOOPBACK;
>> + dev->wanted_features &= ~NETIF_F_LOOPBACK;
>> + }
>> +
>
> if (dev->features & NETIF_F_LOOPBACK)
> tg3_set_loopback(dev, dev->features);
>
Unfortunately at this stage device will not be able to set-loopback so
I resorted to clearing the bit(s).
> Whatever you do, don't modify wanted_features in drivers.
>
Since just clearing the 'features' would leave wanted_features in
discrepant state, I thought this will bring it to a sane state. So
what is a preferred way?
> BTW, similar problems (also like in previous versions) are in
> forcedeth implementation.
Yes, whatever we decide about the state of the wanted_features, I'll
implement similarly for forcedeth. Which previous problem you are
referring to? Is it the return value? There is a different kind of
failure (error while writing the register). Since update_features()
cant handle return value, I'm ignoring the return value. As far as the
correct return code is concerned, I wasn't sure what is appropriate
return code here (may be PHY_ERROR would be appropriate there) but
again I could ignore it just the way rest of the code is ignoring.
>
> Best Regards,
> Michał Mirosław
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2 1/2] net: Export dev_queue_xmit_nit for use by macvlan driver
From: David Miller @ 2011-05-05 17:50 UTC (permalink / raw)
To: david.ward; +Cc: netdev, kaber
In-Reply-To: <1304036552-1589-2-git-send-email-david.ward@ll.mit.edu>
From: David Ward <david.ward@ll.mit.edu>
Date: Thu, 28 Apr 2011 20:22:31 -0400
> @@ -1521,11 +1521,13 @@ static inline int deliver_skb(struct sk_buff *skb,
> }
>
> /*
> - * Support routine. Sends outgoing frames to any network
> - * taps currently in use.
> + * dev_queue_xmit_nit - send outgoing frame to AF_PACKET sockets
> + *
> + * @skb: buffer to send
> + * @dev: network device that AF_PACKET sockets are attached to (if any)
> */
Your change to this comment is inaccurate.
AF_PACKET is only one of several types of entities that register these
kinds of taps.
Also, I really don't like exposing these kinds of internals for what is
largely a macvlan internal issue. Please find a less intrustive way
to solve this problem.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: use NETIF_F_ALL_TSO for vlan features
From: David Miller @ 2011-05-05 17:53 UTC (permalink / raw)
To: shanwei; +Cc: netdev, eilong, dm, leedom, mirqus, bhutchings
In-Reply-To: <4DBA4AB4.5000802@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 29 Apr 2011 13:20:52 +0800
>
> As Dimitris Michailidis suggested, use NETIF_F_ALL_TSO for vlan_features,
> which is a mask, but not hw_features.
>
> Compile test.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
I do not understand why we want to advertise a set of ->vlan_features
TSO flags that are different from the flags advertised in ->hw_features.
Why do we want to do this?
^ permalink raw reply
* Re: [PATCH 2/2 net-next] net: drivers: set TSO/UFO offload option explicitly
From: David Miller @ 2011-05-05 17:54 UTC (permalink / raw)
To: shanwei
Cc: netdev, rusty, mst, eric.dumazet, mirq-linux, mirqus, bhutchings,
dm
In-Reply-To: <4DBA4DF5.5020101@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 29 Apr 2011 13:34:45 +0800
> The device drivers should not use NETIF_F_ALL_TSO mask to set hw_features(or features),
> but have to explicitly set offload option. Because, This would make drivers automatically
> clain to support any new TSO feature an the moment of NETIF_F_ALL_TSO is expanded.
>
> Some code style tuning. Just compile test.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
But loopback is special. It can support anything the kernel stack can emit.
So for loopback, using NETIF_F_ALL_TSO is in fact appropriate.
^ permalink raw reply
* Re: [patch net-next-2.6] net: call dev_alloc_name from register_netdevice
From: David Miller @ 2011-05-05 17:58 UTC (permalink / raw)
To: jpirko; +Cc: netdev, eric.dumazet, mirqus, xemul
In-Reply-To: <1304162492-6606-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Sat, 30 Apr 2011 13:21:32 +0200
> Force dev_alloc_name() to be called from register_netdevice() by
> dev_get_valid_name(). That allows to remove multiple explicit
> dev_alloc_name() calls.
>
> The possibility to call dev_alloc_name in advance remains.
>
> This also fixes veth creation regresion caused by
> 84c49d8c3e4abefb0a41a77b25aa37ebe8d6b743
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
I like this change, and if some real legitimate hole is found
in it we can either quickly fix that or revert this simply.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Removed unnecessary assignments , gotos and goto labels
From: David Miller @ 2011-05-05 18:00 UTC (permalink / raw)
To: sasikanth.v19; +Cc: netdev
In-Reply-To: <1304187809-7887-1-git-send-email-sasikanth.v19@gmail.com>
From: Sasikanth V <sasikanth.v19@gmail.com>
Date: Sat, 30 Apr 2011 23:53:29 +0530
> @@ -1779,15 +1770,15 @@ static int packet_getname(struct socket *sock, struct sockaddr *uaddr,
> sll->sll_ifindex = po->ifindex;
> sll->sll_protocol = po->num;
> sll->sll_pkttype = 0;
> + sll->sll_hatype = 0;
> + sll->sll_halen = 0;
> +
> rcu_read_lock();
> dev = dev_get_by_index_rcu(sock_net(sk), po->ifindex);
> if (dev) {
> sll->sll_hatype = dev->type;
> sll->sll_halen = dev->addr_len;
> memcpy(sll->sll_addr, dev->dev_addr, dev->addr_len);
> - } else {
> - sll->sll_hatype = 0; /* Bad: we have no ARPHRD_UNSPEC */
> - sll->sll_halen = 0;
> }
> rcu_read_unlock();
This is completely bogus.
In the dev != NULL case, we'll now write to sll_hatype and sll_halen
twice, which is less inefficient than making sure we write to these
fields only one.
And outside of this part, I really don't like the cleanups you made
here, and they don't improve the code in any way in my eyes.
Sorry.
^ permalink raw reply
* Re: [PATCH] can: fix SJA1000 dlc for RTR packets
From: David Miller @ 2011-05-05 18:02 UTC (permalink / raw)
To: kurt.van.dijck; +Cc: socketcan-core, netdev
In-Reply-To: <20110502145048.GF338@e-circ.dyndns.org>
From: Kurt Van Dijck <kurt.van.dijck@eia.be>
Date: Mon, 2 May 2011 16:50:48 +0200
> RTR frames do have a valid data length code on CAN.
> The driver for SJA1000 did not handle that situation properly.
>
> Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: Add sendmmsg socket system call
From: David Miller @ 2011-05-05 18:06 UTC (permalink / raw)
To: anton; +Cc: acme, netdev
In-Reply-To: <20110503162135.5e410fcf@kryten>
From: Anton Blanchard <anton@samba.org>
Date: Tue, 3 May 2011 16:21:35 +1000
> This patch adds a multiple message send syscall and is the send
> version of the existing recvmmsg syscall. This is heavily
> based on the patch by Arnaldo that added recvmmsg.
>
> I wrote a microbenchmark to test the performance gains of using
> this new syscall:
>
> http://ozlabs.org/~anton/junkcode/sendmmsg_test.c
>
> The test was run on a ppc64 box with a 10 Gbit network card. The
> benchmark can send both UDP and RAW ethernet packets.
...
> We see a 20% improvement in throughput on UDP send and 30%
> on raw socket send.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Great work, applied, thanks!
^ permalink raw reply
* Re: [PATCH 1/2] net: use NETIF_F_ALL_TSO for vlan features
From: Michał Mirosław @ 2011-05-05 18:19 UTC (permalink / raw)
To: David Miller; +Cc: shanwei, netdev, eilong, dm, leedom, bhutchings
In-Reply-To: <20110505.105350.183065364.davem@davemloft.net>
2011/5/5 David Miller <davem@davemloft.net>:
> From: Shan Wei <shanwei@cn.fujitsu.com>
> Date: Fri, 29 Apr 2011 13:20:52 +0800
>> As Dimitris Michailidis suggested, use NETIF_F_ALL_TSO for vlan_features,
>> which is a mask, but not hw_features.
> I do not understand why we want to advertise a set of ->vlan_features
> TSO flags that are different from the flags advertised in ->hw_features.
>
> Why do we want to do this?
I remember some posts about hardware that needs HW tag insertion for
TSO on VLAN to work or other additional constraints for offloads on
VLANs. I wonder if vlan_features handling should be converted to
something like ndo_fix_features.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCHv4 2/2] tg3: Allow ethtool to enable/disable loopback.
From: Michał Mirosław @ 2011-05-05 18:35 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Matt Carlson, David Miller, netdev, Michael Chan, Tom Herbert
In-Reply-To: <BANLkTin88L+YBrpdaHR57CSx3dg2dMF7Yg@mail.gmail.com>
W dniu 5 maja 2011 19:47 użytkownik Mahesh Bandewar
<maheshb@google.com> napisał:
> On Wed, May 4, 2011 at 11:59 PM, Michał Mirosław <mirqus@gmail.com> wrote:
>> 2011/5/5 Mahesh Bandewar <maheshb@google.com>:
>>> This patch adds tg3_set_features() to handle loopback mode. Currently the
>>> capability is added for the devices which support internal MAC loopback mode.
>>> So when enabled, it enables internal-MAC loopback.
[...]
>>> @@ -9485,6 +9533,15 @@ static int tg3_open(struct net_device *dev)
>>>
>>> netif_tx_start_all_queues(dev);
>>>
>>> + /*
>>> + * Reset loopback feature if it was turned on while the device was down
>>> + * to avoid and any discrepancy in features reporting.
>>> + */
>>> + if (dev->features & NETIF_F_LOOPBACK) {
>>> + dev->features &= ~NETIF_F_LOOPBACK;
>>> + dev->wanted_features &= ~NETIF_F_LOOPBACK;
>>> + }
>>> +
>>
>> if (dev->features & NETIF_F_LOOPBACK)
>> tg3_set_loopback(dev, dev->features);
>>
> Unfortunately at this stage device will not be able to set-loopback so
> I resorted to clearing the bit(s).
ndo_fix_features+ndo_set_features might be caled before ndo_open - the
first might be just from register_netdev() so even before ndo_open
callback.
>> Whatever you do, don't modify wanted_features in drivers.
> Since just clearing the 'features' would leave wanted_features in
> discrepant state, I thought this will bring it to a sane state. So
> what is a preferred way?
If you really can't do other way, driver should keep additional state
that is checked in ndo_fix_features callback.
>> BTW, similar problems (also like in previous versions) are in
>> forcedeth implementation.
> Yes, whatever we decide about the state of the wanted_features, I'll
> implement similarly for forcedeth. Which previous problem you are
> referring to? Is it the return value? There is a different kind of
> failure (error while writing the register). Since update_features()
> cant handle return value, I'm ignoring the return value. As far as the
> correct return code is concerned, I wasn't sure what is appropriate
> return code here (may be PHY_ERROR would be appropriate there) but
> again I could ignore it just the way rest of the code is ignoring.
Let's wait for this threads points to be resolved. You will probably
change the forcedeth's implementation then anyway. :-)
Best Regards,
Michał Mirosław
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox