* [PATCH] be2net: convert hdr.timeout in be_cmd_loopback_test() to le32
From: Sathya Perla @ 2010-06-01 7:01 UTC (permalink / raw)
To: netdev
The current code fails on ppc as hdr.timeout is not being converted
to le32.
Pls apply to net-2.6.
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
---
drivers/net/benet/be_cmds.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 9e305d7..b9ad799 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1593,7 +1593,7 @@ int be_cmd_loopback_test(struct be_adapter *adapter, u32 port_num,
be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_LOWLEVEL,
OPCODE_LOWLEVEL_LOOPBACK_TEST, sizeof(*req));
- req->hdr.timeout = 4;
+ req->hdr.timeout = cpu_to_le32(4);
req->pattern = cpu_to_le64(pattern);
req->src_port = cpu_to_le32(port_num);
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] net/ipv4/tcp_input.c: fix compilation breakage when FASTRETRANS_DEBUG > 1
From: David Miller @ 2010-06-01 6:48 UTC (permalink / raw)
To: joe; +Cc: netdev, eric.dumazet
In-Reply-To: <1275330055.14079.8.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Mon, 31 May 2010 11:20:55 -0700
> Commit: c720c7e8383aff1cb219bddf474ed89d850336e3 missed these.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* Re: [PATCH 0/2] netfilter: netfilter fixes
From: David Miller @ 2010-06-01 6:45 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1275322487-19026-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Mon, 31 May 2010 18:14:45 +0200
> the following two patches fix two problems with the recent introduction of
> a seperately allocated jumpstack for xtables rulesets:
>
> - a memory leak when registering new tables, from Xiaotian Feng
>
> - performance degradation caused by not using per-CPU allocations
> for the jumpstack, from Eric
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks Patrick.
^ permalink raw reply
* Re: [PATCH] net: sock_queue_err_skb() dont mess with sk_forward_alloc
From: David Miller @ 2010-06-01 6:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: anton, netdev
In-Reply-To: <1275321766.3291.100.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 31 May 2010 18:02:46 +0200
> There is also a problem in ip_recv_error(), not called with socket
> locked, skb freed -> potential corruption.
>
> If current socket is 'owned' by a user thread, then we can still corrupt
> sk_forward_alloc, even if we use bh_lock_sock()
>
> I dont think we need to have another backlog for such case, maybe we
> could account for skb->truesize in sk_rmem_alloc (this is atomic), and
> not account for sk_mem_charge ?
That sounds fine to me.
> [PATCH] net: sock_queue_err_skb() dont mess with sk_forward_alloc
>
> Correct sk_forward_alloc handling for error_queue would need to use a
> backlog of frames that softirq handler could not deliver because socket
> is owned by user thread. Or extend backlog processing to be able to
> process normal and error packets.
>
> Another possibility is to not use mem charge for error queue, this is
> what I implemented in this patch.
>
> Note: this reverts commit 29030374
> (net: fix sk_forward_alloc corruptions), since we dont need to lock
> socket anymore.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks good, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] can: mpc5xxx_can.c: Fix build failure
From: Wolfgang Grandegger @ 2010-06-01 6:20 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Grant Likely
In-Reply-To: <4C03FF75.3010208-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 05/31/2010 08:27 PM, Wolfgang Grandegger wrote:
> Hi Anatolij,
>
> On 05/31/2010 06:31 PM, Anatolij Gustschin wrote:
>> Fixes build error caused by the OF device_node pointer
>> being moved into struct device.
>>
>> Signed-off-by: Anatolij Gustschin <agust-ynQEQJNshbs@public.gmane.org>
>> Cc: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang.
^ permalink raw reply
* Re: DDoS attack causing bad effect on conntrack searches
From: Changli Gao @ 2010-06-01 5:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: hawk, Jesper Dangaard Brouer, paulmck, Patrick McHardy,
Linux Kernel Network Hackers, Netfilter Developers
In-Reply-To: <1275368732.2478.88.camel@edumazet-laptop>
On Tue, Jun 1, 2010 at 1:05 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 01 juin 2010 à 08:28 +0800, Changli Gao a écrit :
>> On Tue, Jun 1, 2010 at 5:21 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >
>> > I had a look at current conntrack and found the 'unconfirmed' list was
>> > maybe a candidate for a potential blackhole.
>> >
>> > That is, if a reader happens to hit an entry that is moved from regular
>> > hash table slot 'hash' to unconfirmed list,
>>
>> Sorry, but I can't find where we do this things. unconfirmed list is
>> used to track the unconfirmed cts, whose corresponding skbs are still
>> in path from the first to the last netfilter hooks. As soon as the
>> skbs end their travel in netfilter, the corresponding cts will be
>> confirmed(moving ct from unconfirmed list to regular hash table).
>>
>
> So netfilter is a monolithic thing.
>
> When a packet begins its travel into netfilter, you guarantee that no
> other packet can also begin its travel and find an unconfirmed
> conntrack ?
>
> I wonder why we use atomic ops then to track the confirmed bit :)
seems no need.
>
>
>> unconfirmed list should be small, as networking receiving is in BH.
>
> So according to you, netfilter/ct runs only in input path ?
No. there are another entrances: local out and nf_reinject. If there
isn't any packet queued, as netfilter is in atomic context, the nubmer
of unconfirmed cts should be small( at most, 2 * nr_cpu?).
>
> So I assume a packet is handled by CPU X, creates a new conntrack
> (possibly early droping an old entry that was previously in a standard
> hash chain), inserted in unconfirmed list.
>
Oh, Thanks, I got it.
> _You_ guarantee another CPU
> Y, handling another packet, possibly sent by a hacker reading your
> netdev mails, cannot find the conntrack that was early dropped ?
>
>> How about implementing unconfirmed list as a per cpu variable?
>
> I first implemented such a patch to reduce cache line contention, then I
> asked to myself : What is exactly an unconfirmed conntrack ? Can their
> number be unbounded ? If yes, we have a problem, even on a two cpus
> machine. Using two lists instead of one wont solve the fundamental
> problem.
>
> The real question is, why do we need this unconfirmed 'list' in the
> first place. Is it really a private per cpu thing ?
No, it isn't really private. But most of time, it is accessed locally,
if it is implemented as a per cpu var.
> Can you prove this,
> in respect of lockless lookups, and things like NFQUEUE ?
>
> Each conntrack object has two list anchors. One for IP_CT_DIR_ORIGINAL,
> one for IP_CT_DIR_REPLY.
>
> Unconfirmed list use the first anchor. This means another cpu can
> definitely find an unconfirmed item in a regular hash chain, since we
> dont respect an RCU grace period before re-using an object.
>
> If memory was not a problem, we probably would use a third anchor to
> avoid this, or regular RCU instead of SLAB_DESTROY_BY_RCU variant.
>
thanks for your explaining.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: DDoS attack causing bad effect on conntrack searches
From: Eric Dumazet @ 2010-06-01 5:05 UTC (permalink / raw)
To: Changli Gao
Cc: hawk, Jesper Dangaard Brouer, paulmck, Patrick McHardy,
Linux Kernel Network Hackers, Netfilter Developers
In-Reply-To: <AANLkTikw3uonDB4nPXg8FVFN_07F_wq0SA_ayyAHL6VM@mail.gmail.com>
Le mardi 01 juin 2010 à 08:28 +0800, Changli Gao a écrit :
> On Tue, Jun 1, 2010 at 5:21 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > I had a look at current conntrack and found the 'unconfirmed' list was
> > maybe a candidate for a potential blackhole.
> >
> > That is, if a reader happens to hit an entry that is moved from regular
> > hash table slot 'hash' to unconfirmed list,
>
> Sorry, but I can't find where we do this things. unconfirmed list is
> used to track the unconfirmed cts, whose corresponding skbs are still
> in path from the first to the last netfilter hooks. As soon as the
> skbs end their travel in netfilter, the corresponding cts will be
> confirmed(moving ct from unconfirmed list to regular hash table).
>
So netfilter is a monolithic thing.
When a packet begins its travel into netfilter, you guarantee that no
other packet can also begin its travel and find an unconfirmed
conntrack ?
I wonder why we use atomic ops then to track the confirmed bit :)
> unconfirmed list should be small, as networking receiving is in BH.
So according to you, netfilter/ct runs only in input path ?
So I assume a packet is handled by CPU X, creates a new conntrack
(possibly early droping an old entry that was previously in a standard
hash chain), inserted in unconfirmed list. _You_ guarantee another CPU
Y, handling another packet, possibly sent by a hacker reading your
netdev mails, cannot find the conntrack that was early dropped ?
> How about implementing unconfirmed list as a per cpu variable?
I first implemented such a patch to reduce cache line contention, then I
asked to myself : What is exactly an unconfirmed conntrack ? Can their
number be unbounded ? If yes, we have a problem, even on a two cpus
machine. Using two lists instead of one wont solve the fundamental
problem.
The real question is, why do we need this unconfirmed 'list' in the
first place. Is it really a private per cpu thing ? Can you prove this,
in respect of lockless lookups, and things like NFQUEUE ?
Each conntrack object has two list anchors. One for IP_CT_DIR_ORIGINAL,
one for IP_CT_DIR_REPLY.
Unconfirmed list use the first anchor. This means another cpu can
definitely find an unconfirmed item in a regular hash chain, since we
dont respect an RCU grace period before re-using an object.
If memory was not a problem, we probably would use a third anchor to
avoid this, or regular RCU instead of SLAB_DESTROY_BY_RCU variant.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* [PATCH 19/21] net/ipv4/igmp.c: Remove unnecessary kmalloc casts
From: Joe Perches @ 2010-06-01 3:23 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <cover.1275360951.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
net/ipv4/igmp.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 5fff865..250cb5e 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1646,8 +1646,7 @@ static int sf_setstate(struct ip_mc_list *pmc)
if (dpsf->sf_inaddr == psf->sf_inaddr)
break;
if (!dpsf) {
- dpsf = (struct ip_sf_list *)
- kmalloc(sizeof(*dpsf), GFP_ATOMIC);
+ dpsf = kmalloc(sizeof(*dpsf), GFP_ATOMIC);
if (!dpsf)
continue;
*dpsf = *psf;
--
1.7.0.3.311.g6a6955
^ permalink raw reply related
* [PATCH 11/21] drivers/net/tulip/eeprom.c: Remove unnecessary kmalloc casts
From: Joe Perches @ 2010-06-01 3:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Grant Grundler, Kyle McMartin, netdev
In-Reply-To: <cover.1275360951.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/tulip/eeprom.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/tulip/eeprom.c b/drivers/net/tulip/eeprom.c
index 6002e65..3031ed9 100644
--- a/drivers/net/tulip/eeprom.c
+++ b/drivers/net/tulip/eeprom.c
@@ -120,8 +120,8 @@ static void __devinit tulip_build_fake_mediatable(struct tulip_private *tp)
0x00, 0x06 /* ttm bit map */
};
- tp->mtable = (struct mediatable *)
- kmalloc(sizeof(struct mediatable) + sizeof(struct medialeaf), GFP_KERNEL);
+ tp->mtable = kmalloc(sizeof(struct mediatable) +
+ sizeof(struct medialeaf), GFP_KERNEL);
if (tp->mtable == NULL)
return; /* Horrible, impossible failure. */
@@ -227,9 +227,9 @@ subsequent_board:
return;
}
- mtable = (struct mediatable *)
- kmalloc(sizeof(struct mediatable) + count*sizeof(struct medialeaf),
- GFP_KERNEL);
+ mtable = kmalloc(sizeof(struct mediatable) +
+ count * sizeof(struct medialeaf),
+ GFP_KERNEL);
if (mtable == NULL)
return; /* Horrible, impossible failure. */
last_mediatable = tp->mtable = mtable;
--
1.7.0.3.311.g6a6955
^ permalink raw reply related
* [PATCH 20/21] net/ipv6/mcast.c: Remove unnecessary kmalloc casts
From: Joe Perches @ 2010-06-01 3:23 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <cover.1275360951.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
net/ipv6/mcast.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 59f1881..7b5fb43 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1995,8 +1995,7 @@ static int sf_setstate(struct ifmcaddr6 *pmc)
&psf->sf_addr))
break;
if (!dpsf) {
- dpsf = (struct ip6_sf_list *)
- kmalloc(sizeof(*dpsf), GFP_ATOMIC);
+ dpsf = kmalloc(sizeof(*dpsf), GFP_ATOMIC);
if (!dpsf)
continue;
*dpsf = *psf;
--
1.7.0.3.311.g6a6955
^ permalink raw reply related
* [PATCH 10/21] drivers/net/gianfar.c: Remove unnecessary kmalloc casts
From: Joe Perches @ 2010-06-01 3:23 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
In-Reply-To: <cover.1275360951.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/gianfar.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 1830f31..ab54821 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -681,8 +681,8 @@ static int gfar_of_init(struct of_device *ofdev, struct net_device **pdev)
priv->rx_queue[i] = NULL;
for (i = 0; i < priv->num_tx_queues; i++) {
- priv->tx_queue[i] = (struct gfar_priv_tx_q *)kzalloc(
- sizeof (struct gfar_priv_tx_q), GFP_KERNEL);
+ priv->tx_queue[i] = kzalloc(sizeof(struct gfar_priv_tx_q),
+ GFP_KERNEL);
if (!priv->tx_queue[i]) {
err = -ENOMEM;
goto tx_alloc_failed;
@@ -694,8 +694,8 @@ static int gfar_of_init(struct of_device *ofdev, struct net_device **pdev)
}
for (i = 0; i < priv->num_rx_queues; i++) {
- priv->rx_queue[i] = (struct gfar_priv_rx_q *)kzalloc(
- sizeof (struct gfar_priv_rx_q), GFP_KERNEL);
+ priv->rx_queue[i] = kzalloc(sizeof(struct gfar_priv_rx_q),
+ GFP_KERNEL);
if (!priv->rx_queue[i]) {
err = -ENOMEM;
goto rx_alloc_failed;
--
1.7.0.3.311.g6a6955
^ permalink raw reply related
* [PATCH 1/2] tulip: explicity set to D0 power state during init
From: Steven Walter @ 2010-06-01 3:11 UTC (permalink / raw)
To: grundler, kyle, netdev; +Cc: Steven Walter
In-Reply-To: <AANLkTilr33y7rlJpjto5blK4wXKaVst1O4IM0JgPNP7B@mail.gmail.com>
During the first suspend the chip would refuse to enter D3. Subsequent
suspends worked okay. During resume the chip is commanded into D0.
Doing so during initialization fixes the initial suspend.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
---
drivers/net/tulip/tulip_core.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 3810db9..ec013c2 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -1380,6 +1380,13 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
return i;
}
+ /* The chip will fail to enter a low-power state later unless
+ * first explicitly commanded into D0 */
+ if (pci_set_power_state(pdev, PCI_D0)) {
+ printk (KERN_NOTICE PFX
+ "Failed to set power state to D0\n");
+ }
+
irq = pdev->irq;
/* alloc_etherdev ensures aligned and zeroed private structures */
--
1.6.3.3
^ permalink raw reply related
* Re: Bug#583935: linux-image-2.6.32-5-amd64: kernel trace in net/ipv4/tcp_input.c:2540 tcp_ack
From: Ben Hutchings @ 2010-06-01 1:45 UTC (permalink / raw)
To: Ritesh Raj Sarraf, 583935; +Cc: netdev
In-Reply-To: <20100531175508.13357.50413.reportbug@champaran.hq.netapp.com>
[-- Attachment #1: Type: text/plain, Size: 43132 bytes --]
On Mon, 2010-05-31 at 23:25 +0530, Ritesh Raj Sarraf wrote:
> Package: linux-2.6
> Version: 2.6.32-14
> Severity: normal
> Tags: squeeze
>
> I haven't noticed a stability issue as such but saw this kernel trace
> logged into dmesg.
I'm forwarding this to the 'netdev' list to see if the upstream
developers can debug it.
Debian kernel version 2.6.32-14 is closely based on stable kernel
2.6.32.14.
Ben.
> -- Package-specific info:
> ** Version:
> Linux version 2.6.32-5-amd64 (Debian 2.6.32-14) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Sun May 30 17:20:42 UTC 2010
>
> ** Command line:
> BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/LocalDisk-ROOT ro quiet security=tomoyo splash
>
> ** Tainted: W (512)
> * Taint on warning.
>
> ** Kernel log:
> [ 28.406886] iwlagn 0000:03:00.0: firmware: requesting iwlwifi-5000-2.ucode
> [ 28.548635] iwlagn 0000:03:00.0: loaded firmware version 8.24.2.12
> [ 28.692813] Registered led device: iwl-phy0::radio
> [ 28.692830] Registered led device: iwl-phy0::assoc
> [ 28.692847] Registered led device: iwl-phy0::RX
> [ 28.692863] Registered led device: iwl-phy0::TX
> [ 28.705588] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 28.977787] ip_tables: (C) 2000-2006 Netfilter Core Team
> [ 29.974096] CPU0 attaching NULL sched-domain.
> [ 29.974107] CPU1 attaching NULL sched-domain.
> [ 30.000216] CPU0 attaching sched-domain:
> [ 30.000225] domain 0: span 0-1 level MC
> [ 30.000231] groups: 0 1
> [ 30.000243] CPU1 attaching sched-domain:
> [ 30.000248] domain 0: span 0-1 level MC
> [ 30.000253] groups: 1 0
> [ 30.752068] CE: hpet increasing min_delta_ns to 15000 nsec
> [ 34.129035] e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
> [ 34.184125] e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
> [ 34.185657] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 40.052965] Registered led device: iwl-phy0::radio
> [ 40.053013] Registered led device: iwl-phy0::assoc
> [ 40.053057] Registered led device: iwl-phy0::RX
> [ 40.053099] Registered led device: iwl-phy0::TX
> [ 40.062505] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 40.456244] e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
> [ 40.512218] e1000e 0000:00:19.0: irq 28 for MSI/MSI-X
> [ 40.513753] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 40.820920] Registered led device: iwl-phy0::radio
> [ 40.820972] Registered led device: iwl-phy0::assoc
> [ 40.821016] Registered led device: iwl-phy0::RX
> [ 40.821067] Registered led device: iwl-phy0::TX
> [ 40.838420] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 46.301012] wlan0: direct probe to AP 00:16:b6:a5:e7:1c (try 1)
> [ 46.303662] wlan0: direct probe responded
> [ 46.303669] wlan0: authenticate with AP 00:16:b6:a5:e7:1c (try 1)
> [ 46.305533] wlan0: authenticated
> [ 46.305566] wlan0: associate with AP 00:16:b6:a5:e7:1c (try 1)
> [ 46.308078] wlan0: RX AssocResp from 00:16:b6:a5:e7:1c (capab=0x411 status=0 aid=2)
> [ 46.308084] wlan0: associated
> [ 46.322057] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 46.393592] padlock: VIA PadLock not detected.
> [ 50.772185] tun: Universal TUN/TAP device driver, 1.6
> [ 50.772191] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [ 50.775190] tun0: Disabled Privacy Extensions
> [ 57.217677] CPU0 attaching NULL sched-domain.
> [ 57.217681] CPU1 attaching NULL sched-domain.
> [ 57.240126] CPU0 attaching sched-domain:
> [ 57.240130] domain 0: span 0-1 level MC
> [ 57.240133] groups: 0 1
> [ 57.240139] CPU1 attaching sched-domain:
> [ 57.240141] domain 0: span 0-1 level MC
> [ 57.240144] groups: 1 0
> [ 85.004087] hrtimer: interrupt took 544273 ns
> [ 86.926725] TOMOYO-WARNING: Domain '<kernel> /etc/init.d/kdm /sbin/start-stop-daemon /usr/bin/kdm /etc/kde4/kdm/Xsession /bin/bash /usr/bin/ssh-agent /usr/bin/gpg-agent /usr/bin/dbus-launch /usr/bin/startkde /usr/lib/kde4/libexec/start_kdeinit_wrapper /usr/lib/kde4/libexec/start_kdeinit /usr/bin/kdeinit4 /usr/bin/plasma-desktop' has so many ACLs to hold. Stopped learning mode.
> [ 174.886226] padlock: VIA PadLock Hash Engine not detected.
> [ 364.553852] TOMOYO-WARNING: Domain '<kernel> /etc/init.d/kdm /sbin/start-stop-daemon /usr/bin/kdm /etc/kde4/kdm/Xsession /bin/bash /usr/bin/ssh-agent /usr/bin/gpg-agent /usr/bin/dbus-launch /usr/bin/startkde /usr/lib/kde4/libexec/start_kdeinit_wrapper /usr/lib/kde4/libexec/start_kdeinit /usr/bin/kdeinit4 /usr/bin/kontact' has so many ACLs to hold. Stopped learning mode.
> [ 1107.492423] EXT4-fs (dm-2): mounted filesystem with ordered data mode
> [ 2099.365512] TOMOYO-WARNING: Domain '<kernel> /etc/init.d/kdm /sbin/start-stop-daemon /usr/bin/kdm /etc/kde4/kdm/Xsession /bin/bash /usr/bin/ssh-agent /usr/bin/gpg-agent /usr/bin/dbus-launch /usr/bin/startkde /usr/lib/kde4/libexec/start_kdeinit_wrapper /usr/lib/kde4/libexec/start_kdeinit /usr/bin/kdeinit4 /usr/bin/konsole /bin/bash /usr/bin/sudo /usr/bin/aptitude /usr/bin/dpkg' has so many ACLs to hold. Stopped learning mode.
> [ 3497.934021] TOMOYO-WARNING: Domain '<kernel> /etc/init.d/kdm /sbin/start-stop-daemon /usr/bin/kdm /etc/kde4/kdm/Xsession /bin/bash /usr/bin/ssh-agent /usr/bin/gpg-agent /usr/bin/dbus-launch /usr/bin/startkde /usr/lib/kde4/libexec/start_kdeinit_wrapper /usr/lib/kde4/libexec/start_kdeinit /usr/bin/kdeinit4 /usr/bin/ktorrent' has so many ACLs to hold. Stopped learning mode.
> [ 6794.222126] TOMOYO-WARNING: Domain '<kernel> /etc/init.d/kdm /sbin/start-stop-daemon /usr/bin/kdm /etc/kde4/kdm/Xsession /bin/bash /usr/bin/ssh-agent /usr/bin/gpg-agent /usr/bin/dbus-launch /usr/bin/startkde /usr/lib/kde4/libexec/start_kdeinit_wrapper /usr/lib/kde4/libexec/start_kdeinit /usr/bin/kdeinit4 /usr/bin/krunner /usr/lib/kde4/libexec/kscreenlocker /usr/bin/plasma-overlay' has so many ACLs to hold. Stopped learning mode.
> [ 7716.171410] ------------[ cut here ]------------
> [ 7716.171420] WARNING: at /build/buildd-linux-2.6_2.6.32-14-amd64-yRQD2k/linux-2.6-2.6.32/debian/build/source_amd64_none/net/ipv4/tcp_input.c:2540 tcp_ack+0x160e/0x1952()
> [ 7716.171424] Hardware name: 6475KH8
> [ 7716.171426] Modules linked in: sha256_generic cbc tun aes_x86_64 aes_generic xt_state iptable_filter ip_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_proto_dccp nf_conntrack_pptp xt_conntrack x_tables nf_conntrack_ftp nf_conntrack_sane ts_kmp nf_conntrack_amanda nf_conntrack_h323 nf_conntrack_proto_gre nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_irc nf_conntrack_proto_udplite nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_ipv6 nf_conntrack ppdev lp parport sco bridge stp bnep rfcomm l2cap acpi_cpufreq cpufreq_stats cpufreq_userspace cpufreq_conservative cpufreq_powersave hdaps thinkpad_ec kvm_intel kvm uinput binfmt_misc fuse ext3 jbd loop firewire_sbp2 dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec arc4 snd_pcsp snd_hwdep ecb snd_pcm_oss i915 snd_mixer_oss drm_kms_helper uvcvideo videodev snd_pcm v4l1_compat btusb joydev bluetooth iwlagn pcmcia snd_timer v4l2_compat_ioctl32 drm iwlcore i2c_algo_bit snd t
> hinkpad_acpi yenta_socket i2c_i801 tpm_tis soundcore tpm nvram led_class video snd_page_alloc tpm_bios i2c_core mac80211 cfg80211 wmi rfkill rsrc_nonstatic output pcmcia_core evdev ac serio_raw psmouse button battery processor ext4 mbcache jbd2 crc16 dm_mod sg sd_mod sr_mod crc_t10dif cdrom uhci_hcd firewire_ohci firewire_core crc_itu_t ahci ehci_hcd libata e1000e scsi_mod usbcore nls_base thermal thermal_sys [last unloaded: scsi_wait_scan]
> [ 7716.171547] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1
> [ 7716.171549] Call Trace:
> [ 7716.171551] <IRQ> [<ffffffff81283705>] ? tcp_ack+0x160e/0x1952
> [ 7716.171559] [<ffffffff81283705>] ? tcp_ack+0x160e/0x1952
> [ 7716.171564] [<ffffffff8104dc48>] ? warn_slowpath_common+0x77/0xa3
> [ 7716.171569] [<ffffffff81283705>] ? tcp_ack+0x160e/0x1952
> [ 7716.171573] [<ffffffff81284166>] ? tcp_rcv_established+0xc9/0x6d9
> [ 7716.171578] [<ffffffff8128b6ef>] ? tcp_v4_do_rcv+0x1bb/0x376
> [ 7716.171583] [<ffffffff8126ef89>] ? ip_route_input+0x6b/0xcbf
> [ 7716.171587] [<ffffffff8128bd0f>] ? tcp_v4_rcv+0x465/0x6b6
> [ 7716.171592] [<ffffffff81271216>] ? ip_local_deliver_finish+0x0/0x1e9
> [ 7716.171596] [<ffffffff81271216>] ? ip_local_deliver_finish+0x0/0x1e9
> [ 7716.171600] [<ffffffff8127135c>] ? ip_local_deliver_finish+0x146/0x1e9
> [ 7716.171605] [<ffffffff81270eab>] ? ip_rcv_finish+0x373/0x38d
> [ 7716.171609] [<ffffffff81271165>] ? ip_rcv+0x2a0/0x2ed
> [ 7716.171614] [<ffffffff8124d55e>] ? process_backlog+0x81/0xb4
> [ 7716.171618] [<ffffffff8124db37>] ? net_rx_action+0xae/0x1c9
> [ 7716.171623] [<ffffffff810539d6>] ? __do_softirq+0xdd/0x19f
> [ 7716.171634] [<ffffffffa02b533d>] ? iwl_isr_ict+0x179/0x200 [iwlcore]
> [ 7716.171639] [<ffffffff81011cac>] ? call_softirq+0x1c/0x30
> [ 7716.171643] [<ffffffff81013903>] ? do_softirq+0x3f/0x7c
> [ 7716.171647] [<ffffffff81053845>] ? irq_exit+0x36/0x76
> [ 7716.171651] [<ffffffff81012ffa>] ? do_IRQ+0xa0/0xb6
> [ 7716.171655] [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11
> [ 7716.171657] <EOI> [<ffffffffa0201647>] ? acpi_idle_enter_simple+0x116/0x148 [processor]
> [ 7716.171677] [<ffffffffa0201647>] ? acpi_idle_enter_simple+0x116/0x148 [processor]
> [ 7716.171682] [<ffffffffa0201640>] ? acpi_idle_enter_simple+0x10f/0x148 [processor]
> [ 7716.171686] [<ffffffff81237e46>] ? cpuidle_idle_call+0x94/0xee
> [ 7716.171690] [<ffffffff8100feb1>] ? cpu_idle+0xa2/0xda
> [ 7716.171693] [<ffffffff814ec140>] ? early_idt_handler+0x0/0x71
> [ 7716.171696] [<ffffffff814eccd1>] ? start_kernel+0x3dc/0x3e8
> [ 7716.171699] [<ffffffff814ec3b7>] ? x86_64_start_kernel+0xf9/0x106
> [ 7716.171701] ---[ end trace d930a229f048f9d9 ]---
> [10602.944028] TCP: Peer 151.81.183.141:30126/44441 unexpectedly shrunk window 773717473:773723425 (repaired)
> [10657.848015] TCP: Peer 151.81.183.141:30126/44441 unexpectedly shrunk window 773717473:773723425 (repaired)
>
> ** Model information
> sys_vendor: LENOVO
> product_name: 6475KH8
> product_version: ThinkPad T400
> chassis_vendor: LENOVO
> chassis_version: Not Available
> bios_vendor: LENOVO
> bios_version: 7UET79WW (3.09 )
> board_vendor: LENOVO
> board_name: 6475KH8
> board_version: Not Available
>
> ** Loaded modules:
> Module Size Used by
> sha256_generic 8692 2
> cbc 2539 1
> tun 10828 0
> aes_x86_64 7340 5
> aes_generic 25714 1 aes_x86_64
> xt_state 1303 16
> iptable_filter 2258 1
> ip_tables 13899 1 iptable_filter
> nf_conntrack_ipv4 9833 16
> nf_defrag_ipv4 1139 1 nf_conntrack_ipv4
> nf_conntrack_tftp 3321 0
> nf_conntrack_proto_dccp 6466 0
> nf_conntrack_pptp 3801 0
> xt_conntrack 2407 0
> x_tables 12845 3 xt_state,ip_tables,xt_conntrack
> nf_conntrack_ftp 5537 0
> nf_conntrack_sane 3620 0
> ts_kmp 1623 5
> nf_conntrack_amanda 2197 0
> nf_conntrack_h323 36992 0
> nf_conntrack_proto_gre 3579 1 nf_conntrack_pptp
> nf_conntrack_sip 13546 0
> nf_conntrack_proto_sctp 6238 0
> nf_conntrack_irc 3347 0
> nf_conntrack_proto_udplite 2623 0
> nf_conntrack_netlink 13128 0
> nfnetlink 2398 1 nf_conntrack_netlink
> nf_conntrack_netbios_ns 1282 0
> nf_conntrack_ipv6 10467 0
> nf_conntrack 46551 18 xt_state,nf_conntrack_ipv4,nf_conntrack_tftp,nf_conntrack_proto_dccp,nf_conntrack_pptp,xt_conntrack,nf_conntrack_ftp,nf_conntrack_sane,nf_conntrack_amanda,nf_conntrack_h323,nf_conntrack_proto_gre,nf_conntrack_sip,nf_conntrack_proto_sctp,nf_conntrack_irc,nf_conntrack_proto_udplite,nf_conntrack_netlink,nf_conntrack_netbios_ns,nf_conntrack_ipv6
> ppdev 5030 0
> lp 7462 0
> parport 27954 2 ppdev,lp
> sco 7209 2
> bridge 39598 0
> stp 1440 1 bridge
> bnep 9427 2
> rfcomm 29581 6
> l2cap 24736 16 bnep,rfcomm
> acpi_cpufreq 5555 0
> cpufreq_stats 2659 0
> cpufreq_userspace 1992 0
> cpufreq_conservative 5162 0
> cpufreq_powersave 902 0
> hdaps 7765 1
> thinkpad_ec 3694 1 hdaps
> kvm_intel 38050 0
> kvm 213544 1 kvm_intel
> uinput 6376 1
> binfmt_misc 6431 1
> fuse 50190 1
> ext3 106518 1
> jbd 37085 1 ext3
> loop 11783 0
> firewire_sbp2 11514 0
> dm_crypt 10507 1
> snd_hda_codec_conexant 21869 1
> snd_hda_intel 19907 3
> snd_hda_codec 54244 2 snd_hda_codec_conexant,snd_hda_intel
> arc4 1274 2
> snd_pcsp 6579 2
> snd_hwdep 5380 1 snd_hda_codec
> ecb 1841 2
> snd_pcm_oss 32591 0
> i915 252896 2
> snd_mixer_oss 12606 1 snd_pcm_oss
> drm_kms_helper 20065 1 i915
> uvcvideo 51743 0
> videodev 29993 1 uvcvideo
> snd_pcm 60471 4 snd_hda_intel,snd_hda_codec,snd_pcsp,snd_pcm_oss
> v4l1_compat 11442 2 uvcvideo,videodev
> btusb 9785 2
> joydev 8411 0
> bluetooth 41827 9 sco,bnep,rfcomm,l2cap,btusb
> iwlagn 71756 0
> pcmcia 19474 0
> snd_timer 15582 1 snd_pcm
> v4l2_compat_ioctl32 8538 1 videodev
> drm 142551 3 i915,drm_kms_helper
> iwlcore 77442 1 iwlagn
> i2c_algo_bit 4225 1 i915
> snd 46446 19 snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec,snd_pcsp,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
> thinkpad_acpi 50103 0
> yenta_socket 19115 1
> i2c_i801 7830 0
> tpm_tis 7336 0
> soundcore 4598 1 snd
> tpm 9917 1 tpm_tis
> nvram 5061 1 thinkpad_acpi
> led_class 2433 2 iwlcore,thinkpad_acpi
> video 17445 1 i915
> snd_page_alloc 6249 2 snd_hda_intel,snd_pcm
> tpm_bios 4521 1 tpm
> i2c_core 15712 6 i915,drm_kms_helper,videodev,drm,i2c_algo_bit,i2c_i801
> mac80211 136844 2 iwlagn,iwlcore
> cfg80211 101432 3 iwlagn,iwlcore,mac80211
> wmi 4323 0
> rfkill 13044 4 bluetooth,thinkpad_acpi,cfg80211
> rsrc_nonstatic 7294 1 yenta_socket
> output 1692 1 video
> pcmcia_core 24118 3 pcmcia,yenta_socket,rsrc_nonstatic
> evdev 7352 28
> ac 2192 0
> serio_raw 3752 0
> psmouse 49777 0
> button 4650 1 i915
> battery 4998 0
> processor 30231 3 acpi_cpufreq
> ext4 285611 2
> mbcache 5050 2 ext3,ext4
> jbd2 66919 1 ext4
> crc16 1319 2 l2cap,ext4
> dm_mod 53754 9 dm_crypt
> sg 18744 0
> sd_mod 29777 4
> sr_mod 12602 0
> crc_t10dif 1276 1 sd_mod
> cdrom 29415 1 sr_mod
> uhci_hcd 18521 0
> firewire_ohci 19468 0
> firewire_core 36736 2 firewire_sbp2,firewire_ohci
> crc_itu_t 1307 1 firewire_core
> ahci 32358 3
> ehci_hcd 31039 0
> libata 133520 1 ahci
> e1000e 109967 0
> scsi_mod 122117 5 firewire_sbp2,sg,sd_mod,sr_mod,libata
> usbcore 121959 5 uvcvideo,btusb,uhci_hcd,ehci_hcd
> nls_base 6361 1 usbcore
> thermal 11674 0
> thermal_sys 11942 3 video,processor,thermal
>
> ** Network interface configuration:
>
> auto lo
> iface lo inet loopback
>
> iface eth0dhcp inet dhcp
>
>
> iface dsl-provider inet ppp
> pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
> provider dsl-provider
>
> iface wlan0blr inet dhcp
> wpa-ssid rrs
> wpa-psk *******************************
>
> iface wlan0netapp inet dhcp
> wpa-ssid netapp
>
> ** Network status:
> *** IP interfaces and addresses:
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> link/ether 00:22:68:1b:af:4a brd ff:ff:ff:ff:ff:ff
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:26:c6:72:07:9a brd ff:ff:ff:ff:ff:ff
> inet 192.168.2.101/24 brd 192.168.2.255 scope global wlan0
> inet6 fe80::226:c6ff:fe72:79a/64 scope link
> valid_lft forever preferred_lft forever
> 4: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> link/ether 52:02:e9:0e:27:d2 brd ff:ff:ff:ff:ff:ff
>
> *** Device statistics:
> Inter-| Receive | Transmit
> face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
> lo:42635507 41327 0 0 0 0 0 0 42635507 41327 0 0 0 0 0 0
> eth0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> wlan0:1032619756 1390916 0 0 0 0 0 0 752433881 1882435 0 0 0 0 0 0
> pan0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> *** Protocol statistics:
> Ip:
> 1449157 total packets received
> 0 forwarded
> 0 incoming packets discarded
> 1444671 incoming packets delivered
> 1938464 requests sent out
> 109 outgoing packets dropped
> 15 dropped because of missing route
> 2 reassemblies required
> 1 packets reassembled ok
> 5 fragments failed
> Icmp:
> 3120 ICMP messages received
> 0 input ICMP message failed.
> ICMP input histogram:
> destination unreachable: 3015
> timeout in transit: 105
> 2318 ICMP messages sent
> 0 ICMP messages failed
> ICMP output histogram:
> destination unreachable: 2318
> IcmpMsg:
> InType3: 3015
> InType11: 105
> OutType3: 2318
> Tcp:
> 80024 active connections openings
> 23 passive connection openings
> 14172 failed connection attempts
> 1039 connection resets received
> 47 connections established
> 1372879 segments received
> 1620413 segments send out
> 212825 segments retransmited
> 0 bad segments received.
> 7303 resets sent
> Udp:
> 66389 packets received
> 2313 packets to unknown port received.
> 0 packet receive errors
> 103244 packets sent
> UdpLite:
> TcpExt:
> 531 packets pruned from receive queue because of socket buffer overrun
> 34 ICMP packets dropped because they were out-of-window
> 1 ICMP packets dropped because socket was locked
> 1790 TCP sockets finished time wait in fast timer
> 1265 time wait sockets recycled by time stamp
> 172 packets rejects in established connections because of timestamp
> 26690 delayed acks sent
> 5 delayed acks further delayed because of locked socket
> Quick ack mode was activated 32051 times
> 1061 packets directly queued to recvmsg prequeue.
> 620116 bytes directly received in process context from prequeue
> 359424 packet headers predicted
> 595 packets header predicted and directly queued to user
> 213531 acknowledgments not containing data payload received
> 69799 predicted acknowledgments
> 3 times recovered from packet loss due to fast retransmit
> 9376 times recovered from packet loss by selective acknowledgements
> 6 bad SACK blocks received
> Detected reordering 5 times using FACK
> Detected reordering 12 times using SACK
> Detected reordering 36 times using time stamp
> 33 congestion windows fully recovered without slow start
> 70 congestion windows partially recovered using Hoe heuristic
> 13 congestion windows recovered without slow start by DSACK
> 15526 congestion windows recovered without slow start after partial ack
> 11091 TCP data loss events
> TCPLostRetransmit: 538
> 18 timeouts after reno fast retransmit
> 5211 timeouts after SACK recovery
> 2758 timeouts in loss state
> 19421 fast retransmits
> 232 forward retransmits
> 19995 retransmits in slow start
> 88651 other TCP timeouts
> 3 classic Reno fast retransmits failed
> 2608 SACK retransmits failed
> 6832 packets collapsed in receive queue due to low socket buffer
> 72330 DSACKs sent for old packets
> 10715 DSACKs sent for out of order packets
> 5884 DSACKs received
> 28 DSACKs for out of order packets received
> 2515 connections reset due to unexpected data
> 156 connections reset due to early user close
> 3646 connections aborted due to timeout
> 7 times unabled to send RST due to no memory
> TCPSACKDiscard: 2
> TCPDSACKIgnoredOld: 3730
> TCPDSACKIgnoredNoUndo: 1811
> TCPSpuriousRTOs: 46
> TCPSackShiftFallback: 71643
> IpExt:
> InNoRoutes: 2
> InMcastPkts: 342
> OutMcastPkts: 301
> InBcastPkts: 4
> InOctets: 1070306263
> OutOctets: 732197456
> InMcastOctets: 44349
> OutMcastOctets: 40280
> InBcastOctets: 1312
>
> *** Device features:
> eth0: 0x1109a9
> lo: 0x13865
> pan0: 0xff3865
> wlan0: 0x2000
>
> ** PCI devices:
> 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
> Subsystem: Lenovo Device [17aa:20e0]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
> Latency: 0
> Capabilities: <access denied>
> Kernel driver in use: agpgart-intel
>
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
> Subsystem: Lenovo Device [17aa:20e4]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 31
> Region 0: Memory at f4400000 (64-bit, non-prefetchable) [size=4M]
> Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
> Region 4: I/O ports at 1800 [size=8]
> Expansion ROM at <unassigned> [disabled]
> Capabilities: <access denied>
> Kernel driver in use: i915
>
> 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
> Subsystem: Lenovo Device [17aa:20e4]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Region 0: Memory at f4200000 (64-bit, non-prefetchable) [size=1M]
> Capabilities: <access denied>
>
> 00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07)
> Subsystem: Lenovo Device [17aa:20e6]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
> Latency: 0
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at fc226800 (64-bit, non-prefetchable) [size=16]
> Capabilities: <access denied>
>
> 00:03.3 Serial controller [0700]: Intel Corporation Mobile 4 Series Chipset AMT SOL Redirection [8086:2a47] (rev 07) (prog-if 02 [16550])
> Subsystem: Lenovo Device [17aa:20ec]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin B routed to IRQ 17
> Region 0: I/O ports at 1830 [size=8]
> Region 1: Memory at fc024000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: <access denied>
> Kernel driver in use: serial
>
> 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
> Subsystem: Lenovo Device [17aa:20ee]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 28
> Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at fc025000 (32-bit, non-prefetchable) [size=4K]
> Region 2: I/O ports at 1840 [size=32]
> Capabilities: <access denied>
> Kernel driver in use: e1000e
>
> 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device [17aa:20f0]
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 20
> Region 4: I/O ports at 1860 [size=32]
> Capabilities: <access denied>
> Kernel driver in use: uhci_hcd
>
> 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device [17aa:20f0]
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin B routed to IRQ 21
> Region 4: I/O ports at 1880 [size=32]
> Capabilities: <access denied>
> Kernel driver in use: uhci_hcd
>
> 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device [17aa:20f0]
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin C routed to IRQ 22
> Region 4: I/O ports at 18a0 [size=32]
> Capabilities: <access denied>
> Kernel driver in use: uhci_hcd
>
> 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) (prog-if 20 [EHCI])
> Subsystem: Lenovo Device [17aa:20f1]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin D routed to IRQ 23
> Region 0: Memory at fc226c00 (32-bit, non-prefetchable) [size=1K]
> Capabilities: <access denied>
> Kernel driver in use: ehci_hcd
>
> 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
> Subsystem: Lenovo Device [17aa:20f2]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 17
> Region 0: Memory at fc020000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: <access denied>
> Kernel driver in use: HDA Intel
>
> 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
> I/O behind bridge: 00008000-00008fff
> Memory behind bridge: bc000000-bc1fffff
> Prefetchable memory behind bridge: 00000000bc200000-00000000bc3fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Capabilities: <access denied>
> Kernel driver in use: pcieport
>
> 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
> I/O behind bridge: 00009000-00009fff
> Memory behind bridge: f4300000-f43fffff
> Prefetchable memory behind bridge: 00000000bc400000-00000000bc5fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Capabilities: <access denied>
> Kernel driver in use: pcieport
>
> 00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 03) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=05, subordinate=0c, sec-latency=0
> I/O behind bridge: 00002000-00002fff
> Memory behind bridge: f8000000-f9ffffff
> Prefetchable memory behind bridge: 00000000f4000000-00000000f40fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Capabilities: <access denied>
> Kernel driver in use: pcieport
>
> 00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 03) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=0d, subordinate=14, sec-latency=0
> I/O behind bridge: 00003000-00003fff
> Memory behind bridge: fa000000-fbffffff
> Prefetchable memory behind bridge: 00000000f4100000-00000000f41fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Capabilities: <access denied>
> Kernel driver in use: pcieport
>
> 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device [17aa:20f0]
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 16
> Region 4: I/O ports at 18c0 [size=32]
> Capabilities: <access denied>
> Kernel driver in use: uhci_hcd
>
> 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device [17aa:20f0]
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin B routed to IRQ 17
> Region 4: I/O ports at 18e0 [size=32]
> Capabilities: <access denied>
> Kernel driver in use: uhci_hcd
>
> 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) (prog-if 00 [UHCI])
> Subsystem: Lenovo Device [17aa:20f0]
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin C routed to IRQ 18
> Region 4: I/O ports at 1c00 [size=32]
> Capabilities: <access denied>
> Kernel driver in use: uhci_hcd
>
> 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) (prog-if 20 [EHCI])
> Subsystem: Lenovo Device [17aa:20f1]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin D routed to IRQ 19
> Region 0: Memory at fc227000 (32-bit, non-prefetchable) [size=1K]
> Capabilities: <access denied>
> Kernel driver in use: ehci_hcd
>
> 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93) (prog-if 01 [Subtractive decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Bus: primary=00, secondary=15, subordinate=18, sec-latency=32
> I/O behind bridge: 00004000-00007fff
> Memory behind bridge: f4800000-f7ffffff
> Prefetchable memory behind bridge: 00000000f0000000-00000000f3ffffff
> Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
> BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Capabilities: <access denied>
>
> 00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
> Subsystem: Lenovo Device [17aa:20f5]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Capabilities: <access denied>
>
> 00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI Controller [8086:2929] (rev 03) (prog-if 01 [AHCI 1.0])
> Subsystem: Lenovo Device [17aa:20f8]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin B routed to IRQ 29
> Region 0: I/O ports at 1c48 [size=8]
> Region 1: I/O ports at 183c [size=4]
> Region 2: I/O ports at 1c40 [size=8]
> Region 3: I/O ports at 1838 [size=4]
> Region 4: I/O ports at 1c20 [size=32]
> Region 5: Memory at fc226000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: <access denied>
> Kernel driver in use: ahci
>
> 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03)
> Subsystem: Lenovo Device [17aa:20f9]
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Interrupt: pin A routed to IRQ 23
> Region 0: Memory at fc227400 (64-bit, non-prefetchable) [size=256]
> Region 4: I/O ports at 1c60 [size=32]
> Kernel driver in use: i801_smbus
>
> 03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection [8086:4237]
> Subsystem: Intel Corporation WiFi Link 5100 AGN [8086:1211]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 30
> Region 0: Memory at f4300000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: <access denied>
> Kernel driver in use: iwlagn
>
> 15:00.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba)
> Subsystem: Lenovo Device [17aa:20c6]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 168, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 16
> Region 0: Memory at f4800000 (32-bit, non-prefetchable) [size=4K]
> Bus: primary=15, secondary=16, subordinate=17, sec-latency=176
> Memory window 0: f0000000-f3fff000 (prefetchable)
> Memory window 1: c0000000-c3fff000
> I/O window 0: 00004000-000040ff
> I/O window 1: 00004400-000044ff
> BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
> 16-bit legacy interface ports at 0001
> Kernel driver in use: yenta_cardbus
>
> 15:00.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04) (prog-if 10 [OHCI])
> Subsystem: Lenovo Device [17aa:20c7]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 32 (500ns min, 1000ns max), Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 17
> Region 0: Memory at f4801000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: <access denied>
> Kernel driver in use: firewire_ohci
>
>
> ** USB devices:
> Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 003: ID 0a5c:2145 Broadcom Corp. Bluetooth with Enhanced Data Rate II
> Bus 004 Device 002: ID 08ff:2810 AuthenTec, Inc. AES2810
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 004: ID 17ef:1004 Lenovo
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
> -- System Information:
> Debian Release: squeeze/sid
> APT prefers testing
> APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages linux-image-2.6.32-5-amd64 depends on:
> ii debconf [debconf 1.5.32 Debian configuration management sy
> ii initramfs-tools 0.94.4 tools for generating an initramfs
> ii linux-base 2.6.34-1~experimental.1 Linux image base package
> ii module-init-tool 3.12~pre2-3 tools for managing Linux kernel mo
>
> Versions of packages linux-image-2.6.32-5-amd64 recommends:
> ii firmware-linux-f 2.6.34-1~experimental.1 Binary firmware for various driver
>
> Versions of packages linux-image-2.6.32-5-amd64 suggests:
> pn grub | lilo <none> (no description available)
> ii linux-doc-2.6.32 2.6.32-9 Linux kernel specific documentatio
>
> Versions of packages linux-image-2.6.32-5-amd64 is related to:
> pn firmware-bnx2 <none> (no description available)
> pn firmware-bnx2x <none> (no description available)
> pn firmware-ipw2x00 <none> (no description available)
> pn firmware-ivtv <none> (no description available)
> ii firmware-iwlwifi 0.24 Binary firmware for Intel Wireless
> ii firmware-linux 0.24 Binary firmware for various driver
> ii firmware-linux-nonfree 0.24 Binary firmware for various driver
> pn firmware-qlogic <none> (no description available)
> pn firmware-ralink <none> (no description available)
> pn xen-hypervisor <none> (no description available)
>
> -- debconf information:
> shared/kernel-image/really-run-bootloader: true
> linux-image-2.6.32-5-amd64/postinst/depmod-error-initrd-2.6.32-5-amd64: false
> linux-image-2.6.32-5-amd64/prerm/removing-running-kernel-2.6.32-5-amd64: true
> linux-image-2.6.32-5-amd64/postinst/missing-firmware-2.6.32-5-amd64:
> linux-image-2.6.32-5-amd64/postinst/bootloader-test-error-2.6.32-5-amd64:
> linux-image-2.6.32-5-amd64/postinst/bootloader-error-2.6.32-5-amd64:
> linux-image-2.6.32-5-amd64/prerm/would-invalidate-boot-loader-2.6.32-5-amd64: true
>
>
>
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] tulip: explicity set to D0 power state during init
From: Grant Grundler @ 2010-06-01 1:00 UTC (permalink / raw)
To: Steven Walter; +Cc: grundler, kyle, netdev
In-Reply-To: <1275345283-10650-1-git-send-email-stevenrwalter@gmail.com>
On Mon, May 31, 2010 at 06:34:42PM -0400, Steven Walter wrote:
> During the first suspend the chip would refuse to enter D3. Subsequent
> suspends worked okay. During resume the chip is commanded into D0.
> Doing so during initialization fixes the initial suspend.
>
> Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
> ---
> drivers/net/tulip/tulip_core.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
> index 3810db9..bb8c0ee 100644
> --- a/drivers/net/tulip/tulip_core.c
> +++ b/drivers/net/tulip/tulip_core.c
> @@ -1380,6 +1380,13 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
> return i;
> }
>
> + /* The chip will fail to enter a low-power state later unless
> + * first explicitly commanded into D0 */
> + if (pci_set_power_state(pdev, PCI_D0)) {
> + printk (KERN_ERR PFX
My only quibble is this message really isn't "KERN_ERR" worthy.
Can you explain why you think this should be ERR and not say, KERN_NOTICE?
(I'm looking at the definitions in include/linux/kernel.h of 2.6 source tree.)
If you want to repost with KERN_NOTICE, please include my S-O-B: line above.
thanks,
grant
> + "Failed to set power state to D0\n");
> + }
> +
> irq = pdev->irq;
>
> /* alloc_etherdev ensures aligned and zeroed private structures */
> --
> 1.6.3.3
^ permalink raw reply
* Re: DDoS attack causing bad effect on conntrack searches
From: Changli Gao @ 2010-06-01 0:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: hawk, Jesper Dangaard Brouer, paulmck, Patrick McHardy,
Linux Kernel Network Hackers, Netfilter Developers
In-Reply-To: <1275340896.2478.26.camel@edumazet-laptop>
On Tue, Jun 1, 2010 at 5:21 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> I had a look at current conntrack and found the 'unconfirmed' list was
> maybe a candidate for a potential blackhole.
>
> That is, if a reader happens to hit an entry that is moved from regular
> hash table slot 'hash' to unconfirmed list,
Sorry, but I can't find where we do this things. unconfirmed list is
used to track the unconfirmed cts, whose corresponding skbs are still
in path from the first to the last netfilter hooks. As soon as the
skbs end their travel in netfilter, the corresponding cts will be
confirmed(moving ct from unconfirmed list to regular hash table).
unconfirmed list should be small, as networking receiving is in BH.
How about implementing unconfirmed list as a per cpu variable?
> reader might scan whole
> unconfirmed list to find out he is not anymore on the wanted hash chain.
>
> Problem is this unconfirmed list might be very very long in case of
> DDOS. It's really not designed to be scanned during a lookup.
>
> So I guess we should stop early if we find an unconfirmed entry ?
>
>
>
> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
> index bde095f..0573641 100644
> --- a/include/net/netfilter/nf_conntrack.h
> +++ b/include/net/netfilter/nf_conntrack.h
> @@ -298,8 +298,10 @@ extern int nf_conntrack_set_hashsize(const char *val, struct kernel_param *kp);
> extern unsigned int nf_conntrack_htable_size;
> extern unsigned int nf_conntrack_max;
>
> -#define NF_CT_STAT_INC(net, count) \
> +#define NF_CT_STAT_INC(net, count) \
> __this_cpu_inc((net)->ct.stat->count)
> +#define NF_CT_STAT_ADD(net, count, value) \
> + __this_cpu_add((net)->ct.stat->count, value)
> #define NF_CT_STAT_INC_ATOMIC(net, count) \
> do { \
> local_bh_disable(); \
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index eeeb8bc..e96d999 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -299,6 +299,7 @@ __nf_conntrack_find(struct net *net, u16 zone,
> struct nf_conntrack_tuple_hash *h;
> struct hlist_nulls_node *n;
> unsigned int hash = hash_conntrack(net, zone, tuple);
> + unsigned int cnt = 0;
>
> /* Disable BHs the entire time since we normally need to disable them
> * at least once for the stats anyway.
> @@ -309,10 +310,19 @@ begin:
> if (nf_ct_tuple_equal(tuple, &h->tuple) &&
> nf_ct_zone(nf_ct_tuplehash_to_ctrack(h)) == zone) {
> NF_CT_STAT_INC(net, found);
> + NF_CT_STAT_ADD(net, searched, cnt);
> local_bh_enable();
> return h;
> }
> - NF_CT_STAT_INC(net, searched);
> + /*
> + * If we find an unconfirmed entry, restart the lookup to
> + * avoid scanning whole unconfirmed list
> + */
> + if (unlikely(++cnt > 8 &&
> + !nf_ct_is_confirmed(nf_ct_tuplehash_to_ctrack(h)))) {
> + NF_CT_STAT_INC(net, search_restart);
> + goto begin;
> + }
> }
> /*
> * if the nulls value we got at the end of this lookup is
> @@ -323,6 +333,7 @@ begin:
> NF_CT_STAT_INC(net, search_restart);
> goto begin;
> }
> + NF_CT_STAT_ADD(net, searched, cnt);
> local_bh_enable();
>
> return NULL;
>
>
>
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH 2/2] tulip: implement wake-on-lan support
From: Steven Walter @ 2010-05-31 22:34 UTC (permalink / raw)
To: grundler, kyle, netdev; +Cc: Steven Walter
In-Reply-To: <1275345283-10650-1-git-send-email-stevenrwalter@gmail.com>
Based on a patch from http://simon.baatz.info/wol-support-for-an983b/
Tested to resume from suspend by magic packet.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
drivers/net/tulip/tulip.h | 64 +++++++++++++++++------
drivers/net/tulip/tulip_core.c | 115 +++++++++++++++++++++++++++++++++++++---
2 files changed, 156 insertions(+), 23 deletions(-)
diff --git a/drivers/net/tulip/tulip.h b/drivers/net/tulip/tulip.h
index 0afa2d4..e525875 100644
--- a/drivers/net/tulip/tulip.h
+++ b/drivers/net/tulip/tulip.h
@@ -20,6 +20,7 @@
#include <linux/types.h>
#include <linux/spinlock.h>
#include <linux/netdevice.h>
+#include <linux/ethtool.h>
#include <linux/timer.h>
#include <linux/delay.h>
#include <linux/pci.h>
@@ -51,22 +52,23 @@ struct tulip_chip_table {
enum tbl_flag {
- HAS_MII = 0x0001,
- HAS_MEDIA_TABLE = 0x0002,
- CSR12_IN_SROM = 0x0004,
- ALWAYS_CHECK_MII = 0x0008,
- HAS_ACPI = 0x0010,
- MC_HASH_ONLY = 0x0020, /* Hash-only multicast filter. */
- HAS_PNICNWAY = 0x0080,
- HAS_NWAY = 0x0040, /* Uses internal NWay xcvr. */
- HAS_INTR_MITIGATION = 0x0100,
- IS_ASIX = 0x0200,
- HAS_8023X = 0x0400,
- COMET_MAC_ADDR = 0x0800,
- HAS_PCI_MWI = 0x1000,
- HAS_PHY_IRQ = 0x2000,
- HAS_SWAPPED_SEEPROM = 0x4000,
- NEEDS_FAKE_MEDIA_TABLE = 0x8000,
+ HAS_MII = 0x00001,
+ HAS_MEDIA_TABLE = 0x00002,
+ CSR12_IN_SROM = 0x00004,
+ ALWAYS_CHECK_MII = 0x00008,
+ HAS_ACPI = 0x00010,
+ MC_HASH_ONLY = 0x00020, /* Hash-only multicast filter. */
+ HAS_PNICNWAY = 0x00080,
+ HAS_NWAY = 0x00040, /* Uses internal NWay xcvr. */
+ HAS_INTR_MITIGATION = 0x00100,
+ IS_ASIX = 0x00200,
+ HAS_8023X = 0x00400,
+ COMET_MAC_ADDR = 0x00800,
+ HAS_PCI_MWI = 0x01000,
+ HAS_PHY_IRQ = 0x02000,
+ HAS_SWAPPED_SEEPROM = 0x04000,
+ NEEDS_FAKE_MEDIA_TABLE = 0x08000,
+ COMET_PM = 0x10000,
};
@@ -120,6 +122,11 @@ enum tulip_offsets {
CSR13 = 0x68,
CSR14 = 0x70,
CSR15 = 0x78,
+ CSR18 = 0x88,
+ CSR19 = 0x8c,
+ CSR20 = 0x90,
+ CSR27 = 0xAC,
+ CSR28 = 0xB0,
};
/* register offset and bits for CFDD PCI config reg */
@@ -289,6 +296,30 @@ enum t21143_csr6_bits {
csr6_mask_100bt = (csr6_scr | csr6_pcs | csr6_hbd),
};
+enum tulip_comet_csr13_bits {
+/* The LINKOFFE and LINKONE work in conjunction with LSCE, i.e. they
+ * determine which link status transition wakes up if LSCE is
+ * enabled */
+ comet_csr13_linkoffe = (1 << 17),
+ comet_csr13_linkone = (1 << 16),
+ comet_csr13_wfre = (1 << 10),
+ comet_csr13_mpre = (1 << 9),
+ comet_csr13_lsce = (1 << 8),
+ comet_csr13_wfr = (1 << 2),
+ comet_csr13_mpr = (1 << 1),
+ comet_csr13_lsc = (1 << 0),
+};
+
+enum tulip_comet_csr18_bits {
+ comet_csr18_pmes_sticky = (1 << 24),
+ comet_csr18_pm_mode = (1 << 19),
+ comet_csr18_apm_mode = (1 << 18),
+ comet_csr18_d3a = (1 << 7)
+};
+
+enum tulip_comet_csr20_bits {
+ comet_csr20_pmes = (1 << 15),
+};
/* Keep the ring sizes a power of two for efficiency.
Making the Tx ring too large decreases the effectiveness of channel
@@ -411,6 +442,7 @@ struct tulip_private {
unsigned int csr6; /* Current CSR6 control settings. */
unsigned char eeprom[EEPROM_SIZE]; /* Serial EEPROM contents. */
void (*link_change) (struct net_device * dev, int csr5);
+ struct ethtool_wolinfo wolinfo; /* WOL settings */
u16 sym_advertise, mii_advertise; /* NWay capabilities advertised. */
u16 lpar; /* 21143 Link partner ability. */
u16 advertising[4];
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index bb8c0ee..f57fcf8 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -30,7 +30,6 @@
#include <linux/etherdevice.h>
#include <linux/delay.h>
#include <linux/mii.h>
-#include <linux/ethtool.h>
#include <linux/crc32.h>
#include <asm/unaligned.h>
#include <asm/uaccess.h>
@@ -272,6 +271,7 @@ static void tulip_down(struct net_device *dev);
static struct net_device_stats *tulip_get_stats(struct net_device *dev);
static int private_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static void set_rx_mode(struct net_device *dev);
+static void tulip_set_wolopts(struct pci_dev *pdev, u32 wolopts);
#ifdef CONFIG_NET_POLL_CONTROLLER
static void poll_tulip(struct net_device *dev);
#endif
@@ -309,6 +309,11 @@ static void tulip_up(struct net_device *dev)
/* Wake the chip from sleep/snooze mode. */
tulip_set_power_state (tp, 0, 0);
+ /* Disable all WOL events */
+ pci_enable_wake(tp->pdev, PCI_D3hot, 0);
+ pci_enable_wake(tp->pdev, PCI_D3cold, 0);
+ tulip_set_wolopts(tp->pdev, 0);
+
/* On some chip revs we must set the MII/SYM port before the reset!? */
if (tp->mii_cnt || (tp->mtable && tp->mtable->has_mii))
iowrite32(0x00040000, ioaddr + CSR6);
@@ -345,8 +350,8 @@ static void tulip_up(struct net_device *dev)
} else if (tp->flags & COMET_MAC_ADDR) {
iowrite32(addr_low, ioaddr + 0xA4);
iowrite32(addr_high, ioaddr + 0xA8);
- iowrite32(0, ioaddr + 0xAC);
- iowrite32(0, ioaddr + 0xB0);
+ iowrite32(0, ioaddr + CSR27);
+ iowrite32(0, ioaddr + CSR28);
}
} else {
/* This is set_rx_mode(), but without starting the transmitter. */
@@ -878,8 +883,35 @@ static void tulip_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *in
strcpy(info->bus_info, pci_name(np->pdev));
}
+
+static int tulip_ethtool_set_wol(struct net_device *dev,
+ struct ethtool_wolinfo *wolinfo)
+{
+ struct tulip_private *tp = netdev_priv(dev);
+
+ if (wolinfo->wolopts & (~tp->wolinfo.supported))
+ return -EOPNOTSUPP;
+
+ tp->wolinfo.wolopts = wolinfo->wolopts;
+ device_set_wakeup_enable(&tp->pdev->dev, tp->wolinfo.wolopts);
+ return 0;
+}
+
+static void tulip_ethtool_get_wol(struct net_device *dev,
+ struct ethtool_wolinfo *wolinfo)
+{
+ struct tulip_private *tp = netdev_priv(dev);
+
+ wolinfo->supported = tp->wolinfo.supported;
+ wolinfo->wolopts = tp->wolinfo.wolopts;
+ return;
+}
+
+
static const struct ethtool_ops ops = {
- .get_drvinfo = tulip_get_drvinfo
+ .get_drvinfo = tulip_get_drvinfo,
+ .set_wol = tulip_ethtool_set_wol,
+ .get_wol = tulip_ethtool_get_wol,
};
/* Provide ioctl() calls to examine the MII xcvr state. */
@@ -1092,8 +1124,8 @@ static void set_rx_mode(struct net_device *dev)
iowrite32(3, ioaddr + CSR13);
iowrite32(mc_filter[1], ioaddr + CSR14);
} else if (tp->flags & COMET_MAC_ADDR) {
- iowrite32(mc_filter[0], ioaddr + 0xAC);
- iowrite32(mc_filter[1], ioaddr + 0xB0);
+ iowrite32(mc_filter[0], ioaddr + CSR27);
+ iowrite32(mc_filter[1], ioaddr + CSR28);
}
tp->mc_filter[0] = mc_filter[0];
tp->mc_filter[1] = mc_filter[1];
@@ -1433,6 +1465,19 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
tp->chip_id = chip_idx;
tp->flags = tulip_tbl[chip_idx].flags;
+
+ tp->wolinfo.supported = 0;
+ tp->wolinfo.wolopts = 0;
+ /* COMET: Enable power management only for AN983B */
+ if (chip_idx == COMET ) {
+ u32 sig;
+ pci_read_config_dword (pdev, 0x80, &sig);
+ if (sig == 0x09811317) {
+ tp->flags |= COMET_PM;
+ tp->wolinfo.supported = WAKE_PHY | WAKE_MAGIC;
+ printk(KERN_INFO "tulip_init_one: Enabled WOL support for AN983B\n");
+ }
+ }
tp->pdev = pdev;
tp->base_addr = ioaddr;
tp->revision = pdev->revision;
@@ -1765,11 +1810,43 @@ err_out_free_netdev:
}
+/* set the registers according to the given wolopts */
+static void tulip_set_wolopts (struct pci_dev *pdev, u32 wolopts)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+ struct tulip_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->base_addr;
+
+ if (tp->flags & COMET_PM) {
+
+ unsigned int tmp;
+
+ tmp = ioread32(ioaddr + CSR18);
+ tmp &= ~(comet_csr18_pmes_sticky | comet_csr18_apm_mode | comet_csr18_d3a);
+ tmp |= comet_csr18_pm_mode;
+ iowrite32(tmp, ioaddr + CSR18);
+
+ /* Set the Wake-up Control/Status Register to the given WOL options*/
+ tmp = ioread32(ioaddr + CSR13);
+ tmp &= ~(comet_csr13_linkoffe | comet_csr13_linkone | comet_csr13_wfre | comet_csr13_lsce | comet_csr13_mpre);
+ if (wolopts & WAKE_MAGIC)
+ tmp |= comet_csr13_mpre;
+ if (wolopts & WAKE_PHY)
+ tmp |= comet_csr13_linkoffe | comet_csr13_linkone | comet_csr13_lsce;
+ /* Clear the event flags */
+ tmp |= comet_csr13_wfr | comet_csr13_mpr | comet_csr13_lsc;
+ iowrite32(tmp, ioaddr + CSR13);
+ }
+}
+
#ifdef CONFIG_PM
+
static int tulip_suspend (struct pci_dev *pdev, pm_message_t state)
{
+ pci_power_t pstate;
struct net_device *dev = pci_get_drvdata(pdev);
+ struct tulip_private *tp = netdev_priv(dev);
if (!dev)
return -EINVAL;
@@ -1785,7 +1862,16 @@ static int tulip_suspend (struct pci_dev *pdev, pm_message_t state)
save_state:
pci_save_state(pdev);
pci_disable_device(pdev);
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ pstate = pci_choose_state(pdev, state);
+ if (state.event == PM_EVENT_SUSPEND && pstate != PCI_D0) {
+ int rc;
+
+ tulip_set_wolopts(pdev, tp->wolinfo.wolopts);
+ rc = pci_enable_wake(pdev, pstate, tp->wolinfo.wolopts);
+ if (rc)
+ printk("tulip: pci_enable_wake failed (%d)\n", rc);
+ }
+ pci_set_power_state(pdev, pstate);
return 0;
}
@@ -1794,7 +1880,10 @@ save_state:
static int tulip_resume(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
+ struct tulip_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->base_addr;
int retval;
+ unsigned int tmp;
if (!dev)
return -EINVAL;
@@ -1815,6 +1904,18 @@ static int tulip_resume(struct pci_dev *pdev)
return retval;
}
+ if (tp->flags & COMET_PM) {
+ pci_enable_wake(pdev, PCI_D3hot, 0);
+ pci_enable_wake(pdev, PCI_D3cold, 0);
+
+ /* Clear the PMES flag */
+ tmp = ioread32(ioaddr + CSR20);
+ tmp |= comet_csr20_pmes;
+ iowrite32(tmp, ioaddr + CSR20);
+
+ /* Disable all wake-up events */
+ tulip_set_wolopts(pdev, 0);
+ }
netif_device_attach(dev);
if (netif_running(dev))
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] tulip: explicity set to D0 power state during init
From: Steven Walter @ 2010-05-31 22:34 UTC (permalink / raw)
To: grundler, kyle, netdev; +Cc: Steven Walter
During the first suspend the chip would refuse to enter D3. Subsequent
suspends worked okay. During resume the chip is commanded into D0.
Doing so during initialization fixes the initial suspend.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
drivers/net/tulip/tulip_core.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 3810db9..bb8c0ee 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -1380,6 +1380,13 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
return i;
}
+ /* The chip will fail to enter a low-power state later unless
+ * first explicitly commanded into D0 */
+ if (pci_set_power_state(pdev, PCI_D0)) {
+ printk (KERN_ERR PFX
+ "Failed to set power state to D0\n");
+ }
+
irq = pdev->irq;
/* alloc_etherdev ensures aligned and zeroed private structures */
--
1.6.3.3
^ permalink raw reply related
* ip route with duplicate ip addresses on two different interfaces
From: Alfred Monticello @ 2010-05-31 22:26 UTC (permalink / raw)
To: netdev
eth0 is 192.168.1.15 which is also part of my default network, with 192.168.1.1 being my default route. this works fine.
ppp0 is an outside provider, that sometimes gives me the same IP as what I have on eth0. sometimes I get a different IP for ppp0, but is still within the same subnet as eth0.
when adding the following rule, to try and make any packets seen from 192.168.1.15 on dev ppp0, it still routes out through eth0:
ip rule add from 192.168.1.15 dev ppp0 table ppp0 pref 100
ip route add default via 192.168.1.15 dev ppp0 table ppp0
what am I doing wrong that it won't let me route packets out through dev ppp0 with the same IP as eth0 or an IP within the same subnet as eth0? I suppose the easy answer is to change my default network on eth0, which does work with the following rules, as long as it doesn't match what is on eth0:
ip rule add from 192.168.1.15 table ppp0 pref 100
ip route add default via 192.168.1.15 dev ppp0 table ppp0
...but as soon as I add:
ip rule add from 192.168.1.15 dev ppp0 table ppp0 pref 100
ip route add default via 192.168.1.15 dev ppp0 table ppp0
it will not route properly. I've tried using 192.168.1.15/32, 192.168.1.0/24 but not having any luck.
Thanks in advance.
^ permalink raw reply
* Re: [PATCH] net/ipv4/tcp_input.c: fix compilation breakage when FASTRETRANS_DEBUG > 1
From: Eric Dumazet @ 2010-05-31 21:32 UTC (permalink / raw)
To: Joe Perches; +Cc: David S. Miller, netdev
In-Reply-To: <1275330055.14079.8.camel@Joe-Laptop.home>
Le lundi 31 mai 2010 à 11:20 -0700, Joe Perches a écrit :
> Commit: c720c7e8383aff1cb219bddf474ed89d850336e3 missed these.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> net/ipv4/tcp_input.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 3e6dafc..548d575 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -2639,7 +2639,7 @@ static void DBGUNDO(struct sock *sk, const char *msg)
> if (sk->sk_family == AF_INET) {
> printk(KERN_DEBUG "Undo %s %pI4/%u c%u l%u ss%u/%u p%u\n",
> msg,
> - &inet->daddr, ntohs(inet->dport),
> + &inet->inet_daddr, ntohs(inet->inet_dport),
> tp->snd_cwnd, tcp_left_out(tp),
> tp->snd_ssthresh, tp->prior_ssthresh,
> tp->packets_out);
> @@ -2649,7 +2649,7 @@ static void DBGUNDO(struct sock *sk, const char *msg)
> struct ipv6_pinfo *np = inet6_sk(sk);
> printk(KERN_DEBUG "Undo %s %pI6/%u c%u l%u ss%u/%u p%u\n",
> msg,
> - &np->daddr, ntohs(inet->dport),
> + &np->daddr, ntohs(inet->inet_dport),
> tp->snd_cwnd, tcp_left_out(tp),
> tp->snd_ssthresh, tp->prior_ssthresh,
> tp->packets_out);
>
>
^ permalink raw reply
* [PATCH net-next-2.6] br_netfilter: use skb_set_noref()
From: Eric Dumazet @ 2010-05-31 21:23 UTC (permalink / raw)
To: Stephen Hemminger, Patrick McHardy, David Miller; +Cc: bridge, netdev
Avoid dirtying bridge_parent_rtable refcount, using new dst noref
infrastructure.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/bridge/br_netfilter.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 4442099..cbea5af 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -244,8 +244,7 @@ static int br_nf_pre_routing_finish_ipv6(struct sk_buff *skb)
kfree_skb(skb);
return 0;
}
- dst_hold(&rt->u.dst);
- skb_dst_set(skb, &rt->u.dst);
+ skb_dst_set_noref(skb, &rt->u.dst);
skb->dev = nf_bridge->physindev;
nf_bridge_update_protocol(skb);
@@ -396,8 +395,7 @@ bridged_dnat:
kfree_skb(skb);
return 0;
}
- dst_hold(&rt->u.dst);
- skb_dst_set(skb, &rt->u.dst);
+ skb_dst_set_noref(skb, &rt->u.dst);
}
skb->dev = nf_bridge->physindev;
^ permalink raw reply related
* Re: DDoS attack causing bad effect on conntrack searches
From: Eric Dumazet @ 2010-05-31 21:21 UTC (permalink / raw)
To: hawk
Cc: Jesper Dangaard Brouer, paulmck, Patrick McHardy, Changli Gao,
Linux Kernel Network Hackers, Netfilter Developers
In-Reply-To: <1272292568.13192.43.camel@jdb-workstation>
Le lundi 26 avril 2010 à 16:36 +0200, Jesper Dangaard Brouer a écrit :
> On Sat, 2010-04-24 at 22:11 +0200, Eric Dumazet wrote:
> >
> > > Monday or Tuesdag I'll do a test setup with some old HP380 G4 machines to
> > > see if I can reproduce the DDoS attack senario. And see if I can get
> > > it into to lookup loop.
> >
> > Theorically a loop is very unlikely, given a single retry is very
> > unlikly too.
> >
> > Unless a cpu gets in its cache a corrupted value of a 'next' pointer.
> >
> ...
> >
> > With same hash bucket size (300.032) and max conntracks (800.000), and
> > after more than 10 hours of test, not a single lookup was restarted
> > because of a nulls with wrong value.
>
> So fare, I have to agree with you. I have now tested on the same type
> of hardware (although running a 64-bit kernel, and off net-next-2.6),
> and the result is, the same as yours, I don't see a any restarts of the
> loop. The test systems differs a bit, as it has two physical CPU and 2M
> cache (and annoyingly the system insists on using HPET as clocksource).
>
> Guess, the only explanation would be bad/sub-optimal hash distribution.
> With 40 kpps and 700.000 'searches' per second, the hash bucket list
> length "only" need to be 17.5 elements on average, where optimum is 3.
> With my pktgen DoS test, where I tried to reproduce the DoS attack, only
> see a screw of 6 elements on average.
>
>
> > I can setup a test on a 16 cpu machine, multiqueue card too.
>
> Don't think that is necessary. My theory was it was possible on slower
> single queue NIC, where one CPU is 100% busy in the conntrack search,
> and the other CPUs delete the entries (due to early drop and
> call_rcu()). But guess that note the case, and RCU works perfectly ;-)
>
> > Hmm, I forgot to say I am using net-next-2.6, not your kernel version...
>
> I also did this test using net-next-2.6, perhaps I should try the
> version I use in production...
>
>
I had a look at current conntrack and found the 'unconfirmed' list was
maybe a candidate for a potential blackhole.
That is, if a reader happens to hit an entry that is moved from regular
hash table slot 'hash' to unconfirmed list, reader might scan whole
unconfirmed list to find out he is not anymore on the wanted hash chain.
Problem is this unconfirmed list might be very very long in case of
DDOS. It's really not designed to be scanned during a lookup.
So I guess we should stop early if we find an unconfirmed entry ?
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index bde095f..0573641 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -298,8 +298,10 @@ extern int nf_conntrack_set_hashsize(const char *val, struct kernel_param *kp);
extern unsigned int nf_conntrack_htable_size;
extern unsigned int nf_conntrack_max;
-#define NF_CT_STAT_INC(net, count) \
+#define NF_CT_STAT_INC(net, count) \
__this_cpu_inc((net)->ct.stat->count)
+#define NF_CT_STAT_ADD(net, count, value) \
+ __this_cpu_add((net)->ct.stat->count, value)
#define NF_CT_STAT_INC_ATOMIC(net, count) \
do { \
local_bh_disable(); \
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index eeeb8bc..e96d999 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -299,6 +299,7 @@ __nf_conntrack_find(struct net *net, u16 zone,
struct nf_conntrack_tuple_hash *h;
struct hlist_nulls_node *n;
unsigned int hash = hash_conntrack(net, zone, tuple);
+ unsigned int cnt = 0;
/* Disable BHs the entire time since we normally need to disable them
* at least once for the stats anyway.
@@ -309,10 +310,19 @@ begin:
if (nf_ct_tuple_equal(tuple, &h->tuple) &&
nf_ct_zone(nf_ct_tuplehash_to_ctrack(h)) == zone) {
NF_CT_STAT_INC(net, found);
+ NF_CT_STAT_ADD(net, searched, cnt);
local_bh_enable();
return h;
}
- NF_CT_STAT_INC(net, searched);
+ /*
+ * If we find an unconfirmed entry, restart the lookup to
+ * avoid scanning whole unconfirmed list
+ */
+ if (unlikely(++cnt > 8 &&
+ !nf_ct_is_confirmed(nf_ct_tuplehash_to_ctrack(h)))) {
+ NF_CT_STAT_INC(net, search_restart);
+ goto begin;
+ }
}
/*
* if the nulls value we got at the end of this lookup is
@@ -323,6 +333,7 @@ begin:
NF_CT_STAT_INC(net, search_restart);
goto begin;
}
+ NF_CT_STAT_ADD(net, searched, cnt);
local_bh_enable();
return NULL;
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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 related
* Re: [Regression] [2.6.35-rc1] ssb_is_sprom_available
From: Matthew Wilcox @ 2010-05-31 20:53 UTC (permalink / raw)
To: Maciej Rutecki
Cc: linux-kernel@vger.kernel.org, linux-pci, linux-usb,
Rafael J. Wysocki, netdev, Michael Buesch
In-Reply-To: <201005312155.20602.maciej.rutecki@gmail.com>
On Mon, May 31, 2010 at 09:55:20PM +0200, Maciej Rutecki wrote:
> Last known good: 2.6.34
> Failing kernel: 2.6.35-rc1
>
> subsystem: PCI, USB(?)
>
> Kernel dies during booting on message "ssb_is_sprom_available", see picture:
> http://www.unixy.pl/maciek/download/kernel/2.6.35-rc1/gumis/DSC_0011.JPG
Um, looks like it's something to do with the Sonics Silicon Backplane,
not PCI, nor USB.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: [RFC] netfilter: WIP: Xtables idletimer target implementation
From: Luciano Coelho @ 2010-05-31 20:31 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: ext Patrick McHardy, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, Timo Teras
In-Reply-To: <1275336698.11744.37.camel@powerslave>
On Mon, 2010-05-31 at 22:11 +0200, Luciano Coelho wrote:
> What about my other proposal of creating generic timers and associating
> them with certain interfaces whenever we get a hit? I mean, to add the
> idletimer attribute to eg. /sys/class/net/wlan0/idletimer when a packet
> reaches the target from wlan0?
Let's forget about this other proposal. It's not going to be efficient
at all. It's worse than I thought at first, because we need search all
the associated_ifs in all timers whenever a packet is received.
I'll go for the other solution, which will make things much simpler and
I'll be able to remove the dependency on netdevice_notifiers
completely. :D
--
Cheers,
Luca.
^ permalink raw reply
* Re: Network QoS support in applications
From: Philip Prindeville @ 2010-05-31 20:28 UTC (permalink / raw)
To: Ben Gardiner
Cc: David Miller, dunc, kalle.valo, kaber, netdev, linux-wireless
In-Reply-To: <AANLkTindWCmxtAJU5R3ey_18_3wNUuMGc-jq_EY_itiN@mail.gmail.com>
On 5/31/10 1:30 PM, Ben Gardiner wrote:
> On Tue, May 18, 2010 at 8:04 PM, Philip A. Prindeville
> <philipp@redfish-solutions.com> wrote:
>
>> On 03/11/2010 12:29 PM, Philip A. Prindeville wrote:
>>
>>> On 03/11/2010 12:27 PM, David Miller wrote:
>>>
>>>
>>>> From: "Philip A. Prindeville"<philipp_subx@redfish-solutions.com>
>>>> Date: Thu, 11 Mar 2010 12:21:11 -0700
>>>>
>>>>
>>>>
>>>>> And yes, there will always be misbehaving users. They are a fact of
>>>>> life. That doesn't mean we should lobotomize the network. We don't
>>>>> have an authentication mechanism on ICMP Redirects or Source-Quench,
>>>>>
>>>>>
>>>> Which is why most networks block those packets from the outside.
>>>>
>>>>
>>>>
>>>>> Nor is ARP authenticated.
>>>>>
>>>>>
>>>> Which is why people control who can plug into their physical
>>>> network.
>>>>
>>>> None of the things you are saying support the idea of having
>>>> applications decide what the DSCP marking should be.
>>>>
>>>>
>>> Does "decide what the DSCP marking should be" include complying to the recommendations of RFC-4594?
>>>
>>>
>> If anyone cares, here's an update:
>>
>> I've submitted patches for QoS configuration for:
>>
>> APR/Apache (stalled);
>> Proftpd (committed);
>> Openssh (pending review);
>> Firefox/Thunderbird (reviewed and on-track for commit);
>> Cyrus (committed);
>> Sendmail (submittted and acknowledged, but not yet reviewed);
>> Curl (stalled);
>>
>> All, as per the request of the maintainers, default to either no QoS
>> markings or previous RFC-791 QoS markings if that's what they already
>> supported (Proftpd and Openssh).
>>
>> If anyone can think of anything else that needs to be supported to
>> impact a significant portion of network (or enterprise intranet)
>> traffic, please call it out.
>>
> wget [1], like curl, is used for downloads of artifacts by some build systems.
>
> [1] http://www.gnu.org/software/wget/
>
>
Ok, but I'm not sure that changes anything... what I was asking about
was other services not enumerated: not how the above services are used.
Sorry that wasn't clear.
-Philip
^ permalink raw reply
* Re: [RFC] netfilter: WIP: Xtables idletimer target implementation
From: Luciano Coelho @ 2010-05-31 20:11 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: ext Patrick McHardy, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, Timo Teras
In-Reply-To: <alpine.LSU.2.01.1005312143470.23758@obet.zrqbmnf.qr>
On Mon, 2010-05-31 at 21:51 +0200, ext Jan Engelhardt wrote:
> On Monday 2010-05-31 21:12, Luciano Coelho wrote:
> >
> >I considered this option, but then I didn't find a proper place where to
> >include the attribute in sysfs, since I cannot add it as part of the
> >interface (eg. /sys/class/net/wlan0/idletimer) as I was doing before.
>
> You couldn't have done that before either, because the interface name
> in ipt_ip may refer to an interface that does not exist at all times.
True. That's why I was using netdevice_notifiers , so that I would
monitor the interface state and add the idletimer attribute when a timer
was associated with the interface that went up. But now the rules are
not interface specific, so it cannot be done like that anymore.
> >The other option would be to make the idletimer as part of the
> >xt_IDLETIMER module object in sysfs
> >(ie. /sys/module/xt_IDLETIMER/<user_supplied_name>), but it looks out of
> >place.
>
> I like it. It follows /proc/net/xt_{hashlimit,recent}/<user_supplied_name>.
>
> >And I think adding it as /sys/class/net/idletimer is most likely
> >out of the question.
>
> It follows /sys/class/leds/...
>
>
> I'm impartial though.
Okay, so this can be done in either place. I tend to
prefer /sys/class/net/idletimer.
What about my other proposal of creating generic timers and associating
them with certain interfaces whenever we get a hit? I mean, to add the
idletimer attribute to eg. /sys/class/net/wlan0/idletimer when a packet
reaches the target from wlan0?
--
Cheers,
Luca.
^ 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