twitter: linux.kernel - 26 new messages in 17 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* sound/soc/codecs: Correct code taking the size of a pointer - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/6b6a164c0505e138?hl=en
* Convert Documentation/ to asciidoc? - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/62bd59a1beb04740?hl=en
* drivers/net/cpmac.c: Correct code taking the size of a pointer - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/2c9e8c119d04026f?hl=en
* drivers/net/usb: Correct code taking the size of a pointer - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e07e747e7004379a?hl=en
* nfs broken in net-next? -- now in mainline -- bisected: d9f5950f90292f7cc
42834338dfd5f44dc4cc4ca - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0daf87e388e61614?hl=en
* Are these MTRR settings correct? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ee98ace36c359c1f?hl=en
* nconfig v7 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e6f520d6c713a34a?hl=en
* Async suspend-resume patch w/ completions (was: Re: Async suspend-resume
patch w/ rwsems) - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/744b2baf61c0ac2a?hl=en
* TTY patches for 2.6.33-git - 6 messages, 5 authors
http://groups.google.com/group/linux.kernel/t/1e09e9b25fa77b60?hl=en
* ftrace.h: Use common pr_info fmt string - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/53039310827bd848?hl=en
* Poor KVM guest performance on an HP rack server - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/454ae5bda4756254?hl=en
* RFC: new kqueue API - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/959114a87facd3e4?hl=en
* LTTng 0.181 for Linux kernel 2.6.32 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/34079b18b4556286?hl=en
* Fix various __task_cred related invalid RCU assumptions - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/67b4e9e8ac2af84a?hl=en
* ksoftirqd problem - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/db92cb20826e2f64?hl=en
* : Networking - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9ff0256420d73f04?hl=en
* Please pull NFS client updates and bugfixes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1df72db3f9de8a54?hl=en

==============================================================================
TOPIC: sound/soc/codecs: Correct code taking the size of a pointer
http://groups.google.com/group/linux.kernel/t/6b6a164c0505e138?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 7:30 am
From: Julia Lawall

On Sun, 13 Dec 2009, walter harms wrote:

>
>
> Julia Lawall schrieb:
> > From: Julia Lawall <julia@diku.dk>
> >
> > sizeof(codec->reg_cache) is just the size of the pointer. Elsewhere in the
> > file, codec->reg_cache is used with sizeof(wm8900_reg_defaults), so the
> > code is changed to do the same here.
> >
> > A simplified version of the semantic patch that finds this problem is as
> > follows: (http://coccinelle.lip6.fr/)
> >
> > // <smpl>
> > @@
> > expression *x;
> > expression f;
> > type T;
> > @@
> >
> > *f(...,(T)x,...)
> > // </smpl>
> >
> > Signed-off-by: Julia Lawall <julia@diku.dk>
> >
> > ---
> > sound/soc/codecs/wm8900.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/sound/soc/codecs/wm8900.c b/sound/soc/codecs/wm8900.c
> > index c9438dd..dbc368c 100644
> > --- a/sound/soc/codecs/wm8900.c
> > +++ b/sound/soc/codecs/wm8900.c
> > @@ -199,7 +199,7 @@ static void wm8900_reset(struct snd_soc_codec *codec)
> > snd_soc_write(codec, WM8900_REG_RESET, 0);
> >
> > memcpy(codec->reg_cache, wm8900_reg_defaults,
> > - sizeof(codec->reg_cache));
> > + sizeof(wm8900_reg_defaults));
> > }
>
> I do not think that this was the intention of the original author,
> I guess the idea behind sizeof(*codec->reg_cache) was to protect
> the area behind it (in case wm8900_reg_defaults are badly defined).

sizeof(codec->reg_cache) is the size of a pointer (void *).
sizeof(*codec->reg_cache) is then the size of void. wm8900_reg_defaults
is a static constant array defined a few lines before this code:

static const u16 wm8900_reg_defaults[WM8900_MAXREG] = { ... };

Later in the same file there is:

cache = kmemdup(codec->reg_cache, sizeof(wm8900_reg_defaults),
GFP_KERNEL);

and codec->reg_cache is initialized as follows:

codec->reg_cache = &wm8900->reg_cache[0];

The reg_cache field in wm8900 is declared as u16 reg_cache[WM8900_MAXREG];

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Convert Documentation/ to asciidoc?
http://groups.google.com/group/linux.kernel/t/62bd59a1beb04740?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Dec 13 2009 7:40 am
From: Diego Calleja

Git uses asciidoc, tools/perf/Documentation uses asciidoc... It seems
a good fit for Documentation/. Is there any objection against it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Sun, Dec 13 2009 9:30 am
From: Randy Dunlap

On Sun, 13 Dec 2009 16:38:55 +0100 Diego Calleja wrote:

> Git uses asciidoc, tools/perf/Documentation uses asciidoc... It seems
> a good fit for Documentation/. Is there any objection against it?
> --

I think I'd like to see it, but I can only say for sure after
I see the results. OTOH, Matt Mackall didn't care for it the
last time that this was brought up.

---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Sun, Dec 13 2009 10:00 am
From: Matt Mackall

On Sun, Dec 13, 2009 at 09:29:30AM -0800, Randy Dunlap wrote:
> On Sun, 13 Dec 2009 16:38:55 +0100 Diego Calleja wrote:
>
> > Git uses asciidoc, tools/perf/Documentation uses asciidoc... It seems
> > a good fit for Documentation/. Is there any objection against it?
> > --
>
> I think I'd like to see it, but I can only say for sure after
> I see the results. OTOH, Matt Mackall didn't care for it the
> last time that this was brought up.

Mercurial adopted asciidoc early on, and our experience with it wasn't
great - it had many difficult to work around quirks. We eventually
built our own parser for a subset of 'restructured text' to generate
our help messages and build our docs.

I think if we're going to go down a mark-up road for Documentation/,
we're going to need to roll our own tool and make it aware of
kerneldoc and so forth.

--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: drivers/net/cpmac.c: Correct code taking the size of a pointer
http://groups.google.com/group/linux.kernel/t/2c9e8c119d04026f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 7:40 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

sizeof(dev->dev_addr) is the size of a pointer. On the other hand,
sizeof(pdata->dev_addr) is the size of an array, so use that instead.

A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression *x;
expression f;
type T;
@@

*f(...,(T)x,...)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>

---
drivers/net/cpmac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/cpmac.c b/drivers/net/cpmac.c
index 6782223..8d0be26 100644
--- a/drivers/net/cpmac.c
+++ b/drivers/net/cpmac.c
@@ -1163,7 +1163,7 @@ static int __devinit cpmac_probe(struct platform_device *pdev)
priv->dev = dev;
priv->ring_size = 64;
priv->msg_enable = netif_msg_init(debug_level, 0xff);
- memcpy(dev->dev_addr, pdata->dev_addr, sizeof(dev->dev_addr));
+ memcpy(dev->dev_addr, pdata->dev_addr, sizeof(pdata->dev_addr));

snprintf(priv->phy_name, MII_BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id, phy_id);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: drivers/net/usb: Correct code taking the size of a pointer
http://groups.google.com/group/linux.kernel/t/e07e747e7004379a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 7:50 am
From: Julia Lawall

From: Julia Lawall <julia@diku.dk>

sizeof(dev->dev_addr) is the size of a pointer. A few lines above, the
size of this field is obtained using netdev->addr_len for a call to memcpy,
so do the same here.

A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression *x;
expression f;
type T;
@@

*f(...,(T)x,...)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>

