* Re: [PATCH] aoe: remove dev_base_lock use from aoecmd_cfg_pkts()
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ecashin
In-Reply-To: <1288350929.2560.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 29 Oct 2010 13:15:29 +0200
> dev_base_lock is the legacy way to lock the device list, and is planned
> to disappear. (writers hold RTNL, readers hold RCU lock)
>
> Convert aoecmd_cfg_pkts() to RCU locking.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: remove dev_base_lock use
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, fubar
In-Reply-To: <1288353166.2560.22.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 29 Oct 2010 13:52:46 +0200
> bond_info_seq_start() uses a read_lock(&dev_base_lock) to make sure
> device doesn’t disappear. Same goal can be achieved using RCU.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] decnet: RCU conversion and get rid of dev_base_lock
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: steve; +Cc: eric.dumazet, netdev
In-Reply-To: <1288360479.9016.35.camel@dolmen>
From: Steven Whitehouse <steve@chygwyn.com>
Date: Fri, 29 Oct 2010 14:54:39 +0100
> Hi,
>
> On Fri, 2010-10-29 at 15:09 +0200, Eric Dumazet wrote:
>> While tracking dev_base_lock users, I found decnet used it in
>> dnet_select_source(), but for a wrong purpose:
>>
>> Writers only hold RTNL, not dev_base_lock, so readers must use RCU if
>> they cannot use RTNL.
>>
>> Adds an rcu_head in struct dn_ifaddr and handle proper RCU management.
>>
>> Adds __rcu annotation in dn_route as well.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> I've not tested this, but I've read through it all and it seems good to
> me.
>
> Acked-by: Steven Whitehouse <swhiteho@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] af_unix: fix unix_dgram_poll() behavior for EPOLLOUT event
From: David Miller @ 2010-11-08 21:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: alban.crequy, netdev, davidel
In-Reply-To: <1288539383.2660.38.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 31 Oct 2010 16:36:23 +0100
> [PATCH 1/2] af_unix: fix unix_dgram_poll() behavior for EPOLLOUT event
>
> Alban Crequy reported a problem with connected dgram af_unix sockets and
> provided a test program. epoll() would miss to send an EPOLLOUT event
> when a thread unqueues a packet from the other peer, making its receive
> queue not full.
>
> This is because unix_dgram_poll() fails to call sock_poll_wait(file,
> &unix_sk(other)->peer_wait, wait);
> if the socket is not writeable at the time epoll_ctl(ADD) is called.
>
> We must call sock_poll_wait(), regardless of 'writable' status, so that
> epoll can be notified later of states changes.
>
> Misc: avoids testing twice (sk->sk_shutdown & RCV_SHUTDOWN)
>
> Reported-by: Alban Crequy <alban.crequy@collabora.co.uk>
> Cc: Davide Libenzi <davidel@xmailserver.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] af_unix: unix_write_space() use keyed wakeups
From: David Miller @ 2010-11-08 21:44 UTC (permalink / raw)
To: davidel
Cc: eric.dumazet, alban.crequy, shemminger, gorcunov, adobriyan,
netdev, linux-kernel, pauli.nieminen, rweikusat
In-Reply-To: <alpine.DEB.2.00.1010300759580.9195@localhost6.localdomain6>
From: Davide Libenzi <davidel@xmailserver.org>
Date: Sat, 30 Oct 2010 08:03:15 -0700 (PDT)
> On Sat, 30 Oct 2010, Eric Dumazet wrote:
>
>> This patch is a specialization of commit 37e5540b3c9d (epoll keyed
>> wakeups: make sockets use keyed wakeups).
>
> Whoops, I must have missed AF_UNIX :)
> Looks good to me.
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] af_unix: optimize unix_dgram_poll()
From: David Miller @ 2010-11-08 21:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, davidel, alban.crequy
In-Reply-To: <1288539505.2660.41.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 31 Oct 2010 16:38:25 +0100
> unix_dgram_poll() is pretty expensive to check POLLOUT status, because
> it has to lock the socket to get its peer, take a reference on the peer
> to check its receive queue status, and queue another poll_wait on
> peer_wait. This all can be avoided if the process calling
> unix_dgram_poll() is not interested in POLLOUT status. It makes
> unix_dgram_recvmsg() faster by not queueing irrelevant pollers in
> peer_wait.
>
> On a test program provided by Alan Crequy :
>
> Before:
>
> real 0m0.211s
> user 0m0.000s
> sys 0m0.208s
>
> After:
>
> real 0m0.044s
> user 0m0.000s
> sys 0m0.040s
>
> Suggested-by: Davide Libenzi <davidel@xmailserver.org>
> Reported-by: Alban Crequy <alban.crequy@collabora.co.uk>
> Acked-by: Davide Libenzi <davidel@xmailserver.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/2] qlge: Add firmware info to ethtool get regs.
From: David Miller @ 2010-11-08 21:49 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, jitendra.kalsaria, ying.lok
In-Reply-To: <20101108.134302.102548897.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 08 Nov 2010 13:43:02 -0800 (PST)
> From: Ron Mercer <ron.mercer@qlogic.com>
> Date: Wed, 27 Oct 2010 07:58:26 -0700
>
>> By default we add firmware information to ethtool get regs.
>> Optionally firmware info can instead be sent to log.
>>
>> Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
>
> Applied.
Nevermind, reverted, can you please more carefully build test
your changes?
drivers/net/qlge/qlge_mpi.c:90:12: error: static declaration of 'ql_soft_reset_mpi_risc' follows non-static declaration
drivers/net/qlge/qlge.h:2224:5: note: previous declaration of 'ql_soft_reset_mpi_risc' was here
The line that added the extern declaration to qlge.h seems to be completely
unrelated to the rest of the patch, as if it's a mis-commit or something
from another change you were working on.
^ permalink raw reply
* GIT: net-next-2.6 is now active...
From: David Miller @ 2010-11-08 22:05 UTC (permalink / raw)
To: netdev
I've started the net-next-2.6 tree going, and I'll push
out the initial set of changes (the ones that actually
compile, grumble...) shortly.
I could have started things up last week, but with kernel
summit and LPC there just wasn't much time or justification.
Probably the most interesting thing in this initial set are
the AF_UNIX poll optimizations from Eric Dumazet.
^ permalink raw reply
* [PATCH] Fix header size check for GSO case in recvmsg (af_packet)
From: Mariusz Kozlowski @ 2010-11-08 21:58 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: David S. Miller, netdev, linux-kernel, Mariusz Kozlowski
Parameter 'len' is size_t type so it will never get negative.
Signed-off-by: Mariusz Kozlowski <mk@lab.zgora.pl>
---
net/packet/af_packet.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 3616f27..3451191 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1610,9 +1610,11 @@ static int packet_recvmsg(struct kiocb *iocb, struct socket *sock,
err = -EINVAL;
vnet_hdr_len = sizeof(vnet_hdr);
- if ((len -= vnet_hdr_len) < 0)
+ if (len < vnet_hdr_len)
goto out_free;
+ len -= vnet_hdr_len;
+
if (skb_is_gso(skb)) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 2/2] ipv6: Warn users if maximum number of routes is reached.
From: Ben Greear @ 2010-11-08 22:33 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
This gives users at least some clue as to what the problem
might be and how to go about fixing it.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v1 -> v2: Put warning in correct place.
:100644 100644 a275c6e... 9d9d0e9... M net/ipv6/route.c
net/ipv6/route.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a275c6e..9d9d0e9 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1941,8 +1941,12 @@ struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev,
struct rt6_info *rt = ip6_dst_alloc(&net->ipv6.ip6_dst_ops);
struct neighbour *neigh;
- if (rt == NULL)
+ if (rt == NULL) {
+ if (net_ratelimit())
+ pr_warning("IPv6: Maximum number of routes reached,"
+ " consider increasing route/max_size.\n");
return ERR_PTR(-ENOMEM);
+ }
dev_hold(net->loopback_dev);
in6_dev_hold(idev);
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 01/11] vxge: enable rxhash
From: Jon Mason @ 2010-11-08 22:53 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Sivakumar Subramani, Sreenivasa Honnur,
Ramkrishna Vepa
In-Reply-To: <20101108.124452.115944240.davem@davemloft.net>
On Mon, Nov 08, 2010 at 12:44:52PM -0800, David Miller wrote:
>
> This patch set doesn't apply at all to the current tree, please
> respin them, thanks.
When I sent out the series on Thursday, the tree did not have
"vxge: make functions local and remove dead code". When that patch
was originally released (Oct 15), I asked for it to not be included as
it would break soon-to-be-released patch series. I did not see any
e-mail afterward, so I assumed this was acceptable to you. We then
ran the driver though our internal tests to verify its functionality,
which would need to be re-done if the patches are respun.
I have a reworked version of that patch which can be applied after
this patch series. Is it acceptable to you to revert the commit,
apply the series, then apply the modified version of the "local
functions" patch? I have already sniff tested it on our hardware
without issues.
Thanks,
Jon
^ permalink raw reply
* [PATCH 07/17][trivial] net, wireless: Remove unnecessary casts of void ptr returning alloc function return values
From: Jesper Juhl @ 2010-11-08 23:09 UTC (permalink / raw)
To: linux-kernel
Cc: trivial, Ulrich Kunitz, Daniel Drake, John W. Linville,
linux-wireless, netdev
Hi,
The [vk][cmz]alloc(_node) family of functions return void pointers which
it's completely unnecessary/pointless to cast to other pointer types since
that happens implicitly.
This patch removes such casts from drivers/net/
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
zd_chip.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c b/drivers/net/wireless/zd1211rw/zd_chip.c
index 87a95bc..dfcebed 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -117,8 +117,7 @@ int zd_ioread32v_locked(struct zd_chip *chip, u32 *values, const zd_addr_t *addr
/* Allocate a single memory block for values and addresses. */
count16 = 2*count;
- a16 = (zd_addr_t *) kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)),
- GFP_KERNEL);
+ a16 = kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)), GFP_KERNEL);
if (!a16) {
dev_dbg_f(zd_chip_dev(chip),
"error ENOMEM in allocation of a16\n");
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 1/2] r8169: revert "Handle rxfifo errors on 8168 chips"
From: Francois Romieu @ 2010-11-08 23:23 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Andreas Radke, Matthew Garrett, Daniel J Blueman
The original patch helps under obscure conditions (no pun) but
some 8168 do not like it. The change needs to be tightened with
a specific 8168 version.
This reverts commit 801e147cde02f04b5c2f42764cd43a89fc7400a2.
Regression at https://bugzilla.kernel.org/show_bug.cgi?id=20882
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Andreas Radke <a.radke@arcor.de>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Daniel J Blueman <daniel.blueman@gmail.com>
---
drivers/net/r8169.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index d88ce9f..3a0877e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2931,7 +2931,7 @@ static const struct rtl_cfg_info {
.hw_start = rtl_hw_start_8168,
.region = 2,
.align = 8,
- .intr_event = SYSErr | RxFIFOOver | LinkChg | RxOverflow |
+ .intr_event = SYSErr | LinkChg | RxOverflow |
TxErr | TxOK | RxOK | RxErr,
.napi_event = TxErr | TxOK | RxOK | RxOverflow,
.features = RTL_FEATURE_GMII | RTL_FEATURE_MSI,
@@ -4588,7 +4588,8 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
}
/* Work around for rx fifo overflow */
- if (unlikely(status & RxFIFOOver)) {
+ if (unlikely(status & RxFIFOOver) &&
+ (tp->mac_version == RTL_GIGA_MAC_VER_11)) {
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
break;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] r8169: fix sleeping while holding spinlock.
From: Francois Romieu @ 2010-11-08 23:23 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Daniel J Blueman, Rafael J. Wysocki
As device_set_wakeup_enable can now sleep, move the call to outside
the critical section.
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/net/r8169.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 3a0877e..4c4d169 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -846,10 +846,10 @@ static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
else
tp->features &= ~RTL_FEATURE_WOL;
__rtl8169_set_wol(tp, wol->wolopts);
- device_set_wakeup_enable(&tp->pci_dev->dev, wol->wolopts);
-
spin_unlock_irq(&tp->lock);
+ device_set_wakeup_enable(&tp->pci_dev->dev, wol->wolopts);
+
return 0;
}
--
1.7.2.3
^ permalink raw reply related
* Re: [2.6.37-rc1, patch] gianfar: fix sleep in atomic...
From: Rafael J. Wysocki @ 2010-11-08 23:30 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: David S. Miller, Francois Romieu, Linux Kernel, netdev
In-Reply-To: <AANLkTimf_mVrRPEcj8qBbYw1iYHfWdeKUNS3Kk-dfhTT@mail.gmail.com>
On Tuesday, November 02, 2010, Daniel J Blueman wrote:
> Since device_set_wakeup_enable now sleeps, it should not be called
> from a critical section. Since wol_en is not updated elsewhere, we can
> omit the locking entirely.
>
> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
> index 5c566eb..e641d7c 100644
> --- a/drivers/net/gianfar_ethtool.c
> +++ b/drivers/net/gianfar_ethtool.c
> @@ -635,10 +635,8 @@ static int gfar_set_wol(struct net_device *dev,
> struct ethtool_wolinfo *wol)
> if (wol->wolopts & ~WAKE_MAGIC)
> return -EINVAL;
>
> - spin_lock_irqsave(&priv->bflock, flags);
> priv->wol_en = wol->wolopts & WAKE_MAGIC ? 1 : 0;
> device_set_wakeup_enable(&dev->dev, priv->wol_en);
> - spin_unlock_irqrestore(&priv->bflock, flags);
>
> return 0;
> }
>
^ permalink raw reply
* Re: Netlink limitations
From: Pablo Neira Ayuso @ 2010-11-08 23:36 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Thomas Graf, Patrick McHardy, David S. Miller, netdev
In-Reply-To: <alpine.LNX.2.01.1011081958410.31946@obet.zrqbmnf.qr>
On 08/11/10 20:21, Jan Engelhardt wrote:
> On Monday 2010-11-08 16:16, Thomas Graf wrote:
>>>
>>> Messages are not limited to 64k, individual attributes are. Holger
>>> started working on a nlattr32, which uses 32 bit for the length
>>> value.
>>
>> Also, it is not required to pack everything in attributes. Your protocol
>> may specify that the whole message payload consists of chained attributes.
>> Alternatively you may as well split your attribut chain and dump them
>> as several messages.
>
> Yeah with NETLINK_URELEASE that seems the way to go. However, what are
> compelling arguments to use Netlink over other forms of bidirectional
> communication? (To play devils advocate, one could use nlattr32/TLVs
> over ioctl too.)
Netlink also provides an event-based notification infrastructure. Of
course, you can implement that upon a new socket family that supports
your new ioctls operations taking things in TLV format.
However, I guess that the whole thing will start looking like netlink
quite a lot in the end ;-).
^ permalink raw reply
* Re: [Bugme-new] [Bug 22142] New: skge module doesn't work in 2.6.37-rc1
From: Andrew Morton @ 2010-11-08 23:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bugzilla-daemon, bugme-daemon, netdev, jtmettala
In-Reply-To: <bug-22142-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 5 Nov 2010 23:14:21 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=22142
>
> Summary: skge module doesn't work in 2.6.37-rc1
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.37-rc1
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: jtmettala@gmail.com
> Regression: Yes
>
>
> Here is original report.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/670955
>
> I hope attached file has enough information. It has a trace.
>
skge_devinit() did a nearly-NULL deref.
[ 8.521324] Intel ICH 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 8.521384] Intel ICH 0000:00:1f.5: setting latency timer to 64
[ 8.683032] skge 0000:02:05.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 8.683091] skge: 1.13 addr 0xfbffc000 irq 22 chip Yukon-Lite rev 7
[ 8.696044] BUG: unable to handle kernel NULL pointer dereference at 00000008
[ 8.696162] IP: [<f800a215>] skge_devinit+0x1a5/0x210 [skge]
[ 8.696246] *pde = 00000000
[ 8.696320] Oops: 0002 [#1] SMP
[ 8.696425] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/input/input4/mouse1/uevent
[ 8.696478] Modules linked in: skge(+) i2c_algo_bit joydev snd_mpu401 snd_mpu401_uart snd_seq_midi snd_intel8x0(+) usbhid hid snd_ac97_codec snd_rawmidi snd_seq_midi_event snd_seq ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd ppdev firewire_sbp2 shpchp parport_pc asus_atk0110 firewire_core floppy crc_itu_t ns558 soundcore gameport psmouse serio_raw lp parport
[ 8.697688]
[ 8.697730] Pid: 329, comm: modprobe Not tainted 2.6.37-2-generic #9-Ubuntu P5P800/To Be Filled By O.E.M.
[ 8.697783] EIP: 0060:[<f800a215>] EFLAGS: 00010246 CPU: 0
[ 8.697829] EIP is at skge_devinit+0x1a5/0x210 [skge]
[ 8.697872] EAX: 00000000 EBX: f5fbb000 ECX: 00000000 EDX: 00000000
[ 8.697916] ESI: f5fbb440 EDI: f5f68300 EBP: f5ff5dfc ESP: f5ff5de4
[ 8.697960] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 8.698004] Process modprobe (pid: 329, ti=f5ff4000 task=f5880000 task.ti=f5ff4000)
[ 8.698054] Stack:
[ 8.698093] 00000040 f5f68300 00000000 f6581000 00000000 f5f68300 f5ff5e3c f800f789
[ 8.698400] f800fdd4 f800febd fbffc000 00000000 00000016 f8010131 00000007 c0423af5
[ 8.698706] 00000292 00000001 f5f68344 f6581000 f5ff5e5c f6581060 f5ff5e54 c0388937
[ 8.699012] Call Trace:
[ 8.699059] [<f800f789>] ? skge_probe+0x284/0x41b [skge]
[ 8.699108] [<c0423af5>] ? pm_runtime_enable+0x45/0x70
[ 8.699155] [<c0388937>] ? local_pci_probe+0x47/0xb0
[ 8.699201] [<c0389e18>] ? pci_device_probe+0x68/0x90
[ 8.699247] [<c041cb6d>] ? really_probe+0x4d/0x150
[ 8.699292] [<c0424fab>] ? pm_runtime_barrier+0x4b/0xb0
[ 8.699337] [<c041ce0c>] ? driver_probe_device+0x3c/0x60
[ 8.699383] [<c041ceb1>] ? __driver_attach+0x81/0x90
[ 8.699428] [<c041ce30>] ? __driver_attach+0x0/0x90
[ 8.699473] [<c041be98>] ? bus_for_each_dev+0x48/0x70
[ 8.699518] [<c041ca1e>] ? driver_attach+0x1e/0x20
[ 8.699562] [<c041ce30>] ? __driver_attach+0x0/0x90
[ 8.699606] [<c041c5d1>] ? bus_add_driver+0xc1/0x2c0
[ 8.699652] [<c03897c0>] ? pci_device_remove+0x0/0xf0
[ 8.699697] [<c041d0f6>] ? driver_register+0x66/0x110
[ 8.699742] [<c04fd807>] ? dmi_matches+0x47/0xb0
[ 8.699787] [<c0388ed5>] ? __pci_register_driver+0x45/0xb0
[ 8.699834] [<f802102f>] ? skge_init_module+0x2f/0x31 [skge]
[ 8.699880] [<c0101255>] ? do_one_initcall+0x35/0x170
[ 8.699927] [<f8021000>] ? skge_init_module+0x0/0x31 [skge]
[ 8.699973] [<c018807b>] ? sys_init_module+0x9b/0x1e0
[ 8.700012] [<c02252a2>] ? sys_write+0x42/0x70
[ 8.700012] [<c010309f>] ? sysenter_do_call+0x12/0x28
[ 8.700012] Code: 40 04 66 89 42 04 0f b6 8b 21 01 00 00 8d 83 00 01 00 00 8b 93 78 01 00 00 e8 c8 a9 36 c8 89 d8 e8 b1 57 52 c8 8b 83 00 02 00 00 <f0> 80 48 08 01 83 c4 0c 89 d8 5b 5e 5f 5d c3 8d 74 26 00 31 d2
[ 8.700012] EIP: [<f800a215>] skge_devinit+0x1a5/0x210 [skge] SS:ESP 0068:f5ff5de4
[ 8.700012] CR2: 0000000000000008
[ 8.702518] ---[ end trace 997185377b275fcf ]---
^ permalink raw reply
* Re: [PATCH 2/2] r8169: fix sleeping while holding spinlock.
From: Andrew Hendry @ 2010-11-08 23:48 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev, David S. Miller, Daniel J Blueman, Rafael J. Wysocki
In-Reply-To: <20101108232358.GB13720@electric-eye.fr.zoreil.com>
Was getting this error on boot "BUG: scheduling while atomic:
ethtool/1430/0x00000002" patch fixed them.
Acked-by: Andrew Hendry <andrew.hendry@gmail.com>
On Tue, Nov 9, 2010 at 10:23 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> As device_set_wakeup_enable can now sleep, move the call to outside
> the critical section.
>
> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
> Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
> drivers/net/r8169.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 3a0877e..4c4d169 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -846,10 +846,10 @@ static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> else
> tp->features &= ~RTL_FEATURE_WOL;
> __rtl8169_set_wol(tp, wol->wolopts);
> - device_set_wakeup_enable(&tp->pci_dev->dev, wol->wolopts);
> -
> spin_unlock_irq(&tp->lock);
>
> + device_set_wakeup_enable(&tp->pci_dev->dev, wol->wolopts);
> +
> return 0;
> }
>
> --
> 1.7.2.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
>
^ permalink raw reply
* Re: Loopback performance from kernel 2.6.12 to 2.6.37
From: Andrew Hendry @ 2010-11-09 0:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jesper Dangaard Brouer, netdev
In-Reply-To: <1289228785.2820.203.camel@edumazet-laptop>
results on an i7 860 @ 2.80Ghz machine, no virtualization involved. 2.6.37-rc1+
# time dd if=/dev/zero bs=1M count=10000 | netcat 127.0.0.1 9999
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 50.2022 s, 209 MB/s
real 0m50.210s
user 0m1.094s
sys 0m57.589s
On Tue, Nov 9, 2010 at 2:06 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 08 novembre 2010 à 12:04 +0100, Eric Dumazet a écrit :
>> Le lundi 08 novembre 2010 à 11:58 +0100, Jesper Dangaard Brouer a
>> écrit :
>> > On Fri, 2010-11-05 at 21:29 +0100, Eric Dumazet wrote:
>> > > Le vendredi 05 novembre 2010 à 11:49 +0100, Jesper Dangaard Brouer a
>> > > écrit :
>> > > > Hi Eric,
>> > > >
>> > > > A colleague send me a link to someone who has done some quite extensive
>> > > > performance measurements across different kernel versions.
>> > > >
>> > > > I noticed that the loopback performance has gotten quite bad:
>> > > >
>> > > > http://www.phoronix.com/scan.php?page=article&item=linux_2612_2637&num=6
>> > > >
>> > > > I though you might be interested in the link.
>> > > >
>> > > > See you around :-)
>> > >
>> > > Hi !
>> > >
>> > > Problem is : I have no idea what test they exactly use,
>> > > do you have info about it ?
>> >
>> > Its called the Phoronix test-suite, their website is:
>> > http://www.phoronix-test-suite.com/?k=home
>> >
>> > On my Ubuntu workstation their software comes as a software package:
>> > sudo aptitude install phoronix-test-suite
>> >
>> > They seem to be related to the test/review site:
>> > http://www.phoronix.com/
>> >
>> >
>> >
>> > > This probably can be explained very fast.
>> >
>> > The loopback test seems to be the only real networking test they do.
>> > It looks like they just copy a very big fil via loopback, and record the
>> > time it took... quite simple.
>> >
>> > Their tests seems to be focused on CPU util/speed, graphics/games.
>> >
>> >
>> > The thing that caught my attention, was that they seemed interested in
>> > doing performance regression testing on all kernel versions...
>> >
>> > So, I though, it would be great if someone else would do automated
>> > performance regression testing for us :-), Too bad they only have a
>> > very simple network test.
>> >
>> >
>>
>
>>
>
> CC netdev, if you dont mind.
>
>
> Their network test is basically :
>
> netcat -l 9999 >/dev/null &
> time dd if=/dev/zero bs=1M count=10000 | netcat 127.0.0.1 9999
>
> They say it takes 38 seconds on their "super fast" processor
>
> On my dev machine, not super fast (E5540 @2.53GHz), I get 8 or 9
> seconds, even if only one CPU is online, all others offline.
>
> Go figure... maybe an artifact of the virtualization they use.
>
> I suspect some problem with the ticket spinlocks and a call to
> hypervisor to say 'I am spinning on a spinlock, see if you need to do
> something useful', or maybe ACPI problem (going to/from idle)
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Takes > 1 second to delete macvlan with global IPv6 address on it.
From: Ben Greear @ 2010-11-09 0:20 UTC (permalink / raw)
To: NetDev
This is on an otherwise lightly loaded 2.6.36 + hacks system, 12 physical interfaces,
and two VETH interfaces.
It's much faster to delete an interface when it has no IPv6 address:
[root@ct503-60 lanforge]# time ip link add link eth5 up name eth5#0 address 00:00:00:00:00:01 type macvlan
real 0m0.005s
user 0m0.001s
sys 0m0.004s
[root@ct503-60 lanforge]# time ip link delete eth5#0
real 0m0.033s
user 0m0.001s
sys 0m0.005s
[root@ct503-60 lanforge]# ip link add link eth5 up name eth5#0 address 00:00:00:00:00:01 type macvlan
[root@ct503-60 lanforge]# ip -6 addr add 2002::1/64 dev eth5#0
[root@ct503-60 lanforge]# time ip link delete eth5#0
real 0m1.030s
user 0m0.000s
sys 0m0.013s
Funny enough, if you explicitly remove the IPv6 addr first it seems
to run at normal speed (adding both operation's times together)
[root@ct503-60 lanforge]# ip link add link eth5 up name eth5#0 address 00:00:00:00:00:01 type macvlan
[root@ct503-60 lanforge]# ip -6 addr add 2002::1/64 dev eth5#0
[root@ct503-60 lanforge]# time ip -6 addr delete 2002::1/64 dev eth5#0
real 0m0.001s
user 0m0.000s
sys 0m0.001s
[root@ct503-60 lanforge]# time ip link delete eth5#0
real 0m0.028s
user 0m0.001s
sys 0m0.005s
Take it easy,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [patch v3] ipvs: allow transmit of GRO aggregated skbs
From: Simon Horman @ 2010-11-09 1:08 UTC (permalink / raw)
To: lvs-devel, netdev; +Cc: Julian Anastasov, Herbert Xu
Attempt at allowing LVS to transmit skbs of greater than MTU length that
have been aggregated by GRO and can thus be deaggregated by GSO.
Cc: Julian Anastasov <ja@ssi.bg>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
* LRO is still an outstanding issue, but as its deprecated in favour
of GRO perhaps it doesn't need to be solved.
* v1
- Based on 2.6.35
* v2
- Rebase on current nf-next-2.6 tree (~2.6.37-rc1)
* v3
- Use skb_is_gso() instead of netif_needs_gso() as suggested by
Julian Anastasov and confirmed by Herbert Xu.
Index: lvs-test-2.6/net/netfilter/ipvs/ip_vs_xmit.c
===================================================================
--- lvs-test-2.6.orig/net/netfilter/ipvs/ip_vs_xmit.c 2010-11-08 16:27:31.000000000 +0900
+++ lvs-test-2.6/net/netfilter/ipvs/ip_vs_xmit.c 2010-11-08 16:29:19.000000000 +0900
@@ -408,7 +408,8 @@ ip_vs_bypass_xmit(struct sk_buff *skb, s
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF))) {
+ if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF)) &&
+ !skb_is_gso(skb)) {
ip_rt_put(rt);
icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
IP_VS_DBG_RL("%s(): frag needed\n", __func__);
@@ -461,7 +462,7 @@ ip_vs_bypass_xmit_v6(struct sk_buff *skb
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if (skb->len > mtu) {
+ if (skb->len > mtu && !skb_is_gso(skb)) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
@@ -560,7 +561,8 @@ ip_vs_nat_xmit(struct sk_buff *skb, stru
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF))) {
+ if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF)) &&
+ !skb_is_gso(skb)) {
icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
IP_VS_DBG_RL_PKT(0, AF_INET, pp, skb, 0,
"ip_vs_nat_xmit(): frag needed for");
@@ -675,7 +677,7 @@ ip_vs_nat_xmit_v6(struct sk_buff *skb, s
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if (skb->len > mtu) {
+ if (skb->len > mtu && !skb_is_gso(skb)) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
@@ -790,8 +792,8 @@ ip_vs_tunnel_xmit(struct sk_buff *skb, s
df |= (old_iph->frag_off & htons(IP_DF));
- if ((old_iph->frag_off & htons(IP_DF))
- && mtu < ntohs(old_iph->tot_len)) {
+ if ((old_iph->frag_off & htons(IP_DF) &&
+ mtu < ntohs(old_iph->tot_len) && !skb_is_gso(skb))) {
icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
IP_VS_DBG_RL("%s(): frag needed\n", __func__);
goto tx_error_put;
@@ -903,7 +905,8 @@ ip_vs_tunnel_xmit_v6(struct sk_buff *skb
if (skb_dst(skb))
skb_dst(skb)->ops->update_pmtu(skb_dst(skb), mtu);
- if (mtu < ntohs(old_iph->payload_len) + sizeof(struct ipv6hdr)) {
+ if (mtu < ntohs(old_iph->payload_len) + sizeof(struct ipv6hdr) &&
+ !skb_is_gso(skb)) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
@@ -1008,7 +1011,8 @@ ip_vs_dr_xmit(struct sk_buff *skb, struc
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu) {
+ if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu &&
+ !skb_is_gso(skb)) {
icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
ip_rt_put(rt);
IP_VS_DBG_RL("%s(): frag needed\n", __func__);
@@ -1174,7 +1178,8 @@ ip_vs_icmp_xmit(struct sk_buff *skb, str
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if ((skb->len > mtu) && (ip_hdr(skb)->frag_off & htons(IP_DF))) {
+ if ((skb->len > mtu) && (ip_hdr(skb)->frag_off & htons(IP_DF)) &&
+ !skb_is_gso(skb)) {
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu));
IP_VS_DBG_RL("%s(): frag needed\n", __func__);
goto tx_error_put;
@@ -1288,7 +1293,7 @@ ip_vs_icmp_xmit_v6(struct sk_buff *skb,
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if (skb->len > mtu) {
+ if (skb->len > mtu && !skb_is_gso(skb)) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
^ permalink raw reply
* Re: [patch v3] ipvs: allow transmit of GRO aggregated skbs
From: Simon Horman @ 2010-11-09 1:18 UTC (permalink / raw)
To: lvs-devel, netdev; +Cc: Julian Anastasov, Herbert Xu
In-Reply-To: <20101109010847.GA13974@verge.net.au>
On Tue, Nov 09, 2010 at 10:08:49AM +0900, Simon Horman wrote:
> Attempt at allowing LVS to transmit skbs of greater than MTU length that
> have been aggregated by GRO and can thus be deaggregated by GSO.
>
> Cc: Julian Anastasov <ja@ssi.bg>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> * LRO is still an outstanding issue, but as its deprecated in favour
> of GRO perhaps it doesn't need to be solved.
>
> * v1
> - Based on 2.6.35
>
> * v2
> - Rebase on current nf-next-2.6 tree (~2.6.37-rc1)
>
> * v3
> - Use skb_is_gso() instead of netif_needs_gso() as suggested by
> Julian Anastasov and confirmed by Herbert Xu.
On thinking about this a bit more, I believe that this is material
for stable as its affecting deployed systems. I'll back-port it
and add the appropriate CC once its seen a bit more testing.
>
> Index: lvs-test-2.6/net/netfilter/ipvs/ip_vs_xmit.c
> ===================================================================
> --- lvs-test-2.6.orig/net/netfilter/ipvs/ip_vs_xmit.c 2010-11-08 16:27:31.000000000 +0900
> +++ lvs-test-2.6/net/netfilter/ipvs/ip_vs_xmit.c 2010-11-08 16:29:19.000000000 +0900
> @@ -408,7 +408,8 @@ ip_vs_bypass_xmit(struct sk_buff *skb, s
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF))) {
> + if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF)) &&
> + !skb_is_gso(skb)) {
> ip_rt_put(rt);
> icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
> IP_VS_DBG_RL("%s(): frag needed\n", __func__);
> @@ -461,7 +462,7 @@ ip_vs_bypass_xmit_v6(struct sk_buff *skb
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if (skb->len > mtu) {
> + if (skb->len > mtu && !skb_is_gso(skb)) {
> if (!skb->dev) {
> struct net *net = dev_net(skb_dst(skb)->dev);
>
> @@ -560,7 +561,8 @@ ip_vs_nat_xmit(struct sk_buff *skb, stru
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF))) {
> + if ((skb->len > mtu) && (iph->frag_off & htons(IP_DF)) &&
> + !skb_is_gso(skb)) {
> icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
> IP_VS_DBG_RL_PKT(0, AF_INET, pp, skb, 0,
> "ip_vs_nat_xmit(): frag needed for");
> @@ -675,7 +677,7 @@ ip_vs_nat_xmit_v6(struct sk_buff *skb, s
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if (skb->len > mtu) {
> + if (skb->len > mtu && !skb_is_gso(skb)) {
> if (!skb->dev) {
> struct net *net = dev_net(skb_dst(skb)->dev);
>
> @@ -790,8 +792,8 @@ ip_vs_tunnel_xmit(struct sk_buff *skb, s
>
> df |= (old_iph->frag_off & htons(IP_DF));
>
> - if ((old_iph->frag_off & htons(IP_DF))
> - && mtu < ntohs(old_iph->tot_len)) {
> + if ((old_iph->frag_off & htons(IP_DF) &&
> + mtu < ntohs(old_iph->tot_len) && !skb_is_gso(skb))) {
> icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
> IP_VS_DBG_RL("%s(): frag needed\n", __func__);
> goto tx_error_put;
> @@ -903,7 +905,8 @@ ip_vs_tunnel_xmit_v6(struct sk_buff *skb
> if (skb_dst(skb))
> skb_dst(skb)->ops->update_pmtu(skb_dst(skb), mtu);
>
> - if (mtu < ntohs(old_iph->payload_len) + sizeof(struct ipv6hdr)) {
> + if (mtu < ntohs(old_iph->payload_len) + sizeof(struct ipv6hdr) &&
> + !skb_is_gso(skb)) {
> if (!skb->dev) {
> struct net *net = dev_net(skb_dst(skb)->dev);
>
> @@ -1008,7 +1011,8 @@ ip_vs_dr_xmit(struct sk_buff *skb, struc
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu) {
> + if ((iph->frag_off & htons(IP_DF)) && skb->len > mtu &&
> + !skb_is_gso(skb)) {
> icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu));
> ip_rt_put(rt);
> IP_VS_DBG_RL("%s(): frag needed\n", __func__);
> @@ -1174,7 +1178,8 @@ ip_vs_icmp_xmit(struct sk_buff *skb, str
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if ((skb->len > mtu) && (ip_hdr(skb)->frag_off & htons(IP_DF))) {
> + if ((skb->len > mtu) && (ip_hdr(skb)->frag_off & htons(IP_DF)) &&
> + !skb_is_gso(skb)) {
> icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu));
> IP_VS_DBG_RL("%s(): frag needed\n", __func__);
> goto tx_error_put;
> @@ -1288,7 +1293,7 @@ ip_vs_icmp_xmit_v6(struct sk_buff *skb,
>
> /* MTU checking */
> mtu = dst_mtu(&rt->dst);
> - if (skb->len > mtu) {
> + if (skb->len > mtu && !skb_is_gso(skb)) {
> if (!skb->dev) {
> struct net *net = dev_net(skb_dst(skb)->dev);
>
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 07/17][trivial] net, wireless: Remove unnecessary casts of void ptr returning alloc function return values
From: John W. Linville @ 2010-11-09 1:23 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
trivial-DgEjT+Ai2ygdnm+yROfE0A, Ulrich Kunitz, Daniel Drake,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LNX.2.00.1011082330390.23697-h2p7t3/P30RzeRGmFJ5qR7ZzlVVXadcDXqFh9Ls21Oc@public.gmane.org>
On Tue, Nov 09, 2010 at 12:09:13AM +0100, Jesper Juhl wrote:
> Hi,
>
> The [vk][cmz]alloc(_node) family of functions return void pointers which
> it's completely unnecessary/pointless to cast to other pointer types since
> that happens implicitly.
>
> This patch removes such casts from drivers/net/
>
>
> Signed-off-by: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
> ---
> zd_chip.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c b/drivers/net/wireless/zd1211rw/zd_chip.c
> index 87a95bc..dfcebed 100644
> --- a/drivers/net/wireless/zd1211rw/zd_chip.c
> +++ b/drivers/net/wireless/zd1211rw/zd_chip.c
> @@ -117,8 +117,7 @@ int zd_ioread32v_locked(struct zd_chip *chip, u32 *values, const zd_addr_t *addr
>
> /* Allocate a single memory block for values and addresses. */
> count16 = 2*count;
> - a16 = (zd_addr_t *) kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)),
> - GFP_KERNEL);
> + a16 = kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)), GFP_KERNEL);
> if (!a16) {
> dev_dbg_f(zd_chip_dev(chip),
> "error ENOMEM in allocation of a16\n");
kcalloc?
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/11] vxge: enable rxhash
From: David Miller @ 2010-11-09 2:38 UTC (permalink / raw)
To: jon.mason; +Cc: netdev, Sivakumar.Subramani, Sreenivasa.Honnur, Ramkrishna.Vepa
In-Reply-To: <20101108225340.GA16247@exar.com>
From: Jon Mason <jon.mason@exar.com>
Date: Mon, 8 Nov 2010 16:53:40 -0600
> On Mon, Nov 08, 2010 at 12:44:52PM -0800, David Miller wrote:
>>
>> This patch set doesn't apply at all to the current tree, please
>> respin them, thanks.
>
> When I sent out the series on Thursday, the tree did not have
> "vxge: make functions local and remove dead code". When that patch
> was originally released (Oct 15), I asked for it to not be included as
> it would break soon-to-be-released patch series. I did not see any
> e-mail afterward, so I assumed this was acceptable to you. We then
> ran the driver though our internal tests to verify its functionality,
> which would need to be re-done if the patches are respun.
>
> I have a reworked version of that patch which can be applied after
> this patch series. Is it acceptable to you to revert the commit,
> apply the series, then apply the modified version of the "local
> functions" patch? I have already sniff tested it on our hardware
> without issues.
Ummm, no. I'm not reverting a correct patch just so that your
original patches apply properly.
Please just respin the patch series on top of the current tree.
^ permalink raw reply
* Re: [Bugme-new] [Bug 22142] New: skge module doesn't work in 2.6.37-rc1
From: David Miller @ 2010-11-09 2:46 UTC (permalink / raw)
To: akpm; +Cc: shemminger, bugzilla-daemon, bugme-daemon, netdev, jtmettala
In-Reply-To: <20101108154306.0f93eddb.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 8 Nov 2010 15:43:06 -0800
> skge_devinit() did a nearly-NULL deref.
Fixed in net-2.6:
--------------------
skge: Remove tx queue stopping in skge_devinit()
After e6484930d7c73d324bccda7d43d131088da697b9: net: allocate tx queues in register_netdevice
It causes an Oops at skge_probe() time.
Signed-off-by: Guillaume Chazarain <guichaz@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/skge.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index bfec2e0..220e039 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -3858,7 +3858,6 @@ static struct net_device *skge_devinit(struct skge_hw *hw, int port,
/* device is off until link detection */
netif_carrier_off(dev);
- netif_stop_queue(dev);
return dev;
}
--
1.7.3.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