* [PATCH 10/15] irda: sh_irda: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2013-11-27 1:18 UTC (permalink / raw)
To: linux-sh; +Cc: linux-arm-kernel, Samuel Ortiz, netdev
In-Reply-To: <1385515117-23664-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
This helps increasing build testing coverage.
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: netdev@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Simon Horman <horms@verge.net.au>
---
drivers/net/irda/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index 2a30193..cae5ee2 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -403,7 +403,8 @@ config MCS_FIR
config SH_IRDA
tristate "SuperH IrDA driver"
- depends on IRDA && ARCH_SHMOBILE
+ depends on IRDA
+ depends on ARCH_SHMOBILE || COMPILE_TEST
help
Say Y here if your want to enable SuperH IrDA devices.
--
1.8.3.2
^ permalink raw reply related
* [PATCH 00/15] Enable compilation of various Renesas drivers with COMPILE_TEST
From: Laurent Pinchart @ 2013-11-27 1:18 UTC (permalink / raw)
To: linux-sh-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Thierry Reding,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Russell King, Vinod Koul,
Magnus Damm, Eduardo Valentin, Tomi Valkeinen,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Ian Molton, Mark Brown,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA
Hello,
This patch series enables driver compilation with COMPILE_TEST for various
Renesas drivers. The approach taken here is to split the Kconfig depends line
in two, with compile dependencies (if any) on one line and runtime
dependencies (as a list of the platforms on which the hardware can be found)
on another line. The runtime dependencies line is extended with
|| COMPILE_TEST to enable test compilation. This clearly identifies compile
dependencies, and allow test compilation while not clobbering the
configuration menu with useless options in the normal case.
The patches are based on top of v3.13-rc1. To avoid build warnings or errors
during bisection the following patches sent to linux-sh and appropriate
mailing lists should be applied first:
serial: sh-sci: Fix warnings due to improper casts and printk formats
DMA: shdma: Fix warnings due to improper casts and printk formats
DMA: shdma: Fix warnings due to declared but unused symbols
DMA: shdma: Make sh_dmae_pm static
v4l: sh_vou: Fix warnings due to improper casts and printk formats
mmc: sh_mmcif: Factorize DMA channel request and configuration code
mmc: sh_mmcif: Fix compilation warning on 64-bit platforms
mtd: sh_flctl: Fix warnings due to improper casts
fbdev: sh_mobile_lcdcfb: Don't use plain 0 as NULL pointer
spi: sh-msiof: Fix warnings due to improper casts
spi: rcar: Fix uninitialized variable warning
spi: rcar: Fix pointer cast in the remove function
For convenience I've pushed the whole series and its prerequisites to my git
tree at
git://linuxtv.org/pinchartl/fbdev.git clocks/ccf/multiarch-drivers
The patches will need to go through their respective subsystem's trees. To
help me tracking the mainlining state I'd appreciate if the respective
maintainers could notify me when applying the patches to their trees. Before
doing so I'd like to get an ack from Mark Brown and/or Russell King on the
approach.
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Cc: Guennadi Liakhovetski <g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
Cc: Ian Molton <ian-zdned+2MO1+9FHfhHBbuYA@public.gmane.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Cc: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Cc: Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mauro Carvalho Chehab <m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Cc: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Cc: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Laurent Pinchart (15):
i2c: shmobile/rcar: Restrict non-COMPILE_TEST compilation
input: sh_keysc: Restrict non-COMPILE_TEST compilation
serial: sh-sci: Restrict non-COMPILE_TEST compilation
iommu: shmobile: Enable driver compilation with COMPILE_TEST
DMA: shdma: Enable driver compilation with COMPILE_TEST
v4l: sh_vou: Enable driver compilation with COMPILE_TEST
mmc: sdhi: Enable driver compilation with COMPILE_TEST
mmc: sh_mmcif: Enable driver compilation with COMPILE_TEST
mtd: sh_flctl: Enable driver compilation with COMPILE_TEST
irda: sh_irda: Enable driver compilation with COMPILE_TEST
pwm: pwm-renesas-tpu: Enable driver compilation with COMPILE_TEST
thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST
fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
spi: sh-msiof: Enable driver compilation with COMPILE_TEST
sh: intc: Enable driver compilation with COMPILE_TEST
drivers/dma/sh/Kconfig | 2 +-
drivers/i2c/busses/Kconfig | 4 ++--
drivers/input/keyboard/Kconfig | 2 +-
drivers/iommu/Kconfig | 1 +
drivers/media/platform/Kconfig | 3 ++-
drivers/mmc/host/Kconfig | 6 ++++--
drivers/mtd/nand/Kconfig | 2 +-
drivers/net/irda/Kconfig | 3 ++-
drivers/pwm/Kconfig | 2 +-
drivers/sh/intc/Kconfig | 2 +-
drivers/spi/Kconfig | 3 ++-
drivers/thermal/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 3 ++-
drivers/video/Kconfig | 8 +++++---
14 files changed, 26 insertions(+), 17 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [ovs-dev] [PATCH v2.51 0/5] MPLS actions and matches
From: Simon Horman @ 2013-11-27 0:12 UTC (permalink / raw)
To: Ben Pfaff; +Cc: dev, netdev, Jesse Gross, Ravi K
In-Reply-To: <20131126153347.GA2662@nicira.com>
On Tue, Nov 26, 2013 at 07:33:47AM -0800, Ben Pfaff wrote:
> On Tue, Nov 26, 2013 at 05:08:04PM +0900, Simon Horman wrote:
> > On Thu, Nov 21, 2013 at 12:46:41PM +0900, Simon Horman wrote:
> > > Hi,
> > >
> > > This series implements MPLS actions and matches based on work by
> > > Ravi K, Leo Alterman, Yamahata-san and Joe Stringer.
> > >
> > > This series provides three changes
> > >
> > > * Patches 1 - 3
> > >
> > > Provide user-space support for the VLAN/MPLS tag insertion order
> > > up to and including OpenFlow 1.2, and the different ordering
> > > specified from OpenFlow 1.3. In a nutshell the datapath always
> > > uses the OpenFlow 1.3 ordering, which is to always insert tags
> > > immediately after the L2 header, regardless of the presence of other
> > > tags. And ovs-vswtichd provides compatibility for the behaviour up
> > > to OpenFlow 1.2, which is that MPLS tags should follow VLAN tags
> > > if present.
> > >
> > > Ben, these are for you to review.
> >
> > Hi Ben,
> >
> > I wonder if you could find some time to look over these.
> >
> > I believe that the first patch has not previously been reviewed
> > but other than that there should be few areas of excitement.
>
> I'm taking today and the remainder of this week off (Thursday and Friday
> are a holiday here in the U.S.), so unfortunately there is not much
> chance of progress before Monday.
Enjoy your break :)
^ permalink raw reply
* Re: [PATCH 15/17] net: sfc calls skb_get_rxhash
From: Ben Hutchings @ 2013-11-27 0:05 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx83jRc6c2W7pCNHmbWqLdrjnhPQaq8UUOV1HqyxbHeGig@mail.gmail.com>
On Tue, 2013-11-26 at 15:35 -0800, Tom Herbert wrote:
> On Tue, Nov 26, 2013 at 11:59 AM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > On Mon, 2013-11-25 at 21:57 -0800, Tom Herbert wrote:
> >> Drivers should call skb_get_rxhash to set the rxhash and its type
> >> in an skbuff.
> >>
> >> Signed-off-by: Tom Herbert <therbert@google.com>
> >> ---
> >> drivers/net/ethernet/sfc/rx.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
> >> index 8f09e68..b51466e 100644
> >> --- a/drivers/net/ethernet/sfc/rx.c
> >> +++ b/drivers/net/ethernet/sfc/rx.c
> >> @@ -439,7 +439,8 @@ efx_rx_packet_gro(struct efx_channel *channel, struct efx_rx_buffer *rx_buf,
> >> }
> >>
> >> if (efx->net_dev->features & NETIF_F_RXHASH)
> >> - skb->rxhash = efx_rx_buf_hash(efx, eh);
> >> + skb_set_rxhash(skb, efx_rx_buf_hash(efx, eh),
> >> + RXHASH_TYPE_L3);
> >
> > This is equivalent to what we do now. But efx_rx_packet_gro() is only
> > ever called for TCP packets (checked in __efx_rx_packet()) and their
> > hashes include port numbers, so the hash type could be RXHASH_TYPE_L4.
> >
> It would be great for sfc (and more drivers) to provide L4 hash. I
> think we should fix the API first and then fix drivers to return L4.
OK, so:
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: r8169 Wake on Lan
From: Francois Romieu @ 2013-11-26 23:57 UTC (permalink / raw)
To: Pablo Cholaky; +Cc: netdev
In-Reply-To: <CAEv3EXFm5MrDeZLRyAZdVNoXWEGB7sU405+oM7K=o=eiAnUNPA@mail.gmail.com>
(please no top-posting)
Pablo Cholaky <mrwaltercool@gmail.com> :
[...]
> If kernel parameters are ugly... a on-kernel option should be bad too?
Yes.
You use runtime suspend, suspend to disk and your ethernet network device
is up, right ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH 15/17] net: sfc calls skb_get_rxhash
From: Tom Herbert @ 2013-11-26 23:35 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1385495957.1586.54.camel@bwh-desktop.uk.level5networks.com>
On Tue, Nov 26, 2013 at 11:59 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Mon, 2013-11-25 at 21:57 -0800, Tom Herbert wrote:
>> Drivers should call skb_get_rxhash to set the rxhash and its type
>> in an skbuff.
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>> drivers/net/ethernet/sfc/rx.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
>> index 8f09e68..b51466e 100644
>> --- a/drivers/net/ethernet/sfc/rx.c
>> +++ b/drivers/net/ethernet/sfc/rx.c
>> @@ -439,7 +439,8 @@ efx_rx_packet_gro(struct efx_channel *channel, struct efx_rx_buffer *rx_buf,
>> }
>>
>> if (efx->net_dev->features & NETIF_F_RXHASH)
>> - skb->rxhash = efx_rx_buf_hash(efx, eh);
>> + skb_set_rxhash(skb, efx_rx_buf_hash(efx, eh),
>> + RXHASH_TYPE_L3);
>
> This is equivalent to what we do now. But efx_rx_packet_gro() is only
> ever called for TCP packets (checked in __efx_rx_packet()) and their
> hashes include port numbers, so the hash type could be RXHASH_TYPE_L4.
>
It would be great for sfc (and more drivers) to provide L4 hash. I
think we should fix the API first and then fix drivers to return L4.
Thanks,
Tom
> Ben.
>
>> skb->ip_summed = ((rx_buf->flags & EFX_RX_PKT_CSUMMED) ?
>> CHECKSUM_UNNECESSARY : CHECKSUM_NONE);
>>
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* Re: r8169 Wake on Lan
From: Pablo Cholaky @ 2013-11-26 23:27 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20131126232101.GA7508@electric-eye.fr.zoreil.com>
Seems like ACPI is enabling by default WOL, I'm wrong? Or maybe a BIOS
setting, unconfigurable by user.
My dmesg of r8159
[ 3.834430] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 3.836970] r8169 0000:02:00.0: irq 43 for MSI/MSI-X
[ 3.837151] r8169 0000:02:00.0 eth0: RTL8168g/8111g at
0xffffc9000524a000, a4:5d:36:be:93:a3, XID 0c000800 IRQ 43
[ 3.837154] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200
bytes, tx checksumming: ko]
[ 15.509384] r8169 0000:02:00.0 eth0: link down
[ 2212.203541] r8169 0000:02:00.0 eth0: link down
[33965.758196] r8169 0000:02:00.0: System wakeup enabled by ACPI
[33966.155166] r8169 0000:02:00.0: System wakeup disabled by ACPI
[33970.285568] r8169 0000:02:00.0 eth0: link down
[33991.837714] r8169 0000:02:00.0 eth0: link down
[65787.535308] r8169 0000:02:00.0 eth0: link down
[73646.418210] r8169 0000:02:00.0: System wakeup enabled by ACPI
[73646.818712] r8169 0000:02:00.0: System wakeup disabled by ACPI
[73650.971790] r8169 0000:02:00.0 eth0: link down
[81000.170579] r8169 0000:02:00.0 eth0: link down
[81777.521723] r8169 0000:02:00.0 eth0: link down
[98273.025146] r8169 0000:02:00.0 eth0: link down
If kernel parameters are ugly... a on-kernel option should be bad too?
On Tue, Nov 26, 2013 at 8:21 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Pablo Cholaky <mrwaltercool@gmail.com> :
> [...]
>> I have a HP ENVY laptop with this RealTek, and my laptop don't have a
>> BIOS option to disable WOL. I'm currently using a script on start and
>> shutdown to disable WOL, but could you guys make a module param to
>> enable/disable WOL?
>
> The kernel has to offer a standardized API. Module params are terrible
> in this regard. Please forget it.
>
>> This freaking WOL eats a lot of battery on my laptop and my scripts
>> don't work when I'm using a hibernation or booting a Linux ISO per
>> example.
>
> (if a kernel change can propagate to your ISO, so can your wol
> disabling scripts)
>
> There may be something wrong wrt hibernation (real hibernation, not
> runtime suspend, right ?) but I do not see how the current code could
> change the WoL settings at suspend time for a downed interface.
> Care to provide a short description for your hibernation use ?
>
> The XID line included in dmesg output or plain dmesg itself will be
> welcome to identify the r8169 chipset. It can make some difference in
> the suspend / resume paths.
>
> --
> Ueimor
--
Pablo Cholaky
Linux user and developer
Slash.cl Owner
Blablabla
^ permalink raw reply
* Re: r8169 Wake on Lan
From: Francois Romieu @ 2013-11-26 23:21 UTC (permalink / raw)
To: Pablo Cholaky; +Cc: netdev
In-Reply-To: <CAEv3EXFiUnfkBCiedjXUzc6MXBnP2vqNx4R3739642dGYazTwA@mail.gmail.com>
Pablo Cholaky <mrwaltercool@gmail.com> :
[...]
> I have a HP ENVY laptop with this RealTek, and my laptop don't have a
> BIOS option to disable WOL. I'm currently using a script on start and
> shutdown to disable WOL, but could you guys make a module param to
> enable/disable WOL?
The kernel has to offer a standardized API. Module params are terrible
in this regard. Please forget it.
> This freaking WOL eats a lot of battery on my laptop and my scripts
> don't work when I'm using a hibernation or booting a Linux ISO per
> example.
(if a kernel change can propagate to your ISO, so can your wol
disabling scripts)
There may be something wrong wrt hibernation (real hibernation, not
runtime suspend, right ?) but I do not see how the current code could
change the WoL settings at suspend time for a downed interface.
Care to provide a short description for your hibernation use ?
The XID line included in dmesg output or plain dmesg itself will be
welcome to identify the r8169 chipset. It can make some difference in
the suspend / resume paths.
--
Ueimor
^ permalink raw reply
* Re: netfilter: active obj WARN when cleaning up
From: Sasha Levin @ 2013-11-26 23:13 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: kaber, kadlec, David S. Miller, netfilter-devel, coreteam, netdev,
LKML
In-Reply-To: <20131126230709.GA10948@localhost>
On 11/26/2013 06:07 PM, Pablo Neira Ayuso wrote:
> On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
>> >Ping? I still see this warning.
> Did your test include patch 0c3c6c00c6?
Yeah, it reproduces with today's -next tree, which includes that commit.
Thanks,
Sasha
^ permalink raw reply
* Re: Supporting 4 way connections in LKSCTP
From: Sun Paul @ 2013-11-26 23:10 UTC (permalink / raw)
To: Vlad Yasevich, linux-sctp, netdev, linux-kernel
In-Reply-To: <CAFXGftLsKm9a5bmXX4Fe+rnSvYVdBDOyYGwisRP7XMu+ky=DGw@mail.gmail.com>
Hi Vlad
Thank for your reply. If it is based on the destination IP to find the
best route, why the problem didn't happen on single-homing sample?
In the single-homing sample that provided in the original email, both
of the interfaces (eth1 and eth2) are presented on NODE-B during the
test. However, the LKSCTP library know to use the interface eth1 to
respond to the SCTP request.
- PS
On Wed, Nov 27, 2013 at 7:09 AM, Sun Paul <paulrbk@gmail.com> wrote:
> Hi Vlad
>
> Thank for your reply. If it is based on the destination IP to find the
> best route, why the problem didn't happen on single-homing sample?
>
> In the single-homing sample that provided in the original email, both
> of the interfaces (eth1 and eth2) are presented on NODE-B during the
> test. However, the LKSCTP library know to use the interface eth1 to
> respond to the SCTP request.
>
> - PS
>
> On Tue, Nov 26, 2013 at 11:19 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>> On 11/25/2013 08:03 PM, Sun Paul wrote:
>>> Hi
>>>
>>> we have a problem on using LKSCTP to form a 4 ways multi-homing network.
>>>
>>> Configuration
>>> - Node-A has 2 IP addresses in different subnets, known as IP-A (eth1),
>>> IP-B (eth2)
>>> - Node-B has 2 IP addresses in different subnets, known as IP-X (eth1),
>>> IP-Y (eth2)
>>>
>>
>> First of all, this is not a 4 way multi-homed network. As far as each
>> SCTP association is concerned, it has only 2 destinations to send to
>> so it has only 2 ways to get there. The fact that you have multiple
>> local addresses doesn't mean that every local address can and should
>> be used to connect to the remote.
>>
>>> the four way paths are shown below.
>>> 1. IP-A (11.1.1.1) to IP-X (11.1.1.11)
>>> 2. IP-B (12.1.1.1) to IP-Y (12.1.1.11)
>>> 3. IP-A (11.1.1.1) to IP-Y (12.1.1.11)
>>> 4. IP-B (12.1.1.1) to IP-X (11.1.1.11)
>>
>> No, actually you only have 2 paths: one to IPX and one to IP-Y.
>> Which source address you choose is based on routing policy
>> decisions and is outside the scope of SCTP.
>>
>>>
>>> the HB/HB_ACK is normal for the paths " IP-A to IP-X" and "IP-B to
>>> IP-Y", but it is not correct for the rest of two.
>>
>> Right, because linux is using a host addressing model, not an interface
>> addressing model. SCTP stack simply finds the best source address
>> that can be used to reach IP-X and it happens to be IP-A. So that
>> is what it is going to use.
>>
>> The above explains why you are seeing what you describe below.
>>
>> In the end, linux SCTP implementation determines paths solely based
>> on the destination address.
>>
>> -vlad
>>
>>>
>>> First of all, we are using iproute2 to form 2 table such that when
>>> IP-B arrives on IP-X, it will know how to route back to IP-B on the
>>> same interface, i.e (eth1). Same logic for the path "IP-A to IP-X".
>>>
>>> What we observed here is that when 12.1.1.1 sends INIT to 11.1.1.11,
>>> LKSCTP will send back the INIT_ACK to 12.1.1.1 using 12.1.1.11 but not
>>> using the IP 11.1.1.11.
>>>
>>> The above operation makes the subsequence HB/HB_ACK in using wrong IP address.
>>>
>>> TCP trace on eth1
>>> 18:02:41.058640 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [INIT]
>>> [init tag: 19933036] [rwnd: 102400] [OS: 16] [MIS: 16] [init TSN: 0]
>>> 18:02:41.061634 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [COOKIE ECHO]
>>> 18:02:41.062642 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:02:41.062846 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
>>> 18:02:41.361811 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
>>> 18:02:41.661791 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
>>> 18:02:41.961791 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
>>>
>>> TCP trace on eth2
>>> 18:02:41.058755 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [INIT ACK]
>>> [init tag: 424726157] [rwnd: 131072] [OS: 5] [MIS: 5] [init TSN:
>>> 3340756356]
>>> 18:02:41.061696 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [COOKIE ACK]
>>> 18:02:41.062663 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
>>> 18:02:41.062791 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:02:41.361777 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:02:41.661772 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:02:41.961772 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:02:42.161771 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:02:42.461770 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:02:42.675770 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
>>>
>>>
>>> If we are using single homing, there is no problem on the SCTP
>>> communication. Below is the TCP trace on eth1 using sctp_test
>>>
>>> 18:09:55.356727 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [INIT]
>>> [init tag: 32516609] [rwnd: 102400] [OS: 16] [MIS: 16] [init TSN: 0]
>>> 18:09:55.356811 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [INIT ACK]
>>> [init tag: 3168861995] [rwnd: 131072] [OS: 10] [MIS: 16] [init TSN:
>>> 1877695021]
>>> 18:09:55.357727 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [COOKIE ECHO]
>>> 18:09:55.357788 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [COOKIE ACK]
>>> 18:09:55.358724 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:09:55.358740 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
>>> 18:09:55.379715 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [DATA]
>>> (B)(E) [TSN: 0] [SID: 0] [SSEQ 0] [PPID 0x3]
>>> 18:09:55.379735 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [SACK]
>>> [cum ack 0] [a_rwnd 131064] [#gap acks 0] [#dup tsns 0]
>>> 18:09:55.657716 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
>>> 18:09:55.657732 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
>>>
>>> From the observations, it seems that the LKSCTP library is not able to
>>> use the original local address when multi-homing is being used. Is
>>> there anyway can be resolved it?
>>>
>>> Thanks
>>>
>>> PS
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" 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: netfilter: active obj WARN when cleaning up
From: Pablo Neira Ayuso @ 2013-11-26 23:07 UTC (permalink / raw)
To: Sasha Levin
Cc: kaber, kadlec, David S. Miller, netfilter-devel, coreteam, netdev,
LKML
In-Reply-To: <5294F27D.4000108@oracle.com>
On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
> Ping? I still see this warning.
Did your test include patch 0c3c6c00c6?
> On 09/07/2013 09:10 AM, Sasha Levin wrote:
> >Hi all,
> >
> >While fuzzing with trinity inside a KVM tools guest, running latest -next kernel, I've
> >stumbled on the following:
> >
> >[ 418.311956] ------------[ cut here ]------------
> >[ 418.312449] WARNING: CPU: 6 PID: 4178 at lib/debugobjects.c:260 debug_print_object+0x8d/0xb0()
> >[ 418.313243] ODEBUG: free active (active state 0) object type: timer_list hint:
> >delayed_work_timer_fn+0x0/0x20
> >[ 418.314038] Modules linked in:
> >[ 418.314038] CPU: 6 PID: 4178 Comm: kworker/u16:2 Tainted: G W 3.11.0-next-20130906-sasha
> >#3984
> >[ 418.314038] Workqueue: netns cleanup_net
> >[ 418.314038] 0000000000000104 ffff880410371a58 ffffffff841b7815 0000000000000104
> >[ 418.314038] ffff880410371aa8 ffff880410371a98 ffffffff8112540c ffff880410371a78
> >[ 418.314038] ffffffff853ea0ab ffff8800bdc68b80 ffffffff85a65c00 ffffffff87676658
> >[ 418.314038] Call Trace:
> >[ 418.314038] [<ffffffff841b7815>] dump_stack+0x52/0x87
> >[ 418.320315] [<ffffffff8112540c>] warn_slowpath_common+0x8c/0xc0
> >[ 418.321040] [<ffffffff811254f6>] warn_slowpath_fmt+0x46/0x50
> >[ 418.321101] [<ffffffff81a60ded>] debug_print_object+0x8d/0xb0
> >[ 418.321101] [<ffffffff811444e0>] ? __queue_work+0x390/0x390
> >[ 418.321101] [<ffffffff81a61605>] __debug_check_no_obj_freed+0xa5/0x220
> >[ 418.321101] [<ffffffff81249e76>] ? kmem_cache_destroy+0x86/0xe0
> >[ 418.321101] [<ffffffff81a61795>] debug_check_no_obj_freed+0x15/0x20
> >[ 418.321101] [<ffffffff812874d7>] kmem_cache_free+0x197/0x340
> >[ 418.321101] [<ffffffff81249e76>] kmem_cache_destroy+0x86/0xe0
> >[ 418.321101] [<ffffffff83d5d681>] nf_conntrack_cleanup_net_list+0x131/0x170
> >[ 418.321101] [<ffffffff83d5ec5d>] nf_conntrack_pernet_exit+0x5d/0x70
> >[ 418.321101] [<ffffffff83cda1ce>] ops_exit_list+0x5e/0x70
> >[ 418.321101] [<ffffffff83cda80b>] cleanup_net+0xfb/0x1c0
> >[ 418.321101] [<ffffffff81145c28>] process_one_work+0x338/0x550
> >[ 418.321101] [<ffffffff81145b50>] ? process_one_work+0x260/0x550
> >[ 418.321883] [<ffffffff81147605>] worker_thread+0x215/0x350
> >[ 418.321883] [<ffffffff811473f0>] ? manage_workers+0x180/0x180
> >[ 418.321883] [<ffffffff81150887>] kthread+0xe7/0xf0
> >[ 418.321883] [<ffffffff811507a0>] ? __init_kthread_worker+0x70/0x70
> >[ 418.321883] [<ffffffff841c7a2c>] ret_from_fork+0x7c/0xb0
> >[ 418.321883] [<ffffffff811507a0>] ? __init_kthread_worker+0x70/0x70
> >[ 418.321883] ---[ end trace c974221542b61d0d ]---
> >
> >
> >Thanks,
> >Sasha
>
^ permalink raw reply
* Re: [PATCH v2 11/17] net: ixgbe calls skb_set_rxhash
From: Jeff Kirsher @ 2013-11-26 21:51 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, David Miller
In-Reply-To: <alpine.DEB.2.02.1311260928030.21138@tomh.mtv.corp.google.com>
On Tue, Nov 26, 2013 at 9:31 AM, Tom Herbert <therbert@google.com> wrote:
> Drivers should call skb_set_rxhash to set the rxhash and its type
> in an skbuff.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
I have added the patch to my queue, thanks Tom!
^ permalink raw reply
* Re: [PATCH v2 10/17] net: igb calls skb_set_rxhash
From: Jeff Kirsher @ 2013-11-26 21:51 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, David Miller
In-Reply-To: <alpine.DEB.2.02.1311260928020.21031@tomh.mtv.corp.google.com>
On Tue, Nov 26, 2013 at 9:31 AM, Tom Herbert <therbert@google.com> wrote:
> Drivers should call skb_set_rxhash to set the rxhash and its type
> in an skbuff.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
I have added the patch to my queue, thanks Tom!
^ permalink raw reply
* Re: [PATCH v2 09/17] net: i40e calls skb_set_rxhash
From: Jeff Kirsher @ 2013-11-26 21:50 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, David Miller
In-Reply-To: <alpine.DEB.2.02.1311260923030.21248@tomh.mtv.corp.google.com>
On Tue, Nov 26, 2013 at 9:27 AM, Tom Herbert <therbert@google.com> wrote:
> Drivers should call skb_set_rxhash to set the rxhash and its type
> in an skbuff.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
I have added the patch to my queue, thanks Tom!
^ permalink raw reply
* Re: [PATCH v2 08/17] net: e1000e calls skb_set_rxhash
From: Jeff Kirsher @ 2013-11-26 21:50 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, David Miller
In-Reply-To: <alpine.DEB.2.02.1311260923020.21143@tomh.mtv.corp.google.com>
On Tue, Nov 26, 2013 at 9:27 AM, Tom Herbert <therbert@google.com> wrote:
> Drivers should call skb_set_rxhash to set the rxhash and its type
> in an skbuff.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I have added the patch to my queue, thanks Tom!
^ permalink raw reply
* Kernel Panic in IPv6 vxlan
From: Ryan Whelan @ 2013-11-26 21:41 UTC (permalink / raw)
To: netdev, amwang
I'm not sure if this is the right place to report this- please correct
me if I'm mistaken.
When creating a vxlan interface with an IPv6 multicast group but not
specifying an underlying device, the kernel panics when the vxlan
interface is brought up. This doesn't happen with an IPv4 multicast
group. Linux 3.12.1 x86_64
`ip link add vxlan0 type vxlan id 42 group ff0e::110`
`ip link set vxlan0 up`
[ 192.037669] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000080
[ 192.041392] IP: [<ffffffff8135fb85>] ipv6_sock_mc_join+0x29/0x171
[ 192.043865] PGD 0
[ 192.044693] Oops: 0000 [#1] SMP
[ 192.046020] Modules linked in: nfsd auth_rpcgss oid_registry
nfs_acl nfs lockd fscache sunrpc loop coretemp crc32c_intel vmwgfx ttm
ghash_clmulni_intel aesni_intel aes_x86_64 joydev ablk_helper drm
snd_pcm cryptd lrw snd_page_alloc snd_timer gf128mul glue_helper snd
processor hid_generic psmouse soundcore ehci_pci thermal_sys
parport_pc parport usbhid pcspkr serio_raw hid shpchp evdev i2c_piix4
i2c_core microcode button ac ext4 crc16 jbd2 mbcache dm_mod sg sd_mod
sr_mod cdrom crc_t10dif crct10dif_common ata_generic floppy e1000
uhci_hcd ehci_hcd usbcore usb_common mptspi ata_piix
scsi_transport_spi mptscsih mptbase libata scsi_mod
[ 192.064123] CPU: 1 PID: 173 Comm: kworker/1:2 Not tainted 3.12.1 #1
[ 192.065625] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 09/20/2012
[ 192.068087] Workqueue: vxlan vxlan_igmp_join
[ 192.069154] task: ffff8800175727f0 ti: ffff88001775a000 task.ti:
ffff88001775a000
[ 192.070848] RIP: 0010:[<ffffffff8135fb85>] [<ffffffff8135fb85>]
ipv6_sock_mc_join+0x29/0x171
[ 192.072733] RSP: 0018:ffff88001775bdc8 EFLAGS: 00010246
[ 192.073871] RAX: ffffffff8145f160 RBX: ffff8800175dc8c0 RCX: ffff880017a32870
[ 192.075440] RDX: ffff8800175dc838 RSI: 0000000000000000 RDI: ffff880014052800
[ 192.077089] RBP: ffff8800175dc838 R08: ffff88001775a000 R09: 00000000000032e8
[ 192.078752] R10: 00000000000032e8 R11: 00000000000032e8 R12: ffff880014052800
[ 192.080426] R13: 0000000000000000 R14: ffffffff81678340 R15: 0000000000000000
[ 192.082071] FS: 0000000000000000(0000) GS:ffff880017a20000(0000)
knlGS:0000000000000000
[ 192.083955] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 192.085244] CR2: 0000000000000080 CR3: 000000000160b000 CR4: 00000000000407e0
[ 192.086882] Stack:
[ 192.087362] 0000000000000000 ffff8800175dc8c0 ffff880014052800
ffff880017160000
[ 192.089190] 0000000000000000 0000000000000000 0000000000000000
ffffffff81293269
[ 192.091022] ffff8800175727f0 ffff8800177413c0 ffff8800173bbef8
ffff88001755ea40
[ 192.093443] Call Trace:
[ 192.094056] [<ffffffff81293269>] ? vxlan_igmp_join+0x77/0xa3
[ 192.095399] [<ffffffff8104bc07>] ? process_one_work+0x191/0x294
[ 192.096791] [<ffffffff8104c0b9>] ? worker_thread+0x121/0x1e7
[ 192.098127] [<ffffffff8104bf98>] ? rescuer_thread+0x269/0x269
[ 192.099405] [<ffffffff81050ae1>] ? kthread+0x81/0x89
[ 192.100480] [<ffffffff81050a60>] ? __kthread_parkme+0x5d/0x5d
[ 192.101848] [<ffffffff8138e3fc>] ? ret_from_fork+0x7c/0xb0
[ 192.103135] [<ffffffff81050a60>] ? __kthread_parkme+0x5d/0x5d
[ 192.104493] Code: 5e c3 41 57 41 56 41 55 41 54 49 89 fc 55 48 89
d5 53 41 55 80 3a ff 4c 8b af 98 02 00 00 4c 8b 77 30 0f 85 30 01 00
00 41 89 f7 <49> 8b 9d 80 00 00 00 eb 28 45 85 ff 74 06 44 39 7b 10 75
19 48
[ 192.112812] RIP [<ffffffff8135fb85>] ipv6_sock_mc_join+0x29/0x171
[ 192.114208] RSP <ffff88001775bdc8>
[ 192.114978] CR2: 0000000000000080
[ 192.115813] BUG: unable to handle kernel NULL pointer dereference
at 000000000000006e
[ 192.117676] IP: [<ffffffff8134f89f>] ip6_route_output+0x50/0x76
[ 192.119045] PGD 0
[ 192.119564] Oops: 0000 [#2] SMP
[ 192.120856] Modules linked in: nfsd auth_rpcgss oid_registry
nfs_acl nfs lockd fscache sunrpc loop coretemp crc32c_intel vmwgfx ttm
ghash_clmulni_intel aesni_intel aes_x86_64 joydev ablk_helper drm
snd_pcm cryptd lrw snd_page_alloc snd_timer gf128mul glue_helper snd
processor hid_generic psmouse soundcore ehci_pci thermal_sys
parport_pc parport usbhid pcspkr serio_raw hid shpchp evdev i2c_piix4
i2c_core microcode button ac ext4 crc16 jbd2 mbcache dm_mod sg sd_mod
sr_mod cdrom crc_t10dif crct10dif_common ata_generic floppy e1000
uhci_hcd ehci_hcd usbcore usb_common mptspi ata_piix
scsi_transport_spi mptscsih mptbase libata scsi_mod
[ 192.137768] CPU: 1 PID: 173 Comm: kworker/1:2 Tainted: G D
3.12.1 #1
[ 192.139489] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 09/20/2012
[ 192.141859] Workqueue: vxlan vxlan_igmp_join
[ 192.142860] task: ffff8800175727f0 ti: ffff88001775a000 task.ti:
ffff88001775a000
[ 192.144565] RIP: 0010:[<ffffffff8134f89f>] [<ffffffff8134f89f>]
ip6_route_output+0x50/0x76
[ 192.146499] RSP: 0018:ffff880017a23a00 EFLAGS: 00010286
[ 192.149207] RAX: 0000000000000001 RBX: ffff880017a23b28 RCX: 00000000000000e0
[ 192.151009] RDX: 0000000000000000 RSI: ffff880014052800 RDI: ffff880017a23b3c
[ 192.152666] RBP: ffff880014052800 R08: 00000000000006c0 R09: 0000000000000000
[ 192.154308] R10: 0000000016000000 R11: ffff880014052800 R12: ffffffff81678340
[ 192.155951] R13: ffffffff81678340 R14: ffff880014052800 R15: ffff88001520e050
[ 192.157612] FS: 0000000000000000(0000) GS:ffff880017a20000(0000)
knlGS:0000000000000000
[ 192.159484] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 192.160834] CR2: 000000000000006e CR3: 000000000160b000 CR4: 00000000000407e0
[ 192.162509] Stack:
[ 192.163022] ffff880017a23b00 ffff880017a23b28 ffff8800175dc000
ffffffff81343dea
[ 192.164974] ffff8800170d6780 0000000000000972 ffff88001777b5c0
00000000f9437ecf
[ 192.166901] ffffffff8105f050 ffff8800170ce0c0 0000000000006e49
0000000000008000
[ 192.168821] Call Trace:
[ 192.169430] <IRQ>
[ 192.169909] [<ffffffff81343dea>] ? ip6_dst_lookup_tail+0x3c/0x1a7
[ 192.171425] [<ffffffff8105f050>] ? wakeup_preempt_entity.isra.46+0x18/0x28
[ 192.172940] [<ffffffff81294433>] ? vxlan_xmit_one+0x311/0x6de
[ 192.174230] [<ffffffff8105a6cf>] ? ttwu_do_wakeup+0xf/0xc1
[ 192.175452] [<ffffffff8105c189>] ? try_to_wake_up+0x17e/0x190
[ 192.176716] [<ffffffff812951bb>] ? vxlan_rcv+0x29d/0x2c2
[ 192.177951] [<ffffffff812c2b4d>] ? __copy_skb_header+0x95/0x28f
[ 192.179716] [<ffffffff81294e7d>] ? vxlan_xmit+0x67d/0x71e
[ 192.181003] [<ffffffff812c31ba>] ? __kmalloc_reserve.isra.43+0x2a/0x6d
[ 192.182535] [<ffffffff810fb5d0>] ? virt_to_head_page+0x5/0x27
[ 192.183889] [<ffffffff810fb860>] ? ksize+0x12/0x1e
[ 192.184989] [<ffffffff812c38e7>] ? __alloc_skb+0xb5/0x1a9
[ 192.186191] [<ffffffff812d012e>] ? dev_hard_start_xmit+0x271/0x3ec
[ 192.187573] [<ffffffff812d059c>] ? dev_queue_xmit+0x2f3/0x3c8
[ 192.188894] [<ffffffff812d81cd>] ? neigh_resolve_output+0xe3/0x121
[ 192.190254] [<ffffffff81344b0f>] ? ip6_finish_output2+0x2b3/0x30e
[ 192.191600] [<ffffffff8135da41>] ? mld_sendpack+0x176/0x27c
[ 192.192860] [<ffffffff8135eebf>] ? add_grec+0x37d/0x3c3
[ 192.194115] [<ffffffff8135f27e>] ? mld_ifc_timer_expire+0x1a9/0x1d8
[ 192.195592] [<ffffffff8135f0d5>] ? igmp6_timer_handler+0x5e/0x5e
[ 192.197006] [<ffffffff810407bf>] ? call_timer_fn+0x4b/0xf6
[ 192.198316] [<ffffffff8135f0d5>] ? igmp6_timer_handler+0x5e/0x5e
[ 192.199637] [<ffffffff81040db0>] ? run_timer_softirq+0x189/0x1ce
[ 192.200982] [<ffffffff8107cd81>] ? tick_sched_do_timer+0x25/0x25
[ 192.202369] [<ffffffff8103ae4c>] ? __do_softirq+0xe8/0x201
[ 192.203648] [<ffffffff81076224>] ? ktime_get+0x5f/0x6b
[ 192.204867] [<ffffffff8107b565>] ? clockevents_program_event+0x9a/0xb6
[ 192.206393] [<ffffffff8138fb1c>] ? call_softirq+0x1c/0x30
[ 192.207662] [<ffffffff81003b7c>] ? do_softirq+0x2c/0x60
[ 192.208923] [<ffffffff8103b02a>] ? irq_exit+0x3b/0x7f
[ 192.210130] [<ffffffff81023c39>] ? smp_apic_timer_interrupt+0x2c/0x37
[ 192.211658] [<ffffffff8138f04a>] ? apic_timer_interrupt+0x6a/0x70
[ 192.213021] <EOI>
[ 192.213456] [<ffffffff81054909>] ? up+0xc/0x35
[ 192.214589] [<ffffffff8138a1e9>] ? oops_end+0x5e/0xa7
[ 192.215723] [<ffffffff813826f5>] ? no_context+0x24f/0x27a
[ 192.216930] [<ffffffff8138c336>] ? __do_page_fault+0x359/0x3d7
[ 192.218215] [<ffffffff810611c0>] ? find_busiest_group+0x26/0x1aa
[ 192.219560] [<ffffffff813898b2>] ? page_fault+0x22/0x30
[ 192.220737] [<ffffffff8135fb85>] ? ipv6_sock_mc_join+0x29/0x171
[ 192.222113] [<ffffffff81389320>] ? _raw_spin_lock_bh+0xe/0x1c
[ 192.223488] [<ffffffff81293269>] ? vxlan_igmp_join+0x77/0xa3
[ 192.224820] [<ffffffff8104bc07>] ? process_one_work+0x191/0x294
[ 192.227456] [<ffffffff8104c0b9>] ? worker_thread+0x121/0x1e7
[ 192.228776] [<ffffffff8104bf98>] ? rescuer_thread+0x269/0x269
[ 192.230065] [<ffffffff81050ae1>] ? kthread+0x81/0x89
[ 192.231171] [<ffffffff81050a60>] ? __kthread_parkme+0x5d/0x5d
[ 192.232466] [<ffffffff8138e3fc>] ? ret_from_fork+0x7c/0xb0
[ 192.233737] [<ffffffff81050a60>] ? __kthread_parkme+0x5d/0x5d
[ 192.235013] Code: 8d 7b 14 e8 e8 fb 01 00 a8 32 0f 95 c0 0f b6 c0
48 8b 53 2c 48 0b 53 24 74 05 83 c8 04 eb 1a 48 85 ed 74 15 48 8b 95
98 02 00 00 <8a> 52 6e c0 ea 05 0f b6 d2 c1 e2 03 09 d0 48 89 de 4c 89
e7 48
[ 192.243063] RIP [<ffffffff8134f89f>] ip6_route_output+0x50/0x76
[ 192.244516] RSP <ffff880017a23a00>
[ 192.245355] CR2: 000000000000006e
[ 192.246205] ---[ end trace d2f5dcf3ce91b4cf ]---
[ 192.247572] Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* RE: [PATCH net] be2net: call napi_disable() for all event queues
From: Ajit Khaparde @ 2013-11-26 21:33 UTC (permalink / raw)
To: Ivan Vecera, netdev@vger.kernel.org; +Cc: Sathya Perla, Subramanian Seetharaman
In-Reply-To: <1385484881-25715-1-git-send-email-ivecera@redhat.com>
> -----Original Message-----
> From: Ivan Vecera [mailto:ivecera@redhat.com]
> Sent: Tuesday, November 26, 2013 10:55 AM
> To: netdev@vger.kernel.org
> Cc: Sathya Perla; Subramanian Seetharaman; Ajit Khaparde
> Subject: [PATCH net] be2net: call napi_disable() for all event queues
>
> The recent be2net commit 6384a4d (adds a support for busy polling)
> introduces a regression that results in kernel crash. It incorrectly
> modified be_close() so napi_disable() is called only for the first queue.
> This breaks a correct pairing of napi_enable/_disable for the rest
> of event queues and causes a crash in subsequent be_open() call.
>
> Cc: Sathya Perla <sathya.perla@emulex.com>
> Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
> Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Ajit Khaparde <ajit.khaparde@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
> b/drivers/net/ethernet/emulex/benet/be_main.c
> index 78a0e85..0aec4d2 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -2663,8 +2663,8 @@ static int be_close(struct net_device *netdev)
> napi_disable(&eqo->napi);
> be_disable_busy_poll(eqo);
> }
> - adapter->flags &= ~BE_FLAGS_NAPI_ENABLED;
> }
> + adapter->flags &= ~BE_FLAGS_NAPI_ENABLED;
>
> be_async_mcc_disable(adapter);
>
> --
> 1.8.3.2
^ permalink raw reply
* Re: [PATCH] macvtap: Do not double-count received packets
From: Michael S. Tsirkin @ 2013-11-26 21:09 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev
In-Reply-To: <1385487432-17651-1-git-send-email-vyasevic@redhat.com>
On Tue, Nov 26, 2013 at 12:37:12PM -0500, Vlad Yasevich wrote:
> Currently macvlan will count received packets after calling each
> vlans receive handler. Macvtap attempts to count the packet
> yet again when the user reads the packet from the tap socket.
> This code doesn't do this consistently either. Remove the
> counting from macvap and let only macvlan count received
> packets.
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/macvtap.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index dc76670..50f8dce 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -767,7 +767,6 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
> const struct sk_buff *skb,
> const struct iovec *iv, int len)
> {
> - struct macvlan_dev *vlan;
> int ret;
> int vnet_hdr_len = 0;
> int vlan_offset = 0;
> @@ -821,15 +820,6 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
> copied += len;
>
> done:
> - rcu_read_lock();
> - vlan = rcu_dereference(q->vlan);
> - if (vlan) {
> - preempt_disable();
> - macvlan_count_rx(vlan, copied - vnet_hdr_len, ret == 0, 0);
> - preempt_enable();
> - }
> - rcu_read_unlock();
> -
> return ret ? ret : copied;
> }
>
> --
> 1.8.4.2
^ permalink raw reply
* Re: r8169 Wake on Lan
From: Ben Hutchings @ 2013-11-26 20:36 UTC (permalink / raw)
To: Pablo Cholaky; +Cc: netdev
In-Reply-To: <CAEv3EXFiUnfkBCiedjXUzc6MXBnP2vqNx4R3739642dGYazTwA@mail.gmail.com>
On Tue, 2013-11-26 at 14:23 -0300, Pablo Cholaky wrote:
> Hi there:
>
> I have a HP ENVY laptop with this RealTek, and my laptop don't have a
> BIOS option to disable WOL. I'm currently using a script on start and
> shutdown to disable WOL, but could you guys make a module param to
> enable/disable WOL?
[...]
Module parameters are a terrible configuration interface, particularly
for settings that really apply to individual devices.
Most distributions provide a way to run ethtool when configuring an
interface; see
<http://sources.debian.net/src/ethtool/1:3.11-1/debian/README.Debian>
and look for ETHTOOL_OPTS in
<https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-networkscripts-interfaces.html>
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 0/5] net: hwmon fixes
From: Ben Hutchings @ 2013-11-26 20:08 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nithin Nayak Sujir, e1000-devel, netdev, Michael Chan,
Bruce Allan, Jesse Brandeburg, lm-sensors, David S. Miller
In-Reply-To: <52938D67.2000401@roeck-us.net>
On Mon, 2013-11-25 at 09:48 -0800, Guenter Roeck wrote:
> On 11/25/2013 09:15 AM, Ben Hutchings wrote:
> > On Sat, 2013-11-23 at 09:07 -0800, Guenter Roeck wrote:
> >> On 11/23/2013 08:48 AM, Ben Hutchings wrote:
> >>> On Fri, 2013-11-22 at 22:07 -0800, Guenter Roeck wrote:
> >>>> The hwmon subsystem is used by various network drivers to report temperature
> >>>> sensor and other information. Unfortunately, its use is often not correct.
> >>>> Typical errors are that the mandatory name sysfs attribute is not created,
> >>>> that the temperature sensor index starts with 0 instead of 1, and/or that
> >>>> sysfs attributes are created after the hwmon device was created.
> >>>
> >>> As it happens, I was just looking at what we do in sfc
> >>> (drivers/net/ethernet/sfc/mcdi_mon.c) and wondering why I made it create
> >>> the hwmon device before the attributes. I think I avoided the other
> >>> bugs though.
> >>>
> >> Hi Ben,
> >>
> >> Yes, I know about that one. It concluded that it would be too invasive
> >> and risky to try to fix it without access to hardware to test the results.
> >> That is why I said "fixes _most_ of the problems".
> >>
> >> As for why the attributes are created after registration, it was most likely
> >> because there was no API available to attach the sysfs attributes to
> >> the hwmon device in a clean way. The new APIs fix that.
> >
> > We don't attach them to the hwmon device either, and I would rather not
> > change that yet because lm-sensors 2 is still widely used.
> >
>
> Hmm .. then there should be no good reason to create the attributes
> only after hwmon registration.
>
> As for lm-sensors 2 ... really ? Seems odd that people would use the
> latest kernel with 5+ years old versions of applications / libraries.
> but I guess the world is full of such oddities, so maybe I should not
> be surprised.
[...]
As Jean pointed out, the net drivers implementing hwmon aren't supported
by lm-sensors 2 anyway. So we should go ahead and use the new API in
sfc. I've opened an internal bug report for this, but it is likely to
be low priority for the team. But if you write a patch I can test it.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 15/17] net: sfc calls skb_get_rxhash
From: Ben Hutchings @ 2013-11-26 19:59 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.02.1311252156170.23058@tomh.mtv.corp.google.com>
On Mon, 2013-11-25 at 21:57 -0800, Tom Herbert wrote:
> Drivers should call skb_get_rxhash to set the rxhash and its type
> in an skbuff.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/ethernet/sfc/rx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
> index 8f09e68..b51466e 100644
> --- a/drivers/net/ethernet/sfc/rx.c
> +++ b/drivers/net/ethernet/sfc/rx.c
> @@ -439,7 +439,8 @@ efx_rx_packet_gro(struct efx_channel *channel, struct efx_rx_buffer *rx_buf,
> }
>
> if (efx->net_dev->features & NETIF_F_RXHASH)
> - skb->rxhash = efx_rx_buf_hash(efx, eh);
> + skb_set_rxhash(skb, efx_rx_buf_hash(efx, eh),
> + RXHASH_TYPE_L3);
This is equivalent to what we do now. But efx_rx_packet_gro() is only
ever called for TCP packets (checked in __efx_rx_packet()) and their
hashes include port numbers, so the hash type could be RXHASH_TYPE_L4.
Ben.
> skb->ip_summed = ((rx_buf->flags & EFX_RX_PKT_CSUMMED) ?
> CHECKSUM_UNNECESSARY : CHECKSUM_NONE);
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: source address selection, Rule 7: Prefer temporary addresses (RFC 6724)
From: Hannes Frederic Sowa @ 2013-11-26 19:26 UTC (permalink / raw)
To: Florent Fourcot
Cc: fx.lebail, netdev, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, dcbw, jiri
In-Reply-To: <5294E13B.8010108@enst-bretagne.fr>
On Tue, Nov 26, 2013 at 06:58:19PM +0100, Florent Fourcot wrote:
> >> The RFC 6724 change the default recommendation for source address selection
> >> Rule 7 to prefer temporary addresses rather than public addresses,
> >> while providing an administrative override.
> >>
> >> The administrative override is based on the prefer_src_public sysctl.
> >
> > I like the idea and it could be useful in addition to the new
> > IFA_F_MANAGETEMPADDR flag which should show up any time soon.
> >
>
> I like the principle of the idea too, but is it acceptable to break the
> user space compatibility?
> If the patch is accepted, someone with the value "1" in use_tempaddr
> will have a big surprise with a newer kernel (I do not see any use case
> to set this option to 1, but maybe...).
Yeah, I thought about that, too. But as new kernels would ship with a default
policy of prefer those temporary addresses I thought it would be ok.
^ permalink raw reply
* Re: netfilter: active obj WARN when cleaning up
From: Sasha Levin @ 2013-11-26 19:11 UTC (permalink / raw)
To: pablo, kaber, kadlec, David S. Miller
Cc: netfilter-devel, coreteam, netdev, LKML
In-Reply-To: <522B25B5.6000808@oracle.com>
Ping? I still see this warning.
On 09/07/2013 09:10 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest, running latest -next kernel, I've
> stumbled on the following:
>
> [ 418.311956] ------------[ cut here ]------------
> [ 418.312449] WARNING: CPU: 6 PID: 4178 at lib/debugobjects.c:260 debug_print_object+0x8d/0xb0()
> [ 418.313243] ODEBUG: free active (active state 0) object type: timer_list hint:
> delayed_work_timer_fn+0x0/0x20
> [ 418.314038] Modules linked in:
> [ 418.314038] CPU: 6 PID: 4178 Comm: kworker/u16:2 Tainted: G W 3.11.0-next-20130906-sasha
> #3984
> [ 418.314038] Workqueue: netns cleanup_net
> [ 418.314038] 0000000000000104 ffff880410371a58 ffffffff841b7815 0000000000000104
> [ 418.314038] ffff880410371aa8 ffff880410371a98 ffffffff8112540c ffff880410371a78
> [ 418.314038] ffffffff853ea0ab ffff8800bdc68b80 ffffffff85a65c00 ffffffff87676658
> [ 418.314038] Call Trace:
> [ 418.314038] [<ffffffff841b7815>] dump_stack+0x52/0x87
> [ 418.320315] [<ffffffff8112540c>] warn_slowpath_common+0x8c/0xc0
> [ 418.321040] [<ffffffff811254f6>] warn_slowpath_fmt+0x46/0x50
> [ 418.321101] [<ffffffff81a60ded>] debug_print_object+0x8d/0xb0
> [ 418.321101] [<ffffffff811444e0>] ? __queue_work+0x390/0x390
> [ 418.321101] [<ffffffff81a61605>] __debug_check_no_obj_freed+0xa5/0x220
> [ 418.321101] [<ffffffff81249e76>] ? kmem_cache_destroy+0x86/0xe0
> [ 418.321101] [<ffffffff81a61795>] debug_check_no_obj_freed+0x15/0x20
> [ 418.321101] [<ffffffff812874d7>] kmem_cache_free+0x197/0x340
> [ 418.321101] [<ffffffff81249e76>] kmem_cache_destroy+0x86/0xe0
> [ 418.321101] [<ffffffff83d5d681>] nf_conntrack_cleanup_net_list+0x131/0x170
> [ 418.321101] [<ffffffff83d5ec5d>] nf_conntrack_pernet_exit+0x5d/0x70
> [ 418.321101] [<ffffffff83cda1ce>] ops_exit_list+0x5e/0x70
> [ 418.321101] [<ffffffff83cda80b>] cleanup_net+0xfb/0x1c0
> [ 418.321101] [<ffffffff81145c28>] process_one_work+0x338/0x550
> [ 418.321101] [<ffffffff81145b50>] ? process_one_work+0x260/0x550
> [ 418.321883] [<ffffffff81147605>] worker_thread+0x215/0x350
> [ 418.321883] [<ffffffff811473f0>] ? manage_workers+0x180/0x180
> [ 418.321883] [<ffffffff81150887>] kthread+0xe7/0xf0
> [ 418.321883] [<ffffffff811507a0>] ? __init_kthread_worker+0x70/0x70
> [ 418.321883] [<ffffffff841c7a2c>] ret_from_fork+0x7c/0xb0
> [ 418.321883] [<ffffffff811507a0>] ? __init_kthread_worker+0x70/0x70
> [ 418.321883] ---[ end trace c974221542b61d0d ]---
>
>
> Thanks,
> Sasha
^ permalink raw reply
* FW: loop on reset adapter with ixgbe
From: Skidmore, Donald C @ 2013-11-26 19:03 UTC (permalink / raw)
To: William Dauchy
Cc: netdev@vger.kernel.org, Keller, Jacob E, Fastabend, John R,
Tantilov, Emil S, Potenza, Leonardo
In-Reply-To: <20131126130410.GD2849@gandi.net>
From: Skidmore, Donald C
Sent: Tuesday, November 26, 2013 11:00 AM
To: 'William Dauchy'
Cc: netdev@vger.kernel.org; Keller, Jacob E; Fastabend, John R; Tantilov, Emil S; Potenza, Leonardo
Subject: RE: loop on reset adapter with ixgbe
Hey William,
A quick why to get the device ID would be to:
First get the PCIe bus address from "ethtool -I <port>"
[root@dcsworkstation src]# ethtool -i p258p1
driver: ixgbe
version: 3.11.33-k
firmware-version: 0x18eb0001
bus-info: 0000:05:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
Then use that address to find the device ID:
[root@dcsworkstation src]# lspci -ns 0000:05:00.0
05:00.0 0200: 8086:10fb (rev 01)
As for the FW version I'm concerned that yours might not be correct from the output you sent me earlier.
> ethtool info:
> driver: ixgbe
> version: 3.8.21-k
> firmware-version: 0x00000000
This doesn't look correct to me I will poke our FW folks to verify. It may be worthwhile to dump the FW and send it to me (i.e. ethtool -eeprom-dump).
Thanks,
-Don
p.s. I'm about to be out of the office until Tuesday of next week and am not sure I'll be able to get to my email so I might be slow in a reply. :(
> -----Original Message-----
> From: William Dauchy [mailto:william@gandi.net]
> Sent: Tuesday, November 26, 2013 5:04 AM
> To: Skidmore, Donald C
> Cc: William Dauchy; netdev@vger.kernel.org; Keller, Jacob E; Fastabend,
> John R; Tantilov, Emil S; Potenza, Leonardo
> Subject: Re: loop on reset adapter with ixgbe
>
> On Nov20 18:58, Skidmore, Donald C wrote:
> > I also just noticed your firmware looks in correct. What is the DevID for
> your device?
>
> might be a stupid question, but which id are you talking about? How can I get
> it?
>
> > Likewise do you have another NIC and if so could you check it's firmware-
> version?
>
> I have some NIC with the same firmware without any problem.
>
> Regards,
> --
> William
^ permalink raw reply
* Re: [PATCH] phy: Add Vitesse 8514 phy ID
From: Shruti Kanetkar @ 2013-11-26 18:38 UTC (permalink / raw)
To: shh.xie@gmail.com; +Cc: netdev@vger.kernel.org, David Miller
Hello Shao-Hui,
<shh.xie@gmail.com> wrote in message news:<1385354449-2943-1-git-send-email-shh.xie@gmail.com>...
> From: Shaohui Xie <Shaohui.Xie@freescale.com>
>
> Phy is compatible with Vitesse 82xx
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> drivers/net/phy/vitesse.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
Ack-ed by: Shruti Kanetkar <Shruti@freescale.com>
Regards,
Shruti.
^ 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