* Re: [PATCH 3.2-rc7] skge: restore rx multicast filter on resume and after config changes
From: David Miller @ 2011-12-31 4:33 UTC (permalink / raw)
To: florz; +Cc: netdev, shemminger
In-Reply-To: <20111231033009.GE2698@florz.florz.dyndns.org>
From: Florian Zumbiehl <florz@florz.de>
Date: Sat, 31 Dec 2011 04:30:09 +0100
> Restore skge hardware registers for multicast filtering to their
> appropriate values after system resume and after hardware restarts
> that are done when changing certain settings.
>
> Signed-off-by: Florian Zumbiehl <florz@florz.de>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 3.2-rc7] skge: restore rx multicast filter on resume and after config changes
From: Florian Zumbiehl @ 2011-12-31 3:30 UTC (permalink / raw)
To: netdev, shemminger, davem
Restore skge hardware registers for multicast filtering to their
appropriate values after system resume and after hardware restarts
that are done when changing certain settings.
Signed-off-by: Florian Zumbiehl <florz@florz.de>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index c7b6083..dea0cb4 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -2606,6 +2606,9 @@ static int skge_up(struct net_device *dev)
spin_unlock_irq(&hw->hw_lock);
napi_enable(&skge->napi);
+
+ skge_set_multicast(dev);
+
return 0;
free_tx_ring:
^ permalink raw reply related
* Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.
From: Bjarke Istrup Pedersen @ 2011-12-31 1:37 UTC (permalink / raw)
To: Francois Romieu
Cc: David Miller, shemminger, bhutchings, linux-kernel, netdev, rl
In-Reply-To: <CACPM=kXAr46BXAc3t8puRB37NeFy_ZEOWZa0H=DnSioagSLpxA@mail.gmail.com>
2011/12/30 Bjarke Istrup Pedersen <gurligebis@gentoo.org>:
> 2011/12/30 Francois Romieu <romieu@fr.zoreil.com>:
>> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
>> [...]
>>> Does not build with patch:
>>
>> Neither did it here. My head is already elsewhere.
>>
>> [...]
>>> Wouldn't it be an idea to move the declarations to a via-rhine.h file,
>>> and include it, to work around it, and seperate it like it should be?
>>
>> Code could be correctly ordered too. Forward declare it. It's good enough
>> in the meantime.
>
> Forward declaring it makes it compile just fine.
>
> I'll try and do some stress test of it when the rest of the house goes
> to sleep, so I don't cut off the net :)
>
> /Bjarke
Okay, this is beginning to look great.
Just tried randomly up'ing/down'ing the interfaces on the router while
there was alot of trafic going between them (a client downloading a
knoppix live dvd using bittorrent) - survived without a single bump.
Also tried connect a machine to one of the ports, and copying a large
file across (something that before could make it lock up within 15
secords) - also worked without any problems - CPU usage around 15%
(mostly "top" using that), so thats not bad at all.
Is there any other testcases that I should try out?
/Bjarke
>> --
>> Ueimor
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Julian Anastasov @ 2011-12-31 0:09 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Simon Horman, Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang
In-Reply-To: <20111230112419.GB12015@1984>
Hello,
On Fri, 30 Dec 2011, Pablo Neira Ayuso wrote:
> Hi Simon,
>
> On Fri, Dec 30, 2011 at 02:19:01PM +0900, Simon Horman wrote:
> > Hi Pablo,
> >
> > please consider pulling
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next
> > master
>
> Since this is a fix, I can try to pass this for 3.2-rc7 to davem. I
> read Linus will release 3.2 by new year, so we can still try to see if
> we can get it in time.
>
> Let me know what you prefer.
It is a good idea, if it is not too late.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 0/5] NFS: create blocklayout pipe per network namesapce context
From: Trond Myklebust @ 2011-12-30 22:55 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, bfields-uC3wQj2KruNg9hUCZPvPmw,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111129090754.20730.64567.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Tue, 2011-11-29 at 13:10 +0300, Stanislav Kinsbursky wrote:
> This patch set was created in context of clone of git
> branch: git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git.
> tag: v3.1
>
> This patch set depends on previous patch sets titled:
> 1) "SUNRPC: initial part of making pipefs work in net ns"
> 2) "SUNPRC: cleanup PipeFS for network-namespace-aware users"
> 3) "SUNRPC: make RPC clients use network-namespace-aware PipeFS routines"
> 4) "NFS: create clients and IDMAP pipes per network namespace"
>
> This patch set is the final part of making SUNRPC PipeFS and it's users work in
> network namespace context.
>
> The following series consists of:
>
> ---
>
> Stanislav Kinsbursky (5):
> NFS: handle blocklayout pipe PipeFS dentry by network namespace aware routines
> NFS: blocklayout pipe creation per network namespace context introduced
> NFS: blocklayout PipeFS notifier introduced
> NFS: remove RPC PipeFS mount point reference from blocklayout routines
> SUNRPC: kernel PipeFS mount point creation routines removed
>
>
> fs/nfs/blocklayout/blocklayout.c | 154 ++++++++++++++++++++++++++++-------
> fs/nfs/blocklayout/blocklayout.h | 3 -
> fs/nfs/blocklayout/blocklayoutdev.c | 5 +
> fs/nfs/blocklayout/blocklayoutdm.c | 7 +-
> fs/nfs/inode.c | 1
> fs/nfs/netns.h | 1
> include/linux/sunrpc/rpc_pipe_fs.h | 2
> net/sunrpc/rpc_pipe.c | 21 -----
> 8 files changed, 137 insertions(+), 57 deletions(-)
These patches need rebasing in order to apply on top of 3.2-rc7...
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 6/6] NFS: idmap PipeFS notifier introduced
From: Trond Myklebust @ 2011-12-30 22:54 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111128133410.4251.656.stgit@localhost6.localdomain6>
On Mon, 2011-11-28 at 17:34 +0300, Stanislav Kinsbursky wrote:
> This patch subscribes NFS clients to RPC pipefs notifications. Idmap notifier
> is registering on NFS module load. This notifier callback is responsible for
> creation/destruction of PipeFS idmap pipe dentry for NFS4 clients.
>
> Since ipdmap pipe is created in rpc client pipefs directory, we have make sure,
> that this directory has been created already. IOW RPC client notifier callback
> has been called already. To achive this, PipeFS notifier priorities has been
> introduced (RPC clients notifier priority is greater than NFS idmap one).
> But this approach gives another problem: unlink for RPC client directory will
> be called before NFS idmap pipe unlink on UMOUNT event and will fail, because
> directory is not empty.
> The solution, introduced in this patch, is to try to remove client directory
> once again after idmap pipe was unlinked. This looks like ugly hack, so
> probably it should be replaced in some more elegant way.
>
> Note that no locking required in notifier callback because PipeFS superblock
> pointer is passed as an argument from it's creation or destruction routine and
> thus we can be sure about it's validity.
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
This patch gives me:
Kernel: arch/x86/boot/bzImage is ready (#3)
Building modules, stage 2.
MODPOST 921 modules
ERROR: "nfs_idmap_init" [fs/nfs/nfs.ko] undefined!
ERROR: "nfs_idmap_quit" [fs/nfs/nfs.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2
if CONFIG_NFS_V4 is not defined.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.
From: Bjarke Istrup Pedersen @ 2011-12-30 22:41 UTC (permalink / raw)
To: Francois Romieu
Cc: David Miller, shemminger, bhutchings, linux-kernel, netdev, rl
In-Reply-To: <20111230221938.GA6197@electric-eye.fr.zoreil.com>
2011/12/30 Francois Romieu <romieu@fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
> [...]
>> Does not build with patch:
>
> Neither did it here. My head is already elsewhere.
>
> [...]
>> Wouldn't it be an idea to move the declarations to a via-rhine.h file,
>> and include it, to work around it, and seperate it like it should be?
>
> Code could be correctly ordered too. Forward declare it. It's good enough
> in the meantime.
Forward declaring it makes it compile just fine.
I'll try and do some stress test of it when the rest of the house goes
to sleep, so I don't cut off the net :)
/Bjarke
> --
> Ueimor
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] bonding: fix error handling if slave is busy
From: Stephen Hemminger @ 2011-12-30 22:40 UTC (permalink / raw)
To: David Miller, Jay Vosburgh, Andy Gospodarek, netdev
The bonding device can cause kernel panic in the enslave error handling.
If slave device already has a receive handler registered, then the
error unwind does not clear the new entry out of the slave list.
This ends up leaving a reference to freed memory in the bond
device slave linked list.
The following is a simple example:
# modprobe dummy
# ip li add dummy0-1 link dummy0 type macvlan
# modprobe bonding
# echo +dummy0 >/sys/class/net/bond0/bonding/slaves
# ip -s li show dev bond0
This returns with -EBUSY, but the bonding device has bogus entry in
the slave list, and will panic on next operation that gets statistics
from bond0.
The fix is to detach the slave (which removes it from the list)
in the unwind path.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Patch is against net-next but should be applied to net (3.2), and
stable (3.1 and 3.0).
--- a/drivers/net/bonding/bond_main.c 2011-12-30 14:20:03.171823181 -0800
+++ b/drivers/net/bonding/bond_main.c 2011-12-30 14:20:20.232020474 -0800
@@ -1853,6 +1853,9 @@ err_dest_symlinks:
bond_destroy_slave_symlinks(bond_dev, slave_dev);
err_close:
+ write_lock_bh(&bond->lock);
+ bond_detach_slave(bond, new_slave);
+ write_unlock_bh(&bond->lock);
dev_close(slave_dev);
err_unset_master:
^ permalink raw reply
* Re: [PATCH] r8169: Enable suspend when device is idle from boot.
From: David Miller @ 2011-12-30 22:22 UTC (permalink / raw)
To: tbroch; +Cc: nic_swsd, romieu, netdev
In-Reply-To: <1325183594-8947-1-git-send-email-tbroch@chromium.org>
From: Todd Broch <tbroch@chromium.org>
Date: Thu, 29 Dec 2011 10:33:14 -0800
> The r8169 driver supports power management and correctly transitions
> from active to suspend when link transitions from connected to
> disconnected. However, if link is not connected at boot the device
> remains active after the initial probe.
>
> This change adds a check of the link status to the idle pm_op that
> will schedule a suspend if inactive.
>
> Signed-off-by: Todd Broch <tbroch@chromium.org>
Francois, what would you like me to do with this patch?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next V2 00/21] net/mlx4: SRIOV support
From: Yinghai Lu @ 2011-12-30 22:23 UTC (permalink / raw)
To: Or Gerlitz
Cc: Yevgeny Petrilin, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org, Liran Liss,
jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org
In-Reply-To: <CAJZOPZJ+BxAa_OcB0f5nPAjnW7eZfsDdXz_o-VSCW7dsp5p2wg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 14, 2011 at 1:50 PM, Or Gerlitz <or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Dec 14, 2011 at 10:42 PM, Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
>> got following warning:
>
> could you send your .config as attached to Yevgeny Petrilin
> <yevgenyp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>, he will distribute it to the group
hotplug removal is broken...
sca21d-0a86d3dd:~ # echo 0 > /sys/bus/pci/slots/1/power
[ 123.085198] pciehp 0000:00:02.2:pcie04: disable_slot: physical_slot = 1
[ 123.091863] pciehp 0000:00:02.2:pcie04: pciehp_get_power_status:
SLOTCTRL a8 value read 1f9
[ 123.100210] pciehp 0000:00:02.2:pcie04: pciehp_unconfigure_device:
domain:bus:dev = 0000:30:00
[ 123.114078] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000010
[ 123.121923] IP: [<ffffffff8177fc92>] mlx4_table_put+0x57/0xaf
[ 123.127684] PGD 0
[ 123.129712] Oops: 0000 [#1] SMP
[ 123.132969] CPU 0
[ 123.134806] Modules linked in:
[ 123.138063]
[ 123.139552] Pid: 7617, comm: bash Not tainted
3.2.0-rc7-tip-yh-03751-ga431a72-dirty #35 Oracle Corporation Sun Blade
/BD,ASSY,
[ 123.151662] RIP: 0010:[<ffffffff8177fc92>] [<ffffffff8177fc92>]
mlx4_table_put+0x57/0xaf
[ 123.159850] RSP: 0018:ffff8802707018d8 EFLAGS: 00010296
[ 123.165151] RAX: ffff880175a69900 RBX: ffff8801756f4f50 RCX: ffff880276c407e8
[ 123.172272] RDX: 0000000000000000 RSI: ffff880276c407e8 RDI: ffff880270701898
[ 123.179391] RBP: ffff880270701908 R08: ffff880270701878 R09: 3d605d874c4567fa
[ 123.186512] R10: 3d605d874c4567e5 R11: dead000000200200 R12: 0000000000000000
[ 123.193633] R13: ffff8801756f4f70 R14: ffff8801756f0000 R15: 0000000000000000
[ 123.200754] FS: 00007f44d66686f0(0000) GS:ffff880179e00000(0000)
knlGS:0000000000000000
[ 123.208827] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 123.214564] CR2: 0000000000000010 CR3: 000000016bf94000 CR4: 00000000000407f0
[ 123.221684] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 123.228805] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 123.235926] Process bash (pid: 7617, threadinfo ffff880270700000,
task ffff880276c40000)
[ 123.243997] Stack:
[ 123.246009] 0000000000001dbf ffff8801756f4f50 ffff8801756f0000
0000000000001d80
[ 123.253458] 0000000000040000 0000000000001dbf ffff880270701948
ffffffff8177fec7
[ 123.260908] 0000000000000040 0000000000001d80 0000000000000006
ffff8801756f0000
[ 123.268357] Call Trace:
[ 123.270808] [<ffffffff8177fec7>] mlx4_table_put_range+0x35/0x50
[ 123.276806] [<ffffffff817857f7>] __mlx4_free_mtt_range+0x5c/0x65
[ 123.282893] [<ffffffff81785887>] mlx4_free_mtt_range+0x87/0x92
[ 123.288802] [<ffffffff81779d4e>] ? __mlx4_cmd+0x4a/0x6b
[ 123.294105] [<ffffffff817854e9>] ? mlx4_HW2SW_MPT.constprop.22+0x43/0x45
[ 123.300878] [<ffffffff817858a9>] mlx4_mtt_cleanup+0x17/0x19
[ 123.306527] [<ffffffff8178590c>] mlx4_mr_free_reserved+0x61/0x66
[ 123.312607] [<ffffffff81785d6a>] mlx4_mr_free+0x17/0x3e
[ 123.317910] [<ffffffff81785db0>] mlx4_fmr_free+0x1f/0x2c
[ 123.323307] [<ffffffff81a32e3e>] mlx4_ib_fmr_dealloc+0x24/0x3e
[ 123.329215] [<ffffffff81134437>] ? kfree+0x125/0x131
[ 123.334257] [<ffffffff81981fb7>] ib_dealloc_fmr+0x18/0x25
[ 123.339732] [<ffffffff81984e56>] ib_destroy_fmr_pool+0x8c/0xf7
[ 123.345640] [<ffffffff81a5ebc7>] srp_remove_one+0x19d/0x1c6
[ 123.351287] [<ffffffff81984429>] ib_unregister_device+0x3d/0xe3
[ 123.357284] [<ffffffff81a30058>] mlx4_ib_remove+0x26/0xed
[ 123.362756] [<ffffffff81780246>] mlx4_remove_device+0x57/0x72
[ 123.368577] [<ffffffff8178052a>] mlx4_unregister_device+0x3c/0x72
[ 123.374744] [<ffffffff81782477>] mlx4_remove_one+0xb9/0x23f
[ 123.380395] [<ffffffff81359137>] pci_device_remove+0x3c/0xbc
[ 123.386129] [<ffffffff81416ee7>] __device_release_driver+0x86/0xd2
[ 123.392383] [<ffffffff81416f58>] device_release_driver+0x25/0x32
[ 123.398464] [<ffffffff81416aee>] bus_remove_device+0x93/0xa3
[ 123.404199] [<ffffffff81414d35>] device_del+0x12d/0x17f
[ 123.409499] [<ffffffff81414d9a>] device_unregister+0x13/0x1f
[ 123.415235] [<ffffffff81354826>] pci_stop_bus_device+0x8a/0xad
[ 123.421142] [<ffffffff81354984>] pci_remove_bus_device+0x13/0x1f
[ 123.427226] [<ffffffff81366ac6>] pciehp_unconfigure_device+0x107/0x16d
[ 123.433825] [<ffffffff81366539>] pciehp_disable_slot+0x11e/0x186
[ 123.439906] [<ffffffff813667ec>] pciehp_sysfs_disable_slot+0x68/0x108
[ 123.446420] [<ffffffff81365929>] disable_slot+0x58/0x5c
[ 123.451722] [<ffffffff8136273e>] power_write_file+0xd1/0x11b
[ 123.457457] [<ffffffff8136266d>] ? get_attention_status+0xad/0xad
[ 123.463625] [<ffffffff8135c9b9>] pci_slot_attr_store+0x29/0x2b
[ 123.469533] [<ffffffff811960f8>] sysfs_write_file+0x10e/0x14a
[ 123.475354] [<ffffffff8113b2cd>] vfs_write+0xb5/0x128
[ 123.480483] [<ffffffff8113b529>] sys_write+0x4d/0x77
[ 123.485526] [<ffffffff81c653d2>] system_call_fastpath+0x16/0x1b
[ 123.491517] Code: 89 ef 41 21 c7 89 c8 99 f7 7e 10 31 f6 89 c1 44
89 f8 99 f7 f9 41 89 c7 e8 e8 c0 4d 00 48 8b 83 c8 00 00 00 4d 63 e7
4a 8b 14 e0 <8b> 42 10 ff c8 85 c0 89 42 10 75 37 41 c1 e7 12 4c 89 f7
49 63
[ 123.511545] RIP [<ffffffff8177fc92>] mlx4_table_put+0x57/0xaf
[ 123.517383] RSP <ffff8802707018d8>
[ 123.520866] CR2: 0000000000000010
[ 123.524228] ---[ end trace 6436e31aa4627ed0 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 net-next 0/3] be2net: Patch series
From: David Miller @ 2011-12-30 22:22 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20111230221454.GA6809@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@Emulex.Com>
Date: Fri, 30 Dec 2011 16:14:54 -0600
> [1/3] be2net: fix be_vlan_add/rem_vid
> [2/3] be2net: fix range check for set_qos for a VF
> [3/3] be2net: query link status in be_open()
>
> Please apply.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.
From: Francois Romieu @ 2011-12-30 22:19 UTC (permalink / raw)
To: Bjarke Istrup Pedersen
Cc: David Miller, shemminger, bhutchings, linux-kernel, netdev, rl
In-Reply-To: <CACPM=kUxSRhDc2EqgceBRTFgBei7dh3_n7bPyoH=8aNC_uq4FA@mail.gmail.com>
Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
[...]
> Does not build with patch:
Neither did it here. My head is already elsewhere.
[...]
> Wouldn't it be an idea to move the declarations to a via-rhine.h file,
> and include it, to work around it, and seperate it like it should be?
Code could be correctly ordered too. Forward declare it. It's good enough
in the meantime.
--
Ueimor
^ permalink raw reply
* boding and netpoll
From: Maxim Uvarov @ 2011-12-30 22:17 UTC (permalink / raw)
To: netdev
netpoll_send_skb_on_dev() disables interrupts which cause warning
which does spin_unlock_bh() in case if netpoll is used on bonded
interface (netconsole in my case).
Looking for some clear fix for that. Maybe spin lock instead of
spin_lock_bh in _lock_tx_hashtbl in case if interrupts are disabled?
WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x69/0x80()
[<c0461b59>] ? local_bh_enable_ip+0x69/0x80
[<c045aea1>] warn_slowpath_common+0x81/0xa0
[<c0461b59>] ? local_bh_enable_ip+0x69/0x80
[<c045aee2>] warn_slowpath_null+0x22/0x30
[<c0461b59>] local_bh_enable_ip+0x69/0x80
[<c086ab83>] _raw_spin_unlock_bh+0x13/0x20
[<f82b2150>] tlb_choose_channel+0x50/0xb0 [bonding]
[<f82b3387>] bond_alb_xmit+0x207/0x210 [bonding]
[<f82ab647>] __bond_start_xmit+0x177/0x1a0 [bonding]
[<f82abe66>] bond_start_xmit+0x46/0x80 [bonding]
[<c07c9681>] netpoll_send_skb_on_dev+0x121/0x1a0
[<c07a9afe>] ? __alloc_skb+0x7e/0x120
[<c07c996c>] netpoll_send_udp+0x1dc/0x1f0
[<f838e73f>] write_msg+0x8f/0xc0 [netconsole]
[<f838e6b0>] ? store_remote_port+0x60/0x60 [netconsole]
[<c045b2a7>] __call_console_drivers+0x77/0x90
[<c045b311>] _call_console_drivers+0x51/0x90
[<c045b60b>] call_console_drivers+0x8b/0xd0
[<c045b867>] console_unlock+0x37/0xc0
[<c045be59>] vprintk+0x159/0x300
[<c0541215>] ? path_openat+0xc5/0x360
[<c0541595>] ? do_filp_open+0x35/0x80
[<c045c020>] printk+0x20/0x30
[<c06acc9d>] __handle_sysrq+0x3d/0x110
[<c05aaaee>] ? security_file_permission+0x1e/0x90
[<c06acdba>] write_sysrq_trigger+0x4a/0x50
[<c06acd70>] ? __handle_sysrq+0x110/0x110
[<c057e28d>] proc_reg_write+0x5d/0x80
[<c0534ffb>] vfs_write+0x9b/0x160
[<c04aff91>] ? audit_syscall_exit+0x381/0x3f0
[<c057e230>] ? proc_reg_poll+0x80/0x80
[<c0535622>] sys_write+0x42/0x70
[<c087231f>] sysenter_do_call+0x12/0x28
void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
struct net_device *dev)
{
.
local_irq_save(flags);
status = ops->ndo_start_xmit(skb, dev);
local_irq_restore(flags);
.
}
.
then bond_start_xmit()
static struct slave *tlb_choose_channel(struct bonding *bond, u32
ash_index,
u32 skb_len)
{
.
spin_lock_bh(&(BOND_ALB_INFO(bond).tx_hashtbl_lock));
.....
spin_unlock_bh(&(BOND_ALB_INFO(bond).tx_hashtbl_lock));
}
.
static inline void __raw_spin_unlock_bh(raw_spinlock_t *lock)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
do_raw_spin_unlock(lock);
preempt_enable_no_resched();
local_bh_enable_ip((unsigned long)__builtin_return_address(0));
}
.
static inline void _local_bh_enable_ip(unsigned long ip)
{
WARN_ON_ONCE(in_irq() || irqs_disabled());
Best regards,
Maxim Uvarov.
^ permalink raw reply
* Re: [FIX PATCH net] mlx4_en: nullify cq->vector field when closing completion queue
From: David Miller @ 2011-12-30 22:16 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <4EFC8C26.3060006@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Thu, 29 Dec 2011 17:49:58 +0200
> Caused loss of connectivity when changing ring size.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next 3/3] be2net: query link status in be_open()
From: Ajit Khaparde @ 2011-12-30 22:15 UTC (permalink / raw)
To: davem; +Cc: netdev
be2net gets an async link status notification from the FW when it creates
an MCC queue. There are some cases in which this gratuitous notification
is not received from FW. To cover this explicitly query the link status
in be_open().
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 5 ++++-
drivers/net/ethernet/emulex/benet/be_cmds.c | 21 +++++++++++++++++----
drivers/net/ethernet/emulex/benet/be_cmds.h | 7 ++++---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 7 +++++--
drivers/net/ethernet/emulex/benet/be_main.c | 24 +++++++++++++++---------
5 files changed, 45 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 995198d..cbdec25 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -299,6 +299,8 @@ struct be_vf_cfg {
u32 tx_rate;
};
+#define BE_FLAGS_LINK_STATUS_INIT 1
+
struct be_adapter {
struct pci_dev *pdev;
struct net_device *netdev;
@@ -347,6 +349,7 @@ struct be_adapter {
struct delayed_work work;
u16 work_counter;
+ u32 flags;
/* Ethtool knobs and info */
char fw_ver[FW_VER_LEN];
int if_handle; /* Used to configure filtering */
@@ -538,7 +541,7 @@ static inline bool be_error(struct be_adapter *adapter)
extern void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
u16 num_popped);
-extern void be_link_status_update(struct be_adapter *adapter, u32 link_status);
+extern void be_link_status_update(struct be_adapter *adapter, u8 link_status);
extern void be_parse_stats(struct be_adapter *adapter);
extern int be_load_fw(struct be_adapter *adapter, u8 *func);
#endif /* BE_H */
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 62868ea..0fcb456 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -125,7 +125,14 @@ done:
static void be_async_link_state_process(struct be_adapter *adapter,
struct be_async_event_link_state *evt)
{
- be_link_status_update(adapter, evt->port_link_status);
+ /* When link status changes, link speed must be re-queried from FW */
+ adapter->link_speed = -1;
+
+ /* For the initial link status do not rely on the ASYNC event as
+ * it may not be received in some cases.
+ */
+ if (adapter->flags & BE_FLAGS_LINK_STATUS_INIT)
+ be_link_status_update(adapter, evt->port_link_status);
}
/* Grp5 CoS Priority evt */
@@ -1232,7 +1239,7 @@ err:
/* Uses synchronous mcc */
int be_cmd_link_status_query(struct be_adapter *adapter, u8 *mac_speed,
- u16 *link_speed, u32 dom)
+ u16 *link_speed, u8 *link_status, u32 dom)
{
struct be_mcc_wrb *wrb;
struct be_cmd_req_link_status *req;
@@ -1240,6 +1247,9 @@ int be_cmd_link_status_query(struct be_adapter *adapter, u8 *mac_speed,
spin_lock_bh(&adapter->mcc_lock);
+ if (link_status)
+ *link_status = LINK_DOWN;
+
wrb = wrb_from_mccq(adapter);
if (!wrb) {
status = -EBUSY;
@@ -1247,7 +1257,7 @@ int be_cmd_link_status_query(struct be_adapter *adapter, u8 *mac_speed,
}
req = embedded_payload(wrb);
- if (lancer_chip(adapter))
+ if (adapter->generation == BE_GEN3 || lancer_chip(adapter))
req->hdr.version = 1;
be_wrb_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
@@ -1257,10 +1267,13 @@ int be_cmd_link_status_query(struct be_adapter *adapter, u8 *mac_speed,
if (!status) {
struct be_cmd_resp_link_status *resp = embedded_payload(wrb);
if (resp->mac_speed != PHY_LINK_SPEED_ZERO) {
- *link_speed = le16_to_cpu(resp->link_speed);
+ if (link_speed)
+ *link_speed = le16_to_cpu(resp->link_speed);
if (mac_speed)
*mac_speed = resp->mac_speed;
}
+ if (link_status)
+ *link_status = resp->logical_link_status;
}
err:
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 0b694c6..dca8924 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -960,7 +960,8 @@ struct be_cmd_resp_link_status {
u8 mgmt_mac_duplex;
u8 mgmt_mac_speed;
u16 link_speed;
- u32 rsvd0;
+ u8 logical_link_status;
+ u8 rsvd1[3];
} __packed;
/******************** Port Identification ***************************/
@@ -1507,8 +1508,8 @@ extern int be_cmd_q_destroy(struct be_adapter *adapter, struct be_queue_info *q,
int type);
extern int be_cmd_rxq_destroy(struct be_adapter *adapter,
struct be_queue_info *q);
-extern int be_cmd_link_status_query(struct be_adapter *adapter,
- u8 *mac_speed, u16 *link_speed, u32 dom);
+extern int be_cmd_link_status_query(struct be_adapter *adapter, u8 *mac_speed,
+ u16 *link_speed, u8 *link_status, u32 dom);
extern int be_cmd_reset(struct be_adapter *adapter);
extern int be_cmd_get_stats(struct be_adapter *adapter,
struct be_dma_mem *nonemb_cmd);
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 6ba2dc6..6db6b6a 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -429,11 +429,14 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
struct be_phy_info phy_info;
u8 mac_speed = 0;
u16 link_speed = 0;
+ u8 link_status;
int status;
if ((adapter->link_speed < 0) || (!(netdev->flags & IFF_UP))) {
status = be_cmd_link_status_query(adapter, &mac_speed,
- &link_speed, 0);
+ &link_speed, &link_status, 0);
+ if (!status)
+ be_link_status_update(adapter, link_status);
/* link_speed is in units of 10 Mbps */
if (link_speed) {
@@ -700,7 +703,7 @@ be_self_test(struct net_device *netdev, struct ethtool_test *test, u64 *data)
}
if (be_cmd_link_status_query(adapter, &mac_speed,
- &qos_link_speed, 0) != 0) {
+ &qos_link_speed, NULL, 0) != 0) {
test->flags |= ETH_TEST_FL_FAILED;
data[4] = -1;
} else if (!mac_speed) {
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index fe702c1..6c46753 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -496,19 +496,19 @@ static struct rtnl_link_stats64 *be_get_stats64(struct net_device *netdev,
return stats;
}
-void be_link_status_update(struct be_adapter *adapter, u32 link_status)
+void be_link_status_update(struct be_adapter *adapter, u8 link_status)
{
struct net_device *netdev = adapter->netdev;
- /* when link status changes, link speed must be re-queried from card */
- adapter->link_speed = -1;
- if ((link_status & LINK_STATUS_MASK) == LINK_UP) {
- netif_carrier_on(netdev);
- dev_info(&adapter->pdev->dev, "%s: Link up\n", netdev->name);
- } else {
+ if (!(adapter->flags & BE_FLAGS_LINK_STATUS_INIT)) {
netif_carrier_off(netdev);
- dev_info(&adapter->pdev->dev, "%s: Link down\n", netdev->name);
+ adapter->flags |= BE_FLAGS_LINK_STATUS_INIT;
}
+
+ if ((link_status & LINK_STATUS_MASK) == LINK_UP)
+ netif_carrier_on(netdev);
+ else
+ netif_carrier_off(netdev);
}
static void be_tx_stats_update(struct be_tx_obj *txo,
@@ -2414,6 +2414,7 @@ static int be_open(struct net_device *netdev)
struct be_adapter *adapter = netdev_priv(netdev);
struct be_eq_obj *tx_eq = &adapter->tx_eq;
struct be_rx_obj *rxo;
+ u8 link_status;
int status, i;
status = be_rx_queues_setup(adapter);
@@ -2437,6 +2438,11 @@ static int be_open(struct net_device *netdev)
/* Now that interrupts are on we can process async mcc */
be_async_mcc_enable(adapter);
+ status = be_cmd_link_status_query(adapter, NULL, NULL,
+ &link_status, 0);
+ if (!status)
+ be_link_status_update(adapter, link_status);
+
return 0;
err:
be_close(adapter->netdev);
@@ -2584,7 +2590,7 @@ static int be_vf_setup(struct be_adapter *adapter)
for_all_vfs(adapter, vf_cfg, vf) {
status = be_cmd_link_status_query(adapter, NULL, &lnk_speed,
- vf + 1);
+ NULL, vf + 1);
if (status)
goto err;
vf_cfg->tx_rate = lnk_speed * 10;
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next 2/3] be2net: fix range check for set_qos for a VF
From: Ajit Khaparde @ 2011-12-30 22:15 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 10f2313..fe702c1 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -978,18 +978,22 @@ static int be_set_vf_tx_rate(struct net_device *netdev,
if (!sriov_enabled(adapter))
return -EPERM;
- if (vf >= adapter->num_vfs || rate < 0)
+ if (vf >= adapter->num_vfs)
return -EINVAL;
- if (rate > 10000)
- rate = 10000;
+ if (rate < 100 || rate > 10000) {
+ dev_err(&adapter->pdev->dev,
+ "tx rate must be between 100 and 10000 Mbps\n");
+ return -EINVAL;
+ }
- adapter->vf_cfg[vf].tx_rate = rate;
status = be_cmd_set_qos(adapter, rate / 10, vf + 1);
if (status)
- dev_info(&adapter->pdev->dev,
+ dev_err(&adapter->pdev->dev,
"tx rate %d on VF %d failed\n", rate, vf);
+ else
+ adapter->vf_cfg[vf].tx_rate = rate;
return status;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next 1/3] be2net: fix be_vlan_add/rem_vid
From: Ajit Khaparde @ 2011-12-30 22:15 UTC (permalink / raw)
To: davem; +Cc: netdev
1) fix be_vlan_add/rem_vid to return proper status
2) perform appropriate housekeeping if firmware command succeeds.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 35 ++++++++++++++++++--------
1 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 76f3a98..10f2313 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -817,32 +817,45 @@ static int be_vid_config(struct be_adapter *adapter, bool vf, u32 vf_num)
static int be_vlan_add_vid(struct net_device *netdev, u16 vid)
{
struct be_adapter *adapter = netdev_priv(netdev);
+ int status = 0;
- adapter->vlans_added++;
- if (!be_physfn(adapter))
- return 0;
+ if (!be_physfn(adapter)) {
+ status = -EINVAL;
+ goto ret;
+ }
adapter->vlan_tag[vid] = 1;
if (adapter->vlans_added <= (adapter->max_vlans + 1))
- be_vid_config(adapter, false, 0);
+ status = be_vid_config(adapter, false, 0);
- return 0;
+ if (!status)
+ adapter->vlans_added++;
+ else
+ adapter->vlan_tag[vid] = 0;
+ret:
+ return status;
}
static int be_vlan_rem_vid(struct net_device *netdev, u16 vid)
{
struct be_adapter *adapter = netdev_priv(netdev);
+ int status = 0;
- adapter->vlans_added--;
-
- if (!be_physfn(adapter))
- return 0;
+ if (!be_physfn(adapter)) {
+ status = -EINVAL;
+ goto ret;
+ }
adapter->vlan_tag[vid] = 0;
if (adapter->vlans_added <= adapter->max_vlans)
- be_vid_config(adapter, false, 0);
+ status = be_vid_config(adapter, false, 0);
- return 0;
+ if (!status)
+ adapter->vlans_added--;
+ else
+ adapter->vlan_tag[vid] = 1;
+ret:
+ return status;
}
static void be_set_rx_mode(struct net_device *netdev)
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next 0/3] be2net: Patch series
From: Ajit Khaparde @ 2011-12-30 22:14 UTC (permalink / raw)
To: davem; +Cc: netdev
[1/3] be2net: fix be_vlan_add/rem_vid
[2/3] be2net: fix range check for set_qos for a VF
[3/3] be2net: query link status in be_open()
Please apply.
Thanks
-Ajit
^ permalink raw reply
* Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.
From: Bjarke Istrup Pedersen @ 2011-12-30 22:13 UTC (permalink / raw)
To: Francois Romieu
Cc: David Miller, shemminger, bhutchings, linux-kernel, netdev, rl
In-Reply-To: <20111230215024.GA5513@electric-eye.fr.zoreil.com>
2011/12/30 Francois Romieu <romieu@fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
> [...]
>> Just applied it to HEAD of net-next, and got the following compiler warning:
>> drivers/net/ethernet/via/via-rhine.c:2182:13: warning:
>> 'rhine_task_enable' defined but not used
>
> You are running with CONFIG_PM disabled and a down / up loop will not
> work. The patch below should hide the latter, at least as long as the
> relevant workqueue does not stall for too long... Extra cancel_work in
> task_enable could work too but it will look strange.
>
>> Just so you know that too :)
Does not build with patch:
drivers/net/ethernet/via/via-rhine.c: In function 'rhine_open':
drivers/net/ethernet/via/via-rhine.c:1539:2: error: implicit
declaration of function 'rhine_task_enable'
drivers/net/ethernet/via/via-rhine.c: At top level:
drivers/net/ethernet/via/via-rhine.c:2183:13: warning: conflicting
types for 'rhine_task_enable'
drivers/net/ethernet/via/via-rhine.c:2183:13: error: static
declaration of 'rhine_task_enable' follows non-static declaration
drivers/net/ethernet/via/via-rhine.c:1539:2: note: previous implicit
declaration of 'rhine_task_enable' was here
drivers/net/ethernet/via/via-rhine.c:2183:13: warning:
'rhine_task_enable' defined but not used
Wouldn't it be an idea to move the declarations to a via-rhine.h file,
and include it, to work around it, and seperate it like it should be?
/Bjarke
> Thanks for testing.
>
> diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
> index c57e1da..89ced1b 100644
> --- a/drivers/net/ethernet/via/via-rhine.c
> +++ b/drivers/net/ethernet/via/via-rhine.c
> @@ -1536,6 +1536,7 @@ static int rhine_open(struct net_device *dev)
> alloc_rbufs(dev);
> alloc_tbufs(dev);
> rhine_chip_reset(dev);
> + rhine_task_enable(rp);
> init_registers(dev);
> if (debug > 2)
> netdev_dbg(dev, "%s() Done - status %04x MII status: %04x\n",
> --
> Ueimor
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH net-next] netem: fix classful handling
From: David Miller @ 2011-12-30 22:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, dave.taht, jsullivan, netdev
In-Reply-To: <1325149922.2607.33.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Dec 2011 10:12:02 +0100
> [PATCH v2 net-next] netem: fix classful handling
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH RFC] IPv6: Avoid taking write lock for /proc/net/ipv6_route
From: David Miller @ 2011-12-30 22:09 UTC (permalink / raw)
To: joshhunt00; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <CAKA=qzbZ4x5u1bBM0gAECeMNutyaVzp1FmRPwKHsBEEs7984ag@mail.gmail.com>
From: Josh Hunt <joshhunt00@gmail.com>
Date: Wed, 28 Dec 2011 17:23:07 -0600
> lock_stat shows taking the write lock is causing the slowdown. Using
> this info I decided to write a version of fib6_clean_all() which
> replaces write_lock_bh(&table->tb6_lock) with
> read_lock_bh(&table->tb6_lock). With this new function I see the same
> results as with my rtnetlink iperf test. I guess my question is what
> am I missing? Is there a reason you need to take the write lock when
> reading the route table to display to proc?
You're not missing anything, it's just an oversight or laziness. :-)
I've applied your patch thanks.
Longer term we should make the ipv6 tree traversals RCU safe just
like net/ipv4/fib_trie.c is. Then we can do away with even the
read locks for read-only traversals.
^ permalink raw reply
* Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.
From: Francois Romieu @ 2011-12-30 22:08 UTC (permalink / raw)
To: Bjarke Istrup Pedersen
Cc: David Miller, shemminger, bhutchings, linux-kernel, netdev, rl
In-Reply-To: <CACPM=kUGEqNnVz+-Re0smWgVmZPJfTDWFbbAQp04JAK5E5=PNw@mail.gmail.com>
Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
[...]
> Applied the patch, testing later :)
> You are saying that with CONFIG_PM disabled, I wont be able to bring
> the interface down and up again?
No. You would not see the message with CONFIG_PM but the down / up problem
would still be there. The patch should fix the down / up problem.
/away
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.
From: Bjarke Istrup Pedersen @ 2011-12-30 22:08 UTC (permalink / raw)
To: Francois Romieu
Cc: David Miller, shemminger, bhutchings, linux-kernel, netdev, rl
In-Reply-To: <20111230215024.GA5513@electric-eye.fr.zoreil.com>
2011/12/30 Francois Romieu <romieu@fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
> [...]
>> Just applied it to HEAD of net-next, and got the following compiler warning:
>> drivers/net/ethernet/via/via-rhine.c:2182:13: warning:
>> 'rhine_task_enable' defined but not used
>
> You are running with CONFIG_PM disabled and a down / up loop will not
> work. The patch below should hide the latter, at least as long as the
> relevant workqueue does not stall for too long... Extra cancel_work in
> task_enable could work too but it will look strange.
Applied the patch, testing later :)
You are saying that with CONFIG_PM disabled, I wont be able to bring
the interface down and up again?
>> Just so you know that too :)
>
> Thanks for testing.
>
> diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
> index c57e1da..89ced1b 100644
> --- a/drivers/net/ethernet/via/via-rhine.c
> +++ b/drivers/net/ethernet/via/via-rhine.c
> @@ -1536,6 +1536,7 @@ static int rhine_open(struct net_device *dev)
> alloc_rbufs(dev);
> alloc_tbufs(dev);
> rhine_chip_reset(dev);
> + rhine_task_enable(rp);
> init_registers(dev);
> if (debug > 2)
> netdev_dbg(dev, "%s() Done - status %04x MII status: %04x\n",
> --
> Ueimor
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.
From: Francois Romieu @ 2011-12-30 21:50 UTC (permalink / raw)
To: Bjarke Istrup Pedersen
Cc: David Miller, shemminger, bhutchings, linux-kernel, netdev, rl
In-Reply-To: <CACPM=kXWXUE+JcVhkz-6tGZ2YyteN9sGA80+Pnw6+LaJ-eNWBA@mail.gmail.com>
Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
[...]
> Just applied it to HEAD of net-next, and got the following compiler warning:
> drivers/net/ethernet/via/via-rhine.c:2182:13: warning:
> 'rhine_task_enable' defined but not used
You are running with CONFIG_PM disabled and a down / up loop will not
work. The patch below should hide the latter, at least as long as the
relevant workqueue does not stall for too long... Extra cancel_work in
task_enable could work too but it will look strange.
> Just so you know that too :)
Thanks for testing.
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index c57e1da..89ced1b 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -1536,6 +1536,7 @@ static int rhine_open(struct net_device *dev)
alloc_rbufs(dev);
alloc_tbufs(dev);
rhine_chip_reset(dev);
+ rhine_task_enable(rp);
init_registers(dev);
if (debug > 2)
netdev_dbg(dev, "%s() Done - status %04x MII status: %04x\n",
--
Ueimor
^ permalink raw reply related
* Re: [PATCH 7/7] unix_diag: Fixup RQLEN extension report
From: David Miller @ 2011-12-30 21:47 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <4EFD986F.4030808@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Fri, 30 Dec 2011 14:54:39 +0400
> While it's not too late fix the recently added RQLEN diag extension
> to report rqlen and wqlen in the same way as TCP does.
>
> I.e. for listening sockets the ack backlog length (which is the input
> queue length for socket) in rqlen and the max ack backlog length in
> wqlen, and what the CINQ/OUTQ ioctls do for established.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Applied.
^ 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