---
drivers/net/usb/rtl8150.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index b091e20..f14d225 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -324,7 +324,7 @@ static int rtl8150_set_mac_address(struct net_device *netdev, void *p)
dbg("%02X:", netdev->dev_addr[i]);
dbg("%02X\n", netdev->dev_addr[i]);
/* Set the IDR registers. */
- set_registers(dev, IDR, sizeof(netdev->dev_addr), netdev->dev_addr);
+ set_registers(dev, IDR, netdev->addr_len, netdev->dev_addr);
#ifdef EEPROM_WRITE
{
u8 cr;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: nfs broken in net-next? -- now in mainline -- bisected: d9f5950f90292f7
cc42834338dfd5f44dc4cc4ca
http://groups.google.com/group/linux.kernel/t/0daf87e388e61614?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 9:00 am
From: Eric Dumazet

Le 13/12/2009 03:41, Yinghai Lu a �crit :
>
>>> cause the problem: nfs mount fail.
>>>
>>> the setup is:
>>> 64bit kernel, have all needed drivers in kernel, and boot with
>>> ip=dhcp, root disk is 256M ramdisk.
>>> then try to mount nfs....
>>>
>>
>> change entries default value from 65536 to 256,
>> nfs mount will work.
>>
> interesting:
>
> m:~/dump # grep UDP dmesg.txt
> [ 28.996034] UDP hash table entries: 65536 (order: 11, 10485760 bytes)
> [ 29.032364] UDP-Lite hash table entries: 65536 (order: 11, 10485760 bytes)
>
> will not work
>
> but 32768 will work.

Thanks a lot for this work Yinghai !
This last bit helped me a lot ...

Hmm, udp_lib_get_port() assumes it can loop at least one time in :

for (last = first + udptable->mask + 1;
first != last;
first++) {
// unit_work
}

but if udptable->mask == 65535, loop is not entered at all (since last == first)

We should convert it to a do { } while(...); construct, or use 32bit variables
and (u16) casts.

Thanks

[PATCH] udp: udp_lib_get_port() fix

Now we can have a large udp hash table, udp_lib_get_port() loop
should be converted to a do {} while (cond) form,
or we dont enter it at all if hash table size is exactly 65536.

Reported-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 1f95348..f0126fd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -216,9 +216,8 @@ int udp_lib_get_port(struct sock *sk, unsigned short snum,
* force rand to be an odd multiple of UDP_HTABLE_SIZE
*/
rand = (rand | 1) * (udptable->mask + 1);
- for (last = first + udptable->mask + 1;
- first != last;
- first++) {
+ last = first + udptable->mask + 1;
+ do {
hslot = udp_hashslot(udptable, net, first);
bitmap_zero(bitmap, PORTS_PER_CHAIN);
spin_lock_bh(&hslot->lock);
@@ -238,7 +237,7 @@ int udp_lib_get_port(struct sock *sk, unsigned short snum,
snum += rand;
} while (snum != first);
spin_unlock_bh(&hslot->lock);
- }
+ } while (++first != last);
goto fail;
} else {
hslot = udp_hashslot(udptable, net, snum);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Are these MTRR settings correct?
http://groups.google.com/group/linux.kernel/t/ee98ace36c359c1f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 9:20 am
From: Tvrtko Ursulin

On Sunday 13 Dec 2009 09:25:33 Yinghai Lu wrote:
> On Sun, Dec 13, 2009 at 12:26 AM, Tvrtko Ursulin <tvrtko@ursulin.net> wrote:
> > reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
> > reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
> > reg02: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-back
> > reg03: base=0x0f0000000 ( 3840MB), size= 128MB, count=1: write-combining
> >
> > Still looks like from 3328MB to 3840MB is of status unknown?
> >
> > dmesg in that case:
> >
> > [ 0.000000] Linux version 2.6.32 (tvrtko@deuteros) (gcc version 4.4.1
> > [gcc-4_4-branch revision 150839] (SUSE Linux) ) #2 SMP PREEMPT Sat Dec 12
> > 20:44:59 GMT 2009
> > [ 0.000000] Command line:
> > root=UUID="78df20fb-791f-4a82-b1d6-4e043aa663d1"
> > resume=UUID="fc2d8cd0-fed3-4196-b346-83de887dfcf7" splash=silent quiet
> > vga=0x31a 3
> > [ 0.000000] KERNEL supported cpus:
> > [ 0.000000] Intel GenuineIntel
> > [ 0.000000] AMD AuthenticAMD
> > [ 0.000000] Centaur CentaurHauls
> > [ 0.000000] BIOS-provided physical RAM map:
> > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
> > [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
> > [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
> > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cff90000 (usable)
> > [ 0.000000] BIOS-e820: 00000000cff90000 - 00000000cffa8000 (ACPI
> > data) [ 0.000000] BIOS-e820: 00000000cffa8000 - 00000000cffd0000
> > (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cffd0000 - 00000000d0000000
> > (reserved) [ 0.000000] BIOS-e820: 00000000ff700000 - 0000000100000000
> > (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000130000000
> > (usable) [ 0.000000] DMI present.
> > [ 0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working
> > around it. [ 0.000000] e820 update range: 0000000000000000 -
> > 0000000000010000 (usable) ==> (reserved) [ 0.000000] last_pfn =
> > 0x130000 max_arch_pfn = 0x400000000
> > [ 0.000000] MTRR default type: uncachable
> > [ 0.000000] MTRR fixed ranges enabled:
> > [ 0.000000] 00000-9FFFF write-back
> > [ 0.000000] A0000-EFFFF uncachable
> > [ 0.000000] F0000-FFFFF write-protect
> > [ 0.000000] MTRR variable ranges enabled:
> > [ 0.000000] 0 base 000000000000 mask FFFF80000000 write-back
> > [ 0.000000] 1 base 000080000000 mask FFFFC0000000 write-back
> > [ 0.000000] 2 base 0000C0000000 mask FFFFF0000000 write-back
> > [ 0.000000] 3 disabled
> > [ 0.000000] 4 disabled
> > [ 0.000000] 5 disabled
> > [ 0.000000] 6 disabled
> > [ 0.000000] 7 disabled
> > [ 0.000000] TOM2: 0000000130000000 aka 4864M
>
> that [d0000000, e0000000) is to mmio space.
>
> your var mtrrs is covering [0, d0000000)
>
> and AMD K8 Rev F, will auto cover your [4G, TOM2) aka [4G, 4G+3*256M) to WB
> ... ...

I read this as everything is OK and nothing to worry about, correct?

> > [ 0.251043] node 0 link 0: io port [1000, ffffff]
> > [ 0.251045] TOM: 00000000d0000000 aka 3328M
> > [ 0.251046] Fam 10h mmconf [e0000000, efffffff]
> > [ 0.251048] node 0 link 0: mmio [a0000, bffff]
> > [ 0.251050] node 0 link 0: mmio [d0000000, dfffffff]
> > [ 0.251051] node 0 link 0: mmio [e0000000, efffffff] ==> none
> > [ 0.251053] node 0 link 0: mmio [f0000000, fe7fffff]
> > [ 0.251055] node 0 link 0: mmio [fe800000, fe9fffff]
> > [ 0.251056] node 0 link 0: mmio [fea00000, ffefffff]
> > [ 0.251058] TOM2: 0000000130000000 aka 4864M
> > [ 0.251059] bus: [00,07] on node 0 link 0
> > [ 0.251060] bus: 00 index 0 io port: [0, ffff]
> > [ 0.251062] bus: 00 index 1 mmio: [a0000, bffff]
> > [ 0.251063] bus: 00 index 2 mmio: [d0000000, dfffffff]
> > [ 0.251064] bus: 00 index 3 mmio: [f0000000, ffffffff]
> > [ 0.251065] bus: 00 index 4 mmio: [130000000, fcffffffff]
> > [ 0.251072] ACPI: bus type pci registered
> > [ 0.251107] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0
> > - 255 [ 0.251109] PCI: Not using MMCONFIG.
> > [ 0.251110] PCI: Using configuration type 1 for base access
> > [ 0.251111] PCI: Using configuration type 1 for extended access
>
> only concern that is your BIOS doesn't have [e000000, F0000000)
> reserved in e820 or acpi etc.
>
> you could try to use "pci=check_enable_amd_mmconf" in boot command
> line to enable it.

This produced some differences in kernel output but I don't know if they are for better or worse. I will paste it the latest output here.

[ 0.000000] Linux version 2.6.32 (tvrtko@deuteros) (gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) ) #2 SMP PREEMPT Sat
Dec 12 20:44:59 GMT 2009
[ 0.000000] Command line: pci=check_enable_amd_mmconf root=UUID="78df20fb-791f-4a82-b1d6-4e043aa663d1"
resume=UUID="fc2d8cd0-fed3-4196-b346-83de887dfcf7" splash=silent quiet vga=0x31a
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
[ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000dff90000 (usable)
[ 0.000000] BIOS-e820: 00000000dff90000 - 00000000dffa8000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000dffa8000 - 00000000dffd0000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000dffd0000 - 00000000e0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
[ 0.000000] DMI present.
[ 0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working around it.
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] last_pfn = 0x120000 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-EFFFF uncachable
[ 0.000000] F0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000000 mask FFFF80000000 write-back
[ 0.000000] 1 base 000080000000 mask FFFFC0000000 write-back
[ 0.000000] 2 base 0000C0000000 mask FFFFE0000000 write-back
[ 0.000000] 3 disabled
[ 0.000000] 4 disabled
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] TOM2: 0000000120000000 aka 4608M
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] e820 update range: 00000000e0000000 - 0000000100000000 (usable) ==> (reserved)
[ 0.000000] last_pfn = 0xdff90 max_arch_pfn = 0x400000000
[ 0.000000] Scanning 0 areas for low memory corruption
[ 0.000000] modified physical RAM map:
[ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
[ 0.000000] modified: 0000000000010000 - 000000000009ec00 (usable)
[ 0.000000] modified: 000000000009ec00 - 00000000000a0000 (reserved)
[ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved)
[ 0.000000] modified: 0000000000100000 - 00000000dff90000 (usable)
[ 0.000000] modified: 00000000dff90000 - 00000000dffa8000 (ACPI data)
[ 0.000000] modified: 00000000dffa8000 - 00000000dffd0000 (ACPI NVS)
[ 0.000000] modified: 00000000dffd0000 - 00000000e0000000 (reserved)
[ 0.000000] modified: 00000000ff700000 - 0000000100000000 (reserved)
[ 0.000000] modified: 0000000100000000 - 0000000120000000 (usable)
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] Using GB pages for direct mapping
[ 0.000000] init_memory_mapping: 0000000000000000-00000000dff90000
[ 0.000000] 0000000000 - 00c0000000 page 1G
[ 0.000000] 00c0000000 - 00dfe00000 page 2M
[ 0.000000] 00dfe00000 - 00dff90000 page 4k
[ 0.000000] kernel direct mapping tables up to dff90000 @ 10000-13000
[ 0.000000] init_memory_mapping: 0000000100000000-0000000120000000
[ 0.000000] 0100000000 - 0120000000 page 2M
[ 0.000000] kernel direct mapping tables up to 120000000 @ 12000-14000
[ 0.000000] RAMDISK: 379ea000 - 37fef00a
[ 0.000000] ACPI: RSDP 00000000000fb4f0 00024 (v02 ACPIAM)
[ 0.000000] ACPI: XSDT 00000000dff90100 00054 (v01 112609 XSDT1132 20091126 MSFT 00000097)
[ 0.000000] ACPI: FACP 00000000dff90290 000F4 (v03 112609 FACP1132 20091126 MSFT 00000097)
[ 0.000000] ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0000000000000000/1 (20090903/tbfadt-557)
[ 0.000000] ACPI: DSDT 00000000dff90450 0D100 (v01 A1391 A1391001 00000001 INTL 20060113)
[ 0.000000] ACPI: FACS 00000000dffa8000 00040
[ 0.000000] ACPI: APIC 00000000dff90390 0007C (v01 112609 APIC1132 20091126 MSFT 00000097)
[ 0.000000] ACPI: MCFG 00000000dff90410 0003C (v01 112609 OEMMCFG 20091126 MSFT 00000097)
[ 0.000000] ACPI: OEMB 00000000dffa8040 00072 (v01 112609 OEMB1132 20091126 MSFT 00000097)
[ 0.000000] ACPI: HPET 00000000dff9f450 00038 (v01 112609 OEMHPET 20091126 MSFT 00000097)
[ 0.000000] ACPI: SSDT 00000000dff9f490 0088C (v01 A M I POWERNOW 00000001 AMD 00000001)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at 0000000000000000-0000000120000000
[ 0.000000] Bootmem setup node 0 0000000000000000-0000000120000000
[ 0.000000] NODE_DATA [0000000000013000 - 0000000000014fff]
[ 0.000000] bootmap [0000000000015000 - 0000000000038fff] pages 24
[ 0.000000] (8 early reservations) ==> bootmem [0000000000 - 0120000000]
[ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
[ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
[ 0.000000] #2 [0001000000 - 000166476c] TEXT DATA BSS ==> [0001000000 - 000166476c]
[ 0.000000] #3 [00379ea000 - 0037fef00a] RAMDISK ==> [00379ea000 - 0037fef00a]
[ 0.000000] #4 [000009ec00 - 0000100000] BIOS reserved ==> [000009ec00 - 0000100000]
[ 0.000000] #5 [0001665000 - 0001665340] BRK ==> [0001665000 - 0001665340]
[ 0.000000] #6 [0000010000 - 0000012000] PGTABLE ==> [0000010000 - 0000012000]
[ 0.000000] #7 [0000012000 - 0000013000] PGTABLE ==> [0000012000 - 0000013000]
[ 0.000000] [ffffea0000000000-ffffea0003ffffff] PMD -> [ffff880028600000-ffff88002bffffff] on node 0
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal 0x00100000 -> 0x00120000
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[3] active PFN ranges
[ 0.000000] 0: 0x00000010 -> 0x0000009e
[ 0.000000] 0: 0x00000100 -> 0x000dff90
[ 0.000000] 0: 0x00100000 -> 0x00120000
[ 0.000000] On node 0 totalpages: 1048350
[ 0.000000] DMA zone: 56 pages used for memmap
[ 0.000000] DMA zone: 103 pages reserved
[ 0.000000] DMA zone: 3823 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 14280 pages used for memmap
[ 0.000000] DMA32 zone: 899016 pages, LIFO batch:31
[ 0.000000] Normal zone: 1792 pages used for memmap
[ 0.000000] Normal zone: 129280 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x808
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled)
[ 0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 4, version 33, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
[ 0.000000] 6 Processors exceeds NR_CPUS limit of 4
[ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 24
[ 0.000000] PM: Registered nosave memory: 000000000009e000 - 000000000009f000
[ 0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e4000
[ 0.000000] PM: Registered nosave memory: 00000000000e4000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 00000000dff90000 - 00000000dffa8000
[ 0.000000] PM: Registered nosave memory: 00000000dffa8000 - 00000000dffd0000
[ 0.000000] PM: Registered nosave memory: 00000000dffd0000 - 00000000e0000000
[ 0.000000] PM: Registered nosave memory: 00000000e0000000 - 00000000ff700000
[ 0.000000] PM: Registered nosave memory: 00000000ff700000 - 0000000100000000
[ 0.000000] Allocating PCI resources starting at e0000000 (gap: e0000000:1f700000)
[ 0.000000] NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 25 pages/cpu @ffff880028200000 s72856 r8192 d21352 u524288
[ 0.000000] pcpu-alloc: s72856 r8192 d21352 u524288 alloc=1*2097152
[ 0.000000] pcpu-alloc: [0] 0 1 2 3
[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 1032119
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: pci=check_enable_amd_mmconf root=UUID="78df20fb-791f-4a82-b1d6-4e043aa663d1"
resume=UUID="fc2d8cd0-fed3-4196-b346-83de887dfcf7" splash=silent quiet vga=0x31a
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Initializing CPU#0
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Node 0: aperture @ 20000000 size 32 MB
[ 0.000000] Aperture pointing to e820 RAM. Ignoring.
[ 0.000000] Your BIOS doesn't leave a aperture memory hole
[ 0.000000] Please enable the IOMMU option in the BIOS setup
[ 0.000000] This costs you 64 MB of RAM
[ 0.000000] Mapping aperture over 65536 KB of RAM @ 20000000
[ 0.000000] PM: Registered nosave memory: 0000000020000000 - 0000000024000000
[ 0.000000] Memory: 4055132k/4718592k available (3519k kernel code, 525192k absent, 138268k reserved, 1987k data, 416k init)
[ 0.000000] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Experimental preemptable hierarchical RCU implementation.
[ 0.000000] NR_IRQS:384
[ 0.000000] Extended CMOS year: 2000
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] hpet clockevent registered
[ 0.000000] HPET: 4 timers in total, 1 timers will be used for per-cpu timer
[ 0.000000] Fast TSC calibration using PIT
[ 0.000000] Detected 3013.207 MHz processor.
[ 0.002003] Calibrating delay loop (skipped), value calculated using timer frequency.. 6026.40 BogoMIPS (lpj=3013203)
[ 0.003148] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.004161] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.004637] Mount-cache hash table entries: 256
[ 0.004719] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 0.004720] CPU: L2 Cache: 512K (64 bytes/line)
[ 0.004721] CPU 0/0x0 -> Node 0
[ 0.004723] tseg: 0000000000
[ 0.004729] CPU: Physical Processor ID: 0
[ 0.004730] CPU: Processor Core ID: 0
[ 0.004731] mce: CPU supports 6 MCE banks
[ 0.004737] using C1E aware idle routine
[ 0.004745] ACPI: Core revision 20090903
[ 0.018033] Setting APIC routing to flat
[ 0.018331] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.028368] CPU0: AMD Phenom(tm) II X4 B45 Processor stepping 02
[ 0.028995] Booting processor 1 APIC 0x1 ip 0x6000
[ 0.002999] Initializing CPU#1
[ 0.002999] Calibrating delay using timer specific routine.. 6026.84 BogoMIPS (lpj=3013424)
[ 0.002999] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 0.002999] CPU: L2 Cache: 512K (64 bytes/line)
[ 0.002999] CPU 1/0x1 -> Node 0
[ 0.002999] CPU: Physical Processor ID: 0
[ 0.002999] CPU: Processor Core ID: 1
[ 0.099093] CPU1: AMD Phenom(tm) II X4 B45 Processor stepping 02
[ 0.099098] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[ 0.100006] System has AMD C1E enabled
[ 0.100014] Switch to broadcast mode on CPU0
[ 0.100000] Switch to broadcast mode on CPU1
[ 0.101991] Booting processor 2 APIC 0x2 ip 0x6000
[ 0.002999] Initializing CPU#2
[ 0.002999] Calibrating delay using timer specific routine.. 6026.80 BogoMIPS (lpj=3013404)
[ 0.002999] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 0.002999] CPU: L2 Cache: 512K (64 bytes/line)
[ 0.002999] CPU 2/0x2 -> Node 0
[ 0.002999] CPU: Physical Processor ID: 0
[ 0.002999] CPU: Processor Core ID: 2
[ 0.173047] CPU2: AMD Phenom(tm) II X4 B45 Processor stepping 02
[ 0.173052] checking TSC synchronization [CPU#0 -> CPU#2]: passed.
[ 0.173991] Switch to broadcast mode on CPU2
[ 0.175980] Booting processor 3 APIC 0x3 ip 0x6000
[ 0.002999] Initializing CPU#3
[ 0.002999] Calibrating delay using timer specific routine.. 6026.79 BogoMIPS (lpj=3013399)
[ 0.002999] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 0.002999] CPU: L2 Cache: 512K (64 bytes/line)
[ 0.002999] CPU 3/0x3 -> Node 0
[ 0.002999] CPU: Physical Processor ID: 0
[ 0.002999] CPU: Processor Core ID: 3
[ 0.247040] CPU3: AMD Phenom(tm) II X4 B45 Processor stepping 02
[ 0.247045] checking TSC synchronization [CPU#0 -> CPU#3]: passed.
[ 0.247985] Brought up 4 CPUs
[ 0.247987] Total of 4 processors activated (24106.86 BogoMIPS).
[ 0.247985] Switch to broadcast mode on CPU3
[ 0.248981] devtmpfs: initialized
[ 0.249118] Time: 17:11:29 Date: 12/13/09
[ 0.249983] NET: Registered protocol family 16
[ 0.250038] node 0 link 0: io port [1000, ffffff]
[ 0.250040] TOM: 00000000e0000000 aka 3584M
[ 0.250041] Fam 10h mmconf [e0000000, efffffff]
[ 0.250043] node 0 link 0: mmio [a0000, bffff]
[ 0.250045] node 0 link 0: mmio [e0000000, efffffff] ==> none
[ 0.250047] node 0 link 0: mmio [f0000000, fe7fffff]
[ 0.250048] node 0 link 0: mmio [fe800000, fe9fffff]
[ 0.250050] node 0 link 0: mmio [fea00000, ffefffff]
[ 0.250051] TOM2: 0000000120000000 aka 4608M
[ 0.250053] bus: [00,07] on node 0 link 0
[ 0.250054] bus: 00 index 0 io port: [0, ffff]
[ 0.250055] bus: 00 index 1 mmio: [a0000, bffff]
[ 0.250057] bus: 00 index 2 mmio: [f0000000, ffffffff]
[ 0.250058] bus: 00 index 3 mmio: [120000000, fcffffffff]
[ 0.250065] ACPI: bus type pci registered
[ 0.250088] PCI: Found AMD Family 10h NB with MMCONFIG support.
[ 0.250091] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[ 0.250092] PCI: Not using MMCONFIG.
[ 0.250094] PCI: Using configuration type 1 for base access
[ 0.250095] PCI: Using configuration type 1 for extended access
[ 0.250402] bio: create slab <bio-0> at 0
[ 0.251177] ACPI: EC: Look up EC in DSDT
[ 0.253491] ACPI Error (psargs-0359): [ECEN] Namespace lookup failure, AE_NOT_FOUND
[ 0.253495] ACPI Error (psparse-0537): Method parse/execution failed [\] (Node ffffffff81656ab0), AE_NOT_FOUND
[ 0.253600] ACPI: Executed 3 blocks of module-level executable AML code
[ 0.270570] ACPI: Interpreter enabled
[ 0.270574] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.270594] ACPI: Using IOAPIC for interrupt routing
[ 0.276918] ACPI Warning: Incorrect checksum in table [OEMB] - 69, should be 64 (20090903/tbutils-314)
[ 0.277018] ACPI: No dock devices found.
[ 0.277155] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 0.277258] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[ 0.277260] pci 0000:00:07.0: PME# disabled
[ 0.277288] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
[ 0.277290] pci 0000:00:0a.0: PME# disabled
[ 0.277333] pci 0000:00:11.0: reg 10 io port: [0xc000-0xc007]
[ 0.277339] pci 0000:00:11.0: reg 14 io port: [0xb000-0xb003]
[ 0.277344] pci 0000:00:11.0: reg 18 io port: [0xa000-0xa007]
[ 0.277350] pci 0000:00:11.0: reg 1c io port: [0x9000-0x9003]
[ 0.277355] pci 0000:00:11.0: reg 20 io port: [0x8000-0x800f]
[ 0.277361] pci 0000:00:11.0: reg 24 32bit mmio: [0xfe7ffc00-0xfe7fffff]
[ 0.277407] pci 0000:00:12.0: reg 10 32bit mmio: [0xfe7fe000-0xfe7fefff]
[ 0.277456] pci 0000:00:12.1: reg 10 32bit mmio: [0xfe7fd000-0xfe7fdfff]
[ 0.277519] pci 0000:00:12.2: reg 10 32bit mmio: [0xfe7ff800-0xfe7ff8ff]
[ 0.277566] pci 0000:00:12.2: supports D1 D2
[ 0.277567] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
[ 0.277570] pci 0000:00:12.2: PME# disabled
[ 0.277598] pci 0000:00:13.0: reg 10 32bit mmio: [0xfe7fc000-0xfe7fcfff]
[ 0.277645] pci 0000:00:13.1: reg 10 32bit mmio: [0xfe7fb000-0xfe7fbfff]
[ 0.277709] pci 0000:00:13.2: reg 10 32bit mmio: [0xfe7ff400-0xfe7ff4ff]
[ 0.277755] pci 0000:00:13.2: supports D1 D2
[ 0.277757] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
[ 0.277760] pci 0000:00:13.2: PME# disabled
[ 0.277864] pci 0000:00:14.1: reg 10 io port: [0x00-0x07]
[ 0.277869] pci 0000:00:14.1: reg 14 io port: [0x00-0x03]
[ 0.277875] pci 0000:00:14.1: reg 18 io port: [0x00-0x07]
[ 0.277880] pci 0000:00:14.1: reg 1c io port: [0x00-0x03]
[ 0.277886] pci 0000:00:14.1: reg 20 io port: [0xff00-0xff0f]
[ 0.277944] pci 0000:00:14.2: reg 10 64bit mmio: [0xfe7f4000-0xfe7f7fff]
[ 0.277987] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
[ 0.277991] pci 0000:00:14.2: PME# disabled
[ 0.278083] pci 0000:00:14.5: reg 10 32bit mmio: [0xfe7fa000-0xfe7fafff]
[ 0.278190] pci 0000:01:05.0: reg 10 32bit mmio pref: [0xf0000000-0xf7ffffff]
[ 0.278193] pci 0000:01:05.0: reg 14 io port: [0xd000-0xd0ff]
[ 0.278196] pci 0000:01:05.0: reg 18 32bit mmio: [0xfe9f0000-0xfe9fffff]
[ 0.278201] pci 0000:01:05.0: reg 24 32bit mmio: [0xfe800000-0xfe8fffff]
[ 0.278210] pci 0000:01:05.0: supports D1 D2
[ 0.278223] pci 0000:01:05.1: reg 10 32bit mmio: [0xfe9e8000-0xfe9ebfff]
[ 0.278238] pci 0000:01:05.1: supports D1 D2
[ 0.278276] pci 0000:00:01.0: bridge io port: [0xd000-0xdfff]
[ 0.278278] pci 0000:00:01.0: bridge 32bit mmio: [0xfe800000-0xfe9fffff]
[ 0.278281] pci 0000:00:01.0: bridge 64bit mmio pref: [0xf0000000-0xf7ffffff]
[ 0.278318] pci 0000:02:00.0: reg 10 32bit mmio: [0xfeaff800-0xfeafffff]
[ 0.278326] pci 0000:02:00.0: reg 14 32bit mmio: [0xfeaff400-0xfeaff47f]
[ 0.278346] pci 0000:02:00.0: reg 20 32bit mmio: [0xfeaff000-0xfeaff07f]
[ 0.278354] pci 0000:02:00.0: reg 24 32bit mmio: [0xfeafec00-0xfeafec7f]
[ 0.281027] pci 0000:00:07.0: bridge 32bit mmio: [0xfea00000-0xfeafffff]
[ 0.281057] pci 0000:03:00.0: reg 10 io port: [0xe800-0xe8ff]
[ 0.281070] pci 0000:03:00.0: reg 18 64bit mmio pref: [0xfdfff000-0xfdffffff]
[ 0.281079] pci 0000:03:00.0: reg 20 64bit mmio pref: [0xfdff8000-0xfdffbfff]
[ 0.281085] pci 0000:03:00.0: reg 30 32bit mmio pref: [0xfebf0000-0xfebfffff]
[ 0.281111] pci 0000:03:00.0: supports D1 D2
[ 0.281112] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.281115] pci 0000:03:00.0: PME# disabled
[ 0.284022] pci 0000:00:0a.0: bridge io port: [0xe000-0xefff]
[ 0.284024] pci 0000:00:0a.0: bridge 32bit mmio: [0xfeb00000-0xfebfffff]
[ 0.284026] pci 0000:00:0a.0: bridge 64bit mmio pref: [0xfdf00000-0xfdffffff]
[ 0.284079] pci 0000:00:14.4: transparent bridge
[ 0.284098] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.284246] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
[ 0.284302] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE7._PRT]
[ 0.284347] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCEA._PRT]
[ 0.284404] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
[ 0.288183] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 7 10 *11 12 14 15)
[ 0.288276] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *10 11 12 14 15)
[ 0.288367] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 *11 12 14 15)
[ 0.288458] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 12 14 15)
[ 0.288548] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[ 0.288639] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[ 0.288730] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)
[ 0.288821] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[ 0.288891] vgaarb: device added: PCI:0000:01:05.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.288893] vgaarb: loaded
[ 0.288942] SCSI subsystem initialized
[ 0.296959] libata version 3.00 loaded.
[ 0.296979] usbcore: registered new interface driver usbfs
[ 0.296979] usbcore: registered new interface driver hub
[ 0.296981] usbcore: registered new device driver usb
[ 0.296981] PCI: Using ACPI for IRQ routing
[ 0.297086] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 24, 0
[ 0.297089] hpet0: 4 comparators, 32-bit 14.318180 MHz counter
[ 0.299973] hpet: hpet2 irq 24 for MSI
[ 0.301959] Switching to clocksource tsc
[ 0.304055] pnp: PnP ACPI init
[ 0.304064] ACPI: bus type pnp registered
[ 0.308365] pnp: PnP ACPI: found 14 devices
[ 0.308366] ACPI: ACPI bus type pnp unregistered
[ 0.308378] system 00:09: iomem range 0xfec00000-0xfec00fff could not be reserved
[ 0.308380] system 00:09: iomem range 0xfee00000-0xfee00fff has been reserved
[ 0.308384] system 00:0a: ioport range 0x4d0-0x4d1 has been reserved
[ 0.308386] system 00:0a: ioport range 0x40b-0x40b has been reserved
[ 0.308387] system 00:0a: ioport range 0x4d6-0x4d6 has been reserved
[ 0.308389] system 00:0a: ioport range 0xc00-0xc01 has been reserved
[ 0.308391] system 00:0a: ioport range 0xc14-0xc14 has been reserved
[ 0.308392] system 00:0a: ioport range 0xc50-0xc51 has been reserved
[ 0.308394] system 00:0a: ioport range 0xc52-0xc52 has been reserved
[ 0.308395] system 00:0a: ioport range 0xc6c-0xc6c has been reserved
[ 0.308397] system 00:0a: ioport range 0xc6f-0xc6f has been reserved
[ 0.308399] system 00:0a: ioport range 0xcd0-0xcd1 has been reserved
[ 0.308400] system 00:0a: ioport range 0xcd2-0xcd3 has been reserved
[ 0.308402] system 00:0a: ioport range 0xcd4-0xcd5 has been reserved
[ 0.308403] system 00:0a: ioport range 0xcd6-0xcd7 has been reserved
[ 0.308405] system 00:0a: ioport range 0xcd8-0xcdf has been reserved
[ 0.308407] system 00:0a: ioport range 0xb00-0xb3f has been reserved
[ 0.308408] system 00:0a: ioport range 0x800-0x89f has been reserved
[ 0.308410] system 00:0a: ioport range 0xb00-0xb0f has been reserved
[ 0.308412] system 00:0a: ioport range 0xb20-0xb3f has been reserved
[ 0.308414] system 00:0a: ioport range 0x900-0x90f has been reserved
[ 0.308415] system 00:0a: ioport range 0x910-0x91f has been reserved
[ 0.308417] system 00:0a: ioport range 0xfe00-0xfefe has been reserved
[ 0.308419] system 00:0a: iomem range 0xffb80000-0xffbfffff has been reserved
[ 0.308421] system 00:0a: iomem range 0xfec10000-0xfec1001f has been reserved
[ 0.308423] system 00:0a: iomem range 0xfed40000-0xfed44fff has been reserved
[ 0.308426] system 00:0b: ioport range 0x230-0x23f has been reserved
[ 0.308428] system 00:0b: ioport range 0x290-0x29f has been reserved
[ 0.308429] system 00:0b: ioport range 0x300-0x30f has been reserved
[ 0.308431] system 00:0b: ioport range 0xa30-0xa3f has been reserved
[ 0.308434] system 00:0c: iomem range 0xe0000000-0xefffffff has been reserved
[ 0.308437] system 00:0d: iomem range 0x0-0x9ffff could not be reserved
[ 0.308438] system 00:0d: iomem range 0xc0000-0xcffff has been reserved
[ 0.308440] system 00:0d: iomem range 0xe0000-0xfffff could not be reserved
[ 0.308442] system 00:0d: iomem range 0x100000-0xdfffffff could not be reserved
[ 0.308444] system 00:0d: iomem range 0xfec00000-0xffffffff could not be reserved
[ 0.313146] pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
[ 0.313148] pci 0000:00:01.0: IO window: 0xd000-0xdfff
[ 0.313151] pci 0000:00:01.0: MEM window: 0xfe800000-0xfe9fffff
[ 0.313153] pci 0000:00:01.0: PREFETCH window: 0x000000f0000000-0x000000f7ffffff
[ 0.313156] pci 0000:00:07.0: PCI bridge, secondary bus 0000:02
[ 0.313157] pci 0000:00:07.0: IO window: disabled
[ 0.313159] pci 0000:00:07.0: MEM window: 0xfea00000-0xfeafffff
[ 0.313161] pci 0000:00:07.0: PREFETCH window: disabled
[ 0.313163] pci 0000:00:0a.0: PCI bridge, secondary bus 0000:03
[ 0.313165] pci 0000:00:0a.0: IO window: 0xe000-0xefff
[ 0.313167] pci 0000:00:0a.0: MEM window: 0xfeb00000-0xfebfffff
[ 0.313169] pci 0000:00:0a.0: PREFETCH window: 0x000000fdf00000-0x000000fdffffff
[ 0.313171] pci 0000:00:14.4: PCI bridge, secondary bus 0000:04
[ 0.313172] pci 0000:00:14.4: IO window: disabled
[ 0.313176] pci 0000:00:14.4: MEM window: disabled
[ 0.313179] pci 0000:00:14.4: PREFETCH window: disabled
[ 0.313190] pci 0000:00:07.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 0.313193] pci 0000:00:07.0: setting latency timer to 64
[ 0.313197] pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 0.313199] pci 0000:00:0a.0: setting latency timer to 64
[ 0.313205] pci_bus 0000:00: resource 0 io: [0x00-0xffff]
[ 0.313207] pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffffffffffff]
[ 0.313209] pci_bus 0000:01: resource 0 io: [0xd000-0xdfff]
[ 0.313210] pci_bus 0000:01: resource 1 mem: [0xfe800000-0xfe9fffff]
[ 0.313212] pci_bus 0000:01: resource 2 pref mem [0xf0000000-0xf7ffffff]
[ 0.313214] pci_bus 0000:02: resource 1 mem: [0xfea00000-0xfeafffff]
[ 0.313215] pci_bus 0000:03: resource 0 io: [0xe000-0xefff]
[ 0.313217] pci_bus 0000:03: resource 1 mem: [0xfeb00000-0xfebfffff]
[ 0.313218] pci_bus 0000:03: resource 2 pref mem [0xfdf00000-0xfdffffff]
[ 0.313220] pci_bus 0000:04: resource 3 io: [0x00-0xffff]
[ 0.313221] pci_bus 0000:04: resource 4 mem: [0x000000-0xffffffffffffffff]
[ 0.313241] NET: Registered protocol family 2
[ 0.313336] IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.313997] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[ 0.315875] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 0.316127] TCP: Hash tables configured (established 524288 bind 65536)
[ 0.316129] TCP reno registered
[ 0.316182] NET: Registered protocol family 1
[ 0.444925] pci 0000:01:05.0: Boot video device
[ 0.444959] Unpacking initramfs...
[ 0.529726] Freeing initrd memory: 6164k freed
[ 0.531061] PCI-DMA: Disabling AGP.
[ 0.531131] PCI-DMA: aperture base @ 20000000 size 65536 KB
[ 0.531132] PCI-DMA: using GART IOMMU.
[ 0.531134] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[ 0.532967] Scanning for low memory corruption every 60 seconds
[ 0.533252] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 0.534022] VFS: Disk quotas dquot_6.5.2
[ 0.534053] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.534218] msgmni has been set to 7932
[ 0.534284] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 0.534286] io scheduler noop registered
[ 0.534287] io scheduler anticipatory registered
[ 0.534288] io scheduler deadline registered
[ 0.534307] io scheduler cfq registered (default)
[ 0.534421] pcieport 0000:00:07.0: irq 25 for MSI/MSI-X
[ 0.534426] pcieport 0000:00:07.0: setting latency timer to 64
[ 0.534512] pcieport 0000:00:0a.0: irq 26 for MSI/MSI-X
[ 0.534516] pcieport 0000:00:0a.0: setting latency timer to 64
[ 0.534669] vesafb: framebuffer at 0xf0000000, mapped to 0xffffc90001080000, using 5120k, total 16384k
[ 0.534671] vesafb: mode is 1280x1024x16, linelength=2560, pages=5
[ 0.534672] vesafb: scrolling: redraw
[ 0.534674] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[ 0.541540] Console: switching to colour frame buffer device 160x64
[ 0.547939] fb0: VESA VGA frame buffer device
[ 0.548615] Non-volatile memory driver v1.3
[ 0.548618] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 0.548723] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 0.548896] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 0.549010] ahci 0000:00:11.0: version 3.0
[ 0.549026] ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 0.549137] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[ 0.549140] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
[ 0.549385] scsi0 : ahci
[ 0.549446] scsi1 : ahci
[ 0.549475] scsi2 : ahci
[ 0.549504] scsi3 : ahci
[ 0.549533] scsi4 : ahci
[ 0.549563] scsi5 : ahci
[ 0.549585] ata1: SATA max UDMA/133 abar m1024@0xfe7ffc00 port 0xfe7ffd00 irq 22
[ 0.549588] ata2: SATA max UDMA/133 abar m1024@0xfe7ffc00 port 0xfe7ffd80 irq 22
[ 0.549591] ata3: SATA max UDMA/133 abar m1024@0xfe7ffc00 port 0xfe7ffe00 irq 22
[ 0.549593] ata4: SATA max UDMA/133 abar m1024@0xfe7ffc00 port 0xfe7ffe80 irq 22
[ 0.549595] ata5: SATA max UDMA/133 abar m1024@0xfe7ffc00 port 0xfe7fff00 irq 22
[ 0.549598] ata6: SATA max UDMA/133 abar m1024@0xfe7ffc00 port 0xfe7fff80 irq 22
[ 0.549659] Fixed MDIO Bus: probed
[ 0.549664] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.550931] ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 0.550948] ehci_hcd 0000:00:12.2: EHCI Host Controller
[ 0.550964] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
[ 0.550992] ehci_hcd 0000:00:12.2: debug port 1
[ 0.551007] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfe7ff800
[ 0.557253] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
[ 0.557267] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.557268] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.557270] usb usb1: Product: EHCI Host Controller
[ 0.557272] usb usb1: Manufacturer: Linux 2.6.32 ehci_hcd
[ 0.557273] usb usb1: SerialNumber: 0000:00:12.2
[ 0.557314] usb usb1: configuration #1 chosen from 1 choice
[ 0.557330] hub 1-0:1.0: USB hub found
[ 0.557334] hub 1-0:1.0: 6 ports detected
[ 0.557397] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 0.557405] ehci_hcd 0000:00:13.2: EHCI Host Controller
[ 0.557411] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
[ 0.557433] ehci_hcd 0000:00:13.2: debug port 1
[ 0.557447] ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe7ff400
[ 0.563259] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
[ 0.563265] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.563267] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.563269] usb usb2: Product: EHCI Host Controller
[ 0.563270] usb usb2: Manufacturer: Linux 2.6.32 ehci_hcd
[ 0.563271] usb usb2: SerialNumber: 0000:00:13.2
[ 0.563298] usb usb2: configuration #1 chosen from 1 choice
[ 0.563312] hub 2-0:1.0: USB hub found
[ 0.563315] hub 2-0:1.0: 6 ports detected
[ 0.563354] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.563377] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.563385] ohci_hcd 0000:00:12.0: OHCI Host Controller
[ 0.563390] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 3
[ 0.563407] ohci_hcd 0000:00:12.0: irq 16, io mem 0xfe7fe000
[ 0.618285] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.618286] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.618288] usb usb3: Product: OHCI Host Controller
[ 0.618289] usb usb3: Manufacturer: Linux 2.6.32 ohci_hcd
[ 0.618290] usb usb3: SerialNumber: 0000:00:12.0
[ 0.618318] usb usb3: configuration #1 chosen from 1 choice
[ 0.618330] hub 3-0:1.0: USB hub found
[ 0.618337] hub 3-0:1.0: 3 ports detected
[ 0.618427] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.618434] ohci_hcd 0000:00:12.1: OHCI Host Controller
[ 0.618439] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bus number 4
[ 0.618451] ohci_hcd 0000:00:12.1: irq 16, io mem 0xfe7fd000
[ 0.673283] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.673285] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.673286] usb usb4: Product: OHCI Host Controller
[ 0.673287] usb usb4: Manufacturer: Linux 2.6.32 ohci_hcd
[ 0.673289] usb usb4: SerialNumber: 0000:00:12.1
[ 0.673317] usb usb4: configuration #1 chosen from 1 choice
[ 0.673329] hub 4-0:1.0: USB hub found
[ 0.673335] hub 4-0:1.0: 3 ports detected
[ 0.673422] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 0.673431] ohci_hcd 0000:00:13.0: OHCI Host Controller
[ 0.673436] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5
[ 0.673452] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfe7fc000
[ 0.728281] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.728283] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.728284] usb usb5: Product: OHCI Host Controller
[ 0.728286] usb usb5: Manufacturer: Linux 2.6.32 ohci_hcd
[ 0.728287] usb usb5: SerialNumber: 0000:00:13.0
[ 0.728315] usb usb5: configuration #1 chosen from 1 choice
[ 0.728327] hub 5-0:1.0: USB hub found
[ 0.728333] hub 5-0:1.0: 3 ports detected
[ 0.728421] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 0.728427] ohci_hcd 0000:00:13.1: OHCI Host Controller
[ 0.728432] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 6
[ 0.728445] ohci_hcd 0000:00:13.1: irq 18, io mem 0xfe7fb000
[ 0.783280] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.783282] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.783283] usb usb6: Product: OHCI Host Controller
[ 0.783285] usb usb6: Manufacturer: Linux 2.6.32 ohci_hcd
[ 0.783286] usb usb6: SerialNumber: 0000:00:13.1
[ 0.783315] usb usb6: configuration #1 chosen from 1 choice
[ 0.783327] hub 6-0:1.0: USB hub found
[ 0.783333] hub 6-0:1.0: 3 ports detected
[ 0.783424] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 0.783431] ohci_hcd 0000:00:14.5: OHCI Host Controller
[ 0.783437] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 7
[ 0.783449] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfe7fa000
[ 0.838289] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.838291] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.838292] usb usb7: Product: OHCI Host Controller
[ 0.838293] usb usb7: Manufacturer: Linux 2.6.32 ohci_hcd
[ 0.838294] usb usb7: SerialNumber: 0000:00:14.5
[ 0.838320] usb usb7: configuration #1 chosen from 1 choice
[ 0.838333] hub 7-0:1.0: USB hub found
[ 0.838339] hub 7-0:1.0: 2 ports detected
[ 0.838385] Initializing USB Mass Storage driver...
[ 0.838409] usbcore: registered new interface driver usb-storage
[ 0.838410] USB Mass Storage support registered.
[ 0.838428] usbcore: registered new interface driver libusual
[ 0.838433] usbcore: registered new interface driver ums-alauda
[ 0.838439] usbcore: registered new interface driver ums-cypress
[ 0.838447] usbcore: registered new interface driver ums-datafab
[ 0.838453] usbcore: registered new interface driver ums-freecom
[ 0.838458] usbcore: registered new interface driver ums-isd200
[ 0.838463] usbcore: registered new interface driver ums-jumpshot
[ 0.838469] usbcore: registered new interface driver ums-karma
[ 0.838475] usbcore: registered new interface driver ums-onetouch
[ 0.838480] usbcore: registered new interface driver ums-sddr09
[ 0.838486] usbcore: registered new interface driver ums-sddr55
[ 0.838491] usbcore: registered new interface driver ums-usbat
[ 0.838514] PNP: No PS/2 controller found. Probing ports directly.
[ 0.838841] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.838845] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 0.838886] mice: PS/2 mouse device common for all mice
[ 0.838897] Driver 'rtc_cmos' needs updating - please use bus_type methods
[ 0.838914] rtc_cmos 00:03: RTC can wake from S4
[ 0.838933] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[ 0.838954] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 0.838963] cpuidle: using governor ladder
[ 0.838964] cpuidle: using governor menu
[ 0.839100] usbcore: registered new interface driver hiddev
[ 0.839106] usbcore: registered new interface driver usbhid
[ 0.839108] usbhid: v2.6:USB HID core driver
[ 0.839282] TCP cubic registered
[ 0.839346] NET: Registered protocol family 10
[ 0.839605] lo: Disabled Privacy Extensions
[ 0.839820] PM: Checking image partition UUID="fc2d8cd0-fed3-4196-b346-83de887dfcf7"
[ 0.854311] ata5: SATA link down (SStatus 0 SControl 300)
[ 0.854840] ata1: SATA link down (SStatus 0 SControl 300)
[ 0.854870] ata4: SATA link down (SStatus 0 SControl 300)
[ 0.854879] ata6: SATA link down (SStatus 0 SControl 300)
[ 0.860950] usb 1-3: new high speed USB device using ehci_hcd and address 2
[ 0.980721] usb 1-3: New USB device found, idVendor=05e3, idProduct=0606
[ 0.980722] usb 1-3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 0.980724] usb 1-3: Product: USB2.0 Hub
[ 0.980754] usb 1-3: configuration #1 chosen from 1 choice
[ 0.981218] hub 1-3:1.0: USB hub found
[ 0.981727] hub 1-3:1.0: 4 ports detected
[ 1.007296] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.007965] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.009249] ata2.00: ATA-8: WDC WD1600BEKT-00F3T0, 11.01A11, max UDMA/133
[ 1.009251] ata2.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 1.009604] ata3.00: ATA-8: WDC WD1600BEKT-00F3T0, 11.01A11, max UDMA/133
[ 1.009606] ata3.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 1.011322] ata2.00: configured for UDMA/133
[ 1.011668] ata3.00: configured for UDMA/133
[ 1.023018] scsi 1:0:0:0: Direct-Access ATA WDC WD1600BEKT-0 11.0 PQ: 0 ANSI: 5
[ 1.023109] sd 1:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[ 1.023129] sd 1:0:0:0: [sda] Write Protect is off
[ 1.023131] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.023144] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.023163] scsi 2:0:0:0: Direct-Access ATA WDC WD1600BEKT-0 11.0 PQ: 0 ANSI: 5
[ 1.023226] sda:
[ 1.023231] sd 2:0:0:0: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[ 1.023256] sd 2:0:0:0: [sdb] Write Protect is off
[ 1.023257] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1.023267] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.023329] sdb: sda1 sda2
[ 1.088412] sd 1:0:0:0: [sda] Attached SCSI disk
[ 1.088778] sdb1 sdb2
[ 1.088875] sd 2:0:0:0: [sdb] Attached SCSI disk
[ 1.088877] PM: Resume from disk failed.
[ 1.088881] registered taskstats version 1
[ 1.089130] Magic number: 5:433:188
[ 1.089146] acpi device:1a: hash matches
[ 1.089178] rtc_cmos 00:03: setting system clock to 2009-12-13 17:11:30 UTC (1260724290)
[ 1.089203] Freeing unused kernel memory: 416k freed
[ 1.089278] Write protecting the kernel read-only data: 5040k
[ 1.109960] pata_atiixp 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 1.109979] pata_atiixp 0000:00:14.1: setting latency timer to 64
[ 1.110039] scsi6 : pata_atiixp
[ 1.110078] scsi7 : pata_atiixp
[ 1.111098] ata7: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
[ 1.111099] ata8: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15
[ 1.265681] ata7.00: ATAPI: TSSTcorpCD/DVDW SH-S182D, SB04, max UDMA/33
[ 1.271628] ata7.00: configured for UDMA/33
[ 1.278080] scsi 6:0:0:0: CD-ROM TSSTcorp CD/DVDW SH-S182D SB04 PQ: 0 ANSI: 5
[ 1.300251] usb 4-2: new low speed USB device using ohci_hcd and address 2
[ 1.433847] processor LNXCPU:00: registered as cooling_device0
[ 1.434198] processor LNXCPU:01: registered as cooling_device1
[ 1.434542] processor LNXCPU:02: registered as cooling_device2
[ 1.434878] processor LNXCPU:03: registered as cooling_device3
[ 1.438264] udev: starting version 146
[ 1.444353] usb 4-2: New USB device found, idVendor=046a, idProduct=0021
[ 1.444356] usb 4-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.444430] usb 4-2: configuration #1 chosen from 1 choice
[ 1.453511] input: HID 046a:0021 as /devices/pci0000:00/0000:00:12.1/usb4/4-2/4-2:1.0/input/input0
[ 1.453559] generic-usb 0003:046A:0021.0001: input,hidraw0: USB HID v1.11 Keyboard [HID 046a:0021] on usb-0000:00:12.1-2/input0
[ 1.463431] input: HID 046a:0021 as /devices/pci0000:00/0000:00:12.1/usb4/4-2/4-2:1.1/input/input1
[ 1.463483] generic-usb 0003:046A:0021.0002: input,hidraw1: USB HID v1.11 Device [HID 046a:0021] on usb-0000:00:12.1-2/input1
[ 1.690244] usb 4-3: new low speed USB device using ohci_hcd and address 3
[ 1.843386] usb 4-3: New USB device found, idVendor=046d, idProduct=c521
[ 1.843389] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.843390] usb 4-3: Product: USB Receiver
[ 1.843392] usb 4-3: Manufacturer: Logitech
[ 1.843448] usb 4-3: configuration #1 chosen from 1 choice
[ 1.855718] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:12.1/usb4/4-3/4-3:1.0/input/input2
[ 1.855769] generic-usb 0003:046D:C521.0003: input,hidraw2: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:12.1-3/input0
[ 1.867648] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:12.1/usb4/4-3/4-3:1.1/input/input3
[ 1.867705] generic-usb 0003:046D:C521.0004: input,hiddev0,hidraw3: USB HID v1.11 Device [Logitech USB Receiver] on
usb-0000:00:12.1-3/input1
[ 1.932239] usb 1-3.1: new high speed USB device using ehci_hcd and address 5
[ 2.011921] usb 1-3.1: New USB device found, idVendor=058f, idProduct=6362
[ 2.011923] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.011925] usb 1-3.1: Product: Mass Storage Device
[ 2.011926] usb 1-3.1: Manufacturer: Generic
[ 2.011927] usb 1-3.1: SerialNumber: 058F312D81B
[ 2.011974] usb 1-3.1: configuration #1 chosen from 1 choice
[ 2.012532] scsi8 : SCSI emulation for USB Mass Storage devices
[ 2.012610] usb-storage: device found at 5
[ 2.012611] usb-storage: waiting for device to settle before scanning
[ 7.012642] usb-storage: device scan complete
[ 7.013714] scsi 8:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0
[ 7.014778] scsi 8:0:0:1: Direct-Access Generic USB CF Reader 1.01 PQ: 0 ANSI: 0
[ 7.015869] scsi 8:0:0:2: Direct-Access Generic USB SM Reader 1.02 PQ: 0 ANSI: 0
[ 7.016921] scsi 8:0:0:3: Direct-Access Generic USB MS Reader 1.03 PQ: 0 ANSI: 0
[ 7.411372] sd 8:0:0:3: [sdf] Attached SCSI removable disk
[ 7.412120] sd 8:0:0:0: [sdc] Attached SCSI removable disk
[ 7.413595] sd 8:0:0:2: [sde] Attached SCSI removable disk
[ 7.416362] sd 8:0:0:1: [sdd] 3915072 512-byte logical blocks: (2.00 GB/1.86 GiB)
[ 7.421646] sd 8:0:0:1: [sdd] Write Protect is off
[ 7.421648] sd 8:0:0:1: [sdd] Mode Sense: 03 00 00 00
[ 7.421649] sd 8:0:0:1: [sdd] Assuming drive cache: write through
[ 7.429651] sd 8:0:0:1: [sdd] Assuming drive cache: write through
[ 7.429703] sdd: sdd1 sdd2
[ 7.434840] sd 8:0:0:1: [sdd] Assuming drive cache: write through
[ 7.434893] sd 8:0:0:1: [sdd] Attached SCSI removable disk
[ 8.227063] EXT4-fs (sdd2): mounted filesystem with ordered data mode
[ 11.873641] udev: starting version 146
[ 12.058971] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 12.058986] r8169 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 12.059045] r8169 0000:03:00.0: setting latency timer to 64
[ 12.059081] r8169 0000:03:00.0: irq 27 for MSI/MSI-X
[ 12.059435] eth0: RTL8168d/8111d at 0xffffc900016ca000, 90:e6:ba:10:55:5d, XID 083000c0 IRQ 27
[ 12.071690] sd 1:0:0:0: Attached scsi generic sg0 type 0
[ 12.071713] sd 2:0:0:0: Attached scsi generic sg1 type 0
[ 12.071730] scsi 6:0:0:0: Attached scsi generic sg2 type 5
[ 12.071748] sd 8:0:0:0: Attached scsi generic sg3 type 0
[ 12.071764] sd 8:0:0:1: Attached scsi generic sg4 type 0
[ 12.071779] sd 8:0:0:2: Attached scsi generic sg5 type 0
[ 12.071795] sd 8:0:0:3: Attached scsi generic sg6 type 0
[ 12.318038] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input4
[ 12.318068] ACPI: Power Button [PWRB]
[ 12.318100] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5
[ 12.318115] ACPI: Power Button [PWRF]
[ 12.369307] ACPI: I/O resource piix4_smbus [0xb00-0xb07] conflicts with ACPI region SOR1 [0xb00-0xb0f]
[ 12.369386] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 12.657607] input: PC Speaker as /devices/platform/pcspkr/input/input6
[ 12.851305] firewire_ohci 0000:02:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 12.851311] firewire_ohci 0000:02:00.0: setting latency timer to 64
[ 12.867360] sr0: scsi3-mmc drive: 94x/94x writer dvd-ram cd/rw xa/form2 cdda tray
[ 12.867362] Uniform CD-ROM driver Revision: 3.20
[ 12.867428] sr 6:0:0:0: Attached scsi CD-ROM sr0
[ 12.911233] firewire_ohci: Added fw-ohci device 0000:02:00.0, OHCI version 1.10
[ 13.001396] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 13.054485] ALSA sound/pci/hda/hda_codec.c:3881: autoconfig: line_outs=4 (0x1c/0x19/0x22/0x23/0x0)
[ 13.054488] ALSA sound/pci/hda/hda_codec.c:3885: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 13.054491] ALSA sound/pci/hda/hda_codec.c:3889: hp_outs=1 (0x1d/0x0/0x0/0x0/0x0)
[ 13.054493] ALSA sound/pci/hda/hda_codec.c:3890: mono: mono_out=0x0
[ 13.054494] ALSA sound/pci/hda/hda_codec.c:3893: dig-out=0x20/0x21
[ 13.054496] ALSA sound/pci/hda/hda_codec.c:3901: inputs: mic=0x1a, fmic=0x1e, line=0x1b, fline=0x0, cd=0x0, aux=0x0
[ 13.057591] HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 13.057609] HDA Intel 0000:01:05.1: setting latency timer to 64
[ 13.351096] Adding 2097144k swap on /dev/sda1. Priority:-1 extents:1 across:2097144k
[ 13.356677] Adding 2097144k swap on /dev/sdb1. Priority:-2 extents:1 across:2097144k
[ 13.410307] firewire_core: created device fw0: GUID 001e8c0000a82627, S400
[ 14.635963] device-mapper: uevent: version 1.0.3
[ 14.636058] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
[ 14.650134] md: md0 stopped.
[ 14.650765] md: bind<sdb2>
[ 14.650865] md: bind<sda2>
[ 14.658964] md: raid0 personality registered for level 0
[ 14.659109] raid0: looking at sda2
[ 14.659110] raid0: comparing sda2(308387392)
[ 14.659111] with sda2(308387392)
[ 14.659112] raid0: END
[ 14.659113] raid0: ==> UNIQUE
[ 14.659114] raid0: 1 zones
[ 14.659115] raid0: looking at sdb2
[ 14.659116] raid0: comparing sdb2(308387392)
[ 14.659117] with sda2(308387392)
[ 14.659118] raid0: EQUAL
[ 14.659119] raid0: FINAL 1 zones
[ 14.659120] raid0: done.
[ 14.659121] raid0 : md_size is 616774784 sectors.
[ 14.659122] ******* md0 configuration *********
[ 14.659123] zone0=[sda2/sdb2/]
[ 14.659126] zone offset=0kb device offset=0kb size=308387392kb
[ 14.659143] **********************************
[ 14.659144]
[ 14.659149] md0: detected capacity change from 0 to 315788689408
[ 14.659760] md0: unknown partition table
[ 16.203674] loop: module loaded
[ 16.413378] EXT4-fs (dm-3): mounted filesystem with ordered data mode
[ 16.421834] EXT4-fs (dm-1): mounted filesystem with ordered data mode
[ 16.445411] EXT4-fs (dm-2): mounted filesystem with ordered data mode
[ 16.453738] EXT4-fs (dm-0): mounted filesystem with ordered data mode
[ 16.587404] fuse init (API version 7.13)
[ 19.297783] r8169: eth0: link up
[ 19.297788] r8169: eth0: link up
[ 19.803071] Slow work thread pool: Starting up
[ 19.803117] Slow work thread pool: Ready
[ 19.904979] [drm] Initialized drm 1.1.0 20060810
[ 20.270196] [drm] radeon defaulting to userspace modesetting.
[ 20.270597] pci 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 20.270600] pci 0000:01:05.0: setting latency timer to 64
[ 20.270727] [drm] Initialized radeon 1.31.0 20080528 for 0000:01:05.0 on minor 0
[ 20.275273] powernow-k8: Found 1 AMD Phenom(tm) II X4 B45 Processor processors (4 cpu cores) (version 2.20.00)
[ 20.275308] powernow-k8: 0 : pstate 0 (3000 MHz)
[ 20.275309] powernow-k8: 1 : pstate 1 (2300 MHz)
[ 20.275310] powernow-k8: 2 : pstate 2 (1800 MHz)
[ 20.275312] powernow-k8: 3 : pstate 3 (800 MHz)
[ 20.414690] [drm] Setting GART location based on new memory map
[ 20.414799] [drm] Loading RS780 CP Microcode
[ 20.414801] platform r600_cp.0: firmware: requesting radeon/RS780_pfp.bin
[ 20.452330] platform r600_cp.0: firmware: requesting radeon/RS780_me.bin
[ 20.506542] [drm] Resetting GPU
[ 20.506602] [drm] writeback test succeeded in 1 usecs
[ 22.915987] BIOS EDD facility v0.16 2004-Jun-25, 3 devices found
[ 23.593031] it87: Found IT8712F chip at 0x290, revision 8
[ 23.593044] it87: in3 is VCC (+5V)
[ 23.593047] it87: in7 is VCCH (+5V Stand-By)
[ 23.593603] ACPI: I/O resource it87 [0x295-0x296] conflicts with ACPI region SIOE [0x290-0x2af]
[ 23.593618] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 29.536321] eth0: no IPv6 routers present
[ 32.369960] CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: nconfig v7
http://groups.google.com/group/linux.kernel/t/e6f520d6c713a34a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 9:40 am
From: Sam Ravnborg

