* Re: UDP regression with packets rates < 10k per sec
From: Eric Dumazet @ 2009-09-09 17:06 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0909091234360.15538@V090114053VZO-1>
Christoph Lameter a écrit :
> On Wed, 9 Sep 2009, Eric Dumazet wrote:
>
>> Christoph Lameter a ?crit :
>>> On Wed, 9 Sep 2009, Eric Dumazet wrote:
>>>
>>>> In order to reproduce this here, could you tell me if you use
>>>>
>>>> Producer linux-2.6.22 -> Receiver 2.6.22
>>>> Producer linux-2.6.31 -> Receiver 2.6.31
>>> I use the above setup.
>> Then frames are sent on wire but not received
>>
>> (they are received via mc loop, internal stack magic)
>
> We are talking about two machines running 2.6.22 or 2.6.31. There is no
> magic mc loop between the two machines. -L was not used.
>
>> # ./mcast -L -n1 -r 10000
>> WARNING: Multiple active ethernet devices. Using local address 192.168.0.1
>> Receiver: Listening to control channel 239.0.192.1
>> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 192.168.0.1
>> Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
>>
>> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
>> 100000 0 0 0 10000 3000.0 7.84 8.89 10.51 0.66
>
> These are loopback latencies... Dont use -L
>
>> # uname -a
>> Linux erd 2.6.30.5 #2 SMP Mon Sep 7 17:15:43 CEST 2009 i686 i686 i386 GNU/Linux
>>
>>
>>
>> I tried an old kernel on same hardware :
>>
>> # ./mcast -L -n1 -r 10000
>> WARNING: Multiple active ethernet devices. Using local address 55.225.18.6
>> Receiver: Listening to control channel 239.0.192.1
>> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 55.225.18.6
>> Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
>>
>> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
>> 99999 0 0 0 9998 0.0 9.00 9.95 14.50 1.56
>>
>> Linux erd 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux
>>
>> So my numbers seem much better than yours...
>
> These are loopback numbers. Why is 2.6.9 so high? The regression show at
> less than 10k.
>
> Could you use real NICs? With multiple TX queues and all the other cool
> stuff? And run at lower packet rates?
well, on your mono-flow test, multiqueue wont help anyway.
>
> My loopback numbers also show the same trends.
>
> 2.6.22:
>
> mcast -Ln1
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 101 0 0 0 10 3.0 5.47 5.74 7.00 0.43
>
> mcast -Ln1 -r10000
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 100000 0 0 0 10000 3000.0 5.97 6.11 6.40 0.13
>
>
> 2.6.31-rc9
>
> mcast -Ln1
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 100 0 0 0 10 3.0 13.26 13.45 13.56 0.09
>
> mcast -Ln1 -r10000
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 100000 0 0 0 10000 3000.0 5.70 5.82 5.91 0.07
>
>
> So 2.6.22 is better at 10 msgs per second. 2.6.31 is slightly better at
> 10k.
Unfortunatly there is too much noise on this test
# uname -a
Linux nag001 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux
# ./mcast -Ln1 -C
WARNING: Multiple active ethernet devices. Using local address 55.225.18.110
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 55.225.18.110
Sender: Sending 10 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100 0 0 0 10 0.0 8.78 10.56 18.20 2.62
100 0 0 0 10 3.0 8.60 9.33 9.88 0.45
101 0 0 0 10 3.0 8.42 9.47 11.53 0.85
100 0 0 0 10 3.0 8.37 10.19 14.85 1.74
101 0 0 0 10 3.0 8.86 11.23 18.00 3.11
100 0 0 0 10 3.0 8.43 9.72 11.48 0.82
101 0 0 0 10 3.0 9.02 29.78 210.25 60.16
100 0 0 0 10 3.0 8.47 10.27 11.69 0.99
100 0 0 0 10 3.0 9.21 10.16 12.15 0.84
101 0 0 0 10 3.0 8.46 10.65 17.88 2.64
101 0 0 0 10 3.0 8.65 10.00 11.32 0.86
100 0 0 0 10 3.0 8.98 9.71 10.77 0.58
100 0 0 0 10 3.0 8.38 11.73 19.06 3.74
Also I believe you hit scheduler artefact at very low rate,
since there are two tasks that are considered as coupled.
Check commit 6f3d09291b4982991680b61763b2541e53e2a95f
sched, net: socket wakeups are sync
'sync' wakeups are a hint towards the scheduler that (certain)
networking related wakeups likely create coupling between tasks.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff --git a/net/core/sock.c b/net/core/sock.c
index 09cb3a7..2654c14 100644 (file)
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1621,7 +1621,7 @@ static void sock_def_readable(struct sock *sk, int len)
{
read_lock(&sk->sk_callback_lock);
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
- wake_up_interruptible(sk->sk_sleep);
+ wake_up_interruptible_sync(sk->sk_sleep);
sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
read_unlock(&sk->sk_callback_lock);
}
@@ -1635,7 +1635,7 @@ static void sock_def_write_space(struct sock *sk)
*/
if ((atomic_read(&sk->sk_wmem_alloc) << 1) <= sk->sk_sndbuf) {
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
- wake_up_interruptible(sk->sk_sleep);
+ wake_up_interruptible_sync(sk->sk_sleep);
/* Should agree with poll, otherwise some programs break */
if (sock_writeable(sk))
^ permalink raw reply related
* Re: UDP regression with packets rates < 10k per sec
From: Christoph Lameter @ 2009-09-09 16:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AA7C512.6040100@gmail.com>
On Wed, 9 Sep 2009, Eric Dumazet wrote:
> Christoph Lameter a ?crit :
> > On Wed, 9 Sep 2009, Eric Dumazet wrote:
> >
> >> In order to reproduce this here, could you tell me if you use
> >>
> >> Producer linux-2.6.22 -> Receiver 2.6.22
> >> Producer linux-2.6.31 -> Receiver 2.6.31
> >
> > I use the above setup.
>
> Then frames are sent on wire but not received
>
> (they are received via mc loop, internal stack magic)
We are talking about two machines running 2.6.22 or 2.6.31. There is no
magic mc loop between the two machines. -L was not used.
> # ./mcast -L -n1 -r 10000
> WARNING: Multiple active ethernet devices. Using local address 192.168.0.1
> Receiver: Listening to control channel 239.0.192.1
> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 192.168.0.1
> Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
>
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 100000 0 0 0 10000 3000.0 7.84 8.89 10.51 0.66
These are loopback latencies... Dont use -L
> # uname -a
> Linux erd 2.6.30.5 #2 SMP Mon Sep 7 17:15:43 CEST 2009 i686 i686 i386 GNU/Linux
>
>
>
> I tried an old kernel on same hardware :
>
> # ./mcast -L -n1 -r 10000
> WARNING: Multiple active ethernet devices. Using local address 55.225.18.6
> Receiver: Listening to control channel 239.0.192.1
> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 55.225.18.6
> Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
>
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 99999 0 0 0 9998 0.0 9.00 9.95 14.50 1.56
>
> Linux erd 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux
>
> So my numbers seem much better than yours...
These are loopback numbers. Why is 2.6.9 so high? The regression show at
less than 10k.
Could you use real NICs? With multiple TX queues and all the other cool
stuff? And run at lower packet rates?
My loopback numbers also show the same trends.
2.6.22:
mcast -Ln1
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
101 0 0 0 10 3.0 5.47 5.74 7.00 0.43
mcast -Ln1 -r10000
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100000 0 0 0 10000 3000.0 5.97 6.11 6.40 0.13
2.6.31-rc9
mcast -Ln1
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100 0 0 0 10 3.0 13.26 13.45 13.56 0.09
mcast -Ln1 -r10000
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100000 0 0 0 10000 3000.0 5.70 5.82 5.91 0.07
So 2.6.22 is better at 10 msgs per second. 2.6.31 is slightly better at
10k.
^ permalink raw reply
* Re: [IB] 2.6.31-rc9: SW2HW_EQ failed on Dell R610
From: Roland Dreier @ 2009-09-09 16:36 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0909091001450.28070@V090114053VZO-1>
> > The workaround of limiting possible cpus to 16 should be OK for the time
> > between 2.6.31 and 2.6.31.1.
> Why not merge it immediately? Dell R610s are fairly standard.
I think it's too late now post-rc9 ... it's not a regression (I think
the bug has been there since 2.6.29) and I think Linus would prefer to
minimize the # of patches that go in now.
- R.
^ permalink raw reply
* Re: net_sched 07/07: add classful multiqueue dummy scheduler
From: Patrick McHardy @ 2009-09-09 16:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jarek Poplawski, netdev
In-Reply-To: <4AA563B4.1060003@gmail.com>
Eric Dumazet wrote:
> Jarek Poplawski a écrit :
>> On Mon, Sep 07, 2009 at 03:27:37PM +0200, Patrick McHardy wrote:
>>> Jarek Poplawski wrote:
>> ...
>>>>> +static int mq_dump(struct Qdisc *sch, struct sk_buff *skb)
>>>>> +{
>>>>> + struct net_device *dev = qdisc_dev(sch);
>>>>> + struct Qdisc *qdisc;
>>>>> + unsigned int ntx;
>>>>> +
>>>>> + sch->q.qlen = 0;
>>>>> + memset(&sch->bstats, 0, sizeof(sch->bstats));
>>>>> + memset(&sch->qstats, 0, sizeof(sch->qstats));
>>>>> +
>>>>> + for (ntx = 0; ntx < dev->num_tx_queues; ntx++) {
>>>>> + qdisc = netdev_get_tx_queue(dev, ntx)->qdisc_sleeping;
>>>>> + spin_lock_bh(qdisc_lock(qdisc));
>>>>> + sch->q.qlen += qdisc->q.qlen;
>>>>> + sch->bstats.bytes += qdisc->bstats.bytes;
>>>>> + sch->bstats.packets += qdisc->bstats.packets;
>>>>> + sch->qstats.qlen += qdisc->qstats.qlen;
>>>> Like in Christoph's case, we should probably use q.qlen instead.
>>> Its done a few lines above. This simply sums up all members of qstats.
>> AFAICS these members are updated only in tc_fill_qdisc, starting from
>> the root, so they might be not up-to-date at the moment, unless I miss
>> something.
>
> Yes, we might need an q->ops->update_stats(struct Qdisc *sch) method, and
> to recursively call it from mq_update_stats()
Unless I'm missing something, that shouldn't be necessary since
sch->q.qlen contains the correct sum of all child qdiscs and
this is used by tc_fill_qdisc to update qstats.qlen.
^ permalink raw reply
* Re: net_sched 07/07: add classful multiqueue dummy scheduler
From: Patrick McHardy @ 2009-09-09 16:01 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20090907192429.GC4451@ami.dom.local>
Jarek Poplawski wrote:
> On Mon, Sep 07, 2009 at 03:27:37PM +0200, Patrick McHardy wrote:
>> Jarek Poplawski wrote:
> ...
>>>> +static int mq_dump(struct Qdisc *sch, struct sk_buff *skb)
>>>> +{
>>>> + struct net_device *dev = qdisc_dev(sch);
>>>> + struct Qdisc *qdisc;
>>>> + unsigned int ntx;
>>>> +
>>>> + sch->q.qlen = 0;
>>>> + memset(&sch->bstats, 0, sizeof(sch->bstats));
>>>> + memset(&sch->qstats, 0, sizeof(sch->qstats));
>>>> +
>>>> + for (ntx = 0; ntx < dev->num_tx_queues; ntx++) {
>>>> + qdisc = netdev_get_tx_queue(dev, ntx)->qdisc_sleeping;
>>>> + spin_lock_bh(qdisc_lock(qdisc));
>>>> + sch->q.qlen += qdisc->q.qlen;
>>>> + sch->bstats.bytes += qdisc->bstats.bytes;
>>>> + sch->bstats.packets += qdisc->bstats.packets;
>>>> + sch->qstats.qlen += qdisc->qstats.qlen;
>>> Like in Christoph's case, we should probably use q.qlen instead.
>> Its done a few lines above. This simply sums up all members of qstats.
>
> AFAICS these members are updated only in tc_fill_qdisc, starting from
> the root, so they might be not up-to-date at the moment, unless I miss
> something.
Right. Its overwritten again in tc_fill_qdisc with the proper
value contained in sch->q.qlen however, so the final value
dumped to userspace is correct. So we can simply remove the
qstats.qlen handling in mq_dump().
^ permalink raw reply
* net_sched: fix estimator lock selection for mq child qdiscs
From: Patrick McHardy @ 2009-09-09 15:59 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 4335 bytes --]
commit d0a936694984bfd8bcd56cdddbbe1f077be7f277
Author: Patrick McHardy <kaber@trash.net>
Date: Wed Sep 9 17:50:10 2009 +0200
net_sched: fix estimator lock selection for mq child qdiscs
When new child qdiscs are attached to the mq qdisc, they are actually
attached as root qdiscs to the device queues. The lock selection for
new estimators incorrectly picks the root lock of the existing and
to be replaced qdisc, which results in a use-after-free once the old
qdisc has been destroyed.
Mark mq qdisc instances with a new flag and treat qdiscs attached to
mq as children similar to regular root qdiscs.
Additionally prevent estimators from being attached to the mq qdisc
itself since it only updates its byte and packet counters during dumps.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 9c69585..88eb9de 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -46,6 +46,7 @@ struct Qdisc
#define TCQ_F_THROTTLED 2
#define TCQ_F_INGRESS 4
#define TCQ_F_CAN_BYPASS 8
+#define TCQ_F_MQROOT 16
#define TCQ_F_WARN_NONWC (1 << 16)
int padded;
struct Qdisc_ops *ops;
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index de1ebc4..692d9a4 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -733,7 +733,8 @@ static struct lock_class_key qdisc_rx_lock;
static struct Qdisc *
qdisc_create(struct net_device *dev, struct netdev_queue *dev_queue,
- u32 parent, u32 handle, struct nlattr **tca, int *errp)
+ struct Qdisc *p, u32 parent, u32 handle,
+ struct nlattr **tca, int *errp)
{
int err;
struct nlattr *kind = tca[TCA_KIND];
@@ -810,24 +811,21 @@ qdisc_create(struct net_device *dev, struct netdev_queue *dev_queue,
if (tca[TCA_RATE]) {
spinlock_t *root_lock;
+ err = -EOPNOTSUPP;
+ if (sch->flags & TCQ_F_MQROOT)
+ goto err_out4;
+
if ((sch->parent != TC_H_ROOT) &&
- !(sch->flags & TCQ_F_INGRESS))
+ !(sch->flags & TCQ_F_INGRESS) &&
+ (!p || !(p->flags & TCQ_F_MQROOT)))
root_lock = qdisc_root_sleeping_lock(sch);
else
root_lock = qdisc_lock(sch);
err = gen_new_estimator(&sch->bstats, &sch->rate_est,
root_lock, tca[TCA_RATE]);
- if (err) {
- /*
- * Any broken qdiscs that would require
- * a ops->reset() here? The qdisc was never
- * in action so it shouldn't be necessary.
- */
- if (ops->destroy)
- ops->destroy(sch);
- goto err_out3;
- }
+ if (err)
+ goto err_out4;
}
qdisc_list_add(sch);
@@ -843,6 +841,15 @@ err_out2:
err_out:
*errp = err;
return NULL;
+
+err_out4:
+ /*
+ * Any broken qdiscs that would require a ops->reset() here?
+ * The qdisc was never in action so it shouldn't be necessary.
+ */
+ if (ops->destroy)
+ ops->destroy(sch);
+ goto err_out3;
}
static int qdisc_change(struct Qdisc *sch, struct nlattr **tca)
@@ -867,13 +874,16 @@ static int qdisc_change(struct Qdisc *sch, struct nlattr **tca)
qdisc_put_stab(sch->stab);
sch->stab = stab;
- if (tca[TCA_RATE])
+ if (tca[TCA_RATE]) {
/* NB: ignores errors from replace_estimator
because change can't be undone. */
+ if (sch->flags & TCQ_F_MQROOT)
+ goto out;
gen_replace_estimator(&sch->bstats, &sch->rate_est,
qdisc_root_sleeping_lock(sch),
tca[TCA_RATE]);
-
+ }
+out:
return 0;
}
@@ -1097,7 +1107,7 @@ create_n_graft:
if (!(n->nlmsg_flags&NLM_F_CREATE))
return -ENOENT;
if (clid == TC_H_INGRESS)
- q = qdisc_create(dev, &dev->rx_queue,
+ q = qdisc_create(dev, &dev->rx_queue, p,
tcm->tcm_parent, tcm->tcm_parent,
tca, &err);
else {
@@ -1106,7 +1116,7 @@ create_n_graft:
if (p && p->ops->cl_ops && p->ops->cl_ops->select_queue)
ntx = p->ops->cl_ops->select_queue(p, tcm);
- q = qdisc_create(dev, netdev_get_tx_queue(dev, ntx),
+ q = qdisc_create(dev, netdev_get_tx_queue(dev, ntx), p,
tcm->tcm_parent, tcm->tcm_handle,
tca, &err);
}
diff --git a/net/sched/sch_mq.c b/net/sched/sch_mq.c
index c84dec9..dd5ee02 100644
--- a/net/sched/sch_mq.c
+++ b/net/sched/sch_mq.c
@@ -64,6 +64,7 @@ static int mq_init(struct Qdisc *sch, struct nlattr *opt)
priv->qdiscs[ntx] = qdisc;
}
+ sch->flags |= TCQ_F_MQROOT;
return 0;
err:
^ permalink raw reply related
* Re: [PATCH] slub: fix slab_pad_check()
From: Paul E. McKenney @ 2009-09-09 15:09 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, dhowells, lethal, kernel,
mpm
In-Reply-To: <alpine.DEB.1.10.0909091052380.28070@V090114053VZO-1>
On Wed, Sep 09, 2009 at 10:53:22AM -0400, Christoph Lameter wrote:
> On Wed, 9 Sep 2009, Paul E. McKenney wrote:
>
> > If the embedded guys are OK with an additional pointer in the slab data
> > structure, I have no objection to this approach. I am assuming that we
> > would use the usual ops-style structure full of pointers to functions
> > in order to avoid a pair of extra pointers.
>
> This would also allow us to get rid of the ctor pointer in
> kmem_cache_create(). We can put it into the same structure.
Sounds good -- that would result in no increase in size. Could even
add a dtor if people want it. ;-) (Sorry, couldn't resist...)
Thanx, Paul
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Eric Dumazet @ 2009-09-09 15:09 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0909091000200.28070@V090114053VZO-1>
Christoph Lameter a écrit :
> On Wed, 9 Sep 2009, Eric Dumazet wrote:
>
>> In order to reproduce this here, could you tell me if you use
>>
>> Producer linux-2.6.22 -> Receiver 2.6.22
>> Producer linux-2.6.31 -> Receiver 2.6.31
>
> I use the above setup.
Then frames are sent on wire but not received
(they are received via mc loop, internal stack magic)
# ./mcast -L -n1 -r 10000
WARNING: Multiple active ethernet devices. Using local address 192.168.0.1
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 192.168.0.1
Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100000 0 0 0 10000 3000.0 7.84 8.89 10.51 0.66
# uname -a
Linux erd 2.6.30.5 #2 SMP Mon Sep 7 17:15:43 CEST 2009 i686 i686 i386 GNU/Linux
I tried an old kernel on same hardware :
# ./mcast -L -n1 -r 10000
WARNING: Multiple active ethernet devices. Using local address 55.225.18.6
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 55.225.18.6
Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
99999 0 0 0 9998 0.0 9.00 9.95 14.50 1.56
Linux erd 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux
So my numbers seem much better than yours...
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Christoph Lameter @ 2009-09-09 14:53 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, dhowells, lethal, kernel,
mpm
In-Reply-To: <20090909144238.GA6749@linux.vnet.ibm.com>
On Wed, 9 Sep 2009, Paul E. McKenney wrote:
> If the embedded guys are OK with an additional pointer in the slab data
> structure, I have no objection to this approach. I am assuming that we
> would use the usual ops-style structure full of pointers to functions
> in order to avoid a pair of extra pointers.
This would also allow us to get rid of the ctor pointer in
kmem_cache_create(). We can put it into the same structure.
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Paul E. McKenney @ 2009-09-09 14:42 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, dhowells, lethal, kernel,
mpm
In-Reply-To: <alpine.DEB.1.10.0909091002440.28070@V090114053VZO-1>
On Wed, Sep 09, 2009 at 10:04:20AM -0400, Christoph Lameter wrote:
> On Tue, 8 Sep 2009, Paul E. McKenney wrote:
>
> > > No direct request but I have seen the network developers discover these
> > > features and their caching benefits over the last year. It is likely that
> > > they will try to push it into more components of the net subsystem.
> >
> > So if they push it far enough, they might well decide that they need
> > a SLAB_DESTROY_BY_RCU_BH, for example. Looks like seven bits left,
> > so unless I am missing something, should not be a huge problem should
> > this need arise.
>
> I'd rather have the call_rcu in the slabs replaced by a function that
> can be set by the user. Then we can remove all rcu barriers from the code
> and the slabs could be used with any type of rcu functionality.
If the embedded guys are OK with an additional pointer in the slab data
structure, I have no objection to this approach. I am assuming that we
would use the usual ops-style structure full of pointers to functions
in order to avoid a pair of extra pointers.
Thanx, Paul
^ permalink raw reply
* LOAN AAPLICATION !!!
From: SOLUTION TEAM @ 2009-09-09 14:18 UTC (permalink / raw)
Dear Sir/Madam
We Offer Private loan, Commercial and Personal Loans with very Minimal annual
Interest Rates as Low as 3% within a 1year to 50 years repayment duration
period to any part of the world.
We give out loans within the range of $10,000 to $1,000,000.00 USD.Our loans
are well insured for maximum security is our priority.Interested applicants
should Contact us with the information below via email: jmcloandept@ymail.com
Secretary Name: Mr.Lewis Hogan.
Secretary Email:solutionteam11@ymail.com
BORROWERS INFORMATION:
Names:
Country:
Address:
Age:
Phone Number:
Occupation:
Sex:
Amount Needed:
Loan duration:
Brief description of individual
Warmest Regards,
Secretary, Mr.Lewis Hogan.
Telephone:+4470457 10485
Fax Number:+447 005 963 154
^ permalink raw reply
* Re: [PATCH 1/1] netpoll: fix race between skb_queue_len and skb_dequeue
From: DDD @ 2009-09-09 14:27 UTC (permalink / raw)
To: Matt Mackall; +Cc: David Miller, netdev
In-Reply-To: <1252430825.7145.55.camel@calx>
On Tue, 2009-09-08 at 12:27 -0500, Matt Mackall wrote:
> On Tue, 2009-09-08 at 15:49 +0800, DDD wrote:
> > This race will break the messages order.
> >
> > Sequence of events in the problem case:
> >
> > Assume there is one skb "A" in skb_queue and the next action of
> > netpoll_send_skb() is: sending out "B" skb.
> > The right order of messages should be: send A first, then send B.
> >
> > But as following orders, it will send B first, then send A.
>
> I would say no, the order of messages A and B queued on different CPUs
> is undefined. The only issue is that we can queue a message A on CPU0,
> then causally trigger a message on CPU1 B that arrives first. But bear
> in mind that the message A >>may never arrive<< because the message is
> about a lockup that kills processing of delayed work.
>
> Generally speaking, queueing should be a last ditch effort. We should
> instead aim to deliver all messages immediately, even if they might be
> out of order. Because out of order is better than not arriving at all.
Ah, yes, out of order is better than not arriving at all. :-)
Especially it is based on UDP, so I don't think the order of messages is
important. :-)
I take back this patch.
Thank you very much,
Dongdong
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Christoph Lameter @ 2009-09-09 14:04 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <20090908225937.GO6753@linux.vnet.ibm.com>
On Tue, 8 Sep 2009, Paul E. McKenney wrote:
> > No direct request but I have seen the network developers discover these
> > features and their caching benefits over the last year. It is likely that
> > they will try to push it into more components of the net subsystem.
>
> So if they push it far enough, they might well decide that they need
> a SLAB_DESTROY_BY_RCU_BH, for example. Looks like seven bits left,
> so unless I am missing something, should not be a huge problem should
> this need arise.
I'd rather have the call_rcu in the slabs replaced by a function that
can be set by the user. Then we can remove all rcu barriers from the code
and the slabs could be used with any type of rcu functionality.
^ permalink raw reply
* Re: [IB] 2.6.31-rc9: SW2HW_EQ failed on Dell R610
From: Christoph Lameter @ 2009-09-09 14:02 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev
In-Reply-To: <ada1vmgn76v.fsf@cisco.com>
On Tue, 8 Sep 2009, Roland Dreier wrote:
> The workaround of limiting possible cpus to 16 should be OK for the time
> between 2.6.31 and 2.6.31.1.
Why not merge it immediately? Dell R610s are fairly standard.
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Christoph Lameter @ 2009-09-09 14:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AA6E039.4000907@gmail.com>
On Wed, 9 Sep 2009, Eric Dumazet wrote:
> In order to reproduce this here, could you tell me if you use
>
> Producer linux-2.6.22 -> Receiver 2.6.22
> Producer linux-2.6.31 -> Receiver 2.6.31
I use the above setup.
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: Xiaofei Wu @ 2009-09-09 13:12 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1252376168.5244.11.camel@dogo.mojatatu.com>
I did an experiment. It seems that something is wrong.
>> (1) Could I use pedit action to modify the dst MAC, so the destination node D will accept it,
>> then forward it to node C?
>Yes, you can achieve it with pedit;
>it is as usable as u32 is - you have to know your offsets
>example, here's something done on an incoming packet:
=-=
#Note:
#dst MAC starts at -14
#src MAC at -8
#ethertype at -2
#
>
>
A
/ \
B D
\ /
C
A: eth0, IP 192.168.1.242
waln1, IP 192.168.2.200 ,MAC 00 23 cd af d0 74
D: wlan1, IP 192.168.2.11, MAC 00 23 cd af ec da
wlan2, IP 192.168.4.11
On node A,
1) run 'tc qdisc add dev eth0 handle 1: root prio'
2) run 'tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \
match ip src 192.168.1.0/24 flowid 1:16 \
action mirred egress mirror dev wlan1'
Node A sent some packets to C. (path: A-B-C)
I can use 'tcpdump -i wlan1 -e' to capture the packets from eth0 (node A), but I can't forward the mirroring packets to D, (then D forwards them to C).
3 ) run 'tc filter del dev eth0 parent 1: protocol ip prio 10 u32'
then,
'tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \
match ip src 192.168.1.0/32 flowid 1:16 \
action pedit munge offset -14 u16 set 0x0023 \
munge offset -12 u32 set 0xcdafecda \
munge offset -8 u32 set 0x0023cdaf \
munge offset -4 u32 set 0xd0740800 pipe \
action mirred egress mirror dev wlan1'
After run 'tcpdump -i wlan1 -e', I can not capture any packets.
I change 'mirror' to 'redirect' ('action mirred egress mirror dev wlan1'), also capture nothing.
Why?
BTW,
'uname -a'
Linux fedora 2.6.27.30-170.2.82.fc10.i686 #1 SMP Mon Aug 17 08:38:59 EDT 2009
i686 i686 i386 GNU/Linux
iproute2:
iproute-2.6.27-2.fc10.i386
regards,
wu
^ permalink raw reply
* Re: Next Sept 7: Bug : skb_release_head_state on x86
From: Eric Dumazet @ 2009-09-09 12:10 UTC (permalink / raw)
To: Sachin Sant; +Cc: netdev, Stephen Rothwell, linux-next, David Miller
In-Reply-To: <4AA78DD4.60003@in.ibm.com>
Sachin Sant a écrit :
> Sachin Sant wrote:
>> Will try to boot 0904 and will check if the same problem can be
>> recreated.
> I still have this problem with next-20090908.Although the trace
> looks a bit different.
>
> Haven't checked today's next.
>
> BUG: unable to handle kernel paging request at 00008c90
> IP: [<c0349399>] skb_dma_unmap+0x15/0x91
> *pdpt = 0000000035445001 *pde = 0000000000000000
> Oops: 0000 [#2] SMP
> last sysfs file: /sys/devices/system/cpu/cpu3/topology/core_siblings
> Modules linked in: ipv6 microcode fuse loop dm_mod i2c_piix4 tg3
> i2c_core pcspkr ppdev button libphy sworks_agp rtc_cmos rtc_core
> parport_pc sr_mod rtc_lib sg parport agpgart cdrom floppy ohci_hcd
> ehci_hcd sd_mod crc_t10dif usbcore edd fan ide_pci_generic serverworks
> ide_core ata_generic pata_serverworks libata ips scsi_mod thermal
> processor thermal_sys hwmon [last unloaded: speedstep_lib]
>
> Pid: 6, comm: ksoftirqd/1 Tainted: G D
> (2.6.31-rc9-autotest-next-20090908-5-pae #1) eserver xSeries 235
> -[86717AX]-
> EIP: 0060:[<c0349399>] EFLAGS: 00010296 CPU: 1
> EIP is at skb_dma_unmap+0x15/0x91
> EAX: f5d3dc5c EBX: c056bba0 ECX: 00000001 EDX: 00008be8
> ESI: f4d3b2f0 EDI: 00008be8 EBP: f5c69ec4 ESP: f5c69eac
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> Process ksoftirqd/1 (pid: 6, ti=f5c68000 task=f5c4f280 task.ti=f5c68000)
> Stack:
> 00000001 f5d3dc5c f5c69ec4 0000005f f4d3b2f0 00008be8 f5c69f3c f8d191a1
> <0> c148347c 00000040 f4900380 f4900340 00000000 f55b2000 f4900340 00000064
> <0> f553aa00 00000000 f4900340 00000000 f49006b8 d0622200 0000059a f4d377c0
> Call Trace:
> [<f8d191a1>] ? tg3_poll+0x10f/0x802 [tg3]
> [<c034c151>] ? net_rx_action+0x93/0x173
> [<c01376b8>] ? __do_softirq+0xa7/0x144
> [<c013777b>] ? do_softirq+0x26/0x2b
> [<c01377ca>] ? ksoftirqd+0x4a/0xae
> [<c0137780>] ? ksoftirqd+0x0/0xae
> [<c0146a56>] ? kthread+0x61/0x66
> [<c01469f5>] ? kthread+0x0/0x66
> [<c0103507>] ? kernel_thread_helper+0x7/0x10
> Code: 5a c0 74 07 89 d8 e8 f3 7b e6 ff ba f4 ff ff ff 89 d0 5b 5e 5d c3
> 55 89 e5 57 56 53 83 ec 0c 8b 1d c0 07 61 c0 89 4d e8 89 45 ec <8b> ba
> a8 00 00 00 83 7d e8 02 8b 42 50 8b 72 54 8b 4f 0c 8b 57
> EIP: [<c0349399>] skb_dma_unmap+0x15/0x91 SS:ESP 0068:f5c69eac
> CR2: 0000000000008c90
> ---[ end trace 9239788a6557ba57 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> Pid: 6, comm: ksoftirqd/1 Tainted: G D
> 2.6.31-rc9-autotest-next-20090908-5-pae #1
>
> I went back and tried out some old next versions. Seems like
> the problem was introduced in next-20090903. next-20090902
> worked fine.
>
> Thanks
> -Sachin
>
There were some changes on net-next-2.6 for tg3, you could try to revert them...
(They are working just fine on my machine, but I suspect you have a different chip)
# lspci | grep Ether
14:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5715S Gigabit Ethernet (rev a3)
14:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5715S Gigabit Ethernet (rev a3)
commit 7ab0f2736bfe137a82a7084bbfb5f809da95cabd
Author: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu Sep 3 10:39:43 2009 +0000
netdev: Remove redundant checks for CAP_NET_ADMIN in MDIO implementations
dev_ioctl() already checks capable(CAP_NET_ADMIN) before calling the
driver's implementation of MDIO ioctls.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit daf09de817353f18bb81a23a023d429cfd258e62
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:22:42 2009 +0000
tg3: Update version to 3.102
This patch updates the tg3 version to 3.102.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 882e9793faa9425dff581c33b1af45ed10145626
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:21:36 2009 +0000
tg3: Add MDIO bus address assignments
The 5717 is a dual port chip that has a shared MDIO bus design. While
it is impossible for one function to interface with the wrong phy, that
function still needs to know which MDIO bus address to use when
interfacing with its own phy. This patch adds code to determine which
MDIO bus address to use.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit a1b950d56de3c72bea3343f54de24c43fb7dc74e
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:20:17 2009 +0000
tg3: Add 5717 NVRAM detection routines
This patch adds NVRAM detection routines for the 5717.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f6eb9b1fc1411d22c073f5264e5630a541d0f7df
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:19:53 2009 +0000
tg3: Add 5717 asic rev
This patch adds the 5717 asic rev.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 8d9d7cfc0ec2fe37ff9afd74326d03f38f96ad1b
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:19:05 2009 +0000
tg3: Assign rx ret producer indexes by vector
When RSS is enabled, the status block format changes slightly. The
"rx_jumbo_consumer", "reserved", and "rx_mini_consumer" members get
mapped to the other three rx return ring producer indexes. This patch
introduces a new per-interrupt member which identifies which location
in the status block a particular vector should look for return ring
updates.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 0c1d0e2b05e92ad847b3ebe1c75b7974086bc8fa
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:16:33 2009 +0000
tg3: Adjust RSS ring allocation strategies
When multivector RSS is enabled, the first interrupt vector is only used
to report link interrupts and error conditions. This patch changes the
code so that rx and tx ring resources are not allocated for this vector.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit baf8a94a572928710e9e60967d153a7bf3aebd9c
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:13:00 2009 +0000
tg3: Add RSS support
This patch adds code needed to enable RSS.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit b6080e126012047d42e53154189fdca286d0600e
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:12:00 2009 +0000
tg3: Add coalesce parameters for msix vectors
This patch adds code to tune the coalescing parameters for the other
msix vectors.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit fed9781081aa9600765346c108ff22751e003715
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:10:19 2009 +0000
tg3: Enable NAPI instances for other int vectors
This patch adds code to enable and disable the rest of the NAPI
instances.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit fe5f5787f0866e9f883bdd90018a354f2f3defd1
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:09:39 2009 +0000
tg3: Add TSS support
This patch exposes the additional transmit rings to the kernel and makes
the necessary modifications to transmit, open, and close paths.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 89aeb3bceaa1a02651206a76a7b9dcb8f3884702
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:08:58 2009 +0000
tg3: Update intmbox and coal_now for msix
This patch fixes up two spots that need attention now that msix support
has been added.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f77a6a8e6cee17b21a43bdf6b853cc2fc0e2c4df
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 13:04:37 2009 +0000
tg3: Add tx and rx ring resource tracking
This patch adds code to assign status block, tx producer ring and rx
return ring resources needed for the other interrupt vectors.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 646c9eddcffd202bb0f3d906cecf94eaf10cad31
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 12:58:41 2009 +0000
tg3: Add mailbox assignments
The 5717 assigns mailbox locations to interrupt vectors in a rather
non-intuitive way. (Much of the complexity stems from legacy
compatibility issues.) This patch implements the assignment scheme.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 679563f47cd2547a0e091b5bd3ddf30027af6b08
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 12:55:46 2009 +0000
tg3: Add MSI-X support
This patch adds MSI-X support.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 4f125f42dd55390016e21f8b3960f99d02d1001f
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 12:55:02 2009 +0000
tg3: Add support code around kernel interrupt API
This patch adds code to support multiple interrupt vectors around the
kernel's interrupt API.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 2d31ecaf10c4ae03d49aed516481b2839b0220f6
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 12:53:31 2009 +0000
tg3: Create tg3_rings_reset()
This patch moves most of the chip ring setup logic into a separate
function. This will make it easier to verify the multi ring setup
changes.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit fd2ce37f8e4a570ce90b141a2e7c476c5b399836
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 12:51:13 2009 +0000
tg3: Add per-int coalesce now member
Each interrupt vector has its own bit in the host coalescing register to
force that vector's status block to be updated and generate an
interrupt. This patch adds a member to the per-interrupt structure
that records which bit belongs to that vector.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f19af9c2cc015e42dfe4bd5c383e32066ec2801c
Author: Matt Carlson <mcarlson@broadcom.com>
Date: Tue Sep 1 12:47:49 2009 +0000
tg3: inline tg3_cond_int()
This patch inlines the code of tg3_cond_int() into the function's only
callsite. This prep work makes the following patch cleaner.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: Next Sept 7: Bug : skb_release_head_state on x86
From: Sachin Sant @ 2009-09-09 11:13 UTC (permalink / raw)
To: Sachin Sant
Cc: Eric Dumazet, netdev, Stephen Rothwell, linux-next, David Miller
In-Reply-To: <4AA5E717.1050002@in.ibm.com>
Sachin Sant wrote:
> Will try to boot 0904 and will check if the same problem can be
> recreated.
I still have this problem with next-20090908.Although the trace
looks a bit different.
Haven't checked today's next.
BUG: unable to handle kernel paging request at 00008c90
IP: [<c0349399>] skb_dma_unmap+0x15/0x91
*pdpt = 0000000035445001 *pde = 0000000000000000
Oops: 0000 [#2] SMP
last sysfs file: /sys/devices/system/cpu/cpu3/topology/core_siblings
Modules linked in: ipv6 microcode fuse loop dm_mod i2c_piix4 tg3 i2c_core pcspkr ppdev button libphy sworks_agp rtc_cmos rtc_core parport_pc sr_mod rtc_lib sg parport agpgart cdrom floppy ohci_hcd ehci_hcd sd_mod crc_t10dif usbcore edd fan ide_pci_generic serverworks ide_core ata_generic pata_serverworks libata ips scsi_mod thermal processor thermal_sys hwmon [last unloaded: speedstep_lib]
Pid: 6, comm: ksoftirqd/1 Tainted: G D (2.6.31-rc9-autotest-next-20090908-5-pae #1) eserver xSeries 235 -[86717AX]-
EIP: 0060:[<c0349399>] EFLAGS: 00010296 CPU: 1
EIP is at skb_dma_unmap+0x15/0x91
EAX: f5d3dc5c EBX: c056bba0 ECX: 00000001 EDX: 00008be8
ESI: f4d3b2f0 EDI: 00008be8 EBP: f5c69ec4 ESP: f5c69eac
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process ksoftirqd/1 (pid: 6, ti=f5c68000 task=f5c4f280 task.ti=f5c68000)
Stack:
00000001 f5d3dc5c f5c69ec4 0000005f f4d3b2f0 00008be8 f5c69f3c f8d191a1
<0> c148347c 00000040 f4900380 f4900340 00000000 f55b2000 f4900340 00000064
<0> f553aa00 00000000 f4900340 00000000 f49006b8 d0622200 0000059a f4d377c0
Call Trace:
[<f8d191a1>] ? tg3_poll+0x10f/0x802 [tg3]
[<c034c151>] ? net_rx_action+0x93/0x173
[<c01376b8>] ? __do_softirq+0xa7/0x144
[<c013777b>] ? do_softirq+0x26/0x2b
[<c01377ca>] ? ksoftirqd+0x4a/0xae
[<c0137780>] ? ksoftirqd+0x0/0xae
[<c0146a56>] ? kthread+0x61/0x66
[<c01469f5>] ? kthread+0x0/0x66
[<c0103507>] ? kernel_thread_helper+0x7/0x10
Code: 5a c0 74 07 89 d8 e8 f3 7b e6 ff ba f4 ff ff ff 89 d0 5b 5e 5d c3 55 89 e5 57 56 53 83 ec 0c 8b 1d c0 07 61 c0 89 4d e8 89 45 ec <8b> ba a8 00 00 00 83 7d e8 02 8b 42 50 8b 72 54 8b 4f 0c 8b 57
EIP: [<c0349399>] skb_dma_unmap+0x15/0x91 SS:ESP 0068:f5c69eac
CR2: 0000000000008c90
---[ end trace 9239788a6557ba57 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 6, comm: ksoftirqd/1 Tainted: G D 2.6.31-rc9-autotest-next-20090908-5-pae #1
I went back and tried out some old next versions. Seems like
the problem was introduced in next-20090903. next-20090902
worked fine.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH] dm9000: Use resource_size instead of private macro
From: Tobias Klauser @ 2009-09-09 11:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Tobias Klauser
The macro res_size in drivers/net/dm9000.c is a copy of resource_size in
linux/ioport.h. Remove the function and use resource_size instead.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/dm9000.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index dd771de..00a9db8 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -1185,8 +1185,6 @@ static const struct net_device_ops dm9000_netdev_ops = {
#endif
};
-#define res_size(_r) (((_r)->end - (_r)->start) + 1)
-
/*
* Search DM9000 board, allocate space and register it
*/
@@ -1236,7 +1234,7 @@ dm9000_probe(struct platform_device *pdev)
goto out;
}
- iosize = res_size(db->addr_res);
+ iosize = resource_size(db->addr_res);
db->addr_req = request_mem_region(db->addr_res->start, iosize,
pdev->name);
@@ -1254,7 +1252,7 @@ dm9000_probe(struct platform_device *pdev)
goto out;
}
- iosize = res_size(db->data_res);
+ iosize = resource_size(db->data_res);
db->data_req = request_mem_region(db->data_res->start, iosize,
pdev->name);
--
1.6.0.4
^ permalink raw reply related
* [PATCH] dm9000: Remove unnecessary memset of netdev private data
From: Tobias Klauser @ 2009-09-09 11:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Tobias Klauser
In-Reply-To: <1252494464-4633-1-git-send-email-tklauser@distanz.ch>
The memory for the private data is allocated using kzalloc in
alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
set it to 0 again.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/dm9000.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 00a9db8..11995ad 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -1213,7 +1213,6 @@ dm9000_probe(struct platform_device *pdev)
/* setup board info structure */
db = netdev_priv(ndev);
- memset(db, 0, sizeof(*db));
db->dev = &pdev->dev;
db->ndev = ndev;
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] headers: net/ipv[46]/protocol.c header trim
From: David Miller @ 2009-09-09 10:43 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20090907123825.GB29858@x200.localdomain>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon, 7 Sep 2009 16:38:25 +0400
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] IPv6/addrconf: Fix minor addrlabel thinko
From: David Miller @ 2009-09-09 10:42 UTC (permalink / raw)
To: tgohad; +Cc: yoshfuji, netdev
In-Reply-To: <4AA5F3D3.80706@mvista.com>
From: Tushar Gohad <tgohad@mvista.com>
Date: Mon, 07 Sep 2009 23:04:03 -0700
>
> Fix apparent thinko related to RTM_DELADDRLABEL, introduced by commit 2a8cc6c89039e0530a3335954253b76ed0f9339a.
>
>
> Signed-off-by: Tushar Gohad <tgohad@mvista.com>
Looks good to me, applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH resend] s2io: Remove unnecessary casts
From: David Miller @ 2009-09-09 10:40 UTC (permalink / raw)
To: dave; +Cc: netdev, kernel-janitors
In-Reply-To: <1252384015.6396.11.camel@dbueso-pc>
From: Davidlohr Bueso <dave@gnu.org>
Date: Tue, 08 Sep 2009 00:26:55 -0400
> Hi David,
>
> Don't know why my email client corrupted the patch, anyways, here it is without white spaces.
>
> No need to cast kmalloc.
>
> Thanks,
> Davidlohr
>
>
> Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Since you last submitted this patch a large series of cleanup
patches were added to this driver in the net-next-2.6 tree
and as a result your patch no longer applies properly.
You'll need to respin these changes and make sure they
apply cleanly to net-next-2.6
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] cdc-phonet: autoconfigure Phonet address
From: Marcel Holtmann @ 2009-09-09 10:33 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev
In-Reply-To: <1f7692749ea7722ba7f7f4ff9f86acd2@chewa.net>
Hi Remi,
> > am I understanding this correctly, that even for the USB ones we still
> > have to execute that ioctl() and can not just auto configure them all
> > the time? For the USB ones, I would expect to should plug them in and
> > they are getting configured right away.
>
> The other patch makes the stack use the ioctl() internally.
> But now I see that I forgot some debug statement :(
>
> Still, something needs to ifconfig up/ip link set up.
the ifup/ifdown is fine. And if the addresses get set when I plug the
device in, that looks good to me.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/2] cdc-phonet: autoconfigure Phonet address
From: Rémi Denis-Courmont @ 2009-09-09 10:28 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: netdev
In-Reply-To: <1252491850.8931.28.camel@violet>
On Wed, 09 Sep 2009 12:24:10 +0200, Marcel Holtmann <marcel@holtmann.org>
wrote:
> am I understanding this correctly, that even for the USB ones we still
> have to execute that ioctl() and can not just auto configure them all
> the time? For the USB ones, I would expect to should plug them in and
> they are getting configured right away.
The other patch makes the stack use the ioctl() internally.
But now I see that I forgot some debug statement :(
Still, something needs to ifconfig up/ip link set up.
--
Rémi Denis-Courmont
^ 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