* [PATCH 2/7] au1000-eth: set MODULE_VERSION
From: Florian Fainelli @ 2010-04-07 8:08 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index 2963159..b96abc5 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -83,6 +83,7 @@ static int au1000_debug = 3;
MODULE_AUTHOR(DRV_AUTHOR);
MODULE_DESCRIPTION(DRV_DESC);
MODULE_LICENSE("GPL");
+MODULE_VERSION(DRV_VERSION);
/*
* Theory of operation
^ permalink raw reply related
* [PATCH 1/7] au1000-eth: allow driver to be compiled as a module
From: Florian Fainelli @ 2010-04-07 8:08 UTC (permalink / raw)
To: netdev; +Cc: David Miller
This patch allows the au1000-eth driver to be compiled as a module.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 20e2dec..ac2e364 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -483,7 +483,7 @@ config XTENSA_XT2000_SONIC
This is the driver for the onboard card of the Xtensa XT2000 board.
config MIPS_AU1X00_ENET
- bool "MIPS AU1000 Ethernet support"
+ tristate "MIPS AU1000 Ethernet support"
depends on SOC_AU1X00
select PHYLIB
select CRC32
^ permalink raw reply related
* [PATCH 0/7] au1000-eth cleanups
From: Florian Fainelli @ 2010-04-07 8:08 UTC (permalink / raw)
To: netdev, David Miller
Hi David,
Here comes a serie of 7 cleanups and small enhancements for the Au1000
ethernet driver.
Florian Fainelli (7):
au1000-eth: allow driver to be compiled as a module
au1000-eth: set MODULE_VERSION
au1000-eth: prefix all functions with au1000_
au1000-eth: fix checkpatch errors.
au1000-eth: implement set/get_msglevel
au1000-eth: Use (dev|netdev|netif)_<level> macro helpers
au1000-eth: bump to 1.7
^ permalink raw reply
* Re: RCU problems in fib_table_insert
From: Paul E. McKenney @ 2010-04-07 6:45 UTC (permalink / raw)
To: Robert Olsson; +Cc: Andi Kleen, robert.olsson, netdev, Jens.Laas
In-Reply-To: <19388.8645.99295.495371@gargle.gargle.HOWL>
On Wed, Apr 07, 2010 at 08:10:13AM +0200, Robert Olsson wrote:
>
> Paul E. McKenney writes:
> > On Mon, Mar 22, 2010 at 07:18:34AM +0100, Robert Olsson wrote:
> > >
> > > Seems like Paul and Eric fixed this problem... We use fib_trie with
> > > major infrastructure but always disable preempt. It was unsafe w.
> > > preempt at least before Jareks P. patches about a year ago. I havn't
> > > tested w. preempt after that but maybe someone else have...
>
>
> > Though I must admit that I would be surprised if there wasn't
> > more adjustment required in net/ipv4/fib_trie.c -- lots of
> > rcu_dereference()s in there.
>
> Hi, a follow on this thread.
>
> Maybe I was to pessimistic... we've setup for stress test running during
> easter vacation
>
> Testing the fib_trie with preempt enabled. Continuesly loading/flushing
> "full BGP" via a test script, while routing without the route cache
> to further stress locking. Average load about 300 kpps. Some more test
> details below.
>
> The test was manually stopped after 6 days. So it seems like preempt/rcu
> has been improved with fib_trie.
Always happy to be pleasantly surprised. ;-)
Thanx, Paul
> Thanks
> --ro
>
> HW
> --
> CPU Opteron 2 * 6174, TYAN S8230. Intel 82599
>
> Kernel from net-next-2.6
> ------------------------
> Version 2.6.34-rc1bifrost-x86_64 (gcc version 4.3.2 (GCC) ) #4 SMP PREEMPT
> CONFIG_PREEMPT=y
> CONFIG_DEBUG_PREEMPT=y
> CONFIG_IP_FIB_TRIE=y
> CONFIG_FIB_RULES=y
> CONFIG_TREE_RCU=y
> CONFIG_RCU_FANOUT=64
>
> IP table
> --------
> "BGP" 279 k routes
>
> Test duration
> -------------
> 09:34:14 up 6 days, 20:57, 4 users, load average: 5.28, 5.87, 5.53
>
> Test script
> -----------
> #! /bin/bash
> while(true) do
> ip -batch /etc/inet_route_add.bat;
> ip route list | wc -l; ( 279 k routes )
> ifconfig eth1 down
> ifconfig eth1 10.10.11.1 netmask 255.255.255.0
> ip route list | wc -l; ( 3 routes )
> done;
>
> /proc/net/softnet_stat
>
> 0000d503 00000000 00000014 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 4cc1ecfb 00000000 02bb1bcb 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 4cb95da1 00000000 02cc6574 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 4cb17932 00000000 02e1abdf 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 4cc40ad9 00000000 02f53db0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 4cbfe34f 00000000 0306a88d 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 4ccb10e9 00000000 03d3a11d 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 4ca84c29 00000000 03be0ca1 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 4cb710f8 00000000 04070289 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 0b505d55 00000000 038a9bc0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 0b54a7be 00000000 03a5de6d 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 0b5be81f 00000000 03be018c 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 0b51fdd0 00000000 0559fdd6 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 0b4fa6fd 00000000 056311dc 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 0b4a61d3 00000000 056a9276 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 0b454970 00000000 0572add1 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>
> FYI. CPU0 is resvered for BGP/ssh/stats etc
^ permalink raw reply
* Re: hackbench regression due to commit 9dfc6e68bfe6e
From: Eric Dumazet @ 2010-04-07 6:39 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: Christoph Lameter, netdev, Tejun Heo, Pekka Enberg, alex.shi,
linux-kernel@vger.kernel.org, Ma, Ling, Chen, Tim C,
Andrew Morton
In-Reply-To: <1270607668.2078.259.camel@ymzhang.sh.intel.com>
Le mercredi 07 avril 2010 à 10:34 +0800, Zhang, Yanmin a écrit :
> I collected retired instruction, dtlb miss and LLC miss.
> Below is data of LLC miss.
>
> Kernel 2.6.33:
> # Samples: 11639436896 LLC-load-misses
> #
> # Overhead Command Shared Object Symbol
> # ........ ............... ...................................................... ......
> #
> 20.94% hackbench [kernel.kallsyms] [k] copy_user_generic_string
> 14.56% hackbench [kernel.kallsyms] [k] unix_stream_recvmsg
> 12.88% hackbench [kernel.kallsyms] [k] kfree
> 7.37% hackbench [kernel.kallsyms] [k] kmem_cache_free
> 7.18% hackbench [kernel.kallsyms] [k] kmem_cache_alloc_node
> 6.78% hackbench [kernel.kallsyms] [k] kfree_skb
> 6.27% hackbench [kernel.kallsyms] [k] __kmalloc_node_track_caller
> 2.73% hackbench [kernel.kallsyms] [k] __slab_free
> 2.21% hackbench [kernel.kallsyms] [k] get_partial_node
> 2.01% hackbench [kernel.kallsyms] [k] _raw_spin_lock
> 1.59% hackbench [kernel.kallsyms] [k] schedule
> 1.27% hackbench hackbench [.] receiver
> 0.99% hackbench libpthread-2.9.so [.] __read
> 0.87% hackbench [kernel.kallsyms] [k] unix_stream_sendmsg
>
>
>
>
> Kernel 2.6.34-rc3:
> # Samples: 13079611308 LLC-load-misses
> #
> # Overhead Command Shared Object Symbol
> # ........ ............... .................................................................... ......
> #
> 18.55% hackbench [kernel.kallsyms] [k] copy_user_generic_str
> ing
> 13.19% hackbench [kernel.kallsyms] [k] unix_stream_recvmsg
> 11.62% hackbench [kernel.kallsyms] [k] kfree
> 8.54% hackbench [kernel.kallsyms] [k] kmem_cache_free
> 7.88% hackbench [kernel.kallsyms] [k] __kmalloc_node_track_
> caller
> 6.54% hackbench [kernel.kallsyms] [k] kmem_cache_alloc_node
> 5.94% hackbench [kernel.kallsyms] [k] kfree_skb
> 3.48% hackbench [kernel.kallsyms] [k] __slab_free
> 2.15% hackbench [kernel.kallsyms] [k] _raw_spin_lock
> 1.83% hackbench [kernel.kallsyms] [k] schedule
> 1.82% hackbench [kernel.kallsyms] [k] get_partial_node
> 1.59% hackbench hackbench [.] receiver
> 1.37% hackbench libpthread-2.9.so [.] __read
>
>
Please check values of /proc/sys/net/core/rmem_default
and /proc/sys/net/core/wmem_default on your machines.
Their values can also change hackbench results, because increasing
wmem_default allows af_unix senders to consume much more skbs and stress
slab allocators (__slab_free), way beyond slub_min_order can tune them.
When 2000 senders are running (and 2000 receivers), we might consume
something like 2000 * 100.000 bytes of kernel memory for skbs. TLB
trashing is expected, because all these skbs can span many 2MB pages.
Maybe some node imbalance happens too.
You could try to boot your machine with less ram per node and check :
# cat /proc/buddyinfo
Node 0, zone DMA 2 1 2 2 1 1 1 0 1 1 3
Node 0, zone DMA32 219 298 143 584 145 57 44 41 31 26 517
Node 1, zone DMA32 4 1 17 1 0 3 2 2 2 2 123
Node 1, zone Normal 126 169 83 8 7 5 59 59 49 28 459
One experiment on your Nehalem machine would be to change hackbench so
that each group (20 senders/ 20 receivers) run on a particular NUMA
node.
x86info -c ->
CPU #1
EFamily: 0 EModel: 1 Family: 6 Model: 26 Stepping: 5
CPU Model: Core i7 (Nehalem)
Processor name string: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
Type: 0 (Original OEM) Brand: 0 (Unsupported)
Number of cores per physical package=8
Number of logical processors per socket=16
Number of logical processors per core=2
APIC ID: 0x10 Package: 0 Core: 1 SMT ID 0
Cache info
L1 Instruction cache: 32KB, 4-way associative. 64 byte line size.
L1 Data cache: 32KB, 8-way associative. 64 byte line size.
L2 (MLC): 256KB, 8-way associative. 64 byte line size.
TLB info
Data TLB: 4KB pages, 4-way associative, 64 entries
64 byte prefetching.
Found unknown cache descriptors: 55 5a b2 ca e4
^ permalink raw reply
* Re: RCU problems in fib_table_insert
From: Robert Olsson @ 2010-04-07 6:10 UTC (permalink / raw)
To: paulmck; +Cc: Robert Olsson, Andi Kleen, robert.olsson, netdev, Jens.Laas
In-Reply-To: <20100322065133.GG2517@linux.vnet.ibm.com>
Paul E. McKenney writes:
> On Mon, Mar 22, 2010 at 07:18:34AM +0100, Robert Olsson wrote:
> >
> > Seems like Paul and Eric fixed this problem... We use fib_trie with
> > major infrastructure but always disable preempt. It was unsafe w.
> > preempt at least before Jareks P. patches about a year ago. I havn't
> > tested w. preempt after that but maybe someone else have...
> Though I must admit that I would be surprised if there wasn't
> more adjustment required in net/ipv4/fib_trie.c -- lots of
> rcu_dereference()s in there.
Hi, a follow on this thread.
Maybe I was to pessimistic... we've setup for stress test running during
easter vacation
Testing the fib_trie with preempt enabled. Continuesly loading/flushing
"full BGP" via a test script, while routing without the route cache
to further stress locking. Average load about 300 kpps. Some more test
details below.
The test was manually stopped after 6 days. So it seems like preempt/rcu
has been improved with fib_trie.
Thanks
--ro
HW
--
CPU Opteron 2 * 6174, TYAN S8230. Intel 82599
Kernel from net-next-2.6
------------------------
Version 2.6.34-rc1bifrost-x86_64 (gcc version 4.3.2 (GCC) ) #4 SMP PREEMPT
CONFIG_PREEMPT=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_IP_FIB_TRIE=y
CONFIG_FIB_RULES=y
CONFIG_TREE_RCU=y
CONFIG_RCU_FANOUT=64
IP table
--------
"BGP" 279 k routes
Test duration
-------------
09:34:14 up 6 days, 20:57, 4 users, load average: 5.28, 5.87, 5.53
Test script
-----------
#! /bin/bash
while(true) do
ip -batch /etc/inet_route_add.bat;
ip route list | wc -l; ( 279 k routes )
ifconfig eth1 down
ifconfig eth1 10.10.11.1 netmask 255.255.255.0
ip route list | wc -l; ( 3 routes )
done;
/proc/net/softnet_stat
0000d503 00000000 00000014 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4cc1ecfb 00000000 02bb1bcb 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4cb95da1 00000000 02cc6574 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4cb17932 00000000 02e1abdf 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4cc40ad9 00000000 02f53db0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4cbfe34f 00000000 0306a88d 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4ccb10e9 00000000 03d3a11d 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4ca84c29 00000000 03be0ca1 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4cb710f8 00000000 04070289 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0b505d55 00000000 038a9bc0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0b54a7be 00000000 03a5de6d 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0b5be81f 00000000 03be018c 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0b51fdd0 00000000 0559fdd6 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0b4fa6fd 00000000 056311dc 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0b4a61d3 00000000 056a9276 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0b454970 00000000 0572add1 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
FYI. CPU0 is resvered for BGP/ssh/stats etc
^ permalink raw reply
* RE: [PATCH 1/1] NET: usb: Adding URB_ZERO_PACKET flag to usbnet.c
From: Maulik @ 2010-04-07 5:46 UTC (permalink / raw)
To: 'Elina Pasheva', dbrownell; +Cc: rfiler, netdev, linux-usb
In-Reply-To: <1270599787.8900.8.camel@Linuxdev4-laptop>
> -----Original Message-----
> From: linux-usb-owner@vger.kernel.org [mailto:linux-usb-
> owner@vger.kernel.org] On Behalf Of Elina Pasheva
> Sent: Wednesday, April 07, 2010 5:53 AM
> To: dbrownell@users.sourceforge.net
> Cc: epasheva@sierrawireless.com; rfiler@sierrawireless.com;
> netdev@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: [PATCH 1/1] NET: usb: Adding URB_ZERO_PACKET flag to usbnet.c
>
> Subject: [PATCH 1/1] NET: usb: Adding URB_ZERO_PACKET flag to usbnet.c
> From: Elina Pasheva <epasheva@sierrawireless.com>
> This patch adds setting of the urb transfer flag URB_ZERO_PACKET before
> submitting an urb for drivers that have requested it (by advertising flag
> FLAG_SEND_ZLP).
> The modification is in usbnet.c function usbnet_start_xmit().
> This patch only adds the zero length flag.
> A subsequent patch will address the buggy code we found when devices do
> not
> advertise FLAG_SEND_ZLP in which case there is a possibility of
> transferring
> packets with non-deterministic length.
>
> This patch has been tested on kernel-2.6.34-rc3.
> This patch has been checked against net-2.6 tree.
> Signed-off-by: Elina Pasheva <epasheva@sierrawireless.com>
> Signed-off-by: Rory Filer <rfiler@sierrawireless.com>
> ---
>
> drivers/net/usb/usbnet.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> --- a/drivers/net/usb/usbnet.c 2010-04-06 10:52:54.000000000 -0700
> +++ b/drivers/net/usb/usbnet.c 2010-04-06 16:54:44.000000000 -0700
> @@ -1068,12 +1068,15 @@ netdev_tx_t usbnet_start_xmit (struct sk
> * NOTE: strictly conforming cdc-ether devices should expect
> * the ZLP here, but ignore the one-byte packet.
> */
> - if (!(info->flags & FLAG_SEND_ZLP) && (length % dev->maxpacket) ==
> 0) {
> - urb->transfer_buffer_length++;
> - if (skb_tailroom(skb)) {
> - skb->data[skb->len] = 0;
> - __skb_put(skb, 1);
> - }
> + if (length % dev->maxpacket == 0) {
> + if (!(info->flags & FLAG_SEND_ZLP)) {
> + urb->transfer_buffer_length++;
> + if (skb_tailroom(skb)) {
> + skb->data[skb->len] = 0;
> + __skb_put(skb, 1);
> + }
> + } else
> + urb->transfer_flags |= URB_ZERO_PACKET;
You should place braces for the else case as well. See
Documentation/CodingStyle.
It states to use braces in both the branches since the if() case
contains multiple statements.
Maulik
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2010-04-07 5:28 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, netdev, linux-next, linux-kernel, Jiri Pirko
In-Reply-To: <4BBBF9E9.4080504@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
Hi,
On Wed, 07 Apr 2010 11:20:09 +0800 Cong Wang <amwang@redhat.com> wrote:
>
> If I read the combined diff correctly, it looks fine for me.
Thanks for the confirmation.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2010-04-07 5:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, dm, jpirko
In-Reply-To: <20100406.201220.195404728.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
Hi Dave,
On Tue, 06 Apr 2010 20:12:20 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> Thanks, I'll merge net-2.6 into net-next-2.6 and fix this build
> failure in the latter.
Thanks for that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [v2 Patch 3/3] bonding: make bonding support netpoll
From: Cong Wang @ 2010-04-07 4:20 UTC (permalink / raw)
To: Andy Gospodarek
Cc: linux-kernel@vger.kernel.org, Matt Mackall,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
Andy Gospodarek, Neil Horman, Jeff Moyer, Stephen Hemminger,
bonding-devel@lists.sourceforge.net, Jay Vosburgh, David Miller
In-Reply-To: <70501020920527933@unknownmsgid>
Andy Gospodarek wrote:
> On Apr 6, 2010, at 10:32 PM, Cong Wang <amwang@redhat.com> wrote:
>
>> Andy Gospodarek wrote:
>>> On Tue, Apr 06, 2010 at 12:38:16PM +0800, Cong Wang wrote:
>>>> Cong Wang wrote:
>>>>> Before I try to reproduce it, could you please try to replace
>>>>> the 'read_lock()'
>>>>> in slaves_support_netpoll() with 'read_lock_bh()'? (read_unlock()
>>>>> too) Try if this helps.
>>>>>
>>>> Confirmed. Please use the attached patch instead, for your testing.
>>>>
>>>> Thanks!
>>>>
>>> Moving those locks to bh-locks will not resolve this. I tried that
>>> yesterday and tried your new patch today without success. That
>>> warning
>>> is a WARN_ON_ONCE so you need to reboot to see that it is still a
>>> problem. Simply unloading and loading the new module is not an
>>> accurate
>>> test.
>>> Also, my system still hangs when removing the bonding module. I do
>>> not
>>> think you intended to fix this with the patch, but wanted it to be
>>> clear
>>> to everyone on the list.
>>
>> Actually I did reboot and then tested the module. I didn't get any
>> warning.
>> I just tried again today, and no warnings at all.
>>
>> For removing bonding module, you may need another fix of mine,
>> which is to fix a potential deadlock of workqueue. Try:
>>
>> http://lkml.org/lkml/2010/4/1/58
>>
>>> You should also configure your kernel with a some of the lock
>>> debugging
>>> enabled. I've been using the following:
>>> CONFIG_DETECT_HUNG_TASK=y
>>> CONFIG_DEBUG_SPINLOCK=y
>>> CONFIG_DEBUG_MUTEXES=y
>>> CONFIG_DEBUG_LOCK_ALLOC=y
>>> CONFIG_PROVE_LOCKING=y
>>> CONFIG_LOCKDEP=y
>>> CONFIG_LOCK_STAT=y
>>> CONFIG_DEBUG_LOCKDEP=y
>>
>> Sure, I always keep these.
>>
>>> Here is the output when I remove a slave from the bond. My
>>> xmit_roundrobin patch from earlier (replacing read_lock with
>>> read_trylock) was applied. It might be helpful for you when
>>> debugging
>>> these issues.
>>
>> I don't apply your patch, just tested my patch.
>>
>>> Dead loop on virtual device bond0, fix it urgently!
>> Please provide your bonding configuration and steps to reproduce it.
>>
>
> My first response in this thread provides the commands and
> configuration needed to reproduce this.
Then I should do the right thing.
>
>> What I did is:
>>
>> 1. Load bonding module with "mode=0 miimon=100"
>> 2. Enslave eth0 and active bond0
>> 3. Load netconsole and send messages via bond0
>> 4. Remove eth0 from bond0
>> 5. Remove bonding module
>> 6. Remove netconsole module
>
> Thanks for sending your configuration.
>
> What values are in /proc/sys/kernel/printk?
>
I use default values on RHEL5:
6 4 1 7
I don't think this is related with loglevel, what I checked
is dmesg, not just the console screen.
Thanks.
^ permalink raw reply
* linux-next: manual merge of the pcmcia tree with the net tree
From: Stephen Rothwell @ 2010-04-07 4:17 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-next, linux-kernel, Alexander Kurz, David Miller, netdev
Hi Dominik,
Today's linux-next merge of the pcmcia tree got a conflict in
drivers/net/pcmcia/3c589_cs.c between commit
f64e96973a1fa885ce6e4f7e3fdbae83de98fcab ("net/pcmcia/3c589_cs: using
netdev_info and friends where appropriate") from the net tree and commits
cbd8ca0260b78f3b4157dc8ff23edbd211c4eef5 ("pcmcia: re-work
pcmcia_request_irq()") and cc25a704447fad12205ca8c7c42d6bba1c1590b0
("pcmcia: dev_node removal (drivers with unregister_netdev check)") from
the pcmcia tree.
Most of these conflicts are just due to unrelated white space changes in
the net tree commit. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/pcmcia/3c589_cs.c
index 580977f,5ab589d..0000000
--- a/drivers/net/pcmcia/3c589_cs.c
+++ b/drivers/net/pcmcia/3c589_cs.c
@@@ -129,13 -106,12 +129,12 @@@ enum RxFilter
struct el3_private {
struct pcmcia_device *p_dev;
- dev_node_t node;
- /* For transceiver monitoring */
- struct timer_list media;
- u16 media_status;
- u16 fast_poll;
- unsigned long last_irq;
- spinlock_t lock;
+ /* For transceiver monitoring */
+ struct timer_list media;
+ u16 media_status;
+ u16 fast_poll;
+ unsigned long last_irq;
+ spinlock_t lock;
};
static const char *if_names[] = { "auto", "10baseT", "10base2", "AUI" };
@@@ -301,8 -274,8 +297,8 @@@ static int tc589_config(struct pcmcia_d
ret = pcmcia_request_configuration(link, &link->conf);
if (ret)
goto failed;
-
+
- dev->irq = link->irq.AssignedIRQ;
+ dev->irq = link->irq;
dev->base_addr = link->io.BasePort1;
ioaddr = dev->base_addr;
EL3WINDOW(0);
@@@ -335,8 -308,7 +331,7 @@@
dev->if_port = if_port;
else
printk(KERN_ERR "3c589_cs: invalid if_port requested\n");
-
+
- link->dev_node = &lp->node;
SET_NETDEV_DEV(dev, &link->dev);
if (register_netdev(dev) != 0) {
@@@ -344,15 -316,13 +339,12 @@@
goto failed;
}
- strcpy(lp->node.dev_name, dev->name);
-
- printk(KERN_INFO "%s: 3Com 3c%s, io %#3lx, irq %d, "
- "hw_addr %pM\n",
- dev->name, (multi ? "562" : "589"), dev->base_addr, dev->irq,
- dev->dev_addr);
- printk(KERN_INFO " %dK FIFO split %s Rx:Tx, %s xcvr\n",
- (fifo & 7) ? 32 : 8, ram_split[(fifo >> 16) & 3],
- if_names[dev->if_port]);
+ netdev_info(dev, "3Com 3c%s, io %#3lx, irq %d, hw_addr %pM\n",
+ (multi ? "562" : "589"), dev->base_addr, dev->irq,
+ dev->dev_addr);
+ netdev_info(dev, " %dK FIFO split %s Rx:Tx, %s xcvr\n",
+ (fifo & 7) ? 32 : 8, ram_split[(fifo >> 16) & 3],
+ if_names[dev->if_port]);
return 0;
failed:
^ permalink raw reply
* Re: [v2 Patch 3/3] bonding: make bonding support netpoll
From: Andy Gospodarek @ 2010-04-07 4:02 UTC (permalink / raw)
To: Cong Wang
Cc: Jay Vosburgh, Neil Horman, netdev@vger.kernel.org, Matt Mackall,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
David Miller, Jeff Moyer, Andy Gospodarek,
bonding-devel@lists.sourceforge.net
In-Reply-To: <4BBBEEAA.1050100@redhat.com>
On Apr 6, 2010, at 10:32 PM, Cong Wang <amwang@redhat.com> wrote:
> Andy Gospodarek wrote:
>> On Tue, Apr 06, 2010 at 12:38:16PM +0800, Cong Wang wrote:
>>> Cong Wang wrote:
>>>> Before I try to reproduce it, could you please try to replace
>>>> the 'read_lock()'
>>>> in slaves_support_netpoll() with 'read_lock_bh()'? (read_unlock()
>>>> too) Try if this helps.
>>>>
>>> Confirmed. Please use the attached patch instead, for your testing.
>>>
>>> Thanks!
>>>
>> Moving those locks to bh-locks will not resolve this. I tried that
>> yesterday and tried your new patch today without success. That
>> warning
>> is a WARN_ON_ONCE so you need to reboot to see that it is still a
>> problem. Simply unloading and loading the new module is not an
>> accurate
>> test.
>> Also, my system still hangs when removing the bonding module. I do
>> not
>> think you intended to fix this with the patch, but wanted it to be
>> clear
>> to everyone on the list.
>
>
> Actually I did reboot and then tested the module. I didn't get any
> warning.
> I just tried again today, and no warnings at all.
>
> For removing bonding module, you may need another fix of mine,
> which is to fix a potential deadlock of workqueue. Try:
>
> http://lkml.org/lkml/2010/4/1/58
>
>> You should also configure your kernel with a some of the lock
>> debugging
>> enabled. I've been using the following:
>> CONFIG_DETECT_HUNG_TASK=y
>> CONFIG_DEBUG_SPINLOCK=y
>> CONFIG_DEBUG_MUTEXES=y
>> CONFIG_DEBUG_LOCK_ALLOC=y
>> CONFIG_PROVE_LOCKING=y
>> CONFIG_LOCKDEP=y
>> CONFIG_LOCK_STAT=y
>> CONFIG_DEBUG_LOCKDEP=y
>
>
> Sure, I always keep these.
>
>> Here is the output when I remove a slave from the bond. My
>> xmit_roundrobin patch from earlier (replacing read_lock with
>> read_trylock) was applied. It might be helpful for you when
>> debugging
>> these issues.
>
>
> I don't apply your patch, just tested my patch.
>
>> Dead loop on virtual device bond0, fix it urgently!
>
> Please provide your bonding configuration and steps to reproduce it.
>
My first response in this thread provides the commands and
configuration needed to reproduce this.
> What I did is:
>
> 1. Load bonding module with "mode=0 miimon=100"
> 2. Enslave eth0 and active bond0
> 3. Load netconsole and send messages via bond0
> 4. Remove eth0 from bond0
> 5. Remove bonding module
> 6. Remove netconsole module
Thanks for sending your configuration.
What values are in /proc/sys/kernel/printk?
> And no deadlocks, no warnings.
>
> Thanks.
^ permalink raw reply
* linux-next: manual merge of the rr tree with the net tree
From: Stephen Rothwell @ 2010-04-07 3:51 UTC (permalink / raw)
To: Rusty Russell
Cc: linux-next, linux-kernel, David Woodhouse, Ben Hutchings,
David Miller, netdev, Ondrej Zary
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
include/linux/mod_devicetable.h scripts/mod/file2alias.c between commit
8626d3b4328061f5b82b11ae1d6918a0c3602f42 ("phylib: Support phy module
autoloading") from the net tree and commits
df73f69d6a29eb5a22327009627f23c7ae4be007
("modules:isapnp-mod_devicetable.h") and a8e67afa03daca8b570115ba9b33f508cc5a9133 ("MODULE_DEVICE_TABLE(isapnp, ...) does nothing") from the rr tree.
Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/mod_devicetable.h
index 55f1f9c,e69d69f..0000000
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@@ -474,30 -474,11 +474,37 @@@ struct platform_device_id
__attribute__((aligned(sizeof(kernel_ulong_t))));
};
+#define MDIO_MODULE_PREFIX "mdio:"
+
+#define MDIO_ID_FMT "%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d%d"
+#define MDIO_ID_ARGS(_id) \
+ (_id)>>31, ((_id)>>30) & 1, ((_id)>>29) & 1, ((_id)>>28) & 1, \
+ ((_id)>>27) & 1, ((_id)>>26) & 1, ((_id)>>25) & 1, ((_id)>>24) & 1, \
+ ((_id)>>23) & 1, ((_id)>>22) & 1, ((_id)>>21) & 1, ((_id)>>20) & 1, \
+ ((_id)>>19) & 1, ((_id)>>18) & 1, ((_id)>>17) & 1, ((_id)>>16) & 1, \
+ ((_id)>>15) & 1, ((_id)>>14) & 1, ((_id)>>13) & 1, ((_id)>>12) & 1, \
+ ((_id)>>11) & 1, ((_id)>>10) & 1, ((_id)>>9) & 1, ((_id)>>8) & 1, \
+ ((_id)>>7) & 1, ((_id)>>6) & 1, ((_id)>>5) & 1, ((_id)>>4) & 1, \
+ ((_id)>>3) & 1, ((_id)>>2) & 1, ((_id)>>1) & 1, (_id) & 1
+
+/**
+ * struct mdio_device_id - identifies PHY devices on an MDIO/MII bus
+ * @phy_id: The result of
+ * (mdio_read(&MII_PHYSID1) << 16 | mdio_read(&PHYSID2)) & @phy_id_mask
+ * for this PHY type
+ * @phy_id_mask: Defines the significant bits of @phy_id. A value of 0
+ * is used to terminate an array of struct mdio_device_id.
+ */
+struct mdio_device_id {
+ __u32 phy_id;
+ __u32 phy_id_mask;
+};
+
+ #define ISAPNP_ANY_ID 0xffff
+ struct isapnp_device_id {
+ unsigned short card_vendor, card_device;
+ unsigned short vendor, function;
+ kernel_ulong_t driver_data; /* data private to the driver */
+ };
+
#endif /* LINUX_MOD_DEVICETABLE_H */
diff --cc scripts/mod/file2alias.c
index 36a60a8,6494f5b..0000000
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@@ -796,28 -796,19 +796,41 @@@ static int do_platform_entry(const cha
return 1;
}
+static int do_mdio_entry(const char *filename,
+ struct mdio_device_id *id, char *alias)
+{
+ int i;
+
+ alias += sprintf(alias, MDIO_MODULE_PREFIX);
+
+ for (i = 0; i < 32; i++) {
+ if (!((id->phy_id_mask >> (31-i)) & 1))
+ *(alias++) = '?';
+ else if ((id->phy_id >> (31-i)) & 1)
+ *(alias++) = '1';
+ else
+ *(alias++) = '0';
+ }
+
+ /* Terminate the string */
+ *alias = 0;
+
+ return 1;
+}
+
+ /* looks like: "pnp:dD" */
+ static int do_isapnp_entry(const char *filename,
+ struct isapnp_device_id *id, char *alias)
+ {
+ sprintf(alias, "pnp:d%c%c%c%x%x%x%x*",
+ 'A' + ((id->vendor >> 2) & 0x3f) - 1,
+ 'A' + (((id->vendor & 3) << 3) | ((id->vendor >> 13) & 7)) - 1,
+ 'A' + ((id->vendor >> 8) & 0x1f) - 1,
+ (id->function >> 4) & 0x0f, id->function & 0x0f,
+ (id->function >> 12) & 0x0f, (id->function >> 8) & 0x0f);
+ return 1;
+ }
+
/* Ignore any prefix, eg. some architectures prepend _ */
static inline int sym_is(const char *symbol, const char *name)
{
@@@ -965,10 -956,10 +978,14 @@@ void handle_moddevtable(struct module *
do_table(symval, sym->st_size,
sizeof(struct platform_device_id), "platform",
do_platform_entry, mod);
+ else if (sym_is(symname, "__mod_mdio_device_table"))
+ do_table(symval, sym->st_size,
+ sizeof(struct mdio_device_id), "mdio",
+ do_mdio_entry, mod);
+ else if (sym_is(symname, "__mod_isapnp_device_table"))
+ do_table(symval, sym->st_size,
+ sizeof(struct isapnp_device_id), "isa",
+ do_isapnp_entry, mod);
free(zeros);
}
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with Linus' tree
From: Cong Wang @ 2010-04-07 3:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Jiri Pirko
In-Reply-To: <20100407125836.3c7f1095.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/bonding/bond_main.c between commit
> 9e2e61fbf8ad016d24e4af0afff13505f3dd2a2a ("bonding: fix potential
> deadlock in bond_uninit()") from Linus' tree and commit
> 22bedad3ce112d5ca1eaf043d4990fa2ed698c87 ("net: convert multicast list to
> list_head") from the net tree.
>
> Just context changes. If fixed it up (see below) and can carry the fix
> for a while.
Hi, Stephen,
If I read the combined diff correctly, it looks fine for me.
Thanks for letting me know!
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: David Miller @ 2010-04-07 3:12 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, dm, jpirko
In-Reply-To: <20100407125817.e8e1d174.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 7 Apr 2010 12:58:17 +1000
> After merging the wireless tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/net/cxgb4/cxgb4_main.c: In function 'set_addr_filters':
> drivers/net/cxgb4/cxgb4_main.c:264: error: dereferencing pointer to incomplete type
> drivers/net/cxgb4/cxgb4_main.c:265: error: dereferencing pointer to incomplete type
>
> Caused by commit b8ff05a9c3237f694a1c3bf8ceec3bf6c3c14b15 ("cxgb4: Add
> main driver file and driver Makefile") from Linus' tree interacting with
> commit 22bedad3ce112d5ca1eaf043d4990fa2ed698c87 ("net: convert multicast
> list to list_head"). The latter removed struct dev_addr_list.
>
> I have reverted commit b8ff05a9c3237f694a1c3bf8ceec3bf6c3c14b15 (and
> 43e9da8d782b8a40d5127fcc59ac2e543cf16d7d ("net: Hook up cxgb4 to Kconfig
> and Makefile") that depended on it) for today.
Thanks, I'll merge net-2.6 into net-next-2.6 and fix this build
failure in the latter.
^ permalink raw reply
* linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2010-04-07 2:58 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Francois Romieu
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/via-velocity.c between commit
bcbe53682f65330bdd9ad7eed9575d2ff536353a ("via-velocity: Fix
FLOW_CNTL_TX_RX handling in set_mii_flow_control()") from Linus' tree and
commit 3a7f8681ffb27bcc540fb74cda15e39c9395737b ("via-velocity: remove
private #define") from the net tree.
I fixed it up (see below) and can carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/via-velocity.c
index bc278d4,078903f..0000000
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@@ -811,8 -811,8 +811,8 @@@ static void set_mii_flow_control(struc
break;
case FLOW_CNTL_TX_RX:
- MII_REG_BITS_ON(ANAR_PAUSE, MII_REG_ANAR, vptr->mac_regs);
- MII_REG_BITS_OFF(ANAR_ASMDIR, MII_REG_ANAR, vptr->mac_regs);
+ MII_REG_BITS_ON(ADVERTISE_PAUSE_CAP, MII_ADVERTISE, vptr->mac_regs);
- MII_REG_BITS_ON(ADVERTISE_PAUSE_ASYM, MII_ADVERTISE, vptr->mac_regs);
++ MII_REG_BITS_OFF(ADVERTISE_PAUSE_ASYM, MII_ADVERTISE, vptr->mac_regs);
break;
case FLOW_CNTL_DISABLE:
^ permalink raw reply
* linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2010-04-07 2:58 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Amerigo Wang, Jiri Pirko
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/bonding/bond_main.c between commit
9e2e61fbf8ad016d24e4af0afff13505f3dd2a2a ("bonding: fix potential
deadlock in bond_uninit()") from Linus' tree and commit
22bedad3ce112d5ca1eaf043d4990fa2ed698c87 ("net: convert multicast list to
list_head") from the net tree.
Just context changes. If fixed it up (see below) and can carry the fix
for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/bonding/bond_main.c
index 0075514,22682f1..0000000
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@@ -4550,9 -4476,10 +4508,7 @@@ static void bond_uninit(struct net_devi
bond_remove_proc_entry(bond);
- netif_addr_lock_bh(bond_dev);
- bond_mc_list_destroy(bond);
- netif_addr_unlock_bh(bond_dev);
- if (bond->wq)
- destroy_workqueue(bond->wq);
-
+ __hw_addr_flush(&bond->mc_list);
}
/*------------------------- Module initialization ---------------------------*/
^ permalink raw reply
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2010-04-07 2:58 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Dimitris Michailidis, Jiri Pirko
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
Hi Dave,
After merging the wireless tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/net/cxgb4/cxgb4_main.c: In function 'set_addr_filters':
drivers/net/cxgb4/cxgb4_main.c:264: error: dereferencing pointer to incomplete type
drivers/net/cxgb4/cxgb4_main.c:265: error: dereferencing pointer to incomplete type
Caused by commit b8ff05a9c3237f694a1c3bf8ceec3bf6c3c14b15 ("cxgb4: Add
main driver file and driver Makefile") from Linus' tree interacting with
commit 22bedad3ce112d5ca1eaf043d4990fa2ed698c87 ("net: convert multicast
list to list_head"). The latter removed struct dev_addr_list.
I have reverted commit b8ff05a9c3237f694a1c3bf8ceec3bf6c3c14b15 (and
43e9da8d782b8a40d5127fcc59ac2e543cf16d7d ("net: Hook up cxgb4 to Kconfig
and Makefile") that depended on it) for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] net/irda: Add SuperH IrDA driver support
From: David Miller @ 2010-04-07 2:52 UTC (permalink / raw)
To: kuninori.morimoto.gx; +Cc: netdev, samuel
In-Reply-To: <uy6h15gtn.wl%kuninori.morimoto.gx@renesas.com>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: Tue, 06 Apr 2010 13:46:12 +0900 (JST)
> This is very simple driver for SuperH Mobile IrDA
> which support SIR/MIR/FIR.
> This patch add only SIR support for now.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied to net-next-2.6, thank you.
^ permalink raw reply
* Re: [PATCH 0/2] net/irda: sh_sir: Bug fix patches
From: David Miller @ 2010-04-07 2:52 UTC (permalink / raw)
To: kuninori.morimoto.gx; +Cc: netdev, samuel
In-Reply-To: <u39z96vk2.wl%kuninori.morimoto.gx@renesas.com>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: Tue, 06 Apr 2010 13:42:39 +0900 (JST)
>
> Dear David
>
> Kuninori Morimoto (2):
> net/irda: sh_sir: fixup err return value on sh_sir_open
> net/irda: sh_sir: Modify iounmap wrong execution
>
> These 2 patches are bug fix of sh_sir driver.
Both applied to net-next-2.6, thank you.
^ permalink raw reply
* newbie question about qdisc_watchdog_schedule
From: Yongjian Zhang @ 2010-04-07 2:52 UTC (permalink / raw)
To: netdev
Hi all,
I have a newbie question about qdisc_watchdog_schedule(). This
function appears in the source code of several qdiscs and it seems to
be used when the qdisc is asked to dequeue a packet but cannot.
I tried to trace the source code but only found some function calls to
start a timer. No callback function seems to be involved...
Google did not give me any documentation to this function either...
Can anyone maybe show me what does qdisc_watchdog_schedule() do and/or
why we have to call it when there's no packet to dequeue?
Thanks a lot!
Jack
^ permalink raw reply
* Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
From: David Miller @ 2010-04-07 2:52 UTC (permalink / raw)
To: eric.dumazet
Cc: john.linn, netdev, linuxppc-dev, grant.likely, jwboyer,
john.williams, michal.simek, jtyner
In-Reply-To: <1270502993.9013.36.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 05 Apr 2010 23:29:53 +0200
> So, I ask, cant you use netdev_alloc_skb_ip_align() in this driver ?
Thanks to everyone for getting this patch into shape.
I applied version 4 of the patch to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH] socket: remove duplicate declaration of struct timespec
From: David Miller @ 2010-04-07 2:51 UTC (permalink / raw)
To: hagen; +Cc: netdev
In-Reply-To: <1270568392-22030-1-git-send-email-hagen@jauu.net>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Tue, 6 Apr 2010 17:39:52 +0200
> struct timespec ts was alreay defined. Reuse the previously
> defined one and reduce the memory footprint on the stack by
> 16 bytes.
>
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] TIPC: Updated topology subscription protocol according to latest spec
From: David Miller @ 2010-04-07 2:51 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion
In-Reply-To: <1270590052-975-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 6 Apr 2010 17:40:52 -0400
> This patch makes it explicit in the API that all fields in subscriptions and events exchanged with the Topology Server must be in
> network byte order.
> It also ensures that all fields of a subscription are compared when cancelling a subscription, in order to avoid inadvertent
> cancelling of the wrong subscription.
> Finally, the tipc module version is updated to 2.0.0, to reflect the API change.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] NET: usb: Adding URB_ZERO_PACKET flag to usbnet.c
From: David Miller @ 2010-04-07 2:50 UTC (permalink / raw)
To: epasheva; +Cc: dbrownell, rfiler, netdev, linux-usb
In-Reply-To: <1270599787.8900.8.camel@Linuxdev4-laptop>
From: Elina Pasheva <epasheva@sierrawireless.com>
Date: Tue, 6 Apr 2010 17:23:07 -0700
> Subject: [PATCH 1/1] NET: usb: Adding URB_ZERO_PACKET flag to usbnet.c
> From: Elina Pasheva <epasheva@sierrawireless.com>
> This patch adds setting of the urb transfer flag URB_ZERO_PACKET before
> submitting an urb for drivers that have requested it (by advertising flag
> FLAG_SEND_ZLP).
> The modification is in usbnet.c function usbnet_start_xmit().
> This patch only adds the zero length flag.
> A subsequent patch will address the buggy code we found when devices do not
> advertise FLAG_SEND_ZLP in which case there is a possibility of transferring
> packets with non-deterministic length.
>
> This patch has been tested on kernel-2.6.34-rc3.
> This patch has been checked against net-2.6 tree.
> Signed-off-by: Elina Pasheva <epasheva@sierrawireless.com>
> Signed-off-by: Rory Filer <rfiler@sierrawireless.com>
Applied to net-next-2.6, thanks.
^ 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