On Sun, Dec 13, 2009 at 03:25:14PM +0100, Jan Engelhardt wrote:
>
> On Sunday 2009-12-13 12:55, Sam Ravnborg wrote:
> >
> >> >Thanks for catching this. It is a by-product of the code for
> >> >presenting everything inside a single menu. Easily fixed in the next
> >> >version. By the way, is anyone using this option at all? It would much
> >> >simplify the code if I did not have to support the one giant menu
> >> >option.
> >>
> >> Well nconfig is the first to provide that option. (Note: I don't use
> >> gconfig or xconfig, so I cannot tell if they have something like that.)
> >> So to see whether there is use, you would have to wait a number of
> >> kernel releases that have nconfig integrated.
> >
> >We already have:
> >Optional personality available
> > . ------------------------------
> > . If you prefer to have all of the kernel options listed in a single
> > . menu, rather than the default multimenu hierarchy, run the menuconfig
> > . with MENUCONFIG_MODE environment variable set to single_menu. Example:
> > .
> > . make MENUCONFIG_MODE=single_menu menuconfig
>
> I think the discussion went about "show hidden symbols" rather than
> "show everything in a single menu". Or at least that was my intention -
> sorry for any confusion.

I did not check what nconfig does exactly - I just assumed it was
the single_menu mode.
I know several people has requested the possibility to see all
ie. also hidden) symbols before.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Async suspend-resume patch w/ completions (was: Re: Async suspend-
resume patch w/ rwsems)
http://groups.google.com/group/linux.kernel/t/744b2baf61c0ac2a?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Dec 13 2009 9:40 am
From: Alan Stern

