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

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

Today's topics:

* kernel/rcutree.h:301: sorry, unimplemented: inlining failed in call to 'rcu_
bootup_announce': function body not available - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/61416b53d6226fba?hl=en
* x86: check range in update range - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dcbd272b5d2fe827?hl=en
* git pull on linux-next makes my system crawl to its knees and beg for mercy -
2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/109495e0b678b319?hl=en
* CPU probe/release files - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a267f22b644611d2?hl=en
* iplink: add macvlan options for bridge mode - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/6dcbb596faaefd95?hl=en
* Build error with 2.6.33-rc1 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/c9c996d28facd007?hl=en
* x86: do_debug && PTRACE_SINGLESTEP broken by 08d68323d1f0c34452e614263b212ca
556dae47f - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/253956bb28f9a94f?hl=en
* x86: initialize stack canary in secondary start - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2d346f902281bd0a?hl=en
* scripts/checkpatch.pl: Change long line warning to 105 chars - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/735854ce62c52e1e?hl=en
* Staging: vt665x depend on WIRELESS - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/346e4337e96055ec?hl=en
* Performance regression in scsi sequential throughput (iozone) due to "e084b -
page-allocator: preserve PFN ordering when __GFP_COLD is set" - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/0f198fe3053e9f98?hl=en
* anonfd: Make file read-only if fops->write is not set - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/73bcf73ccb2e0116?hl=en
* Security: Add prctl(PR_{GET,SET}_NETWORK) - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a960a1b4696443c0?hl=en
* FWD: [PATCH v2] vmscan: limit concurrent reclaimers in shrink_zone - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/a99f9348e2fa4b15?hl=en
* tg3 and bcm5703 cards - rx dropped packets - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f3bf1364d4aa0fb1?hl=en
* Makefile references to non-existent CONFIG variables - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fbd1103bb1029890?hl=en
* x86: Fix objdump version check in chkobjdump.awk for different formats. - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/3107dd6fb7b8b381?hl=en

==============================================================================
TOPIC: kernel/rcutree.h:301: sorry, unimplemented: inlining failed in call to
'rcu_bootup_announce': function body not available
http://groups.google.com/group/linux.kernel/t/61416b53d6226fba?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Dec 18 2009 9:30 am
From: "Paul E. McKenney"

On Fri, Dec 18, 2009 at 08:07:51AM -0900, Mr. James W. Laferriere wrote:
> Hello Paul (& Americo, ALL) ,
>
> On Fri, 18 Dec 2009, Paul E. McKenney wrote:
>> On Fri, Dec 18, 2009 at 05:52:51PM +0800, Américo Wang wrote:
>>> On Fri, Dec 18, 2009 at 1:45 PM, Mr. James W. Laferriere
>>> <babydr@baby-dragons.com> wrote:
>>>> Hello All ,
>>>>
>>>> gcc -Wp,-MD,kernel/.rcutree.o.d -nostdinc -isystem
>>>> /usr/lib/gcc/i486-slackware-linux/3.4.6/include -Iinclude
>>>> -I/usr/src/linux-2.6.32.1/arch/x86/include -include
>>>> include/linux/autoconf.h
>>>> -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
>>>> -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
>>>> -Wno-format-security -fno-delete-null-pointer-checks -O2 -m32
>>>> -msoft-float
>>>> -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2
>>>> -fno-unit-at-a-time -march=i686 -ffreestanding -DCONFIG_AS_CFI=1 -pipe
>>>> -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx
>>>> -mno-sse2 -mno-3dnow -fno-omit-frame-pointer -fno-optimize-sibling-calls
>>>> -g
>>>> -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s"
>>>> -D"KBUILD_BASENAME=KBUILD_STR(rcutree)"
>>>> -D"KBUILD_MODNAME=KBUILD_STR(rcutree)" -c -o kernel/rcutree.o
>>>> kernel/rcutree.c
>>>> kernel/rcutree.c: In function `__rcu_init':
>>>> kernel/rcutree.h:301: sorry, unimplemented: inlining failed in call to
>>>> 'rcu_bootup_announce': function body not available
>>>> kernel/rcutree.c:1740: sorry, unimplemented: called from here
>>>> make[1]: *** [kernel/rcutree.o] Error 1
>>>> make: *** [kernel] Error 2
>>>>
>>>> There is no way , thru the 'make *config' methods to
>>>> disable this
>>>> broken stuff , So How may I get past this brokeness ?
>>>> And looking the posts for the 2.6.32-pre/rc the old rcu has
>>>> been
>>>> trashed completely . So I am not able to even try using that .
>>>>
>>>> Would someone please shed some light on this . I really
>>>> need the
>>>> updates for the Fusion/mpt driver & the changes in the /md/ tree as well
>>>> .
>>>
>>> Hmm, I see the problem, but not sure how to fix it...
>>>
>>> Paul, why do we have #include "rcutree_plugin.h" at the bottom
>>> of rcutree.c? This looks strange for me...
>>>
>>> How about moving it up? At least just move upper to rcu_init().
>>
>> Could you please apply commit #dbe01350fa8ce0c11948ab7d6be71a4d901be151
>> from Linus's git tree? Corresponding diff attached.
>>
>> Thanx, Paul
>>
>> ------------------------------------------------------------------------
>>
>> diff --git a/kernel/rcutree.h b/kernel/rcutree.h
>> index c1891c3..ddb79ec 100644
>> --- a/kernel/rcutree.h
>> +++ b/kernel/rcutree.h
>> @@ -301,7 +301,7 @@ DECLARE_PER_CPU(struct rcu_data, rcu_preempt_data);
>> #else /* #ifdef RCU_TREE_NONCORE */
>>
>> /* Forward declarations for rcutree_plugin.h */
>> -static inline void rcu_bootup_announce(void);
>> +static void rcu_bootup_announce(void);
>> long rcu_batches_completed(void);
>> static void rcu_preempt_note_context_switch(int cpu);
>> static int rcu_preempted_readers(struct rcu_node *rnp);
>> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
>> index ef2a58c..c03edf7 100644
>> --- a/kernel/rcutree_plugin.h
>> +++ b/kernel/rcutree_plugin.h
>> @@ -33,7 +33,7 @@ DEFINE_PER_CPU(struct rcu_data, rcu_preempt_data);
>> /*
>> * Tell them what RCU they are running.
>> */
>> -static inline void rcu_bootup_announce(void)
>> +static void rcu_bootup_announce(void)
>> {
>> printk(KERN_INFO
>> "Experimental preemptable hierarchical RCU implementation.\n");
>> @@ -481,7 +481,7 @@ void exit_rcu(void)
>> /*
>> * Tell them what RCU they are running.
>> */
>> -static inline void rcu_bootup_announce(void)
>> +static void rcu_bootup_announce(void)
>> {
>> printk(KERN_INFO "Hierarchical RCU implementation.\n");
>> }
>
> Thank you & Americo for responding .
>
> Patch applied & same error as far as I can tell .
> did
>
> make mrproper
> cp ../old.config .config (same as in previous email)
> make oldconfig
> ( time make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install
> modules_install ) >../linux-2.6.32.1d.log 2>&1
> error'd (See below) ...
>
> If there is any further info I can provide or something I can do to
> provide , Please request it .

Hmmm.... Yes. Could you please execute the following command from
the top-level directory of your patched kernel source tree?

grep rcu_bootup_announce kernel/rcu*

I would expect the following output:

kernel/rcutree.c: rcu_bootup_announce();
kernel/rcutree.h:static void rcu_bootup_announce(void);
kernel/rcutree_plugin.h:static void __init rcu_bootup_announce(void)
kernel/rcutree_plugin.h:static void __init rcu_bootup_announce(void)

Thanx, Paul

> Tia , JimL
>
> gcc -Wp,-MD,kernel/.rcutree.o.d -nostdinc -isystem
> /usr/lib/gcc/i486-slackware-linux/3.4.6/include -Iinclude
> -I/usr/src/linux-2.6.32.1/arch/x86/include -include
> include/linux/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes
> -Wno-trigraphs -fno-strict-aliasing -fno-common
> -Werror-implicit-function-declaration -Wno-format-security
> -fno-delete-null-pointer-checks -O2 -m32 -msoft-float -mregparm=3
> -freg-struct-return -mpreferred-stack-boundary=2 -fno-unit-at-a-time
> -march=i686 -ffreestanding -DCONFIG_AS_CFI=1 -pipe -Wno-sign-compare
> -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
> -fno-omit-frame-pointer -fno-optimize-sibling-calls -g
> -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s"
> -D"KBUILD_BASENAME=KBUILD_STR(rcutree)"
> -D"KBUILD_MODNAME=KBUILD_STR(rcutree)" -c -o kernel/rcutree.o
> kernel/rcutree.c
> kernel/rcutree.c: In function `__rcu_init':
> kernel/rcutree.h:301: sorry, unimplemented: inlining failed in call to
> 'rcu_bootup_announce': function body not available
> kernel/rcutree.c:1740: sorry, unimplemented: called from here
> make[1]: *** [kernel/rcutree.o] Error 1
> make: *** [kernel] Error 2
>
>
> --
> +------------------------------------------------------------------+
> | James W. Laferriere | System Techniques | Give me VMS |
> | Network&System Engineer | 3237 Holden Road | Give me Linux |
> | babydr@baby-dragons.com | Fairbanks, AK. 99709 | only on AXP |
> +------------------------------------------------------------------+

