* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix buildwarnings
From: Marc Kleine-Budde @ 2010-10-27 11:58 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
morinaga526-ECg8zkTtlr0C6LszWs/t0g, David Miller,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CC813B9.3080506-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1048 bytes --]
On 10/27/2010 01:57 PM, Wolfgang Grandegger wrote:
> On 10/27/2010 01:27 PM, Tomoya MORINAGA wrote:
>> On Wednesday, October 27, 2010 3:52 AM : Marc Kleine-Budde and Wolfgang Grandegge wrote:
>>
>> The following is some inarticulate points I have for your questions.
>> Please give me more information.
>>
>>> Do I understand your code correctly? You have a big loop, but only do
>>> two different things at certain values of the loop? Smells fishy.
>> Uh, I can't understand your intention.
>> Please show in detail.
>> This processing does configuration for all message objects.
>
> Not all, but just a few of them. We believe it can be implemented more
> efficiently.
I misread the code...sorry - I'm just writing a longer answer.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix buildwarnings
From: Wolfgang Grandegger @ 2010-10-27 11:57 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, Marc Kleine-Budde,
chripell-VaTbYqLCNhc, morinaga526-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, David Miller,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <008201cb75c9$f27ff720$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
On 10/27/2010 01:27 PM, Tomoya MORINAGA wrote:
> On Wednesday, October 27, 2010 3:52 AM : Marc Kleine-Budde and Wolfgang Grandegge wrote:
>
> The following is some inarticulate points I have for your questions.
> Please give me more information.
>
>> Do I understand your code correctly? You have a big loop, but only do
>> two different things at certain values of the loop? Smells fishy.
> Uh, I can't understand your intention.
> Please show in detail.
> This processing does configuration for all message objects.
Not all, but just a few of them. We believe it can be implemented more
efficiently.
>
>> what does this loop do? why is it nessecarry? I don't like delay loops
>> in the hot path of a driver.
> This loop is for waiting for all tx Message Object completion.
> This is Topcliff CAN HW specification.
What do you mean with "tx Message Object completion"? Is TX done not
signaled via interrupt? Please explain why you need to wait multiples of
500us here in the hot TX path.
>> If you figured out how to use the endianess conversion functions from
>> the cpu_to_{le,be}-{le,to}_to_cpup family use them here, too.
> Uh,le32_to_cpu have been used already here.
> I can't understand your intention.
> Please show in detail.
>
>
>>> All these check if busy in the code make me a bit nervous, can you
>>> please explain why they are needed. A pointer to the manual is okay, too.
>> Me too. I already ask in my previous mail how long that functions
>> usually blocks.
> When accessing read/write from/to Message RAM,
> Since it takes much time for transferring between Register and Message RAM,
Much time means how many mirco-seconds?
> SW must check busy flag of CAN register.
> This is a Topcliff HW specification.
Maybe the busy check could also be done *before* the Message RAM is
accessed to avoid (or minimize) waiting.
>> is there some pdev->name instead of KBUILD_MODNAME that can be used?
> I can't understand your intention.
> pdev(struct pci_dev) doesn't have "name" member.
> Please show in detail.
Using KBUILD_MODNAME is OK. It does hold the name of the driver as required.
Wolfgang.
^ permalink raw reply
* [PATCH] NET: sunrpc, remove unneeded NULL tests
From: Jiri Slaby @ 2010-10-27 11:52 UTC (permalink / raw)
To: bfields; +Cc: davem, netdev, linux-kernel, jirislaby, Neil Brown, linux-nfs
Stanse found that req in xprt_reserve_xprt is dereferenced prior its
test to NULL. If that's the case, the checks are unnecessary, so
remove them.
The alternative is not to dereference it before the test. The patch
is to point out the problem, you have to decide.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>
Cc: linux-nfs@vger.kernel.org
---
net/sunrpc/xprt.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 4c8f18a..5355c71 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -202,10 +202,8 @@ int xprt_reserve_xprt(struct rpc_task *task)
goto out_sleep;
}
xprt->snd_task = task;
- if (req) {
- req->rq_bytes_sent = 0;
- req->rq_ntrans++;
- }
+ req->rq_bytes_sent = 0;
+ req->rq_ntrans++;
return 1;
out_sleep:
@@ -213,7 +211,7 @@ out_sleep:
task->tk_pid, xprt);
task->tk_timeout = 0;
task->tk_status = -EAGAIN;
- if (req && req->rq_ntrans)
+ if (req->rq_ntrans)
rpc_sleep_on(&xprt->resend, task, NULL);
else
rpc_sleep_on(&xprt->sending, task, NULL);
--
1.7.3.1
^ permalink raw reply related
* Re: can: About Socket CAN with MSI issue
From: Tomoya MORINAGA @ 2010-10-27 11:41 UTC (permalink / raw)
To: Dave Airlie
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, David Miller,
chripell-VaTbYqLCNhc, qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <AANLkTi=bJTMhEo2agsMJ8fptNp7suERCGkzybb5m7ggg@mail.gmail.com>
On Wednesday, October 27, 2010 4:56 PM, Dave Airlie wrote:
> Its a bug in the PCI layer most likely,
Thank you for your information.
This issue occurrs with Socket-CAN driver only.
Previous version our CAN driver(Not Socket-CAN but Tolapai ) works well.
Thus, IMHO, PCI layer doesn't related to the issue.
Thanks, Tomoya(OKI SEMICONDUCTOR CO., LTD.)
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix buildwarnings
From: Tomoya MORINAGA @ 2010-10-27 11:27 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: andrew.chih.howe.khor, socketcan-core, sameo, margie.foster,
netdev, linux-kernel, yong.y.wang, masa-korg, kok.howg.ewe,
chripell, morinaga526, David Miller, joel.clark, qi.wang
In-Reply-To: <4CC72360.1070608@pengutronix.de>
On Wednesday, October 27, 2010 3:52 AM : Marc Kleine-Budde and Wolfgang Grandegge wrote:
The following is some inarticulate points I have for your questions.
Please give me more information.
> Do I understand your code correctly? You have a big loop, but only do
> two different things at certain values of the loop? Smells fishy.
Uh, I can't understand your intention.
Please show in detail.
This processing does configuration for all message objects.
> what does this loop do? why is it nessecarry? I don't like delay loops
> in the hot path of a driver.
This loop is for waiting for all tx Message Object completion.
This is Topcliff CAN HW specification.
> If you figured out how to use the endianess conversion functions from
> the cpu_to_{le,be}-{le,to}_to_cpup family use them here, too.
Uh,le32_to_cpu have been used already here.
I can't understand your intention.
Please show in detail.
>> All these check if busy in the code make me a bit nervous, can you
>> please explain why they are needed. A pointer to the manual is okay, too.
> Me too. I already ask in my previous mail how long that functions
> usually blocks.
When accessing read/write from/to Message RAM,
Since it takes much time for transferring between Register and Message RAM,
SW must check busy flag of CAN register.
This is a Topcliff HW specification.
> is there some pdev->name instead of KBUILD_MODNAME that can be used?
I can't understand your intention.
pdev(struct pci_dev) doesn't have "name" member.
Please show in detail.
Thanks, Tomoya(OKI SEMICONDUCTOR CO., LTD.)
^ permalink raw reply
* [BUG net-2.6 vlan/bonding] lockdep splats
From: Eric Dumazet @ 2010-10-27 10:24 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Jesse Gross, Jarek Poplawski
On latest net-2.6 kernel I got following splat, not sure its related to
vlan changes...
[ 51.402912] tg3 0000:14:04.0: eth2: Link is up at 1000 Mbps, full duplex
[ 51.402915] tg3 0000:14:04.0: eth2: Flow control is off for TX and off for RX
[ 51.402993] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 52.277993] bonding: bond0: Setting MII monitoring interval to 100.
[ 52.278233] bonding: bond0: setting mode to active-backup (1).
[ 52.280125] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 52.280127] 8021q: adding VLAN 0 to HW filter on device bond0
[ 52.526629] bnx2 0000:07:00.0: irq 42 for MSI/MSI-X
[ 52.652352] bnx2 0000:07:00.0: eth1: using MSI
[ 52.652542] bonding: bond0: enslaving eth1 as a backup interface with a down link.
[ 52.930032] tg3 0000:14:04.0: BAR 0: set to [mem 0xfdff0000-0xfdffffff 64bit] (PCI address [0xfdff0000-0xfdffffff]
[ 52.930045] tg3 0000:14:04.0: BAR 2: set to [mem 0xfdfe0000-0xfdfeffff 64bit] (PCI address [0xfdfe0000-0xfdfeffff]
[ 52.930134] tg3 0000:14:04.0: irq 43 for MSI/MSI-X
[ 52.959296] bonding: bond0: enslaving eth2 as a backup interface with a down link.
[ 52.991401]
[ 52.991402] ======================================================
[ 52.991511] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
[ 52.991569] 2.6.36-04573-g4b60626-dirty #65
[ 52.991622] ------------------------------------------------------
[ 52.991696] ip/4842 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:
[ 52.991758] (&bond->lock){++++..}, at: [<efe4d300>] bond_set_multicast_list+0x60/0x2c0 [bonding]
[ 52.991966]
[ 52.991967] and this task is already holding:
[ 52.992008] (&bonding_netdev_addr_lock_key){+.....}, at: [<c04e5530>] dev_mc_sync+0x50/0xa0
[ 52.992008] which would create a new lock dependency:
[ 52.992008] (&bonding_netdev_addr_lock_key){+.....} -> (&bond->lock){++++..}
[ 52.992008]
[ 52.992008] but this new dependency connects a SOFTIRQ-irq-safe lock:
[ 52.992008] (&(&mc->mca_lock)->rlock){+.-...}
[ 52.992008] ... which became SOFTIRQ-irq-safe at:
[ 52.992008] [<c0272beb>] __lock_acquire+0x96b/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
[ 52.992008] [<c0584e40>] mld_ifc_timer_expire+0xf0/0x280
[ 52.992008] [<c024cee6>] run_timer_softirq+0x146/0x310
[ 52.992008] [<c024591d>] __do_softirq+0xad/0x1c0
[ 52.992008]
[ 52.992008] to a SOFTIRQ-irq-unsafe lock:
[ 52.992008] (&bond->lock){++++..}
[ 52.992008] ... which became SOFTIRQ-irq-unsafe at:
[ 52.992008] ... [<c0272c3b>] __lock_acquire+0x9bb/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f36b8>] _raw_write_lock+0x38/0x50
[ 52.992008] [<efe4cbe4>] bond_vlan_rx_register+0x24/0x70 [bonding]
[ 52.992008] [<c0598010>] register_vlan_dev+0xc0/0x280
[ 52.992008] [<c0599f3a>] vlan_newlink+0xaa/0xd0
[ 52.992008] [<c04ed4b4>] rtnl_newlink+0x404/0x490
[ 52.992008] [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220
[ 52.992008] [<c050424e>] netlink_rcv_skb+0x8e/0xb0
[ 52.992008] [<c04ecbac>] rtnetlink_rcv+0x1c/0x30
[ 52.992008] [<c0503bfb>] netlink_unicast+0x24b/0x290
[ 52.992008] [<c0503e37>] netlink_sendmsg+0x1f7/0x310
[ 52.992008] [<c04cd41c>] sock_sendmsg+0xac/0xe0
[ 52.992008] [<c04ceb80>] sys_sendmsg+0x130/0x230
[ 52.992008] [<c04cf04e>] sys_socketcall+0xde/0x280
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008]
[ 52.992008] other info that might help us debug this:
[ 52.992008]
[ 52.992008] 3 locks held by ip/4842:
[ 52.992008] #0: (rtnl_mutex){+.+.+.}, at: [<c04ecb84>] rtnl_lock+0x14/0x20
[ 52.992008] #1: (&vlan_netdev_addr_lock_key){+.....}, at: [<c04e1181>] dev_set_rx_mode+0x21/0x40
[ 52.992008] #2: (&bonding_netdev_addr_lock_key){+.....}, at: [<c04e5530>] dev_mc_sync+0x50/0xa0
[ 52.992008]
[ 52.992008] the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
[ 52.992008] -> (&(&mc->mca_lock)->rlock){+.-...} ops: 44 {
[ 52.992008] HARDIRQ-ON-W at:
[ 52.992008] [<c0272c0f>] __lock_acquire+0x98f/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
[ 52.992008] [<c05856a8>] igmp6_group_added+0x28/0x140
[ 52.992008] [<c058618c>] ipv6_dev_mc_inc+0x26c/0x460
[ 52.992008] [<c056d754>] ipv6_add_dev+0x204/0x320
[ 52.992008] [<c082d80c>] addrconf_init+0x4b/0x153
[ 52.992008] [<c082d5ce>] inet6_init+0x17b/0x282
[ 52.992008] [<c0201125>] do_one_initcall+0x35/0x170
[ 52.992008] [<c08018ea>] kernel_init+0x113/0x1ae
[ 52.992008] [<c020323a>] kernel_thread_helper+0x6/0x10
[ 52.992008] IN-SOFTIRQ-W at:
[ 52.992008] [<c0272beb>] __lock_acquire+0x96b/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
[ 52.992008] [<c0584e40>] mld_ifc_timer_expire+0xf0/0x280
[ 52.992008] [<c024cee6>] run_timer_softirq+0x146/0x310
[ 52.992008] [<c024591d>] __do_softirq+0xad/0x1c0
[ 52.992008] INITIAL USE at:
[ 52.992008] [<c0272534>] __lock_acquire+0x2b4/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
[ 52.992008] [<c05856a8>] igmp6_group_added+0x28/0x140
[ 52.992008] [<c058618c>] ipv6_dev_mc_inc+0x26c/0x460
[ 52.992008] [<c056d754>] ipv6_add_dev+0x204/0x320
[ 52.992008] [<c082d80c>] addrconf_init+0x4b/0x153
[ 52.992008] [<c082d5ce>] inet6_init+0x17b/0x282
[ 52.992008] [<c0201125>] do_one_initcall+0x35/0x170
[ 52.992008] [<c08018ea>] kernel_init+0x113/0x1ae
[ 52.992008] [<c020323a>] kernel_thread_helper+0x6/0x10
[ 52.992008] }
[ 52.992008] ... key at: [<c0e5c2d8>] __key.36358+0x0/0x8
[ 52.992008] ... acquired at:
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
[ 52.992008] [<c04e5328>] __dev_mc_add+0x28/0x70
[ 52.992008] [<c04e539f>] dev_mc_add+0xf/0x20
[ 52.992008] [<c058572f>] igmp6_group_added+0xaf/0x140
[ 52.992008] [<c058618c>] ipv6_dev_mc_inc+0x26c/0x460
[ 52.992008] [<c056d754>] ipv6_add_dev+0x204/0x320
[ 52.992008] [<c0571274>] addrconf_notify+0x214/0x890
[ 52.992008] [<c02623d8>] notifier_call_chain+0x48/0x60
[ 52.992008] [<c02624cf>] raw_notifier_call_chain+0x1f/0x30
[ 52.992008] [<c04df63c>] call_netdevice_notifiers+0x2c/0x60
[ 52.992008] [<c04dffe7>] register_netdevice+0x3f7/0x4c0
[ 52.992008] [<efe52a27>] bond_create+0x97/0xd0 [bonding]
[ 52.992008] [<efc5593c>] 0xefc5593c
[ 52.992008] [<c0201125>] do_one_initcall+0x35/0x170
[ 52.992008] [<c027d5f4>] sys_init_module+0x124/0x1aa0
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008]
[ 52.992008] -> (&bonding_netdev_addr_lock_key){+.....} ops: 7 {
[ 52.992008] HARDIRQ-ON-W at:
[ 52.992008] [<c0272c0f>] __lock_acquire+0x98f/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
[ 52.992008] [<c04e5328>] __dev_mc_add+0x28/0x70
[ 52.992008] [<c04e539f>] dev_mc_add+0xf/0x20
[ 52.992008] [<c058572f>] igmp6_group_added+0xaf/0x140
[ 52.992008] [<c058618c>] ipv6_dev_mc_inc+0x26c/0x460
[ 52.992008] [<c056d754>] ipv6_add_dev+0x204/0x320
[ 52.992008] [<c0571274>] addrconf_notify+0x214/0x890
[ 52.992008] [<c02623d8>] notifier_call_chain+0x48/0x60
[ 52.992008] [<c02624cf>] raw_notifier_call_chain+0x1f/0x30
[ 52.992008] [<c04df63c>] call_netdevice_notifiers+0x2c/0x60
[ 52.992008] [<c04dffe7>] register_netdevice+0x3f7/0x4c0
[ 52.992008] [<efe52a27>] bond_create+0x97/0xd0 [bonding]
[ 52.992008] [<efc5593c>] 0xefc5593c
[ 52.992008] [<c0201125>] do_one_initcall+0x35/0x170
[ 52.992008] [<c027d5f4>] sys_init_module+0x124/0x1aa0
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008] INITIAL USE at:
[ 52.992008] [<c0272534>] __lock_acquire+0x2b4/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
[ 52.992008] [<c04e5328>] __dev_mc_add+0x28/0x70
[ 52.992008] [<c04e539f>] dev_mc_add+0xf/0x20
[ 52.992008] [<c058572f>] igmp6_group_added+0xaf/0x140
[ 52.992008] [<c058618c>] ipv6_dev_mc_inc+0x26c/0x460
[ 52.992008] [<c056d754>] ipv6_add_dev+0x204/0x320
[ 52.992008] [<c0571274>] addrconf_notify+0x214/0x890
[ 52.992008] [<c02623d8>] notifier_call_chain+0x48/0x60
[ 52.992008] [<c02624cf>] raw_notifier_call_chain+0x1f/0x30
[ 52.992008] [<c04df63c>] call_netdevice_notifiers+0x2c/0x60
[ 52.992008] [<c04dffe7>] register_netdevice+0x3f7/0x4c0
[ 52.992008] [<efe52a27>] bond_create+0x97/0xd0 [bonding]
[ 52.992008] [<efc5593c>] 0xefc5593c
[ 52.992008] [<c0201125>] do_one_initcall+0x35/0x170
[ 52.992008] [<c027d5f4>] sys_init_module+0x124/0x1aa0
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008] }
[ 52.992008] ... key at: [<efe5fecd>] bonding_netdev_addr_lock_key+0x0/0xffffaa0a [bonding]
[ 52.992008] ... acquired at:
[ 52.992008] [<c0270994>] check_irq_usage+0x54/0xe0
[ 52.992008] [<c02730a7>] __lock_acquire+0xe27/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f3958>] _raw_read_lock+0x38/0x50
[ 52.992008] [<efe4d300>] bond_set_multicast_list+0x60/0x2c0 [bonding]
[ 52.992008] [<c04e10f5>] __dev_set_rx_mode+0x35/0xa0
[ 52.992008] [<c04e556f>] dev_mc_sync+0x8f/0xa0
[ 52.992008] [<c0598b84>] vlan_dev_set_rx_mode+0x24/0x40
[ 52.992008] [<c04e10f5>] __dev_set_rx_mode+0x35/0xa0
[ 52.992008] [<c04e1188>] dev_set_rx_mode+0x28/0x40
[ 52.992008] [<c04e1255>] __dev_open+0xb5/0xf0
[ 52.992008] [<c04e14b4>] __dev_change_flags+0x84/0x160
[ 52.992008] [<c04e1633>] dev_change_flags+0x23/0x60
[ 52.992008] [<c04ebfb0>] do_setlink+0x170/0x700
[ 52.992008] [<c04ed425>] rtnl_newlink+0x375/0x490
[ 52.992008] [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220
[ 52.992008] [<c050424e>] netlink_rcv_skb+0x8e/0xb0
[ 52.992008] [<c04ecbac>] rtnetlink_rcv+0x1c/0x30
[ 52.992008] [<c0503bfb>] netlink_unicast+0x24b/0x290
[ 52.992008] [<c0503e37>] netlink_sendmsg+0x1f7/0x310
[ 52.992008] [<c04cd41c>] sock_sendmsg+0xac/0xe0
[ 52.992008] [<c04ceb80>] sys_sendmsg+0x130/0x230
[ 52.992008] [<c04cf04e>] sys_socketcall+0xde/0x280
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008]
[ 52.992008]
[ 52.992008] the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock:
[ 52.992008] -> (&bond->lock){++++..} ops: 55 {
[ 52.992008] HARDIRQ-ON-W at:
[ 52.992008] [<c0272c0f>] __lock_acquire+0x98f/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f35bd>] _raw_write_lock_bh+0x3d/0x50
[ 52.992008] [<efe4cb0a>] bond_vlan_rx_add_vid+0x9a/0x150 [bonding]
[ 52.992008] [<c0597a20>] vlan_device_event+0x90/0x530
[ 52.992008] [<c02623d8>] notifier_call_chain+0x48/0x60
[ 52.992008] [<c02624cf>] raw_notifier_call_chain+0x1f/0x30
[ 52.992008] [<c04df63c>] call_netdevice_notifiers+0x2c/0x60
[ 52.992008] [<c04e15c3>] __dev_notify_flags+0x33/0x80
[ 52.992008] [<c04e164c>] dev_change_flags+0x3c/0x60
[ 52.992008] [<c053e8b1>] devinet_ioctl+0x591/0x6f0
[ 52.992008] [<c053fa32>] inet_ioctl+0xa2/0xd0
[ 52.992008] [<c04cccb8>] sock_ioctl+0x68/0x270
[ 52.992008] [<c02f48be>] do_vfs_ioctl+0x7e/0x5e0
[ 52.992008] [<c02f4e87>] sys_ioctl+0x67/0x80
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008] HARDIRQ-ON-R at:
[ 52.992008] [<c027279e>] __lock_acquire+0x51e/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f385d>] _raw_read_lock_bh+0x3d/0x50
[ 52.992008] [<efe4cd1f>] bond_get_stats+0x3f/0x1d0 [bonding]
[ 52.992008] [<c04dc3b5>] dev_get_stats+0x35/0xb0
[ 52.992008] [<c04eb6db>] rtnl_fill_ifinfo+0x32b/0x830
[ 52.992008] [<c04ecf6a>] rtmsg_ifinfo+0x6a/0xf0
[ 52.992008] [<c04e003c>] register_netdevice+0x44c/0x4c0
[ 52.992008] [<efe52a27>] bond_create+0x97/0xd0 [bonding]
[ 52.992008] [<efc5593c>] 0xefc5593c
[ 52.992008] [<c0201125>] do_one_initcall+0x35/0x170
[ 52.992008] [<c027d5f4>] sys_init_module+0x124/0x1aa0
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008] SOFTIRQ-ON-W at:
[ 52.992008] [<c0272c3b>] __lock_acquire+0x9bb/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f36b8>] _raw_write_lock+0x38/0x50
[ 52.992008] [<efe4cbe4>] bond_vlan_rx_register+0x24/0x70 [bonding]
[ 52.992008] [<c0598010>] register_vlan_dev+0xc0/0x280
[ 52.992008] [<c0599f3a>] vlan_newlink+0xaa/0xd0
[ 52.992008] [<c04ed4b4>] rtnl_newlink+0x404/0x490
[ 52.992008] [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220
[ 52.992008] [<c050424e>] netlink_rcv_skb+0x8e/0xb0
[ 52.992008] [<c04ecbac>] rtnetlink_rcv+0x1c/0x30
[ 52.992008] [<c0503bfb>] netlink_unicast+0x24b/0x290
[ 52.992008] [<c0503e37>] netlink_sendmsg+0x1f7/0x310
[ 52.992008] [<c04cd41c>] sock_sendmsg+0xac/0xe0
[ 52.992008] [<c04ceb80>] sys_sendmsg+0x130/0x230
[ 52.992008] [<c04cf04e>] sys_socketcall+0xde/0x280
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008] SOFTIRQ-ON-R at:
[ 52.992008] [<c0272c3b>] __lock_acquire+0x9bb/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f3958>] _raw_read_lock+0x38/0x50
[ 52.992008] [<efe50664>] bond_mii_monitor+0x24/0x5f0 [bonding]
[ 52.992008] [<c0257d9d>] process_one_work+0x15d/0x420
[ 52.992008] [<c02586d4>] worker_thread+0x134/0x2d0
[ 52.992008] [<c025c564>] kthread+0x74/0x80
[ 52.992008] [<c020323a>] kernel_thread_helper+0x6/0x10
[ 52.992008] INITIAL USE at:
[ 52.992008] [<c0272534>] __lock_acquire+0x2b4/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f385d>] _raw_read_lock_bh+0x3d/0x50
[ 52.992008] [<efe4cd1f>] bond_get_stats+0x3f/0x1d0 [bonding]
[ 52.992008] [<c04dc3b5>] dev_get_stats+0x35/0xb0
[ 52.992008] [<c04eb6db>] rtnl_fill_ifinfo+0x32b/0x830
[ 52.992008] [<c04ecf6a>] rtmsg_ifinfo+0x6a/0xf0
[ 52.992008] [<c04e003c>] register_netdevice+0x44c/0x4c0
[ 52.992008] [<efe52a27>] bond_create+0x97/0xd0 [bonding]
[ 52.992008] [<efc5593c>] 0xefc5593c
[ 52.992008] [<c0201125>] do_one_initcall+0x35/0x170
[ 52.992008] [<c027d5f4>] sys_init_module+0x124/0x1aa0
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008] }
[ 52.992008] ... key at: [<efe5fe5c>] __key.38049+0x0/0xffffaa7b [bonding]
[ 52.992008] ... acquired at:
[ 52.992008] [<c0270994>] check_irq_usage+0x54/0xe0
[ 52.992008] [<c02730a7>] __lock_acquire+0xe27/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<c05f3958>] _raw_read_lock+0x38/0x50
[ 52.992008] [<efe4d300>] bond_set_multicast_list+0x60/0x2c0 [bonding]
[ 52.992008] [<c04e10f5>] __dev_set_rx_mode+0x35/0xa0
[ 52.992008] [<c04e556f>] dev_mc_sync+0x8f/0xa0
[ 52.992008] [<c0598b84>] vlan_dev_set_rx_mode+0x24/0x40
[ 52.992008] [<c04e10f5>] __dev_set_rx_mode+0x35/0xa0
[ 52.992008] [<c04e1188>] dev_set_rx_mode+0x28/0x40
[ 52.992008] [<c04e1255>] __dev_open+0xb5/0xf0
[ 52.992008] [<c04e14b4>] __dev_change_flags+0x84/0x160
[ 52.992008] [<c04e1633>] dev_change_flags+0x23/0x60
[ 52.992008] [<c04ebfb0>] do_setlink+0x170/0x700
[ 52.992008] [<c04ed425>] rtnl_newlink+0x375/0x490
[ 52.992008] [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220
[ 52.992008] [<c050424e>] netlink_rcv_skb+0x8e/0xb0
[ 52.992008] [<c04ecbac>] rtnetlink_rcv+0x1c/0x30
[ 52.992008] [<c0503bfb>] netlink_unicast+0x24b/0x290
[ 52.992008] [<c0503e37>] netlink_sendmsg+0x1f7/0x310
[ 52.992008] [<c04cd41c>] sock_sendmsg+0xac/0xe0
[ 52.992008] [<c04ceb80>] sys_sendmsg+0x130/0x230
[ 52.992008] [<c04cf04e>] sys_socketcall+0xde/0x280
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 52.992008]
[ 52.992008]
[ 52.992008] stack backtrace:
[ 52.992008] Pid: 4842, comm: ip Not tainted 2.6.36-04573-g4b60626-dirty #65
[ 52.992008] Call Trace:
[ 52.992008] [<c05f00e8>] ? printk+0x1d/0x25
[ 52.992008] [<c02708b3>] check_usage+0x3d3/0x460
[ 52.992008] [<c027a9a0>] ? __module_text_address+0x10/0x60
[ 52.992008] [<c0270994>] check_irq_usage+0x54/0xe0
[ 52.992008] [<c02730a7>] __lock_acquire+0xe27/0x1960
[ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0
[ 52.992008] [<efe4d300>] ? bond_set_multicast_list+0x60/0x2c0 [bonding]
[ 52.992008] [<c05f3958>] _raw_read_lock+0x38/0x50
[ 52.992008] [<efe4d300>] ? bond_set_multicast_list+0x60/0x2c0 [bonding]
[ 52.992008] [<efe4d300>] bond_set_multicast_list+0x60/0x2c0 [bonding]
[ 52.992008] [<c04e10f5>] __dev_set_rx_mode+0x35/0xa0
[ 52.992008] [<c04e556f>] dev_mc_sync+0x8f/0xa0
[ 52.992008] [<c0598b84>] vlan_dev_set_rx_mode+0x24/0x40
[ 52.992008] [<c04e10f5>] __dev_set_rx_mode+0x35/0xa0
[ 52.992008] [<c04e1188>] dev_set_rx_mode+0x28/0x40
[ 52.992008] [<c04e1255>] __dev_open+0xb5/0xf0
[ 52.992008] [<c05f39fa>] ? _raw_spin_unlock_bh+0x2a/0x30
[ 52.992008] [<c04e14b4>] __dev_change_flags+0x84/0x160
[ 52.992008] [<c04e1633>] dev_change_flags+0x23/0x60
[ 52.992008] [<c04ebfb0>] do_setlink+0x170/0x700
[ 52.992008] [<c03a6c5f>] ? nla_parse+0x1f/0xa0
[ 52.992008] [<c04ed425>] rtnl_newlink+0x375/0x490
[ 52.992008] [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220
[ 52.992008] [<c04ecb84>] ? rtnl_lock+0x14/0x20
[ 52.992008] [<c04ed0b0>] ? rtnl_newlink+0x0/0x490
[ 52.992008] [<c04ecc50>] ? rtnetlink_rcv_msg+0x0/0x220
[ 52.992008] [<c050424e>] netlink_rcv_skb+0x8e/0xb0
[ 52.992008] [<c04ecb90>] ? rtnetlink_rcv+0x0/0x30
[ 52.992008] [<c04ecbac>] rtnetlink_rcv+0x1c/0x30
[ 52.992008] [<c0503bfb>] netlink_unicast+0x24b/0x290
[ 52.992008] [<c0503e37>] netlink_sendmsg+0x1f7/0x310
[ 52.992008] [<c04cd41c>] sock_sendmsg+0xac/0xe0
[ 52.992008] [<c0273c6b>] ? lock_release_non_nested+0x8b/0x300
[ 52.992008] [<c02c6cab>] ? might_fault+0x4b/0xa0
[ 52.992008] [<c02c6cab>] ? might_fault+0x4b/0xa0
[ 52.992008] [<c02c6cf1>] ? might_fault+0x91/0xa0
[ 52.992008] [<c039e074>] ? _copy_from_user+0x44/0x70
[ 52.992008] [<c04d74ba>] ? verify_iovec+0x5a/0xa0
[ 52.992008] [<c04ceb80>] sys_sendmsg+0x130/0x230
[ 52.992008] [<c027266c>] ? __lock_acquire+0x3ec/0x1960
[ 52.992008] [<c02c7e23>] ? do_wp_page+0x2a3/0x7d0
[ 52.992008] [<c02c9500>] ? handle_mm_fault+0x1b0/0x7e0
[ 52.992008] [<c0273c6b>] ? lock_release_non_nested+0x8b/0x300
[ 52.992008] [<c02c6cab>] ? might_fault+0x4b/0xa0
[ 52.992008] [<c02c6cab>] ? might_fault+0x4b/0xa0
[ 52.992008] [<c04cf04e>] sys_socketcall+0xde/0x280
[ 52.992008] [<c0202d43>] ? sysenter_exit+0xf/0x18
[ 52.992008] [<c039d938>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36
[ 53.028128] ADDRCONF(NETDEV_UP): vlan.103: link is not ready
[ 53.060760] ADDRCONF(NETDEV_UP): vlan.825: link is not ready
[ 55.326508] warning: `ntpdate' uses 32-bit capabilities (legacy support in use)
[ 55.661812] bnx2 0000:07:00.0: eth1: NIC SerDes Link is Up, 1000 Mbps full duplex
[ 55.680088] bonding: bond0: link status definitely up for interface eth1, 1000 Mbps full duplex.
[ 55.680171] bonding: bond0: making interface eth1 the new active one.
[ 55.680322] bonding: bond0: first active interface up!
[ 55.680470] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 55.680798] ADDRCONF(NETDEV_CHANGE): vlan.103: link becomes ready
[ 55.681169] ADDRCONF(NETDEV_CHANGE): vlan.825: link becomes ready
[ 56.204977] tg3 0000:14:04.0: eth2: Link is up at 1000 Mbps, full duplex
[ 56.205048] tg3 0000:14:04.0: eth2: Flow control is off for TX and off for RX
[ 56.280028] bonding: bond0: link status definitely up for interface eth2, 1000 Mbps full duplex.
[ 59.545392] bonding: bond0: link status definitely down for interface eth1, disabling it
[ 59.545477] bonding: bond0: making interface eth2 the new active one.
[ 61.650007] eth0: no IPv6 routers present
[ 65.891006] vlan.103: no IPv6 routers present
[ 66.339005] vlan.825: no IPv6 routers present
[ 66.354005] bond0: no IPv6 routers present
^ permalink raw reply
* Re: tbf/htb qdisc limitations
From: Jarek Poplawski @ 2010-10-27 9:48 UTC (permalink / raw)
To: Bill Fink; +Cc: Eric Dumazet, Rick Jones, Steven Brudenell, netdev
In-Reply-To: <20101027005143.bfa8fbfd.billfink@mindspring.com>
On Wed, Oct 27, 2010 at 12:51:43AM -0400, Bill Fink wrote:
> On Wed, 20 Oct 2010, Jarek Poplawski wrote:
> > Btw, if you find time I would be interested in checking an opposite
> > concept of lower than real mtu (256) to use rate tables different way
> > (other tbf parameters without change). The patch below is needed for
> > this to work.
>
> Sorry. I'm totally swamped at work currently and won't be able
> to investigate that.
No problem, especially when current solution works for you.
Jarek P.
^ permalink raw reply
* [PATCH] ipv6/udp: report SndbufErrors and RcvbufErrors
From: Eric Dumazet @ 2010-10-27 9:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, stable
In-Reply-To: <1288124842.2652.28.camel@edumazet-laptop>
commit a18135eb9389 (Add UDP_MIB_{SND,RCV}BUFERRORS handling.)
forgot to make the necessary changes in net/ipv6/proc.c to report
additional counters in /proc/net/snmp6
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv6/proc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
index d082eae..24b3558 100644
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -126,6 +126,8 @@ static const struct snmp_mib snmp6_udp6_list[] = {
SNMP_MIB_ITEM("Udp6NoPorts", UDP_MIB_NOPORTS),
SNMP_MIB_ITEM("Udp6InErrors", UDP_MIB_INERRORS),
SNMP_MIB_ITEM("Udp6OutDatagrams", UDP_MIB_OUTDATAGRAMS),
+ SNMP_MIB_ITEM("Udp6RcvbufErrors", UDP_MIB_RCVBUFERRORS),
+ SNMP_MIB_ITEM("Udp6SndbufErrors", UDP_MIB_SNDBUFERRORS),
SNMP_MIB_SENTINEL
};
@@ -134,6 +136,8 @@ static const struct snmp_mib snmp6_udplite6_list[] = {
SNMP_MIB_ITEM("UdpLite6NoPorts", UDP_MIB_NOPORTS),
SNMP_MIB_ITEM("UdpLite6InErrors", UDP_MIB_INERRORS),
SNMP_MIB_ITEM("UdpLite6OutDatagrams", UDP_MIB_OUTDATAGRAMS),
+ SNMP_MIB_ITEM("UdpLite6RcvbufErrors", UDP_MIB_RCVBUFERRORS),
+ SNMP_MIB_ITEM("UdpLite6SndbufErrors", UDP_MIB_SNDBUFERRORS),
SNMP_MIB_SENTINEL
};
^ permalink raw reply related
* [PATCH] conntrack: allow nf_ct_alloc_hashtable() to get highmem pages
From: Eric Dumazet @ 2010-10-27 9:09 UTC (permalink / raw)
To: David Miller, Patrick McHardy
Cc: netdev, Netfilter Development Mailinglist, stable
commit ea781f197d6a8 (use SLAB_DESTROY_BY_RCU and get rid of call_rcu())
did a mistake in __vmalloc() call in nf_ct_alloc_hashtable().
I forgot to add __GFP_HIGHMEM, so pages were taken from LOWMEM only.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/netfilter/nf_conntrack_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 1eacf8d..27a5ea6 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1312,7 +1312,8 @@ void *nf_ct_alloc_hashtable(unsigned int *sizep, int *vmalloced, int nulls)
if (!hash) {
*vmalloced = 1;
printk(KERN_WARNING "nf_conntrack: falling back to vmalloc.\n");
- hash = __vmalloc(sz, GFP_KERNEL | __GFP_ZERO, PAGE_KERNEL);
+ hash = __vmalloc(sz, GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO,
+ PAGE_KERNEL);
}
if (hash && nulls)
^ permalink raw reply related
* [PATCH 1/1] netxen: fix kdump
From: Amit Kumar Salecha @ 2010-10-27 8:51 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Rajesh Borundia
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
Reset the whole hw instead of freeing hw resources
consumed by each pci function.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_ctx.c | 15 ---------------
drivers/net/netxen/netxen_nic_main.c | 7 +++++++
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_ctx.c b/drivers/net/netxen/netxen_nic_ctx.c
index 1261212..f7d06cb 100644
--- a/drivers/net/netxen/netxen_nic_ctx.c
+++ b/drivers/net/netxen/netxen_nic_ctx.c
@@ -255,19 +255,6 @@ out_free_rq:
}
static void
-nx_fw_cmd_reset_ctx(struct netxen_adapter *adapter)
-{
-
- netxen_issue_cmd(adapter, adapter->ahw.pci_func, NXHAL_VERSION,
- adapter->ahw.pci_func, NX_DESTROY_CTX_RESET, 0,
- NX_CDRP_CMD_DESTROY_RX_CTX);
-
- netxen_issue_cmd(adapter, adapter->ahw.pci_func, NXHAL_VERSION,
- adapter->ahw.pci_func, NX_DESTROY_CTX_RESET, 0,
- NX_CDRP_CMD_DESTROY_TX_CTX);
-}
-
-static void
nx_fw_cmd_destroy_rx_ctx(struct netxen_adapter *adapter)
{
struct netxen_recv_context *recv_ctx = &adapter->recv_ctx;
@@ -698,8 +685,6 @@ int netxen_alloc_hw_resources(struct netxen_adapter *adapter)
if (!NX_IS_REVISION_P2(adapter->ahw.revision_id)) {
if (test_and_set_bit(__NX_FW_ATTACHED, &adapter->state))
goto done;
- if (reset_devices)
- nx_fw_cmd_reset_ctx(adapter);
err = nx_fw_cmd_create_rx_ctx(adapter);
if (err)
goto err_out_free;
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 50820be..35ae1aa 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1356,6 +1356,13 @@ netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
break;
}
+ if (reset_devices) {
+ if (adapter->portnum == 0) {
+ NXWR32(adapter, NX_CRB_DEV_REF_COUNT, 0);
+ adapter->need_fw_reset = 1;
+ }
+ }
+
err = netxen_start_firmware(adapter);
if (err)
goto err_out_decr_ref;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/2] can: pch_can: fix sparse warning
From: Marc Kleine-Budde @ 2010-10-27 8:38 UTC (permalink / raw)
To: socketcan-core; +Cc: netdev, Marc Kleine-Budde, Tomoya MORINAGA
In-Reply-To: <1288168706-870-1-git-send-email-mkl@pengutronix.de>
This patch fixes the following sparse warning:
drivers/net/can/pch_can.c:231:26: warning: incorrect type in argument 1 (different address spaces)
drivers/net/can/pch_can.c:231:26: expected unsigned int [usertype] *addr
drivers/net/can/pch_can.c:231:26: got unsigned int [noderef] <asn:2>*<noident>
Let pch_can_bit_{set,clear} first parameter be a void __iomem pointer.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
---
drivers/net/can/pch_can.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 55ec324..c63209f 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -213,12 +213,12 @@ static DEFINE_PCI_DEVICE_TABLE(pch_pci_tbl) = {
};
MODULE_DEVICE_TABLE(pci, pch_pci_tbl);
-static inline void pch_can_bit_set(u32 *addr, u32 mask)
+static inline void pch_can_bit_set(void __iomem *addr, u32 mask)
{
iowrite32(ioread32(addr) | mask, addr);
}
-static inline void pch_can_bit_clear(u32 *addr, u32 mask)
+static inline void pch_can_bit_clear(void __iomem *addr, u32 mask)
{
iowrite32(ioread32(addr) & ~mask, addr);
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] can: pch_can: fix section mismatch warning by using a whitelisted name
From: Marc Kleine-Budde @ 2010-10-27 8:38 UTC (permalink / raw)
To: socketcan-core-0fE9KPoRgkgATYTw5x5z8w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Marc Kleine-Budde
In-Reply-To: <1288168706-870-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
This patch fixes the following section mismatch warning:
WARNING: drivers/net/can/pch_can.o(.data+0x18):
Section mismatch in reference from the variable pch_can_pcidev
to the variable .devinit.rodata:pch_pci_tbl
The variable pch_can_pcidev references
the variable __devinitconst pch_pci_tbl
This is actually a false positive which is fixed by giving the offending
variable a whitelisted name, it's renamed to "pch_can_pci_driver".
This makes sense because the variable is of the type "struct pci_driver".
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
---
drivers/net/can/pch_can.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index c63209f..6727182 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -1437,7 +1437,7 @@ probe_exit_endev:
return rc;
}
-static struct pci_driver pch_can_pcidev = {
+static struct pci_driver pch_can_pci_driver = {
.name = "pch_can",
.id_table = pch_pci_tbl,
.probe = pch_can_probe,
@@ -1448,13 +1448,13 @@ static struct pci_driver pch_can_pcidev = {
static int __init pch_can_pci_init(void)
{
- return pci_register_driver(&pch_can_pcidev);
+ return pci_register_driver(&pch_can_pci_driver);
}
module_init(pch_can_pci_init);
static void __exit pch_can_pci_exit(void)
{
- pci_unregister_driver(&pch_can_pcidev);
+ pci_unregister_driver(&pch_can_pci_driver);
}
module_exit(pch_can_pci_exit);
--
1.7.2.3
_______________________________________________
Socketcan-core mailing list
Socketcan-core@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply related
* [PATCH 0/2] can: pch_can: fix sparse warnings and section mismatch
From: Marc Kleine-Budde @ 2010-10-27 8:38 UTC (permalink / raw)
To: socketcan-core-0fE9KPoRgkgATYTw5x5z8w; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA
Hello,
this patch fixes two problems found during compile time, a sparse warning
and a section mismatch.
These patches apply to net-2.6/master
cheers, Marc
---
The following changes since commit 7a876b0efcba3804da3051313445fa7be751cab7:
IPv6: Temp addresses are immediately deleted. (2010-10-26 12:35:13 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/mkl/linux-2.6.git can/pch_can-for-net-2.6
Marc Kleine-Budde (2):
can: pch_can: fix sparse warning
can: pch_can: fix section mismatch warning by using a whitelisted name
drivers/net/can/pch_can.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: VLAN packets silently dropped in promiscuous mode
From: Guillaume Gaudonville @ 2010-10-27 8:32 UTC (permalink / raw)
To: Jesse Gross; +Cc: Roger Luethi, netdev, Patrick McHardy
In-Reply-To: <AANLkTinH1Q4iq1_wg7HU_==khAtKOTZ2gz79s_EfzLYP@mail.gmail.com>
Jesse Gross wrote:
> On Mon, Oct 25, 2010 at 6:48 AM, Guillaume Gaudonville
> <guillaume.gaudonville@6wind.com> wrote:
>
>> Jesse Gross wrote:
>>
>>> On Fri, Oct 15, 2010 at 2:16 AM, Guillaume Gaudonville
>>> <guillaume.gaudonville@6wind.com> wrote:
>>>
>>>
>>>> Jesse Gross wrote:
>>>>
>>>>
>>>>> On Thu, Sep 30, 2010 at 1:07 AM, Roger Luethi <rl@hellgate.ch> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Wed, 29 Sep 2010 10:44:26 -0700, Jesse Gross wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Wed, Sep 29, 2010 at 4:37 AM, Roger Luethi <rl@hellgate.ch> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I noticed packets for unknown VLANs getting silently dropped even in
>>>>>>>> promiscuous mode (this is true only for the hardware accelerated
>>>>>>>> path).
>>>>>>>> netif_nit_deliver was introduced specifically to prevent that, but
>>>>>>>> the
>>>>>>>> function gets called only _after_ packets from unknown VLANs have
>>>>>>>> been
>>>>>>>> dropped.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Some drivers are fixing this on a case by case basis by disabling
>>>>>>> hardware accelerated VLAN stripping when in promiscuous mode, i.e.:
>>>>>>>
>>>>>>>
>>>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f6c01819979afbfec7e0b15fe52371b8eed87e8
>>>>>>>
>>>>>>> However, at this point it is more or less random which drivers do
>>>>>>> this. It would obviously be much better if it were consistent.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> My understanding is this. Hardware VLAN tagging and stripping can
>>>>>> always
>>>>>> be
>>>>>> enabled. The kernel passes 802.1Q information along with the stripped
>>>>>> header to libpcap which reassembles the original header where
>>>>>> necessary.
>>>>>> Works for me.
>>>>>>
>>>>>>
>>>>>>
>>>>> Sorry, I misread your original post as saying that the VLAN header
>>>>> gets dropped, rather than the entire packet. I agree that this is how
>>>>> it should work but not necessarily how it does work (again, depending
>>>>> on the driver). Here's the problem that I was talking about:
>>>>>
>>>>> Most drivers have a snippet of code that looks something like this
>>>>> (taken from ixgbe):
>>>>>
>>>>> if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
>>>>> vlan_gro_receive(napi, adapter->vlgrp, tag, skb);
>>>>> else
>>>>> napi_gro_receive(napi, skb);
>>>>>
>>>>> At this point the VLAN has already been stripped in hardware. If
>>>>> there is no VLAN group configured on the device then we hit the second
>>>>> case. The VLAN header was removed from the SKB and the tag variable
>>>>> is unused. It is no longer possible for libpcap to reconstruct the
>>>>> header because the information was thrown away (even the fact that
>>>>> there was a VLAN tag at all).
>>>>>
>>>>> There are a couple ways to fix this:
>>>>>
>>>>> * Turn off VLAN stripping when in promiscuous mode (as done by the ixgbe
>>>>> driver)
>>>>>
>>>>>
>>>>>
>>>> This is not totally true: if changing the MTU ixgbe_change_mtu will call:
>>>> ixgbe_reinit_locked--> ixgbe_up --> ixgbe_configure:
>>>> --> ixgbe_set_rx_mode: flag IFF_PROMISC is tested
>>>> ixgbe_vlan_filter_enable is not called
>>>> --> ixgbe_restore_vlan --> ixgbe_vlan_rx_register: flag
>>>> IFF_PROMISC is not tested ixgbe_vlan_filter_enable
>>>> will be called.
>>>>
>>>> In fact it should happen each time we configure something which needs a
>>>> reset of the device. Why don't add a test
>>>> on flag promiscuous directly in ixgbe_vlan_filter_enable? Or do it on
>>>> each
>>>> call, if we want to allow a device in promiscuous
>>>> mode to enable this feature.
>>>>
>>>> What do you think?
>>>>
>>>>
>>> I can believe that there are paths that lead to this not working
>>> correctly. That was actually my larger point: this is something that
>>> is commonly not implemented correctly in drivers. Rather than try to
>>> study every driver my goal is to just avoid the problem completely by
>>> handling vlan acceleration centrally in the networking core. I sent
>>> out an RFC patch series a few days ago that should solve this problem:
>>>
>>> http://marc.info/?l=linux-netdev&m=128700022614170&w=3
>>> --
>>> 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
>>>
>>>
>> Thank you, I'm going to check these patches and try to apply them in our
>> kernel.
>>
>
> An updated set of patches has been merged into net-2.6, so you might
> want to try that instead.
>
Ok I will, thank you.
--
Guillaume Gaudonville
6WIND
Software Engineer
Tel: +33 1 39 30 92 63
Mob: +33 6 47 85 34 33
Fax: +33 1 39 30 92 11
guillaume.gaudonville@6wind.com
www.6wind.com
Join the Multicore Packet Processing Forum: www.multicorepacketprocessing.com
Ce courriel ainsi que toutes les pièces jointes, est uniquement destiné à son ou ses destinataires. Il contient des informations confidentielles qui sont la propriété de 6WIND. Toute révélation, distribution ou copie des informations qu'il contient est strictement interdite. Si vous avez reçu ce message par erreur, veuillez immédiatement le signaler à l'émetteur et détruire toutes les données reçues
This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to 6WIND. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Maciej Żenczykowski @ 2010-10-27 8:35 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: netdev, Brian Haley
In-Reply-To: <4CC78F19.9080504@hp.com>
So how does all this work with privacy addresses, established
connections, and a link flap?
^ permalink raw reply
* Re: can: About Socket CAN with MSI issue
From: Dave Airlie @ 2010-10-27 7:56 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: linux-kernel, netdev, socketcan-core, sameo, 21cnbao, chripell,
w.sang, wg, David Miller, margie.foster, kok.howg.ewe, joel.clark,
andrew.chih.howe.khor, yong.y.wang, qi.wang
In-Reply-To: <002801cb758f$876aaf00$66f8800a@maildom.okisemi.com>
On Wed, Oct 27, 2010 at 2:29 PM, Tomoya MORINAGA
<tomoya-linux@dsn.okisemi.com> wrote:
> We have faced issue when our CAN diriver whose MSI is enabled, after installing the driver,
> once remove the driver and install the driver again,
> As a result, interupt handler of the driver is not called again.
>
> Do you have any information or suggestion about the above issue?
Its a bug in the PCI layer most likely,
http://amailbox.org/mailarchive/linux-kernel/2010/10/7/4629072
Dave.
^ permalink raw reply
* Re: can: About Socket CAN with MSI issue
From: Wolfgang Grandegger @ 2010-10-27 7:31 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <002801cb758f$876aaf00$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
On 10/27/2010 06:29 AM, Tomoya MORINAGA wrote:
> We have faced issue when our CAN diriver whose MSI is enabled, after installing the driver,
> once remove the driver and install the driver again,
> As a result, interupt handler of the driver is not called again.
>
> Do you have any information or suggestion about the above issue?
Not really, the remove functions looks ok, apart from the fact, that
pch_can_reset() is called *after* pci_iounmap().
Wolfgang.
^ permalink raw reply
* [PATCH] ehea: fix use after free
From: Eric Dumazet @ 2010-10-27 5:21 UTC (permalink / raw)
To: leitao; +Cc: davem, netdev
In-Reply-To: <1288118920.2652.4.camel@edumazet-laptop>
Le mardi 26 octobre 2010 à 20:48 +0200, Eric Dumazet a écrit :
> Note: driver already uses skb after its freeing, before your patch.
>
> if (vlan_tx_tag_present(skb)) {
> swqe->tx_control |= EHEA_SWQE_VLAN_INSERT;
> swqe->vlan_tag = vlan_tx_tag_get(skb);
> }
>
Could you please test following patch ?
Thanks
[PATCH] ehea: fix use after free
ehea_start_xmit() dereferences skb after its freeing in ehea_xmit3() to
get vlan tags.
Move the offending block before the potential ehea_xmit3() call.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/ehea/ehea_main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index bb7d306..e59d386 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2249,6 +2249,11 @@ static int ehea_start_xmit(struct sk_buff *skb, struct net_device *dev)
memset(swqe, 0, SWQE_HEADER_SIZE);
atomic_dec(&pr->swqe_avail);
+ if (vlan_tx_tag_present(skb)) {
+ swqe->tx_control |= EHEA_SWQE_VLAN_INSERT;
+ swqe->vlan_tag = vlan_tx_tag_get(skb);
+ }
+
if (skb->len <= SWQE3_MAX_IMM) {
u32 sig_iv = port->sig_comp_iv;
u32 swqe_num = pr->swqe_id_counter;
@@ -2279,11 +2284,6 @@ static int ehea_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
pr->swqe_id_counter += 1;
- if (vlan_tx_tag_present(skb)) {
- swqe->tx_control |= EHEA_SWQE_VLAN_INSERT;
- swqe->vlan_tag = vlan_tx_tag_get(skb);
- }
-
if (netif_msg_tx_queued(port)) {
ehea_info("post swqe on QP %d", pr->qp->init_attr.qp_nr);
ehea_dump(swqe, 512, "swqe");
^ permalink raw reply related
* Re: tbf/htb qdisc limitations
From: Bill Fink @ 2010-10-27 4:51 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Eric Dumazet, Rick Jones, Steven Brudenell, netdev
In-Reply-To: <20101020110612.GA18315@ff.dom.local>
On Wed, 20 Oct 2010, Jarek Poplawski wrote:
> On Tue, Oct 19, 2010 at 03:37:24AM -0400, Bill Fink wrote:
> > On Sun, 17 Oct 2010, Jarek Poplawski wrote:
> >
> > > On Sat, Oct 16, 2010 at 09:24:34PM -0400, Bill Fink wrote:
> > > > On Sat, 16 Oct 2010, Jarek Poplawski wrote:
> > > ...
> > > > > http://code.google.com/p/pspacer/wiki/HTBon10GbE
> > > > >
> > > > > If it doesn't help reconsider hfsc.
> > > >
> > > > Thanks for the link. From his results, it appears you can
> > > > get better accuracy by keeping TSO/GSO enabled and upping
> > > > the tc mtu parameter to 64000. I will have to try that out.
> > >
> > > Sure, but you have to remember that scheduler doesn't know real packet
> > > sizes and rate tables are less accurate especially for smaller packets,
> > > so it depends on conditions.
> >
> > On my testing on the real data path, TSO/GSO enabled did seem
> > to give more accurate results for a single stream. But when
> > I tried multiple 10-GigE paths simultaneously, each with a
> > single stream across it, non-TSO/GSO seemed to fare better
> > overall.
>
> Btw, if you find time I would be interested in checking an opposite
> concept of lower than real mtu (256) to use rate tables different way
> (other tbf parameters without change). The patch below is needed for
> this to work.
Sorry. I'm totally swamped at work currently and won't be able
to investigate that.
-Bill
> diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
> index 641a30d..9ac3460 100644
> --- a/net/sched/sch_tbf.c
> +++ b/net/sched/sch_tbf.c
> @@ -123,9 +123,6 @@ static int tbf_enqueue(struct sk_buff *skb, struct Qdisc* sch)
> struct tbf_sched_data *q = qdisc_priv(sch);
> int ret;
>
> - if (qdisc_pkt_len(skb) > q->max_size)
> - return qdisc_reshape_fail(skb, sch);
> -
> ret = qdisc_enqueue(skb, q->qdisc);
> if (ret != NET_XMIT_SUCCESS) {
> if (net_xmit_drop_count(ret))
^ permalink raw reply
* Re: [PATCH 2/2 v4] xps: Transmit Packet Steering
From: Eric Dumazet @ 2010-10-27 4:46 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.1.00.1010262033520.2997@pokey.mtv.corp.google.com>
Le mardi 26 octobre 2010 à 20:38 -0700, Tom Herbert a écrit :
> The benefits of XPS are improved locality in the per queue data
> structures. Also, transmit completions are more likely to be done
> nearer to the sending thread, so this should promote locality back
> to the socket on free (e.g. UDP).
I dont understand this part of changelog :
We now early orphan packets before giving them to device.
(see skb_orphan_try())
So at completion time, we dont touch socket anymore.
However, we free skb, so this promotes locality on kmem caches, iff tx
completion is run on same cpu.
^ permalink raw reply
* Re: [PATCH 2/2 v4] xps: Transmit Packet Steering
From: Eric Dumazet @ 2010-10-27 4:32 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.1.00.1010262033520.2997@pokey.mtv.corp.google.com>
Le mardi 26 octobre 2010 à 20:38 -0700, Tom Herbert a écrit :
> This patch implements transmit packet steering (XPS) for multiqueue
> devices. XPS selects a transmit queue during packet transmission based
> on configuration. This is done by mapping the CPU transmitting the
> packet to a queue. This is the transmit side analogue to RPS-- where
> RPS is selecting a CPU based on receive queue, XPS selects a queue
> based on the CPU (previously there was an XPS patch from Eric
> Dumazet, but that might more appropriately be called transmit completion
> steering).
>
> Each transmit queue can be associated with a number of CPUs which will
> use the queue to send packets. This is configured as a CPU mask on a
> per queue basis in:
>
> /sys/class/net/eth<n>/queues/tx-<n>/xps_cpus
>
> The mappings are stored per device in an inverted data structure that
> maps CPUs to queues. In the netdevice structure this is an array of
> num_possible_cpu structures where each structure holds and array of
> queue_indexes for queues which that CPU can use.
>
> The benefits of XPS are improved locality in the per queue data
> structures. Also, transmit completions are more likely to be done
> nearer to the sending thread, so this should promote locality back
> to the socket on free (e.g. UDP). The benefits of XPS are dependent on
> cache hierarchy, application load, and other factors. XPS would
> nominally be configured so that a queue would only be shared by CPUs
> which are sharing a cache, the degenerative configuration woud be that
> each CPU has it's own queue.
>
> Below are some benchmark results which show the potential benfit of
> this patch. The netperf test has 500 instances of netperf TCP_RR test
> with 1 byte req. and resp.
>
> bnx2x on 16 core AMD
> XPS (16 queues, 1 TX queue per CPU) 1234K at 100% CPU
> No XPS (16 queues) 996K at 100% CPU
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/netdevice.h | 27 ++++
> net/core/dev.c | 55 +++++++-
> net/core/net-sysfs.c | 367 ++++++++++++++++++++++++++++++++++++++++++++-
> net/core/net-sysfs.h | 3 +
> 4 files changed, 446 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index fcd3dda..f19b78b 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -503,6 +503,13 @@ struct netdev_queue {
> struct Qdisc *qdisc;
> unsigned long state;
> struct Qdisc *qdisc_sleeping;
> +#ifdef CONFIG_RPS
> + struct netdev_queue *first;
> + atomic_t count;
> + struct xps_dev_maps *xps_maps;
> + struct kobject kobj;
> +#endif
> +
> /*
> * write mostly part
> */
> @@ -530,6 +537,26 @@ struct rps_map {
> #define RPS_MAP_SIZE(_num) (sizeof(struct rps_map) + (_num * sizeof(u16)))
>
> /*
> + * This structure holds an XPS map which can be of variable length. The
> + * map is an array of queues.
> + */
> +struct xps_map {
> + unsigned int len;
> + unsigned int alloc_len;
> + struct rcu_head rcu;
> + u16 queues[0];
> +};
OK, so its a 'small' structure. And we dont want it to share a cache
line with an other user in the kernel, or false sharing might happen.
Make sure you allocate big enough ones to fill a full cache line.
alloc_len = (L1_CACHE_BYTES - sizeof(struct xps_map)) / sizeof(u16);
I see you allocate ones with alloc_len = 1. Thats not good.
> +
> +/*
> + * This structure holds all XPS maps for device. Maps are indexed by CPU.
> + */
> +struct xps_dev_maps {
> + struct rcu_head rcu;
> + struct xps_map *cpu_map[0];
Hmm... per_cpu maybe, instead of an array ?
Also make sure this xps_dev_maps use a full cache line, to avoid false
sharing.
> +};
> +#define netdev_get_xps_maps(dev) ((dev)->_tx[0].xps_maps)
> +
> +/*
> * The rps_dev_flow structure contains the mapping of a flow to a CPU and the
> * tail pointer for that CPU's input queue at the time of last enqueue.
> */
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 4df783c..12426a6 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2119,6 +2119,44 @@ static inline u16 dev_cap_txqueue(struct net_device *dev, u16 queue_index)
> return queue_index;
> }
>
> +static inline int get_xps_queue(struct net_device *dev, struct sk_buff *skb)
> +{
> +#ifdef CONFIG_RPS
> + struct xps_dev_maps *dev_maps;
> + struct xps_map *map;
> + int queue_index = -1;
> +
> + preempt_disable();
> + rcu_read_lock();
> + dev_maps = rcu_dereference(netdev_get_xps_maps(dev));
> + if (dev_maps) {
> + map = rcu_dereference(dev_maps->cpu_map[smp_processor_id()]);
Really I am not sure we need this array and smp_processor_id().
Please consider alloc_percpu().
Then, use __this_cpu_ptr() and avoid the preempt_disable()/enable()
thing. Its a hint we want to use, because as soon as we leave
get_xps_queue() we might migrate to another cpu ?
> + if (map) {
> + if (map->len == 1)
> + queue_index = map->queues[0];
> + else {
> + u32 hash;
> + if (skb->sk && skb->sk->sk_hash)
> + hash = skb->sk->sk_hash;
> + else
> + hash = (__force u16) skb->protocol ^
> + skb->rxhash;
> + hash = jhash_1word(hash, hashrnd);
> + queue_index = map->queues[
> + ((u64)hash * map->len) >> 32];
> + }
> + if (unlikely(queue_index >= dev->real_num_tx_queues))
> + queue_index = -1;
> + }
> + }
> + rcu_read_unlock();
> + preempt_enable();
> +
> + return queue_index;
> +#endif
> + return -1;
> +}
> +
> static struct netdev_queue *dev_pick_tx(struct net_device *dev,
> struct sk_buff *skb)
> {
> @@ -2138,7 +2176,9 @@ static struct netdev_queue *dev_pick_tx(struct net_device *dev,
> queue_index >= dev->real_num_tx_queues) {
> int old_index = queue_index;
>
> - queue_index = skb_tx_hash(dev, skb);
> + queue_index = get_xps_queue(dev, skb);
> + if (queue_index < 0)
> + queue_index = skb_tx_hash(dev, skb);
>
> if (queue_index != old_index && sk) {
> struct dst_entry *dst =
> @@ -5052,6 +5092,17 @@ static int netif_alloc_netdev_queues(struct net_device *dev)
> return -ENOMEM;
> }
> dev->_tx = tx;
> +#ifdef CONFIG_RPS
> + /*
> + * Set a pointer to first element in the array which holds the
> + * reference count.
> + */
> + {
> + int i;
> + for (i = 0; i < count; i++)
> + tx[i].first = tx;
> + }
> +#endif
> return 0;
> }
>
> @@ -5616,7 +5667,9 @@ void free_netdev(struct net_device *dev)
>
> release_net(dev_net(dev));
>
> +#ifndef CONFIG_RPS
> kfree(dev->_tx);
> +#endif
>
> kfree(rcu_dereference_raw(dev->ingress_queue));
>
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index b143173..e193cf2 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -764,18 +764,375 @@ net_rx_queue_update_kobjects(struct net_device *net, int old_num, int new_num)
> return error;
> }
>
> -static int rx_queue_register_kobjects(struct net_device *net)
> +/*
> + * netdev_queue sysfs structures and functions.
> + */
> +struct netdev_queue_attribute {
> + struct attribute attr;
> + ssize_t (*show)(struct netdev_queue *queue,
> + struct netdev_queue_attribute *attr, char *buf);
> + ssize_t (*store)(struct netdev_queue *queue,
> + struct netdev_queue_attribute *attr, const char *buf, size_t len);
> +};
> +#define to_netdev_queue_attr(_attr) container_of(_attr, \
> + struct netdev_queue_attribute, attr)
> +
> +#define to_netdev_queue(obj) container_of(obj, struct netdev_queue, kobj)
> +
> +static ssize_t netdev_queue_attr_show(struct kobject *kobj,
> + struct attribute *attr, char *buf)
> +{
> + struct netdev_queue_attribute *attribute = to_netdev_queue_attr(attr);
> + struct netdev_queue *queue = to_netdev_queue(kobj);
> +
> + if (!attribute->show)
> + return -EIO;
> +
> + return attribute->show(queue, attribute, buf);
> +}
> +
> +static ssize_t netdev_queue_attr_store(struct kobject *kobj,
> + struct attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct netdev_queue_attribute *attribute = to_netdev_queue_attr(attr);
> + struct netdev_queue *queue = to_netdev_queue(kobj);
> +
> + if (!attribute->store)
> + return -EIO;
> +
> + return attribute->store(queue, attribute, buf, count);
> +}
> +
> +static const struct sysfs_ops netdev_queue_sysfs_ops = {
> + .show = netdev_queue_attr_show,
> + .store = netdev_queue_attr_store,
> +};
> +
> +static inline unsigned int get_netdev_queue_index(struct netdev_queue *queue)
> +{
> + struct net_device *dev = queue->dev;
> + int i;
> +
> + for (i = 0; i < dev->num_tx_queues; i++)
> + if (queue == &dev->_tx[i])
> + break;
> +
> + BUG_ON(i >= dev->num_tx_queues);
> +
> + return i;
> +}
> +
> +
> +static ssize_t show_xps_map(struct netdev_queue *queue,
> + struct netdev_queue_attribute *attribute, char *buf)
> +{
> + struct netdev_queue *first = queue->first;
> + struct xps_dev_maps *dev_maps;
> + cpumask_var_t mask;
> + unsigned long index;
> + size_t len = 0;
> + int i;
> +
> + if (!zalloc_cpumask_var(&mask, GFP_KERNEL))
> + return -ENOMEM;
> +
> + index = get_netdev_queue_index(queue);
> +
> + rcu_read_lock();
> + dev_maps = rcu_dereference(first->xps_maps);
> + if (dev_maps) {
> + for (i = 0; i < num_possible_cpus(); i++) {
The use of num_possible_cpus() seems wrong to me.
Dont you meant nr_cpu_ids ?
Some machines have two possible cpus, numbered 0 and 8 :
num_possible_cpus = 2
nr_cpu_ids = 8
anyway, using a per_cpu var, this loop becomes more friendly :
for_each_possible_cpu(i) {
and you use less ram, and you also use NUMA friendly allocations as
well.
> + struct xps_map *map =
> + rcu_dereference(dev_maps->cpu_map[i]);
> + if (map) {
> + int j;
> + for (j = 0; j < map->len; j++) {
> + if (map->queues[j] == index) {
> + cpumask_set_cpu(i, mask);
> + break;
> + }
> + }
> + }
> + }
> + }
> + len += cpumask_scnprintf(buf + len, PAGE_SIZE, mask);
> + if (PAGE_SIZE - len < 3) {
> + rcu_read_unlock();
> + free_cpumask_var(mask);
> + return -EINVAL;
> + }
> + rcu_read_unlock();
> +
> + free_cpumask_var(mask);
> + len += sprintf(buf + len, "\n");
> + return len;
> +}
> +
> +static void xps_map_release(struct rcu_head *rcu)
> +{
> + struct xps_map *map = container_of(rcu, struct xps_map, rcu);
> +
> + kfree(map);
> +}
> +
> +static void xps_dev_maps_release(struct rcu_head *rcu)
> {
> + struct xps_dev_maps *dev_maps =
> + container_of(rcu, struct xps_dev_maps, rcu);
> +
> + kfree(dev_maps);
> +}
> +
> +static DEFINE_MUTEX(xps_map_mutex);
> +
> +static ssize_t store_xps_map(struct netdev_queue *queue,
> + struct netdev_queue_attribute *attribute,
> + const char *buf, size_t len)
> +{
> + struct netdev_queue *first = queue->first;
> + cpumask_var_t mask;
> + int err, i, cpu, pos, map_len, alloc_len, need_set;
> + unsigned long index;
> + struct xps_map *map, *new_map;
> + struct xps_dev_maps *dev_maps, *new_dev_maps;
> + int nonempty = 0;
> +
> + if (!capable(CAP_NET_ADMIN))
> + return -EPERM;
> +
> + if (!alloc_cpumask_var(&mask, GFP_KERNEL))
> + return -ENOMEM;
> +
> + index = get_netdev_queue_index(queue);
> +
> + err = bitmap_parse(buf, len, cpumask_bits(mask), nr_cpumask_bits);
> + if (err) {
> + free_cpumask_var(mask);
> + return err;
> + }
> +
> + new_dev_maps = kzalloc(sizeof(struct xps_dev_maps) +
> + (num_possible_cpus() * sizeof(struct xps_map *)), GFP_KERNEL);
> + if (!new_dev_maps) {
> + free_cpumask_var(mask);
> + return err;
> + }
> +
> + mutex_lock(&xps_map_mutex);
> +
> + dev_maps = first->xps_maps;
> +
> + for (cpu = 0; cpu < num_possible_cpus(); cpu++) {
> + new_map = map = dev_maps ? dev_maps->cpu_map[cpu] : NULL;
> +
> + if (map) {
> + for (pos = 0; pos < map->len; pos++)
> + if (map->queues[pos] == index)
> + break;
> + map_len = map->len;
> + alloc_len = map->alloc_len;
> + } else
> + pos = map_len = alloc_len = 0;
> +
> + need_set = cpu_isset(cpu, *mask) && cpu_online(cpu);
> +
> + if (need_set && pos >= map_len) {
> + /* Need to add queue to this CPU's map */
> + if (map_len >= alloc_len) {
> + alloc_len = alloc_len ? 2 * alloc_len : 1;
See my first comment : Please reserve use a full cache line here
Also please use kzalloc_node() to get better NUMA affinity.
> + new_map = kzalloc(sizeof(struct xps_map) +
> + (alloc_len * sizeof(u16)), GFP_KERNEL);
> + if (!new_map)
> + goto error;
> + new_map->alloc_len = alloc_len;
> + for (i = 0; i < map_len; i++)
> + new_map->queues[i] = map->queues[i];
> + new_map->len = map_len;
> + }
> + new_map->queues[new_map->len++] = index;
> + } else if (!need_set && pos < map_len) {
> + /* Need to remove queue from this CPU's map */
> + if (map_len > 1)
> + new_map->queues[pos] =
> + new_map->queues[--new_map->len];
> + else
> + new_map = NULL;
> + }
> + new_dev_maps->cpu_map[cpu] = new_map;
> + }
^ permalink raw reply
* can: About Socket CAN with MSI issue
From: Tomoya MORINAGA @ 2010-10-27 4:29 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
sameo-VuQAYsv1563Yd54FQh9/CA, 21cnbao-Re5JQEeQqe8AvxtiuMwx3w,
chripell-VaTbYqLCNhc, w.sang-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, David Miller,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20101026.105206.15244527.davem@davemloft.net>
We have faced issue when our CAN diriver whose MSI is enabled, after installing the driver,
once remove the driver and install the driver again,
As a result, interupt handler of the driver is not called again.
Do you have any information or suggestion about the above issue?
As to the our latest CAN driver,
please refer to followoing patch posted by me.
[PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
Thanks, Tomoya(OKI SEMICONDUCTOR CO., LTD.)
^ permalink raw reply
* [PATCH 2/3] qlcnic: reduce rx ring size
From: Amit Kumar Salecha @ 2010-10-27 3:53 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sony Chacko
In-Reply-To: <1288151589-32431-1-git-send-email-amit.salecha@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
If eswitch is enabled, rcv ring size can be reduce, as
physical port is partition-ed.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 4 ++++
drivers/net/qlcnic/qlcnic_ethtool.c | 23 +++++------------------
drivers/net/qlcnic/qlcnic_main.c | 14 ++++++++++++--
3 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index a60ff17..6400e6a 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -146,11 +146,13 @@
#define MAX_CMD_DESCRIPTORS 1024
#define MAX_RCV_DESCRIPTORS_1G 4096
#define MAX_RCV_DESCRIPTORS_10G 8192
+#define MAX_RCV_DESCRIPTORS_VF 2048
#define MAX_JUMBO_RCV_DESCRIPTORS_1G 512
#define MAX_JUMBO_RCV_DESCRIPTORS_10G 1024
#define DEFAULT_RCV_DESCRIPTORS_1G 2048
#define DEFAULT_RCV_DESCRIPTORS_10G 4096
+#define DEFAULT_RCV_DESCRIPTORS_VF 1024
#define MAX_RDS_RINGS 2
#define get_next_index(index, length) \
@@ -971,6 +973,8 @@ struct qlcnic_adapter {
u16 num_txd;
u16 num_rxd;
u16 num_jumbo_rxd;
+ u16 max_rxd;
+ u16 max_jumbo_rxd;
u8 max_rds_rings;
u8 max_sds_rings;
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 25e93a5..ec21d24 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -437,14 +437,8 @@ qlcnic_get_ringparam(struct net_device *dev,
ring->rx_jumbo_pending = adapter->num_jumbo_rxd;
ring->tx_pending = adapter->num_txd;
- if (adapter->ahw.port_type == QLCNIC_GBE) {
- ring->rx_max_pending = MAX_RCV_DESCRIPTORS_1G;
- ring->rx_jumbo_max_pending = MAX_JUMBO_RCV_DESCRIPTORS_1G;
- } else {
- ring->rx_max_pending = MAX_RCV_DESCRIPTORS_10G;
- ring->rx_jumbo_max_pending = MAX_JUMBO_RCV_DESCRIPTORS_10G;
- }
-
+ ring->rx_max_pending = adapter->max_rxd;
+ ring->rx_jumbo_max_pending = adapter->max_jumbo_rxd;
ring->tx_max_pending = MAX_CMD_DESCRIPTORS;
ring->rx_mini_max_pending = 0;
@@ -472,24 +466,17 @@ qlcnic_set_ringparam(struct net_device *dev,
struct ethtool_ringparam *ring)
{
struct qlcnic_adapter *adapter = netdev_priv(dev);
- u16 max_rcv_desc = MAX_RCV_DESCRIPTORS_10G;
- u16 max_jumbo_desc = MAX_JUMBO_RCV_DESCRIPTORS_10G;
u16 num_rxd, num_jumbo_rxd, num_txd;
-
if (ring->rx_mini_pending)
return -EOPNOTSUPP;
- if (adapter->ahw.port_type == QLCNIC_GBE) {
- max_rcv_desc = MAX_RCV_DESCRIPTORS_1G;
- max_jumbo_desc = MAX_JUMBO_RCV_DESCRIPTORS_10G;
- }
-
num_rxd = qlcnic_validate_ringparam(ring->rx_pending,
- MIN_RCV_DESCRIPTORS, max_rcv_desc, "rx");
+ MIN_RCV_DESCRIPTORS, adapter->max_rxd, "rx");
num_jumbo_rxd = qlcnic_validate_ringparam(ring->rx_jumbo_pending,
- MIN_JUMBO_DESCRIPTORS, max_jumbo_desc, "rx jumbo");
+ MIN_JUMBO_DESCRIPTORS, adapter->max_jumbo_rxd,
+ "rx jumbo");
num_txd = qlcnic_validate_ringparam(ring->tx_pending,
MIN_CMD_DESCRIPTORS, MAX_CMD_DESCRIPTORS, "tx");
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 5a3ce08..7a298cd 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -656,13 +656,23 @@ qlcnic_check_options(struct qlcnic_adapter *adapter)
dev_info(&pdev->dev, "firmware v%d.%d.%d\n",
fw_major, fw_minor, fw_build);
-
if (adapter->ahw.port_type == QLCNIC_XGBE) {
- adapter->num_rxd = DEFAULT_RCV_DESCRIPTORS_10G;
+ if (adapter->flags & QLCNIC_ESWITCH_ENABLED) {
+ adapter->num_rxd = DEFAULT_RCV_DESCRIPTORS_VF;
+ adapter->max_rxd = MAX_RCV_DESCRIPTORS_VF;
+ } else {
+ adapter->num_rxd = DEFAULT_RCV_DESCRIPTORS_10G;
+ adapter->max_rxd = MAX_RCV_DESCRIPTORS_10G;
+ }
+
adapter->num_jumbo_rxd = MAX_JUMBO_RCV_DESCRIPTORS_10G;
+ adapter->max_jumbo_rxd = MAX_JUMBO_RCV_DESCRIPTORS_10G;
+
} else if (adapter->ahw.port_type == QLCNIC_GBE) {
adapter->num_rxd = DEFAULT_RCV_DESCRIPTORS_1G;
adapter->num_jumbo_rxd = MAX_JUMBO_RCV_DESCRIPTORS_1G;
+ adapter->max_jumbo_rxd = MAX_JUMBO_RCV_DESCRIPTORS_1G;
+ adapter->max_rxd = MAX_RCV_DESCRIPTORS_1G;
}
adapter->msix_supported = !!use_msi_x;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 3/3] qlcnic: define valid vlan id range
From: Amit Kumar Salecha @ 2010-10-27 3:53 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sony Chacko
In-Reply-To: <1288151589-32431-1-git-send-email-amit.salecha@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
4095 vlan id is reserved and should not be use.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 6400e6a..8ecc170 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1134,7 +1134,7 @@ struct qlcnic_eswitch {
#define MAX_RX_QUEUES 4
#define DEFAULT_MAC_LEARN 1
-#define IS_VALID_VLAN(vlan) (vlan >= MIN_VLAN_ID && vlan <= MAX_VLAN_ID)
+#define IS_VALID_VLAN(vlan) (vlan >= MIN_VLAN_ID && vlan < MAX_VLAN_ID)
#define IS_VALID_BW(bw) (bw >= MIN_BW && bw <= MAX_BW)
#define IS_VALID_TX_QUEUES(que) (que > 0 && que <= MAX_TX_QUEUES)
#define IS_VALID_RX_QUEUES(que) (que > 0 && que <= MAX_RX_QUEUES)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/3] qlcnic: fix mac learning
From: Amit Kumar Salecha @ 2010-10-27 3:53 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1288151589-32431-1-git-send-email-amit.salecha@qlogic.com>
In failover bonding case, same mac address can be programmed on other slave function.
Fw will delete old entry (original func) associated with that mac address.
Need to reporgram mac address, if failover again happen to original function.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 1 +
drivers/net/qlcnic/qlcnic_main.c | 5 +++++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 26c37d3..a60ff17 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -942,6 +942,7 @@ struct qlcnic_ipaddr {
#define QLCNIC_LOOPBACK_TEST 2
#define QLCNIC_FILTER_AGE 80
+#define QLCNIC_READD_AGE 20
#define QLCNIC_LB_MAX_FILTERS 64
struct qlcnic_filter {
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f047c7c..5a3ce08 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1860,6 +1860,11 @@ qlcnic_send_filter(struct qlcnic_adapter *adapter,
hlist_for_each_entry_safe(tmp_fil, tmp_hnode, n, head, fnode) {
if (!memcmp(tmp_fil->faddr, &src_addr, ETH_ALEN) &&
tmp_fil->vlan_id == vlan_id) {
+
+ if (jiffies >
+ (QLCNIC_READD_AGE * HZ + tmp_fil->ftime))
+ qlcnic_change_filter(adapter, src_addr, vlan_id,
+ tx_ring);
tmp_fil->ftime = jiffies;
return;
}
--
1.6.0.2
^ permalink raw reply related
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