On Sat, 12 Dec 2009, Linus Torvalds wrote:

> This version still has a major problem, which is not related to
> completions vs rwsems, but simply to the fact that you wanted to do this
> at the generic device layer level rather than do it at the actual
> low-level suspend/resume level.
>
> Namely that there's no apparent sane way to say "don't wait for children".
>
> PCI bridges that don't suspend at all - or any other device that only
> suspends in the 'suspend_late()' thing, for that matter - don't have any
> reason what-so-ever to wait for children, since they aren't actually
> suspending in the first place. But you make them wait regardless, which
> then serializes things unnecessarily (for example, two unrelated USB
> controllers).

In reality this should never be a problem.

Consider that ultimately we want to achieve the following two goals:

Implement a two-pass algorithm, so that synchronous devices
can't cause spurious dependencies between two async devices.
(This will fix the issue of an intermediate PCI bridge
serializing two unrelated USB controllers.)

Convert all lengthy suspend/resume operations to async.

Obviously we don't want to do this all at once. But until the goals
are achieved, there's no point worrying about devices being forced to
wait for their children or parents. And after the goals are achieved,
it won't matter.

Why not? Consider the devices which would be delayed. If they use
synchronous suspend/resume then they won't take much time, so delaying
them won't matter. Indeed, based on Arjan's preliminary measurements
it's fair to say that the total time taken by all the synchronous
suspends/resumes put together should be negligible. Even if all of
them were somehow delayed until all the async activities were complete,
nobody would notice or care. (And conversely, if all the async
activities could somehow be forced to wait until all the synchronous
suspends/resumes were done, nobody would notice or care.)