--
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 2 ==
Date: Fri, Dec 18 2009 10:10 am
From: "Mr. James W. Laferriere"

Hello Paul ,

On Fri, 18 Dec 2009, Paul E. McKenney wrote:
> On Fri, Dec 18, 2009 at 08:07:51AM -0900, Mr. James W. Laferriere wrote:
>> On Fri, 18 Dec 2009, Paul E. McKenney wrote:
>>> On Fri, Dec 18, 2009 at 05:52:51PM +0800, Américo Wang wrote:
>>>> On Fri, Dec 18, 2009 at 1:45 PM, Mr. James W. Laferriere
>>>> <babydr@baby-dragons.com> wrote:
>>>>> Hello All ,
>>>>>
>>>>> gcc -Wp,-MD,kernel/.rcutree.o.d -nostdinc -isystem
>>>>> /usr/lib/gcc/i486-slackware-linux/3.4.6/include -Iinclude
>>>>> -I/usr/src/linux-2.6.32.1/arch/x86/include -include
>>>>> include/linux/autoconf.h
>>>>> -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
>>>>> -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
>>>>> -Wno-format-security -fno-delete-null-pointer-checks -O2 -m32
>>>>> -msoft-float
>>>>> -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2
>>>>> -fno-unit-at-a-time -march=i686 -ffreestanding -DCONFIG_AS_CFI=1 -pipe
>>>>> -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx
>>>>> -mno-sse2 -mno-3dnow -fno-omit-frame-pointer -fno-optimize-sibling-calls
>>>>> -g
>>>>> -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s"
>>>>> -D"KBUILD_BASENAME=KBUILD_STR(rcutree)"
>>>>> -D"KBUILD_MODNAME=KBUILD_STR(rcutree)" -c -o kernel/rcutree.o
>>>>> kernel/rcutree.c
>>>>> kernel/rcutree.c: In function `__rcu_init':
>>>>> kernel/rcutree.h:301: sorry, unimplemented: inlining failed in call to
>>>>> 'rcu_bootup_announce': function body not available
>>>>> kernel/rcutree.c:1740: sorry, unimplemented: called from here
>>>>> make[1]: *** [kernel/rcutree.o] Error 1
>>>>> make: *** [kernel] Error 2
>>>>>
>>>>> There is no way , thru the 'make *config' methods to
>>>>> disable this
>>>>> broken stuff , So How may I get past this brokeness ?
>>>>> And looking the posts for the 2.6.32-pre/rc the old rcu has
>>>>> been
>>>>> trashed completely . So I am not able to even try using that .
>>>>>
>>>>> Would someone please shed some light on this . I really
>>>>> need the
>>>>> updates for the Fusion/mpt driver & the changes in the /md/ tree as well
>>>>> .
>>>>
>>>> Hmm, I see the problem, but not sure how to fix it...
>>>>
>>>> Paul, why do we have #include "rcutree_plugin.h" at the bottom
>>>> of rcutree.c? This looks strange for me...
>>>>
>>>> How about moving it up? At least just move upper to rcu_init().
>>>
>>> Could you please apply commit #dbe01350fa8ce0c11948ab7d6be71a4d901be151
>>> from Linus's git tree? Corresponding diff attached.
>>>
>>> Thanx, Paul
>>>
>>> ------------------------------------------------------------------------
>>>
>>> diff --git a/kernel/rcutree.h b/kernel/rcutree.h
>>> index c1891c3..ddb79ec 100644
>>> --- a/kernel/rcutree.h
>>> +++ b/kernel/rcutree.h
>>> @@ -301,7 +301,7 @@ DECLARE_PER_CPU(struct rcu_data, rcu_preempt_data);
>>> #else /* #ifdef RCU_TREE_NONCORE */
>>>
>>> /* Forward declarations for rcutree_plugin.h */
>>> -static inline void rcu_bootup_announce(void);
>>> +static void rcu_bootup_announce(void);
>>> long rcu_batches_completed(void);
>>> static void rcu_preempt_note_context_switch(int cpu);
>>> static int rcu_preempted_readers(struct rcu_node *rnp);
>>> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
>>> index ef2a58c..c03edf7 100644
>>> --- a/kernel/rcutree_plugin.h
>>> +++ b/kernel/rcutree_plugin.h
>>> @@ -33,7 +33,7 @@ DEFINE_PER_CPU(struct rcu_data, rcu_preempt_data);
>>> /*
>>> * Tell them what RCU they are running.
>>> */
>>> -static inline void rcu_bootup_announce(void)
>>> +static void rcu_bootup_announce(void)
>>> {
>>> printk(KERN_INFO
>>> "Experimental preemptable hierarchical RCU implementation.\n");
>>> @@ -481,7 +481,7 @@ void exit_rcu(void)
>>> /*
>>> * Tell them what RCU they are running.
>>> */
>>> -static inline void rcu_bootup_announce(void)
>>> +static void rcu_bootup_announce(void)
>>> {
>>> printk(KERN_INFO "Hierarchical RCU implementation.\n");
>>> }
>>
>> Thank you & Americo for responding .
>>
>> Patch applied & same error as far as I can tell .
>> did
>>
>> make mrproper
>> cp ../old.config .config (same as in previous email)
>> make oldconfig
>> ( time make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install
>> modules_install ) >../linux-2.6.32.1d.log 2>&1
>> error'd (See below) ...
>>
>> If there is any further info I can provide or something I can do to
>> provide , Please request it .
>
> Hmmm.... Yes. Could you please execute the following command from
> the top-level directory of your patched kernel source tree?
>
> grep rcu_bootup_announce kernel/rcu*
>
> I would expect the following output:
>
> kernel/rcutree.c: rcu_bootup_announce();
> kernel/rcutree.h:static void rcu_bootup_announce(void);
> kernel/rcutree_plugin.h:static void __init rcu_bootup_announce(void)
> kernel/rcutree_plugin.h:static void __init rcu_bootup_announce(void)
>
> Thanx, Paul

This is with your patch applied on top of linux-2.6.32.1.tar.gz
no other patches or additions .

OK , it looks like I wandered right by the first file ie:
'kernel/rcutree.h' so I need to patch that as well . Doing this by hand as the
offending system is not online and all I have is serial console access presently
.
But , the last two you've changed to 'void __init' instead of just
'void' .
Do you want me to add those changes to the file
'kernel/rcutree_plugin.h' as well ?

# grep rcu_bootup_announce kernel/rcu*
kernel/rcutree.c: rcu_bootup_announce();
kernel/rcutree.h:static inline void rcu_bootup_announce(void);
kernel/rcutree_plugin.h:static void rcu_bootup_announce(void)
kernel/rcutree_plugin.h:static void rcu_bootup_announce(void)

==============================================================================
TOPIC: x86: check range in update range
http://groups.google.com/group/linux.kernel/t/dcbd272b5d2fe827?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 18 2009 9:30 am
From: Jesse Barnes

On Fri, 18 Dec 2009 01:46:59 -0800
Yinghai Lu <yinghai@kernel.org> wrote:

>
> fend off wrong range
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>

This could be merged with the previous patch.

--
Jesse Barnes, Intel Open Source Technology Center
--
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: git pull on linux-next makes my system crawl to its knees and beg for
mercy
http://groups.google.com/group/linux.kernel/t/109495e0b678b319?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Dec 18 2009 9:30 am
From: "Luis R. Rodriguez"

I can't describe it any better. It really is pissing me the fuck off,
its as if I have invisible elves using my nuts as punching bags.
Something is seriously fucked with 2.6.32, my box, or linux-next, or
perhaps there is another possibility someone might be able to help
enlighten me about which I am not considering. I'd also would love to
hear from others and see if I'm not the only one because if this issue
is reproducible, it would be bad. First let me describe the issue in
detail.

I tend to always be on a 2.6.32 kernel + John's queued up patches for
wireless for the next kernel release (I use wireless-testing). My
system is a Thinkpad T61, userspace is Ubuntu 9.10 based (ships with
git 1.6.3.3) and I kept an ext3 filesystem to be able to go back in
time to 2.6.27 at will without issues. I git clone'd linux-next a few
weeks ago. After a few days I then tried to git pull and my system
became completely unusable, It took *ages* to open up a terminal and
start running commands. Even ssh'ing into my box became a hassle to
the point that my *entire* morning was spent trying to patiently wait
for the git pull to finish. I gave up, I don't recall I had anything
on my kernel logs. Bewildered with this issue I set out to prove to
myself this issue was not a 2.6.32 issue and booted other kernels,
including Ubuntu's distro kernel on 2.6.31 and then later my own built
fresh 2.6.27.41 kernel. The issue was reproducible on all three
kernels!

This lead me to believe this was a system / hard drive issue and
embraced myself for a system fix. I yet needed to prove this was
indeed a system issue. I've been using myself without touching
linux-next for a while now and it works flawlessly, and even doing
testing with ath5k / ath9k for some random projects I have. I git pull
wireless-testing just fine, and pm-suspend just fine every day without
any hiccup.

I then started to suspect I probably got a fucked linux-next somehow,
I do recall I did pm-suspend during a pull of wireless-testing before
and never had issues after resume or with the tree at all. I don't
recall doing the pm-suspend with linux-next but it could be possible.
Since my last giving up on the 'git pull' of linux-next I tried to
'git reset --hard origin' and then trying a 'git pull' but saw my
issue easily becoming unusable again, I ctrl-c'd out of that quickly,
tried 'git fsck' and did fine some complaints. I started to want to
blame my hard drive so I rm -rf'd linux-next and tried a fresh clone.
It pulled fine, my system was slow but nothing *that* unusual.

A couple of days ago I do a 'git pull' again and ... my system starts
crying again, begging me to stop, so I did. My 'git describe' now
tells me I'm at next-20091211 and 'git fsck' tells me:

dangling tree 3500a4301d572e57c700d18d6730f4ac3e33b923
dangling tree e50022fd1e44c3ca63d57e5b263a8263fa5e291b
dangling tree c105e67e2b609e02eefe2b676e53f79b3e375a32
dangling tree 850b60a21ebf9721d16eeb7d68d6e6250893b558
dangling tree dd0bc64a4fe9eac9de3edb0db68d7a83d0477655
dangling tree ac135ee3b2031dcbed733af87c1b82833c1bd035
dangling tree 635a4c8728714746bc1a80692bd7b998af36c7fd
dangling tree 08708a50cd385efc23cfda7dd88cacf951db2237
dangling tree d27198a37d7b393ed9f5dc99c2f56e1c715c4572
dangling tree cc753417b1a3c1b61c0f1b37e7560be1f5404b93
dangling tree 237dcc5120bfe3aebcd2e19ab3640fbecb855ff2
dangling tree 32815626af9eb48dbe04fa790b154a9424871041
dangling tree 299294383dc096b0363ae3f7a49fe937a5e6027c
dangling tree 18acf23ea04f77d96c5eb092bbed0d598eb580ef
dangling tree 08c9e248624d407404e04481adf27d385c3a7e57
dangling tree beccf2344a596fed67cbe0f874210a98bd2b7c40
dangling tree d8df306d4dcf551d47f7d914bd7754c000e541f8
dangling tree 93e83c3ea3a1fef405546af4d99ecd1032ab9b09
dangling tree 65f9e4a9c3af938337fb7ec49eb354ebb19553f5
dangling tree 0a0c81ebe4e60b5941adf92494c45a9cc4ebbd85
dangling tree 5e1b8d853b32c4ee11cf4ef142be4d9a3096f679
dangling tree e11b176056fb40d5ef9cae77af37f53d7bf9342d
dangling tree 8a1e91d681554cafc74586c7ac3eb77299fbb091
dangling tree 10201bc2b2ceac311424bdbc3949a726926a6a3d
dangling tree fa21357016b62184d347f16f22fce54a0fc3aef5
dangling tree e33177806b80d35b0547a76e5fe26b59c55b5aa1
dangling tree cf3a11b7f1b83c86870881cb40f7c1af5b1daf9a
dangling tree e43d57bb730a492b73f6e6a8e5fd218d14e4b741
dangling tree 9f62ff527891032a5f0511f8f38cfe686b15ee5f
dangling tree 7476a37bdcedc8ecc568d73225a55b59899e70df
dangling tree 6085f588e0656a48e76f5e87dfb5ca03e7649bc4
dangling tree ea93955aa22995d17cc90f300343a535c8bdbf0c
dangling tree 1d95edfaf4d9065bf86cae97629fa28dd76e9fd3
dangling tree f29a99c8fee39c9934cca06a00e7ca5b48437ca0
dangling tree ff9bcf59a9392f7856a13c7541107165d8eb5659
dangling tree 3d9e29ac71b065829550996559094525e6f4ea4e
dangling tree cea7adf5352ce365f580066d1e2123e63b48f261
dangling tree 2fa8f7cd3a02839cf41ae7b01267047ffdbcfbe5
dangling tree 42ddc9e3585548880386d48dd7393d4111347ccd
dangling tree 83e30d38fb1e8ca59440f830f9bc203c615eff49
dangling tree 71e83d06ef0bb5bb105cf64bbb80bc6580bc06eb
dangling tree 7bedcf303aafcdedd6d0b3119bd8040d1fab3983
dangling tree 83f1a1eae41b9d6c7d2b6d549c35485a4e20847a
dangling tree eff8c7a202e29a8793b581b4c1b8d372a5289356
dangling tree 84f9bb0e7549269370c88a0878655fa4f5c09b27
dangling tree 4ffa81c9721df067d741fbd40227163d77ff7513

I'm starting to doubt this is a hard drive issue, I will be cloning
linux-next as-is exactly on my system on some other T61 (but a little
bigger and with Nvidia graphics) I have by git clone'ing over ssh to
my linux-next/.git/ and then I'll scp over my linux-next/.git/config
to it and try a git pull and see if that system also goes ape shit.

I am wondering if others have experiences issues like this as well.

Here's my kernel config for wireless-testing:

http://bombadil.infradead.org/~mcgrof/configs/2009/12/wireless-testing.config

And my config for 2.6.27:

http://bombadil.infradead.org/~mcgrof/configs/2009/12/2.6.27.41.config

Even if a git tree gets terribly messed up the issues I'm seeing seem
to painful for an average user to experience, there has got to be
something major going on under the hood, and not sure why I don't see
this sort of thing with following wireless-testing.

Luis
--
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 2 ==
Date: Fri, Dec 18 2009 9:40 am
From: Bartlomiej Zolnierkiewicz

On Friday 18 December 2009 06:26:29 pm Luis R. Rodriguez wrote:

> on my kernel logs. Bewildered with this issue I set out to prove to
> myself this issue was not a 2.6.32 issue and booted other kernels,
> including Ubuntu's distro kernel on 2.6.31 and then later my own built
> fresh 2.6.27.41 kernel. The issue was reproducible on all three
> kernels!
>
> This lead me to believe this was a system / hard drive issue and
> embraced myself for a system fix. I yet needed to prove this was

Just some hints for ruling out the system / hard drive problem.

smartctl -a /dev/sdx is your friend for checking your disk (keep an eye
on anything suspicious like re-allocated sector count going up etc.)

It could be also fs related issue that shows up only under specific
conditions (i.e. almost full partition -- some file-systems starts to
crawl when the amount of available free space gets low).

HTH
--
Bartlomiej Zolnierkiewicz
--
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: CPU probe/release files
http://groups.google.com/group/linux.kernel/t/a267f22b644611d2?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 18 2009 9:30 am
From: Andreas Schwab

Nathan Fontenot <nfont@austin.ibm.com> writes:

> Andreas Schwab wrote:
>> Nathan Fontenot <nfont@austin.ibm.com> writes:
>>
>>> Index: powerpc/arch/powerpc/Kconfig
>>> ===================================================================
>>> --- powerpc.orig/arch/powerpc/Kconfig 2009-10-28 15:21:47.000000000 -0500
>>> +++ powerpc/arch/powerpc/Kconfig 2009-10-28 15:21:53.000000000 -0500
>>> @@ -320,6 +320,10 @@
>>> Say N if you are unsure.
>>> +config ARCH_CPU_PROBE_RELEASE
>>> + def_bool y
>>> + depends on HOTPLUG_CPU
>>> +
>>
>> That does not work.
>>
>> drivers/built-in.o: In function `.store_online':
>> cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
>> cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> cpu_hotplug_driver_lock is only defined on pseries, but HOTPLUG_CPU is
>> also defined on pmac.
>
> These two routines should be defined as a no-op if CONFIG_ARCH_CPU_PROBE_RELEASE
> is not defined in linux/cpu.h.

