* RE: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
From: David Laight @ 2012-08-22 14:42 UTC (permalink / raw)
To: Linus Torvalds, Ben Hutchings
Cc: H. Peter Anvin, David Miller, tglx, mingo, netdev,
linux-net-drivers, x86
In-Reply-To: <CA+55aFzxhxjOeFSUUJ6XQGUmnaZf7QPSz611zmj2VziEDUB_sA@mail.gmail.com>
> Any patch that exports some "atomic 128-bit MMIO writes" for general
> use sounds totally and utterly broken. You can't do it. It's
> *fundamentally* an operation that many CPU's cannot even do. 64-bit
> buses (or even 32-bit ones) will make the 128-bit write be split up
> *anyway*, regardless of any 128-bit register issues.
>
> And nobody else sane cares about this, so it shouldn't even be a
> x86-64 specific thing...
There are several other processors that can generate long
PCIe transfers, sometimes by using a DMA engine associated
with the PCIe interface (eg freescale 83xx ppc).
Given the slow speed of PCIe transactions (think ISA bus
speeds - at least with some targets), it is important to
be able to request multi-word transfers in a generic way
on systems that can support it.
This support is a property of the PCIe interface block,
not that of the driver that wishes to use the function.
I don't know if XMM register transfers generate 16byte
TLP on any x86 cpus - they might on some.
Perhaps claiming the function is atomic is the real
problem - otherwise a single TLP could be used on
systems (and in contexts) where it is possible, but
a slower mulit-TLP transfer done (possibly without
guaranteeing the transfer order) done where it is not.
David
^ permalink raw reply
* Re: NULL deref in bnx2 / crashes ? ( was: netconsole leads to stalled CPU task )
From: Sylvain Munaut @ 2012-08-22 14:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1345640757.5158.1321.camel@edumazet-glaptop>
Hi,
> my patch was incomplete, sorry :
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index 346b1eb..ddc453b 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -335,8 +335,13 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
> /* don't get messages out of order, and no recursion */
> if (skb_queue_len(&npinfo->txq) == 0 && !netpoll_owner_active(dev)) {
> struct netdev_queue *txq;
> + int queue_index = skb_get_queue_mapping(skb);
>
> - txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
> + if (queue_index >= dev->real_num_tx_queues) {
> + queue_index = 0;
> + skb_set_queue_mapping(skb, 0);
> + }
> + txq = netdev_get_tx_queue(dev, queue_index);
>
> /* try until next clock tick */
> for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
Ok, I tried this.
The machine with the intel card still hard freeze (no output / no nothing ...)
The machine with the bnx2 don't crash anymore and no NULL deref, but
the modprobe still hangs and I get this every 180 sec or so :
[ 775.956926] INFO: rcu_preempt self-detected stall on CPU { 14}
(t=600009 jiffies)
[ 775.956927] Pid: 3154, comm: modprobe Not tainted
3.6.0-rc2-00092-g9040592-dirty #8
[ 775.956928] Call Trace:
[ 775.956931] <IRQ> [<ffffffff81094a58>] ? rcu_pending+0xee/0x490
[ 775.956933] [<ffffffff810571da>] ?
irqtime_account_process_tick.isra.73+0x134/0x23a
[ 775.956934] [<ffffffff81095406>] ? rcu_check_callbacks+0x79/0x85
[ 775.956936] [<ffffffff81041609>] ? update_process_times+0x30/0x62
[ 775.956938] [<ffffffff8106f204>] ? tick_sched_timer+0x75/0x9e
[ 775.956939] [<ffffffff8106f18f>] ? tick_nohz_handler+0xd0/0xd0
[ 775.956941] [<ffffffff810501cf>] ? __run_hrtimer.isra.26+0x75/0xcd
[ 775.956943] [<ffffffff81050873>] ? hrtimer_interrupt+0xe2/0x1f0
[ 775.956948] [<ffffffffa000941d>] ? bnx2_poll_work+0x2d3/0xa52 [bnx2]
[ 775.956950] [<ffffffff8100fa5c>] ? sched_clock+0x5/0x8
[ 775.956952] [<ffffffff81023d93>] ? smp_apic_timer_interrupt+0x6d/0x7f
[ 775.956954] [<ffffffff8133244a>] ? apic_timer_interrupt+0x6a/0x70
[ 775.956956] [<ffffffff8126d407>] ? __napi_complete+0x1c/0x23
[ 775.956958] [<ffffffff81074249>] ? do_raw_spin_lock+0x18/0x1b
[ 775.956960] [<ffffffff8126e596>] ? net_rx_action+0x7f/0x185
[ 775.956962] [<ffffffff8100f80e>] ? __cycles_2_ns+0x9/0x45
[ 775.956964] [<ffffffff8103caae>] ? __do_softirq+0x9c/0x14b
[ 775.956966] [<ffffffff81332b3c>] ? call_softirq+0x1c/0x30
[ 775.956968] <EOI> [<ffffffff8100aea6>] ? do_softirq+0x3c/0x7a
[ 775.956970] [<ffffffff8103c9db>] ? _local_bh_enable_ip.isra.7+0x76/0xa3
[ 775.956972] [<ffffffff812804b7>] ? netpoll_poll_dev+0xfe/0x4bc
[ 775.956974] [<ffffffff81280b02>] ? netpoll_send_skb_on_dev+0x28d/0x33b
[ 775.956978] [<ffffffffa0ff2c4c>] ? bond_dev_queue_xmit+0x62/0x7f [bonding]
[ 775.956982] [<ffffffffa0ff7588>] ? bond_3ad_xmit_xor+0xe7/0x10c [bonding]
[ 775.956984] [<ffffffffa0ff2ffd>] ? bond_start_xmit+0x394/0x3ff [bonding]
[ 775.956987] [<ffffffff81280ac1>] ? netpoll_send_skb_on_dev+0x24c/0x33b
[ 775.956990] [<ffffffffa0079fd5>] ?
vlan_dev_hard_start_xmit+0xab/0xf6 [8021q]
[ 775.956992] [<ffffffff81280ac1>] ? netpoll_send_skb_on_dev+0x24c/0x33b
[ 775.956996] [<ffffffffa01998e8>] ? __br_deliver+0x93/0xbe [bridge]
[ 775.956998] [<ffffffffa019837d>] ? br_dev_xmit+0x14a/0x16b [bridge]
[ 775.957001] [<ffffffff81280ac1>] ? netpoll_send_skb_on_dev+0x24c/0x33b
[ 775.957003] [<ffffffff81280372>] ? find_skb.isra.24+0x31/0x78
[ 775.957005] [<ffffffff81280bdc>] ? netpoll_send_skb+0x2c/0x39
[ 775.957007] [<ffffffffa00c422a>] ? write_msg+0x98/0xf3 [netconsole]
[ 775.957009] [<ffffffff81037db2>] ?
call_console_drivers.constprop.17+0x6e/0x7d
[ 775.957011] [<ffffffff81038248>] ? console_unlock+0x2ab/0x351
[ 775.957012] [<ffffffff81039112>] ? register_console+0x273/0x303
[ 775.957014] [<ffffffffa0103182>] ? init_netconsole+0x182/0x210 [netconsole]
[ 775.957016] [<ffffffffa0103000>] ? 0xffffffffa0102fff
[ 775.957018] [<ffffffff81002085>] ? do_one_initcall+0x75/0x12c
[ 775.957019] [<ffffffff81077b35>] ? sys_init_module+0x80/0x1c5
[ 775.957020] [<ffffffff813319b9>] ? system_call_fastpath+0x16/0x1b
Cheers,
Sylvain
^ permalink raw reply
* Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
From: Ben Hutchings @ 2012-08-22 14:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, David Miller, tglx, mingo, netdev,
linux-net-drivers, x86
In-Reply-To: <CA+55aFzxhxjOeFSUUJ6XQGUmnaZf7QPSz611zmj2VziEDUB_sA@mail.gmail.com>
On Wed, 2012-08-22 at 07:20 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2012 at 6:26 AM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> >
> > It's <1345598804.2659.78.camel@bwh-desktop.uk.solarflarecom.com>.
>
> That doesn't help me in the least. I don't *have* that email. It was
> never sent to me. I don't know what list it went on, and googling the
> ID doesn't get me anything. So sending me the mail ID is kind of
> pointless.
>
> So I still don't see the actual patch. But everything I heard about it
> indirectly makes me go "That's just crazy".
Sorry, I'll paste it below.
> > When updating a TX DMA ring pointer in sfc, we can push the first new
> > descriptor at the same time, so that for a linear packet only one DMA
> > read is then required before the packet goes out on the wire. Currently
> > this requires 2-4 MMIO writes (each a separate PCIe transactions),
> > depending on the host word size. There is a measurable reduction in
> > latency if we can reduce it to 1 PCIe transaction. (But as previously
> > discussed, write-combining isn't suitable for this.)
>
> Quite frankly, this isn't even *remotely* changing my mind about our
> FPU model. I'm like "ok, some random driver is trying to be clever,
> and it's almost certainly getting things entirely wrong and doing
> things that only work on certain machines".
>
> If you really think it's a big deal, do it in *your* driver, and make
> it do the whole irq_fpu_usable() check together with
> kernel_fpu_begin/end(). And make it very much x86-specific and with a
> fallback to non-atomic accesses.
[...]
Which is what I first submitted, but David wanted it to be generic.
Ben.
---
Subject: sfc: Use __raw_writeo() to perform TX descriptor push where possible
Use the new __raw_writeo() function for TX descriptor push where
available. This means we now use only a single PCIe transaction
on x86_64 (vs 2 before), reducing TX latency slightly.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/bitfield.h | 3 +++
drivers/net/ethernet/sfc/io.h | 18 ++++++++++++++++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/bitfield.h b/drivers/net/ethernet/sfc/bitfield.h
index b26a954..5feeba2 100644
--- a/drivers/net/ethernet/sfc/bitfield.h
+++ b/drivers/net/ethernet/sfc/bitfield.h
@@ -83,6 +83,9 @@ typedef union efx_qword {
/* An octword (eight-word, i.e. 16 byte) datatype - little-endian in HW */
typedef union efx_oword {
+#ifdef HAVE_INT128
+ __le128 u128;
+#endif
__le64 u64[2];
efx_qword_t qword[2];
__le32 u32[4];
diff --git a/drivers/net/ethernet/sfc/io.h b/drivers/net/ethernet/sfc/io.h
index 751d1ec..fbcdc6d 100644
--- a/drivers/net/ethernet/sfc/io.h
+++ b/drivers/net/ethernet/sfc/io.h
@@ -57,10 +57,22 @@
* current state.
*/
-#if BITS_PER_LONG == 64
+#if defined(writeo)
+#define EFX_USE_OWORD_IO 1
+#endif
+
+#if defined(readq) && defined(writeq)
#define EFX_USE_QWORD_IO 1
#endif
+#ifdef EFX_USE_OWORD_IO
+static inline void _efx_writeo(struct efx_nic *efx, __le128 value,
+ unsigned int reg)
+{
+ __raw_writeo((__force u128)value, efx->membase + reg);
+}
+#endif
+
#ifdef EFX_USE_QWORD_IO
static inline void _efx_writeq(struct efx_nic *efx, __le64 value,
unsigned int reg)
@@ -235,7 +247,9 @@ static inline void _efx_writeo_page(struct efx_nic *efx, efx_oword_t *value,
"writing register %x with " EFX_OWORD_FMT "\n", reg,
EFX_OWORD_VAL(*value));
-#ifdef EFX_USE_QWORD_IO
+#if defined(EFX_USE_OWORD_IO)
+ _efx_writeo(efx, value->u128, reg);
+#elif defined(EFX_USE_QWORD_IO)
_efx_writeq(efx, value->u64[0], reg + 0);
_efx_writeq(efx, value->u64[1], reg + 8);
#else
--
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 related
* Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
From: Linus Torvalds @ 2012-08-22 14:20 UTC (permalink / raw)
To: Ben Hutchings
Cc: H. Peter Anvin, David Miller, tglx, mingo, netdev,
linux-net-drivers, x86
In-Reply-To: <1345642009.15245.0.camel@deadeye.wl.decadent.org.uk>
On Wed, Aug 22, 2012 at 6:26 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
>
> It's <1345598804.2659.78.camel@bwh-desktop.uk.solarflarecom.com>.
That doesn't help me in the least. I don't *have* that email. It was
never sent to me. I don't know what list it went on, and googling the
ID doesn't get me anything. So sending me the mail ID is kind of
pointless.
So I still don't see the actual patch. But everything I heard about it
indirectly makes me go "That's just crazy".
> When updating a TX DMA ring pointer in sfc, we can push the first new
> descriptor at the same time, so that for a linear packet only one DMA
> read is then required before the packet goes out on the wire. Currently
> this requires 2-4 MMIO writes (each a separate PCIe transactions),
> depending on the host word size. There is a measurable reduction in
> latency if we can reduce it to 1 PCIe transaction. (But as previously
> discussed, write-combining isn't suitable for this.)
Quite frankly, this isn't even *remotely* changing my mind about our
FPU model. I'm like "ok, some random driver is trying to be clever,
and it's almost certainly getting things entirely wrong and doing
things that only work on certain machines".
If you really think it's a big deal, do it in *your* driver, and make
it do the whole irq_fpu_usable() check together with
kernel_fpu_begin/end(). And make it very much x86-specific and with a
fallback to non-atomic accesses.
Any patch that exports some "atomic 128-bit MMIO writes" for general
use sounds totally and utterly broken. You can't do it. It's
*fundamentally* an operation that many CPU's cannot even do. 64-bit
buses (or even 32-bit ones) will make the 128-bit write be split up
*anyway*, regardless of any 128-bit register issues.
And nobody else sane cares about this, so it shouldn't even be a
x86-64 specific thing. It should be a driver hack, since that's what
it is. We don't want to support crazy stuff like this in general, that
is not just architecture-, but microarchitecture-specific.
I think you'd be crazy to even want to do this in the first place, but
if you do, keep it internal to your driver, and don't expose the crazy
to anybody else.
Linus
^ permalink raw reply
* Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
From: Linus Torvalds @ 2012-08-22 14:06 UTC (permalink / raw)
To: David Miller; +Cc: hpa, bhutchings, tglx, mingo, netdev, linux-net-drivers, x86
In-Reply-To: <20120821.220010.1158630981089834558.davem@davemloft.net>
On Tue, Aug 21, 2012 at 10:00 PM, David Miller <davem@davemloft.net> wrote:
>
> All the x86 crypto code hits this case all the time, easiest example
> is doing a dm-crypt on a block device when an IPSEC packet arrives.
>
> The crypto code has all of this special code and layering that is
> there purely so it can fall back to the slow non-optimized version
> of the crypto operation when it hits this can't-nest-fpu-saving
> situation.
Right. And it needs to be there. The current interface is fine and correct.
We can maybe optimize the current model (as outlined earlier), but no,
there's no way in hell we're doing lazy saving of FPU state from
interrupts etc. So all the "check if I can use FPU state at all", and
the explicit kernel_fpu_begin/end() interfaces are absolutely the
right model.
I realize that the people who write that code think that *their* code
is the most important thing in the world, and everything else should
revolve around them, and we should make everything else slower just to
make them happy. But they are wrong.
Deal with it, or do not. You can do the crypto entirely in software. I
think the current model is absolutely the right one, exactly because
it *allows* you to use the FPU for crypto, but it doesn't force the
rest of the kernel to make sure the FPU is always available to you.
I think your complaining about the interface is entirely bogus, and
comes from not appreciating that other areas and uses have other
concerns.
What I would suggest is trying to do profiling, and seeing if the
"let's try to save only once, and restore only when returning to user
space" approach helps. But that's an *implementation* change, not an
interface change. The interface is doing the right thing, the
implementation is just not perhaps optimal.
Linus
^ permalink raw reply
* Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
From: Ben Hutchings @ 2012-08-22 13:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, David Miller, tglx, mingo, netdev,
linux-net-drivers, x86
In-Reply-To: <CA+55aFy=ohFoZ1yZGdj1DCcNXU9gsndgH9Qod4q8+s=sbGKUzQ@mail.gmail.com>
On Tue, 2012-08-21 at 20:52 -0700, Linus Torvalds wrote:
[...]
> I haven't seen the patch being discussed, or the rationale for it. But
> I doubt it makes sense to do 128-bit MMIO and expect any kind of
> atomicity things anyway, and I very much doubt that using SSE would
> make all that much sense. What's the background, and why would you
> want to do this crap?
It's <1345598804.2659.78.camel@bwh-desktop.uk.solarflarecom.com>.
When updating a TX DMA ring pointer in sfc, we can push the first new
descriptor at the same time, so that for a linear packet only one DMA
read is then required before the packet goes out on the wire. Currently
this requires 2-4 MMIO writes (each a separate PCIe transactions),
depending on the host word size. There is a measurable reduction in
latency if we can reduce it to 1 PCIe transaction. (But as previously
discussed, write-combining isn't suitable for this.)
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 v3 13/17] lockd: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-08-22 13:22 UTC (permalink / raw)
To: Sasha Levin
Cc: J. Bruce Fields, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tj-DgEjT+Ai2ygdnm+yROfE0A, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, axboe-tSWWG44O7X1aa/9Udqfwiw,
agk-H+wXaHxf7aLQT0dZR+AlfA, dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
neilb-l3A5Bk7waGM, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w, jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <5034CD02.2010103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Sasha Levin (levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) wrote:
> On 08/22/2012 01:47 PM, J. Bruce Fields wrote:
> > On Wed, Aug 22, 2012 at 04:27:08AM +0200, Sasha Levin wrote:
> >> +static int __init nlm_init(void)
> >> +{
> >> + hash_init(nlm_files);
> >> + return 0;
> >> +}
> >> +
> >> +module_init(nlm_init);
> >
> > That's giving me:
> >
> > fs/lockd/svcsubs.o: In function `nlm_init':
> > /home/bfields/linux-2.6/fs/lockd/svcsubs.c:454: multiple definition of `init_module'
> > fs/lockd/svc.o:/home/bfields/linux-2.6/fs/lockd/svc.c:606: first defined here
> > make[2]: *** [fs/lockd/lockd.o] Error 1
> > make[1]: *** [fs/lockd] Error 2
> > make[1]: *** Waiting for unfinished jobs....
>
> I tested this entire patch set both with linux-next and Linus' latest master,
> and it worked fine in both places.
>
> Is it possible that lockd has a -next tree which isn't pulled into linux-next?
> (there's nothing listed in MAINTAINERS that I could see).
fs/lockd/Makefile:
obj-$(CONFIG_LOCKD) += lockd.o
lockd-objs-y := clntlock.o clntproc.o clntxdr.o host.o svc.o svclock.o \
svcshare.o svcproc.o svcsubs.o mon.o xdr.o grace.o
your patch adds a module_init to svcsubs.c.
However, there is already one in svc.c, pulled into the same module.
in your test build, is CONFIG_LOCKD defined as "m" or "y" ? You should
always test both.
One solution here is to create a "local" init function in svcsubs.c and
expose it to svc.c, so the latter can call it from its module init
function.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v3 13/17] lockd: use new hashtable implementation
From: J. Bruce Fields @ 2012-08-22 13:12 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, neilb,
ccaulfie, teigland, Trond.Myklebust, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <5034CD02.2010103@gmail.com>
On Wed, Aug 22, 2012 at 02:13:54PM +0200, Sasha Levin wrote:
> On 08/22/2012 01:47 PM, J. Bruce Fields wrote:
> > On Wed, Aug 22, 2012 at 04:27:08AM +0200, Sasha Levin wrote:
> >> +static int __init nlm_init(void)
> >> +{
> >> + hash_init(nlm_files);
> >> + return 0;
> >> +}
> >> +
> >> +module_init(nlm_init);
> >
> > That's giving me:
> >
> > fs/lockd/svcsubs.o: In function `nlm_init':
> > /home/bfields/linux-2.6/fs/lockd/svcsubs.c:454: multiple definition of `init_module'
> > fs/lockd/svc.o:/home/bfields/linux-2.6/fs/lockd/svc.c:606: first defined here
> > make[2]: *** [fs/lockd/lockd.o] Error 1
> > make[1]: *** [fs/lockd] Error 2
> > make[1]: *** Waiting for unfinished jobs....
>
> I tested this entire patch set both with linux-next and Linus' latest master,
> and it worked fine in both places.
>
> Is it possible that lockd has a -next tree which isn't pulled into linux-next?
> (there's nothing listed in MAINTAINERS that I could see).
No, there's the same problem with Linus's latest.
I'm applying just patches 1 and 13--but doesn't look like your earlier
patches touch lockd.
Are you actually building lockd? (CONFIG_LOCKD).
--b.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: NULL deref in bnx2 / crashes ? ( was: netconsole leads to stalled CPU task )
From: Eric Dumazet @ 2012-08-22 13:05 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: netdev
In-Reply-To: <CAF6-1L6zr5WJxo6FVk+2ya=EEs++u3x9iSrDxX-weBofLJuA1g@mail.gmail.com>
On Wed, 2012-08-22 at 14:17 +0200, Sylvain Munaut wrote:
> Hi,
>
> > Could be the infamous slave_dev_queue_mapping striking again.
> >
> > Could you please try :
> >
> > diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> > index 346b1eb..df731a0 100644
> > --- a/net/core/netpoll.c
> > +++ b/net/core/netpoll.c
> > @@ -335,8 +335,11 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
> > /* don't get messages out of order, and no recursion */
> > if (skb_queue_len(&npinfo->txq) == 0 && !netpoll_owner_active(dev)) {
> > struct netdev_queue *txq;
> > + int queue_index = skb_get_queue_mapping(skb);
> >
> > - txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
> > + if (queue_index >= dev->real_num_tx_queues)
> > + queue_index = 0;
> > + txq = netdev_get_tx_queue(dev, queue_index);
> >
> > /* try until next clock tick */
> > for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
>
>
> Well, it doesn't solve the problem :(
>
> It does have an effect though. Now even on the machine with the
> broadcom card, it just freeze the machine ...
> On the machine with intel card, it actually does get a couple of
> netconsole packet out and then freeze as well.
>
my patch was incomplete, sorry :
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 346b1eb..ddc453b 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -335,8 +335,13 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
/* don't get messages out of order, and no recursion */
if (skb_queue_len(&npinfo->txq) == 0 && !netpoll_owner_active(dev)) {
struct netdev_queue *txq;
+ int queue_index = skb_get_queue_mapping(skb);
- txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
+ if (queue_index >= dev->real_num_tx_queues) {
+ queue_index = 0;
+ skb_set_queue_mapping(skb, 0);
+ }
+ txq = netdev_get_tx_queue(dev, queue_index);
/* try until next clock tick */
for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
^ permalink raw reply related
* Re: NULL deref in bnx2 / crashes ? ( was: netconsole leads to stalled CPU task )
From: Sylvain Munaut @ 2012-08-22 12:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1345634026.5158.1084.camel@edumazet-glaptop>
Hi,
> Could be the infamous slave_dev_queue_mapping striking again.
>
> Could you please try :
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index 346b1eb..df731a0 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -335,8 +335,11 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
> /* don't get messages out of order, and no recursion */
> if (skb_queue_len(&npinfo->txq) == 0 && !netpoll_owner_active(dev)) {
> struct netdev_queue *txq;
> + int queue_index = skb_get_queue_mapping(skb);
>
> - txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
> + if (queue_index >= dev->real_num_tx_queues)
> + queue_index = 0;
> + txq = netdev_get_tx_queue(dev, queue_index);
>
> /* try until next clock tick */
> for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
Well, it doesn't solve the problem :(
It does have an effect though. Now even on the machine with the
broadcom card, it just freeze the machine ...
On the machine with intel card, it actually does get a couple of
netconsole packet out and then freeze as well.
FYI this is the disass of bnx2 module around the issue :
0x00000000000065f9 <+433>: mov %rax,%rsi
0x00000000000065fc <+436>: mov %rax,0x8(%rsp)
0x0000000000006601 <+441>: add $0x98,%rdi
0x0000000000006608 <+448>: callq 0xac9 <dma_mapping_error>
0x000000000000660d <+453>: test %eax,%eax
0x000000000000660f <+455>: mov 0x8(%rsp),%rdx
0x0000000000006614 <+460>: mov 0x10(%rsp),%r8d
0x0000000000006619 <+465>: mov 0x18(%rsp),%r9d
0x000000000000661e <+470>: jne 0x6966 <bnx2_start_xmit+1310>
0x0000000000006624 <+476>: movzbl %r15b,%eax
0x0000000000006628 <+480>: shl $0x10,%r9d
0x000000000000662c <+484>: mov %rdx,%rsi
0x000000000000662f <+487>: imul $0x18,%rax,%rcx
0x0000000000006633 <+491>: shl $0x4,%rax
0x0000000000006637 <+495>: shr $0x20,%rsi
0x000000000000663b <+499>: add 0x350(%r12),%rcx
0x0000000000006643 <+507>: or %r9d,%r8d
0x0000000000006646 <+510>: mov %r9d,0x38(%rsp)
0x000000000000664b <+515>: movl $0x0,0x24(%rsp)
0x0000000000006653 <+523>: mov %rdx,0x8(%rcx)
0x0000000000006657 <+527>: mov %rbx,(%rcx)
0x000000000000665a <+530>: add 0x348(%r12),%rax
0x0000000000006662 <+538>: mov %edx,0x4(%rax)
0x0000000000006665 <+541>: mov %r14d,%edx
0x0000000000006668 <+544>: mov %esi,(%rax)
0x000000000000666a <+546>: or $0x80,%dl
0x000000000000666d <+549>: mov %r8d,0x8(%rax)
0x0000000000006671 <+553>: mov %edx,0xc(%rax)
The issue it at this line :
0x0000000000006653 <+523>: mov %rdx,0x8(%rcx)
RCX is NULL it seems.
Cheers,
Sylvain Munaut
^ permalink raw reply
* Re: [PATCH v3 13/17] lockd: use new hashtable implementation
From: Sasha Levin @ 2012-08-22 12:13 UTC (permalink / raw)
To: J. Bruce Fields
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tj-DgEjT+Ai2ygdnm+yROfE0A, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w, jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <20120822114752.GC20158-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On 08/22/2012 01:47 PM, J. Bruce Fields wrote:
> On Wed, Aug 22, 2012 at 04:27:08AM +0200, Sasha Levin wrote:
>> +static int __init nlm_init(void)
>> +{
>> + hash_init(nlm_files);
>> + return 0;
>> +}
>> +
>> +module_init(nlm_init);
>
> That's giving me:
>
> fs/lockd/svcsubs.o: In function `nlm_init':
> /home/bfields/linux-2.6/fs/lockd/svcsubs.c:454: multiple definition of `init_module'
> fs/lockd/svc.o:/home/bfields/linux-2.6/fs/lockd/svc.c:606: first defined here
> make[2]: *** [fs/lockd/lockd.o] Error 1
> make[1]: *** [fs/lockd] Error 2
> make[1]: *** Waiting for unfinished jobs....
I tested this entire patch set both with linux-next and Linus' latest master,
and it worked fine in both places.
Is it possible that lockd has a -next tree which isn't pulled into linux-next?
(there's nothing listed in MAINTAINERS that I could see).
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v6] bonding support for IPv6 transmit hashing
From: Jeremy Brookman @ 2012-08-22 12:06 UTC (permalink / raw)
To: John Eaglesham; +Cc: Jay Vosburgh, netdev
In-Reply-To: <503409DC.5010001@8192.net>
>> If John signs off and somebody tests this, I'll post a formal
>> submssion with the full commit message.
>
> Since my last submission I ended up making some changes on my end to
> streamline the logic. I can fold together my patch with yours and test them
> later tonight. If everything looks good I'll post the changes back to the
> list.
Great - thanks for that Jay/John; will look forward to the latest
patch later. I'm actually looking at the 2.6.32 branch so have tested
a backport of Jay's patch (which only took a couple of very minor
modifications); a quick test on an 8-port bond with layer3+4 hashing
looked fine. (Will hold off until the final patch before doing more
testing.)
Regards,
Jeremy
On Tue, Aug 21, 2012 at 11:21 PM, John Eaglesham <linux@8192.net> wrote:
> On 8/21/2012 12:19 PM, Jay Vosburgh wrote:
>>
>> Jeremy Brookman <jeremy.brookman@gmail.com> wrote:
>>
>>>> You should use a mix of tabs, as necessary, to get things to line up
>>>> how I told you they need to line up.
>>>
>>>
>>> Unless I'm missing something, this change doesn't seem to have made it
>>> through to the kernel tip, but we could really use this bugfix. Is it
>>> in a repository I didn't notice, or not yet through the review? If
>>> it's not through the review, is any help needed to get it there?
>>
>>
>> The submitter (John Eaglesham) never posted an updated version
>> that addressed the various comments, nor did his original patch
>> submission include a Signed-off-by.
>>
>> I went ahead and updated the patch to address the comments; I've
>> only compile tested this. Are you (Jeremy or John) able to test this to
>> confirm that it will hash ipv6 traffic as expected (I can test it, but
>> it won't be today)?
>>
>> John, can you post a Signed-off-by for your patch (really, this
>> updated version of your patch)?
>>
^ permalink raw reply
* Problem removing netns
From: Bjørnar Ness @ 2012-08-22 11:59 UTC (permalink / raw)
To: netdev
I am experimenting with netns (Linux precision 3.2.0-0.bpo.2-amd64 #1
SMP Sun Jun 3 21:40:57 UTC 2012 x86_64 GNU/Linux)
and have problems removing unused namespace, this is what I do:
ip netns add netns_one
ip netns add netns_two
ip link add name if_one type veth peer name if_one_peer
ip link add name if_two type veth peer name if_two_peer
ip link set dev if_one_peer netns netns_one
ip link set dev if_two_peer netns netns_two
ip netns exec netns_one bash
# in other terminal:
ip netns delete netns_two
# => Cannot remove /var/run/netns/netns_two: Device or resource busy
Is this expected behaviour? If so, what is the correct process to
actually remove a namespace?
--
Bj(/)rnar
^ permalink raw reply
* Re: [PATCH v3 13/17] lockd: use new hashtable implementation
From: J. Bruce Fields @ 2012-08-22 11:47 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, neilb,
ccaulfie, teigland, Trond.Myklebust, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <1345602432-27673-14-git-send-email-levinsasha928@gmail.com>
On Wed, Aug 22, 2012 at 04:27:08AM +0200, Sasha Levin wrote:
> +static int __init nlm_init(void)
> +{
> + hash_init(nlm_files);
> + return 0;
> +}
> +
> +module_init(nlm_init);
That's giving me:
fs/lockd/svcsubs.o: In function `nlm_init':
/home/bfields/linux-2.6/fs/lockd/svcsubs.c:454: multiple definition of `init_module'
fs/lockd/svc.o:/home/bfields/linux-2.6/fs/lockd/svc.c:606: first defined here
make[2]: *** [fs/lockd/lockd.o] Error 1
make[1]: *** [fs/lockd] Error 2
make[1]: *** Waiting for unfinished jobs....
--b.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] net: dev: fix the incorrect hold of net namespace's lo device
From: Eric Dumazet @ 2012-08-22 11:24 UTC (permalink / raw)
To: Gao feng; +Cc: ebiederm, davem, netdev
In-Reply-To: <5034BBBB.6080307@cn.fujitsu.com>
On Wed, 2012-08-22 at 19:00 +0800, Gao feng wrote:
> Hi Eric
>
> I saw your patch and think this patch is clear and doesn't change too much logic.
>
> I test your patch, it not fix this problem.
>
> In my test case,when moving a net device to another net namespace,
> Because you patch delete NETDEV_UNREGISTER event from dst_dev_event,
> we will just put dst entries into the dst garbage list in event
> NETDEV_DOWN,without call dst_ifdown to change these dst entries' device
> to the lo device,and now this net device belongs to the new net namespace.
>
Then fix the "moving a net device to another net namespace", instead
of slowing down other common operations.
dev_change_net_namespace() is probably a better place to put your patch
> After the net device beeing moved to another net namespace, I rmmod this
> net device's driver,this will trigger the new added event NETDEV_UNREGISTER_FINISH,
> so in dst_dev_event,we will change these dst entries's device to the new net
> namespace's lo device,and this will make the referenct count of the new net namespace's
> lo device incorrect. when we exit the new net namespace,this emg message is still exist.
>
> Message from syslogd@Donkey at Aug 22 18:50:13 ...
> kernel:[ 1161.979036] unregister_netdevice: waiting for lo to become free. Usage count = 1
>
> And because net_mutex is locked here,so we can't create new net namespace.
>
> > rcu_barrier() at this place will kill some workloads.
> >
>
> I think this will only add some workloads when unregister a net device.
> Do I miss something?
Yes, rcu_barrier() at this point is killing performance, because we hold
RTNL.
We worked hard to batch things, your patch is a huge step backward.
^ permalink raw reply
* Re: NULL deref in bnx2 / crashes ? ( was: netconsole leads to stalled CPU task )
From: Eric Dumazet @ 2012-08-22 11:13 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: netdev
In-Reply-To: <CAF6-1L4wh0P-Wi-keN98wb-2V_avZYVE3ycf3tEe9SBpgK1dDQ@mail.gmail.com>
On Wed, 2012-08-22 at 12:53 +0200, Sylvain Munaut wrote:
> Hi again, a bit more detail:
>
> > I'm trying to use the netconsole to feed kernel message to the outside
> > but this lead to a stall ...
> >
> > This only happens in a fairly specific configuration where you have a
> > bridge over vlan over bonding.
> > I tested with only (bridge over vlan) and (vlan over bonding) and
> > those work fine.
> >
> > [snip ... see original mail for all details]
>
> I was previously testing under Xen.
>
> For this round of test, I tried the kernel natively. And I also
> included Dave Miller pending series ( e0e3cea4... ) since there was
> patch related to netconsole and bridging / ...
> So in the end, it's a 3.6-rc2 + Dave Miller tree (commit e0e3cea4 ) +
> pf malloc patch + ip pmtu patch from Eric Dumazet.
>
> I am now seeing more debug when I load netconsole in that config:
>
> [ 88.705138] netpoll: netconsole: local port 8888
> [ 88.705140] netpoll: netconsole: local IP 10.208.1.30
> [ 88.705141] netpoll: netconsole: interface 'mgmt'
> [ 88.705142] netpoll: netconsole: remote port 8000
> [ 88.705143] netpoll: netconsole: remote IP 10.208.1.3
> [ 88.705144] netpoll: netconsole: remote ethernet address 00:16:3e:1a:37:37
> [ 88.705469] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000008
> [ 88.705475] IP: [<ffffffffa0006653>] bnx2_start_xmit+0x20b/0x539 [bnx2]
> [ 88.705476] PGD 0
> [ 88.705478] Oops: 0002 [#1] PREEMPT SMP
> [ 88.705509] Modules linked in: netconsole(+) configfs nfsd
> auth_rpcgss nfs_acl nfs lockd fscache sunrpc bridge 8021q garp stp llc
> bonding ext2 iTCO_wdt iTCO_vendor_support lpc_ich mfd_core coretemp
> joydev kvm evdev crc32c_intel ghash_clmulni_intel aesni_intel
> aes_x86_64 aes_generic acpi_power_meter psmouse serio_raw dcdbas
> processor ablk_helper i7core_edac pcspkr cryptd edac_core microcode
> button hid_generic ext4 crc16 jbd2 mbcache dm_mod raid10 raid456
> async_raid6_recov async_memcpy async_pq async_xor xor async_tx
> raid6_pq raid1 raid0 multipath linear md_mod sr_mod usbhid cdrom hid
> ses sd_mod enclosure crc_t10dif usb_storage ata_generic pata_acpi uas
> uhci_hcd megaraid_sas ata_piix ehci_hcd libata usbcore scsi_mod
> usb_common bnx2
> [ 88.705511] CPU 2
> [ 88.705512] Pid: 3017, comm: modprobe Not tainted
> 3.6.0-rc2-00092-g9040592-dirty #6 Dell Inc. PowerEdge R610/0F0XJ6
> [ 88.705515] RIP: 0010:[<ffffffffa0006653>] [<ffffffffa0006653>]
> bnx2_start_xmit+0x20b/0x539 [bnx2]
> [ 88.705516] RSP: 0018:ffff88061e8fda28 EFLAGS: 00010002
> [ 88.705517] RAX: 0000000000000000 RBX: ffff8803200f2300 RCX: 0000000000000000
> [ 88.705519] RDX: 0000000320a95c02 RSI: 0000000000000003 RDI: ffff8800cb36f000
> [ 88.705519] RBP: ffff88031f814000 R08: 0000000000000054 R09: 0000000000000000
> [ 88.705520] R10: 000000000000ffff R11: 0000000000000000 R12: ffff8803215d52c0
> [ 88.705521] R13: ffff8803210e13c0 R14: 0000000000010008 R15: 0000000000000000
> [ 88.705522] FS: 00007fe9d0854700(0000) GS:ffff88062fc20000(0000)
> knlGS:0000000000000000
> [ 88.705523] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 88.705524] CR2: 0000000000000008 CR3: 0000000619ccb000 CR4: 00000000000007e0
> [ 88.705525] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 88.705526] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 88.705528] Process modprobe (pid: 3017, threadinfo
> ffff88061e8fc000, task ffff8806205e8000)
> [ 88.705528] Stack:
> [ 88.705530] ffff88062ffecd80 0000000320a95c02 0000000000000054
> ffffffff00000000
> [ 88.705532] 0000000000000041 ffff8803215d55f8 ffff88031f8167d8
> ffffffff00000000
> [ 88.705534] 0000000000000000 0000000100000000 ffff88062ffedb08
> ffff8803200f2300
> [ 88.705534] Call Trace:
> [ 88.705542] [<ffffffff81280a76>] ? netpoll_send_skb_on_dev+0x201/0x31d
> [ 88.705546] [<ffffffffa007fc4c>] ? bond_dev_queue_xmit+0x62/0x7f [bonding]
> [ 88.705549] [<ffffffffa0084588>] ? bond_3ad_xmit_xor+0xe7/0x10c [bonding]
> [ 88.705552] [<ffffffffa007fffd>] ? bond_start_xmit+0x394/0x3ff [bonding]
> [ 88.705554] [<ffffffff81280a76>] ? netpoll_send_skb_on_dev+0x201/0x31d
> [ 88.705558] [<ffffffffa004afd5>] ?
> vlan_dev_hard_start_xmit+0xab/0xf6 [8021q]
> [ 88.705559] [<ffffffff81280a76>] ? netpoll_send_skb_on_dev+0x201/0x31d
> [ 88.705564] [<ffffffffa00938e8>] ? __br_deliver+0x93/0xbe [bridge]
> [ 88.705567] [<ffffffffa009237d>] ? br_dev_xmit+0x14a/0x16b [bridge]
> [ 88.705569] [<ffffffff81280a76>] ? netpoll_send_skb_on_dev+0x201/0x31d
> [ 88.705570] [<ffffffff81280372>] ? find_skb.isra.23+0x31/0x78
> [ 88.705572] [<ffffffff81280bbe>] ? netpoll_send_skb+0x2c/0x39
> [ 88.705574] [<ffffffffa00a222a>] ? write_msg+0x98/0xf3 [netconsole]
> [ 88.705579] [<ffffffff81037db2>] ?
> call_console_drivers.constprop.17+0x6e/0x7d
> [ 88.705580] [<ffffffff81038248>] ? console_unlock+0x2ab/0x351
> [ 88.705582] [<ffffffff81039112>] ? register_console+0x273/0x303
> [ 88.705584] [<ffffffffa00fa182>] ? init_netconsole+0x182/0x210 [netconsole]
> [ 88.705586] [<ffffffffa00fa000>] ? 0xffffffffa00f9fff
> [ 88.705588] [<ffffffff81002085>] ? do_one_initcall+0x75/0x12c
> [ 88.705590] [<ffffffff81077b35>] ? sys_init_module+0x80/0x1c5
> [ 88.705593] [<ffffffff813319b9>] ? system_call_fastpath+0x16/0x1b
> [ 88.705606] Code: 41 c1 e1 10 48 89 d6 48 6b c8 18 48 c1 e0 04 48
> c1 ee 20 49 03 8c 24 50 03 00 00 45 09 c8 44 89 4c 24 38 c7 44 24 24
> 00 00 00 00 <48> 89 51 08 48 89 19 49 03 84 24 48 03 00 00 89 50 04 44
> 89 f2
> [ 88.705608] RIP [<ffffffffa0006653>] bnx2_start_xmit+0x20b/0x539 [bnx2]
> [ 88.705609] RSP <ffff88061e8fda28>
> [ 88.705609] CR2: 0000000000000008
> [ 88.705611] ---[ end trace 24b75fe520341c20 ]---
> [ 88.705985] note: modprobe[3017] exited with preempt_count 6
> [ 88.706135] Dead loop on virtual device mgmt, fix it urgently!
> [ 88.706201] Dead loop on virtual device mgmt, fix it urgently!
> [ 148.557967] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
> (detected by 0, t=60002 jiffies)
> [ 148.557967] INFO: Stall ended before state dump start
> [ 328.112761] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
> (detected by 2, t=240007 jiffies)
> [ 328.112761] INFO: Stall ended before state dump start
>
>
> And when trying on another machine that has Intel network cards, it
> just completely freezes the machine ... nothing even gets printed on
> the screen or anywhere I can see.
>
> Also note that this also doesn't work in 3.5.1 so it's not a new
> behavior. 3.2.x don't support netconsole over vlan at all so can't
> test on it.
>
> Cheers,
>
>
Could be the infamous slave_dev_queue_mapping striking again.
Could you please try :
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 346b1eb..df731a0 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -335,8 +335,11 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
/* don't get messages out of order, and no recursion */
if (skb_queue_len(&npinfo->txq) == 0 && !netpoll_owner_active(dev)) {
struct netdev_queue *txq;
+ int queue_index = skb_get_queue_mapping(skb);
- txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
+ if (queue_index >= dev->real_num_tx_queues)
+ queue_index = 0;
+ txq = netdev_get_tx_queue(dev, queue_index);
/* try until next clock tick */
for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
^ permalink raw reply related
* [PATCH] ipvs: Fix GSO support for IPVS DR IPv6 mode
From: Jesper Dangaard Brouer @ 2012-08-22 11:11 UTC (permalink / raw)
To: Simon Horman, Hans Schillstrom, lvs-devel, Jesper Dangaard Brouer
Cc: netdev, Julian Anastasov, Wensong Zhang, netfilter-devel
The MTU check in ip_vs_dr_xmit_v6() were missing a
check for skb_is_gso().
This e.g. caused issues for KVM IPVS setups, where different
Segmentation Offloading techniques are utilized, between guests,
via the virtio driver. This resulted in very bad performance,
due to the ICMPv6 "too big" messages didn't affect the sender.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
To Simon,
This should perhaps go to stable?
The patch is based on ipvs-next, but will apply on ipvs with an offset.
Jesper
net/netfilter/ipvs/ip_vs_xmit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 543a554..80c3006 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -1113,7 +1113,7 @@ ip_vs_dr_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
/* MTU checking */
mtu = dst_mtu(&rt->dst);
- if (skb->len > mtu) {
+ if (skb->len > mtu && !skb_is_gso(skb))) {
if (!skb->dev) {
struct net *net = dev_net(skb_dst(skb)->dev);
^ permalink raw reply related
* Re: [PATCH] net: dev: fix the incorrect hold of net namespace's lo device
From: Gao feng @ 2012-08-22 11:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: ebiederm, davem, netdev
In-Reply-To: <1345624786.5158.759.camel@edumazet-glaptop>
On Wed, 2012-08-22 at 16:39 +0800, Eric Dumazet wrote:
> On Wed, 2012-08-22 at 16:31 +0800, Gao feng wrote:
>> in dst_dev_event,we get the still referenced dst entries
>> from dst_garbage list,and call dst_ifdown to change these
>> dst entries' device to the net namesapce's lo device.
>>
>> when we moving a net device(A) to another net namespace,
>> because free_fib_info_rcu is called after a grace period,
>> we may call dst_dev_event before free_fib_info_rcu putting
>> dst_entry into the dst_garbage list.
>>
>> so in dst_dev_event, we can't see these dst entries through
>> dst_garbage list, and without changing their device to the
>> old net namespace's lo device. after a grace period, these
>> dst entries which dst->dev is device A will in the dst_garbage
>> list, and the device A will belong to the new net namespcae.
>>
>> then we exit from this new net namespace, the dst_dev_event
>> is called again,it will get these dst entries from dst_garbage
>> list,and call dst_ifdown to hold the new net namespace's lo
>> device incorrectly and put the device A.
>>
>> so it will tigger the emg message in netdev_wait_allrefs like
>> below.
>> unregister_netdevice: waiting for lo to become free. Usage count = 1
>>
>> fix this problem by adding rcu_barrier() in dst_dev_event
>> when event is NETDEV_UNREGISTER.
>> with this,dst_ifdown will be called after the dst_garbage list
>> beeing updated.
>>
>> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
>> ---
>> net/core/dst.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/core/dst.c b/net/core/dst.c
>> index 56d6361..38c2199 100644
>> --- a/net/core/dst.c
>> +++ b/net/core/dst.c
>> @@ -375,6 +375,7 @@ static int dst_dev_event(struct notifier_block *this, unsigned long event,
>>
>> switch (event) {
>> case NETDEV_UNREGISTER:
>> + rcu_barrier();
>> case NETDEV_DOWN:
>> mutex_lock(&dst_gc_mutex);
>> for (dst = dst_busy_list; dst; dst = dst->next) {
>
>
> Did you miss http://patchwork.ozlabs.org/patch/176517/ or is this patch
> an alternative ?
>
Hi Eric
I saw your patch and think this patch is clear and doesn't change too much logic.
I test your patch, it not fix this problem.
In my test case,when moving a net device to another net namespace,
Because you patch delete NETDEV_UNREGISTER event from dst_dev_event,
we will just put dst entries into the dst garbage list in event
NETDEV_DOWN,without call dst_ifdown to change these dst entries' device
to the lo device,and now this net device belongs to the new net namespace.
After the net device beeing moved to another net namespace, I rmmod this
net device's driver,this will trigger the new added event NETDEV_UNREGISTER_FINISH,
so in dst_dev_event,we will change these dst entries's device to the new net
namespace's lo device,and this will make the referenct count of the new net namespace's
lo device incorrect. when we exit the new net namespace,this emg message is still exist.
Message from syslogd@Donkey at Aug 22 18:50:13 ...
kernel:[ 1161.979036] unregister_netdevice: waiting for lo to become free. Usage count = 1
And because net_mutex is locked here,so we can't create new net namespace.
> rcu_barrier() at this place will kill some workloads.
>
I think this will only add some workloads when unregister a net device.
Do I miss something?
^ permalink raw reply
* NULL deref in bnx2 / crashes ? ( was: netconsole leads to stalled CPU task )
From: Sylvain Munaut @ 2012-08-22 10:53 UTC (permalink / raw)
To: netdev
Hi again, a bit more detail:
> I'm trying to use the netconsole to feed kernel message to the outside
> but this lead to a stall ...
>
> This only happens in a fairly specific configuration where you have a
> bridge over vlan over bonding.
> I tested with only (bridge over vlan) and (vlan over bonding) and
> those work fine.
>
> [snip ... see original mail for all details]
I was previously testing under Xen.
For this round of test, I tried the kernel natively. And I also
included Dave Miller pending series ( e0e3cea4... ) since there was
patch related to netconsole and bridging / ...
So in the end, it's a 3.6-rc2 + Dave Miller tree (commit e0e3cea4 ) +
pf malloc patch + ip pmtu patch from Eric Dumazet.
I am now seeing more debug when I load netconsole in that config:
[ 88.705138] netpoll: netconsole: local port 8888
[ 88.705140] netpoll: netconsole: local IP 10.208.1.30
[ 88.705141] netpoll: netconsole: interface 'mgmt'
[ 88.705142] netpoll: netconsole: remote port 8000
[ 88.705143] netpoll: netconsole: remote IP 10.208.1.3
[ 88.705144] netpoll: netconsole: remote ethernet address 00:16:3e:1a:37:37
[ 88.705469] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000008
[ 88.705475] IP: [<ffffffffa0006653>] bnx2_start_xmit+0x20b/0x539 [bnx2]
[ 88.705476] PGD 0
[ 88.705478] Oops: 0002 [#1] PREEMPT SMP
[ 88.705509] Modules linked in: netconsole(+) configfs nfsd
auth_rpcgss nfs_acl nfs lockd fscache sunrpc bridge 8021q garp stp llc
bonding ext2 iTCO_wdt iTCO_vendor_support lpc_ich mfd_core coretemp
joydev kvm evdev crc32c_intel ghash_clmulni_intel aesni_intel
aes_x86_64 aes_generic acpi_power_meter psmouse serio_raw dcdbas
processor ablk_helper i7core_edac pcspkr cryptd edac_core microcode
button hid_generic ext4 crc16 jbd2 mbcache dm_mod raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor xor async_tx
raid6_pq raid1 raid0 multipath linear md_mod sr_mod usbhid cdrom hid
ses sd_mod enclosure crc_t10dif usb_storage ata_generic pata_acpi uas
uhci_hcd megaraid_sas ata_piix ehci_hcd libata usbcore scsi_mod
usb_common bnx2
[ 88.705511] CPU 2
[ 88.705512] Pid: 3017, comm: modprobe Not tainted
3.6.0-rc2-00092-g9040592-dirty #6 Dell Inc. PowerEdge R610/0F0XJ6
[ 88.705515] RIP: 0010:[<ffffffffa0006653>] [<ffffffffa0006653>]
bnx2_start_xmit+0x20b/0x539 [bnx2]
[ 88.705516] RSP: 0018:ffff88061e8fda28 EFLAGS: 00010002
[ 88.705517] RAX: 0000000000000000 RBX: ffff8803200f2300 RCX: 0000000000000000
[ 88.705519] RDX: 0000000320a95c02 RSI: 0000000000000003 RDI: ffff8800cb36f000
[ 88.705519] RBP: ffff88031f814000 R08: 0000000000000054 R09: 0000000000000000
[ 88.705520] R10: 000000000000ffff R11: 0000000000000000 R12: ffff8803215d52c0
[ 88.705521] R13: ffff8803210e13c0 R14: 0000000000010008 R15: 0000000000000000
[ 88.705522] FS: 00007fe9d0854700(0000) GS:ffff88062fc20000(0000)
knlGS:0000000000000000
[ 88.705523] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 88.705524] CR2: 0000000000000008 CR3: 0000000619ccb000 CR4: 00000000000007e0
[ 88.705525] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 88.705526] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 88.705528] Process modprobe (pid: 3017, threadinfo
ffff88061e8fc000, task ffff8806205e8000)
[ 88.705528] Stack:
[ 88.705530] ffff88062ffecd80 0000000320a95c02 0000000000000054
ffffffff00000000
[ 88.705532] 0000000000000041 ffff8803215d55f8 ffff88031f8167d8
ffffffff00000000
[ 88.705534] 0000000000000000 0000000100000000 ffff88062ffedb08
ffff8803200f2300
[ 88.705534] Call Trace:
[ 88.705542] [<ffffffff81280a76>] ? netpoll_send_skb_on_dev+0x201/0x31d
[ 88.705546] [<ffffffffa007fc4c>] ? bond_dev_queue_xmit+0x62/0x7f [bonding]
[ 88.705549] [<ffffffffa0084588>] ? bond_3ad_xmit_xor+0xe7/0x10c [bonding]
[ 88.705552] [<ffffffffa007fffd>] ? bond_start_xmit+0x394/0x3ff [bonding]
[ 88.705554] [<ffffffff81280a76>] ? netpoll_send_skb_on_dev+0x201/0x31d
[ 88.705558] [<ffffffffa004afd5>] ?
vlan_dev_hard_start_xmit+0xab/0xf6 [8021q]
[ 88.705559] [<ffffffff81280a76>] ? netpoll_send_skb_on_dev+0x201/0x31d
[ 88.705564] [<ffffffffa00938e8>] ? __br_deliver+0x93/0xbe [bridge]
[ 88.705567] [<ffffffffa009237d>] ? br_dev_xmit+0x14a/0x16b [bridge]
[ 88.705569] [<ffffffff81280a76>] ? netpoll_send_skb_on_dev+0x201/0x31d
[ 88.705570] [<ffffffff81280372>] ? find_skb.isra.23+0x31/0x78
[ 88.705572] [<ffffffff81280bbe>] ? netpoll_send_skb+0x2c/0x39
[ 88.705574] [<ffffffffa00a222a>] ? write_msg+0x98/0xf3 [netconsole]
[ 88.705579] [<ffffffff81037db2>] ?
call_console_drivers.constprop.17+0x6e/0x7d
[ 88.705580] [<ffffffff81038248>] ? console_unlock+0x2ab/0x351
[ 88.705582] [<ffffffff81039112>] ? register_console+0x273/0x303
[ 88.705584] [<ffffffffa00fa182>] ? init_netconsole+0x182/0x210 [netconsole]
[ 88.705586] [<ffffffffa00fa000>] ? 0xffffffffa00f9fff
[ 88.705588] [<ffffffff81002085>] ? do_one_initcall+0x75/0x12c
[ 88.705590] [<ffffffff81077b35>] ? sys_init_module+0x80/0x1c5
[ 88.705593] [<ffffffff813319b9>] ? system_call_fastpath+0x16/0x1b
[ 88.705606] Code: 41 c1 e1 10 48 89 d6 48 6b c8 18 48 c1 e0 04 48
c1 ee 20 49 03 8c 24 50 03 00 00 45 09 c8 44 89 4c 24 38 c7 44 24 24
00 00 00 00 <48> 89 51 08 48 89 19 49 03 84 24 48 03 00 00 89 50 04 44
89 f2
[ 88.705608] RIP [<ffffffffa0006653>] bnx2_start_xmit+0x20b/0x539 [bnx2]
[ 88.705609] RSP <ffff88061e8fda28>
[ 88.705609] CR2: 0000000000000008
[ 88.705611] ---[ end trace 24b75fe520341c20 ]---
[ 88.705985] note: modprobe[3017] exited with preempt_count 6
[ 88.706135] Dead loop on virtual device mgmt, fix it urgently!
[ 88.706201] Dead loop on virtual device mgmt, fix it urgently!
[ 148.557967] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 0, t=60002 jiffies)
[ 148.557967] INFO: Stall ended before state dump start
[ 328.112761] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
(detected by 2, t=240007 jiffies)
[ 328.112761] INFO: Stall ended before state dump start
And when trying on another machine that has Intel network cards, it
just completely freezes the machine ... nothing even gets printed on
the screen or anywhere I can see.
Also note that this also doesn't work in 3.5.1 so it's not a new
behavior. 3.2.x don't support netconsole over vlan at all so can't
test on it.
Cheers,
Sylvain Munaut
^ permalink raw reply
* Re: [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag
From: Ian Campbell @ 2012-08-22 10:26 UTC (permalink / raw)
To: David Miller
Cc: mgorman@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, xen-devel@lists.xensource.com,
konrad@darnok.org, akpm@linux-foundation.org
In-Reply-To: <20120808.155046.820543563969484712.davem@davemloft.net>
On Wed, 2012-08-08 at 23:50 +0100, David Miller wrote:
> Just use something like a call to __pskb_pull_tail(skb, len) and all
> that other crap around that area can simply be deleted.
I think you mean something like this, which works for me, although I've
only lightly tested it.
Ian.
8<----------------------------------------
>From 9e47e3e87a33b45974448649a97859a479183041 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 22 Aug 2012 10:15:29 +0100
Subject: [PATCH] xen-netfront: use __pskb_pull_tail to ensure linear area is big enough on RX
I'm slightly concerned by the "only in exceptional circumstances"
comment on __pskb_pull_tail but the structure of an skb just created
by netfront shouldn't hit any of the especially slow cases.
This approach still does slightly more work than the old way, since if
we pull up the entire first frag we now have to shuffle everything
down where before we just received into the right place in the first
place.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: xen-devel@lists.xensource.com
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/xen-netfront.c | 39 ++++++++++-----------------------------
1 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3089990..650f79a 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -57,8 +57,7 @@
static const struct ethtool_ops xennet_ethtool_ops;
struct netfront_cb {
- struct page *page;
- unsigned offset;
+ int pull_to;
};
#define NETFRONT_SKB_CB(skb) ((struct netfront_cb *)((skb)->cb))
@@ -867,15 +866,9 @@ static int handle_incoming_queue(struct net_device *dev,
struct sk_buff *skb;
while ((skb = __skb_dequeue(rxq)) != NULL) {
- struct page *page = NETFRONT_SKB_CB(skb)->page;
- void *vaddr = page_address(page);
- unsigned offset = NETFRONT_SKB_CB(skb)->offset;
-
- memcpy(skb->data, vaddr + offset,
- skb_headlen(skb));
+ int pull_to = NETFRONT_SKB_CB(skb)->pull_to;
- if (page != skb_frag_page(&skb_shinfo(skb)->frags[0]))
- __free_page(page);
+ __pskb_pull_tail(skb, pull_to - skb_headlen(skb));
/* Ethernet work: Delayed to here as it peeks the header. */
skb->protocol = eth_type_trans(skb, dev);
@@ -913,7 +906,6 @@ static int xennet_poll(struct napi_struct *napi, int budget)
struct sk_buff_head errq;
struct sk_buff_head tmpq;
unsigned long flags;
- unsigned int len;
int err;
spin_lock(&np->rx_lock);
@@ -955,24 +947,13 @@ err:
}
}
- NETFRONT_SKB_CB(skb)->page =
- skb_frag_page(&skb_shinfo(skb)->frags[0]);
- NETFRONT_SKB_CB(skb)->offset = rx->offset;
-
- len = rx->status;
- if (len > RX_COPY_THRESHOLD)
- len = RX_COPY_THRESHOLD;
- skb_put(skb, len);
+ NETFRONT_SKB_CB(skb)->pull_to = rx->status;
+ if (NETFRONT_SKB_CB(skb)->pull_to > RX_COPY_THRESHOLD)
+ NETFRONT_SKB_CB(skb)->pull_to = RX_COPY_THRESHOLD;
- if (rx->status > len) {
- skb_shinfo(skb)->frags[0].page_offset =
- rx->offset + len;
- skb_frag_size_set(&skb_shinfo(skb)->frags[0], rx->status - len);
- skb->data_len = rx->status - len;
- } else {
- __skb_fill_page_desc(skb, 0, NULL, 0, 0);
- skb_shinfo(skb)->nr_frags = 0;
- }
+ skb_shinfo(skb)->frags[0].page_offset = rx->offset;
+ skb_frag_size_set(&skb_shinfo(skb)->frags[0], rx->status);
+ skb->data_len = rx->status;
i = xennet_fill_frags(np, skb, &tmpq);
@@ -999,7 +980,7 @@ err:
* receive throughout using the standard receive
* buffer size was cut by 25%(!!!).
*/
- skb->truesize += skb->data_len - (RX_COPY_THRESHOLD - len);
+ skb->truesize += skb->data_len - RX_COPY_THRESHOLD;
skb->len += skb->data_len;
if (rx->flags & XEN_NETRXF_csum_blank)
--
1.7.2.5
^ permalink raw reply related
* [PATCH (net.git) 2/2] stmmac: fix a typo in the macro used to mask the mmc irq
From: Giuseppe CAVALLARO @ 2012-08-22 10:26 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1345631176-29494-1-git-send-email-peppe.cavallaro@st.com>
This patch fixes the name of the macro used to mask the
mmc interrupt: erroneously it was used: MMC_DEFAUL_MASK.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index c07cfe9..0c74a70 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -33,7 +33,7 @@
#define MMC_TX_INTR 0x00000108 /* MMC TX Interrupt */
#define MMC_RX_INTR_MASK 0x0000010c /* MMC Interrupt Mask */
#define MMC_TX_INTR_MASK 0x00000110 /* MMC Interrupt Mask */
-#define MMC_DEFAUL_MASK 0xffffffff
+#define MMC_DEFAULT_MASK 0xffffffff
/* MMC TX counter registers */
@@ -147,8 +147,8 @@ void dwmac_mmc_ctrl(void __iomem *ioaddr, unsigned int mode)
/* To mask all all interrupts.*/
void dwmac_mmc_intr_all_mask(void __iomem *ioaddr)
{
- writel(MMC_DEFAUL_MASK, ioaddr + MMC_RX_INTR_MASK);
- writel(MMC_DEFAUL_MASK, ioaddr + MMC_TX_INTR_MASK);
+ writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_INTR_MASK);
+ writel(MMC_DEFAULT_MASK, ioaddr + MMC_TX_INTR_MASK);
}
/* This reads the MAC core counters (if actaully supported).
--
1.7.4.4
^ permalink raw reply related
* [PATCH (net.git) 1/2] stmmac: fix GMAC syn ID
From: Giuseppe CAVALLARO @ 2012-08-22 10:26 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro, Gianni Antoniazzi
Erroneously the DWMAC_CORE_3_40 was set to 34 instead of 0x34.
This can generate problems when run on old chips because
the driver assumes that there are the extra 16 regs available
for perfect filtering.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Gianni Antoniazzi <gianni.antoniazzi-ext@st.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index f90fcb5..b4c44a5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -229,6 +229,6 @@ enum rtc_control {
#define GMAC_MMC_RX_CSUM_OFFLOAD 0x208
/* Synopsys Core versions */
-#define DWMAC_CORE_3_40 34
+#define DWMAC_CORE_3_40 0x34
extern const struct stmmac_dma_ops dwmac1000_dma_ops;
--
1.7.4.4
^ permalink raw reply related
* Hello...!!
From: Dr.Amadou Kebbi @ 2012-08-22 10:24 UTC (permalink / raw)
Good day
I work with a bank In West Africa,Burkina faso,I have a business
transaction for you.In my department we discovered an abandoned sum of
$10.5 Million US Dollars.In an account that belongs to one of our
foreign customer who died along with his entire family in plane crash.
Since his supposed next of kin died along side with him, there is
nobody to claim the left over balance in the account.It is therefore
upon this discovery that I and other officials in my department
decided to seek your assistance and present you to the bank as his
Next of kin or business associate.
If you accept i would give you the guide lines of how we can achieve
this transfer of the balance (10.5 Million Dollars) to your
account.and we will share the money 50-50%.Get back to me if you are
financially capable of handling this transaction.furnish me the below
information.for more details.
Your full name….
Your age and sex…
Your country......
Your Cell phone number..
Your Occupation....
My Regards to you and your family
Dr.Amadou Kebbi
N/B? Sorry if you received this letter in your spam, Due to recent
connection error here in the con.
^ permalink raw reply
* Re: [PATCH] ipv4: properly update pmtu
From: Eric Dumazet @ 2012-08-22 10:23 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: David Miller, netdev, Julian Anastasov
In-Reply-To: <1345630873.5158.970.camel@edumazet-glaptop>
On Wed, 2012-08-22 at 12:21 +0200, Eric Dumazet wrote:
> Thans Sylvain for being an early tester of bleeding edge kernel !
Oh well, I meant to say Thanks ;)
^ permalink raw reply
* Re: [PATCH] ipv4: properly update pmtu
From: Eric Dumazet @ 2012-08-22 10:21 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: David Miller, netdev, Julian Anastasov
In-Reply-To: <CAF6-1L77Z23dCfnee3nO3-V9U_tc1jz0ptXf9YcBcARGYnOvsw@mail.gmail.com>
On Wed, 2012-08-22 at 12:16 +0200, Sylvain Munaut wrote:
> Hi,
>
> > From: Eric Dumazet <edumazet@google.com>
>
> > ip_rt_update_pmtu() calls dst_set_expires() to rearm a new expiration,
> > but dst_set_expires() does nothing because dst.expires is already set.
> >
> > It seems we want to set the expires field to a new value, regardless
> > of prior one.
> >
> > With help from Julian Anastasov.
> >
> > Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > CC: Julian Anastasov <ja@ssi.bg>
>
> Tested-by: Sylvain Munaut <s.munaut@whatever-company.com>
>
> I confirm this corrects the issue for me. I tested this on 3 machines
> with 2 different hw config that all previously exhibited the issue
> short after boot and now they've been running with this version of the
> patch for hours without problems.
>
> @Eric: Thanks for looking into this.
Thans Sylvain for being an early tester of bleeding edge kernel !
^ 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