Okay, so consider a case where A comes before B in dpm_list and B is
the parent of C. Suppose B doesn't need to wait for C to suspend, but
we force it to wait anyhow.

If A or C is synchronous then we're okay, by the considerations above.
Suppose A is async. Then it wouldn't be delayed unless it was one of
B's ancestors, so suppose it is. Now we are potentially delaying A
more than necessary.

Or are we? Even though B might not need to wait for C to suspend,
there's an excellent chance that A _does_ need to wait for C. If we
allow B to suspend before C then there would be nothing to prevent A
from suspending too quickly. A's driver would need to wait explicitly
for C -- which is unreasonable since C isn't one of A's children.
(Rafael made a similar point.)

In short, allowing devices to suspend before their children would be
dangerous and probably would not save a significant amount of time.

Alan Stern

== 2 of 2 ==
Date: Sun, Dec 13 2009 11:10 am
From: Alan Stern

On Sun, 13 Dec 2009, Alan Stern wrote:

> > Namely that there's no apparent sane way to say "don't wait for children".
> >
> > PCI bridges that don't suspend at all - or any other device that only
> > suspends in the 'suspend_late()' thing, for that matter - don't have any
> > reason what-so-ever to wait for children, since they aren't actually
> > suspending in the first place. But you make them wait regardless, which
> > then serializes things unnecessarily (for example, two unrelated USB
> > controllers).

> In short, allowing devices to suspend before their children would be
> dangerous and probably would not save a significant amount of time.

There's more to be said. Even without this "don't wait for children"
thing, there can be bad interactions causing unnecessary delays. For
example, suppose A (async) is the parent of B (sync), B comes before C
(sync) in dpm_list, and C is the parent of D (async). Even if A & B
are unrelated to C & D, they will be forced to wait for them. It
doesn't matter that A and D are unrelated and so could suspend
concurrently.

In essence, every synchonrous device is treated as though it depends on
all the synchronous devices preceding it in dpm_list. That's a lot of
unnecessary constraints. At the moment we have no choice, because we
have to assume that some of those constraints actually are necessary --
and we don't know which ones.

It's an inescapable fact: If there are unnecessary ordering constraints
then you generally can't be 100% efficient in carrying out parallel
operations. Compared with all these extra "synchronous" constraints,
the relatively small number of "don't need to wait for children"
constraints is harmless. I bet that if we got rid of all unnecessary
constraints except for making parents always wait for their children,
we'd attain more than 95% of the ideal speedup.

Alan Stern

==============================================================================
TOPIC: TTY patches for 2.6.33-git
http://groups.google.com/group/linux.kernel/t/1e09e9b25fa77b60?hl=en
==============================================================================

== 1 of 6 ==
Date: Sun, Dec 13 2009 9:50 am
From: Linus Torvalds

On Sun, 13 Dec 2009, Ingo Molnar wrote:
>
> In the last ~4.5 years:
>
> earth4:~/tip> git checkout v2.6.12
> Date: Fri Jun 17 12:48:29 2005 -0700
> earth4:~/tip> git grep -w unlock_kernel | wc -l
> 713
>
> earth4:~/tip> git checkout linus
> Date: Fri Dec 11 20:58:20 2009 -0800
> earth4:~/tip> git grep -w unlock_kernel | wc -l
> 841

Git hint of the day: you don't need to check out a kernel to do "git
grep".

Do this:

git grep -w unlock_kernel v2.6.12 | wc

and it will JustWork(tm).

> Also, a lot of BKL use was hidden before, and due to the BKL removal
> activities (by Thomas, Frederic, Jon, Alan and others) the remaining BKL using
> sites are a lot more well defined, a lot more isolated and thus a lot more
> removable than ever before.

That's the main thing. We've been pushing them down a lot.

We still have a few annoying core ones, though. I hate the execve() and
file locking ones.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 6 ==
Date: Sun, Dec 13 2009 10:00 am
From: Arjan van de Ven

On Sun, 13 Dec 2009 07:58:44 +0100
Ingo Molnar <mingo@elte.hu> wrote:

>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > We've had quite a bit of BKL work this merge-window. Maybe we'll
> > even get rid of it one of these days. There are "only" about 600
> > instances of "lock_kernel()" in the tree right now ;)
>
> I tend to use unlock_kernel() as the metric. (as it's more precisely
> greppable and it is also more indicative of the underlying complexity
> of locking, as it gets used more in more complex scenarios)

another metric is... how many times do we take the BKL for some
workload. (For example booting or compiling a kernel).
A counter like "BKLs-per-second" would be nice to expose
(and then we can track that number going up as a regression etc)

For me, a secondary metric would be "how many times do we depend on the
magic auto-drop/reget behavior".. also easy to build a counter for.

--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 6 ==
Date: Sun, Dec 13 2009 10:20 am
From: Ingo Molnar

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

>
>
> On Sun, 13 Dec 2009, Ingo Molnar wrote:
> >
> > In the last ~4.5 years:
> >
> > earth4:~/tip> git checkout v2.6.12
> > Date: Fri Jun 17 12:48:29 2005 -0700
> > earth4:~/tip> git grep -w unlock_kernel | wc -l
> > 713
> >
> > earth4:~/tip> git checkout linus
> > Date: Fri Dec 11 20:58:20 2009 -0800
> > earth4:~/tip> git grep -w unlock_kernel | wc -l
> > 841
>
> Git hint of the day: you don't need to check out a kernel to do "git
> grep".
>
> Do this:
>
> git grep -w unlock_kernel v2.6.12 | wc
>
> and it will JustWork(tm).

/me adds it to the metal toolbox

> > Also, a lot of BKL use was hidden before, and due to the BKL removal
> > activities (by Thomas, Frederic, Jon, Alan and others) the remaining BKL using
> > sites are a lot more well defined, a lot more isolated and thus a lot more
> > removable than ever before.
>
> That's the main thing. We've been pushing them down a lot.
>
> We still have a few annoying core ones, though. I hate the execve() and file
> locking ones.