??? CONFIG_ARCH_CPU_PROBE_RELEASE *is* defined.

Andreas.

--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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: iplink: add macvlan options for bridge mode
http://groups.google.com/group/linux.kernel/t/6dcbb596faaefd95?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Dec 18 2009 9:30 am
From: Stephen Hemminger

On Fri, 18 Dec 2009 14:45:07 +0100
Arnd Bergmann <arnd@arndb.de> wrote:

> Ping!
>
> Stephen, I submitted this twice but never heard back from you.
> The changes to macvlan have been merged in 2.6.33-rc1, so it
> would be good to have this included as well.
>
> Arnd
>

iproute gets updated (after patch is in upstream). I haven't started
on the 2.6.33 version yet.
--
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 2 ==
Date: Fri, Dec 18 2009 9:50 am
From: Arnd Bergmann

On Friday 18 December 2009, Stephen Hemminger wrote:
> On Fri, 18 Dec 2009 14:45:07 +0100
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > Ping!
> >
> > Stephen, I submitted this twice but never heard back from you.
> > The changes to macvlan have been merged in 2.6.33-rc1, so it
> > would be good to have this included as well.
> >
> > Arnd
> >
>
> iproute gets updated (after patch is in upstream). I haven't started
> on the 2.6.33 version yet.

