* 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: 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: 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
* 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: 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
* 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: [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: 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: 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: Eric Dumazet @ 2009-09-09 17:08 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.
>
I have no idea how you run the test then, and how are computed time deltas.
Are you clocks synchronized to less than one us ? How is it done ?
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Christoph Lameter @ 2009-09-09 17:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AA7E0FA.5070005@gmail.com>
On Wed, 9 Sep 2009, Eric Dumazet wrote:
> I have no idea how you run the test then, and how are computed time deltas.
>
> Are you clocks synchronized to less than one us ? How is it done ?
Packets are sent one way and include a timestamp. Once in a while (probe
interval) a packet is sent back to the sender (with the timestamp the
sender took earlier). The sender takes a second timestamp and
calculates the latency by dividing by two.
Seen this approach in multiple middleware test programs. Clocks are
typically not synchronized enough to actually compare timestamps from two
systems.
^ permalink raw reply
* Re: [PATCH] ath5k: do not free irq after resume when card has been removed
From: Thadeu Lima de Souza Cascardo @ 2009-09-09 17:50 UTC (permalink / raw)
To: Bob Copeland
Cc: ath5k-devel, linux-wireless, netdev, linux-kernel, lrodriguez,
mickflemm, jirislaby, linville, johannes
In-Reply-To: <20090909033237.GC13550@hash.localnet>
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
On Tue, Sep 08, 2009 at 11:32:37PM -0400, Bob Copeland wrote:
> On Tue, Sep 08, 2009 at 09:52:31PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > ath5k will try to request irq when resuming and fails if the device
> > (like a PCMCIA card) has been removed.
>
> That's not true, ath5k no longer requests an irq when resuming.
>
I've just saw there's a commit by you in the next tree that just removes
the irq requesting and releasing in resume/suspend functions.
> > This solves this issue defining a new flag for the status bitmap to
> > indicate when irq has been successfully requested and does not try to
> > release it if not.
>
> I'd rather not fix it with a status bit. What kernel is this against?
>
This is against v2.6.31-rc9, so I get a warning with a version that's
about to get stable. Sorry I am late in the release cycle.
I've used a status bit because the drivers I took a look at did
release/request irq in suspend/resume. I couldn't find a message about
not doing it was the right thing which I thought I saw in the latest
updates to v2.6.31-rcX. I guess it was something just like your commit
which I did see some weeks ago.
Since this is warning, is this worth backporting to rc?
> --
> Bob Copeland %% www.bobcopeland.com
>
Regards,
Cascardo.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Christoph Lameter @ 2009-09-09 17:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AA7E082.90807@gmail.com>
On Wed, 9 Sep 2009, Eric Dumazet wrote:
> > 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
> >
> > 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
> >
> >
> > So 2.6.22 is better at 10 msgs per second. 2.6.31 is slightly better at
> > 10k.
>
> Linux nag001 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux
>
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 101 0 0 0 10 3.0 8.42 9.47 11.53 0.85
>
> Also I believe you hit scheduler artefact at very low rate,
> since there are two tasks that are considered as coupled.
>
> Check commit 6f3d09291b4982991680b61763b2541e53e2a95f
Reverting that patch yields:
clameter@rd-strategy3-deb64:~$ ./mcast -Ln1
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
101 0 0 0 10 3.0 27.21 31.28 52.68 8.16
Not good.
^ permalink raw reply
* Re: [PATCH] ath5k: do not free irq after resume when card has been removed
From: Bob Copeland @ 2009-09-09 19:31 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: jirislaby-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ, johannes-cdvu00un1VgdHxzADdlk8Q
In-Reply-To: <20090909175006.GA7945-StA3NKSgq9XYLCA8tIpKU1aTQe2KTcn/@public.gmane.org>
On Wed, Sep 09, 2009 at 02:50:06PM -0300, Thadeu Lima de Souza Cascardo wrote:
> This is against v2.6.31-rc9, so I get a warning with a version that's
> about to get stable. Sorry I am late in the release cycle.
Ok yes, that makes sense then.
> Since this is warning, is this worth backporting to rc?
It's too late probably, but we can send it to stable for 2.6.31.1.
Thank you for the patch by the way, just keep in mind that wireless
patches should be against the wireless-testing kernel in the future.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: net_sched 07/07: add classful multiqueue dummy scheduler
From: Jarek Poplawski @ 2009-09-09 19:52 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, netdev
In-Reply-To: <4AA7D1B3.7010708@trash.net>
On Wed, Sep 09, 2009 at 06:02:59PM +0200, Patrick McHardy wrote:
> 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.
You're perfectly right! (And the code is perfectly misleading.;-)
Thanks,
Jarek P.
^ permalink raw reply
* [PATCH NEXT 1/2] netxen: fix check for ip addr hashing support
From: Dhananjay Phadke @ 2009-09-09 20:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Amit Kumar Salecha
Fix typo in checking dest ip has support before
programming destip addresses.
Signed-off-by: Amit Kumar Salecha <amit@netxen.com>
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 304618a..81c24a7 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -2340,7 +2340,7 @@ netxen_config_indev_addr(struct net_device *dev, unsigned long event)
struct in_device *indev;
struct netxen_adapter *adapter = netdev_priv(dev);
- if (netxen_destip_supported(adapter))
+ if (!netxen_destip_supported(adapter))
return;
indev = in_dev_get(dev);
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 2/2] netxen: fix tx descriptor structure
From: Dhananjay Phadke @ 2009-09-09 20:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Amit Kumar Salecha
In-Reply-To: <1252526963-25621-1-git-send-email-dhananjay@netxen.com>
From: Amit Kumar Salecha <amit@qlogic.com>
Fix the offset of vlan_TCI field in cmd_desc_type0.
Signed-off-by: Amit Kumar Salecha <amit@qlogic.com>
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 2a52479..2371888 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -348,9 +348,9 @@ struct cmd_desc_type0 {
__le64 addr_buffer4;
- __le16 vlan_TCI;
- __le16 reserved;
__le32 reserved2;
+ __le16 reserved;
+ __le16 vlan_TCI;
} __attribute__ ((aligned(64)));
--
1.6.0.2
^ permalink raw reply related
* questions / potential bug: e1000e and tx delay setting in msi-x mode
From: Michal Soltys @ 2009-09-09 20:15 UTC (permalink / raw)
To: Linux Netdev List
While experimenting a bit with intel PRO/1000 CT nic (reported by lspci as Intel
Corporation 82574L Gigabit Network Connection), I noticed following issues (?):
1) under default IntMode (MSI-X), TxAbsIntDelay doesn't seem to limit interrupt
rate (as seen via /proc/interrupts), although it is capped by InterruptThrottleRate
(or not at all, if this one is disabled).
For example: with TxIntDelay 100 and TxAbsIntDelay 1000 - rate (as read from
/proc/interrupts) under simple udp netcat bombarding (1k packet size):
nc -u somehost someport </dev/zero
... will be around 115k int/sec - expected value w/o any interrupt moderation.
When IntMode is set to 0 or 1 (so either regular or MSI) - both TxIntDelay and
TxAbsIntDelay seem to work properly - in the above example, rate would stay below
1500 int/sec. But ...
2) ... at the same time, cpu load (as reported by mpstat -P ALL 1) is barely better
in the latter case. Furthermore, if I disable any delays, e.g. load e1000e module with:
options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=1
.. then netcat test will max cpu core, and it will be unable to reach full 1gbit, while:
options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
.. will easily handle 1gbit with ~50%+ idle core (in my case at least).
Should the difference between MSI and MSI-X modes be so large ?
Earlier tests (pt. #1):
options e1000e TxIntDelay=100 TxAbsIntDelay=1000 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=1
.. handles 1gbit with ~60%+ idle core.
and:
options e1000e TxIntDelay=100 TxAbsIntDelay=1000 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
.. are roughly identical as far as cpu load goes.
Those quick tests were done with nic interrupt(s) and netcat pinned at the same core.
Tested with current 2.6.31-rc9 and stable 2.6.30 tree.
^ permalink raw reply
* Re: [PATCH 0/5] Adds implementation of TFRC-SP on DCCP test tree
From: Gerrit Renker @ 2009-09-09 20:19 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <4AA6A252.5060405@embedded.ufcg.edu.br>
| These patches adds implementation of TFRC-SP at the receiver side, and
| are targeted at the DCCP branch
<snip>
|
| Following this patches, we'll be sending the sender side of TFRC-SP.
| Once this code is integrated on the branch, we can proceed adding the
| CCID4 code that uses this new TFRC-SP.
Thanks for all the work and for resending. I will be going through these
over the weekend. My suggestion is that if they compile and work cleanly,
to replace the existing patches in the CCID-4 subtree, so that testing
of the experimental CCID-4 features can continue.
Thanks a lot
Gerrit
^ permalink raw reply
* [PATCH] [NIU] VLAN does not work with niu driver
From: Joyce Yu @ 2009-09-09 21:10 UTC (permalink / raw)
To: netdev
From: Joyce Yu <joyce.yu@sun.com>
Date: Wed, 9 Sep 2009 08:43:00 -0700
Subject: [PATCH] VLAN does not work with niu driver
Signed-off-by: Joyce Yu <joyce.yu@sun.com>
---
drivers/net/niu.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/niu.h b/drivers/net/niu.h
index 3bd0b59..35678db 100644
--- a/drivers/net/niu.h
+++ b/drivers/net/niu.h
@@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
#define RCR_PKT_TYPE_UDP 0x2
#define RCR_PKT_TYPE_SCTP 0x3
-#define NIU_RXPULL_MAX ETH_HLEN
+#define NIU_RXPULL_MAX 64
struct rx_pkt_hdr0 {
#if defined(__LITTLE_ENDIAN_BITFIELD)
--
1.6.4
--
^ permalink raw reply related
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Stephen Hemminger @ 2009-09-09 21:35 UTC (permalink / raw)
To: Joyce.Yu; +Cc: netdev
In-Reply-To: <4AA819D8.1020306@Sun.COM>
On Wed, 09 Sep 2009 14:10:48 -0700
Joyce Yu <Joyce.Yu@sun.com> wrote:
> From: Joyce Yu <joyce.yu@sun.com>
> Date: Wed, 9 Sep 2009 08:43:00 -0700
> Subject: [PATCH] VLAN does not work with niu driver
> Signed-off-by: Joyce Yu <joyce.yu@sun.com>
>
> ---
> drivers/net/niu.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/niu.h b/drivers/net/niu.h
> index 3bd0b59..35678db 100644
> --- a/drivers/net/niu.h
> +++ b/drivers/net/niu.h
> @@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
> #define RCR_PKT_TYPE_UDP 0x2
> #define RCR_PKT_TYPE_SCTP 0x3
>
> -#define NIU_RXPULL_MAX ETH_HLEN
> +#define NIU_RXPULL_MAX 64
>
> struct rx_pkt_hdr0 {
> #if defined(__LITTLE_ENDIAN_BITFIELD)
> --
> 1.6.4
>
Shouldn't the vlan driver being doing pskb_may_pull()
or pskb_pull() instead?
--
^ permalink raw reply
* Re: questions / potential bug: e1000e and tx delay setting in msi-x mode
From: Brandeburg, Jesse @ 2009-09-09 21:59 UTC (permalink / raw)
To: Michal Soltys; +Cc: Linux Netdev List, e1000-devel
In-Reply-To: <4AA80CEE.5030704@ziu.info>
I CCd the maintainers list, which since you are talking about the out of
tree driver (I think) is probably more appropriate for future postings.
On Wed, 9 Sep 2009, Michal Soltys wrote:
> While experimenting a bit with intel PRO/1000 CT nic (reported by lspci as Intel
> Corporation 82574L Gigabit Network Connection), I noticed following issues (?):
>
> 1) under default IntMode (MSI-X), TxAbsIntDelay doesn't seem to limit interrupt
> rate (as seen via /proc/interrupts), although it is capped by InterruptThrottleRate
> (or not at all, if this one is disabled).
Tx[Abs]IntDelay is not meant to work when MSI-X mode is enabled. The only
interrupt throttling you should need is the InterruptThrottleRate (btw you
can use ethtool -C ethX rx-usecs <usecs between interrupts> to modify this
on the fly.)
> For example: with TxIntDelay 100 and TxAbsIntDelay 1000 - rate (as read from
> /proc/interrupts) under simple udp netcat bombarding (1k packet size):
>
> nc -u somehost someport </dev/zero
>
> ... will be around 115k int/sec - expected value w/o any interrupt moderation.
>
> When IntMode is set to 0 or 1 (so either regular or MSI) - both TxIntDelay and
> TxAbsIntDelay seem to work properly - in the above example, rate would stay below
> 1500 int/sec. But ...
>
> 2) ... at the same time, cpu load (as reported by mpstat -P ALL 1) is barely better
> in the latter case. Furthermore, if I disable any delays, e.g. load e1000e module with:
>
> options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=1
>
> .. then netcat test will max cpu core, and it will be unable to reach full 1gbit, while:
>
> options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
>
> .. will easily handle 1gbit with ~50%+ idle core (in my case at least).
>
>
> Should the difference between MSI and MSI-X modes be so large ?
It is, because in the case of MSI-X we don't have to check the ICR
register, which avoids a huge amount of CPU stall to read the single
register. It is the main reason for using MSI-X and MSI (in our case we
still have to read ICR in the case of MSI on some hardware - hardware bug)
> Earlier tests (pt. #1):
>
> options e1000e TxIntDelay=100 TxAbsIntDelay=1000 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=1
>
> .. handles 1gbit with ~60%+ idle core.
>
> and:
>
> options e1000e TxIntDelay=100 TxAbsIntDelay=1000 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
> options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
>
> .. are roughly identical as far as cpu load goes.
>
what it comes down to is that the TxAbsIntDelay and TxIntDelay registers
were introduced in the time before InterruptThrottleRate, back in the day
where we only had PCI and PCI-X adapters. Later PCI/PCI-X/PCIe adapters
have the hardware to support the InterruptThrottleRate.
These module parameters equate directly to registers in our NIC
TADV = TxAbsIntDelay
TIDV = TxIntDelay
ITR = InterruptThrottleRate
The 82574L datasheet[1] mentions that in MSI-X mode the IDE (interrupt
delay enable) bit should *NOT* be set, and the TADV and TIDV registers do
nothing when the IDE bit is not set, so that pretty well explains what you
see. Because the ITR register uses a different mechanism to coalese
interrupts, it will still apply even without IDE enabled.
> Those quick tests were done with nic interrupt(s) and netcat pinned at the same core.
>
>
> Tested with current 2.6.31-rc9 and stable 2.6.30 tree.
[1] http://download.intel.com/design/network/datashts/82574.pdf
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: jamal @ 2009-09-09 22:11 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <313388.35529.qm@web111617.mail.gq1.yahoo.com>
On Wed, 2009-09-09 at 06:12 -0700, Xiaofei Wu wrote:
>
> After run 'tcpdump -i wlan1 -e', I can not capture any packets.
Could it be related to the wireless driver? Here's something i tried
on my laptop
---
dogo:/home/hadi# tc qdisc add dev lo handle 1: root prio
dogo:/home/hadi# tc filter add dev lo parent 1: protocol ip prio 10 u32
match ip src 127.0.0.1/24 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 eth0
---
On window1: tcpdump -n -i eth0
on window2: ping 127.0.0.2
On window1 i see:
----
dogo:/home/hadi# tcpdump -n -i eth0 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:05:23.184602 00:23:cd:af:d0:74 > 00:23:cd:af:ec:da, ethertype IPv4
(0x0800), length 98: 127.0.0.2 > 127.0.0.2: ICMP echo request, id 53329,
seq 1, length 64
18:05:23.558949 00:06:dc:44:4b:ed > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: arp who-has 10.0.0.34 tell 10.0.0.33
18:05:24.199184 00:23:cd:af:d0:74 > 00:23:cd:af:ec:da, ethertype IPv4
(0x0800), length 98: 127.0.0.2 > 127.0.0.2: ICMP echo request, id 53329,
seq 2, length 64
--------
Try the exact example, if it doesnt work then you have other problems;
cheers,
jamal
^ permalink raw reply
* [AX25] kernel panic
From: Bernard Pidoux @ 2009-09-09 22:28 UTC (permalink / raw)
To: Ralf Baechle DL5RB; +Cc: Linux Netdev List, linux-hams
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Hi Ralf,
Here is a set of not so frequent kernel panics captured via netconsole
that seem related to AX25 timer.
Regards,
Bernard Pidoux
[-- Attachment #2: kernel_panic_AX25 --]
[-- Type: text/plain, Size: 33053 bytes --]
------------------------
sam. août 8 22:08:26 CEST 2009
------------------------
BUG: unable to handle kernel paging request at ffff880004c90648
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 7e2067 PTE 4c90160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm i2c_viapro snd_timer snd_page_alloc snd_mixer_oss snd i2c_core soundcore sr_mod 8139cp 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos thermal via_agp processor evdev button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff880004c90400 RCX: 0000000000000058
RDX: ffffe200009cb3d8 RSI: ffffffff8067f060 RDI: ffff880004c90618
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 0000000000000490
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff880004c90618
R13: ffff880004c90400 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff880004c90648 CR3: 0000000074843000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff880004c90400 ffff880004c90400 ffff880004c90400 ffffffffa035bb30
ffffffff80717e30 ffffffffa035b850 ffffffff80717e60 ffffffffa035edb4
ffff880004c90400 ffff880004c90400 0000000000000000 ffffffffa035bb30
Call Trace:
<IRQ> <0> [<ffffffffa035bb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa035b850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa035edb4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa035bb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa035b045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa035bb55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff880004c90648
---[ end trace 366e8cf762bbf316 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..BUG: unable to handle kernel paging request at ffff88001bbee248
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 899067 PTE 1bbee160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm 8139cp snd_timer snd_page_alloc snd_mixer_oss snd soundcore sr_mod 8139too mii i2c_viapro i2c_core shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table thermal processor floppy rtc_cmos via_agp button sg evdev pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff88001bbee000 RCX: 0000000000000058
RDX: ffffe2000060cbb8 RSI: ffffffff8067f060 RDI: ffff88001bbee218
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 00000000000003ee
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff88001bbee218
R13: ffff88001bbee000 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff88001bbee248 CR3: 00000000296e7000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff88001bbee000 ffff88001bbee000 ffff88001bbee000 ffffffffa0355b30
ffffffff80717e30 ffffffffa0355850 ffffffff80717e60 ffffffffa0358db4
ffff88001bbee000 ffff88001bbee000 0000000000000000 ffffffffa0355b30
Call Trace:
<IRQ> <0> [<ffffffffa0355b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0355850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa0358db4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa0355b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0355045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa0355b55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff88001bbee248
---[ end trace b7e0c620509cd638 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..------------------------
jeu. août 13 00:13:13 CEST 2009
------------------------
BUG: unable to handle kernel paging request at ffff880071c80e48
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 9bc067 PMD b4b067 PTE 71c80160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: loop netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss 8139cp i2c_viapro snd soundcore sr_mod 8139too i2c_core mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table thermal floppy rtc_cmos processor via_agp button sg evdev pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff880071c80c00 RCX: 0000000000000058
RDX: ffffe200010313d8 RSI: ffffffff8067f060 RDI: ffff880071c80e18
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 0000000000000480
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff880071c80e18
R13: ffff880071c80c00 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff880071c80e48 CR3: 000000007a11c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff880071c80c00 ffff880071c80c00 ffff880071c80c00 ffffffffa0358b30
ffffffff80717e30 ffffffffa0358850 ffffffff80717e60 ffffffffa035bdb4
ffff880071c80c00 ffff880071c80c00 0000000000000000 ffffffffa0358b30
Call Trace:
<IRQ> <0> [<ffffffffa0358b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0358850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa035bdb4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa0358b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0358045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa0358b55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff880071c80e48
---[ end trace d516331eccbfb939 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..------------------------
sam. août 15 10:15:34 CEST 2009
------------------------
------------------------
sam. août 15 10:16:32 CEST 2009
------------------------
-------------------------------
sam. août 15 13:11:53 CEST 2009
-------------------------------
-------------------------------
sam. août 15 13:16:21 CEST 2009
-------------------------------
-------------------------------
sam. août 15 14:36:50 CEST 2009
-------------------------------
-------------------------------
Sun Aug 16 04:03:12 CEST 2009
-------------------------------
-------------------------------
Mon Aug 17 04:03:21 CEST 2009
-------------------------------
-------------------------------
lun. août 17 12:43:33 CEST 2009
-------------------------------
-------------------------------
lun. août 17 14:03:50 CEST 2009
-------------------------------
-------------------------------
Tue Aug 18 04:03:17 CEST 2009
-------------------------------
-------------------------------
Wed Aug 19 04:03:22 CEST 2009
-------------------------------
-------------------------------
Thu Aug 20 04:03:24 CEST 2009
-------------------------------
-------------------------------
jeu. août 20 14:21:57 CEST 2009
-------------------------------
-------------------------------
jeu. août 20 15:42:15 CEST 2009
-------------------------------
general protection fault: 0000 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa6/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc i2c_viapro snd_mixer_oss snd i2c_core soundcore sr_mod 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos via_agp thermal evdev processor button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 30904, comm: astropulse_5.06 Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffffa034fb3d>] [<ffffffffa034fb3d>] ax25_heartbeat_expiry+0xd/0x60 [ax25]
RSP: 0000:ffffffff80717ea0 EFLAGS: 00010206
RAX: ffff880061829fd8 RBX: ffff88006f59b000 RCX: ffffffffa034fb30
RDX: 6e75203a7473696c RSI: 0000000000000e3f RDI: ffff88006f59b000
RBP: ffffffff80717ea0 R08: ffff88006f59b250 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000100
R13: ffffffff8075a600 R14: ffffffffa034fb30 R15: ffffffff80717ed0
FS: 0000000001493860(0063) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f771ebbd000 CR3: 000000006b867000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process astropulse_5.06 (pid: 30904, threadinfo ffff880061828000, task ffff8800618641a0)
Stack:
ffffffff80717f10 ffffffff8024976c ffffffff8075c210 ffffffff8075be10
ffffffff8075ba10 ffffffff8075b610 ffff88006f512970 ffff88006f512970
ffffffff8025f8ff 0000000000000008 0000000000000001 0000000000000100
Call Trace:
<IRQ> <0> [<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0>Code: 80 7a 58 00 66 90 74 da c9 0f 1f 44 00 00 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8b 57 28 48 89 e5 48 85 d2 74 0c <8b> 42 50 85 c0 78 11 83 f8 01 7f 17 0f 1f 80 00 00 00 00 e8 fb
RIP [<ffffffffa034fb3d>] ax25_heartbeat_expiry+0xd/0x60 [ax25]
RSP <ffffffff80717ea0>
---[ end trace 0dee287bd3d290a3 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Fri Aug 21 04:03:18 CEST 2009
-------------------------------
-------------------------------
Sat Aug 22 04:03:24 CEST 2009
-------------------------------
-------------------------------
Sun Aug 23 04:03:27 CEST 2009
-------------------------------
-------------------------------
Mon Aug 24 04:03:26 CEST 2009
-------------------------------
-------------------------------
Tue Aug 25 04:03:23 CEST 2009
-------------------------------
-------------------------------
Wed Aug 26 04:03:25 CEST 2009
-------------------------------
general protection fault: 0000 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa12/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd 8139too mii i2c_viapro soundcore i2c_core sr_mod shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos via_agp thermal evdev processor button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 28253, comm: astropulse_5.06 Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffffa0342ae8>] [<ffffffffa0342ae8>] ax25_t1timer_expiry+0x8/0x50 [ax25]
RSP: 0000:ffffffff80717ea0 EFLAGS: 00010246
RAX: ffff880074023fd8 RBX: ffff88007bc90000 RCX: ffffffffa0342ae0
RDX: a86496acda711900 RSI: 0000000000000000 RDI: ffff88007bc90000
RBP: ffffffff80717ea0 R08: ffff88007bc90078 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000100
R13: ffffffff8075a600 R14: ffffffffa0342ae0 R15: ffffffff80717ed0
FS: 000000000224b860(0063) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa029a4e000 CR3: 000000007e8e9000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process astropulse_5.06 (pid: 28253, threadinfo ffff880074022000, task ffff8800714c2bc0)
Stack:
ffffffff80717f10 ffffffff8024976c ffffffff8075c210 ffffffff8075be10
ffffffff8075ba10 ffffffff8075b610 ffffffff80717ed0 ffffffff80717ed0
ffffffff8025f8ff 0000000000000008 0000000000000001 0000000000000100
Call Trace:
<IRQ> <0> [<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0>Code: 44 00 00 75 e7 80 7a 58 00 66 90 74 da c9 0f 1f 44 00 00 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8b 57 28 48 89 e5 <8b> 42 50 85 c0 78 0a 83 f8 01 7f 14 e8 e7 f1 ff ff c9 66 0f 1f
RIP [<ffffffffa0342ae8>] ax25_t1timer_expiry+0x8/0x50 [ax25]
RSP <ffffffff80717ea0>
---[ end trace 963e5b19794631dc ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Thu Aug 27 04:03:22 CEST 2009
-------------------------------
-------------------------------
Fri Aug 28 04:03:26 CEST 2009
-------------------------------
BUG: unable to handle kernel paging request at ffff880077ca0e48
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 9bc067 PMD b7b067 PTE 77ca0160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa6/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd i2c_viapro soundcore i2c_core sr_mod 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos via_agp thermal evdev processor button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 30841, comm: setiathome-5.28 Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0000:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff880077ca0c00 RCX: 0000000000000058
RDX: ffffe20001a29a48 RSI: ffffffff8067f060 RDI: ffff880077ca0e18
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 00000000000004a0
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff880077ca0e18
R13: ffff880077ca0c00 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000041b93940(0063) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff880077ca0e48 CR3: 000000006e1fc000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process setiathome-5.28 (pid: 30841, threadinfo ffff88007957c000, task ffff8800750cabc0)
Stack:
ffff880077ca0c00 ffff880077ca0c00 ffff880077ca0c00 ffffffffa034fb30
ffffffff80717e30 ffffffffa034f850 ffffffff80717e60 ffffffffa0352db4
ffff880077ca0c00 ffff880077ca0c00 0000000000000000 ffffffffa034fb30
Call Trace:
<IRQ> <0> [<ffffffffa034fb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa034f850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa0352db4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa034fb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa034f045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa034fb55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0>Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff880077ca0e48
---[ end trace 2278e28e8ee624db ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Sat Aug 29 04:03:23 CEST 2009
-------------------------------
-------------------------------
Sun Aug 30 04:03:21 CEST 2009
-------------------------------
-------------------------------
Mon Aug 31 04:03:24 CEST 2009
-------------------------------
BUG: unable to handle kernel paging request at ffff88006eca8a48
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 9bc067 PMD b33067 PTE 6eca8160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd i2c_viapro 8139too i2c_core soundcore sr_mod mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table via_agp rtc_cmos floppy thermal processor button sg evdev pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff88006eca8800 RCX: 0000000000000058
RDX: ffffe200017e8f68 RSI: ffffffff8067f060 RDI: ffff88006eca8a18
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 00000000000004a8
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff88006eca8a18
R13: ffff88006eca8800 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff88006eca8a48 CR3: 000000006e00b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff88006eca8800 ffff88006eca8800 ffff88006eca8800 ffffffffa0345b30
ffffffff80717e30 ffffffffa0345850 ffffffff80717e60 ffffffffa0348db4
ffff88006eca8800 ffff88006eca8800 0000000000000000 ffffffffa0345b30
Call Trace:
<IRQ> <0> [<ffffffffa0345b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0345850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa0348db4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa0345b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0345045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa0345b55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff88006eca8a48
---[ end trace 62fd644f9e0af320 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Tue Sep 1 04:03:25 CEST 2009
-------------------------------
BUG: unable to handle kernel paging request at ffff88000ad0a248
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 812067 PTE ad0a160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa5/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd soundcore i2c_viapro i2c_core sr_mod 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd rtc_cmos floppy thermal button cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table processor via_agp evdev sg pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff88000ad0a000 RCX: 0000000000000058
RDX: ffffe200019d57a8 RSI: ffffffff8067f060 RDI: ffff88000ad0a218
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 000000000000050a
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff88000ad0a218
R13: ffff88000ad0a000 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff88000ad0a248 CR3: 00000000751da000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff88000ad0a000 ffff88000ad0a000 ffff88000ad0a000 ffffffffa0350b30
ffffffff80717e30 ffffffffa0350850 ffffffff80717e60 ffffffffa0353db4
ffff88000ad0a000 ffff88000ad0a000 0000000000000000 ffffffffa0350b30
Call Trace:
<IRQ> <0> [<ffffffffa0350b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0350850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa0353db4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa0350b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0350045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffffa0350b55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff88000ad0a248
---[ end trace 8cace7d340707eda ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Wed Sep 2 04:03:25 CEST 2009
-------------------------------
-------------------------------
Thu Sep 3 04:03:19 CEST 2009
-------------------------------
-------------------------------
Fri Sep 4 04:03:21 CEST 2009
-------------------------------
BUG: unable to handle kernel paging request at ffff8800141b6a48
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 85c067 PTE 141b6160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa6/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd shpchp i2c_viapro 8139too pci_hotplug soundcore i2c_core sr_mod mii binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table via_agp floppy sg rtc_cmos thermal evdev processor button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 32129, comm: setiathome-5.28 Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0000:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff8800141b6800 RCX: 0000000000000058
RDX: ffffe200004610c8 RSI: ffffffff8067f060 RDI: ffff8800141b6a18
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 00000000000001b6
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff8800141b6a18
R13: ffff8800141b6800 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000041ee4940(0063) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8800141b6a48 CR3: 00000000781d5000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process setiathome-5.28 (pid: 32129, threadinfo ffff8800781e2000, task ffff8800183641a0)
Stack:
ffff8800141b6800 ffff8800141b6800 ffff8800141b6800 ffffffffa034ab30
ffffffff80717e30 ffffffffa034a850 ffffffff80717e60 ffffffffa034ddb4
ffff8800141b6800 ffff8800141b6800 0000000000000000 ffffffffa034ab30
Call Trace:
<IRQ> <0> [<ffffffffa034ab30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa034a850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa034ddb4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa034ab30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa034a045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa034ab55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0>Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff8800141b6a48
---[ end trace 469a474dc114bf10 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Sat Sep 5 04:03:26 CEST 2009
-------------------------------
-------------------------------
Sun Sep 6 04:03:11 CEST 2009
-------------------------------
-------------------------------
Mon Sep 7 04:03:20 CEST 2009
-------------------------------
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-09 22:32 UTC (permalink / raw)
To: Daniel Walker
Cc: i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp,
netdev-u79uwXL29TY76Z2rM5mHXA, Hansjoerg Lipp,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Daniel Walker wrote 07.09.09 16:30:
> Yeah, it looks like the whole file needs a checkpatch clean up.. Sounds
like your not willing to do that?
It's not a question of willingness. You may notice I did a lot of cleanup work already. But it's very time consuming work, and there has been more important work to attend to first.
> Usually if a checkpatch cleanup comes
first prior to all your other changes , it doesn't usually cloud the
rest of the changes..
Sure. But that would mean postponing the merging of bugfixes until someone finds the time to do a complete checkpatch cleanup of the affected code. I don't think that's a sensible approach.
Thanks,
Tilman
^ 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