When we did the BKL-as-a-mutex trick and let lockdep loose on it, three areas
were particularly tricky: tty, reiser3 and NFS. tty and reiserfs should be ok
now, but i havent seen much activity on the NFS front.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 6 ==
Date: Sun, Dec 13 2009 10:40 am
From: Trond Myklebust

On Sun, 2009-12-13 at 19:17 +0100, Ingo Molnar wrote:
> When we did the BKL-as-a-mutex trick and let lockdep loose on it, three areas
> were particularly tricky: tty, reiser3 and NFS. tty and reiserfs should be ok
> now, but i havent seen much activity on the NFS front.

I've got a couple of NFS bkl removal patches queued up that I'll send on
to Linus today, but they will not suffice to fully remove BKL from the
NFS code.

The main remaining problem area is that of file locking (i.e. anything
that references inode->i_flock). I've started work on that, but a couple
of higher interrupts have prevented me from pulling it all together in
time for this merge window...

Trond

== 5 of 6 ==
Date: Sun, Dec 13 2009 11:10 am
From: Linus Torvalds

On Sun, 13 Dec 2009, Trond Myklebust wrote:
>
> The main remaining problem area is that of file locking (i.e. anything
> that references inode->i_flock). I've started work on that, but a couple
> of higher interrupts have prevented me from pulling it all together in
> time for this merge window...

I'm pretty sure we've had at least two trees with the file locking code
fixed, but NFS in a status of "unknown".

If I recall correctly, the file locking code itself is not that hard:
we've done it without the kernel lock in the past (long long ago), and the
lock usage doesn't nest (or at least it didn't at some point back then ;).
In fact, I think we even do the actual lock data structure allocations
outside of the kernel lock exactly because we at one time had a patch that
used a spinlock for protection of the lists.

(Again, not only my memory, but the code itself may have bitrotted in the
meantime, of course).

== 6 of 6 ==
Date: Sun, Dec 13 2009 11:10 am
From: Frederic Weisbecker

On Sun, Dec 13, 2009 at 07:17:26PM +0100, Ingo Molnar wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> >
> >
> > On Sun, 13 Dec 2009, Ingo Molnar wrote:
> > >
> > > In the last ~4.5 years:
> > >
> > > earth4:~/tip> git checkout v2.6.12
> > > Date: Fri Jun 17 12:48:29 2005 -0700
> > > earth4:~/tip> git grep -w unlock_kernel | wc -l
> > > 713
> > >
> > > earth4:~/tip> git checkout linus
> > > Date: Fri Dec 11 20:58:20 2009 -0800
> > > earth4:~/tip> git grep -w unlock_kernel | wc -l
> > > 841
> >
> > Git hint of the day: you don't need to check out a kernel to do "git
> > grep".
> >
> > Do this:
> >
> > git grep -w unlock_kernel v2.6.12 | wc
> >
> > and it will JustWork(tm).
>
> /me adds it to the metal toolbox
>
> > > Also, a lot of BKL use was hidden before, and due to the BKL removal
> > > activities (by Thomas, Frederic, Jon, Alan and others) the remaining BKL using
> > > sites are a lot more well defined, a lot more isolated and thus a lot more
> > > removable than ever before.
> >
> > That's the main thing. We've been pushing them down a lot.
> >
> > We still have a few annoying core ones, though. I hate the execve() and file
> > locking ones.
>
> When we did the BKL-as-a-mutex trick and let lockdep loose on it, three areas
> were particularly tricky: tty, reiser3 and NFS. tty and reiserfs should be ok
> now, but i havent seen much activity on the NFS front.
>
> Ingo

Nfs was a problem in the BKL-as-a-mutex tree because it is acquired
recursively and then locked up. And I suspect this recursion happens
only on mount time because vfs acquires it too there.

But looking at it more closely, it doesn't look that dramatic at
a first glance.

git-grep unlock_kernel fs/nfs

fs/nfs/callback.c: unlock_kernel();
fs/nfs/callback.c: unlock_kernel();

In nfs4_callback_svc() it embraces the socket
listening/processing callback thread.

svc_recv() might sleep so the bkl can be
lost in the middle.

And then svc_process().

This doesn't seem to protect anything there.

In nfs4_callback_svc() it's about the same thing, plus
a list manipulation but protected by a spinlock.

fs/nfs/delegation.c: unlock_kernel();
fs/nfs/delegation.c: unlock_kernel();
fs/nfs/nfs4state.c: unlock_kernel();
fs/nfs/nfs4state.c: unlock_kernel();

In the above cases we have the following comment:

/* Protect inode->i_flock using the BKL */

And really it doesn't seem to protect anything else,
fortunately it is acquired in a short path.

fs/nfs/super.c: unlock_kernel();
fs/nfs/super.c: unlock_kernel();

Protect the mount/unmount path, a bit trickier there.

But really that looks way much easier to fix than it was
with reiserfs.

==============================================================================
TOPIC: ftrace.h: Use common pr_info fmt string
http://groups.google.com/group/linux.kernel/t/53039310827bd848?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Dec 13 2009 10:00 am
From: Joe Perches

On Sun, 2009-12-13 at 15:50 +0100, Frederic Weisbecker wrote:
> On Sun, Dec 13, 2009 at 09:48:15AM -0500, Steven Rostedt wrote:
> > > pr_info("event trace: Could not activate trace point " \
> > > - "probe to " #call "\n"); \
> > > + "probe to %s\n", #call); \
> > This reduces format string space a bit, but doesn't it just add another
> > string to the string tables #func == "func" as well as add code to pass
> > in another parameter?
> Yeah, I don't understand the purpose of this patch either...

For sched, it reduces size by ~1k.

== 2 of 2 ==
Date: Sun, Dec 13 2009 10:40 am
From: Joe Perches

The patch from Li Zefan you've already queued is better

http://lkml.org/lkml/2009/12/13/60

Subject: [PATCH 03/13] tracing: Move a printk out of ftrace_raw_reg_event_foo()
Date: Sun, 13 Dec 2009 14:08:04 +0100
From: Li Zefan <lizf@cn.fujitsu.com>

Move the printk from each ftrace_raw_reg_event_foo() to
its caller ftrace_event_enable_disable(). This avoids each
regfunc trace event callbacks to handle a same error report
that can be carried from the caller.

==============================================================================
TOPIC: Poor KVM guest performance on an HP rack server
http://groups.google.com/group/linux.kernel/t/454ae5bda4756254?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 10:40 am
From: Jeremy Fitzhardinge

On 12/13/09 02:12, Ozan Çağlayan wrote:
> Hmm, that's because we're using/developing a Linux distribution which
> doesn't have 64-bit support yet. But since the guest will be a
> compile-farm for our needs, it's worth trying to run an 64-bit distro on
> the host to see the difference, thanks for the tip but how much should
> this affect the performance?

32-bit PAE is marginal above 4G of memory and the limit is at about 8G.
Above that, so much lowmem (<~1GB) is occupied by page and other kernel
structures that there's barely any memory to do any real work. If this
is what's happening, you'd expect to see poor host performance, and slow
guest performance would be secondary to that.

With 64-bit, all the memory can be directly addressed so none of this
applies. I would expect to see significant performance gains.

There's nothing to stop you from running 32-bit PAE guests, so you can
do your distro development that way (at least in part).

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: RFC: new kqueue API
http://groups.google.com/group/linux.kernel/t/959114a87facd3e4?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 10:40 am
From: Andi Kleen

On Sun, Dec 13, 2009 at 11:37:13AM +0100, Stefani Seibold wrote:
> As i figured out during the port the old kfifo API users, most of them
> did not need a streamed fifo, because there work only with fixed size
> entries. The kfifo is oversized for this kind of users, so i decided to
> write a new kqueue API which is optimized for fixed size entries.
>
> There are a some benefits:
>
> - Performance (a put or get of an integer does only generate 4 assembly
> instructions on a x86)
> - Type save
> - Cleaner interface
> - Easier to use
> - Less error prone
> - Smaller footprint
>
> The API is similar to the new kfifo API, but there is no need for a
> length paramter, because the size of the entry is know by the queue
> structure.

I must say I'm a bit sceptical if the advantages are really worth
the additional code. That code would be always compiled in in addition
to kfifo, so at least the code footprint would be always larger.

Perhaps you could get the advantages for type-safety using
inline wrappers to kfifo?

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: LTTng 0.181 for Linux kernel 2.6.32
http://groups.google.com/group/linux.kernel/t/34079b18b4556286?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 10:50 am
From: Josh Boyer

On Fri, Dec 04, 2009 at 11:06:33AM -0500, Mathieu Desnoyers wrote:
>Hi,
>
>I just released LTTng 0.181 for Linux kernel 2.6.32. All packages and
>links to the git tree can be found at:
>
>http://www.lttng.org
>
>Comment and feedback are always welcome.

This fails to build for PowerPC 44x. The following trivial patch fixes it.

josh

From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Subject: Fix LTTng 0.181 compilation on PowerPC

LTTng fails to build on powerpc due to a missing #include in the instrumented
arch/powerpc/kernel/timer.c file. Fix it.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 5465ab2..3e7f6e4 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -54,6 +54,7 @@
#include <linux/irq.h>
#include <linux/delay.h>
#include <linux/perf_event.h>
+#include <trace/trap.h>

#include <asm/io.h>
#include <asm/processor.h>

==============================================================================
TOPIC: Fix various __task_cred related invalid RCU assumptions
http://groups.google.com/group/linux.kernel/t/67b4e9e8ac2af84a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 11:00 am
From: Peter Zijlstra

On Wed, 2009-12-09 at 21:34 -0800, Paul E. McKenney wrote:

> Ah -- I have a related lockdep question. Is there a primitive that says
> whether or not the current task holds at least one lock of any type?
> If so, I would like to make rcu_dereference() do at least a little crude
> checking for this problem.

Hmm, no, but that's not hard to do, however I actually implemented
something like that for RCU a long while ago and that gives a metric TON
of false positives due to things like the radix tree which are RCU-safe
but are not required to be used with RCU.

==============================================================================
TOPIC: ksoftirqd problem
http://groups.google.com/group/linux.kernel/t/db92cb20826e2f64?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 11:10 am
From: Nico

Hi,

I recently switched to kernel 2.6.32 (self configured/compiled) and I've noticed an odd behavior on one of my servers. I run a bittorrent tracker on one of my servers and when using kernel 2.6.32, every now and then ksoftirqd will jump up to 20% of my CPU for almost a minute. The tracker has a total peers amount of ~45000 peers (if it matters) and this behavior seems to only happen under kernel 2.6.32. Switching back to kernel 2.6.31.1 on the server, ksoftirdq does not behave that way.

Any thoughts?

PS: please CC me as I'm not subscribed to the list

Thanks :)

_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: : Networking
http://groups.google.com/group/linux.kernel/t/9ff0256420d73f04?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 11:10 am
From: William Allen Simpson

Andrew Morton wrote:
> On Sat, 12 Dec 2009 05:10:32 -0500 William Allen Simpson <william.allen.simpson@gmail.com> wrote:
>
>> David Miller wrote:
>>> David S. Miller (4):
>>> Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6
>>> tcp: Remove runtime check that can never be true.
>> This is a poor patch that was never sent to the netdev list for review.
>
> It's better than the original code, which was checking to see whether a
> u8 exceeded 536!
>
It's preventative, to insure against changes to field sizes. And it's
correct C in form that has compiled without error for a dozen years. But
as you pointed out, gcc 4.0 generates a warning, while gcc 4.4 doesn't....

In the olden days, we'd have done these tests with preprocessor code, and
that's apparently the style that Linux still prefers. Sorry, I've not paid
much attention since early debian, so I'm not up on the current state of
undocumented Linux defines.

As I mentioned in an early post to the netdev list, while I've long had
credit in BSD-derived systems, this is the first I've tried to implement for
Linux kernel -- although I did give permission 15 or so years ago for a fair
amount of my stuff to be ported here under GPL....

Thanks in advance for your patience.

>> Please substitute the better patch in the main tree.
>
> Linus won't remove a commit from the middle of David's merge and
> replace it with some unchangelogged, un-signed-off alternative.
>
Actually, it *was* change-logged, discussed, and signed-off:

http://www.spinics.net/lists/netdev/msg115570.html

David rejected it with the deeply explanatory message:

"Guess again."

http://www.spinics.net/lists/netdev/msg115585.html

I'll also remind you that David has previously rejected range-checking in
other patches of mine, with the message:

"You're being way too anal here, and adding these checks to
drivers would be just a lot of rediculious bloat." [sic]

So, we have a fundamental difference about checking for negative before
stuffing a signed value into an unsigned value.

Then again, in 30+ years, AFAIK I've never shipped code that had a
serious denial of service attack because of a failure to range check.
Yes, I'm referring to 2.6.29, .30, and .31.

I may not be perfect, but I try really, really hard to get it right.

> An appropriate way to handle this is to prepare a new patch against
> Linus or David's tree after this merge has been performed. Package
> that patch in the usual way and send it to the usual recipients. That's
> the no-fuss, no-drama, stuff-gets-done path.
>
It was ready before the merge was performed -- instead we got Miller-lite
drama, fuss, and no-stuff-gets-done....

Since David has rejected it, I was using this message to appeal.

Is there no ability to appeal poor decisions by a maintainer?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Please pull NFS client updates and bugfixes
http://groups.google.com/group/linux.kernel/t/1df72db3f9de8a54?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 13 2009 11:10 am
From: Trond Myklebust

Hi Linus,

Please pull from the repository at

git pull git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git

This will update the following files through the appended changesets.

Cheers,
Trond

commit 190f38e5cedc910940b1da9015f00458c18f97b4
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 10 09:05:55 2009 -0500

NFS: Fix nfs_migrate_page()

The call to migrate_page() will cause the page->private field to be
cleared.
Also fix up the locking around the page->private transfer, so that we ensure
that calls to nfs_page_find_request() don't end up racing.

Finally, fix up a double free bug: nfs_unlock_request() already calls
nfs_release_request() for us...

Reported-by: Wu Fengguang <fengguang.wu@intel.com>
Tested-by: Andi Kleen <andi@firstfloor.org>
Cc: stable@kernel.org
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 053e324f67b9921fe7de0c4cbc720d29cb4bf207
Author: Suresh Jayaraman <sjayaraman@suse.de>
Date: Wed Dec 9 23:15:22 2009 +0530

rpc: remove unneeded function parameter in gss_add_msg()

The pointer to struct gss_auth parameter in gss_add_msg is not really needed
after commit 5b7ddd4a. Zap it.

Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 7cab89b275fd5647e72b781ac41b58a214640334
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Tue Dec 8 14:35:28 2009 -0500

nfs41: Invoke RECLAIM_COMPLETE on all new client ids

The NFSv4.1 spec indicates RECLAIM_COMPLETE is to be issued
whenever a client establishes a new client id, not only after
detecting the server has rebooted.

Set the NFS4CLNT_RECLAIM_REBOOT bit after every new client id has
been established. This enables us to issue RECLAIM_COMPLETE
during the wrap up of the NFS4CLNT_RECLAIM_REBOOT state.

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 480e3243df156e39eea6c91057e2ae612a6bbe19
Author: Roel Kluin <roel.kluin@gmail.com>
Date: Tue Dec 8 13:13:03 2009 -0500

SUNRPC: IS_ERR/PTR_ERR confusion