Ok, thanks for the info. Tell me when/if I should resubmit.
I also have another (smaller) patch that also accepts the same
options for the macvtap driver, which is not upstream.
Should I also send that when the kernel code hits net-next,
2.6.34-rc1 or 2.6.34?

Arnd
--
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: Build error with 2.6.33-rc1
http://groups.google.com/group/linux.kernel/t/c9c996d28facd007?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Dec 18 2009 9:40 am
From: Tvrtko Ursulin

Hi,

There is first thiw warning about gawk, and then the failure. Not sure if they
are related. This build system has mawk installed (Ubuntu 8.10).

Error: Your awk doesn't support charactor-class.
Please try to use gawk.
CC arch/x86/lib/inat.o
arch/x86/lib/inat.c:24:25: error: inat-tables.c: No such file or directory
arch/x86/lib/inat.c: In function 'inat_get_opcode_attribute':
arch/x86/lib/inat.c:29: error: 'inat_primary_table' undeclared (first use in
this function)
arch/x86/lib/inat.c:29: error: (Each undeclared identifier is reported only
once
arch/x86/lib/inat.c:29: error: for each function it appears in.)
arch/x86/lib/inat.c: In function 'inat_get_escape_attribute':
arch/x86/lib/inat.c:44: error: 'inat_escape_tables' undeclared (first use in
this function)
arch/x86/lib/inat.c: In function 'inat_get_group_attribute':
arch/x86/lib/inat.c:67: error: 'inat_group_tables' undeclared (first use in
this function)
arch/x86/lib/inat.c: In function 'inat_get_avx_attribute':
arch/x86/lib/inat.c:85: error: 'inat_avx_tables' undeclared (first use in this
function)
make[1]: *** [arch/x86/lib/inat.o] Error 1
make: *** [arch/x86/lib] Error 2
--
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 2 ==
Date: Fri, Dec 18 2009 9:50 am
From: Masami Hiramatsu

Tvrtko Ursulin wrote:
>
> Hi,
>
> There is first thiw warning about gawk, and then the failure. Not sure if they
> are related. This build system has mawk installed (Ubuntu 8.10).

Thank you for reporting it.
We are currently trying to fix it for non-POSIX awks as like as mawk.

http://lkml.org/lkml/2009/12/16/458

Fixing patches are already in tip/x86/urgent tree.

Thank you again!

--
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

==============================================================================
TOPIC: x86: do_debug && PTRACE_SINGLESTEP broken by 08d68323d1f0c34452e614263b
212ca556dae47f
http://groups.google.com/group/linux.kernel/t/253956bb28f9a94f?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Dec 18 2009 9:40 am
From: Oleg Nesterov

On 12/18, Frederic Weisbecker wrote:
>
> On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
> > Hi.
> >
> > do_debug() is obviously wrong wrt PTRACE_SINGLESTEP/TIF_SINGLESTEP, no?
> >
> > Afaics this was broken by
> >
> > hw-breakpoints: modifying generic debug exception to use thread-specific debug registers
> > commit 08d68323d1f0c34452e614263b212ca556dae47f
> >
> > To verify, the "patch" below fixes the stepping for me, not sure what
> > is the proper fix...
> >
> > Oleg.
> >
> > --- arch/x86/kernel/traps.c~ 2009-12-18 00:20:49.000000000 +0100
> > +++ arch/x86/kernel/traps.c 2009-12-18 01:44:05.000000000 +0100
> > @@ -575,7 +575,7 @@ dotraplinkage void __kprobes do_debug(st
> > regs->flags &= ~X86_EFLAGS_TF;
> > }
> > si_code = get_si_code(tsk->thread.debugreg6);
> > - if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS))
> > +// if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS))
> > send_sigtrap(tsk, regs, error_code, si_code);
>
>
>
> But I don't understand why it is broken with the check.
> If we are in a singlestep exception, dr6 should have its
> DR_STEP bit set...
>
> Single stepping works well for me, after a quick check on
> gdb. How did you trigger the bug?

Please find the trivial test-case below. It hangs, because
PTRACE_SINGLESTEP doesn't trigger the trap.

(not sure this matters, but I did the testing under kvm)

Oleg.

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <assert.h>

int main(void)
{
int pid, status, i;

pid = fork();
if (!pid)
for (;;);

sleep(1);
assert(ptrace(PTRACE_ATTACH, pid, 0,0) == 0);

assert(pid == wait(&status));
assert(WIFSTOPPED(status));

for (i = 0; i < 10; ++i) {
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);

printf("wait %d ...\n", i);
assert(pid == wait(&status));

assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP);
}

kill(pid, SIGKILL);
return 0;
}

== 2 of 3 ==
Date: Fri, Dec 18 2009 9:40 am
From: "K.Prasad"

On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
> Hi.
>
> do_debug() is obviously wrong wrt PTRACE_SINGLESTEP/TIF_SINGLESTEP, no?
>
> Afaics this was broken by
>
> hw-breakpoints: modifying generic debug exception to use thread-specific debug registers
> commit 08d68323d1f0c34452e614263b212ca556dae47f
>
> To verify, the "patch" below fixes the stepping for me, not sure what
> is the proper fix...
>
> Oleg.
>
> --- arch/x86/kernel/traps.c~ 2009-12-18 00:20:49.000000000 +0100
> +++ arch/x86/kernel/traps.c 2009-12-18 01:44:05.000000000 +0100
> @@ -575,7 +575,7 @@ dotraplinkage void __kprobes do_debug(st
> regs->flags &= ~X86_EFLAGS_TF;
> }
> si_code = get_si_code(tsk->thread.debugreg6);
> - if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS))
> +// if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS))
> send_sigtrap(tsk, regs, error_code, si_code);
> preempt_conditional_cli(regs);
>

The cause for such a behaviour isn't apparent to me and like others, I'm
unable to recreate it (Single-stepping using gdb over a tiny program
running on x86, latest -tip works fine).

Did you try to narrow down the causative piece of code, among the
several hooks in do_debug()?

A separate 'dr6' and 'thread.debugreg6' was desired by the community (refer:
Pine.LNX.4.44L0.0904011216460.3736-100000@iolanthe.rowland.org and
Pine.LNX.4.44L0.0904091634150.4094-100000@iolanthe.rowland.org) then.
'dr6' and 'thread.deebugreg6' would contain the value of the DR6 status
register and every exception handler would reset the bits in them
corresponding to which action has been taken. The difference in them being
that 'thread.debugreg6' would be eventually processed by code interested
in user-space while 'dr6' was restricted to those hooks in do_debug().

Thanks,
K.Prasad

== 3 of 3 ==
Date: Fri, Dec 18 2009 10:00 am
From: "K.Prasad"

On Fri, Dec 18, 2009 at 06:27:47PM +0100, Oleg Nesterov wrote:
> On 12/18, Frederic Weisbecker wrote:
> >
> > On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
> > > Hi.

> > Single stepping works well for me, after a quick check on
> > gdb. How did you trigger the bug?
>
> Please find the trivial test-case below. It hangs, because
> PTRACE_SINGLESTEP doesn't trigger the trap.
>

aah...my other mail just criss-crossed yours.

I quickly ran on the said x86 box, loaded with -tip (commit
7818b3d0fc68f5c2a85fed86d9fa37131c5a3068) and it runs fine.

[root@llm05 prasadkr]# cat oleg.c
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <assert.h>

int main(void)
{
int pid, status, i;

pid = fork();
if (!pid)
for (;;);

sleep(1);
assert(ptrace(PTRACE_ATTACH, pid, 0,0) == 0);

assert(pid == wait(&status));
assert(WIFSTOPPED(status));

for (i = 0; i < 10; ++i) {
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);

printf("wait %d ...\n", i);
assert(pid == wait(&status));

assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP);
}

kill(pid, SIGKILL);
return 0;
}

[root@llm05 prasadkr]# gcc -o oleg oleg.c -g -Wall
[root@llm05 prasadkr]# ./oleg
wait 0 ...
wait 1 ...
wait 2 ...
wait 3 ...
wait 4 ...
wait 5 ...
wait 6 ...
wait 7 ...
wait 8 ...
wait 9 ...
[root@llm05 prasadkr]#

Am I missing something here?

Thanks,
K.Prasad

==============================================================================
TOPIC: x86: initialize stack canary in secondary start
http://groups.google.com/group/linux.kernel/t/2d346f902281bd0a?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 18 2009 9:40 am
From: "Pan, Jacob jun"

>-----Original Message-----
>From: Thomas Gleixner [mailto:tglx@linutronix.de]
>Sent: Friday, December 18, 2009 8:03 AM
>To: Pan, Jacob jun
>Cc: H. Peter Anvin; x86@kernel.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH 1/2] x86: initialize stack canary in secondary start
>
>On Thu, 17 Dec 2009, Pan, Jacob jun wrote:
>> >From 06503838368350268a46528e134c1dad9f4f8c93 Mon Sep 17 00:00:00 2001
>> From: Jacob Pan <jacob.jun.pan@intel.com>
>> Date: Thu, 17 Sep 2009 07:36:43 -0700
>> Subject: [PATCH 1/2] x86: initialize stack canary in secondary start
>>
>> some secondary clockevent setup code needs to call request_irq, which will
>> cause fake stack check failure in schedule() if voluntary preemption
>> model is chosen, it is safe to have stack canary initialized here early,
>> since start_secondary() does not return.
>
>Where is it initialized now ? Shouldnt the current init be removed ?
>
[[JPAN]] it is currently in cpu_idle(), i don't think it can be removed since
there are other path calling it. calling boot_init_stack_canary() is redundant
in some case but harmless.

>Thanks,
>
> tglx
>
>> Signed-off-by: Jacob Pan <jacob.jun.pan@intel.com>
>> ---
>> arch/x86/kernel/smpboot.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>> index 678d0b8..56ce974 100644
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -48,6 +48,7 @@
>> #include <linux/err.h>
>> #include <linux/nmi.h>
>> #include <linux/tboot.h>
>> +#include <linux/stackprotector.h>
>>
>> #include <asm/acpi.h>
>> #include <asm/desc.h>
>> @@ -324,6 +325,9 @@ notrace static void __cpuinit start_secondary(void
>*unused)
>> /* enable local interrupts */
>> local_irq_enable();
>>
>> + /* to prevent fake stack check failure in clock setup */
>> + boot_init_stack_canary();
>> +
>> x86_cpuinit.setup_percpu_clockev();
>>
>> wmb();
>> --
>> 1.6.5.3
>>
>>
--
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: scripts/checkpatch.pl: Change long line warning to 105 chars
http://groups.google.com/group/linux.kernel/t/735854ce62c52e1e?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Dec 18 2009 9:40 am
From: Joe Perches

On Fri, 2009-12-18 at 15:37 +0100, Krzysztof Halasa wrote:
> > Add 80 character long line STRICT test
> Not sure what do you mean.

CHK messages are only printed when --strict is on the command line

> This makes perfect sense, at least until shown otherwise (though being
> a warning instead of an error means it's ok to trigger in perfectly
> valid code).

It's a CHK, only printed with --strict.

== 2 of 3 ==
Date: Fri, Dec 18 2009 9:50 am
From: Linus Torvalds

On Fri, 18 Dec 2009, Paul Mundt wrote:

> On Thu, Dec 17, 2009 at 09:12:24PM -0800, Joe Perches wrote:
> > On Thu, 2009-12-17 at 23:29 -0500, Valdis.Kletnieks@vt.edu wrote:
> > > Yeah, but I respectfully submit that if the regexp '^\t{6}' matches a non-
> > > continuation line, it's probably in its rights to whinge.
> > > grep -r -P '^\t{7:}(?!(.*,$|.*\);$))' . | more
> > > produces a whole lot of "this can't end well" output.
> >
> > I think this is a good test to add to checkpatch.
> >
> > Add 105 character long line WARN test
> > Add 80 character long line STRICT test
> > Add 6+ leading indent tabs test, consider restructuring
> >
> This looks like a reasonable compromise.

I like this. Except I think the indent test should count spaces too some
way. Or do we already warn about excessive space that should be tabs?

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/

== 3 of 3 ==
Date: Fri, Dec 18 2009 10:00 am
From: Joe Perches

On Fri, 2009-12-18 at 09:43 -0800, Linus Torvalds wrote:
> I like this. Except I think the indent test should count spaces too some
> way. Or do we already warn about excessive space that should be tabs?

Andy's the checkpatch guy to verify this but:

There's a separate test for spaces that should be tabs.

If you had a 64 space indent and ran the silly script,
it'd complain about the spaces.

If you converted the spaces to tabs and ran the silly
script again with --strict, it'd complain about the
indent depth.

==============================================================================
TOPIC: Staging: vt665x depend on WIRELESS
http://groups.google.com/group/linux.kernel/t/346e4337e96055ec?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 18 2009 9:50 am
From: Randy Dunlap

On Fri, 18 Dec 2009 20:23:08 +0300 Alexander Beregalov wrote:

> Fix build error when NET or/and WIRELESS are not enabled.
>
> Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
> ---
> drivers/staging/vt6655/Kconfig | 2 +-
> drivers/staging/vt6656/Kconfig | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vt6655/Kconfig b/drivers/staging/vt6655/Kconfig
> index 825bbc4..6a186be 100644
> --- a/drivers/staging/vt6655/Kconfig
> +++ b/drivers/staging/vt6655/Kconfig
> @@ -1,6 +1,6 @@
> config VT6655
> tristate "VIA Technologies VT6655 support"
> - depends on PCI
> + depends on PCI && WIRELESS
> select WIRELESS_EXT
> select WEXT_PRIV
> ---help---
> diff --git a/drivers/staging/vt6656/Kconfig b/drivers/staging/vt6656/Kconfig
> index 87bcd26..6fceae4 100644
> --- a/drivers/staging/vt6656/Kconfig
> +++ b/drivers/staging/vt6656/Kconfig
> @@ -1,6 +1,6 @@
> config VT6656
> tristate "VIA Technologies VT6656 support"
> - depends on USB
> + depends on USB && WIRELESS
> select WIRELESS_EXT
> select WEXT_PRIV
> ---help---
> --

depends on WLAN

would be better, and the patch has already been submitted to Greg...
I don't know where it is in his "system" though.

---
~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/

==============================================================================
TOPIC: Performance regression in scsi sequential throughput (iozone) due to "e
084b - page-allocator: preserve PFN ordering when __GFP_COLD is set"
http://groups.google.com/group/linux.kernel/t/0f198fe3053e9f98?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 18 2009 9:50 am
From: Mel Gorman

On Fri, Dec 18, 2009 at 02:38:15PM +0100, Christian Ehrhardt wrote:
> Christian Ehrhardt wrote:
>> Mel Gorman wrote:
>> [...]
>>>>
>>>
>>> One way of finding out if cache hottness was the problem would be to
>>> profile
>>> for cache misses and see if there are massive differences with and
>>> without
>>> the patch. Is that an option?
>>>
>> It is an option to verify things, but as mentioned above I would
>> expect an increase amounts of consumed cycles per kb which I don't see.
>> I'll track caches anyway to be sure.
>>
>> My personal current assumption is that either there is some time lost
>> from the read syscall until the A event blocktrace tracks or I'm wrong
>> with my assumption about user processes and iozone runs "slower".
>>
>
> After I was able to verify that the time is lost above the block device
> layer I ran further tests to check out where the additional latency due
> to commit e084b occurs.
> With "strace -frT -e trace=open,close,read,write" I could isolate the
> continuous stream of read calls done by the iozone child process.
> In those data two things were revealed:
> a) The time is lost between read and Block device enter (not e.g. due to
> slow userspace execution or scheduling effects)
> Time spent in userspace until the next read call is almost the same,
> but the average time spent "inside" the read call increases from 788µs
> to 3278µs
> b) The time is lost in a few big peaks
> The majority of read calls are ~500-750µs in both cases, but there is
> a slight shift of approximately 8% that occur now as durations between
> 15000 and 60000µs
>
> As mentioned before there is no significant increase of spent cpu cycles
> - therefore I watched out how the read call could end up in sleeps
> (latency but not used cycles).
> I found that there is a chance to run into "congestion_wait" in case
> __alloc_pages_direct_reclaim() was able to free some pages with
> try_to_free_pages() but doesn't get a page in the subsequent
> get_page_from_freelist().

This is true although it was also the case before the patch.

> To get details about that I patched in some simple counters and
> ktime_get based timings. The results are impressive and point exactly
> towards the congestion_wait theory
>
> The following data is again taken with iozone 1 thread random read in a
> very low memory environment, the counters were zeroed before starting
> iozone
> Bad = the kernel just with commit e084b, good = kernel one commit before
> e084b. The throughput in good case while taking this data was
> approximately ~168% of that of the bad case.
>
> GOOD BAD
> perf_count_congestion_wait 245 1388
> perf_count_pages_direct_reclaim 10993 5365
> perf_count_failed_pages_direct_reclaim 0 1090
> Note - the data also shows that the average time spent in the
> f_op->aio_read call issued by do_sync_read increases by 68.5% which is
> directly inversely proportional to the average loss in throughput.
>
> This lets me conclude that patch e084b causes the system to run into
> congestion_wait after the semi-failed call to
> __alloc_pages_direct_reclaim.

You mention that the "GOOD" kernel is one commit before e084b but can
you test with just that patch reverted please? As the patch is only
about list manipulation, I'm failing to see how it can affect
congestion_wait().

> Unfortunately I don't understand memory management enough to find the
> relation between e084b actually changing the order and position of freed
> pages in the LRU list to __alloc_pages_direct_reclaim not getting pages
> as effectively as before.

Off-hand, neither can I. I regret that I'm going off-line for the
Christmas very soon and I'll be in the middle of nowhere with no
internet connection or test machines in the interim. It's going to be
the new year before I get to look at this properly.

Even if this patch is not the real problem, your instrumentation patches
will help pin down the real problem. Thanks and sorry I'll be delayed in
getting back to you properly.

> Ideas and comments welcome!
>
> Kind regards,
> Christian
>
> P.S: attached are the three patches I used to get those new numbers
>
>
> --
>
> Grüsse / regards, Christian Ehrhardt
> IBM Linux Technology Center, Linux Performance on System z
>

