* Re: [PATCH V4] CAN: Add Flexcan CAN controller driver
From: Marc Kleine-Budde @ 2010-07-21 21:42 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1279746286-19736-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1979 bytes --]
Hello,
Marc Kleine-Budde wrote:
> This core is found on some Freescale SoCs and also some Coldfire
> SoCs. Support for Coldfire is missing though at the moment as
> they have an older revision of the core which does not have RX FIFO
> support.
>
> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
>
> Changes to prev version:
>
> * use be32_to_cpup in flexcan_start_xmit
> * add comments about stats->tx_bytes and stats->tx_bytes
> * fix FLEXCAN_ESR_ACK_ERR (set CAN_ERR_BUSERROR)
> * add forgotten FLEXCAN_ESR_CRC_ERR
> * fix inc of can.can_stats.error_warning
> * handle changes of CAN error state in NAPI
> * only send bus error in case of a real error
> * implement CAN_CTRLMODE_BERR_REPORTING
>
> The CAN_CTRLMODE_BERR_REPORTING implementation is a bit tricky, we have to
> enable the error bit interrupt, otherwise we don't get any warning or
> error passive interrupts. Regarding error bits NAPI is only scheduled if
> CAN_CTRLMODE_BERR_REPORTING is activated. The NAPI-poll() is analogue, only
> generate bus error messages of CAN_CTRLMODE_BERR_REPORTING is active.
>
> Cheers, Marc
>
> P.S.: this can be pulled, too:
>
> The following changes since commit 11fe883936980fe242869d671092a466cf1db3e3:
>
> Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 (2010-07-20 18:25:24 -0700)
>
> are available in the git repository at:
>
> ssh://git.pengutronix.de/git/mkl/linux-2.6.git for-net-next-2.6
The correct URL is:
git://git.pengutronix.de/git/mkl/linux-2.6.git for-net-next-2.6
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH net-next] drivers/net/qlge: Remove duplicated initial DUMP_ macro entries
From: David Miller @ 2010-07-21 21:43 UTC (permalink / raw)
To: joe; +Cc: ron.mercer, linux-driver, netdev, linux-kernel
In-Reply-To: <1279747141.1909.22.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Wed, 21 Jul 2010 14:19:01 -0700
> There are a couple of errors in the previous patch.
> Two of the first DUMP_<foo> entries are duplicated.
> Sorry, bad use of emacs macros...
>
> Signed-off-by: Joe Perches <joe@perches.com>
Since I didn't push your original change out yet, I'll just add this
to the original commit.
Thanks!
^ permalink raw reply
* RE: [Bugme-new] [Bug 16383] New: Regression with e1000e from 2.6.34.1 to 2.6.35-rc5
From: Tantilov, Emil S @ 2010-07-21 21:43 UTC (permalink / raw)
To: Andrew Morton, Kirsher, Jeffrey T, Brandeburg, Jesse,
Allan, Bruce W
Cc: bugzilla-daemon@bugzilla.kernel.org,
bugme-daemon@bugzilla.kernel.org, netdev@vger.kernel.org,
craig@haquarter.de
In-Reply-To: <20100721134843.f8b5b217.akpm@linux-foundation.org>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Andrew Morton
>Sent: Wednesday, July 21, 2010 1:49 PM
>To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Duyck, Alexander
>H; Waskiewicz Jr, Peter P
>Cc: bugzilla-daemon@bugzilla.kernel.org; bugme-daemon@bugzilla.kernel.org;
>netdev@vger.kernel.org; craig@haquarter.de
>Subject: Re: [Bugme-new] [Bug 16383] New: Regression with e1000e from
>2.6.34.1 to 2.6.35-rc5
>
>
>(switched to email. Please respond via emailed reply-to-all, not via the
>bugzilla web interface).
>
>On Wed, 14 Jul 2010 00:44:51 GMT
>bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=16383
>>
>> Summary: Regression with e1000e from 2.6.34.1 to 2.6.35-rc5
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 2.6.35
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: high
>> Priority: P1
>> Component: Network
>> AssignedTo: drivers_network@kernel-bugs.osdl.org
>> ReportedBy: craig@haquarter.de
>> Regression: Yes
>>
>>
>> Created an attachment (id=27094)
>> --> (https://bugzilla.kernel.org/attachment.cgi?id=27094)
>> .config
>>
>> Networking stops working with 2.6.35 (tested rc-3 and rc5).
>
>This is a post-2.6.34 regression, guys. There's some more info in
>bugzilla.
>
>> # egrep "(e1000|eth)" dmesg-2.6.34.1
>> e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
>> e1000e: Copyright (c) 1999 - 2009 Intel Corporation.
>> e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
>> e1000e 0000:00:19.0: setting latency timer to 64
>> 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 5c:ff:35:02:2d:a9
>> 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
>> 0000:00:19.0: eth0: MAC: 9, PHY: 10, PBA No: a002ff-0ff
>> e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
>>
>> # egrep "(e1000|eth)" dmesg-2.6.35-rc5
>> e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k4
>> e1000e: Copyright (c) 1999 - 2009 Intel Corporation.
>> e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
>> e1000e 0000:00:19.0: setting latency timer to 64
>> e1000e 0000:00:19.0: (unregistered net_device): Failed to initialize MSI
>> interrupts. Falling back to legacy interrupts.
>> e1000e 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1)
>5c:ff:35:02:2d:a9
>> e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
>> e1000e 0000:00:19.0: eth0: MAC: 9, PHY: 10, PBA No: a002ff-0ff
>> e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
>>
>> I hadn't set CONFIG_PCI_MSI but enabling it on 2.6.35-rc5 made no
>difference.
On what HW is this issue seen? Please provide the output of:
lspci -vvv
ethtool -e
ethtool -S
kernel config.
Thanks,
Emil
^ permalink raw reply
* Re: mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
From: mark gross @ 2010-07-21 22:09 UTC (permalink / raw)
To: Andrew Morton
Cc: Rafael J. Wysocki, Valdis.Kletnieks, mark gross, e1000-devel,
netdev, linux-kernel, James Bottomley, Thomas Gleixner,
David S. Miller
In-Reply-To: <20100720140751.71ee83a8.akpm@linux-foundation.org>
On Tue, Jul 20, 2010 at 02:07:51PM -0700, Andrew Morton wrote:
> On Tue, 20 Jul 2010 16:35:25 -0400
> Valdis.Kletnieks@vt.edu wrote:
>
> > On Mon, 19 Jul 2010 16:38:09 PDT, akpm@linux-foundation.org said:
> > > The mm-of-the-moment snapshot 2010-07-19-16-37 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > Throws a warning at boot:
> >
> > [ 1.786060] WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x28/0x54()
> > [ 1.786088] Hardware name: Latitude E6500
> > [ 1.787045] pm_qos_update_request() called for unknown object
> > [ 1.787966] Modules linked in:
> > [ 1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
> > [ 1.790035] Call Trace:
> > [ 1.791121] [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
> > [ 1.792205] [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
> > [ 1.793279] [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
> > [ 1.794347] [<ffffffff8134889e>] e1000_configure+0x421/0x459
> > [ 1.795393] [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
> > [ 1.796436] [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
> > [ 1.797491] [<ffffffff8145f948>] __dev_open+0xae/0xe2
> > [ 1.798547] [<ffffffff8145f997>] dev_open+0x1b/0x49
> > [ 1.799612] [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
> > [ 1.800685] [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
> > [ 1.801744] [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
> > [ 1.802793] [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
> > [ 1.803845] [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
> > [ 1.804885] [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
> > [ 1.805915] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> > [ 1.806937] [<ffffffff81590e00>] ? restore_args+0x0/0x30
> > [ 1.807955] [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
> > [ 1.808958] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> > [ 1.809958] ---[ end trace 84b562a00a60539e ]---
> >
> > Looks like a repeat of something I reported against -mmotm 2010-05-11, though a
> > WARNING rather than an outright crash - the traceback is pretty much identical.
> > I have *no* idea why -rc3-mmotm0701 doesn't whinge similarly.
> >
>
> I don't recall you reporting that, sorry.
>
> The warning was added by
>
> : commit 82f682514a5df89ffb3890627eebf0897b7a84ec
> : Author: James Bottomley <James.Bottomley@suse.de>
> : AuthorDate: Mon Jul 5 22:53:06 2010 +0200
> : Commit: Rafael J. Wysocki <rjw@sisk.pl>
> : CommitDate: Mon Jul 19 02:00:34 2010 +0200
> :
> : pm_qos: Get rid of the allocation in pm_qos_add_request()
>
>
> It's a pretty crappy warning too. Neither the warning nor the code
> comments provide developers with any hint as to what they have done
> wrong, nor what they must do to fix things. And the patch changelog
> doesn't mention the new warnings *at all*.
Sorry about that. Its my fault, but I thought I had stronger language
in the original warning text.
The warning is for pm_qos users that are attempting to change a request
that isn't even in the list of request. It was a silent failure in the
original code. The result of the silent fail is that the request is not
changed as assumed by the caller.
> So one must assume that the people who stuck this thing in the tree
> have volunteered to fix e1000e. Let's cc 'em.
I'll put a 1000e patch together at the airport, but I wont be able to
test it until tuesday.
--mgross
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] Re: mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
From: mark gross @ 2010-07-21 22:12 UTC (permalink / raw)
To: Florian Mickler
Cc: Andrew Morton, Valdis.Kletnieks, Rafael J. Wysocki, mark gross,
e1000-devel, netdev, linux-kernel, James Bottomley,
Thomas Gleixner, David S. Miller
In-Reply-To: <20100721091200.40c43158@schatten.dmk.lab>
On Wed, Jul 21, 2010 at 09:12:00AM +0200, Florian Mickler wrote:
> On Tue, 20 Jul 2010 14:07:51 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Tue, 20 Jul 2010 16:35:25 -0400
> > Valdis.Kletnieks@vt.edu wrote:
> >
> > > On Mon, 19 Jul 2010 16:38:09 PDT, akpm@linux-foundation.org said:
> > > > The mm-of-the-moment snapshot 2010-07-19-16-37 has been uploaded to
> > > >
> > > > http://userweb.kernel.org/~akpm/mmotm/
> > >
> > > Throws a warning at boot:
> > >
> > > [ 1.786060] WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x28/0x54()
> > > [ 1.786088] Hardware name: Latitude E6500
> > > [ 1.787045] pm_qos_update_request() called for unknown object
> > > [ 1.787966] Modules linked in:
> > > [ 1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
> > > [ 1.790035] Call Trace:
> > > [ 1.791121] [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
> > > [ 1.792205] [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
> > > [ 1.793279] [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
> > > [ 1.794347] [<ffffffff8134889e>] e1000_configure+0x421/0x459
> > > [ 1.795393] [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
> > > [ 1.796436] [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
> > > [ 1.797491] [<ffffffff8145f948>] __dev_open+0xae/0xe2
> > > [ 1.798547] [<ffffffff8145f997>] dev_open+0x1b/0x49
> > > [ 1.799612] [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
> > > [ 1.800685] [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
> > > [ 1.801744] [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
> > > [ 1.802793] [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
> > > [ 1.803845] [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
> > > [ 1.804885] [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
> > > [ 1.805915] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> > > [ 1.806937] [<ffffffff81590e00>] ? restore_args+0x0/0x30
> > > [ 1.807955] [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
> > > [ 1.808958] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> > > [ 1.809958] ---[ end trace 84b562a00a60539e ]---
> > >
> > > Looks like a repeat of something I reported against -mmotm 2010-05-11, though a
> > > WARNING rather than an outright crash - the traceback is pretty much identical.
> > > I have *no* idea why -rc3-mmotm0701 doesn't whinge similarly.
> > >
> >
> > I don't recall you reporting that, sorry.
> >
> > The warning was added by
> >
> > : commit 82f682514a5df89ffb3890627eebf0897b7a84ec
> > : Author: James Bottomley <James.Bottomley@suse.de>
> > : AuthorDate: Mon Jul 5 22:53:06 2010 +0200
> > : Commit: Rafael J. Wysocki <rjw@sisk.pl>
> > : CommitDate: Mon Jul 19 02:00:34 2010 +0200
> > :
> > : pm_qos: Get rid of the allocation in pm_qos_add_request()
> >
> >
> > It's a pretty crappy warning too. Neither the warning nor the code
> > comments provide developers with any hint as to what they have done
> > wrong, nor what they must do to fix things. And the patch changelog
> > doesn't mention the new warnings *at all*.
> >
> > So one must assume that the people who stuck this thing in the tree
> > have volunteered to fix e1000e. Let's cc 'em.
> >
>
> e1000 calls update_request before registering said request with pm_qos.
> This was silently ignored before but now emits a warning. The warning
> is sound, because it means, that the constraint-request didn't take
> effect.
>
> The right thing is probably to register the request before
> calling update_request.
>
> Attached patch moves the registering from e1000_up to e1000_open and
> the unregistering from e1000_down to e1000_close.
> It is only compile-tested as I don't have the hardware.
>
> Cheers,
> Flo
>
> p.s.: sorry if this get's mangled or is wrongly formatted, i'm just using
> the "insert file" option of my mailclient and crossing my fingers...
>
>
> From 693c71b911ff0845c872261d5704a1d40960722d Mon Sep 17 00:00:00 2001
> From: Florian Mickler <florian@mickler.org>
> Date: Wed, 21 Jul 2010 08:44:21 +0200
> Subject: [PATCH] e1000e: register pm_qos request on hardware activation
>
> The pm_qos_add_request call has to register the pm_qos request with the pm_qos
> susbsystem before first use of the pm_qos request via
> pm_qos_update_request.
>
> As pm_qos changed to use plists there is no benefit in registering and
> unregistering the pm_qos request on ifup/ifdown and thus we move the
> registering into e1000_open and the unregistering in e1000_close.
>
> This fixes the following warning:
>
> [ 1.786060] WARNING: at kernel/pm_qos_params.c:264
> pm_qos_update_request+0x28/0x54()
> [ 1.786088] Hardware name: Latitude E6500
> [ 1.787045] pm_qos_update_request() called for unknown object
> [ 1.787966] Modules linked in:
> [ 1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
> [ 1.790035] Call Trace:
> [ 1.791121] [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
> [ 1.792205] [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
> [ 1.793279] [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
> [ 1.794347] [<ffffffff8134889e>] e1000_configure+0x421/0x459
> [ 1.795393] [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
> [ 1.796436] [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
> [ 1.797491] [<ffffffff8145f948>] __dev_open+0xae/0xe2
> [ 1.798547] [<ffffffff8145f997>] dev_open+0x1b/0x49
> [ 1.799612] [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
> [ 1.800685] [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
> [ 1.801744] [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
> [ 1.802793] [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
> [ 1.803845] [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
> [ 1.804885] [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
> [ 1.805915] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> [ 1.806937] [<ffffffff81590e00>] ? restore_args+0x0/0x30
> [ 1.807955] [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
> [ 1.808958] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> [ 1.809958] ---[ end trace 84b562a00a60539e ]---
>
> Signed-off-by: Florian Mickler <florian@mickler.org>
> ---
> drivers/net/e1000e/netdev.c | 18 +++++++++---------
> 1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index 8ba366a..1bd9054 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -3218,12 +3218,6 @@ int e1000e_up(struct e1000_adapter *adapter)
> {
> struct e1000_hw *hw = &adapter->hw;
>
> - /* DMA latency requirement to workaround early-receive/jumbo issue */
> - if (adapter->flags & FLAG_HAS_ERT)
> - pm_qos_add_request(&adapter->netdev->pm_qos_req,
> - PM_QOS_CPU_DMA_LATENCY,
> - PM_QOS_DEFAULT_VALUE);
> -
> /* hardware has been reset, we need to reload some things */
> e1000_configure(adapter);
>
> @@ -3287,9 +3281,6 @@ void e1000e_down(struct e1000_adapter *adapter)
> e1000_clean_tx_ring(adapter);
> e1000_clean_rx_ring(adapter);
>
> - if (adapter->flags & FLAG_HAS_ERT)
> - pm_qos_remove_request(&adapter->netdev->pm_qos_req);
> -
> /*
> * TODO: for power management, we could drop the link and
> * pci_disable_device here.
> @@ -3524,6 +3515,12 @@ static int e1000_open(struct net_device *netdev)
> E1000_MNG_DHCP_COOKIE_STATUS_VLAN))
> e1000_update_mng_vlan(adapter);
>
> + /* DMA latency requirement to workaround early-receive/jumbo issue */
> + if (adapter->flags & FLAG_HAS_ERT)
> + pm_qos_add_request(&adapter->netdev->pm_qos_req,
> + PM_QOS_CPU_DMA_LATENCY,
> + PM_QOS_DEFAULT_VALUE);
> +
> /*
> * before we allocate an interrupt, we must be ready to handle it.
> * Setting DEBUG_SHIRQ in the kernel makes it fire an interrupt
> @@ -3628,6 +3625,9 @@ static int e1000_close(struct net_device *netdev)
> if (adapter->flags & FLAG_HAS_AMT)
> e1000_release_hw_control(adapter);
>
> + if (adapter->flags & FLAG_HAS_ERT)
> + pm_qos_remove_request(&adapter->netdev->pm_qos_req);
> +
> pm_runtime_put_sync(&pdev->dev);
>
> return 0;
> --
> 1.7.1.1
>
wow! thanks! I'll test this when I get back next tuesday.
--mgross
^ permalink raw reply
* [PATCH net-next-2.6 1/2] bonding: change test for presence of VLANs
From: Jay Vosburgh @ 2010-07-21 22:14 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Pedro Garcia, Patrick McHardy
After commit:
commit ad1afb00393915a51c21b1ae8704562bf036855f
Author: Pedro Garcia <pedro.netdev@dondevamos.com>
Date: Sun Jul 18 15:38:44 2010 -0700
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
it is now regular practice for a VLAN "add vid" for VLAN 0 to
arrive prior to any VLAN registration or creation of a vlan_group.
This patch updates the bonding code that tests for the presence
of VLANs configured above bonding. The new logic tests for bond->vlgrp
to determine if a registration has occured, instead of testing that
bonding's internal vlan_list is empty.
The old code would panic when vlan_list was not empty, but
vlgrp was still NULL (because only an "add vid" for VLAN 0 had occured).
Bonding still adds VLAN 0 to its internal list so that 802.1p
frames are handled correctly on transmit when non-VLAN accelerated
slaves are members of the bond. The test against bond->vlan_list
remains in bond_dev_queue_xmit for this reason.
Modification to the bond->vlgrp now occurs under lock (in
addition to RTNL), because not all inspections of it occur under RTNL.
Additionally, because 8021q will never issue a "kill vid" for
VLAN 0, there is now logic in bond_uninit to release any remaining
entries from vlan_list.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Cc: Pedro Garcia <pedro.netdev@dondevamos.com>
Cc: Patrick McHardy <kaber@trash.net>
---
drivers/net/bonding/bond_alb.c | 4 ++--
drivers/net/bonding/bond_main.c | 30 +++++++++++++++++++++++-------
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 3662d6e..e3b35d0 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -682,7 +682,7 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
client_info->ntt = 0;
}
- if (!list_empty(&bond->vlan_list)) {
+ if (bond->vlgrp) {
if (!vlan_get_tag(skb, &client_info->vlan_id))
client_info->tag = 1;
}
@@ -904,7 +904,7 @@ static void alb_send_learning_packets(struct slave *slave, u8 mac_addr[])
skb->priority = TC_PRIO_CONTROL;
skb->dev = slave->dev;
- if (!list_empty(&bond->vlan_list)) {
+ if (bond->vlgrp) {
struct vlan_entry *vlan;
vlan = bond_next_vlan(bond,
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 20f45cb..f3b01ce 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -424,6 +424,7 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb,
{
unsigned short uninitialized_var(vlan_id);
+ /* Test vlan_list not vlgrp to catch and handle 802.1p tags */
if (!list_empty(&bond->vlan_list) &&
!(slave_dev->features & NETIF_F_HW_VLAN_TX) &&
vlan_get_tag(skb, &vlan_id) == 0) {
@@ -487,7 +488,9 @@ static void bond_vlan_rx_register(struct net_device *bond_dev,
struct slave *slave;
int i;
+ write_lock(&bond->lock);
bond->vlgrp = grp;
+ write_unlock(&bond->lock);
bond_for_each_slave(bond, slave, i) {
struct net_device *slave_dev = slave->dev;
@@ -569,7 +572,7 @@ static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *sla
write_lock_bh(&bond->lock);
- if (list_empty(&bond->vlan_list))
+ if (!bond->vlgrp)
goto out;
if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
@@ -596,7 +599,7 @@ static void bond_del_vlans_from_slave(struct bonding *bond,
write_lock_bh(&bond->lock);
- if (list_empty(&bond->vlan_list))
+ if (!bond->vlgrp)
goto out;
if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
@@ -604,6 +607,8 @@ static void bond_del_vlans_from_slave(struct bonding *bond,
goto unreg;
list_for_each_entry(vlan, &bond->vlan_list, vlan_list) {
+ if (!vlan->vlan_id)
+ continue;
/* Save and then restore vlan_dev in the grp array,
* since the slave's driver might clear it.
*/
@@ -1443,7 +1448,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
/* no need to lock since we're protected by rtnl_lock */
if (slave_dev->features & NETIF_F_VLAN_CHALLENGED) {
pr_debug("%s: NETIF_F_VLAN_CHALLENGED\n", slave_dev->name);
- if (!list_empty(&bond->vlan_list)) {
+ if (bond->vlgrp) {
pr_err("%s: Error: cannot enslave VLAN challenged slave %s on VLAN enabled bond %s\n",
bond_dev->name, slave_dev->name, bond_dev->name);
return -EPERM;
@@ -1942,7 +1947,7 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
*/
memset(bond_dev->dev_addr, 0, bond_dev->addr_len);
- if (list_empty(&bond->vlan_list)) {
+ if (!bond->vlgrp) {
bond_dev->features |= NETIF_F_VLAN_CHALLENGED;
} else {
pr_warning("%s: Warning: clearing HW address of %s while it still has VLANs.\n",
@@ -2134,9 +2139,9 @@ static int bond_release_all(struct net_device *bond_dev)
*/
memset(bond_dev->dev_addr, 0, bond_dev->addr_len);
- if (list_empty(&bond->vlan_list))
+ if (!bond->vlgrp) {
bond_dev->features |= NETIF_F_VLAN_CHALLENGED;
- else {
+ } else {
pr_warning("%s: Warning: clearing HW address of %s while it still has VLANs.\n",
bond_dev->name, bond_dev->name);
pr_warning("%s: When re-adding slaves, make sure the bond's HW address matches its VLANs'.\n",
@@ -2569,7 +2574,7 @@ static void bond_arp_send_all(struct bonding *bond, struct slave *slave)
if (!targets[i])
break;
pr_debug("basa: target %x\n", targets[i]);
- if (list_empty(&bond->vlan_list)) {
+ if (!bond->vlgrp) {
pr_debug("basa: empty vlan: arp_send\n");
bond_arp_send(slave->dev, ARPOP_REQUEST, targets[i],
bond->master_ip, 0);
@@ -2658,6 +2663,9 @@ static void bond_send_gratuitous_arp(struct bonding *bond)
bond->master_ip, 0);
}
+ if (!bond->vlgrp)
+ return;
+
list_for_each_entry(vlan, &bond->vlan_list, vlan_list) {
vlan_dev = vlan_group_get_device(bond->vlgrp, vlan->vlan_id);
if (vlan->vlan_ip) {
@@ -3590,6 +3598,8 @@ static int bond_inetaddr_event(struct notifier_block *this, unsigned long event,
}
list_for_each_entry(vlan, &bond->vlan_list, vlan_list) {
+ if (!bond->vlgrp)
+ continue;
vlan_dev = vlan_group_get_device(bond->vlgrp, vlan->vlan_id);
if (vlan_dev == event_dev) {
switch (event) {
@@ -4686,6 +4696,7 @@ static void bond_work_cancel_all(struct bonding *bond)
static void bond_uninit(struct net_device *bond_dev)
{
struct bonding *bond = netdev_priv(bond_dev);
+ struct vlan_entry *vlan, *tmp;
bond_netpoll_cleanup(bond_dev);
@@ -4699,6 +4710,11 @@ static void bond_uninit(struct net_device *bond_dev)
bond_remove_proc_entry(bond);
__hw_addr_flush(&bond->mc_list);
+
+ list_for_each_entry_safe(vlan, tmp, &bond->vlan_list, vlan_list) {
+ list_del(&vlan->vlan_list);
+ kfree(vlan);
+ }
}
/*------------------------- Module initialization ---------------------------*/
--
1.6.0.2
^ permalink raw reply related
* [PATCH net-next-2.6 2/2] bonding: don't lock when copying/clearing VLAN list on slave
From: Jay Vosburgh @ 2010-07-21 22:14 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Michael Chan
In-Reply-To: <1279750488-32611-1-git-send-email-fubar@us.ibm.com>
When copying VLAN information to or removing from a slave
during slave addition or removal, the bonding code currently holds
the bond->lock for write to prevent concurrent modification of the
vlan_list / vlgrp.
This is unnecessary, as all of these operations occur under
RTNL. Holding the bond->lock also caused might_sleep issues for
some drivers' ndo_vlan_* functions. This patch removes the extra
locking.
Problem reported by Michael Chan <mchan@broadcom.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Cc: Michael Chan <mchan@broadcom.com>
---
drivers/net/bonding/bond_main.c | 16 +++-------------
1 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index f3b01ce..2cc4cfc 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -570,10 +570,8 @@ static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *sla
struct vlan_entry *vlan;
const struct net_device_ops *slave_ops = slave_dev->netdev_ops;
- write_lock_bh(&bond->lock);
-
if (!bond->vlgrp)
- goto out;
+ return;
if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
slave_ops->ndo_vlan_rx_register)
@@ -581,13 +579,10 @@ static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *sla
if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
!(slave_ops->ndo_vlan_rx_add_vid))
- goto out;
+ return;
list_for_each_entry(vlan, &bond->vlan_list, vlan_list)
slave_ops->ndo_vlan_rx_add_vid(slave_dev, vlan->vlan_id);
-
-out:
- write_unlock_bh(&bond->lock);
}
static void bond_del_vlans_from_slave(struct bonding *bond,
@@ -597,10 +592,8 @@ static void bond_del_vlans_from_slave(struct bonding *bond,
struct vlan_entry *vlan;
struct net_device *vlan_dev;
- write_lock_bh(&bond->lock);
-
if (!bond->vlgrp)
- goto out;
+ return;
if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
!(slave_ops->ndo_vlan_rx_kill_vid))
@@ -621,9 +614,6 @@ unreg:
if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
slave_ops->ndo_vlan_rx_register)
slave_ops->ndo_vlan_rx_register(slave_dev, NULL);
-
-out:
- write_unlock_bh(&bond->lock);
}
/*------------------------------- Link status -------------------------------*/
--
1.6.0.2
^ permalink raw reply related
* mirred, redirect action vs. dev refcount issue
From: Stephen Hemminger @ 2010-07-21 23:24 UTC (permalink / raw)
To: jamal, David Miller; +Cc: netdev
Both the mirrored and redirect TC actions, hold a pointer to the
target device and increment the refcount. The problem is that administrator
may want to remove the target device (for example ifb0) and this will
cause the kernel to get in the "can't delete ifb0 with references" state.
Fixing this isn't trivial but I think that the best way would be to have
the action API have a device notifier and walk the actions and call a new
hook (device_event) similar to existing walk. The device_event in the
action ops can then redirect any mirror/redirect that are going to a dead
device off to bit bucket.
Alternatively, the mirror/redirect could just use ifindex which is
a soft reference, so if device is removed, they just drop.
Lazy me favors the later.
^ permalink raw reply
* Re: mirred, redirect action vs. dev refcount issue
From: David Miller @ 2010-07-21 23:39 UTC (permalink / raw)
To: shemminger; +Cc: hadi, netdev
In-Reply-To: <20100721162426.5aa4b646@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 21 Jul 2010 16:24:26 -0700
> Alternatively, the mirror/redirect could just use ifindex which is
> a soft reference, so if device is removed, they just drop.
>
> Lazy me favors the later.
If it is the action rule holding onto the device, it should have
an appropriate netdevice notifier handler.
If it's a transient reference on receive, it should be transient
and released eventually.
^ permalink raw reply
* Re: mirred, redirect action vs. dev refcount issue
From: Stephen Hemminger @ 2010-07-21 23:52 UTC (permalink / raw)
To: David Miller; +Cc: hadi, netdev
In-Reply-To: <20100721.163955.12041610.davem@davemloft.net>
On Wed, 21 Jul 2010 16:39:55 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 21 Jul 2010 16:24:26 -0700
>
> > Alternatively, the mirror/redirect could just use ifindex which is
> > a soft reference, so if device is removed, they just drop.
> >
> > Lazy me favors the later.
>
> If it is the action rule holding onto the device, it should have
> an appropriate netdevice notifier handler.
There is no notifier there, and the module doesn't keep track of
list of filters. So that is why it has to be done at act api level.
> If it's a transient reference on receive, it should be transient
> and released eventually.
Kernel doesn't keep transient reference on receive any more.
^ permalink raw reply
* Re: mirred, redirect action vs. dev refcount issue
From: David Miller @ 2010-07-21 23:58 UTC (permalink / raw)
To: shemminger; +Cc: hadi, netdev
In-Reply-To: <20100721165247.6d1dd879@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 21 Jul 2010 16:52:47 -0700
> On Wed, 21 Jul 2010 16:39:55 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
>> If it is the action rule holding onto the device, it should have
>> an appropriate netdevice notifier handler.
>
> There is no notifier there, and the module doesn't keep track of
> list of filters. So that is why it has to be done at act api level.
Any rule, or route, or whatever that makes references to devices must
transparently accomodate the requested removal or downing of a device.
There is no way around this.
So either the action code needs to keep track of it's table entries on
some global list that can be traversed at notifier time, or we go with
the ifindex thing.
Whether the ifindex or the global list + delete scheme is better is a
topic for discussion. Since from the user's perspective it is unclear
which semantic is less surprising, entries disappearing or suddenly
stop working (or start applying to a different device which has taken
a previous one's ifindex!).
^ permalink raw reply
* Re: mirred, redirect action vs. dev refcount issue
From: Stephen Hemminger @ 2010-07-22 0:00 UTC (permalink / raw)
To: David Miller; +Cc: hadi, netdev
In-Reply-To: <20100721.165802.111593910.davem@davemloft.net>
On Wed, 21 Jul 2010 16:58:02 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 21 Jul 2010 16:52:47 -0700
>
> > On Wed, 21 Jul 2010 16:39:55 -0700 (PDT)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> If it is the action rule holding onto the device, it should have
> >> an appropriate netdevice notifier handler.
> >
> > There is no notifier there, and the module doesn't keep track of
> > list of filters. So that is why it has to be done at act api level.
>
> Any rule, or route, or whatever that makes references to devices must
> transparently accomodate the requested removal or downing of a device.
>
> There is no way around this.
>
> So either the action code needs to keep track of it's table entries on
> some global list that can be traversed at notifier time, or we go with
> the ifindex thing.
>
> Whether the ifindex or the global list + delete scheme is better is a
> topic for discussion. Since from the user's perspective it is unclear
> which semantic is less surprising, entries disappearing or suddenly
> stop working (or start applying to a different device which has taken
> a previous one's ifindex!).
ifindex is unique (until integer wraps) so that soft reference
works.
--
^ permalink raw reply
* Re: [Bugme-new] [Bug 16383] New: Regression with e1000e from 2.6.34.1 to 2.6.35-rc5
From: Craig @ 2010-07-22 0:06 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: Andrew Morton, Kirsher, Jeffrey T, Brandeburg, Jesse,
Allan, Bruce W, Duyck, Alexander H, Waskiewicz Jr, Peter P,
bugzilla-daemon@bugzilla.kernel.org,
bugme-daemon@bugzilla.kernel.org, netdev@vger.kernel.org
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FFE8449AA@rrsmsx501.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
Hi,
> On what HW is this issue seen? Please provide the output of:
Hardware (it was already on bugzilla as pointed out by Andrew): Lenovo
ThinkPad X201, model 3626W16 (i5)
> lspci -vvv
> ethtool -e
> ethtool -S
see attached files
> kernel config.
https://bugzilla.kernel.org/attachment.cgi?id=27094
Best regards,
Stefan Behte
[-- Attachment #2: ethtool-e --]
[-- Type: text/plain, Size: 14622 bytes --]
Offset Values
------ ------
0x0000 5c ff 35 02 2d a9 00 08 ff ff c1 00 ff ff ff ff
0x0010 02 a0 ff ff c3 10 53 21 aa 17 ea 10 00 00 00 00
0x0020 02 07 00 00 00 00 05 a5 28 00 00 18 00 00 00 0c
0x0030 64 2a 40 0b 43 08 13 00 ea 10 ad ba ea 10 eb 10
0x0040 ad ba ad ba ad ba ad ba 00 80 90 80 00 4e 00 00
0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff
0x0060 00 01 00 40 33 13 07 40 ff ff ff ff ff ff ff ff
0x0070 ff ff ff ff ff ff ff ff ff ff 00 01 ff ff 8b 42
0x0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff
0x00a0 23 88 30 00 18 00 31 00 24 88 30 00 16 00 31 00
0x00b0 25 88 30 00 1c 00 31 00 8c 88 30 00 07 00 31 00
0x00c0 8d 88 30 00 07 00 31 00 8e 88 30 00 07 00 31 00
0x00d0 27 88 30 00 01 00 31 00 35 88 30 00 01 00 31 00
0x00e0 34 88 30 00 01 00 31 00 33 88 30 00 02 00 31 00
0x00f0 40 60 1f 00 04 d0 11 00 07 01 12 00 00 00 1f 00
0x0100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0110 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0120 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0150 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0170 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0180 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0190 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0200 69 53 84 03 01 00 00 00 00 00 00 00 00 00 00 00
0x0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0320 00 00 00 00 00 00 00 00 03 3d 00 00 00 00 00 00
0x0330 00 00 00 00 00 00 00 00 00 00 00 00 bc 0c 00 00
0x0340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x03a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x03b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x03c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x03d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x03e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x03f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0510 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0520 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0530 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0550 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0570 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0580 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff
0x0590 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0600 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0610 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0620 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0630 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0640 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0650 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0660 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0670 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0680 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0690 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0700 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0710 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0720 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0730 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0740 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0750 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0760 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0770 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0780 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0790 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0800 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0810 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0820 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0830 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0840 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0850 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0860 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0870 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0880 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0890 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0900 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0910 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0920 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0930 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0940 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0950 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0960 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0970 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0980 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0aa0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ab0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ac0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ad0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ae0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0af0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ba0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0be0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bf0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ca0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ce0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cf0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0da0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0db0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0dc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0dd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0de0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0df0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ea0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0eb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ec0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ed0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ee0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ef0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fa0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[-- Attachment #3: ethtool-S --]
[-- Type: text/plain, Size: 1220 bytes --]
NIC statistics:
rx_packets: 152716
tx_packets: 42897
rx_bytes: 218463656
tx_bytes: 3179209
rx_broadcast: 16
tx_broadcast: 21
rx_multicast: 290
tx_multicast: 0
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 290
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 5
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 218463656
rx_csum_offload_good: 152393
rx_csum_offload_errors: 0
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 4
dropped_smbus: 0
rx_dma_failed: 0
tx_dma_failed: 0
[-- Attachment #4: lspci-vvv --]
[-- Type: text/plain, Size: 22436 bytes --]
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
Subsystem: Lenovo Device 2193
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: [e0] Vendor Specific Information <?>
Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 215a
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 16
Region 0: Memory at f2000000 (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: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
Subsystem: Lenovo Device 215f
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 f2727800 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 06)
Subsystem: Lenovo Device 2153
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 20
Region 0: Memory at f2500000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f2525000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 1820 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) (prog-if 20 [EHCI])
Subsystem: Lenovo Device 2163
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 f2728000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
Subsystem: Lenovo Device 215e
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 f2520000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Virtual Channel <?>
Capabilities: [130] Root Complex Link <?>
Kernel driver in use: HDA Intel
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06) (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=0d, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
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: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
Slot # 0, PowerLimit 10.000000; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Lenovo Device 2164
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 (rev 06) (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: f0000000-f1ffffff
Prefetchable memory behind bridge: 00000000f2800000-00000000f28fffff
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: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surpise+
Slot # 3, PowerLimit 10.000000; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Lenovo Device 2164
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 5 (rev 06) (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: 0000f000-00000fff
Memory behind bridge: f2400000-f24fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
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: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #5, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
Slot # 4, PowerLimit 10.000000; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Lenovo Device 2164
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) (prog-if 20 [EHCI])
Subsystem: Lenovo Device 2163
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 f2728400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a6) (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=0e, subordinate=0e, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
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: [50] Subsystem: Lenovo Device 2165
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 06)
Subsystem: Lenovo Device 2166
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: [e0] Vendor Specific Information <?>
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 06) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo Device 2168
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 16
Region 0: I/O ports at 1860 [size=8]
Region 1: I/O ports at 1814 [size=4]
Region 2: I/O ports at 1818 [size=8]
Region 3: I/O ports at 1810 [size=4]
Region 4: I/O ports at 1840 [size=32]
Region 5: Memory at f2727000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA <?>
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
Subsystem: Lenovo Device 2167
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 11
Region 0: Memory at f2728800 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 1880 [size=32]
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 06)
Subsystem: Lenovo Device 2190
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-
Interrupt: pin D routed to IRQ 11
Region 0: Memory at f2526000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
02:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
Subsystem: Intel Corporation Centrino Ultimate-N 6300 3x3 AGN
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 16
Region 0: Memory at f2400000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <32us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140] Device Serial Number 00-24-d7-ff-ff-0a-45-68
Kernel driver in use: iwlagn
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02)
Subsystem: Lenovo Device 2196
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
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02)
Subsystem: Lenovo Device 2196
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
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
Subsystem: Lenovo Device 2196
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
ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02)
Subsystem: Lenovo Device 2196
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
ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
Subsystem: Lenovo Device 2196
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
ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
Subsystem: Lenovo Device 2196
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
^ permalink raw reply
* (unknown),
From: Mr Tomo Sand @ 2010-07-22 0:19 UTC (permalink / raw)
I am Tomo Sand, I have a business deal of $40 million for you.
^ permalink raw reply
* (unknown),
From: Mr Tomo Sand @ 2010-07-22 0:43 UTC (permalink / raw)
I am Tomo Sand, I have a business deal of $40 million for you.
^ permalink raw reply
* Re: [patch v2.6 4/4] libxt_ipvs: user-space lib for netfilter matcher xt_ipvs
From: Simon Horman @ 2010-07-22 1:38 UTC (permalink / raw)
To: Jan Engelhardt
Cc: lvs-devel, netdev, linux-kernel, netfilter, netfilter-devel,
Malcolm Turnbull, Wensong Zhang, Julius Volz, Patrick McHardy,
David S. Miller, Hannes Eder
In-Reply-To: <20100721134102.GA21188@verge.net.au>
On Wed, Jul 21, 2010 at 10:41:03PM +0900, Simon Horman wrote:
> On Wed, Jul 21, 2010 at 03:28:16PM +0200, Jan Engelhardt wrote:
> >
> > On Wednesday 2010-07-21 15:21, Simon Horman wrote:
> > >> On Wednesday 2010-07-21 03:21, Simon Horman wrote:
> > >> >> +
> > >> >> +#define XT_IPVS_IPVS_PROPERTY (1 << 0) /* all other options imply this one */
> > >> >> +#define XT_IPVS_PROTO (1 << 1)
> > >> >> +#define XT_IPVS_VADDR (1 << 2)
> > >> >> +#define XT_IPVS_VPORT (1 << 3)
> > >> >> +#define XT_IPVS_DIR (1 << 4)
> > >> >> +#define XT_IPVS_METHOD (1 << 5)
> > >> >> +#define XT_IPVS_VPORTCTL (1 << 6)
> > >> >> +#define XT_IPVS_MASK ((1 << 7) - 1)
> > >> >> +#define XT_IPVS_ONCE_MASK (XT_IPVS_MASK & ~XT_IPVS_IPVS_PROPERTY)
> > >>
> > >> Can't these just be an enum?
> > >
> > >More than one option can be used at once - they form a mini bitmap -
> > >so no, I don't think we can use an enum.
> >
> > An enum does not dictate that you cannot combine values of it with itself.
> >
> > enum { A = 1 << 0, B = 1 << 0, };
> > unsigned int flags = A | B;
> >
> > is perfectly fine, which is what other modules do.
>
> Understood. I'll make it so.
Hi Jan,
I must confess that I'm not familiar with using enum in this way.
Can I confirm that you are suggesting the following?
enum {
XT_IPVS_IPVS_PROPERTY = 1 << 0, /* all other options imply this one */
XT_IPVS_PROTO = 1 << 1,
XT_IPVS_VADDR = 1 << 2,
XT_IPVS_VPORT = 1 << 3,
XT_IPVS_DIR = 1 << 4,
XT_IPVS_METHOD = 1 << 5,
XT_IPVS_VPORTCTL = 1 << 6,
XT_IPVS_MASK = (1 << 7) - 1,
XT_IPVS_ONCE_MASK = (XT_IPVS_MASK & ~XT_IPVS_IPVS_PROPERTY)
};
^ permalink raw reply
* linux-next: build warning after merge of the nettree
From: Stephen Rothwell @ 2010-07-22 2:06 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Richard Cochran, Florian Fainelli
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
Hi Dave,
After merging the net tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/net/r6040.c: In function 'r6040_ioctl':
drivers/net/r6040.c:513: warning: passing argument 2 of 'phy_mii_ioctl' from incompatible pointer type
include/linux/phy.h:522: note: expected 'struct ifreq *' but argument is of type 'struct mii_ioctl_data *'
Introduced by commit 28b041139e344ecd0f144d6205b004ae354cfa1e ("net:
preserve ifreq parameter when calling generic phy_mii_ioctl()") (which
changed the phy_mii_ioctl() API) interacting with commit
3831861b4ad8fd0ad7110048eb3e155628799d2b ("r6040: implement phylib")
(which added a use of that function).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build warning after merge of the net tree
From: Stephen Rothwell @ 2010-07-22 2:11 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 562 bytes --]
Hi Dave,
After merging the net tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/vhost/net.c: In function 'vhost_net_set_backend':
drivers/vhost/net.c:536: warning: label 'done' defined but not used
Introduced by commit 11fe883936980fe242869d671092a466cf1db3e3 ("Merge
branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6") which
kept the unneeded label. Sorry if I misguided you.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] LSM: Add post recvmsg() hook.
From: Tetsuo Handa @ 2010-07-22 3:38 UTC (permalink / raw)
To: davem
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, paul.moore, netdev,
linux-security-module
In-Reply-To: <20100721.114509.37203355.davem@davemloft.net>
David Miller wrote:
> From: Tetsuo Handa
> Date: Sat, 17 Jul 2010 10:17:10 +0900
>
> > NETWORKING [IPv4/IPv6] maintainers and Paul, is below patch fine for you?
>
> Unfortunately, after further consideration, I must reject this patch
> and also the post accept() LSM hook one.
>
> Sorry.
>
> I looked into history of the discussions on this issue, and I have found
> that the core issue with these hooks has not been addressed.
>
> We must ensure that if:
>
> 1) Application makes poll() on UDP socket in blocking mode, and UDP
> reports that receive data is available
>
> and
>
> 2) Application, after such a poll() call, makes a blocking recvmsg() call
> and no other activity has occurred on the socket meanwhile
>
> Then we MUST return immediately with that available data.
>
> This LSM hook, when it triggers, can violate this rule, even if you do
> this looping thing.
>
Existing LSM hooks already violate this rule.
security_socket_accept() and security_socket_recvmsg() are allowed to return
immediately with error code instead of available data even if conditions (1)
and (2) are met.
> The post accept() hook has the same problems.
>
> Here is where we originally discussed this, in detail:
>
> http://www.spinics.net/lists/netdev/msg95660.html
>
> Therefore, I think this shows that what Tomoyo is trying to do is
> fatally flawed. We brought this fundamental issue up to you about a
> year ago, and the issue is still not addressed.
>
> So consider very seriously, that what you are trying to do cannot be
> performed without breaking applications and API behavioral
> expectations.
LSM is something that breaks applications and API behavioral expectations.
For example, an application called access("/bin/sh", X_OK) and assumed that
execution of /bin/sh will be permitted unless somebody does chmod("/bin/sh", 0)
before the application calls execve("/bin/sh"). But however, if LSM's policy
changed from "allow execution of /bin/sh" to "deny execution of /bin/sh"
between access("/bin/sh", X_OK) and execve("/bin/sh"), the application was
broken by the LSM. Although such change unlikely happens in normal
circumstance, it can happen and we tolerate such breakage.
Another example. An application called select() on non-socket object (e.g.
regular file). The select() will say "read operation will not block" and
the application will call read() with expectations that read() returns
immediately with available data (or EOF) rather than error code unless
somebody does chmod("the file", 0). But however, if LSM's policy changed from
"allow reading the file" to "deny reading the file" between select() and
read(), the application was broken by the LSM. Although such change unlikely
happens in normal circumstance, it can happen and we tolerate such breakage.
Another example. An application called socket(), bind() and listen().
A connection request arrived and enqueued into the listening socket's backlog.
Now, select() starts saying "read operation will not block" and the application
calls accept() with expectations that accept() returns immediately with
established connection rather than error code. But however, if LSM's policy
changed from "allow picking up the connection" to "deny picking up the
connection" between select() and accept(), the application was broken by the
LSM. Although such change unlikely happens in normal circumstance, it can
happen and we tolerate such breakage.
The only difference between security_socket_accept()/security_socket_recvmsg()
and security_socket_post_accept()/security_socket_post_recvmsg() is that
the connection/datagram in the queue is removed or not when these LSM hooks
returned error code. Existing LSM hooks already made it impossible to return
available data even if conditions (1) and (2) are met.
Generally speaking, the connection/datagram being not removed from the queue
when these LSM hooks returned error code might be preferable. But for TOMOYO,
the connection/datagram being removed from the queue is preferable.
Reasons shown below.
TOMOYO is concerned with protecting applications with minimal side effects.
Being unable to boot the system by granting chmod("/sbin/init", 0) or being
unable to login to the system by granting rename("/etc/shadow", "/etc/shadow0")
or being unable to allocate CPU time for each application by making specific
applications to eat 100% of CPU time etc. are serious side effects for TOMOYO.
Say, there are 100 connections/datagrams in the socket's queue and 1 out of 100
is the connection/datagram which should not be delivered to the application.
(a) If the caller didn't close() the socket when security_socket_accept()/
security_socket_recvmsg() returned error code, subsequent select() will say
"read operation will not block" and the caller will immediately call
accept()/recvmsg() again. This lets the application to spend 100% of CPU
time for only 1 connection/datagram which can not be picked up. This is
nearly DoS for server side and completely DoS for client side.
(b) If the caller close()d the socket when security_socket_accept()/
security_socket_recvmsg() returned error code, all queued connections/
datagrams are discarded. The connections/datagrams which should be
delivered to the application are discarded (i.e. 99 connections/datagrams
are disturbed by only 1 connection/datagram).
Therefore, I will have to ask application developers to modify the
application to call close(), socket(), bind(), listen(), accept()
(regarding server side) and call close(), socket(), connect() (regarding
client side) whenever security_socket_accept()/security_socket_recvmsg()
returned an error. This is nearly DoS for client side.
Silently dropping the 1 connection/datagram with returning non-fatal error code
(e.g. -EAGAIN) (or wait for next connection/datagram unless MSG_DONTWAIT or
O_NONBLOCK is set) seems to give minimal side effects to both server side and
client side. But if you still cannot tolerate dropping the connection/datagram,
what about below idea?
int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
size_t len, int noblock, int flags, int *addr_len)
{
struct inet_sock *inet = inet_sk(sk);
struct sockaddr_in *sin = (struct sockaddr_in *)msg->msg_name;
struct sk_buff *skb;
unsigned int ulen;
int peeked;
int err;
int is_udplite = IS_UDPLITE(sk);
bool slow;
+ bool peek_forced;
/*
* Check any passed addresses
*/
if (addr_len)
*addr_len = sizeof(*sin);
if (flags & MSG_ERRQUEUE)
return ip_recv_error(sk, msg, len);
+ /* LSM wants to decide permission based on skb? */
+ peek_forced = security_socket_recvmsg_force_peek(sk);
try_again:
- skb = __skb_recv_datagram(sk, flags | (noblock ? MSG_DONTWAIT : 0),
- &peeked, &err);
+ skb = __skb_recv_datagram(sk, flags | (noblock ? MSG_DONTWAIT : 0) |
+ (peek_forced ? MSG_PEEK : 0), &peeked, &err);
if (!skb)
goto out;
+ if (peek_forced) {
+ err = security_socket_post_recvmsg(sk, skb);
+ if (err < 0) {
+ /*
+ * Do not remove this message from queue because LSM
+ * decided not to deliver this message to the caller.
+ */
+ peek_forced = false;
+ goto out_free;
+ }
+ }
ulen = skb->len - sizeof(struct udphdr);
if (len > ulen)
len = ulen;
else if (len < ulen)
msg->msg_flags |= MSG_TRUNC;
(...snipped...)
out_free:
+ if (peek_forced && !(flags & MSG_PEEK)) {
+ /*
+ * Remove this message from queue because this message was
+ * peeked for LSM but the caller did not ask to peek.
+ */
+ slow = lock_sock_fast(sk);
+ skb_kill_datagram(sk, skb, flags);
+ unlock_sock_fast(sk, slow);
+ goto out;
+ }
skb_free_datagram_locked(sk, skb);
out:
return err;
(...snipped...)
}
where security_socket_recvmsg_force_peek() returns true (if LSM module wants to
do permission check based on skb) or false (if LSM module does not want to do
permission check based on skb) and security_socket_post_recvmsg() returns error
code (if LSM module decided not to deliver) or 0 (if LSM module decided to
deliver). security_socket_post_recvmsg() must not call skb_kill_datagram().
In this way, security_socket_post_recvmsg() can keep socket's queue state
intact like security_socket_recvmsg() (but side effects (a) and (b) remains as
well as security_socket_recvmsg() hook).
Do permission checks upon enqueue time and do not perform permission check upon
dequeue time cannot be an answer. Side effects with security_socket_accept()/
security_socket_recvmsg() are what SELinux is experiencing as well as TOMOYO
will experience. (Though, it seems to me that SELinux is not interested in such
side effects.)
Regards.
^ permalink raw reply
* Fwd: LVS on local node
From: Franchoze Eric @ 2010-07-22 3:51 UTC (permalink / raw)
To: wensong; +Cc: lvs-devel, netdev, netfilter-devel
Hello,
I'm trying to do load balancing of incoming traffic to my applications. This applications are not very smp friendly, and I want try to run some instances according to number of cpus on single machine. And balance load of incoming traffic/connections to this applications.
Looks like is should be similar to http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.localnode.html
linux kernel 2.6.32 with or without hide interface patches. Tried different configurations but could not see packets on application layer.
192.168.1.165 - eth0 - interface for external connections
195.0.0.1 - dummy0 - virtual interface, real application is binded to that address.
Configuration is:
-A -t 192.168.1.165:1234 -s wlc
-a -t 192.168.1.165:1234 -r 195.0.0.1:1234 -g -w
#ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.165:1234 wlc
-> 195.0.0.1:1234 Local 1 0 0
#
Log:
[ 2106.897409] IPVS: lookup/out TCP 192.168.1.165:44847->192.168.1.165:1234 not hit
[ 2106.897412] IPVS: lookup service: fwm 0 TCP 192.168.1.165:1234 hit
[ 2106.897414] IPVS: ip_vs_wlc_schedule(): Scheduling...
[ 2106.897416] IPVS: WLC: server 195.0.0.1:1234 activeconns 0 refcnt 2 weight 1 overhead 1
[ 2106.897418] IPVS: Enter: ip_vs_conn_new, net/netfilter/ipvs/ip_vs_conn.c line 693
[ 2106.897421] IPVS: Bind-dest TCP c:192.168.1.165:44847 v:192.168.1.165:1234 d:195.0.0.1:1234 fwd:L s:0 conn->flags:181 conn->refcnt:1 dest->refcnt:3
[ 2106.897425] IPVS: Schedule fwd:L c:192.168.1.165:44847 v:192.168.1.165:1234 d:195.0.0.1:1234 conn->flags:1C1 conn->refcnt:2
[ 2106.897429] IPVS: TCP input [S...] 195.0.0.1:1234->192.168.1.165:44847 state: NONE->SYN_RECV conn->refcnt:2
[ 2106.897431] IPVS: Enter: ip_vs_null_xmit, net/netfilter/ipvs/ip_vs_xmit.c line 212
[ 2106.897439] IPVS: lookup/in TCP 192.168.1.165:1234->192.168.1.165:44847 not hit
[ 2106.897441] IPVS: lookup/out TCP 192.168.1.165:1234->192.168.1.165:44847 not hit
[ 2107.277535] IPVS: packet type=1 proto=17 daddr=255.255.255.255 ignored
[ 2108.542691] IPVS: packet type=1 proto=17 daddr=192.168.1.255 ignored
As the result, server application does receive anything on accept(). I tried to make dummy0 a hidden device and play with arp settings. But without result.
I will be happy to hear any idea how to do connection in this environment.
^ permalink raw reply
* Re: [PATCH] Re: mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
From: Valdis.Kletnieks @ 2010-07-22 4:05 UTC (permalink / raw)
To: Florian Mickler
Cc: Andrew Morton, Rafael J. Wysocki, mark gross, e1000-devel, netdev,
linux-kernel, James Bottomley, Thomas Gleixner, David S. Miller
In-Reply-To: <20100721091200.40c43158@schatten.dmk.lab>
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
On Wed, 21 Jul 2010 09:12:00 +0200, Florian Mickler said:
> Attached patch moves the registering from e1000_up to e1000_open and
> the unregistering from e1000_down to e1000_close.
> It is only compile-tested as I don't have the hardware.
My laptop has the hardware, so I tested it - system does indeed boot
without whinging about this issue. Feel free to stick in a:
Tested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Thanks for the fast fix. :)
> From 693c71b911ff0845c872261d5704a1d40960722d Mon Sep 17 00:00:00 2001
> From: Florian Mickler <florian@mickler.org>
> Date: Wed, 21 Jul 2010 08:44:21 +0200
> Subject: [PATCH] e1000e: register pm_qos request on hardware activation
>
> The pm_qos_add_request call has to register the pm_qos request with the pm_qos
> susbsystem before first use of the pm_qos request via
> pm_qos_update_request.
>
> As pm_qos changed to use plists there is no benefit in registering and
> unregistering the pm_qos request on ifup/ifdown and thus we move the
> registering into e1000_open and the unregistering in e1000_close.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH] LSM: Add post recvmsg() hook.
From: David Miller @ 2010-07-22 4:06 UTC (permalink / raw)
To: penguin-kernel
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, paul.moore, netdev,
linux-security-module
In-Reply-To: <201007220338.o6M3citW076383@www262.sakura.ne.jp>
Your analysis is wrong, and what Tomoyo is doing is so fundamentally
different than what the existing SELINUX hooks do.
The existing LSM hooks do not break BSD socket behavior. Do you know
why? Because someone who understood all of this spent a great deal
of time carefully designing them.
The existing hooks do not drop packets on recvmsg() when a security
check does not pass, they signal the error long before the socket
receive queue is even looked at. It is just like seeing a -EFAULT,
-ENFILE, or similar error.
Checks are always made _BEFORE_ major state changes are made to the
socket.
That is critically important, and it's what you seem to fail to see.
The hooks you propose _LOSE_ information. So even if another process
has the 'fd' for a socket, and they would be allowed to receive the
packet by LSM checks, the post hook does not allow that to happen
because the failing 'fd' just frees up the packet and loses it
forever.
The existing hooks signal before we pull the new connection out of the
accept queue during accept(), therefore avoiding the illegal situation
your post ->accept() hook would create since there is absolutely no
way (and there should not be a way) to push a connection back into the
sock accept queue after we've taken it from the protocol layer.
And again here, the proposed hooks _LOSE_ information. The accepted
connection is lost forever, another process with valid security
credentials cannot accept the connection. It is completely gone.
And I'm not even going to entertain adding facilities to allow pushing
things back into the socket state after they've been removed for
inspection.
I think we've been through this issue enough times that we have covered
the issues in their entirety, and nothing you have written convinces
me that my position is wrong and that it is valid to put the Tomoyo
post-recvmsg and post-accept hooks into the tree.
Sorry, but I'm not applying your patches, they are fundamentally flawed
unlike the existing hooks.
^ permalink raw reply
* Re: linux-next: build warning after merge of the net tree
From: David Miller @ 2010-07-22 4:09 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel
In-Reply-To: <20100722121157.344c8462.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 22 Jul 2010 12:11:57 +1000
> After merging the net tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/vhost/net.c: In function 'vhost_net_set_backend':
> drivers/vhost/net.c:536: warning: label 'done' defined but not used
>
> Introduced by commit 11fe883936980fe242869d671092a466cf1db3e3 ("Merge
> branch 'master' of
> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6") which
> kept the unneeded label. Sorry if I misguided you.
I've fixed this, thanks Stephen. Don't worry, not your fault :)
^ permalink raw reply
* Re: linux-next: build warning after merge of the nettree
From: David Miller @ 2010-07-22 4:11 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, richardcochran, florian
In-Reply-To: <20100722120639.cc8d56a5.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 22 Jul 2010 12:06:39 +1000
> After merging the net tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/net/r6040.c: In function 'r6040_ioctl':
> drivers/net/r6040.c:513: warning: passing argument 2 of 'phy_mii_ioctl' from incompatible pointer type
> include/linux/phy.h:522: note: expected 'struct ifreq *' but argument is of type 'struct mii_ioctl_data *'
>
> Introduced by commit 28b041139e344ecd0f144d6205b004ae354cfa1e ("net:
> preserve ifreq parameter when calling generic phy_mii_ioctl()") (which
> changed the phy_mii_ioctl() API) interacting with commit
> 3831861b4ad8fd0ad7110048eb3e155628799d2b ("r6040: implement phylib")
> (which added a use of that function).
Thanks Stephen, should be fixed as follows:
--------------------
r6040: Fix args to phy_mii_ioctl().
Reported by Stephen Rothwell.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/r6040.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 7d482a2..142c381 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -510,7 +510,7 @@ static int r6040_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
if (!lp->phydev)
return -EINVAL;
- return phy_mii_ioctl(lp->phydev, if_mii(rq), cmd);
+ return phy_mii_ioctl(lp->phydev, rq, cmd);
}
static int r6040_rx(struct net_device *dev, int limit)
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] LSM: Add post recvmsg() hook.
From: Tetsuo Handa @ 2010-07-22 4:41 UTC (permalink / raw)
To: davem
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, paul.moore, netdev,
linux-security-module
In-Reply-To: <20100721.210636.197931242.davem@davemloft.net>
David Miller wrote:
> Your analysis is wrong, and what Tomoyo is doing is so fundamentally
> different than what the existing SELINUX hooks do.
>
> The existing LSM hooks do not break BSD socket behavior. Do you know
> why? Because someone who understood all of this spent a great deal
> of time carefully designing them.
>
> The existing hooks do not drop packets on recvmsg() when a security
> check does not pass, they signal the error long before the socket
> receive queue is even looked at. It is just like seeing a -EFAULT,
> -ENFILE, or similar error.
>
> Checks are always made _BEFORE_ major state changes are made to the
> socket.
Excuse me, below check is made inside recvmsg() and may return error if
SELinux's policy has changed after the select() said "ready" and before
security_socket_recvmsg() is called. No?
int avc_has_perm_noaudit(u32 ssid, u32 tsid,
u16 tclass, u32 requested,
unsigned flags,
struct av_decision *in_avd)
{
struct avc_node *node;
struct av_decision avd_entry, *avd;
int rc = 0;
u32 denied;
BUG_ON(!requested);
rcu_read_lock();
node = avc_lookup(ssid, tsid, tclass);
if (!node) {
rcu_read_unlock();
if (in_avd)
avd = in_avd;
else
avd = &avd_entry;
security_compute_av(ssid, tsid, tclass, avd);
rcu_read_lock();
node = avc_insert(ssid, tsid, tclass, avd);
} else {
if (in_avd)
memcpy(in_avd, &node->ae.avd, sizeof(*in_avd));
avd = &node->ae.avd;
}
denied = requested & ~(avd->allowed);
if (denied) {
if (flags & AVC_STRICT)
rc = -EACCES;
else if (!selinux_enforcing || (avd->flags & AVD_FLAGS_PERMISSIVE))
avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
tsid, tclass, avd->seqno);
else
rc = -EACCES;
}
rcu_read_unlock();
return rc;
}
int avc_has_perm(u32 ssid, u32 tsid, u16 tclass,
u32 requested, struct common_audit_data *auditdata)
{
struct av_decision avd;
int rc;
rc = avc_has_perm_noaudit(ssid, tsid, tclass, requested, 0, &avd);
avc_audit(ssid, tsid, tclass, requested, &avd, rc, auditdata);
return rc;
}
static int socket_has_perm(struct task_struct *task, struct socket *sock,
u32 perms)
{
struct inode_security_struct *isec;
struct common_audit_data ad;
u32 sid;
int err = 0;
isec = SOCK_INODE(sock)->i_security;
if (isec->sid == SECINITSID_KERNEL)
goto out;
sid = task_sid(task);
COMMON_AUDIT_DATA_INIT(&ad, NET);
ad.u.net.sk = sock->sk;
err = avc_has_perm(sid, isec->sid, isec->sclass, perms, &ad);
out:
return err;
}
static int selinux_socket_recvmsg(struct socket *sock, struct msghdr *msg,
int size, int flags)
{
return socket_has_perm(current, sock, SOCKET__READ);
}
static struct security_operations selinux_ops = {
(...snipped...)
.socket_recvmsg = selinux_socket_recvmsg,
(...snipped...)
};
Are you saying that selinux_socket_recvmsg() always returns 0?
> That is critically important, and it's what you seem to fail to see.
>
> The hooks you propose _LOSE_ information. So even if another process
> has the 'fd' for a socket, and they would be allowed to receive the
> packet by LSM checks, the post hook does not allow that to happen
> because the failing 'fd' just frees up the packet and loses it
> forever.
>
> The existing hooks signal before we pull the new connection out of the
> accept queue during accept(), therefore avoiding the illegal situation
> your post ->accept() hook would create since there is absolutely no
> way (and there should not be a way) to push a connection back into the
> sock accept queue after we've taken it from the protocol layer.
>
> And again here, the proposed hooks _LOSE_ information. The accepted
> connection is lost forever, another process with valid security
> credentials cannot accept the connection. It is completely gone.
>
> And I'm not even going to entertain adding facilities to allow pushing
> things back into the socket state after they've been removed for
> inspection.
>
> I think we've been through this issue enough times that we have covered
> the issues in their entirety, and nothing you have written convinces
> me that my position is wrong and that it is valid to put the Tomoyo
> post-recvmsg and post-accept hooks into the tree.
>
> Sorry, but I'm not applying your patches, they are fundamentally flawed
> unlike the existing hooks.
Did the idea described in previous mail _LOSE_ information?
I made the udp_recvmsg() to force MSG_PEEK so that the message will not be
removed from the queue if security_socket_post_recvmsg() returned error code
and remove the message from the queue only if security_socket_post_recvmsg()
returned 0 and the caller did not pass MSG_PEEK.
^ 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