IS_ERR returns 1 or 0, PTR_ERR returns the error value.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 88069f77e1ac580a495762ce7a631c251c52cb90
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Tue Dec 8 08:33:16 2009 -0500

NFSv41: Fix a potential state leakage when restarting nfs4_close_prepare

Currently, if the call to nfs4_setup_sequence() in nfs4_close_prepare
fails, any later retries will fail to launch an RPC call, due to the fact
that the &state->flags will have been cleared.
Ditto if nfs4_close_done() triggers a call to the NFSv4.1 version of
nfs_restart_rpc().

We therefore move the actual clearing of the state->flags to
nfs4_close_done(), when we know that the RPC call was successful.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 74e7bb73a3e0d15a7db10b0f2b2efdeeef36609e
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Mon Dec 7 09:48:30 2009 -0500

nfs41: Handle NFSv4.1 session errors in the delegation recall code

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 79708861189eb89dea6711bd0464b097b69e7c79
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Mon Dec 7 09:23:21 2009 -0500

nfs41: Retry delegation return if it failed with session error

Update nfs4_delegreturn_done() to retry the operation after setting the
NFS4CLNT_SESSION_SETUP bit to indicate the need to reset the session.

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit bcfa49f6f931ce4097309ca8501d842a6f0ac860
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Mon Dec 7 09:22:29 2009 -0500

nfs41: Handle session errors during delegation return

Add session error handling to nfs4_open_delegation_recall()

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit f455848a11cbbf15989609a46b24e81a6f13a08e
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Mon Dec 7 09:16:09 2009 -0500

nfs41: Mark stateids in need of reclaim if state manager gets stale clientid

The state manager was not marking the stateids as needing to be reclaimed
after reestablishing the clientid.

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 0110ee152b69f8cbde19d8bc1dd59e197e419d76
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Mon Dec 7 09:00:24 2009 -0500

NFS: Fix up the declaration of nfs4_restart_rpc when NFSv4 not configured

Also rename it: it is used in generic code, and so should not have a 'nfs4'
prefix.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 9dfdf404c99347e2e224e25f8626e7b6399a05cd
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Sun Dec 6 12:57:34 2009 -0500

nfs41: Don't clear DRAINING flag on NFS4ERR_STALE_CLIENTID

If CREATE_SESSION fails with NFS4ERR_STALE_CLIENTID, don't clear the
NFS4CLNT_SESSION_DRAINING flag and don't wake RPCs waiting for the
session to be reestablished. We don't have a session yet, so there
is no reason to wake other RPCs.

This avoids sending spurious compounds with bogus sequenceID during
session and state recovery.

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
[Trond.Myklebust@netapp.com: cleaned up patch by adding the
nfs41_begin/end_drain_session() helpers]
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 9430fb6b5315f7bc94b05be915c64ebfefc55bbc
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Sun Dec 6 12:23:46 2009 -0500

nfs41: nfs41_setup_state_renewal

Move call to get the lease time and the setup of the state
renewal out of nfs4_create_session so that it can be called
after clearing the DRAINING flag. We use the getattr RPC
to obtain the lease time, which requires a sequence slot.

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit bcb56164ceb21317208eee89c829580d51b84a6d
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Sat Dec 5 19:32:19 2009 -0500

NFSv41: More cleanups

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 35dc1d74a8d97a302a202ccb6751bf2bdbf5173e
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Sat Dec 5 19:32:19 2009 -0500

NFSv41: Fix up some bugs in the NFS4CLNT_SESSION_DRAINING code

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit d61e612a728fb9bf848c4383f8f6645e822d5b57
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Sat Dec 5 19:32:19 2009 -0500

NFSv41: Clean up slot table management

We no longer need to maintain a distinction between nfs41_sequence_done and
nfs41_sequence_free_slot.

This fixes a number of slot table leakages in the NFSv4.1 code.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit f26468fb9384e73fb357d2e84d3e9c88c7d1129d
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Sat Dec 5 19:32:11 2009 -0500

NFSv41: Fix nfs4_proc_create_session

We should not assume that nfs41_init_clientid() will always want to
initialise the session. If it is being called due to a server reboot, then
we just want to reset the session after re-establishing the clientid.

Fix this by getting rid of the 'reset' parameter in
nfs4_proc_create_session(), and instead relying on whether or not the
session slot table pointer is non-NULL.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit da6ebfe34a3921cfb47b938fb819abc78c6080e5
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Sat Dec 5 16:08:41 2009 -0500

nfs41: Invoke RECLAIM_COMPLETE

This patch invokes RECLAIM_COMPLETE after the client is done
reclaiming state.

There are interpretations of the spec that suggest that
RECLAIM_COMPLETE should also be issued after a new clientid
has been obtained from the server and even if there is no
state to reclaim. This tells the server that the client
has no state to reclaim even if the client isn't aware the
server may have rebooted.

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit fce5c838e13392cc88a1330d1471fe6419e02ed7
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Sat Dec 5 16:08:41 2009 -0500

nfs41: RECLAIM_COMPLETE functionality

Implements RECLAIM_COMPLETE as an asynchronous RPC.
NFS4ERR_DELAY is retried, NFS4ERR_DEADSESSION invokes the error handling
but does not result in a retry, since we don't want to have a lingering
RECLAIM_COMPLETE call sent in the middle of a possible new state recovery
cycle. If a session reset occurs, a new wave of reclaim operations will
follow, containing their own RECLAIM_COMPLETE call. We don't want a
retry to get on the way of recovery by incorrectly indicating to the
server that we're done reclaiming state.

A subsequent patch invokes the functionality.

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 180197536b15d5862b389ce90b46ec8d004056f6
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Sat Dec 5 16:08:40 2009 -0500

nfs41: RECLAIM_COMPLETE XDR functionality

XDR encoding and decoding for RECLAIM_COMPLETE. Implements the necessary
encoding to indicate reclaim complete for the entire client. In the future,
it can be extended to provide reclaim complete functionality for a single
file system after migration.

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 8b173218bd7dfa5723ab96cc37b32dc380446bab
Author: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Date: Sat Dec 5 16:08:39 2009 -0500

Cleanup some NFSv4 XDR decode comments

Signed-off-by: Ricardo Labiaga <Ricardo.Labiaga@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 0556d1a6958ba15659ac2089ebc0a3c5e71f08a8
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Sat Dec 5 15:03:20 2009 -0500

NFSv41: nfs4_reset_session must always set NFS4CLNT_SESSION_DRAINING

Otherwise we have no guarantees that other processes won't start another
RPC call while we're resetting the session.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 2597641deae82c9a95e255518da189ab557da0af
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:48:55 2009 -0500

nfs41: v2 fix cb_recall bug

in NFSv4.1 the seqid part of a stateid in CB_RECALL must be 0

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 0629e370dd5819efa5cf8d418a8e6729efe388ef
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:46:14 2009 -0500

nfs41: check SEQUENCE status flag

the server can indicate a number of error conditions by setting the
appropriate bits in the SEQUENCE operation. The client re-establishes
state with the server when it receives one of those, with the action
depending on the specific case.

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 2449ea2e191123729b2dc37a06fcb9d6ea7e2736
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:36:55 2009 -0500

nfs41: V2 adjust max_rqst_sz, max_resp_sz w.r.t to rsize, wsize

The v4.1 client should take into account the desired rsize, wsize when
negotiating the max size in CREATE_SESSION. Accordingly, it should use
rsize, wsize that are smaller than the session negotiated values.

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 7b183d0d432ab3525ae29511a5348ead3e790620
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:33:25 2009 -0500

nfs41: remove server-only EXCHGID4_FLAG_CONFIRMED_R flag from exchange_id

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 4882ef72cd9a5c006087ca94a228323018eac29f
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:30:21 2009 -0500

nfs41: add support for the exclusive create flags

In v4.1 the client MUST/SHOULD use the EXCLUSIVE4_1 flag instead of
EXCLUSIVE4, and GUARDED when the server supports persistent sessions.
For now (and until we support suppattr_exclcreat), we don't send any
attributes with EXCLUSIVE4_1 relying in the subsequent SETATTR as in v4.0

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit d8cb1a7ce36d44602946f06af4267da304fb4011
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:29:53 2009 -0500

nfs41: check if session exists and if it is persistent

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 31f0960778c78198957cf02cc970d92b72b929e4
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:27:02 2009 -0500

nfs41: V2 initial support for CB_RECALL_ANY

For now the clients returns _all_ the delegations of the specificed type
it holds

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit c79571a508801e055a0be583d6dc70bddad7bb64
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:20:52 2009 -0500

nfs4: V2 return/expire delegations depending on their type

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit b4a6f4966efc7e70dc8d8a9e60744de6845b14bf
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:19:11 2009 -0500

nfs4: minor delegation cleaning

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 07bccc2dd4e8745859f0fa7d120ea39320fbcdbf
Author: Alexandros Batsakis <batsakis@netapp.com>
Date: Sat Dec 5 13:19:01 2009 -0500

nfs41: add support for callback with RPC version number 4

The NFSv4.1 spec-29 (18.36.3) says that the server MUST use an ONC RPC
(program) version number equal to 4 in callbacks sent to the client.
For now we allow both versions 1 and 4.

Signed-off-by: Alexandros Batsakis <batsakis@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 0b9e2d41f1f0360be08809d4e3bb56b67be6241a
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 16:02:14 2009 -0500

nfs41: only state manager sets NFS4CLNT_SESSION_SETUP

Replace sync and async handlers setting of the NFS4CLNT_SESSION_SETUP bit with
setting NFS4CLNT_CHECK_LEASE, and let the state manager decide to reset the session.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 691daf3b0c410c8bcab6735796be03ea446e1924
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:39 2009 -0500

nfs41: drain session cleanup

Do not wake up the next slot_tbl_waitq task in nfs4_free_slot because we
may be draining the slot. Either signal the state manager that the session
is drained (the state manager wakes up tasks) OR wake up the next task.

In nfs41_sequence_done, the slot dereference is only needed in the sequence
operation success case.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit ea028ac92541ac30bf202ed94cb53eec2ea0c9d6
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:38 2009 -0500

nfs41: nfs41: fix state manager deadlock in session reset

If the session is reset during state recovery, the state manager thread can
sleep on the slot_tbl_waitq causing a deadlock.

Add a completion framework to the session. Have the state manager thread set
a new session state (NFS4CLNT_SESSION_DRAINING) and wait for the session slot
table to drain.

Signal the state manager thread in nfs41_sequence_free_slot when the
NFS4CLNT_SESSION_DRAINING bit is set and the session is drained.

Reported-by: Trond Myklebust <trond@netapp.com>
Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 05f0d2364726c92f6b870db654967088349379fe
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:37 2009 -0500

nfs41: remove nfs4_recover_session

nfs4_recover_session can put rpciod to sleep. Just use nfs4_schedule_recovery.

Reported-by: Trond Myklebust <trond.myklebust@netapp.com>
Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 2628eddff15cb38b7246d5c18e2f7dc3e2c0d0c2
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:35 2009 -0500

nfs41: don't clear tk_action on success

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 8ba9bf8e5160b0b4ebc56f64ad445c6c0ecdac1d
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:34 2009 -0500

nfs41: fix switch in nfs4_recovery_handle_error

Do not fall through and set NFS4CLNT_SESSION_RESET bit on NFS4ERR_EXPIRED

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit b9179237e2b2b4d34b5821cca3db280ebbc8694a
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:32 2009 -0500

nfs41: fix switch in nfs4_handle_exception

Do not fall through and call nfs4_delay on session error handling.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 36bbe34239f63377b5179ad32fd13cd71d6e1ba7
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:30 2009 -0500

nfs41: free the slot on unhandled read errors

nfs4_read_done returns zero on unhandled errors. nfs_readpage_result will
return on a negative tk_status without freeing the slot.
Call nfs4_sequence_free_slot on unhandled errors in nfs4_read_done.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit e608e79f1bf4b967afcf57777e63b5f0939b00e8
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:29 2009 -0500

nfs41: call free slot from nfs4_restart_rpc

nfs41_sequence_free_slot can be called multiple times on SEQUENCE operation
errors.
No reason to inline nfs4_restart_rpc

Reported-by: Trond Myklebust <trond.myklebust@netapp.com>

nfs_writeback_done and nfs_readpage_retry call nfs4_restart_rpc outside the
error handler, and the slot is not freed prior to restarting in the rpc_prepare
state during session reset.

Fix this by moving the call to nfs41_sequence_free_slot from the error
path of nfs41_sequence_done into nfs4_restart_rpc, and by removing the test
for NFS4CLNT_SESSION_SETUP.
Always free slot and goto the rpc prepare state on async errors.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 1d9ddde94aed01c4618cf6f70883cc511c3b2b62
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:27 2009 -0500

nfs41: nfs4_get_lease_time will never session reset

Make this clear by calling rpc_restart-call.
Prepare for nfs4_restart_rpc() to free slots.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 6df08189ffd33d8357759561dba49d25c0335858
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:55:05 2009 -0500

nfs41: rename cl_state session SETUP bit to RESET

The bit is no longer used for session setup, only for session reset.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 4d643d1dfa9349164fe928e255f68020d91dbfe0
Author: Andy Adamson <andros@netapp.com>
Date: Fri Dec 4 15:52:24 2009 -0500

nfs41: add create session into establish_clid

Reported-by: Trond Myklebust <trond.myklebust@netapp.com>

Resetting the clientid from the state manager could result in not confirming
the clientid due to create session not being called.

Move the create session call from the NFS4CLNT_SESSION_SETUP state manager
initialize session case into the NFS4CLNT_LEASE_EXPIRED case establish_clid
call.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 44ed3556bad809797f7b06a4a88918fd8a23d6fe
Author: NeilBrown <neilb@suse.de>
Date: Thu Dec 3 15:58:56 2009 -0500

NFS4ERR_FILE_OPEN handling in Linux/NFS

NFS4ERR_FILE_OPEN is return by the server when an operation cannot be
performed because the file is currently open and local (to the server)
semantics prohibit the operation while the file is open.
A typical case is a RENAME operation on an MS-Windows platform, which
prevents rename while the file is open.

While it is possible that such a condition is transitory, it is also
very possible that the file will be held open for an extended period
of time thus preventing the operation.

The current behaviour of Linux/NFS is to retry the operation
indefinitely. This is not appropriate - we do not expect a rename to
take an arbitrary amount of time to complete.

Rather, and error should be returned. The most obvious error code
would be EBUSY, which is a legal at least for 'rename' and 'unlink',
and accurately captures the reason for the error.

This patch allows a few retries until about 2 seconds have elapsed,
then returns EBUSY.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 24e93025ee434a58d35e5abb283c5bcc9a13e477
Author: Miklos Szeredi <mszeredi@suse.cz>
Date: Thu Dec 3 15:58:56 2009 -0500

nfs: clean up sillyrenaming in nfs_rename()

The d_instantiate(new_dentry, NULL) is superfluous, the dentry is
already negative. Rehashing this dummy dentry isn't needed either,
d_move() works fine on an unhashed target.

The re-checking for busy after a failed nfs_sillyrename() is bogus
too: new_dentry->d_count < 2 would be a bug here.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 27226104e60964f21717e0f452cecd45c85a64c6
Author: Miklos Szeredi <mszeredi@suse.cz>
Date: Thu Dec 3 15:58:56 2009 -0500