> Index: linux-2.6-git-2.6.31-bisect2/fs/read_write.c
> ===================================================================
> --- linux-2.6-git-2.6.31-bisect2.orig/fs/read_write.c
> +++ linux-2.6-git-2.6.31-bisect2/fs/read_write.c
> @@ -249,25 +249,37 @@ static void wait_on_retry_sync_kiocb(str
> __set_current_state(TASK_RUNNING);
> }
>
> +unsigned long perf_count_do_sync_read_calls_aio_read = 0;
> +unsigned long perf_tsum_do_sync_read_calls_aio_read = 0;
> +unsigned long perf_count_do_sync_read_calls_wait_on_sync_kiocb = 0;
> +unsigned long perf_tsum_do_sync_read_calls_wait_on_sync_kiocb = 0;
> ssize_t do_sync_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos)
> {
> struct iovec iov = { .iov_base = buf, .iov_len = len };
> struct kiocb kiocb;
> ssize_t ret;
> + ktime_t tv64_pre;
>
> init_sync_kiocb(&kiocb, filp);
> kiocb.ki_pos = *ppos;
> kiocb.ki_left = len;
>
> for (;;) {
> + perf_count_do_sync_read_calls_aio_read++;
> + tv64_pre = ktime_get();
> ret = filp->f_op->aio_read(&kiocb, &iov, 1, kiocb.ki_pos);
> + perf_tsum_do_sync_read_calls_aio_read += ktime_sub(ktime_get(),tv64_pre).tv64;
> if (ret != -EIOCBRETRY)
> break;
> wait_on_retry_sync_kiocb(&kiocb);
> }
>
> - if (-EIOCBQUEUED == ret)
> + if (-EIOCBQUEUED == ret) {
> + perf_count_do_sync_read_calls_wait_on_sync_kiocb++;
> + tv64_pre = ktime_get();
> ret = wait_on_sync_kiocb(&kiocb);
> + perf_tsum_do_sync_read_calls_wait_on_sync_kiocb += ktime_sub(ktime_get(),tv64_pre).tv64;
> + }
> *ppos = kiocb.ki_pos;
> return ret;
> }
> Index: linux-2.6-git-2.6.31-bisect2/kernel/sysctl.c
> ===================================================================
> --- linux-2.6-git-2.6.31-bisect2.orig/kernel/sysctl.c
> +++ linux-2.6-git-2.6.31-bisect2/kernel/sysctl.c
> @@ -257,6 +257,10 @@ extern unsigned long perf_count_pages_di
> extern unsigned long perf_count_failed_pages_direct_reclaim;
> extern unsigned long perf_count_do_generic_file_read_calls_page_cache_alloc_cold;
> extern unsigned long perf_tsum_do_generic_file_read_calls_page_cache_alloc_cold;
> +extern unsigned long perf_count_do_sync_read_calls_aio_read;
> +extern unsigned long perf_tsum_do_sync_read_calls_aio_read;
> +extern unsigned long perf_count_do_sync_read_calls_wait_on_sync_kiocb;
> +extern unsigned long perf_tsum_do_sync_read_calls_wait_on_sync_kiocb;
> static struct ctl_table perf_table[] = {
> {
> .ctl_name = CTL_UNNUMBERED,
> @@ -297,6 +301,38 @@ static struct ctl_table perf_table[] = {
> .maxlen = sizeof(unsigned long),
> .mode = 0666,
> .proc_handler = &proc_doulongvec_minmax,
> + },
> + {
> + .ctl_name = CTL_UNNUMBERED,
> + .procname = "perf_count_do_sync_read_calls_aio_read",
> + .data = &perf_count_do_sync_read_calls_aio_read,
> + .maxlen = sizeof(unsigned long),
> + .mode = 0666,
> + .proc_handler = &proc_doulongvec_minmax,
> + },
> + {
> + .ctl_name = CTL_UNNUMBERED,
> + .procname = "perf_tsum_do_sync_read_calls_aio_read",
> + .data = &perf_tsum_do_sync_read_calls_aio_read,
> + .maxlen = sizeof(unsigned long),
> + .mode = 0666,
> + .proc_handler = &proc_doulongvec_minmax,
> + },
> + {
> + .ctl_name = CTL_UNNUMBERED,
> + .procname = "perf_count_do_sync_read_calls_wait_on_sync_kiocb",
> + .data = &perf_count_do_sync_read_calls_wait_on_sync_kiocb,
> + .maxlen = sizeof(unsigned long),
> + .mode = 0666,
> + .proc_handler = &proc_doulongvec_minmax,
> + },
> + {
> + .ctl_name = CTL_UNNUMBERED,
> + .procname = "perf_tsum_do_sync_read_calls_wait_on_sync_kiocb",
> + .data = &perf_tsum_do_sync_read_calls_wait_on_sync_kiocb,
> + .maxlen = sizeof(unsigned long),
> + .mode = 0666,
> + .proc_handler = &proc_doulongvec_minmax,
> },
> { .ctl_name = 0 }
> };

> Index: linux-2.6-git-2.6.31-bisect2/include/linux/sysctl.h
> ===================================================================
> --- linux-2.6-git-2.6.31-bisect2.orig/include/linux/sysctl.h
> +++ linux-2.6-git-2.6.31-bisect2/include/linux/sysctl.h
> @@ -69,6 +69,7 @@ enum
> CTL_BUS=8, /* Busses */
> CTL_ABI=9, /* Binary emulation */
> CTL_CPU=10, /* CPU stuff (speed scaling, etc) */
> + CTL_PERF=11, /* Performance counters and timer sums for debugging */
> CTL_ARLAN=254, /* arlan wireless driver */
> CTL_S390DBF=5677, /* s390 debug */
> CTL_SUNRPC=7249, /* sunrpc debug */
> Index: linux-2.6-git-2.6.31-bisect2/kernel/sysctl.c
> ===================================================================
> --- linux-2.6-git-2.6.31-bisect2.orig/kernel/sysctl.c
> +++ linux-2.6-git-2.6.31-bisect2/kernel/sysctl.c
> @@ -177,6 +177,7 @@ static struct ctl_table_root sysctl_tabl
> .default_set.list = LIST_HEAD_INIT(root_table_header.ctl_entry),
> };
>
> +static struct ctl_table perf_table[];
> static struct ctl_table kern_table[];
> static struct ctl_table vm_table[];
> static struct ctl_table fs_table[];
> @@ -230,6 +231,13 @@ static struct ctl_table root_table[] = {
> .mode = 0555,
> .child = dev_table,
> },
> + {
> + .ctl_name = CTL_PERF,
> + .procname = "perf",
> + .mode = 0555,
> + .child = perf_table,
> + },
> +
> /*
> * NOTE: do not add new entries to this table unless you have read
> * Documentation/sysctl/ctl_unnumbered.txt
> @@ -244,6 +252,19 @@ static int min_wakeup_granularity_ns;
> static int max_wakeup_granularity_ns = NSEC_PER_SEC; /* 1 second */
>

twitter

Friday, December 18, 2009

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

0 Comments:

Post a Comment

About Me

Previous Posts