* Re: [net 0/2] Clean up netfilter cache on xmit-to-self.
From: David Miller @ 2010-07-26 5:01 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <20100725.215912.39197141.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 25 Jul 2010 21:59:12 -0700 (PDT)
> From: Ben Greear <greearb@candelatech.com>
> Date: Thu, 22 Jul 2010 12:54:46 -0700
>
>> These patches are against 2.6.34.1. The first one may be
>> worth submitting to stable. The second one is less critical
>> and should probably just go in the development tree.
>
> I'll apply the first one to net-2.6 and queue up for -stable
>
> The second one will go to net-next-2.6
Actually it appears net-next-2.6 already has this change.
^ permalink raw reply
* Re: [net 0/2] Clean up netfilter cache on xmit-to-self.
From: David Miller @ 2010-07-26 4:59 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1279828488-17800-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Thu, 22 Jul 2010 12:54:46 -0700
> These patches are against 2.6.34.1. The first one may be
> worth submitting to stable. The second one is less critical
> and should probably just go in the development tree.
I'll apply the first one to net-2.6 and queue up for -stable
The second one will go to net-next-2.6
Thanks.
^ permalink raw reply
* Re: [patch] usbnet: fix 100% CPU use on suspended device
From: David Miller @ 2010-07-26 4:57 UTC (permalink / raw)
To: ellyjones-hpIqsD4AKlfQT0dZR+AlfA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTi=pSkOuiFGAK4inPdm-KbLuVrz51e2T6eV51ts0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Elly Jones <ellyjones-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Date: Wed, 21 Jul 2010 14:51:48 -0400
> Subject: [patch] usbnet: fix 100% CPU use on suspended device
> From: Elly Jones <ellyjones-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>
> This patch causes the usbnet module not to attempt to submit URBs to the device
> if the device is not ready to accept them. This fixes a misbehavior trigged by
> the Qualcomm Gobi driver (released under GPL through their Code Aurora
> initiative) which causes the usbnet core to consume 100% of CPU attempting and
> failing to submit URBs. This patch is against Linus's 2.6 repo commit
> a9f7f2e74ae0e6a801a2433dc8e9124d73da0cb4.
> Signed-off-by: Elizabeth Jones <ellyjones-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
If the Qualcomm Gobi driver is the only one where this happens, maybe the
real problem is in that driver.
I'm not applying this until a USB person looks more deeply into this.
> ---
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 81c76ad..df7e72e 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -1172,6 +1172,7 @@ static void usbnet_bh (unsigned long param)
> // or are we maybe short a few urbs?
> } else if (netif_running (dev->net) &&
> netif_device_present (dev->net) &&
> + dev->udev->can_submit &&
> !timer_pending (&dev->delay) &&
> !test_bit (EVENT_RX_HALT, &dev->flags)) {
> int temp = dev->rxq.qlen;
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6] netlink: netlink_recvmsg() fix
From: David Miller @ 2010-07-26 4:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: johannes, netdev
In-Reply-To: <1279701835.2452.17.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Jul 2010 10:43:55 +0200
> [PATCH net-next-2.6 v3] netlink: netlink_recvmsg() fix
>
> commit 1dacc76d0014
> (net/compat/wext: send different messages to compat tasks)
> introduced a race condition on netlink, in case MSG_PEEK is used.
>
> An skb given by skb_recv_datagram() might be shared, we must copy it
> before any modification, or risk fatal corruption.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] forcedeth: Fix different hardware statistics versions.
From: David Miller @ 2010-07-26 4:54 UTC (permalink / raw)
To: mditto; +Cc: netdev, adobriyan, shemminger, ben, stas, linux-kernel
In-Reply-To: <20100722220252.E46C7182B00@starthinker.mtv.corp.google.com>
From: mditto@google.com (Mike Ditto)
Date: Thu, 22 Jul 2010 15:02:52 -0700 (PDT)
> The macros for the values of the bit field describing the four
> different versions of statistics supported by different hardware
> variants were being misused. Where the code was trying to test if the
> hardware implements V3, it was actually testing whether it implements
> any of V1, V2, or V3, causing the driver to report statistics that
> don't really exist in the hardware, with bogus values.
>
> Signed-off-by: Mike Ditto <mditto@google.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: Another oops + repost
From: Martín Ferrari @ 2010-07-26 3:21 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, 577640
In-Reply-To: <m1zkxjwjq9.fsf@fess.ebiederm.org>
Hi,
On Thu, Jul 22, 2010 at 18:43, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> First of all, I would like to know if anybody was able to fix this
>> problem that got kinda lost in the thread:
>
> I can't reproduce this on 2.6.35-rc1+
>
> Can you please test a 2.6.35-rc version? If you can still reproduce
> it there can you send me your .config? Otherwise I expect my last
> round of changes to sysfs fixed whatever was the underlying problem.
I just download and compiled rc6, and all of these problems seem to be
solved. Thanks a lot!
--
Martín Ferrari
^ permalink raw reply
* RE: [REGRESSION] e1000e stopped working [MANUALLY BISECTED]
From: Maxim Levitsky @ 2010-07-26 0:25 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, Allan, Bruce W,
Pieper, Jeffrey E
In-Reply-To: <1279374897.8428.5.camel@localhost.localdomain>
On Sat, 2010-07-17 at 16:54 +0300, Maxim Levitsky wrote:
> On Fri, 2010-07-16 at 17:23 -0600, Tantilov, Emil S wrote:
> > Maxim Levitsky wrote:
> > > On Thu, 2010-07-15 at 22:09 +0300, Maxim Levitsky wrote:
> > >> On Thu, 2010-07-15 at 13:02 -0600, Tantilov, Emil S wrote:
> > >>> Maxim Levitsky wrote:
> > >>>> On Thu, 2010-07-15 at 02:33 +0300, Maxim Levitsky wrote:
> > >>>>> On Wed, 2010-07-14 at 16:56 -0600, Tantilov, Emil S wrote:
> > >>>>>> Maxim Levitsky wrote:
> > >>>>>>> On Mon, 2010-07-12 at 15:23 -0600, Tantilov, Emil S wrote:
> > >>>>>>>> Maxim Levitsky wrote:
> > >>>>>>>>> On Mon, 2010-07-05 at 12:58 +0300, Maxim Levitsky wrote:
> > >>>>>>>>>> On Mon, 2010-07-05 at 01:13 -0700, Jeff Kirsher wrote:
> > >>>>>>>>>>> On Sun, Jul 4, 2010 at 15:48, Maxim Levitsky
> > >>>>>>>>>>> <maximlevitsky@gmail.com> wrote:
> > >>>>>>>>>>>> Did few guesses, and now I see that reverting the below
> > >>>>>>>>>>>> commit fixes the problem.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> "e1000e: Fix/cleanup PHY reset code for ICHx/PCHx"
> > >>>>>>>>>>>> e98cac447cc1cc418dff1d610a5c79c4f2bdec7f.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>> Maxim Levitsky
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>
> > >>>>>>>>>>> Can you give us till Tuesday to respond? I know that there
> > >>>>>>>>>>> are some additional e1000e patches in my queue, which may
> > >>>>>>>>>>> resolve the issue, but this weekend the power is down to do
> > >>>>>>>>>>> some infrastructure upgrades which prevents us from doing
> > >>>>>>>>>>> any investigation.debugging until Tuesday.
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Sure.
> > >>>>>>>>>>
> > >>>>>>>>>> Best regards,
> > >>>>>>>>>> Maxim Levitsky
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Updates?
> > >>>>>>>>
> > >>>>>>>> We are working on reproducing the issue. So far we have not
> > >>>>>>>> seen the problem when testing with net-next.
> > >>>>>>>>
> > >>>>>>>> I asked in previous email about some additional info from
> > >>>>>>>> ethtool (-d, -e, -S) and kernel config. That would help us to
> > >>>>>>>> narrow it down.
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>> Emil
> > >>>>>>> I did send -e and -d output.
> > >>>>>>
> > >>>>>> Sorry, looks like I lost the email with the attachements.
> > >>>>>>
> > >>>>>> Could you provide the output of dmesg after the failure occurs?
> > >>>>>>
> > >>>>>>> Since you probably want -S output during failure, I need to
> > >>>>>>> recompile kernel for that. I will do that soon.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> One question, in two weeks I hope 2.6.35 won't be released?
> > >>>>>>> If so, I will have enough free time then to narrow down this
> > >>>>>>> issue.
> > >>>>>>>
> > >>>>>>> Other solution, is to revert this commit.
> > >>>>>>> (I have never seen this problem with it reverted).
> > >>>>>>
> > >>>>>> We have been running reboot tests on 2 separate systems with
> > >>>>>> recent net-next kernels using your config and so far no luck in
> > >>>>>> reproducing this issue.
> > >>>>>>
> > >>>>>> What is the make model of your system (or MB)?
> > >>>>>
> > >>>>> the motherboard is Intel DG965RY.
> > >>>>>
> > >>>>> However, I am using vanilla kernel.
> > >>>>> net-next might contain further fixes.
> > >>>>>
> > >>>>> I see if net-next works here.
> > >>>>
> > >>>> Yep, net-next works here.
> > >>>>
> > >>>>
> > >>>> I have the problem on vanilla kernel.
> > >>>> Last revision of it, I tested is 2.6.35-rc4 exactly
> > >>>> (815c4163b6c8ebf8152f42b0a5fd015cfdcedc78)
> > >>>>
> > >>>>
> > >>>> Maybe vanilla git master works, I test it too soon.
> > >>>
> > >>> Thanks for the information! Good to know that this issue does not
> > >>> exist in the latest branch.
> > >>>
> > >>> Have you by any chance tested a stable branch (2.6.34.x)?
> > >>
> > >> I only did test plain 2.6.34 (v2.6.34)
> > > And forgot to add, that it did work.
> > >
> > >>
> > >> Also I repeat that revert of e98cac447cc1cc418dff1d610a5c79c4f2bdec7f
> > >> (e1000e: Fix/cleanup PHY reset code for ICHx/PCHx) fixes the bug on
> > >> vanilla kernel.
> > >>
> > >> Also I just pulled latest vanilla git, and I according to diffstat I
> > >> see no changes in e1000e, so its likely that bug remains there.
> > >> I will test that soon.
> > > Tested, broken as expected.
> >
> > That makes sense. Unfortunately we are still not able to reproduce even on recent pull from Linus tree.
> >
> > If you want - you can look at the patches for e1000e in net-next and start applying those to your tree until the issue is resolved.
> >
> That exactly what I will do soon.
>
>
> Also I can narrow down the problem by reverting the commit partially.
>
> After one week, I will have enough free time to do all the thing like
> above. Now I have none.
>
>
> > I will keep trying it here, but none of the systems we have exhibit the issue you described, so the bug could be exposed by something in your system/config.
> I also think so. Otherwise, we would see more bug-reports.
>
> You probably don't need to try anymore and reproduce that issue, because
> of that.
>
This commit, present in net-next, solves the problem:
commit 1286950690f0f82ffa504e1e149ee3fdb4c51478
Author: Bruce Allan <bruce.w.allan@intel.com>
Date: Mon Jul 26 03:19:38 2010 +0300
e1000e: cleanup e1000_sw_lcd_config_ich8lan()
Do not acquire and release the PHY unnecessarily for parts that return
from this workaround without actually accessing the PHY registers.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Also, the above patch is part of whole series of patches with scary descriptions (that is these fix bugs).
If I were you I would send them to Linus for 2.6.35 inclusion too.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH 2.6.35-rc1] net-next: Fix an overflow bug in vmxnet3 Tx descriptor
From: David Miller @ 2010-07-26 0:06 UTC (permalink / raw)
To: bhavesh; +Cc: netdev, linux-kernel
In-Reply-To: <20100725004329.GB6680@bhavesh-lx1.eng.vmware.com>
From: Bhavesh Davda <bhavesh@vmware.com>
Date: Sat, 24 Jul 2010 17:43:29 -0700
> ---
If you put the "---" there are the beginning of your message,
the whole commit message is discarded by GIT.
I said you should put "---" at the end of the commit message,
when you want to add more side commentary that should not appear
in the commit message but is for people in this thread to read.
I fixed this up when adding your patch, but I have no idea why
you did this. Please don't do it again.
> Fix an overflow bug in vmxnet3 Tx descriptor
>
> This patch fixes a bug where a 16K buffer on a Tx descriptor was overflowing
> into the 'gen' bit in the descriptor thereby corrupting the descriptor and
> stalling the transmit ring.
>
> Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
> Signed-off-by: Matthew Delco <delcoM@vmware.com>
> Signed-off-by: Ronghua Zhang <ronghua@vmware.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ks8842: Support 100Mbps when accessed via timberdale
From: David Miller @ 2010-07-26 0:03 UTC (permalink / raw)
To: richard.rojfors; +Cc: netdev
In-Reply-To: <1280091327.17191.8.camel@debian>
From: Richard Röjfors <richard.rojfors@pelagicore.com>
Date: Sun, 25 Jul 2010 22:55:27 +0200
> The flow control setting is removed from TX and RX control
> registers. Full duplex flow control was not enabled in SGCR3,
> but we tend to get better performance without flow control.
Flow control is not just for you, it's for the other end too.
If you're getting bad flow control enabled performance then
either:
1) the flow control is configured to kick in too late or
too soon
or
2) your ring sizes need adjustment
I'm not applying this patch, flow control is important and
should be enabled by default whenever possible. Please
instead go try and figure out if flow control trigger
points or RX/TX ring sizes need adjustment instead.
Thanks.
^ permalink raw reply
* Re: [PATCH] 3c59x: Add ethtool WOL support
From: David Miller @ 2010-07-25 23:48 UTC (permalink / raw)
To: bugzilla, andrew; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <201007250524.18911.andrew@beldisplaytech.com>
From: "Andrew O. Shadoura" <andrew@beldisplaytech.com>
Date: Sun, 25 Jul 2010 05:24:17 +0300
> This patch adds wrappers for ethtool to get or set wake-on-LAN
> setting without re-inserting the kernel module.
>
> Signed-off-by: Andrew O. Shadoura <andrew@beldisplaytech.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 NEXT 2/2] qlcnic: fix diag resource allocation
From: David Miller @ 2010-07-25 23:36 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, sony.chacko
In-Reply-To: <1280032338-7002-3-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Sat, 24 Jul 2010 21:32:18 -0700
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> netif_device_attach missing from error path in qlcnic_diag_alloc_res
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2 NEXT 1/2] qlcnic: fix loopback test
From: David Miller @ 2010-07-25 23:36 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1280032338-7002-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Sat, 24 Jul 2010 21:32:17 -0700
> o Loopback not supported for virtual function.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* linux and 2 LAN-cards ?
From: AgentC @ 2010-07-25 22:36 UTC (permalink / raw)
To: netdev
Hi,
I'm a linux newbie and have some configuration-probs with the network.
could anyone give some hints to get it working?
normally I used mainboard internal LAN for modemrouter / webaccess only.
out of some configurationproblems I had to remove my additional netgear-
router which was used as hub for my additional terminal-workstations
in my flat. but now it is impossible to do that anymore cause my
webserver will not work when the netgear is between the DSL-modemrouter
and my server. so I decided to try it out with a second LAN card (PCI)
where I tried to connect the netgear as hub.
but what happened was, that all outside access wasn't possible anymore
(for example ping google.de) but access to the dsl-modemrouter was
possible. ping connection to the netgear was not possible.
what happened? have the both network adapters conflicts on the PCI-bus?
or is this a configuration problem within linux config ?
can anyone tell me what went wrong and how to fix that problem ?
sincerly,
Ralf M.
^ permalink raw reply
* [PATCH] ks8842: Support 100Mbps when accessed via timberdale
From: Richard Röjfors @ 2010-07-25 20:55 UTC (permalink / raw)
To: netdev; +Cc: davem
This patch removes the code which disabled 100Mbps advertising when
the ks8842 is accessed via timberdale.
At higher speed it's good to be nice to the internal state machine
in timberdale, by acking interrupts, a write to it's interrupt
ack register (IAR).
The flow control setting is removed from TX and RX control
registers. Full duplex flow control was not enabled in SGCR3,
but we tend to get better performance without flow control.
diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
index 634dad1..9cbf9af 100644
--- a/drivers/net/ks8842.c
+++ b/drivers/net/ks8842.c
@@ -34,7 +34,12 @@
#define DRV_NAME "ks8842"
/* Timberdale specific Registers */
-#define REG_TIMB_RST 0x1c
+#define REG_TIMB_RST 0x1c
+#define REG_TIMB_FIFO 0x20
+#define REG_TIMB_ISR 0x24
+#define REG_TIMB_IER 0x28
+#define REG_TIMB_IAR 0x2C
+#define REQ_TIMB_DMA_RESUME 0x30
/* KS8842 registers */
@@ -256,11 +261,8 @@ static void ks8842_reset_hw(struct ks8842_adapter *adapter)
/* Enable QMU Transmit flow control / transmit padding / Transmit CRC */
ks8842_write16(adapter, 16, 0x000E, REG_TXCR);
- /* enable the receiver, uni + multi + broadcast + flow ctrl
- + crc strip */
- ks8842_write16(adapter, 16, 0x8 | 0x20 | 0x40 | 0x80 | 0x400,
- REG_RXCR);
-
+ /* enable the receiver, uni + multi + broadcast + crc strip */
+ ks8842_write16(adapter, 16, 0x8 | 0x20 | 0x40 | 0x80, REG_RXCR);
/* TX frame pointer autoincrement */
ks8842_write16(adapter, 17, 0x4000, REG_TXFDPR);
@@ -276,16 +278,12 @@ static void ks8842_reset_hw(struct ks8842_adapter *adapter)
/* enable no excessive collison drop */
ks8842_enable_bits(adapter, 32, 1 << 3, REG_SGCR2);
- /* Enable port 1 force flow control / back pressure / transmit / recv */
- ks8842_write16(adapter, 48, 0x1E07, REG_P1CR2);
+ /* Enable port 1 / back pressure / transmit / recv */
+ ks8842_write16(adapter, 48, 0xE07, REG_P1CR2);
/* restart port auto-negotiation */
ks8842_enable_bits(adapter, 49, 1 << 13, REG_P1CR4);
- if (!(adapter->conf_flags & MICREL_KS884X))
- /* only advertise 10Mbps */
- ks8842_clear_bits(adapter, 49, 3 << 2, REG_P1CR4);
-
/* Enable the transmitter */
ks8842_enable_tx(adapter);
@@ -543,6 +541,10 @@ void ks8842_tasklet(unsigned long arg)
/* Ack */
ks8842_write16(adapter, 18, isr, REG_ISR);
+ if (!(adapter->conf_flags & MICREL_KS884X))
+ /* Ack in the timberdale IP as well */
+ iowrite32(0x1, adapter->hw_addr + REG_TIMB_IAR);
+
if (!netif_running(netdev))
return;
^ permalink raw reply related
* [PATCH] ip: correctly report 802.15.4 link type
From: Jan Engelhardt @ 2010-07-25 20:28 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev
In-Reply-To: <1280089683-12020-1-git-send-email-jengelh@medozas.de>
Up until now, the "hardwpan" devices were displayed as link/[804].
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
lib/ll_types.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/ll_types.c b/lib/ll_types.c
index 846cdb0..1cc46b6 100644
--- a/lib/ll_types.c
+++ b/lib/ll_types.c
@@ -125,6 +125,9 @@ __PF(IEEE80211_PRISM,ieee802.11/prism)
#ifdef ARPHRD_IEEE80211_RADIOTAP
__PF(IEEE80211_RADIOTAP,ieee802.11/radiotap)
#endif
+#ifdef ARPHRD_IEEE802154
+__PF(IEEE802154, ieee802.15.4)
+#endif
#ifdef ARPHRD_NONE
__PF(NONE, none)
#endif
--
1.7.1
^ permalink raw reply related
* iproute2: 802.15.4 reporting
From: Jan Engelhardt @ 2010-07-25 20:28 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev
Hi,
I am resending this patch as it has not been included yet.
Last time you mentioned something about wanting to do this different,
but this is already your standard array of int-string mappings, not
much to improve there I'd say.
Jan
^ permalink raw reply
* Re: [PATCH] 3c59x: Add ethtool WOL support
From: Andrew O. Shadoura @ 2010-07-25 19:03 UTC (permalink / raw)
To: Netdev mailing list; +Cc: Linux kernel mailing list
In-Reply-To: <201007250524.18911.andrew@beldisplaytech.com>
[-- Attachment #1: Type: Text/Plain, Size: 293 bytes --]
Hello.
On Sunday 25 July 2010 05:24:17 Andrew O. Shadoura wrote:
> I've actually tested this patch on a machine with a network
> card that's idenfied by lsusb as "3c905C-TX/TX-M", and it seems
> to work.
Oops, of course I meant "it's identified by lspci as ...".
--
WBR, Andrew
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] netfilter: xtables: inclusion of xt_SYSRQ
From: John Haxby @ 2010-07-25 18:13 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Patrick McHardy, Netfilter Developer Mailing List,
Linux Netdev List
In-Reply-To: <alpine.LSU.2.01.1007251848520.14790@obet.zrqbmnf.qr>
On 25 Jul 2010, at 17:49, Jan Engelhardt wrote:
>
> On Wednesday 2010-04-28 17:03, Jan Engelhardt wrote:
>> On Wednesday 2010-04-28 16:54, John Haxby wrote:
>>>
>>> use-case I see -- the one I see is where the sys admins used to have a "crash
>>> trolley" which was a console and PS/2 keyboard which they could plug into a
>>> machine to get some information, but as many rack machines no longer have
>>> anything PS/2 and USB hot plug is unlikely to work on a sick machine
>>
>
> I still think we should merge this. A hold-up like this would have never
> happened with staging drivers!
>
Me too. I've been caught up with other things, but Patrick's suggestion of a separate module only half worked out.
Using encapsulation sockets, to get the sysrq handled in BH context works well except that there are no encapsulation sockets for IPv6. That, for me at least was a bit of a show stopper.
In exploring this, though, I did correct one weakness in the protocol. An opportunistic hacker could take a sysrq packet and replay it to other hosts in the LAN in the hope that they have the same password (this is a realistic weakness rather than a theoretical one). To counter this I simply added the target IP address to the hash.
Would you like me to submit that to xt_SYSRQ anyway? (In a couple of weeks I'm afraid, I'm out for a while.)
jch
^ permalink raw reply
* Re: [PATCH 1/2] netfilter: xtables: inclusion of xt_SYSRQ
From: Jan Engelhardt @ 2010-07-25 16:49 UTC (permalink / raw)
To: John Haxby
Cc: Patrick McHardy, Netfilter Developer Mailing List,
Linux Netdev List
In-Reply-To: <alpine.LSU.2.01.1004281701220.9518@obet.zrqbmnf.qr>
On Wednesday 2010-04-28 17:03, Jan Engelhardt wrote:
>On Wednesday 2010-04-28 16:54, John Haxby wrote:
>>
>> use-case I see -- the one I see is where the sys admins used to have a "crash
>> trolley" which was a console and PS/2 keyboard which they could plug into a
>> machine to get some information, but as many rack machines no longer have
>> anything PS/2 and USB hot plug is unlikely to work on a sick machine
>
I still think we should merge this. A hold-up like this would have never
happened with staging drivers!
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: Lennert Buytenhek @ 2010-07-25 15:54 UTC (permalink / raw)
To: walter harms
Cc: Dan Carpenter, Joe Perches, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <4C4C4E75.4080603@bfs.de>
On Sun, Jul 25, 2010 at 04:47:17PM +0200, walter harms wrote:
> >> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
> >> have usefull values than adding a check but this is up to the maintainer.
> >
> > I don't see the point of that at all. We check against zero to see
> > whether the caller bothered to fill in the field at all, but if the
> > caller wants to pass in bogus values, that's up to the caller.
>
> at first i have to admit i looked only at the patch.
> for me the situation looks this way:
>
> You check the values for 0 (and uses default) or take what ever in pd is.
> The current code is setup like:
>
> 1. check if pd is set
> 2. check if pd->value is non zero and use it
>
> the whole "check X" can be avoided if you could create a pd with all values
> set to default and just take what comes from the user.
Why would you want to avoid "check X"?
> my objection agains this kind of code is that it is not obvious
> what some one is trying to archive
> (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
>
> the pd check means: do i have a configuration ?
Yep.
> the pd->t_clk != 0 means: should i use then or default ?
Yep.
> This is mixing two very different questions.
And?
You're arguing against the use of 'if (a && b)' in general?
> therefore my idea in the last posting to have a default init if (!pd)
> and then use the else to make clear that additional checks for
> pd->value are expected.
Again, I don't see the point of this, and I think we're just splitting
hairs here and wasting everyone's time.
> this this is the init code readability and simplicity should be king.
'if (foo != NULL && foo->value <op> <value>)' is a fairly common C
construct, in my opinion, and I don't see how expanding it into a
multi-line nested if construct will make it either more readable or
simpler.
> hope that helps,
Not really.
thanks,
Lennert
^ permalink raw reply
* RE: Splice status
From: Ofer Heifetz @ 2010-07-25 14:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Changli Gao, Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <1279030308.2634.349.camel@edumazet-laptop>
Hi Eric,
Still trying to get better performance with splice, I noticed that when using splice there are twice the file size memcpy (placed a counter in memcpy), I verified it via samba file transfer and splice-fromnet/out.
I also used the splice-fromnet/out and using ftrace I did notice that data is copied twice using these routines: skb_splice_bits, pipe_to_file.
I thought that the main goal of splice is to refrain from one copy when moving data from network to file descriptor.
If there are the same number of memcpy and context switches and in samba copy additional vfs overhead it makes sense that splice deteriates the samba overall write performance.
-Ofer
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Tuesday, July 13, 2010 5:12 PM
To: Ofer Heifetz
Cc: Changli Gao; Jens Axboe; netdev@vger.kernel.org
Subject: RE: Splice status
Le mardi 13 juillet 2010 à 14:41 +0300, Ofer Heifetz a écrit :
> Hi,
>
> I wanted to let you know that I have been testing Samba splice on Marvell 6282 SoC on 2.6.35_rc3 and noticed that it gave worst performance than not using it and also noticed that on re-writing file the iowait is high.
>
> iometer using 2G file (file is created before test)
>
> Splice write cpu% iow%
> -----------------------
> No 58 98 0
> Yes 14 100 48
>
> iozone using 2G file (file created during test)
>
> Splice write cpu% iow% re-write cpu% iow%
> -------------------------------------------
> No 35 85 4 58.2 70 0
> Yes 33 85 4 15.7 100 58
>
> Any clue why splice introduces a high iowait?
> I noticed samba uses up to 16K per splice syscall, changing the samba to try more did not help, so I guess it is a kernel limitation.
>
splice(socket -> pipe) provides partial buffers (depending on the MTU)
With typical MTU=1500 and tcp timestamps, each network frame contains
1448 bytes of payload, partially filling one page (of 4096 bytes)
When doing the splice(pipe -> file), kernel has to coalesce partial
data, but amount of written data per syscall() is small (about 20
Kbytes)
Without splice(), the write() syscall provides more data, and vfs
overhead is smaller as buffer size is a power of two.
Samba uses a 128 KBytes TRANSFER_BUF_SIZE in its default_sys_recvfile()
implementation, it easily outperforms splice() implementation.
You could try extending pipe size (fcntl(fd, F_SETPIPE_SZ, 256)), maybe
it will be a bit better. (and ask 256*4096 bytes to splice())
I tried this and got about 256Kbytes per splice() call...
# perf report
# Events: 13K
#
# Overhead Command Shared Object Symbol
# ........ .............. ................. ......
#
8.69% splice-fromnet [kernel.kallsyms] [k] memcpy
3.82% splice-fromnet [kernel.kallsyms] [k] kunmap_atomic
3.51% splice-fromnet [kernel.kallsyms] [k] __block_prepare_write
2.79% splice-fromnet [kernel.kallsyms] [k] __skb_splice_bits
2.58% splice-fromnet [kernel.kallsyms] [k] ext3_mark_iloc_dirty
2.45% splice-fromnet [kernel.kallsyms] [k] do_get_write_access
2.04% splice-fromnet [kernel.kallsyms] [k] __find_get_block
1.89% splice-fromnet [kernel.kallsyms] [k] _raw_spin_lock
1.83% splice-fromnet [kernel.kallsyms] [k] journal_add_journal_head
1.46% splice-fromnet [bnx2x] [k] bnx2x_rx_int
1.46% splice-fromnet [kernel.kallsyms] [k] kfree
1.42% splice-fromnet [kernel.kallsyms] [k] journal_put_journal_head
1.29% splice-fromnet [kernel.kallsyms] [k] __ext3_get_inode_loc
1.26% splice-fromnet [kernel.kallsyms] [k] journal_dirty_metadata
1.25% splice-fromnet [kernel.kallsyms] [k] page_address
1.20% splice-fromnet [kernel.kallsyms] [k] journal_cancel_revoke
1.15% splice-fromnet [kernel.kallsyms] [k] tcp_read_sock
1.09% splice-fromnet [kernel.kallsyms] [k] unlock_buffer
1.09% splice-fromnet [kernel.kallsyms] [k] pipe_to_file
1.05% splice-fromnet [kernel.kallsyms] [k] radix_tree_lookup_element
1.04% splice-fromnet [kernel.kallsyms] [k] kmap_atomic_prot
1.04% splice-fromnet [kernel.kallsyms] [k] kmem_cache_free
1.03% splice-fromnet [kernel.kallsyms] [k] kmem_cache_alloc
1.01% splice-fromnet [bnx2x] [k] bnx2x_poll
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: walter harms @ 2010-07-25 14:47 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Dan Carpenter, Joe Perches, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <20100724190036.GA21121@mail.wantstofly.org>
Lennert Buytenhek schrieb:
> On Sat, Jul 24, 2010 at 10:59:07AM +0200, walter harms wrote:
>
>> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
>> have usefull values than adding a check but this is up to the maintainer.
>
> I don't see the point of that at all. We check against zero to see
> whether the caller bothered to fill in the field at all, but if the
> caller wants to pass in bogus values, that's up to the caller.
>
at first i have to admit i looked only at the patch.
for me the situation looks this way:
You check the values for 0 (and uses default) or take what ever in pd is.
The current code is setup like:
1. check if pd is set
2. check if pd->value is non zero and use it
the whole "check X" can be avoided if you could create a pd with all values
set to default and just take what comes from the user.
my objection agains this kind of code is that it is not obvious
what some one is trying to archive
(pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
the pd check means: do i have a configuration ?
the pd->t_clk != 0 means: should i use then or default ?
This is mixing two very different questions. therefore my idea in the last
posting to have a default init if (!pd) and then use the else to make clear
that additional checks for pd->value are expected.
this this is the init code readability and simplicity should be king.
hope that helps,
re,
wh
^ permalink raw reply
* [PATCH] nf_conntrack_extend: introduce __nf_ct_ext_exist()
From: Changli Gao @ 2010-07-25 14:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
some users of nf_ct_ext_exist() know ct->ext isn't NULL. For these users, the
check for ct->ext isn't necessary, the function __nf_ct_ext_exist() can be
used instead.
the type of the return value of nf_ct_ext_exist() is changed to bool.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
include/net/netfilter/nf_conntrack_extend.h | 9 +++++++--
net/netfilter/nf_conntrack_extend.c | 22 ++++++++++++----------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h
index 32d15bd..0772d29 100644
--- a/include/net/netfilter/nf_conntrack_extend.h
+++ b/include/net/netfilter/nf_conntrack_extend.h
@@ -28,9 +28,14 @@ struct nf_ct_ext {
char data[0];
};
-static inline int nf_ct_ext_exist(const struct nf_conn *ct, u8 id)
+static inline bool __nf_ct_ext_exist(const struct nf_ct_ext *ext, u8 id)
{
- return (ct->ext && ct->ext->offset[id]);
+ return !!ext->offset[id];
+}
+
+static inline bool nf_ct_ext_exist(const struct nf_conn *ct, u8 id)
+{
+ return (ct->ext && __nf_ct_ext_exist(ct->ext, id));
}
static inline void *__nf_ct_ext_find(const struct nf_conn *ct, u8 id)
diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
index fdc8fb4..7dcf7a4 100644
--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -23,9 +23,10 @@ void __nf_ct_ext_destroy(struct nf_conn *ct)
{
unsigned int i;
struct nf_ct_ext_type *t;
+ struct nf_ct_ext *ext = ct->ext;
for (i = 0; i < NF_CT_EXT_NUM; i++) {
- if (!nf_ct_ext_exist(ct, i))
+ if (!__nf_ct_ext_exist(ext, i))
continue;
rcu_read_lock();
@@ -73,44 +74,45 @@ static void __nf_ct_ext_free_rcu(struct rcu_head *head)
void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
{
- struct nf_ct_ext *new;
+ struct nf_ct_ext *old, *new;
int i, newlen, newoff;
struct nf_ct_ext_type *t;
/* Conntrack must not be confirmed to avoid races on reallocation. */
NF_CT_ASSERT(!nf_ct_is_confirmed(ct));
- if (!ct->ext)
+ old = ct->ext;
+ if (!old)
return nf_ct_ext_create(&ct->ext, id, gfp);
- if (nf_ct_ext_exist(ct, id))
+ if (__nf_ct_ext_exist(old, id))
return NULL;
rcu_read_lock();
t = rcu_dereference(nf_ct_ext_types[id]);
BUG_ON(t == NULL);
- newoff = ALIGN(ct->ext->len, t->align);
+ newoff = ALIGN(old->len, t->align);
newlen = newoff + t->len;
rcu_read_unlock();
- new = __krealloc(ct->ext, newlen, gfp);
+ new = __krealloc(old, newlen, gfp);
if (!new)
return NULL;
- if (new != ct->ext) {
+ if (new != old) {
for (i = 0; i < NF_CT_EXT_NUM; i++) {
- if (!nf_ct_ext_exist(ct, i))
+ if (!__nf_ct_ext_exist(old, i))
continue;
rcu_read_lock();
t = rcu_dereference(nf_ct_ext_types[i]);
if (t && t->move)
t->move((void *)new + new->offset[i],
- (void *)ct->ext + ct->ext->offset[i]);
+ (void *)old + old->offset[i]);
rcu_read_unlock();
}
- call_rcu(&ct->ext->rcu, __nf_ct_ext_free_rcu);
+ call_rcu(&old->rcu, __nf_ct_ext_free_rcu);
ct->ext = new;
}
^ permalink raw reply related
* Re: Question about way that NICs deliver packets to the kernel
From: Junchang Wang @ 2010-07-25 14:18 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: Ben Hutchings, romieu
In-Reply-To: <4C45D9FA.5090108@hp.com>
Hi list,
> Clearly something is out of joint - let's go off-list (or on to
> netperf-talk@netperf.org) and hash that out to see what may be happening.
> It will probably involve variations on grabbing the top-of-trunk, adding
> the debug option etc.
>
The discrepancy between netperf and top has been worked out.
It seems top produce buggy data when I try to send output to a file.
For example, "top -b > output" gives out my previous buggy data in its
first iteration.
Actually, the report of top should be:
top - 21:37:15 up 21 min, 6 users, load average: 0.43, 0.28, 0.19
Tasks: 152 total, 2 running, 149 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.2%us, 5.4%sy, 0.0%ni, 50.9%id, 0.0%wa, 0.0%hi, 43.5%si, 0.0%
Mem: 2074064k total, 690192k used, 1383872k free, 39372k buffers
Swap: 2096476k total, 0k used, 2096476k free, 435056k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3916 root 20 0 2228 584 296 R 86.3 0.0 0:09.72 netserver
I think 50.9% system idle makes sense because this is a dual-core system
and netserver is consuming 86.3% of a core. On average, the CPU usage
of the whole system reported by top can be regarded as from 46.2% to
50.1%.
netperf's report of 48% is right and testifies that "there is no huge
discrepancy
between the overall CPU utilization reported by top and the CPU utilization
reported by netperf."
Thanks Rick.
--
--Junchang
^ permalink raw reply
* Re: [PATCH 0/2] ks8842: Support for passing flags via platform data and 100 Mbps support
From: Richard Röjfors @ 2010-07-25 12:13 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1280003108.28285.279.camel@debian>
On 07/24/2010 10:25 PM, Richard Röjfors wrote:
> To follow are two patches
> * Introduce a flags field in the platform data.
> * removes flow control and advertise 100Mbps
Forget these two patches, I missed the patch from David Choi.
My patches won't apply after his.
--Richard
^ 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