nfs: dont unhash target if renaming a directory

Move unhashing the target to after the check for existence and being a
non-directory.

If renaming a directory then the VFS already unhashes the target if it
is not busy. If it's busy then acquiring more references during the
rename makes no difference.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 28f79a1a695e7a5b00af3b6713b449e08581ffbb
Author: Miklos Szeredi <mszeredi@suse.cz>
Date: Thu Dec 3 15:58:56 2009 -0500

nfs: fix comments in nfs_rename()

Comments are wrong or out of date. In particular d_drop() doesn't
free the inode it just unhashes the dentry. And if target is a
directory then it is not checked for being busy.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit e48de5ec25b37d42292c876c1d3337766aae89bd
Author: Miklos Szeredi <mszeredi@suse.cz>
Date: Thu Dec 3 15:58:56 2009 -0500

nfs: remove unnecessary check from nfs_rename()

VFS already checks if both source and target are directories.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 9c4c761a629caa5572c1a29a8288416070d5d6b7
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 15:58:56 2009 -0500

NFSv4.1: Handle NFSv4.1 session errors in the lock recovery code

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 3a28becc35e5c8f1fabb707bcd8a473712653de6
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: soft connect semantics for UDP

Introduce soft connect behavior for UDP transports. In this case, a
major timeout returns ETIMEDOUT instead of EIO.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit caabea8a565fb4e16f8e58e16bb9d535e591b709
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: Use soft connect semantics when performing RPC ping

Currently, if a remote RPC service is unreachable, an RPC ping will
hang until the underlying transport connect attempt times out. A more
desirable behavior might be to have the ping fail immediately so upper
layers can recover appropriately.

In the case of an NFS mount, for instance, this would mean the
mount(2) system call could fail immediately if the server isn't
listening, rather than hanging uninterruptibly for more than 3
minutes.

Change rpc_ping() so that it fails immediately for connection-oriented
transports. rpc_create() will then fail immediately for such
transports if an RPC ping was requested.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 012da158f636347c4eb28fd1e1cca020fef5e54d
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: Use soft connects for autobinding over TCP

Autobinding is handled by the rpciod process, not in user processes
that are generating regular RPC requests. Thus autobinding is usually
not affected by signals targetting user processes, such as KILL or
timer expiration events.

In addition, an RPC request generated by a user process that has
RPC_TASK_SOFTCONN set and needs to perform an autobind will hang if
the remote rpcbind service is not available.

For rpcbind queries on connection-oriented transports, let's use the
new soft connect semantic to return control to the user's process
quickly, if the kernel's rpcbind client can't connect to the remote
rpcbind service.

Logic is introduced in call_bind_status() to handle connection errors
that occurred during an asynchronous rpcbind query. The logic
abandons the rpcbind query if the RPC request has SOFTCONN set, and
retries after a few seconds in the normal case.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 2a76b3bfa22993fc09166bd6a8db0dbe902b6813
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: Use TCP for local rpcbind upcalls

Use TCP with the soft connect semantic for local rpcbind upcalls so
the kernel can detect immediately if the local rpcbind daemon is not
running.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>

commit c526611dd631b2802b6b0221ffb306c5fa25c86c
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: Use a cached RPC client and transport for rpcbind upcalls

The kernel's rpcbind client creates and deletes an rpc_clnt and its
underlying transport socket for every upcall to the local rpcbind
daemon.

When starting a typical NFS server on IPv4 and IPv6, the NFS service
itself does three upcalls (one per version) times two upcalls (one
per transport) times two upcalls (one per address family), making 12,
plus another one for the initial call to unregister previous NFS
services. Starting the NLM service adds an additional 13 upcalls,
for similar reasons.

(Currently the NFS service doesn't start IPv6 listeners, but it will
soon enough).

Instead, let's create an rpc_clnt for rpcbind upcalls during the
first local rpcbind query, and cache it. This saves the overhead of
creating and destroying an rpc_clnt and a socket for every upcall.

The new logic also prevents the kernel from attempting an RPCB_SET or
RPCB_UNSET if it knows from the start that the local portmapper does
not support rpcbind protocol version 4. This will cut down on the
number of rpcbind upcalls in legacy environments.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>

commit 5a46211540a83871196489247f57da2bdde58d87
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: Simplify synopsis of rpcb_local_clnt()

Clean up: At one point, rpcb_local_clnt() handled IPv6 loopback
addresses too, but it doesn't any more; only IPv4 loopback is used
now. Get rid of the @addr and @addrlen arguments to
rpcb_local_clnt().

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 09a21c4102c8f7893368553273d39c0cadedf9af
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: Allow RPCs to fail quickly if the server is unreachable

The kernel sometimes makes RPC calls to services that aren't running.
Because the kernel's RPC client always assumes the hard retry semantic
when reconnecting a connection-oriented RPC transport, the underlying
reconnect logic takes a long while to time out, even though the remote
may have responded immediately with ECONNREFUSED.

In certain cases, like upcalls to our local rpcbind daemon, or for NFS
mount requests, we'd like the kernel to fail immediately if the remote
service isn't reachable. This allows another transport to be tried
immediately, or the pending request can be abandoned quickly.

Introduce a per-request flag which controls how call_transmit_status()
behaves when request transmission fails because the server cannot be
reached.

We don't want soft connection semantics to apply to other errors. The
default case of the switch statement in call_transmit_status() no
longer falls through; the fall through code is copied to the default
case, and a "break;" is added.

The transport's connection re-establishment timeout is also ignored for
such requests. We want the request to fail immediately, so the
reconnect delay is skipped. Additionally, we don't want a connect
failure here to further increase the reconnect timeout value, since
this request will not be retried.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 206a134b4d8abf57cd34dffacf993869355b9aac
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: Check explicitly for tk_status == 0 in call_transmit_status()

The success case, where task->tk_status == 0, is by far the most
frequent case in call_transmit_status().

The default: arm of the switch statement in call_transmit_status()
handles the 0 case. default: was moved close to the top of the switch
statement in call_transmit_status() under the theory that the compiler
places object code for the earliest arms of a switch statement first,
making the CPU do less work.

The default: arm of a switch statement, however, is executed only
after all the other cases have been checked. Even if the compiler
rearranges the object code, the default: arm is the "last resort",
meaning all of the other cases have been explicitly exhausted. That
makes the current arrangement about as inefficient as it gets for the
common case.

To fix this, add an explicit check for zero before the switch
statement. That forces the compiler to do the zero check first, no
matter what optimizations it might try to do to the switch statement.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit dd47f96c077b4516727e497e4b6fd47a06778c0a
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

NFS: Revert default r/wsize behavior

When the "rsize=" or "wsize=" mount options are not specified,
text-based mounts have slightly different behavior than legacy binary
mounts. Text-based mounts use the smaller of the server's maximum
and the client's maximum, but binary mounts use the smaller of the
server's _preferred_ size and the client's maximum.

This difference is actually pretty subtle. Most servers advertise
the same value as their maximum and their preferred transfer size, so
the end result is the same in most cases.

The reason for this difference is that for text-based mounts, if
r/wsize are not specified, they are set to the largest value supported
by the client. For legacy mounts, the values are set to zero if these
options are not specified.

nfs_server_set_fsinfo() can negotiate the transfer size defaults
correctly in any case. There's no need to specify any particular
value as default in the text-based option parsing logic.

Note that nfs4 doesn't use nfs_server_set_fsinfo(), but the mount.nfs4
command does set rsize and wsize to 0 if the user didn't specify these
options. So, make the same change for text-based NFSv4 mounts.

Thanks to James Pearson <james-p@moving-picture.com> for reporting and
diagnosing the problem.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit d250e190fb9b06f4c595eade88b3d0b705fb330a
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

NFS: Display compressed (shorthand) IPv6 in /proc/mounts

Recent changes to snprintf() introduced the %pI6c formatter, which can
display an IPv6 address with standard shorthanding. Use this new
formatter when displaying IPv6 server addresses in /proc/mounts.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit dd1fd90fe65e2e642f0e58e2ff4849f317a6c43d
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Dec 3 15:58:56 2009 -0500

SUNRPC: Display compressed (shorthand) IPv6 presentation addresses

Recent changes to snprintf() introduced the %pI6c formatter, which can
display an IPv6 address with standard shorthanding. Using a
shorthanded address can save us a few bytes of memory for each stored
presentation address, or a few bytes on the wire when sending these in
a universal address.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit a01878aac57eac6eb4bf194788ab2cc440490d0f
Author: Richard Kennedy <richard@rsk.demon.co.uk>
Date: Thu Dec 3 15:58:56 2009 -0500

NFS: reorder nfs4_sequence_regs to remove 8 bytes of padding on 64 bits

reorder nfs4_sequence_args to remove 8 bytes of padding on 64 bit
builds.

The size of this structure drops to 24 bytes from 32 and reduces the
text size of nfs.ko.
On my x86_64 size reports

text data bss
2.6.32-rc5 200996 8512 432 209940 33414 nfs.ko
+patch 200884 8512 432 209828 333a4 nfs.ko

Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit ee671b016fbfc26d69c3fe02e28706222beb1149
Author: Jeff Layton <jlayton@redhat.com>
Date: Thu Dec 3 15:58:56 2009 -0500

NFS: convert proto= option to use netids rather than a protoname

Solaris uses netids as values for the proto= option, so that when
someone specifies "tcp6" they get traffic over TCP + IPv6. Until
recently, this has never really been an issue for Linux since it didn't
support NFS over IPv6. The netid and the protocol name were generally
always the same (modulo any strange configuration in /etc/netconfig).

The solaris manpage documents their proto= option as:

proto= _netid_ | rdma

This patch is intended to bring Linux closer to how the Solaris proto=
option works, by declaring a static netid mapping in the kernel and
converting the proto= and mountproto= options to follow it and display
the proper values in /proc/mounts.

Much of this functionality will need to be provided by a userspace
mount.nfs patch. Chuck Lever has a patch to change mount.nfs in
the same way. In principle, we could do *all* of this in userspace but
that would mean that the options in /proc/mounts may not match the
options used by userspace.

The alternative to the static mapping here is to add a mechanism to
upcall to userspace for netid's. I'm not opposed to that option, but
it'll probably mean more overhead (and quite a bit more code). Rather
than shoot for that at first, I figured it was probably better to
start simply.

Comments welcome.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit d4e935bd67ca05db4119b67801d9ece6ae139f05
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Thu Dec 3 15:58:33 2009 -0500

The rpc server does not require that service threads take the BKL.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 1185a552e3d78807031f4021c5edb60d3e8838f1
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 15:54:02 2009 -0500

NFSv4: Ensure nfs4_close_context() is declared as static

Fix another 'sparse' warning in fs/nfs/nfs4proc.c

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 0a6566ecd3afc74aad11c2e07794ff5529c13862
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 15:54:01 2009 -0500

NFSv4: Ensure nfs_dns_lookup() and nfs_dns_update() are declared static

Fix two 'sparse' warnings in fs/nfs/dns_resolve.c

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit b6d408ba8c8be3646dea6f80a2fe55ac403119c8
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 15:53:22 2009 -0500

NFSv4: Fix up error handling in the state manager main loop.

The nfs4_state_manager should not be looking at the error values when
deciding whether or not to loop round in order to handle a higher priority
state recovery task. It should rather be looking at the clp->cl_state.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit a9ed2e2583747fb3139a764c317fac58893b968f
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 15:53:21 2009 -0500

NFSv4: Handle NFS4ERR_GRACE when recovering an expired lease.

If our lease expires, and the server reboots while we're recovering, we
need to be able to wait until the grace period is over.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit c8b7ae3d3221536228260757444ee10c6d71793f
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 15:53:21 2009 -0500

NFSv4: Ensure the state manager handles NFS4ERR_NO_GRACE correctly

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 4f7cdf18e14f81860b856ef7694ef58eb1a751c0
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 15:53:20 2009 -0500

NFSv4: The state manager shouldn't exit on errors that were handled

nfs4_recovery_handle_error() will correctly handle errors such as
NFS4ERR_CB_PATH_DOWN, however because they are still passed back to the
main loop in nfs4_state_manager(), they can cause the latter to exit
prematurely.

Fix this by letting nfs4_recovery_handle_error() change the error value in
cases where there is no action required by the caller.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit e345e88a774875cec26e097ea3ff2dc40c4f9da2
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 15:52:41 2009 -0500

NFSv4: Fix up the callers of nfs4_state_end_reclaim_reboot

In practice, we need to ensure that we call nfs4_state_end_reclaim_reboot
in 2 cases:

- If we lose the lease while we were reclaiming state
OR
- After we're done with reboot recovery

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit d18cc1fda25295416a2855d44c2936db01df9eec
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 08:10:17 2009 -0500

NFSv4: Fix a potential state manager deadlock when returning delegations

The nfsv4 state manager could potentially deadlock inside
__nfs_inode_return_delegation() if the server reboots, so that the calls to
nfs_msync_inode() end up waiting on state recovery to complete.

Also ensure that if a server reboot or network partition causes us to have
to stop returning delegations, that NFS4CLNT_DELEGRETURN is set so that
the state manager can resume any outstanding delegation returns after it
has dealt with the state recovery situation.

Finally, ensure that the state manager doesn't wait for the DELEGRETURN
call to complete. It doesn't need to, and that too can cause a deadlock.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit d327cf7449e6fd5cbac784c641770e9366faa386
Author: J. Bruce Fields <bfields@fieldses.org>
Date: Thu Dec 3 08:10:17 2009 -0500

Re: acl trouble after upgrading ubuntu

Subject: [PATCH] nfs: fix acl decoding

Commit 28f566942c6b1d929f5e240e69e7081b77b238d3 "NFS: use dynamically
computed compound_hdr.replen for xdr_inline_pages offset" accidentally
changed the amount of space to allow for the acl reply, resulting in an
IO error on attempts to get an acl.

Reported-by: Paul Rudin <paul@rudin.co.uk>
Cc: Benny Halevy <bhalevy@panasas.com>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit f0380f3d16df8f9e2fcd1d8c16fb0d94370bea99
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 08:10:17 2009 -0500

RPC: Fix two potential races in put_rpccred

It is possible for rpcauth_destroy_credcache() to cause the rpc credentials
to be unhashed while put_rpccred is waiting for the rpc_credcache_lock on
another cpu. Should this happen, then we can end up calling
hlist_del_rcu(&cred->cr_hash) a second time in put_rpccred, thus causing
list corruption.

Should the credential actually be hashed, it is also possible for
rpcauth_lookup_credcache to find and reference it before we get round to
unhashing it. In this case, the call to rpcauth_unhash_cred will fail, and
so we should just exit without destroying the cred.

Reported-by: Neil Brown <neilb@suse.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit feb8ca37cc3d83c07fd042509ef1e176cfeb2cfa
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 08:10:17 2009 -0500

SUNRPC: Ensure that we honour autoclose before attempting to reconnect

If the XPRT_CLOSE_WAIT flag is set, we need to ensure that we call
xprt->ops->close() while holding xprt_lock_write() before we can
start reconnecting.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 96f287b0cf512ee537826943c15b0b8647472f70
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Dec 3 08:09:56 2009 -0500

NFS: BKL removal from the mount code...

None of the code in nfs_umount_begin() or nfs_remount() has any BKL
dependency.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Sunday, December 13, 2009

linux.kernel - 26 new messages in 17 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts