* 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
* Re: TCP kernel tables overflowing after sustained 1000 new connections per second
From: David Miller @ 2009-09-10 0:08 UTC (permalink / raw)
To: paulsheer; +Cc: linux-kernel, roque, netdev
In-Reply-To: <c67e3dc60909091146j4aeaf422v4e0543eff87c7f9a@mail.gmail.com>
From: Paul Sheer <paulsheer@gmail.com>
Date: Wed, 9 Sep 2009 20:46:07 +0200
Can you please send networking reports and questions at least
CC:'d to netdev@vger.kernel.org, which is where the networking
developers are subscribed? I've added it to the CC:
> I am developing a high-performance application, and testing against Apache.
> It makes 1000 new connections to Apache per second.
>
> After 16 seconds the test grinds to a halt. A Linux kernel problem. There are
> several hurdles to overcome when trying to sustain such through-put. Some
> are configuration issues, others I believe are real problems with the kernel
> internals. I'll discuss these all below.
>
> Configuration:
>
> These are the relavent kernel configuration parameters:
>
> /proc/sys/net/ipv4/tcp_tw_recycle
> /proc/sys/net/ipv4/tcp_tw_reuse
> /proc/sys/net/ipv4/tcp_max_tw_buckets
> /proc/sys/net/ipv4/ip_local_port_range
> /proc/sys/net/ipv4/tcp_timestamps
> /proc/sys/net/ipv4/tcp_fin_timeout
> /proc/sys/net/ipv4/tcp_orphan_retries
> /proc/sys/net/ipv4/tcp_rfc1337
> /proc/sys/net/ipv4/tcp_max_orphans
> /proc/sys/net/ipv4/tcp_max_syn_backlog
> /proc/sys/net/ipv4/tcp_mem
>
> On a gigabit local LAN I can set the timeouts very low to encourage
> port reuse. A well known configuration issue with all OS's - just search
> for MyOS+TIMED_WAIT on google. No problems here.
>
>
> The second problem is the ip_conntrack module.
>
> If you don't know that your distribution has enabled this module
> by default, it not easy to work out that it has internal tables
> that max out at 16384. So this explains why my system
> stops accepting connections after exactly 16 seconds.
> If you stop the application, give it a few minutes, try again,
> then you can do another 16 seconds of flat out load for it
> grinds to a halt again. Doing an rm on the module ko and
> rebooting fixed *this* problem.
>
> The third problem seems to be connected to /proc/net/tcp6
>
> look at the output of the script
>
> while true ; do echo "`date`: `cat /proc/net/tcp6 | wc -l` vs `cat
> /proc/net/tcp | wc -l`" ; sleep 1 ; done
>
> while I run my load test:
>
>
> Wed Sep 9 20:39:26 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:27 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:28 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:29 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:31 SAST 2009: 1233 vs 20
> Wed Sep 9 20:39:32 SAST 2009: 2640 vs 21
> Wed Sep 9 20:39:33 SAST 2009: 4190 vs 20
> Wed Sep 9 20:39:34 SAST 2009: 5813 vs 20
> Wed Sep 9 20:39:35 SAST 2009: 7527 vs 20
> Wed Sep 9 20:39:37 SAST 2009: 9568 vs 44
> Wed Sep 9 20:39:38 SAST 2009: 11819 vs 21
> Wed Sep 9 20:39:40 SAST 2009: 14510 vs 21
> Wed Sep 9 20:39:42 SAST 2009: 16971 vs 20
> Wed Sep 9 20:39:44 SAST 2009: 16971 vs 20
> Wed Sep 9 20:39:46 SAST 2009: 17013 vs 20
> Wed Sep 9 20:39:48 SAST 2009: 17013 vs 20
> Wed Sep 9 20:39:50 SAST 2009: 17013 vs 20
>
> So it is clear "something" is filling up in tcp_ipv6.c
>
> any ideas Pedro?
> anyone?
>
> Many thanks.
>
> -paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* pull request: wireless-next-2.6 2009-09-09
From: John W. Linville @ 2009-09-10 0:10 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
One last batch of wireless bits for the 2.6.32 merge window... :-)
This includes a number of ath9k updates related especially to bluetooth
coexistance, as well as a number of b43 changes related to support of SDIO
and the associated SSB over SDIO bus support.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 6ec1c69a8f6492fd25722f4762721921da074c12:
David S. Miller (1):
net_sched: add classful multiqueue dummy scheduler
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Albert Herranz (1):
ssb: Implement SDIO host bus support
Christian Lamparter (1):
ar9170: implement frequency calibration for one-stage/openfw
Holger Schurig (1):
cfg80211: allow scanning on specified frequencies when using wext-compatibility
Ivo van Doorn (1):
rt2x00: Hardcode TX ack timeout and consume time
Joe Perches (1):
MAINTAINERS: Add Atheros Linux wireless drivers home page
Joerg Albert (3):
ar9170: added phy register initialisation from eeprom values
ath,ar9170: move CTL_ defines into regd.h
ath,ar9170: implemented conformance test limit calc. for tx power
Luis R. Rodriguez (5):
ath9k: propagate ieee80211_alloc_hw() failure
ath9k: propagate errors on ath_init_device() and request_irq()
ath9k: claim irq for ath9k, not ath for pci
wireless: update cfg80211 kconfig entry
wireless: mark prism54 as deprecated and mark for removal
Michael Buesch (10):
b43: Use a threaded IRQ handler
b43: Remove TX spinlock
b43: Remove DMA/PIO queue locks
b43: Remove PIO RX workqueue
b43: remove SHM spinlock
ssb: Fail ssb modinit, if attach of the buses failed.
b43: PCMCIA is not experimental anymore
b43: Really disable QoS, if requested
b43: Fix sparse warning in hw-tkip code
b44/b43/b43legacy: Fix switch warnings introduced by SSB-SDIO
Sujith (2):
ath9k: Fix RX Filter handling for BAR
ath9k: Fix channelFlags for 2GHZ
Vasanthakumar Thiagarajan (6):
ath9k: Disable ASPM when btcoex is active
ath9k: Remove unnecessary casting to u8 in pci_read_config_byte() call
ath9k: Store subsystem id in struct hw_version
ath9k: Enable btcoex based on the subsystem id of the device
ath9k: Get rid of the modparam btcoex_enable
ath9k: Initialize the priority gpio for BT coex 3-wire
Documentation/feature-removal-schedule.txt | 29 ++
MAINTAINERS | 2 +
drivers/net/b44.c | 10 +-
drivers/net/wireless/Kconfig | 57 +--
drivers/net/wireless/ath/ar9170/phy.c | 420 +++++++++++++++++++-
drivers/net/wireless/ath/ath9k/ahb.c | 10 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 23 +
drivers/net/wireless/ath/ath9k/btcoex.h | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 30 +-
drivers/net/wireless/ath/ath9k/hw.h | 10 +
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 12 +-
drivers/net/wireless/ath/ath9k/pci.c | 22 +-
drivers/net/wireless/ath/ath9k/recv.c | 3 +
drivers/net/wireless/ath/ath9k/reg.h | 1 -
drivers/net/wireless/ath/regd.h | 6 +
drivers/net/wireless/ath/regd_common.h | 6 -
drivers/net/wireless/b43/Kconfig | 4 +-
drivers/net/wireless/b43/b43.h | 30 +-
drivers/net/wireless/b43/debugfs.c | 67 +---
drivers/net/wireless/b43/debugfs.h | 3 +-
drivers/net/wireless/b43/dma.c | 31 +--
drivers/net/wireless/b43/dma.h | 3 -
drivers/net/wireless/b43/main.c | 460 +++++++++++-----------
drivers/net/wireless/b43/main.h | 4 -
drivers/net/wireless/b43/phy_common.c | 1 -
drivers/net/wireless/b43/phy_common.h | 3 +-
drivers/net/wireless/b43/phy_g.c | 7 -
drivers/net/wireless/b43/phy_g.h | 3 +-
drivers/net/wireless/b43/pio.c | 71 +---
drivers/net/wireless/b43/pio.h | 6 -
drivers/net/wireless/b43/sysfs.c | 3 -
drivers/net/wireless/b43/xmit.c | 10 +-
drivers/net/wireless/b43legacy/main.c | 8 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 5 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 5 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 4 -
drivers/net/wireless/rt2x00/rt2800usb.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00.h | 3 -
drivers/net/wireless/rt2x00/rt2x00config.c | 11 -
drivers/net/wireless/rt2x00/rt61pci.c | 2 +-
drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
drivers/ssb/Kconfig | 14 +
drivers/ssb/Makefile | 1 +
drivers/ssb/main.c | 64 +++-
drivers/ssb/scan.c | 11 +
drivers/ssb/sdio.c | 610 ++++++++++++++++++++++++++++
drivers/ssb/ssb_private.h | 40 ++
include/linux/ssb/ssb.h | 25 +-
net/wireless/Kconfig | 11 +-
net/wireless/scan.c | 41 ++-
52 files changed, 1673 insertions(+), 539 deletions(-)
create mode 100644 drivers/ssb/sdio.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-09-09.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 0:15 UTC (permalink / raw)
To: Joyce.Yu; +Cc: netdev
In-Reply-To: <4AA819D8.1020306@Sun.COM>
From: Joyce Yu <Joyce.Yu@sun.com>
Date: Wed, 09 Sep 2009 14:10:48 -0700
> drivers/net/niu.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Can I get a more verbose commit message than this?
> @@ -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
>
See, that's why I want a detailed commit message, because if you
described things more clearly I'd understand why you choose the value
'64' as opposed to, say, the size of a VLAN header which to me would
be a more appropriate value to use here.
You just seem to be reverting a change I made a while back, and it
just so happens to fix your problem. But '64' is too large a value
to use here and it will impact performance.
You did check to see if there were any performance regressions
resulting from your change, right?
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 0:16 UTC (permalink / raw)
To: shemminger; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909143514.0bd1e7ba@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 9 Sep 2009 14:35:14 -0700
> Shouldn't the vlan driver being doing pskb_may_pull()
> or pskb_pull() instead?
I thought about it, and my answer is 'probably not'.
Just like for eth_type_trans(), it's pretty reasonable to
expect the link level header to be linearized already.
^ permalink raw reply
* Re: TCP kernel tables overflowing after sustained 1000 new connections per second
From: Brian Haley @ 2009-09-10 0:26 UTC (permalink / raw)
To: paulsheer; +Cc: David Miller, linux-kernel, roque, netdev
In-Reply-To: <20090909.170824.141343404.davem@davemloft.net>
>> The third problem seems to be connected to /proc/net/tcp6
>>
>> look at the output of the script
>>
>> while true ; do echo "`date`: `cat /proc/net/tcp6 | wc -l` vs `cat
>> /proc/net/tcp | wc -l`" ; sleep 1 ; done
>>
>> while I run my load test:
>>
>>
>> Wed Sep 9 20:39:26 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:27 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:28 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:29 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:31 SAST 2009: 1233 vs 20
>> Wed Sep 9 20:39:32 SAST 2009: 2640 vs 21
>> Wed Sep 9 20:39:33 SAST 2009: 4190 vs 20
>> Wed Sep 9 20:39:34 SAST 2009: 5813 vs 20
>> Wed Sep 9 20:39:35 SAST 2009: 7527 vs 20
>> Wed Sep 9 20:39:37 SAST 2009: 9568 vs 44
>> Wed Sep 9 20:39:38 SAST 2009: 11819 vs 21
>> Wed Sep 9 20:39:40 SAST 2009: 14510 vs 21
>> Wed Sep 9 20:39:42 SAST 2009: 16971 vs 20
>> Wed Sep 9 20:39:44 SAST 2009: 16971 vs 20
>> Wed Sep 9 20:39:46 SAST 2009: 17013 vs 20
>> Wed Sep 9 20:39:48 SAST 2009: 17013 vs 20
>> Wed Sep 9 20:39:50 SAST 2009: 17013 vs 20
>>
>> So it is clear "something" is filling up in tcp_ipv6.c
By default, apache is going to open an IPv6 socket, so every connection,
even IPv4, will use an IPv6 socket with a mapped address:
# netstat -anp | grep apache
tcp6 0 0 :::80 :::* LISTEN 27795/apache2
tcp6 0 0 ::ffff:10.0.0.1:80 ::ffff:10.0.0.2:35271 ESTABLISHED27813/apache2
I'm guessing that 17013 is your 16384 plus a few in time-wait, right?
There's a way to change it to be IPv4-only in the conf file from what I remember.
-Brian
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-09-09
From: David Miller @ 2009-09-10 0:36 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090910001025.GA19645@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 9 Sep 2009 20:10:25 -0400
> One last batch of wireless bits for the 2.6.32 merge window... :-)
>
> This includes a number of ath9k updates related especially to bluetooth
> coexistance, as well as a number of b43 changes related to support of SDIO
> and the associated SSB over SDIO bus support.
Pulled, thanks John!
^ permalink raw reply
* Re: [PATCH] ipv6: Add IFA_F_DADFAILED flag
From: Brian Haley @ 2009-09-10 0:41 UTC (permalink / raw)
To: Jens Rosenboom; +Cc: david Miller, netdev@vger.kernel.org, YOSHIFUJI Hideaki
In-Reply-To: <1252424623.5827.14.camel@fnki-nb00130>
Jens Rosenboom wrote:
> On Tue, 2009-09-08 at 11:18 -0400, Brian Haley wrote:
>> Jens Rosenboom wrote:
>>>> --- a/net/ipv6/addrconf.c
>>>> +++ b/net/ipv6/addrconf.c
>>>> @@ -1376,7 +1376,7 @@ static void addrconf_dad_stop(struct inet6_ifaddr *ifp)
>>>> if (ifp->flags&IFA_F_PERMANENT) {
>>>> spin_lock_bh(&ifp->lock);
>>>> addrconf_del_timer(ifp);
>>>> - ifp->flags |= IFA_F_TENTATIVE;
>>>> + ifp->flags |= IFA_F_DADFAILED;
>>> I think you still have to set IFA_F_TENTATIVE here, too, otherwise
>>> ipv6_dev_get_saddr() will use this address.
>> The tentative bit is still set from when this address was added back
>> in ipv6_add_addr() from what I can tell, re-setting it here is actually
>> unnecessary. At least /sbin/ip was still showing it set during my
>> testing.
>
> There is the possibility of a race when the dad_timer expires at the
> same time the NA triggering DAD failure is received. There isn't a big
> chance to see that during real world testing, though.
Ok, how does this look? I changed it to set the tentative flag as it did
before, plus clear the dad_failed flag if the device got restarted,
triggering DAD to happen again for any tentative address, that was an
oversight on my part.
I'd still like to know if using this last ifa_flag is going to be an issue,
I actually finished a similar patch that uses a new IFA_ADDRFLAGS structure
to pass in/out this additional info.
-Brian
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index a60c821..fd97404 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -41,6 +41,7 @@ enum
#define IFA_F_NODAD 0x02
#define IFA_F_OPTIMISTIC 0x04
+#define IFA_F_DADFAILED 0x08
#define IFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE 0x40
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 43b3c9f..c9b3690 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1371,12 +1371,14 @@ struct inet6_ifaddr *ipv6_get_ifaddr(struct net *net, const struct in6_addr *add
/* Gets referenced address, destroys ifaddr */
-static void addrconf_dad_stop(struct inet6_ifaddr *ifp)
+static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
{
if (ifp->flags&IFA_F_PERMANENT) {
spin_lock_bh(&ifp->lock);
addrconf_del_timer(ifp);
ifp->flags |= IFA_F_TENTATIVE;
+ if (dad_failed)
+ ifp->flags |= IFA_F_DADFAILED;
spin_unlock_bh(&ifp->lock);
in6_ifa_put(ifp);
#ifdef CONFIG_IPV6_PRIVACY
@@ -1422,7 +1424,7 @@ void addrconf_dad_failure(struct inet6_ifaddr *ifp)
}
}
- addrconf_dad_stop(ifp);
+ addrconf_dad_stop(ifp, 1);
}
/* Join to solicited addr multicast group. */
@@ -2778,7 +2780,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags)
idev->cnf.accept_dad < 1 ||
!(ifp->flags&IFA_F_TENTATIVE) ||
ifp->flags & IFA_F_NODAD) {
- ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
+ ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC|IFA_F_DADFAILED);
spin_unlock_bh(&ifp->lock);
read_unlock_bh(&idev->lock);
@@ -2795,7 +2797,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags)
* - otherwise, kill it.
*/
in6_ifa_hold(ifp);
- addrconf_dad_stop(ifp);
+ addrconf_dad_stop(ifp, 0);
return;
}
@@ -2829,7 +2831,7 @@ static void addrconf_dad_timer(unsigned long data)
* DAD was successful
*/
- ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
+ ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC|IFA_F_DADFAILED);
spin_unlock_bh(&ifp->lock);
read_unlock_bh(&idev->lock);
^ permalink raw reply related
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Matheos Worku @ 2009-09-10 1:01 UTC (permalink / raw)
To: David Miller; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909.171517.34998160.davem@davemloft.net>
David Miller wrote:
> From: Joyce Yu <Joyce.Yu@sun.com>
> Date: Wed, 09 Sep 2009 14:10:48 -0700
>
>> drivers/net/niu.h | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Can I get a more verbose commit message than this?
>
>> @@ -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
>>
>
> See, that's why I want a detailed commit message, because if you
> described things more clearly I'd understand why you choose the value
> '64' as opposed to, say, the size of a VLAN header which to me would
> be a more appropriate value to use here.
Dave,
The frame type in NIU HW is embedded in a HW header, so it is
possible to check the HW header and decide whether to pull up ETH_HLEN
or VLAN header size of bytes. However, considering the amount of work
required to get and examine the HW header (including endianess issues),
we thought pulling up 64 bytes by default (as used in cassini.c) would
be efficient.
Regards,
Matheos
>
> You just seem to be reverting a change I made a while back, and it
> just so happens to fix your problem. But '64' is too large a value
> to use here and it will impact performance.
>
> You did check to see if there were any performance regressions
> resulting from your change, right?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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