* [PATCH 2/2] caif-spi: Bugfix SPI_DATA_POS settings were inverted.
From: sjur.brandeland @ 2010-08-10 17:36 UTC (permalink / raw)
To: davem; +Cc: sjurbren, netdev, Sjur Braendeland
In-Reply-To: <1281461807-17408-1-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Braendeland <sjur.brandeland@stericsson.com>
The setting of SPI_DATA_POS depending on CONFIG_CAIF_SPI_SYNC
where inverted.
Change-Id: I4886d1d69cc50557f516e05c40f649fed55384a2
Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
---
drivers/net/caif/caif_spi_slave.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/caif/caif_spi_slave.c b/drivers/net/caif/caif_spi_slave.c
index 077ccf8..2111dbf 100644
--- a/drivers/net/caif/caif_spi_slave.c
+++ b/drivers/net/caif/caif_spi_slave.c
@@ -22,13 +22,13 @@
#include <net/caif/caif_spi.h>
#ifndef CONFIG_CAIF_SPI_SYNC
-#define SPI_DATA_POS SPI_CMD_SZ
+#define SPI_DATA_POS 0
static inline int forward_to_spi_cmd(struct cfspi *cfspi)
{
return cfspi->rx_cpck_len;
}
#else
-#define SPI_DATA_POS 0
+#define SPI_DATA_POS SPI_CMD_SZ
static inline int forward_to_spi_cmd(struct cfspi *cfspi)
{
return 0;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] caif: Bugfix - Increase default headroom size for control channel.
From: sjur.brandeland @ 2010-08-10 17:36 UTC (permalink / raw)
To: davem; +Cc: sjurbren, netdev, Sjur Braendeland
From: Sjur Braendeland <sjur.brandeland@stericsson.com>
Headroom size for control channel must be at least 48 bytes in some scenarios.
Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
---
net/caif/cfpkt_skbuff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/caif/cfpkt_skbuff.c b/net/caif/cfpkt_skbuff.c
index 01f238f..c49a669 100644
--- a/net/caif/cfpkt_skbuff.c
+++ b/net/caif/cfpkt_skbuff.c
@@ -9,7 +9,7 @@
#include <linux/hardirq.h>
#include <net/caif/cfpkt.h>
-#define PKT_PREFIX 16
+#define PKT_PREFIX 48
#define PKT_POSTFIX 2
#define PKT_LEN_WHEN_EXTENDING 128
#define PKT_ERROR(pkt, errmsg) do { \
--
1.6.3.3
^ permalink raw reply related
* Re: i386 allmodconfig, current mainline
From: Phillip Lougher @ 2010-08-10 18:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Faisal Latif, Chien Tung, Dan Williams,
Samuel Ortiz, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100809164346.6e30cf8c.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Andrew Morton wrote:
> fs/squashfs/xattr.c:37: warning: 'squashfs_xattr_handler' declared inline after being called
> fs/squashfs/xattr.c:37: warning: previous declaration of 'squashfs_xattr_handler' was here
>
The fix for this is in linux-next, and it will be in my imminent 2.6.36 pull
request to Linus.
Phillip
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] net: add Fast Ethernet driver for PXA168.
From: Philip Rakity @ 2010-08-10 18:12 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Sachin Sanap, netdev@vger.kernel.org, Ashish Karkare,
Prabhanjan Sarnaik, eric.y.miao@gmail.com, Mark Brown
In-Reply-To: <20100810180154.GD25474@mail.wantstofly.org>
Maybe the solution is to add a new option in Kconfig to define the extra headers size the driver will need. That option will increase the headers. I do not like that very much since it requires someone know how big the value should be. Could default it to 48 or 64 bytes and allow it to be edited. It is not great solution since it fixes the pxa168 driver but does not handle other drivers.
thoughts ?
On Aug 10, 2010, at 11:01 AM, Lennert Buytenhek wrote:
> On Tue, Aug 10, 2010 at 10:55:02AM -0700, Philip Rakity wrote:
>
>> We agree that extra header prepend space is needed. The solution of
>> globally defining SKB_NET_PAD to increase this area for all drivers
>> is where I have some concern. The solution certainly works but at
>> the cost of extra space for drivers that do not need to do this.
>> The solution is fine by me and maybe the best answer is to increase
>> the value in the standard linux implementation from 32 to 48 or 64 bytes.
>
> What I said was:
>
> | This seems like something that, should you want to handle it, should be
> | handled centrally (e.g. by conditionally increasing NET_SKB_PAD or so)
> | and not hardcoded into one specific driver only.
>
> In other words, "don't hardcode it into your driver just because you
> think that most users will want to use your driver for bridging/routing
> to wlan".
>
> It makes no sense to categorically declare that "pxa168_eth will always
> be used for routing to wireless, so we'll add some extra headroom by
> default there, but e1000e will not, so there we won't".
>
> Even if this stays a private kernel tree hack, I would still do it
> globally rather than locally.
>
>
>>>> 11n needs more.
>>>
>>> Really? Pointer?
>
> Still curious about this.
will forward pointer reference later (on another computer)
^ permalink raw reply
* Re: [PATCH v2] net: add Fast Ethernet driver for PXA168.
From: Lennert Buytenhek @ 2010-08-10 18:01 UTC (permalink / raw)
To: Philip Rakity
Cc: Sachin Sanap, netdev@vger.kernel.org, Ashish Karkare,
Prabhanjan Sarnaik, eric.y.miao@gmail.com, Mark Brown
In-Reply-To: <6546F80B-0B5E-4F41-A500-7B75493A42DE@marvell.com>
On Tue, Aug 10, 2010 at 10:55:02AM -0700, Philip Rakity wrote:
> We agree that extra header prepend space is needed. The solution of
> globally defining SKB_NET_PAD to increase this area for all drivers
> is where I have some concern. The solution certainly works but at
> the cost of extra space for drivers that do not need to do this.
> The solution is fine by me and maybe the best answer is to increase
> the value in the standard linux implementation from 32 to 48 or 64 bytes.
What I said was:
| This seems like something that, should you want to handle it, should be
| handled centrally (e.g. by conditionally increasing NET_SKB_PAD or so)
| and not hardcoded into one specific driver only.
In other words, "don't hardcode it into your driver just because you
think that most users will want to use your driver for bridging/routing
to wlan".
It makes no sense to categorically declare that "pxa168_eth will always
be used for routing to wireless, so we'll add some extra headroom by
default there, but e1000e will not, so there we won't".
Even if this stays a private kernel tree hack, I would still do it
globally rather than locally.
> > > 11n needs more.
> >
> > Really? Pointer?
Still curious about this.
^ permalink raw reply
* Re: [PATCH v2] net: add Fast Ethernet driver for PXA168.
From: Philip Rakity @ 2010-08-10 17:55 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Sachin Sanap, netdev@vger.kernel.org, Ashish Karkare,
Prabhanjan Sarnaik, eric.y.miao@gmail.com, Mark Brown
In-Reply-To: <20100810173052.GB25474@mail.wantstofly.org>
We agree that extra header prepend space is needed. The solution of globally defining SKB_NET_PAD to increase this area for all drivers is where I have some concern. The solution certainly works but at the cost of extra space for drivers that do not need to do this. The solution is fine by me and maybe the best answer is to increase the value in the standard linux implementation from 32 to 48 or 64 bytes.
On Aug 10, 2010, at 10:30 AM, Lennert Buytenhek wrote:
> On Tue, Aug 10, 2010 at 09:24:23AM -0700, Philip Rakity wrote:
>
>>>> * Headroom in SKB for 802.11 not included in the patch since that
>>>> varies based on 802.11 a/b/g/n.
>>>
>>> I don't think this is true?
>>>
>>> (The 11a/b/n on-the-air preambles are of different lengths (and are
>>> sent at different rates), but that isn't visible to software.)
>>
>> 802.11b/g headers are larger and if not handled by firmware in an
>> offload engine are programmed by the driver. There needs to be room
>> for
>>
>> a) Frame Control (2 bytes)
>> b) AID (2 bytes)
>> c) address-1 (6 bytes)
>> d) address-2 (6 bytes)
>> e) address-3 (6 bytes)
>> f) seqfrag (2 bytes)
>> g) address-4 (6 bytes)
>>
>> or 30 bytes.
>
> Depends on the driver and/or whether you are doing WDS.
>
> mwl8k always needs 30 bytes due to hardware pecularities (while the
> 4-address-with-QoS header is 32 bytes, the QoS field is always passed
> in the TX descriptor), but other drivers might need 32 bytes (and not
> 30 bytes) for 4-address-with-QoS headers, or might not need 30 or 32
> bytes for transmitting 3-address or 2-address frames.
>
>
>> 11n needs more.
>
> Really? Pointer?
>
>
>> Some of these fields ARE visible to s/w.
>
> Where did I say that they are not?
>
> What I said was that the _preambles_ are not visible to software.
^ permalink raw reply
* Re: [PATCH v2] net: add Fast Ethernet driver for PXA168.
From: Lennert Buytenhek @ 2010-08-10 17:30 UTC (permalink / raw)
To: Philip Rakity
Cc: Sachin Sanap, netdev@vger.kernel.org, Ashish Karkare,
Prabhanjan Sarnaik, eric.y.miao@gmail.com, Mark Brown
In-Reply-To: <7B1965FC-E61F-4BFD-86B1-F9D390A012CC@marvell.com>
On Tue, Aug 10, 2010 at 09:24:23AM -0700, Philip Rakity wrote:
> >> * Headroom in SKB for 802.11 not included in the patch since that
> >> varies based on 802.11 a/b/g/n.
> >
> > I don't think this is true?
> >
> > (The 11a/b/n on-the-air preambles are of different lengths (and are
> > sent at different rates), but that isn't visible to software.)
>
> 802.11b/g headers are larger and if not handled by firmware in an
> offload engine are programmed by the driver. There needs to be room
> for
>
> a) Frame Control (2 bytes)
> b) AID (2 bytes)
> c) address-1 (6 bytes)
> d) address-2 (6 bytes)
> e) address-3 (6 bytes)
> f) seqfrag (2 bytes)
> g) address-4 (6 bytes)
>
> or 30 bytes.
Depends on the driver and/or whether you are doing WDS.
mwl8k always needs 30 bytes due to hardware pecularities (while the
4-address-with-QoS header is 32 bytes, the QoS field is always passed
in the TX descriptor), but other drivers might need 32 bytes (and not
30 bytes) for 4-address-with-QoS headers, or might not need 30 or 32
bytes for transmitting 3-address or 2-address frames.
> 11n needs more.
Really? Pointer?
> Some of these fields ARE visible to s/w.
Where did I say that they are not?
What I said was that the _preambles_ are not visible to software.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 1/2] net: dsa: introduce STPID switch tagging handling code
From: Mike Frysinger @ 2010-08-10 17:04 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: Karl Beldan, netdev, uclinux-dist-devel
In-Reply-To: <20100810140552.GV8876@mail.wantstofly.org>
On Tue, Aug 10, 2010 at 10:05, Lennert Buytenhek wrote:
> Is the hardware you're doing this on available somewhere for me to
> try things out on?
yes & no. the board in question is here (that picture has two ethernet ports):
http://www.analog.com/en/embedded-processing-dsp/blackfin/BF518-EZBRD/processors/product.html
but that was the first few revs of the board ... later ones have
dropped the switch because it didnt support PTP packets. i dont think
you can specify "give me an older rev" when ordering from ADI.
if you're interested, i can probably find you an older one laying
around if you're interested in testing things.
-mike
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: Geert Uytterhoeven @ 2010-08-10 16:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Greg KH, David Woodhouse, Mike Frysinger,
Jesse Barnes, Kevin Curtis, Phillip Lougher, Faisal Latif,
Chien Tung, Dan Williams, Samuel Ortiz,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100810101521.0dcd4393.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
On Tue, Aug 10, 2010 at 02:15, Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> wrote:
> On Mon, 9 Aug 2010 16:43:46 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> Guys. What's goin' on out there?
>
> I guess we are all so up to date that noone does 32 bit builds any
> more ... Also noone is bothering to look at the build logs:
>
> linus tree: http://kisskb.ellerman.id.au/kisskb/branch/3/
> linux-next: http://kisskb.ellerman.id.au/kisskb/branch/9/
Yeah, we have build failures migrating from -next to -linus :-(
BTW, still no one has commented on http://lkml.org/lkml/2010/7/13/378?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] net: add Fast Ethernet driver for PXA168.
From: Philip Rakity @ 2010-08-10 16:24 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Sachin Sanap, netdev@vger.kernel.org, Ashish Karkare,
Prabhanjan Sarnaik, eric.y.miao@gmail.com, Mark Brown
In-Reply-To: <20100810123329.GR8876@mail.wantstofly.org>
On Aug 10, 2010, at 5:33 AM, Lennert Buytenhek wrote:
> On Tue, Aug 10, 2010 at 02:00:04PM +0530, Sachin Sanap wrote:
>
>> * Headroom in SKB for 802.11 not included in the patch since that
>> varies based on 802.11 a/b/g/n.
>
> I don't think this is true?
>
> (The 11a/b/n on-the-air preambles are of different lengths (and are
> sent at different rates), but that isn't visible to software.)
>
>
802.11b/g headers are larger and if not handled by firmware in an offload engine are programmed by the driver. There needs to be room for
a) Frame Control (2 bytes)
b) AID (2 bytes)
c) address-1 (6 bytes)
d) address-2 (6 bytes)
e) address-3 (6 bytes)
f) seqfrag (2 bytes)
g) address-4 (6 bytes)
or 30 bytes. 11n needs more. Some of these fields ARE visible to s/w. So the skb prepend area needs to be larger when sending from ethernet to wifi since there will not be room for some of these fields.
Philip
<snip>
^ permalink raw reply
* Re: e1000e crashes with 2.6.34.x and ThinkPad T60
From: Allan, Bruce W @ 2010-08-10 16:34 UTC (permalink / raw)
To: Marc Haber, Tantilov, Emil S
Cc: Network Developers, e1000-devel@lists.sf.net,
Linux Kernel Developers, Linux
In-Reply-To: <20100810120458.GB21511@torres.zugschlus.de>
On Tuesday, August 10, 2010 5:05 AM, Marc Haber wrote:
> On Wed, Aug 04, 2010 at 12:23:45PM -0600, Tantilov, Emil S wrote:
>> Looking at your lspci output - your system has a slightly different
>> HW, but I don't know if this is significant.
>>
>> Are you loading the kernel with any parameters (cat /proc/cmdline)?
>
> BOOT_IMAGE=/vmlinuz-2.6.35-zgws1 root=/dev/mapper/root ro
> resume=/dev/mapper/swap0 quiet splash radeon.modeset=1
>
>> Do you have firewall configured (iptables -L)?
>
> I am working pretty intensively with virtual machines which are natted
> here and there. I have a handful of MASQUERADE rules in the
> nat/POSTROUTING chain, but that's it.
>
>> Also now that 2.6.35 is out - could you give it a try and see if the
>> situation had improved?
>
> Tried, no improvement.
>
> Greetings
> Marc
[adding e1000-devel, the Intel wired ethernet developers mailing list]
We have had other recent reports of issues with this part that are due to
ASPM L1 being enabled. Would you please try disabling L1 after the driver
is loaded as follows (assuming your adapter is still PCI bus/device/number
02:00.0 as indicated in the lspci output you provided earlier):
1) First check the hexadecimal value of the LnkCtl register -
# setpci -s 2:0.0 0xf0
2) Disable ASPM (both L0s and L1) by zeroing out bits 0 and 1 in the value
returned by the previous step. For example, if it returned 42 (hex 42,
that is) -
# setpci -s 2:0.0 0xf0=0x40
3) Confirm ASPM is disabled by checking the output from lspci again.
Please let us know if this helps your situation, thanks.
Bruce.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
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: Yet another bridge netfilter crash
From: Herbert Xu @ 2010-08-10 15:19 UTC (permalink / raw)
To: Changli Gao; +Cc: Patrick McHardy, Stephen Hemminger, netdev
In-Reply-To: <AANLkTikpCOrkPqOkahXBFFoH6bqTKhA-+_mUy0qGrRnq@mail.gmail.com>
On Tue, Aug 10, 2010 at 06:39:42AM +0800, Changli Gao wrote:
>
> How about always using the skb->nf_bridge of the skb last received in
> a defrag queue as the nf_bridge of the final defraged skb? I have
> posted a patch doing such thing.
> http://patchwork.ozlabs.org/patch/60904/
I'd rather just drop the fragment (and maybe fail the whole
reassembly) if you detect nf_bridge mismatches.
Reassembling fragments from two interfaces is one thing, but
knowingly reassembling fragments across two bridges is just
wrong.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Missing device binding relating to tcp_v4_send_reset?
From: Ben Greear @ 2010-08-10 14:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber
In-Reply-To: <20100810.014846.258126767.davem@davemloft.net>
On 08/10/2010 01:48 AM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Mon, 09 Aug 2010 10:46:26 -0700
>
>> This snippet is from some patches Patrick did for me some time
>> back. I think the rest of his work has been merged upstream, but
>> this patch was not. I'm honestly not sure if it's needed or not,
>> but we've been running with it for at least a year or so and it's
>> been working fine for us.
>
> There is no reason at all to force a reply to a packet to
> go out of the same interface as the packet which triggered
> that reply arrived upon.
Ok, in my case I *did* want this behaviour..it makes send-to-self,
BIND_TO_DEVICE and virtual routers and such work properly if I
recall correctly.
Would you consider a sysctl to enable this feature, with it disabled
by default? Please note there are similar sysctls for ICMP already...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 1/2] net: dsa: introduce STPID switch tagging handling code
From: Lennert Buytenhek @ 2010-08-10 14:05 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Karl Beldan, netdev, uclinux-dist-devel
In-Reply-To: <AANLkTinNiE1BE=HuwVG2Tom922XJXxQDB-JMsPYimPTk@mail.gmail.com>
On Thu, Jul 29, 2010 at 01:50:45PM -0400, Mike Frysinger wrote:
> >>> >> + source_port = dsa_header[1] & 0x03;
> >>> >> + if (source_port >= DSA_MAX_PORTS || ds->ports[source_port] == NULL)
> >>> >> + goto out_drop;
> >>> >> +
> >>> >> + if (((dsa_header[0] & ETH_P_8021QH) == ETH_P_8021QH) &&
> >>> >
> >>> > This is bogus -- what it does is:
> >>> >
> >>> > if ((dsa_header[0] & 0x81) == 0x81)
> >>> >
> >>> > It doesn't look like you need to mask here at all.
> >>>
> >>> where does it say dsa_header[0] will always have 0x81 set ?
> >>
> >> Eh?
> >>
> >> This code is checking whether the packet has a STPID tag on it or not.
> >> A STPID tag exists if the first 12 nibbles are 0x810.
> >>
> >> You are checking whether the first 8 nibbles of this are equal to 0x81
> >> by doing:
> >>
> >> if ((byte & 0x81) == 0x81)
> >>
> >> What if the first byte is 0x93? Or 0xc5?
> >
> > that was my point. should it be masking or doing a raw compare ?
>
> and the answer is ... ? so i can send an updated patch ;)
From what I understand, you should just be checking for equality with
0x81 in the first byte, as that is what indicates presence of the STPID
tag.
Is the hardware you're doing this on available somewhere for me to
try things out on?
^ permalink raw reply
* Re: [09/38] xen: netfront: explicitly generate arp_notify event after migration.
From: Ian Campbell @ 2010-08-10 13:07 UTC (permalink / raw)
To: Greg KH
Cc: Jeremy Fitzhardinge, xen-devel@lists.xensource.com,
David S. Miller, Stephen Hemminger, linux-kernel@vger.kernel.org,
stable@kernel.org, netdev@vger.kernel.org,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
stable-review@kernel.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <20100806183200.858950407@clark.site>
Hi Greg,
Looks like I forgot to request this for 2.6.32 too, could you queue it
up there as well?
It depends on the previous patch in this series (arp_notify: allow
drivers to explicitly request a notification event.).
Thanks,
Ian.
On Fri, 2010-08-06 at 19:30 +0100, Greg KH wrote:
> 2.6.35-stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
> From: Ian Campbell <Ian.Campbell@citrix.com>
>
> commit 592970675c9522bde588b945388c7995c8b51328 upstream.
>
> Use newly introduced netif_notify_peers() method to ensure a gratuitous ARP is
> generated after a migration.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Stephen Hemminger <shemminger@linux-foundation.org>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Cc: xen-devel@lists.xensource.com
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
> ---
> drivers/net/xen-netfront.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1621,6 +1621,7 @@ static void backend_changed(struct xenbu
> if (xennet_connect(netdev) != 0)
> break;
> xenbus_switch_state(dev, XenbusStateConnected);
> + netif_notify_peers(netdev);
> break;
>
> case XenbusStateClosing:
>
>
^ permalink raw reply
* Re: Auto generation of IPv6 link local address
From: Jon Smirl @ 2010-08-10 12:49 UTC (permalink / raw)
To: Michał Mirosław; +Cc: Netdev
In-Reply-To: <AANLkTi=zmZHsJpMRxk5wa56Uh0fKPkBaLT1hp0uZzax+@mail.gmail.com>
2010/8/10 Michał Mirosław <mirqus@gmail.com>:
> 2010/8/10 Jon Smirl <jonsmirl@gmail.com>:
>> When I bring my Ethernet interface up it automatically gets a link
>> local IPv6 address.
>>
>> eth3 Link encap:Ethernet HWaddr 00:1b:21:59:65:32
>> inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
>> inet6 addr: fe80::21b:21ff:fe59:6532/64 Scope:Link -->
>> Missing from my driver
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:1836635 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:1283010 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:2259859914 (2.2 GB) TX bytes:121836850 (121.8 MB)
>> Interrupt:16 Memory:dbd60000-dbd80000
>>
>> I'm writing a device driver for new 802.15.4 hardware. When I bring it
>> up I don't get an automatic IPv6 link local address. What controls
>> whether an adapter gets a link local address added or not? My driver
>> should get one so I must have something wrong in my code.
>>
>> wpan0 Link encap:IEEE 802.15.4 HWaddr 00:50:c2:ff:fe:a8:a8:c5
>> UP BROADCAST RUNNING NOARP MTU:1280 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:10
>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> addrconf_notify() in linux-2.6.34/net/ipv6/addrconf.c does not have
> code for IEEE 802.15.4. I don't know much about 802.15.4, but if IPv6
> with static addresses works over it, then adding support for
> autogenerated addresses should be easy (just addrconf_dev_config() and
> ipv6_generate_eui64()?).
It was easy...
I added a ipv6_generate_eui64() since the addresses are already 64b.
wpan0 Link encap:IEEE 802.15.4 HWaddr 00:50:c2:ff:fe:a8:a8:c5
inet6 addr: fe80::50:c2ff:fea8:c545/64 Scope:Link
inet6 addr: aaaa::1/64 Scope:Global
UP BROADCAST RUNNING NOARP MTU:1280 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Back to working on my 6lowpan implementation.
http://en.wikipedia.org/wiki/6lowpan
>
> Best Regards,
> Michał Mirosław
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH v2] net: add Fast Ethernet driver for PXA168.
From: Lennert Buytenhek @ 2010-08-10 12:33 UTC (permalink / raw)
To: Sachin Sanap
Cc: Philip Rakity, netdev@vger.kernel.org, Ashish Karkare,
Prabhanjan Sarnaik, eric.y.miao@gmail.com, Mark Brown
In-Reply-To: <1281429004.17990.2.camel@pe-lt522.marvell.com>
On Tue, Aug 10, 2010 at 02:00:04PM +0530, Sachin Sanap wrote:
> * Headroom in SKB for 802.11 not included in the patch since that
> varies based on 802.11 a/b/g/n.
I don't think this is true?
(The 11a/b/n on-the-air preambles are of different lengths (and are
sent at different rates), but that isn't visible to software.)
> +#define ETH_HW_IP_ALIGN 2 /* hw aligns IP header */
> +#define ETH_DATA_LEN 1500
> +#define MAX_PKT_SIZE 1518
How about (stacked) VLANs?
Is the hardware entirely unable to receive larger packets than this, or
is it capable of receiving such packets but e.g. with loss of hardware
receive checksum offloading?
(I guess the hardware can't do RX checksum offload at all since I see
no references to skb->ip_summed and CHECKSUM_*?)
> +#define MAX_DESCS_PER_HIGH (60)
> +#define TX_DESC_COUNT_LOW (10)
These don't seem used.
> +struct pxa168_eth_private {
>
> [...]
>
> + /* Size of Tx Ring per queue */
> + int tx_ring_size;
>
> [...]
>
> + /* Size of Rx Ring per queue */
> + int rx_ring_size;
If you're not going to let the tx/rx ring size be runtime configurable
(like they are in mv643xx_eth), you might as well leave these as defines.
> +static void ethernet_phy_set_addr(struct pxa168_eth_private *pep, int phy_addr)
> +{
> + u32 reg_data;
> +
> + reg_data = rdl(pep, PHY_ADDRESS);
> + reg_data &= ~(0x1f);
No need for the parentheses.
> +static inline u8 flip_8_bits(u8 x)
> +{
> + return (((x) & 0x01) << 3) | (((x) & 0x002) << 1)
> + | (((x) & 0x04) >> 1) | (((x) & 0x008) >> 3)
0x02, 0x08
> + addr0 = (mac_addr[5] >> 2) & 0x03f;
> + addr1 = (mac_addr[5] & 0x003) | (((mac_addr[4] & 0x7f)) << 2);
> + addr2 = ((mac_addr[4] & 0x80) >> 7) | mac_addr[3] << 1;
> + addr3 = (mac_addr[2] & 0x0ff) | ((mac_addr[1] & 1) << 8);
0x34, 0x03, 0xff
> + if (i == HOP_NUMBER) {
> + if (!del) {
> + printk(KERN_INFO "%s: table section is full\n",
> + __FILE__);
> + return -ENOSPC;
> + } else
What does it mean in practice if this happens? (The error message
could be a bit more descriptive.)
> +static void pxa168_eth_set_rx_mode(struct net_device *dev)
> +{
> + struct pxa168_eth_private *pep = netdev_priv(dev);
> + struct netdev_hw_addr *ha;
> + u32 val;
> +
> + val = rdl(pep, PORT_CONFIG);
> + if (dev->flags & IFF_PROMISC)
> + val |= PCR_PM;
> + else
> + val &= ~PCR_PM;
> + wrl(pep, PORT_CONFIG, val);
> + netdev_for_each_mc_addr(ha, dev)
> + update_hash_table_mac_address(pep, NULL, ha->addr);
> +}
1. Don't indent with spaces.
2. This will never remove old multicast MAC addresses?
> + pep->work_todo &= ~(WORK_TX_DONE);
Doesn't need parentheses.
> +static int rxq_process(struct net_device *dev, int budget)
> +{
> + struct pxa168_eth_private *pep = netdev_priv(dev);
> + struct net_device_stats *stats = &dev->stats;
> + unsigned int received_packets = 0;
> + struct sk_buff *skb;
> +
> + while (budget-- > 0) {
> +
> + int rx_next_curr_desc, rx_curr_desc, rx_used_desc;
No need for an empty line.
> +static int pxa168_eth_collect_events(struct pxa168_eth_private *pep,
> + struct net_device *dev)
> +{
> + u32 icr;
> + int ret = 0;
> +
> + icr = rdl(pep, INT_CAUSE);
> + if (0x00 == icr)
icr == 0
> + wrl(pep, INT_CAUSE, icr ^ 0xffffffff);
~icr ?
> + /* Extended Port Configuration */
> + wrl(pep,
> + PORT_CONFIG_EXT, PCXR_2BSM | /* Two byte suffix aligns IP hdr */
Prefix?
> + dma_free_coherent(NULL, pep->tx_desc_area_size,
> + pep->p_tx_desc_area, pep->tx_desc_dma);
BTW, you should pass in a struct device * to the DMA allocation
functions.
> + err = request_irq(dev->irq, pxa168_eth_int_handler,
> + IRQF_DISABLED , dev->name, dev);
Superfluous space before the comma.
> +static void eth_tx_submit_descs_for_skb(struct pxa168_eth_private *pep,
> + struct sk_buff *skb)
> +{
> + int tx_index;
> + struct tx_desc *desc;
> + int length;
> +
> + tx_index = eth_alloc_tx_desc_index(pep);
> + desc = &pep->p_tx_desc_area[tx_index];
> + length = skb->len;
> + pep->tx_skb[tx_index] = skb;
> + desc->byte_cnt = length;
> + desc->buf_ptr = dma_map_single(NULL, skb->data, length, DMA_TO_DEVICE);
> + wmb();
> + desc->cmd_sts = BUF_OWNED_BY_DMA | TX_GEN_CRC | TX_FIRST_DESC |
> + TX_ZERO_PADDING | TX_LAST_DESC;
> + if (unlikely(!(pep->tx_desc_count % (pep->tx_ring_size / 4))))
> + desc->cmd_sts |= TX_EN_INT;
Is this intended to only generate transmit completion interrupts for
every N packets?
If so, you cannot delay kfree_skb()ing a transmitted skb indefinitely.
If you want to batch TX completion interrupts, you at least have to put
in a timeout.
Also, the descriptor is in device-visible memory, and BUF_OWNED_BY_DMA
becomes visible to the device as soon as you do the preceding store to
desc->cmd_sts -- you cannot then go back and alter that field, as you
could race with the device clearing BUF_OWNED_BY_DMA.
> +static int pxa168_eth_start_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct pxa168_eth_private *pep = netdev_priv(dev);
> + struct net_device_stats *stats = &dev->stats;
> +
> + eth_tx_submit_descs_for_skb(pep, skb);
In mv643xx_eth, txq_submit_*() are much larger because they have to deal
with scatter-gather transmit. Since you don't support that, you might
as well just inline this function here.
> +static int pxa168_smi_read(struct mii_bus *bus, int phy_addr, int regnum)
> +{
> + int val;
> + struct pxa168_eth_private *pep = bus->priv;
> + int i = 0;
> +
> + /* wait for the SMI register to become available */
> + for (i = 0; (val = rdl(pep, SMI)) & SMI_BUSY; i++) {
> + if (i == PHY_WAIT_ITERATIONS) {
> + printk(KERN_ERR
> + "pxa168 PHY timeout, val=0x%x\n", val);
> + return -ETIMEDOUT;
> + }
> + udelay(1);
> + }
> + wrl(pep, SMI, (phy_addr << 16) | (regnum << 21) | SMI_OP_R);
> + /* now wait for the data to be valid */
> + for (i = 0; !((val = rdl(pep, SMI)) & SMI_R_VALID); i++) {
> + if (i == PHY_WAIT_ITERATIONS) {
> + printk(KERN_ERR
> + "pxa168 PHY RD timeout, val=0x%x\n", val);
> + return -ETIMEDOUT;
> + }
> + udelay(1);
> + }
> + return val & 0xffff;
> +}
This can end up busy-waiting (i.e. hogging the CPU) for twice 500 us,
i.e. 1 msec. Isn't there a SMI completion interrupt you can use, or
at least yield the cpu by sleeping for a bit?
> +static int pxa168_smi_write(struct mii_bus *bus, int phy_addr, int regnum,
> + u16 value)
> +{
> + struct pxa168_eth_private *pep = bus->priv;
> + int i;
> +
> + /* wait for the SMI register to become available */
> + for (i = 0; rdl(pep, SMI) & SMI_BUSY; i++) {
> + if (i == PHY_WAIT_ITERATIONS) {
> + printk(KERN_ERR "pxa168 PHY busy timeout.\n");
> + return -ETIMEDOUT;
> + }
> + udelay(1);
> + }
> + wrl(pep, SMI, (phy_addr << 16) | (regnum << 21) |
> + SMI_OP_W | (value & 0xffff));
I would wait here for the write to complete, otherwise you can't report
errors due to the slave address not responding.
> + clk = clk_get(&pdev->dev, "MFUCLK");
> + if (IS_ERR(clk)) {
> + printk(KERN_ERR "fast Ethernet failed to get clock\n");
At least stick the name of the driver in here.
> + /* init callback is used for board specific initialization
> + * e.g on Aspenite its used to initialize the PHY transceiver.
> + */
> + int (*init)(void);
Is resetting the PHY not enough?
^ permalink raw reply
* Dead Config Option STMMAC_ETH?
From: Christian Dietrich @ 2010-08-10 12:28 UTC (permalink / raw)
To: David S. Miller, Giuseppe Cavallaro, netdev, linux-kernel
Cc: vamos-dev@i4.informatik.uni-erlangen.de
Hi all!
As part of the VAMOS[0] research project at the University of
Erlangen we are looking at multiple integrity errors in linux'
configuration system.
I've been running a check on the drivers/net/stmmac sourcetree for
config Items not defined in Kconfig and found such a case. Sourcecode
blocks depending on these Items are not reachable from a vanilla
kernel -- dead code. I've seen such dead blocks made on purpose
e.g. while integrating new features into the kernel but generally
they're just useless.
As far as i can see in drivers/net/stmmac/Kconfig STMMAC_ETH and several
depending flags are dead in the linux vanilla kernel, because it depends
on CPU_SUBTYPE_ST40, but there isn't a Kconfig option for that. But
f96691872439ab2071171d4531c4a95b5d493ae5 suggests, that support for this
ST40 plattform was removed in 2007.
There seems to be, that there was much effort on the stmmac drivers in
the last few months, so i just wanted to ask if this problem is known.
Regards
Christian Dietrich
[0] http://vamos1.informatik.uni-erlangen.de
--
(λ x . x x) (λ x . x x) -- See how beatiful the lambda is
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Marcel Holtmann @ 2010-08-10 12:12 UTC (permalink / raw)
To: Jiri Kosina
Cc: Alan Ott, David S Miller, Michael Poole, Bastien Nocera,
Eric Dumazet, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LNX.2.00.1008101344480.29919-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
Hi Jiri,
> > > that the ioctl() API is synchronous is fine to me, however pushing that
> > > down to the transport drivers seems wrong to me. I think the HID core
> > > should be able to handle a fully asynchronous transport driver. I know
> > > that with the USB subsystem you are little bit spoiled here, but for
> > > Bluetooth it is not the case. And in the end even using the asynchronous
> > > USB URB calls would be nice as well.
> > >
> >
> > How are the URB calls better than using the synchronous calls? (see below)
>
> Hi,
>
> I think this was the last mail in the thread so far, right?
>
> > > So why not make the core actually wait for responses from the transport
> > > driver.
> >
> > Because this makes the USB side a lot more complicated, and it would
> > introduce transport specific code into the core. Further, it would
> > involve the transport driver calling hidraw with _every_ single packet
> > it receives. Further, it would have to call hidraw with HANDSHAKE
> > protocol error packets as well.
> >
> > > I would make the transport drivers a lot simpler in the long
> > > run.
> >
> > It would make the USB transport driver and drivers/hid/hidraw much more
> > complicated right now, at the expense of making the BT transport driver
> > marginally simpler (and I'm not even convinced whether it would really be
> > simpler). (see below for more)
>
> Seconded.
>
> > > And I know that most likely besides Bluetooth and USB you won't see
> > > another, but you never know.
> > >
> > I just don't understand the objection. In each transport type, the waiting
> > will have to be done in a different way. USB and BT are different enough that
> > this is the case already, without having to imagine future buses which use
> > HID. In BT, you have to check each packet which comes back from the BT network
> > to see whether it is the response packet that hidraw is waiting for. Further,
> > you have to check for HANDSHAKE packets indicating protocol error. Where
> > better for this to be done than in hidp? Further, how can this possibly happen
> > in drivers/hid/hidraw, as it doesn't know about the details of bluetooth to
> > make this determination, and why should it? In my last email (
> > http://lkml.org/lkml/2010/7/9/231 ) to which I got no response, I laid out how
> > doing the blocking in drivers/hid/hidraw would only make all the parts except
> > bluetooth more complicated (including the core, and the USB side), and would
> > also introduce bluetooth-specific things into the core.
> >
> > Further, you're saying that using the asynchronous USB URB calls would be a
> > benefit. How is it a benefit to replace a single function call which does
> > exactly what I want, with a set of asynchronous calls and then adding my own
> > blocking to make it do the same thing? This sounds to me like it would be 1:
> > more text, 2: duplication of code, 3: error prone. I can't understand how this
> > is of benefit. Please explain to me what I'm missing.
> >
> > In theory, what you're saying makes sense. Making common code and logic
> > actually common is always good. In practice though, in this case, I submit
> > that there really isn't any commonality, and the only way for there to be
> > commonality is to do the USB side the hard way. Further, drivers/hid/hidraw
> > can't wait for a bluetooth packet without having code that's
> > bluetooth-specific. It seems just that simple to me.
> >
> > I'll give it some more thought, and take another look at the code to see if
> > there's something obvious that I'm missing. If you know what I'm missing in my
> > understanding of the problem, please tell me :)
>
> Marcel, did you have time to review Alan's explanation a little bit?
>
> I must say I would really like to have this feature merged, but of course
> not if you completely disagree .. but then we'll have to find some
> consensus. Currently Alan's summary above quite aligns with my opinion.
my opinion is still that we should make the core do the async handling.
I think that we let USB dictate how APIs for HID should look like.
However that is maybe fine anyway since the Bluetooth HID guys where not
really inventive since they copying USB HID for the better and mostly
for the worst. Especially since Bluetooth doesn't have the endpoint
direction limits like USB does. Anyhow, just get the patches re-based
and re-submitted and I can have a second look.
Regards
Marcel
^ permalink raw reply
* Re: e1000e crashes with 2.6.34.x and ThinkPad T60
From: Marc Haber @ 2010-08-10 12:04 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: Marc Haber, Linux Kernel Developers,
Linux Kernel Network Developers, Allan, Bruce W
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A13660024083FE@rrsmsx501.amr.corp.intel.com>
On Wed, Aug 04, 2010 at 12:23:45PM -0600, Tantilov, Emil S wrote:
> Looking at your lspci output - your system has a slightly different HW, but I don't know if this is significant.
>
> Are you loading the kernel with any parameters (cat /proc/cmdline)?
BOOT_IMAGE=/vmlinuz-2.6.35-zgws1 root=/dev/mapper/root ro
resume=/dev/mapper/swap0 quiet splash radeon.modeset=1
> Do you have firewall configured (iptables -L)?
I am working pretty intensively with virtual machines which are natted
here and there. I have a handful of MASQUERADE rules in the
nat/POSTROUTING chain, but that's it.
> Also now that 2.6.35 is out - could you give it a try and see if the situation had improved?
Tried, no improvement.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* Re: e1000e crashes with 2.6.34.x and ThinkPad T60
From: Marc Haber @ 2010-08-10 12:02 UTC (permalink / raw)
To: Chuck Ebbert
Cc: Marc Haber, Allan, Bruce W, Linux Kernel Developers,
Linux Kernel Network Developers,
e1000-devel@lists.sourceforge.net
In-Reply-To: <20100806014610.2bd64d44@katamari>
On Fri, Aug 06, 2010 at 01:46:10AM -0400, Chuck Ebbert wrote:
> On Fri, 30 Jul 2010 14:56:14 +0200
> Marc Haber <mh+linux-kernel@zugschlus.de> wrote:
>
> > Capabilities: <access denied>
>
> That's not very useful.
>
> The pcie capabilities are completely missing.
Again, apologizes. The attached lspci -vvv is from 2.6.35, right after
the first freeze with this kernel version.
Greetings
Marc
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
Subsystem: Lenovo ThinkPad T60
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: Len=09 <?>
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: ee100000-ee1fffff
Prefetchable memory behind bridge: 00000000d8000000-00000000dfffffff
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: [88] Subsystem: Lenovo Device 2014
Capabilities: [80] 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: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4161
Capabilities: [a0] Express (v1) 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 #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <1us, L1 <4us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #1, PowerLimit 75.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Off, PwrInd On, 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-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [140 v1] Root Complex Link
Desc: PortNumber=02 ComponentID=01 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed19000
Kernel driver in use: pcieport
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
Subsystem: Lenovo ThinkPad T60/R60 series
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 49
Region 0: Memory at ee400000 (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: 00000000fee0300c Data: 41c1
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 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=80
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: HDA Intel
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) (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: 00003000-00003fff
Memory behind bridge: ee000000-ee0fffff
Prefetchable memory behind bridge: 00000000c0000000-00000000c01fffff
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 (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
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 <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+ Surprise+
Slot #2, PowerLimit 6.500W; 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-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4169
Capabilities: [90] Subsystem: Lenovo Device 2011
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-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=01 ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c001
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00004000-00005fff
Memory behind bridge: ec000000-edffffff
Prefetchable memory behind bridge: 00000000e4000000-00000000e40fffff
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 (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
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 #2, 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+ Surprise+
Slot #3, PowerLimit 6.500W; 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-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4171
Capabilities: [90] Subsystem: Lenovo Device 2011
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-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=02 ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c001
Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) (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=04, subordinate=0b, sec-latency=0
I/O behind bridge: 00006000-00007fff
Memory behind bridge: e8000000-e9ffffff
Prefetchable memory behind bridge: 00000000e4100000-00000000e41fffff
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 (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
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 #3, 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+ Surprise+
Slot #4, PowerLimit 6.500W; 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-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4179
Capabilities: [90] Subsystem: Lenovo Device 2011
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-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=03 ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c001
Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02) (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=0c, subordinate=13, sec-latency=0
I/O behind bridge: 00008000-00009fff
Memory behind bridge: ea000000-ebffffff
Prefetchable memory behind bridge: 00000000e4200000-00000000e42fffff
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 (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
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+ Surprise+
Slot #5, PowerLimit 6.500W; 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-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4181
Capabilities: [90] Subsystem: Lenovo Device 2011
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-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=04 ComponentID=02 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c001
Kernel driver in use: pcieport
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 4: I/O ports at 1800 [size=32]
Kernel driver in use: uhci_hcd
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 17
Region 4: I/O ports at 1820 [size=32]
Kernel driver in use: uhci_hcd
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at 1840 [size=32]
Kernel driver in use: uhci_hcd
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
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 4: I/O ports at 1860 [size=32]
Kernel driver in use: uhci_hcd
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
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 ee404000 (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
Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=15, subordinate=18, sec-latency=32
I/O behind bridge: 0000a000-0000dfff
Memory behind bridge: e4300000-e7ffffff
Prefetchable memory behind bridge: 00000000e0000000-00000000e3ffffff
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 2013
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
Subsystem: Lenovo ThinkPad T60/R60 series
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: Len=0c <?>
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Lenovo ThinkPad T60/R60 series
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 16
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4 [size=1]
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374 [size=1]
Region 4: I/O ports at 1880 [size=16]
Kernel driver in use: ata_piix
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo ThinkPad T60/R60 series
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 45
Region 0: I/O ports at 18c8 [size=8]
Region 1: I/O ports at 18ac [size=4]
Region 2: I/O ports at 18c0 [size=8]
Region 3: I/O ports at 18a8 [size=4]
Region 4: I/O ports at 18b0 [size=16]
Region 5: Memory at ee404400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4189
Capabilities: [70] 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: ahci
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
Subsystem: Lenovo ThinkPad T60/R60 series
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 23
Region 4: I/O ports at 18e0 [size=32]
Kernel driver in use: i801_smbus
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400 (prog-if 00 [VGA controller])
Subsystem: Lenovo Thinkpad T60 model 2007
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 46
Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at 2000 [size=256]
Region 2: Memory at ee100000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at ee120000 [disabled] [size=128K]
Capabilities: [50] 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: [58] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- 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 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 4191
Kernel driver in use: radeon
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
Subsystem: Lenovo ThinkPad T60
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 47
Region 0: Memory at ee000000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at 3000 [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: 00000000fee0300c Data: 41e1
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
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 v1] 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: 14, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-16-41-ff-ff-aa-be-37
Kernel driver in use: e1000e
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
Subsystem: Intel Corporation ThinkPad R60e/X60s
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 48
Region 0: Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
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=0 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0100c Data: 41b9
Capabilities: [e0] Express (v1) Legacy 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+
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 <64us
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 v1] 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: 14, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-18-de-ff-ff-9d-59-43
Kernel driver in use: iwl3945
15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller
Subsystem: Lenovo ThinkPad T60/R60 series
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 168, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at e4300000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=15, secondary=16, subordinate=17, sec-latency=176
Memory window 0: e0000000-e3fff000 (prefetchable)
Memory window 1: c4000000-c7fff000
I/O window 0: 0000a000-0000a0ff
I/O window 1: 0000a400-0000a4ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
Kernel driver in use: yenta_cardbus
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Jiri Kosina @ 2010-08-10 11:46 UTC (permalink / raw)
To: Alan Ott
Cc: Marcel Holtmann, David S Miller, Michael Poole, Bastien Nocera,
Eric Dumazet, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C4878C2.9000903-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
On Thu, 22 Jul 2010, Alan Ott wrote:
> > that the ioctl() API is synchronous is fine to me, however pushing that
> > down to the transport drivers seems wrong to me. I think the HID core
> > should be able to handle a fully asynchronous transport driver. I know
> > that with the USB subsystem you are little bit spoiled here, but for
> > Bluetooth it is not the case. And in the end even using the asynchronous
> > USB URB calls would be nice as well.
> >
>
> How are the URB calls better than using the synchronous calls? (see below)
Hi,
I think this was the last mail in the thread so far, right?
> > So why not make the core actually wait for responses from the transport
> > driver.
>
> Because this makes the USB side a lot more complicated, and it would
> introduce transport specific code into the core. Further, it would
> involve the transport driver calling hidraw with _every_ single packet
> it receives. Further, it would have to call hidraw with HANDSHAKE
> protocol error packets as well.
>
> > I would make the transport drivers a lot simpler in the long
> > run.
>
> It would make the USB transport driver and drivers/hid/hidraw much more
> complicated right now, at the expense of making the BT transport driver
> marginally simpler (and I'm not even convinced whether it would really be
> simpler). (see below for more)
Seconded.
> > And I know that most likely besides Bluetooth and USB you won't see
> > another, but you never know.
> >
> I just don't understand the objection. In each transport type, the waiting
> will have to be done in a different way. USB and BT are different enough that
> this is the case already, without having to imagine future buses which use
> HID. In BT, you have to check each packet which comes back from the BT network
> to see whether it is the response packet that hidraw is waiting for. Further,
> you have to check for HANDSHAKE packets indicating protocol error. Where
> better for this to be done than in hidp? Further, how can this possibly happen
> in drivers/hid/hidraw, as it doesn't know about the details of bluetooth to
> make this determination, and why should it? In my last email (
> http://lkml.org/lkml/2010/7/9/231 ) to which I got no response, I laid out how
> doing the blocking in drivers/hid/hidraw would only make all the parts except
> bluetooth more complicated (including the core, and the USB side), and would
> also introduce bluetooth-specific things into the core.
>
> Further, you're saying that using the asynchronous USB URB calls would be a
> benefit. How is it a benefit to replace a single function call which does
> exactly what I want, with a set of asynchronous calls and then adding my own
> blocking to make it do the same thing? This sounds to me like it would be 1:
> more text, 2: duplication of code, 3: error prone. I can't understand how this
> is of benefit. Please explain to me what I'm missing.
>
> In theory, what you're saying makes sense. Making common code and logic
> actually common is always good. In practice though, in this case, I submit
> that there really isn't any commonality, and the only way for there to be
> commonality is to do the USB side the hard way. Further, drivers/hid/hidraw
> can't wait for a bluetooth packet without having code that's
> bluetooth-specific. It seems just that simple to me.
>
> I'll give it some more thought, and take another look at the code to see if
> there's something obvious that I'm missing. If you know what I'm missing in my
> understanding of the problem, please tell me :)
Marcel, did you have time to review Alan's explanation a little bit?
I must say I would really like to have this feature merged, but of course
not if you completely disagree .. but then we'll have to find some
consensus. Currently Alan's summary above quite aligns with my opinion.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [PATCH] net: add Fast Ethernet driver for PXA168.
From: Lennert Buytenhek @ 2010-08-10 11:40 UTC (permalink / raw)
To: Philip Rakity
Cc: Sachin Sanap, netdev@vger.kernel.org, Ashish Karkare,
Prabhanjan Sarnaik, eric.y.miao@gmail.com, Mark Brown
In-Reply-To: <26AE03C2-9D1A-4E63-82E3-DD47BD451B70@marvell.com>
On Fri, Aug 06, 2010 at 08:44:02AM -0700, Philip Rakity wrote:
> You should change
>
> >>> + skb = dev_alloc_skb(MAX_PKT_SIZE + ETH_HW_IP_ALIGN);
>
> >>
>
> to allocatie ADDITIONAL prepend space in the header. If you are doing
> ethernet to 802.11 routing or bridging then the wireless driver will
> not have enough space in front of the header to prepend its headers
> without having to allocate additional space.
This seems like something that, should you want to handle it, should be
handled centrally (e.g. by conditionally increasing NET_SKB_PAD or so)
and not hardcoded into one specific driver only.
^ permalink raw reply
* Re: [RFC PATCH 1/2] pci: add function reset call that can be used inside of probe
From: Kenji Kaneshige @ 2010-08-10 10:39 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, jbarnes, netdev, linux-pci, Alexander Duyck
In-Reply-To: <20100731005803.32625.6891.stgit@localhost.localdomain>
(2010/07/31 9:58), Jeff Kirsher wrote:
> From: Alexander Duyck<alexander.h.duyck@intel.com>
>
> This change makes it so that there are several new calls available.
>
> The first is __pci_reset_dev which works similar to pci_reset_dev, however
> it does not obtain the device lock. This is important as I found several
> cases such as __pci_reset_function in which the call was obtaining the
> device lock even though the lock had yet to be initialized. In addition if
> one wishes to do such a reset during probe it will hang since the device
> lock is already being held.
>
> The second change that was added was a function named
> pci_reset_device_function. This function is similar to pci_reset_function
> however it does not hold the device lock and so it as well can be called
> during the driver probe routine.
>
> Signed-off-by: Alexander Duyck<alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> ---
>
> drivers/pci/pci.c | 74 +++++++++++++++++++++++++++++++++++++++++++--------
> include/linux/pci.h | 1 +
> 2 files changed, 64 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 60f30e7..1421bc7 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2445,17 +2445,14 @@ static int pci_parent_bus_reset(struct pci_dev *dev, int probe)
> return 0;
> }
>
> -static int pci_dev_reset(struct pci_dev *dev, int probe)
> +static int __pci_dev_reset(struct pci_dev *dev, int probe)
> {
> int rc;
>
> might_sleep();
>
> - if (!probe) {
> + if (!probe)
> pci_block_user_cfg_access(dev);
> - /* block PM suspend, driver probe, etc. */
> - device_lock(&dev->dev);
> - }
>
> rc = pci_dev_specific_reset(dev, probe);
> if (rc != -ENOTTY)
> @@ -2474,11 +2471,26 @@ static int pci_dev_reset(struct pci_dev *dev, int probe)
> goto done;
>
> rc = pci_parent_bus_reset(dev, probe);
> +
> done:
> - if (!probe) {
> - device_unlock(&dev->dev);
> + if (!probe)
> pci_unblock_user_cfg_access(dev);
> - }
> +
> + return rc;
> +}
> +
> +static int pci_dev_reset(struct pci_dev *dev, int probe)
> +{
> + int rc;
> +
> + /* block PM suspend, driver probe, etc. */
> + if (!probe)
> + device_lock(&dev->dev);
> +
> + rc = __pci_dev_reset(dev, probe);
> +
> + if (!probe)
> + device_unlock(&dev->dev);
>
> return rc;
> }
> @@ -2502,7 +2514,7 @@ done:
> */
> int __pci_reset_function(struct pci_dev *dev)
> {
> - return pci_dev_reset(dev, 0);
> + return __pci_dev_reset(dev, 0);
> }
> EXPORT_SYMBOL_GPL(__pci_reset_function);
>
> @@ -2519,7 +2531,7 @@ EXPORT_SYMBOL_GPL(__pci_reset_function);
> */
> int pci_probe_reset_function(struct pci_dev *dev)
> {
> - return pci_dev_reset(dev, 1);
> + return __pci_dev_reset(dev, 1);
> }
>
> /**
> @@ -2542,7 +2554,7 @@ int pci_reset_function(struct pci_dev *dev)
> {
> int rc;
>
> - rc = pci_dev_reset(dev, 1);
> + rc = __pci_dev_reset(dev, 1);
> if (rc)
> return rc;
>
> @@ -2563,6 +2575,46 @@ int pci_reset_function(struct pci_dev *dev)
> EXPORT_SYMBOL_GPL(pci_reset_function);
>
> /**
> + * pci_reset_device_function - quiesce and reinitialize a PCI device function
> + * @dev: PCI device to reset
> + *
> + * Some devices allow an individual function to be reset without affecting
> + * other functions in the same device. The PCI device must be responsive
> + * to PCI config space in order to use this function.
> + *
> + * This function is very similar to pci_reset_function, however this function
> + * does not obtain the device lock during the reset. This is due to the fact
> + * that the call is meant to be used during probe if the reset_devices
> + * kernel parameter is set.
> + *
> + * Returns 0 if the device function was successfully reset or negative if the
> + * device doesn't support resetting a single function.
> + */
> +int pci_reset_device_function(struct pci_dev *dev)
> +{
> + int rc;
> +
> + rc = __pci_dev_reset(dev, 1);
> + if (rc)
> + return rc;
> +
> + pci_save_state(dev);
> +
> + /*
> + * both INTx and MSI are disabled after the Interrupt Disable bit
> + * is set and the Bus Master bit is cleared.
> + */
> + pci_write_config_word(dev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);
> +
> + rc = __pci_dev_reset(dev, 0);
Could you tell me why you need to program command register before reset?
"MSI enable" and "Bus Master" bits are cleared by the reset. Furthermore,
resetting the device clears the "Interrupt Disable bit", even though it
was set just before the rest. So I'm a little confused.
Thanks,
Kenji Kaneshige
^ permalink raw reply
* Re: [RFC] [PATCH] Don't destroy TCP sockets twice
From: Herbert Xu @ 2010-08-10 10:39 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <20100810103206.GC6801@basil.fritz.box>
On Tue, Aug 10, 2010 at 12:32:06PM +0200, Andi Kleen wrote:
>
> Yes I stored the backtrace of the first caller in the ugly debug
> patches and dumped that on the second destroy. It was tcp_done the
> first time.
>
> Also did the same for tcp_sk() and there it was the fin sending.
>
> I agree that tcp_close() should skip it in theory but I saw
> it anyways :/
So I presume the second caller was tcp_close? That means we have
a serious bug in our stack, as if the socket is already in the
CLOSE state then tcp_close should have short-circuited.
This means that something is changing the TCP socket state after
going into CLOSE. Can you try adding your debug backtrace patch to
tcp_set_state to see if anybody is indeed changing the socket
state after going into CLOSE (and more importantly who is changing
it)?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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