I said I was hoping that -rc8 was the last -rc, and I hate doing this, but
we've had more changes since -rc8 than we had in -rc8. And while most of
them are pretty trivial, I really couldn't face doing a 2.6.23 release and
take the risk of some really stupid brown-paper-bag thing.
So there's a final -rc out there, and right now my plan is to make this
series really short, and release 2.6.23 in a few days. So please do give
it a last good testing, and holler about any issues you find!
This is also a good time to warn about the fact that we're doing the x86
merge very soon (as in the next day or two) after 2.6.23 is out, so if you
have pending patches for the next series that touch arch/i386 or x86-64,
you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
keepers of the merge scripts, and will help you prepare..
Doing it as early as possible in the 2.6.24-rc4 series (basically I'll do
it first thing) will mean that we'll have the maximum amount of time to
sort out any issues, and the thing is, Thomas and Ingo already have a tree
ready to go, so people can check their work against that, and don't need
to think that they have to do any fixups after it his *my* tree. It would
be much better if everybody was just ready for it, and not taken by
surprise.
In other words, people who know they may be affected and would want to
prepare can look at (for example)
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
and generally get ready for the switch-over.
Linus
On Mon, 1 Oct 2007, Linus Torvalds wrote:
> This is also a good time to warn about the fact that we're doing the x86
> merge very soon (as in the next day or two) after 2.6.23 is out, so if you
> have pending patches for the next series that touch arch/i386 or x86-64,
> you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
> keepers of the merge scripts, and will help you prepare..
>
> Doing it as early as possible in the 2.6.24-rc4 series (basically I'll do
> it first thing) will mean that we'll have the maximum amount of time to
> sort out any issues, and the thing is, Thomas and Ingo already have a tree
> ready to go, so people can check their work against that, and don't need
> to think that they have to do any fixups after it his *my* tree. It would
> be much better if everybody was just ready for it, and not taken by
> surprise.
>
> In other words, people who know they may be affected and would want to
> prepare can look at (for example)
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
>
> and generally get ready for the switch-over.
I have uploaded an update of the arch/x86 tree based on -rc9 to
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
For convenience there is a patch fixup script which helps you to
convert pending patches against this tree.
http://userweb.kernel.org/~tglx/x86/x86-fixup-patches.py
It's generated from the merge script and fixes the namespace of
patches. There will still be some rejects which can not be fixed up
automatically, but this should be rare.
I did a test with Andrews -mm series and only ~10 arch/x86 related
patches had rejects, out of 230+ patches, so the 100%-painless
conversion ratio is better than 95%. Those patches with rejects were
trivial to fix.
Usage: x86-fixup-patches.py sourcepatch destpatch
source and dest can be the same.
A helper script to convert complete quilt series is here:
http://userweb.kernel.org/~tglx/x86/fixupseries.sh
If there is anything we can help with the transition, please do not
hesitate to ask.
Thanks,
Thomas, Ingo
On Tuesday 02 October 2007 11:17:02 Thomas Gleixner wrote:
> > This is also a good time to warn about the fact that we're doing the x86
> > merge very soon (as in the next day or two) after 2.6.23 is out, so if you
> > have pending patches for the next series that touch arch/i386 or x86-64,
> > you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
> > keepers of the merge scripts, and will help you prepare..
Yes I have ~100 patches for arch/x86_64, arch/i386
Should I just drop them?
-Andi
Andi Kleen wrote:
> On Tuesday 02 October 2007 11:17:02 Thomas Gleixner wrote:
>>> This is also a good time to warn about the fact that we're doing the x86
>>> merge very soon (as in the next day or two) after 2.6.23 is out, so if you
>>> have pending patches for the next series that touch arch/i386 or x86-64,
>>> you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
>>> keepers of the merge scripts, and will help you prepare..
>
>
> Yes I have ~100 patches for arch/x86_64, arch/i386
>
> Should I just drop them?
Why don't you work with Thomas and Ingo to make sure everything is in
sync and prepped for 2.6.24?
Jeff
On Tuesday 02 October 2007 12:37:55 Jeff Garzik wrote:
> Andi Kleen wrote:
> > On Tuesday 02 October 2007 11:17:02 Thomas Gleixner wrote:
> >>> This is also a good time to warn about the fact that we're doing the x86
> >>> merge very soon (as in the next day or two) after 2.6.23 is out, so if you
> >>> have pending patches for the next series that touch arch/i386 or x86-64,
> >>> you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
> >>> keepers of the merge scripts, and will help you prepare..
> >
> >
> > Yes I have ~100 patches for arch/x86_64, arch/i386
> >
> > Should I just drop them?
>
> Why don't you work with Thomas and Ingo to make sure everything is in
> sync and prepped for 2.6.24?
The easiest way to do that would be to first merge all the queued and
collected patches from the last months. Once they are in people
can then create whatever mess they like.
The other way round (adapting 100+ patches to a possibly completely
different tree) will be a huge amount of work which I am
frankly not very motivated to do because I think it's quite unnecessary.
I would probably just push the work back to all the patch submitters -- that is
what I meant with dropping the patches.
I assume mess up first would be also a minor catastrophe for Andrew --
in addition to my patches he also has a large number of patches
touching {x86_64,i386}
-Andi
On Tue, 2 Oct 2007, Andi Kleen wrote:
> On Tuesday 02 October 2007 12:37:55 Jeff Garzik wrote:
> > Andi Kleen wrote:
> > > On Tuesday 02 October 2007 11:17:02 Thomas Gleixner wrote:
> > >>> This is also a good time to warn about the fact that we're doing the x86
> > >>> merge very soon (as in the next day or two) after 2.6.23 is out, so if you
> > >>> have pending patches for the next series that touch arch/i386 or x86-64,
> > >>> you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
> > >>> keepers of the merge scripts, and will help you prepare..
> > >
> > >
> > > Yes I have ~100 patches for arch/x86_64, arch/i386
> > >
> > > Should I just drop them?
> >
> > Why don't you work with Thomas and Ingo to make sure everything is in
> > sync and prepped for 2.6.24?
>
> The easiest way to do that would be to first merge all the queued and
> collected patches from the last months. Once they are in people
> can then create whatever mess they like.
>
> The other way round (adapting 100+ patches to a possibly completely
> different tree) will be a huge amount of work which I am
> frankly not very motivated to do because I think it's quite unnecessary.
>
> I would probably just push the work back to all the patch submitters -- that is
> what I meant with dropping the patches.
I picked up your queue at
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt-current/current.tar.gz
and converted it with the fixup script to:
http://www.tglx.de/~tglx/patches-ak.tar.bz2
Hope that helps,
tglx
On Mon, 2007-10-01 at 20:41 -0700, Linus Torvalds wrote:
> I said I was hoping that -rc8 was the last -rc, and I hate doing this, but
> we've had more changes since -rc8 than we had in -rc8. And while most of
> them are pretty trivial, I really couldn't face doing a 2.6.23 release and
> take the risk of some really stupid brown-paper-bag thing.
>
Dirt. Booting with "profile=sleep,2" is broken in 2.6.23-rc9 and
2.6.23-rc8 but working in 2.6.22. I was checking it out as part of a
discussion in another thread and noticed it broken in -mm as well
(2.6.23-rc8-mm2). Bisect is in progress but suggestions as to the prime
candidates are welcome or preferably, pointing out that I'm an idiot
because I missed twiddling some config change.
2.6.22 output
gringo:~# readprofile | sort -rn
69604 total 0.0309
27287 m_start 243.6339
16430 sync_page 205.3750
13161 sync_buffer 205.6406
4035 sys_init_module 0.6121
2842 msleep 88.8125
2573 call_usermodehelper_keys 10.7208
1554 ps2_sendbyte 6.0703
803 log_wait_commit 2.7882
378 do_lookup 0.9844
160 do_get_write_access 0.1111
89 synchronize_rcu 1.3906
76 ps2_command 0.0792
66 ide_do_drive_cmd 0.2292
59 do_fork 0.1085
54 congestion_wait 0.3750
29 __rtnl_unlock 1.8125
4 kthread 0.0357
2 *unknown*
2 journal_stop 0.0038
1 kthreadd 0.0035
1 kthread_create 0.0063
latest git output
gringo:~# readprofile
0 *unknown*
0 total 0.0000
I checked the obvious stuff like DEBUG options being set,
CONFIG_PROFILING being set etc.
> So there's a final -rc out there, and right now my plan is to make this
> series really short, and release 2.6.23 in a few days. So please do give
> it a last good testing, and holler about any issues you find!
>
> This is also a good time to warn about the fact that we're doing the x86
> merge very soon (as in the next day or two) after 2.6.23 is out, so if you
> have pending patches for the next series that touch arch/i386 or x86-64,
> you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
> keepers of the merge scripts, and will help you prepare..
>
> Doing it as early as possible in the 2.6.24-rc4 series (basically I'll do
> it first thing) will mean that we'll have the maximum amount of time to
> sort out any issues, and the thing is, Thomas and Ingo already have a tree
> ready to go, so people can check their work against that, and don't need
> to think that they have to do any fixups after it his *my* tree. It would
> be much better if everybody was just ready for it, and not taken by
> surprise.
>
> In other words, people who know they may be affected and would want to
> prepare can look at (for example)
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
>
> and generally get ready for the switch-over.
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, 2 Oct 2007, Andi Kleen wrote:
> Yes I have ~100 patches for arch/x86_64, arch/i386 Should I just drop
> them?
I asuume that Andrew is periodically pulling your queue into -mm, isn't
he? If so, Thomas explicitly stated that -mm can be converted easily with
just a few rejects, right?
--
Jiri Kosina
* Mel Gorman <[email protected]> wrote:
> Dirt. Booting with "profile=sleep,2" is broken in 2.6.23-rc9 and
> 2.6.23-rc8 but working in 2.6.22. I was checking it out as part of a
> discussion in another thread and noticed it broken in -mm as well
> (2.6.23-rc8-mm2). Bisect is in progress but suggestions as to the
> prime candidates are welcome or preferably, pointing out that I'm an
> idiot because I missed twiddling some config change.
Mel, does the patch below fix this bug for you? (Note: you will need to
enable CONFIG_SCHEDSTATS=y too.)
if yes, then Linus please pull this single fix from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
| Ingo Molnar (1):
| sched: fix profile=sleep
|
| sched_fair.c | 10 ++++++++++
| 1 file changed, 10 insertions(+)
risk is low: the new code only runs with CONFIG_SCHEDSTATS=y
(default:off) and profile=sleep (default:off), so it ought to be fairly
safe to add at this point. (and we had very similar code in v2.6.22
anyway)
Ingo
------------------------->
Subject: sched: fix profile=sleep
From: Ingo Molnar <[email protected]>
fix sleep profiling - we lost this chunk in the CFS merge.
Found-by: Mel Gorman <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
kernel/sched_fair.c | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: linux/kernel/sched_fair.c
===================================================================
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -639,6 +639,16 @@ static void enqueue_sleeper(struct cfs_r
se->block_start = 0;
se->sum_sleep_runtime += delta;
+
+ /*
+ * Blocking time is in units of nanosecs, so shift by 20 to
+ * get a milliseconds-range estimation of the amount of
+ * time that the task spent sleeping:
+ */
+ if (unlikely(prof_on == SLEEP_PROFILING)) {
+ profile_hits(SLEEP_PROFILING, (void *)get_wchan(tsk),
+ delta >> 20);
+ }
}
#endif
}
* Thomas Gleixner <[email protected]> wrote:
> On Tue, 2 Oct 2007, Andi Kleen wrote:
> > On Tuesday 02 October 2007 12:37:55 Jeff Garzik wrote:
> > > Andi Kleen wrote:
> > > > On Tuesday 02 October 2007 11:17:02 Thomas Gleixner wrote:
> > > >>> This is also a good time to warn about the fact that we're doing the x86
> > > >>> merge very soon (as in the next day or two) after 2.6.23 is out, so if you
> > > >>> have pending patches for the next series that touch arch/i386 or x86-64,
> > > >>> you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
> > > >>> keepers of the merge scripts, and will help you prepare..
> > > >
> > > >
> > > > Yes I have ~100 patches for arch/x86_64, arch/i386
> > > >
> > > > Should I just drop them?
> > >
> > > Why don't you work with Thomas and Ingo to make sure everything is in
> > > sync and prepped for 2.6.24?
> >
> > The easiest way to do that would be to first merge all the queued
> > and collected patches from the last months. Once they are in people
> > can then create whatever mess they like.
> >
> > The other way round (adapting 100+ patches to a possibly completely
> > different tree) will be a huge amount of work which I am frankly not
> > very motivated to do because I think it's quite unnecessary.
> >
> > I would probably just push the work back to all the patch submitters
> > -- that is what I meant with dropping the patches.
>
> I picked up your queue at
>
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt-current/current.tar.gz
>
> and converted it with the fixup script to:
>
> http://www.tglx.de/~tglx/patches-ak.tar.bz2
>
> Hope that helps,
thanks Thomas - i have applied this queue ontop of the unified arch/x86
tree (i skipped vdso-text-offset which change is already upstream) and
it built and booted fine on a couple of x86 systems - 32-bit and 64-bit
alike. So your script worked like a charm.
Andi, could you please send us the list of patches from the
current.tar.gz queue above that you consider 2.6.24 candidates? (and
please add to the list if there's anything else pending) Thanks,
Ingo
> Andi, could you please send us the list of patches from the
> current.tar.gz queue above that you consider 2.6.24 candidates?
Everything in principle except the patches marked with TBD.
> (and
> please add to the list if there's anything else pending)
I'm still merging/fixing etc. so the list is not final yet.
-Andi
* Andi Kleen <[email protected]> wrote:
> > Andi, could you please send us the list of patches from the
> > current.tar.gz queue above that you consider 2.6.24 candidates?
>
> Everything in principle except the patches marked with TBD.
ok, the ones marked TBD are:
cflags-probe
cpa-clflush
sched-clock-share
svm-disabled
unwinder
> > (and please add to the list if there's anything else pending)
>
> I'm still merging/fixing etc. so the list is not final yet.
please merge it ontop of the arch/x86 tree so that we can start
reviewing and testing it based on the unified tree ASAP. (but sending us
a queue to the old layout is fine too - whichever variant you can do
fastest) Thanks,
Ingo
Linus> I said I was hoping that -rc8 was the last -rc, and I hate
Linus> doing this, but we've had more changes since -rc8 than we had
Linus> in -rc8. And while most of them are pretty trivial, I really
Linus> couldn't face doing a 2.6.23 release and take the risk of some
Linus> really stupid brown-paper-bag thing.
Linus> So there's a final -rc out there, and right now my plan is to
Linus> make this series really short, and release 2.6.23 in a few
Linus> days. So please do give it a last good testing, and holler
Linus> about any issues you find!
Just to let people know, I was running 2.6.23-rc for over 53 days
without any issues. Mix of SCSI, Sata, tape drives, disks, MD, LVM,
SMP, etc. I suspect we've got a pretty darn stable release coming out
soon.
John
> please merge it ontop of the arch/x86 tree so that we can start
> reviewing and testing it based on the unified tree ASAP. (but sending us
> a queue to the old layout is fine too - whichever variant you can do
> fastest)
It will be uploaded to the usual location.
-Andi
On Tue, Oct 02, 2007 at 04:31:15PM +0200, Ingo Molnar wrote:
>
> * Andi Kleen <[email protected]> wrote:
>
> > > Andi, could you please send us the list of patches from the
> > > current.tar.gz queue above that you consider 2.6.24 candidates?
> >
> > Everything in principle except the patches marked with TBD.
>
> ok, the ones marked TBD are:
>
> cflags-probe
> cpa-clflush
> sched-clock-share
> svm-disabled
> unwinder
>
> > > (and please add to the list if there's anything else pending)
> >
> > I'm still merging/fixing etc. so the list is not final yet.
>
> please merge it ontop of the arch/x86 tree so that we can start
> reviewing and testing it based on the unified tree ASAP. (but sending us
> a queue to the old layout is fine too - whichever variant you can do
> fastest) Thanks,
Hi Andi/Ingo.
I plan to integrate cflags-probe in kbuild.git if there is no objection.
And I will address any x86 issues when I do so.
On top of that I will most likely do the same change for i386.
Sam
* John Stoffel <[email protected]> wrote:
>
> Linus> I said I was hoping that -rc8 was the last -rc, and I hate
> Linus> doing this, but we've had more changes since -rc8 than we had
> Linus> in -rc8. And while most of them are pretty trivial, I really
> Linus> couldn't face doing a 2.6.23 release and take the risk of some
> Linus> really stupid brown-paper-bag thing.
>
> Linus> So there's a final -rc out there, and right now my plan is to
> Linus> make this series really short, and release 2.6.23 in a few
> Linus> days. So please do give it a last good testing, and holler
> Linus> about any issues you find!
>
> Just to let people know, I was running 2.6.23-rc for over 53 days
> without any issues. Mix of SCSI, Sata, tape drives, disks, MD, LVM,
> SMP, etc. I suspect we've got a pretty darn stable release coming out
> soon.
that's pretty impressive! v2.6.23-rc2, right?
Ingo
>
> I plan to integrate cflags-probe in kbuild.git if there is no objection.
Fine for me. Please take what you want.
-Andi
* Sam Ravnborg <[email protected]> wrote:
> On Tue, Oct 02, 2007 at 04:31:15PM +0200, Ingo Molnar wrote:
> >
> > * Andi Kleen <[email protected]> wrote:
> >
> > > > Andi, could you please send us the list of patches from the
> > > > current.tar.gz queue above that you consider 2.6.24 candidates?
> > >
> > > Everything in principle except the patches marked with TBD.
> >
> > ok, the ones marked TBD are:
> >
> > cflags-probe
> > cpa-clflush
> > sched-clock-share
> > svm-disabled
> > unwinder
> >
> > > > (and please add to the list if there's anything else pending)
> > >
> > > I'm still merging/fixing etc. so the list is not final yet.
> >
> > please merge it ontop of the arch/x86 tree so that we can start
> > reviewing and testing it based on the unified tree ASAP. (but sending us
> > a queue to the old layout is fine too - whichever variant you can do
> > fastest) Thanks,
>
> Hi Andi/Ingo.
>
> I plan to integrate cflags-probe in kbuild.git if there is no
> objection. And I will address any x86 issues when I do so. On top of
> that I will most likely do the same change for i386.
great. I think that's the most straightforward merge path for such
Makefile updates. Andi, Thomas, any objections?
Ingo
Sam,
On Tue, 2 Oct 2007, Sam Ravnborg wrote:
> Hi Andi/Ingo.
>
> I plan to integrate cflags-probe in kbuild.git if there is no objection.
> And I will address any x86 issues when I do so.
> On top of that I will most likely do the same change for i386.
Makes sense. While you are at it, can you please have an eye on the
Build system changes I did to make arch/x86 with the two stub
directories arch/i386 and arch/x86_64 work.
Thanks,
tglx
On Tue, Oct 02, 2007 at 05:30:27PM +0200, Thomas Gleixner wrote:
> Sam,
>
> On Tue, 2 Oct 2007, Sam Ravnborg wrote:
> > Hi Andi/Ingo.
> >
> > I plan to integrate cflags-probe in kbuild.git if there is no objection.
> > And I will address any x86 issues when I do so.
> > On top of that I will most likely do the same change for i386.
By the way - that patch depends on a few other patches in Andi's queue
but I will await until they are included.
>
> Makes sense. While you are at it, can you please have an eye on the
> Build system changes I did to make arch/x86 with the two stub
> directories arch/i386 and arch/x86_64 work.
Thats on my TODO list - but I do not think I will find time before the merge.
Sam
Linus> I said I was hoping that -rc8 was the last -rc, and I hate
Linus> doing this, but we've had more changes since -rc8 than we had
Linus> in -rc8. And while most of them are pretty trivial, I really
Linus> couldn't face doing a 2.6.23 release and take the risk of some
Linus> really stupid brown-paper-bag thing.
Linus> So there's a final -rc out there, and right now my plan is to
Linus> make this series really short, and release 2.6.23 in a few
Linus> days. So please do give it a last good testing, and holler
Linus> about any issues you find!
John> Just to let people know, I was running 2.6.23-rc for over 53
John> days without any issues. Mix of SCSI, Sata, tape drives, disks,
John> MD, LVM, SMP, etc. I suspect we've got a pretty darn stable
John> release coming out soon.
2.6.23-rc2 is what I meant. Oops...
On (02/10/07 14:15), Ingo Molnar didst pronounce:
>
> * Mel Gorman <[email protected]> wrote:
>
> > Dirt. Booting with "profile=sleep,2" is broken in 2.6.23-rc9 and
> > 2.6.23-rc8 but working in 2.6.22. I was checking it out as part of a
> > discussion in another thread and noticed it broken in -mm as well
> > (2.6.23-rc8-mm2). Bisect is in progress but suggestions as to the
> > prime candidates are welcome or preferably, pointing out that I'm an
> > idiot because I missed twiddling some config change.
>
> Mel, does the patch below fix this bug for you? (Note: you will need to
> enable CONFIG_SCHEDSTATS=y too.)
>
Nice one Ingo - got it first try. The problem commit was
dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the code removed
in this commit is put back by this latest patch. When applied, profile=sleep
works as long as CONFIG_SCHEDSTAT is set.
Thanks.
> if yes, then Linus please pull this single fix from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
>
> | Ingo Molnar (1):
> | sched: fix profile=sleep
> |
> | sched_fair.c | 10 ++++++++++
> | 1 file changed, 10 insertions(+)
>
> risk is low: the new code only runs with CONFIG_SCHEDSTATS=y
> (default:off) and profile=sleep (default:off), so it ought to be fairly
> safe to add at this point. (and we had very similar code in v2.6.22
> anyway)
>
> Ingo
>
> ------------------------->
> Subject: sched: fix profile=sleep
> From: Ingo Molnar <[email protected]>
>
> fix sleep profiling - we lost this chunk in the CFS merge.
>
> Found-by: Mel Gorman <[email protected]>
> Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Mel Gorman <[email protected]>
That said, I am not super-keen on this only working when SCHEDSTAT is set
without telling the user about it. It's not urgent enough to pick up as a
late-late fix but prehaps something like this?
=============
profile=sleep only works if CONFIG_SCHEDSTATS is set. This patch notes the
limitation in Documentation/kernel-parameters.txt and prints a warning at
boot-time if profile=sleep is used without CONFIG_SCHEDSTAT.
Signed-off-by: Mel Gorman <[email protected]>
---
Documentation/kernel-parameters.txt | 3 ++-
kernel/profile.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc9-005_ingo_profile_fix/Documentation/kernel-parameters.txt linux-2.6.23-rc9-010_document_profilesleep/Documentation/kernel-parameters.txt
--- linux-2.6.23-rc9-005_ingo_profile_fix/Documentation/kernel-parameters.txt 2007-10-02 04:24:52.000000000 +0100
+++ linux-2.6.23-rc9-010_document_profilesleep/Documentation/kernel-parameters.txt 2007-10-02 16:43:41.000000000 +0100
@@ -1395,7 +1395,8 @@ and is between 256 and 4096 characters.
Param: "schedule" - profile schedule points.
Param: <number> - step/bucket size as a power of 2 for
statistical time based profiling.
- Param: "sleep" - profile D-state sleeping (millisecs)
+ Param: "sleep" - profile D-state sleeping (millisecs).
+ Requires CONFIG_SCHEDSTATS to work
processor.max_cstate= [HW,ACPI]
Limit processor to maximum C-state
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc9-005_ingo_profile_fix/kernel/profile.c linux-2.6.23-rc9-010_document_profilesleep/kernel/profile.c
--- linux-2.6.23-rc9-005_ingo_profile_fix/kernel/profile.c 2007-10-02 04:24:52.000000000 +0100
+++ linux-2.6.23-rc9-010_document_profilesleep/kernel/profile.c 2007-10-02 16:44:50.000000000 +0100
@@ -60,6 +60,7 @@ static int __init profile_setup(char * s
int par;
if (!strncmp(str, sleepstr, strlen(sleepstr))) {
+#ifdef CONFIG_SCHEDSTATS
prof_on = SLEEP_PROFILING;
if (str[strlen(sleepstr)] == ',')
str += strlen(sleepstr) + 1;
@@ -68,6 +69,10 @@ static int __init profile_setup(char * s
printk(KERN_INFO
"kernel sleep profiling enabled (shift: %ld)\n",
prof_shift);
+#else
+ printk(KERN_WARNING
+ "kernel sleep profiling requires CONFIG_SCHEDSTATS\n");
+#endif /* CONFIG_SCHEDSTATS */
} else if (!strncmp(str, schedstr, strlen(schedstr))) {
prof_on = SCHED_PROFILING;
if (str[strlen(schedstr)] == ',')
On Tuesday, 2 October 2007 11:17, Thomas Gleixner wrote:
> On Mon, 1 Oct 2007, Linus Torvalds wrote:
> > This is also a good time to warn about the fact that we're doing the x86
> > merge very soon (as in the next day or two) after 2.6.23 is out, so if you
> > have pending patches for the next series that touch arch/i386 or x86-64,
> > you should get in touch with Thomas Gleixner and Ingo Molnar, who are the
> > keepers of the merge scripts, and will help you prepare..
> >
> > Doing it as early as possible in the 2.6.24-rc4 series (basically I'll do
> > it first thing) will mean that we'll have the maximum amount of time to
> > sort out any issues, and the thing is, Thomas and Ingo already have a tree
> > ready to go, so people can check their work against that, and don't need
> > to think that they have to do any fixups after it his *my* tree. It would
> > be much better if everybody was just ready for it, and not taken by
> > surprise.
> >
> > In other words, people who know they may be affected and would want to
> > prepare can look at (for example)
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
> >
> > and generally get ready for the switch-over.
>
> I have uploaded an update of the arch/x86 tree based on -rc9 to
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
>
> For convenience there is a patch fixup script which helps you to
> convert pending patches against this tree.
>
> http://userweb.kernel.org/~tglx/x86/x86-fixup-patches.py
>
> It's generated from the merge script and fixes the namespace of
> patches. There will still be some rejects which can not be fixed up
> automatically, but this should be rare.
>
> I did a test with Andrews -mm series and only ~10 arch/x86 related
> patches had rejects, out of 230+ patches, so the 100%-painless
> conversion ratio is better than 95%. Those patches with rejects were
> trivial to fix.
>
> Usage: x86-fixup-patches.py sourcepatch destpatch
>
> source and dest can be the same.
>
> A helper script to convert complete quilt series is here:
> http://userweb.kernel.org/~tglx/x86/fixupseries.sh
>
> If there is anything we can help with the transition, please do not
> hesitate to ask.
Well, there are several arch-dependent power management patches in -mm queued
up for merging. Do I need to take care of converting them myself, or will that
be done automatically, or ...?
Greetings,
Rafael
On Tue, 2 Oct 2007 22:12:13 +0200
"Rafael J. Wysocki" <[email protected]> wrote:
> > Usage: x86-fixup-patches.py sourcepatch destpatch
> >
> > source and dest can be the same.
> >
> > A helper script to convert complete quilt series is here:
> > http://userweb.kernel.org/~tglx/x86/fixupseries.sh
> >
> > If there is anything we can help with the transition, please do not
> > hesitate to ask.
>
> Well, there are several arch-dependent power management patches in -mm queued
> up for merging. Do I need to take care of converting them myself, or will that
> be done automatically, or ...?
It should be OK. I'll wait until this lot hits Linus's tree and then I'll
redo the whole -mm patch queue.
The one problem with this is that I will have trouble repulling and remerging
the 81 subsystem tree which are part of -mm until their owners have fixed
everything up - I'll either need to temporarily drop them or will need to
fix them up with Thomas's script each time I fetch them.
But whatever - I'll sort it out..
On Tuesday, 2 October 2007 22:11, Andrew Morton wrote:
> On Tue, 2 Oct 2007 22:12:13 +0200
> "Rafael J. Wysocki" <[email protected]> wrote:
>
> > > Usage: x86-fixup-patches.py sourcepatch destpatch
> > >
> > > source and dest can be the same.
> > >
> > > A helper script to convert complete quilt series is here:
> > > http://userweb.kernel.org/~tglx/x86/fixupseries.sh
> > >
> > > If there is anything we can help with the transition, please do not
> > > hesitate to ask.
> >
> > Well, there are several arch-dependent power management patches in -mm queued
> > up for merging. Do I need to take care of converting them myself, or will that
> > be done automatically, or ...?
>
> It should be OK. I'll wait until this lot hits Linus's tree and then I'll
> redo the whole -mm patch queue.
>
> The one problem with this is that I will have trouble repulling and remerging
> the 81 subsystem tree which are part of -mm until their owners have fixed
> everything up - I'll either need to temporarily drop them or will need to
> fix them up with Thomas's script each time I fetch them.
>
> But whatever - I'll sort it out..
Many thanks!
> The one problem with this is that I will have trouble repulling and remerging
> the 81 subsystem tree which are part of -mm until their owners have fixed
> everything up - I'll either need to temporarily drop them or will need to
> fix them up with Thomas's script each time I fetch them.
FWIW, I just pulled Thomas's x86 branch into my for-2.6.24 branch and
test-booted that on one of my systems with no obvious problems. (Hey,
it compiled, ship it...)
- R.
Mel Gorman wrote:
> On (02/10/07 14:15), Ingo Molnar didst pronounce:
>> * Mel Gorman <[email protected]> wrote:
>>
>>> Dirt. Booting with "profile=sleep,2" is broken in 2.6.23-rc9 and
>>> 2.6.23-rc8 but working in 2.6.22. I was checking it out as part of a
>>> discussion in another thread and noticed it broken in -mm as well
>>> (2.6.23-rc8-mm2). Bisect is in progress but suggestions as to the
>>> prime candidates are welcome or preferably, pointing out that I'm an
>>> idiot because I missed twiddling some config change.
>> Mel, does the patch below fix this bug for you? (Note: you will need to
>> enable CONFIG_SCHEDSTATS=y too.)
>>
>
> Nice one Ingo - got it first try. The problem commit was
> dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the code removed
> in this commit is put back by this latest patch. When applied, profile=sleep
> works as long as CONFIG_SCHEDSTAT is set.
>
And if it isn't set? I can easily see building a new kernel with stats
off and forgetting to change the boot options.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
John Stoffel wrote:
> Linus> I said I was hoping that -rc8 was the last -rc, and I hate
> Linus> doing this, but we've had more changes since -rc8 than we had
> Linus> in -rc8. And while most of them are pretty trivial, I really
> Linus> couldn't face doing a 2.6.23 release and take the risk of some
> Linus> really stupid brown-paper-bag thing.
>
> Linus> So there's a final -rc out there, and right now my plan is to
> Linus> make this series really short, and release 2.6.23 in a few
> Linus> days. So please do give it a last good testing, and holler
> Linus> about any issues you find!
>
> Just to let people know, I was running 2.6.23-rc for over 53 days
> without any issues. Mix of SCSI, Sata, tape drives, disks, MD, LVM,
> SMP, etc. I suspect we've got a pretty darn stable release coming out
> soon.
>
I've been running rc8-git3 since it came out, and while I've built git-5
and will build rc9, I probably will continue testing until I find a bug
or have to boot for some other reason. Running really well, even with a
lot of kvm stuff going on, kernel builds for other machines, etc.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Mon, Oct 01, 2007 at 08:41:49PM -0700, Linus Torvalds wrote:
>
> I said I was hoping that -rc8 was the last -rc, and I hate doing this, but
> we've had more changes since -rc8 than we had in -rc8. And while most of
> them are pretty trivial, I really couldn't face doing a 2.6.23 release and
> take the risk of some really stupid brown-paper-bag thing.
>
> So there's a final -rc out there, and right now my plan is to make this
> series really short, and release 2.6.23 in a few days. So please do give
> it a last good testing, and holler about any issues you find!
Looks pretty good at first glance. Dual-K7, adaptec 29160, NFS, e1000,
root on /dev/sda*. Not even one bad thing to report yet.
Cheers,
Willy
On Tuesday 02 October 2007 04:41:49 Linus Torvalds wrote:
[snip]
> In other words, people who know they may be affected and would want to
> prepare can look at (for example)
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
>
> and generally get ready for the switch-over.
This is certainly a tool issue, but if I use Debian's kernel-image "make-kpkg"
wrapper around the kernel build system, it fails with:
cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
Obviously, this file has moved to arch/x86/boot, but it seems like possibly
unnecessary breakage. I've been copying bzImage for years from
arch/x86_64/boot, and I'm sure there's a handful of scripts (other than
Debian's kernel-image) doing this too.
For now, I hacked the tool[1]. Maybe, if we care, a symlink could be set up
between arch/x86/boot and arch/$ARCH/boot ? Or would papering over this be
more trouble than it's worth?
[1] http://devzero.co.uk/~alistair/kernel-package-changes.diff
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
On 10/2/07, Alistair John Strachan <[email protected]> wrote:
> This is certainly a tool issue, but if I use Debian's kernel-image "make-kpkg"
> wrapper around the kernel build system, it fails with:
>
> cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
>
> Obviously, this file has moved to arch/x86/boot, but it seems like possibly
> unnecessary breakage. I've been copying bzImage for years from
> arch/x86_64/boot, and I'm sure there's a handful of scripts (other than
> Debian's kernel-image) doing this too.
I believe most sane tools would be using the output of uname -m, so a
possible way to fix this would be fixing the data passed to userspace
from uname. However, that might be the case that it creates a new set
of problems too, with tools relying on the output of uname -m to
determine wheter the machine is 32 or 64 bit, and so on.
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
El Mon, 1 Oct 2007 20:41:49 -0700 (PDT), Linus Torvalds <[email protected]> escribi?:
> So there's a final -rc out there, and right now my plan is to make this
> series really short, and release 2.6.23 in a few days. So please do give
> it a last good testing, and holler about any issues you find!
Also...if someone dislikes something in http://kernelnewbies.org/Linux_2_6_23 ,
or wants to fix my english, do it soon :)
On Wed, 3 Oct 2007, Diego Calleja wrote:
>
> Also...if someone dislikes something in http://kernelnewbies.org/Linux_2_6_23 ,
> or wants to fix my english, do it soon :)
Heh. The "remove sk98lin driver" bullet is sadly wrong. We had to
reinstate it because it supported some cards that the skge driver doesn't
handle.
Linus
On Tue, 2007-10-02 at 18:09 -0400, Bill Davidsen wrote:
> Mel Gorman wrote:
> > On (02/10/07 14:15), Ingo Molnar didst pronounce:
> >> * Mel Gorman <[email protected]> wrote:
> >>
> >>> Dirt. Booting with "profile=sleep,2" is broken in 2.6.23-rc9 and
> >>> 2.6.23-rc8 but working in 2.6.22. I was checking it out as part of a
> >>> discussion in another thread and noticed it broken in -mm as well
> >>> (2.6.23-rc8-mm2). Bisect is in progress but suggestions as to the
> >>> prime candidates are welcome or preferably, pointing out that I'm an
> >>> idiot because I missed twiddling some config change.
> >> Mel, does the patch below fix this bug for you? (Note: you will need to
> >> enable CONFIG_SCHEDSTATS=y too.)
> >>
> >
> > Nice one Ingo - got it first try. The problem commit was
> > dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the code removed
> > in this commit is put back by this latest patch. When applied, profile=sleep
> > works as long as CONFIG_SCHEDSTAT is set.
> >
> And if it isn't set? I can easily see building a new kernel with stats
> off and forgetting to change the boot options.
>
If CONFIG_SCHEDSTAT is off and profile=sleep is set, you see with Ingo's
patch and readprofile;
0 *unknown*
0 total 0.0000
That is a tad confusing hence my follow-up patch which would say
"/proc/profile" doesn't exist when readprofile is used and the warning
in dmesg.
--
Mel Gorman
On Tue, 2007-10-02 at 11:17 +0200, Thomas Gleixner wrote:
[...]
> I have uploaded an update of the arch/x86 tree based on -rc9 to
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
>
[...]
> If there is anything we can help with the transition, please do not
> hesitate to ask.
>
> Thanks,
>
> Thomas, Ingo
Hi Thomas,
This latest x86 branch build and boot without problem with my usual
x86_64 config.
If you remember our conversation one month ago, I was unable to build
your tree.
I've upgraded my Ubuntu distribution from 7.04 to 7.10 beta this week,
maybe this fixed it.
But I still had to do some manual fixes to get the packaging steps
working:
mkdir arch/x86_64/boot/
ln -s ../../../arch/x86/boot/bzImage arch/x86_64/boot/bzImage
Best regards,
- Eric
* Mel Gorman <[email protected]> wrote:
> On (02/10/07 14:15), Ingo Molnar didst pronounce:
> >
> > * Mel Gorman <[email protected]> wrote:
> >
> > > Dirt. Booting with "profile=sleep,2" is broken in 2.6.23-rc9 and
> > > 2.6.23-rc8 but working in 2.6.22. I was checking it out as part of a
> > > discussion in another thread and noticed it broken in -mm as well
> > > (2.6.23-rc8-mm2). Bisect is in progress but suggestions as to the
> > > prime candidates are welcome or preferably, pointing out that I'm an
> > > idiot because I missed twiddling some config change.
> >
> > Mel, does the patch below fix this bug for you? (Note: you will need to
> > enable CONFIG_SCHEDSTATS=y too.)
>
> Nice one Ingo - got it first try. The problem commit was
> dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the code
> removed in this commit is put back by this latest patch. When
> applied, profile=sleep works as long as CONFIG_SCHEDSTAT is set.
great - thanks for testing it. I'm glad you caught it as sleep=profile
is pretty useful in "why is my system so slow" tests. (which problems
are usually reported _after_ a stable kernel is released ...)
Ingo
* Mel Gorman <[email protected]> wrote:
> > > Nice one Ingo - got it first try. The problem commit was
> > > dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the
> > > code removed in this commit is put back by this latest patch.
> > > When applied, profile=sleep works as long as CONFIG_SCHEDSTAT is
> > > set.
> > >
> > And if it isn't set? I can easily see building a new kernel with
> > stats off and forgetting to change the boot options.
>
> If CONFIG_SCHEDSTAT is off and profile=sleep is set, you see with
> Ingo's patch and readprofile;
>
> 0 *unknown*
> 0 total 0.0000
>
> That is a tad confusing hence my follow-up patch which would say
> "/proc/profile" doesn't exist when readprofile is used and the warning
> in dmesg.
yep - that's the best we can do for the stable release.
We could improve quality of behavior here by not offering /proc/profile
in that case and by printk-ing something if profile=sleep is specified
on a !CONFIG_SCHEDSTATS kernel. I'm willing to apply patches that do
that :)
Ingo
hm, i just triggered the procfs crash below with -rc9 on a testbox.
Config attached. It's easy to reproduce it via 'service sshd restart'.
The crash site is:
(gdb) list *0xc017599d
0xc017599d is in seq_path (fs/seq_file.c:354).
349 if (m->count < m->size) {
350 char *s = m->buf + m->count;
351 char *p = d_path(dentry, mnt, s, m->size - m->count);
352 if (!IS_ERR(p)) {
353 while (s <= p) {
354 char c = *p++;
355 if (!c) {
356 p = m->buf + m->count;
357 m->count = s - m->buf;
358 return s - p;
(gdb)
any ideas? Fortunately i was able to do an strace of the incident:
3247 munmap(0xb7f3e000, 4096) = 0
3247 open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
3247 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
3247 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f3e000
3247 read(3, <unfinished ...>
3247 +++ killed by SIGSEGV +++
and doing "cat /proc/mounts" triggers the crash reliably.
Ingo
---------------->
BUG: unable to handle kernel paging request at virtual address f2a40000
printing eip:
c017599d
*pdpt = 0000000000001001
*pde = 0000000000aee067
*pte = 0000000032a40000
Oops: 0000 [#1]
PREEMPT DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c017599d>] Not tainted VLI
EFLAGS: 00010297 (2.6.23-rc9 #89)
EIP is at seq_path+0x60/0xca
eax: f2a3fffe ebx: c290c8d4 ecx: f6e341f0 edx: f2a3fffe
esi: f2a3f007 edi: c29097f0 ebp: ec5ddf1c esp: ec5ddf04
ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
Process sshd (pid: 2743, ti=ec5dc000 task=f6e341f0 task.ti=ec5dc000)
Stack: 00000ff9 c2bf6b40 f2a3fffe c29097c0 c2bf6b40 c29097f0 ec5ddf34 c0173c41
c05ffe64 00000400 c2bf6b40 c29097f0 ec5ddf74 c0175d2b 00000400 b7fa2000
f5277600 c2bf6b60 00000000 c0109e99 ec5ddf80 00000246 c01555e6 00000000
Call Trace:
[<c0106f80>] show_trace_log_lvl+0x19/0x2e
[<c0107030>] show_stack_log_lvl+0x9b/0xa3
[<c0107428>] show_registers+0x1c4/0x2e3
[<c010772d>] die+0x115/0x1e0
[<c0115e3b>] do_page_fault+0x808/0x8e1
[<c0508faa>] error_code+0x6a/0x70
[<c0173c41>] show_vfsmnt+0x44/0x11e
[<c0175d2b>] seq_read+0xeb/0x25f
[<c0160e63>] vfs_read+0x87/0xe5
[<c0161613>] sys_read+0x3d/0x61
[<c010606e>] sysenter_past_esp+0x6b/0xb5
=======================
Code: 89 45 f0 76 77 eb 7a 8b 55 ec 8b 4d ec 89 f7 8b 02 89 c2 03 51 0c 29 c7 89 f0 89 79 0c 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 8b 45 08 0f be d9 89 da e8
EIP: [<c017599d>] seq_path+0x60/0xca SS:ESP 0068:ec5ddf04
BUG: unable to handle kernel paging request at virtual address f2a40000
printing eip:
c017599d
*pdpt = 0000000000001001
*pde = 0000000000aee067
*pte = 0000000032a40000
Oops: 0000 [#2]
PREEMPT DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c017599d>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #89)
EIP is at seq_path+0x60/0xca
eax: f2a3fffe ebx: c290c8d4 ecx: c02be275 edx: f2a3fffe
esi: f2a3f007 edi: c29097f0 ebp: ef2b7f1c esp: ef2b7f04
ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
Process sshd (pid: 2744, ti=ef2b6000 task=f6e5cce0 task.ti=ef2b6000)
Stack: 00000ff9 c2bf6b40 f2a3fffe c29097c0 c2bf6b40 c29097f0 ef2b7f34 c0173c41
c05ffe64 00000400 c2bf6b40 c29097f0 ef2b7f74 c0175d2b 00000400 b7f09000
f7375240 c2bf6b60 00000000 00000073 ef2b7f80 00000246 c01555e6 00000000
Call Trace:
[<c0106f80>] show_trace_log_lvl+0x19/0x2e
[<c0107030>] show_stack_log_lvl+0x9b/0xa3
[<c0107428>] show_registers+0x1c4/0x2e3
[<c010772d>] die+0x115/0x1e0
[<c0115e3b>] do_page_fault+0x808/0x8e1
[<c0508faa>] error_code+0x6a/0x70
[<c0173c41>] show_vfsmnt+0x44/0x11e
[<c0175d2b>] seq_read+0xeb/0x25f
[<c0160e63>] vfs_read+0x87/0xe5
[<c0161613>] sys_read+0x3d/0x61
[<c010606e>] sysenter_past_esp+0x6b/0xb5
=======================
Code: 89 45 f0 76 77 eb 7a 8b 55 ec 8b 4d ec 89 f7 8b 02 89 c2 03 51 0c 29 c7 89 f0 89 79 0c 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 8b 45 08 0f be d9 89 da e8
EIP: [<c017599d>] seq_path+0x60/0xca SS:ESP 0068:ef2b7f04
update: occasionally the reading of /proc/mounts succeeds, and it's:
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "rootfs / rootfs rw 0 0\n/dev/root"..., 4096) = 290
write(1, "rootfs / rootfs rw 0 0\n/dev/root"..., 290rootfs / rootfs rw 0 0
/dev/root / ext3 rw,noatime,nodiratime,data=ordered 0 0
/proc /proc proc rw 0 0
/proc/bus/usb /proc/bus/usb usbfs rw 0 0
/sys /sys sysfs rw 0 0
/dev/devpts /dev/pts devpts rw 0 0
/dev/sda2 /home ext3 rw,noatime,nodiratime,data=ordered 0 0
nodev /debug debugfs rw 0 0
) = 290
read(3, "", 4096) = 0
close(3) = 0
there's nothing particularly interesting in it. (perhaps debugfs)
Ingo
* Ingo Molnar <[email protected]> wrote:
> nodev /debug debugfs rw 0 0
> ) = 290
> read(3, "", 4096) = 0
> close(3) = 0
>
> there's nothing particularly interesting in it. (perhaps debugfs)
disabling debugfs makes the crash go away so it's debugfs related. The
.config delta is below.
Ingo
--- .config.broken.000 2007-10-03 10:28:14.000000000 +0200
+++ .config.good.000 2007-10-03 11:11:18.000000000 +0200
@@ -85,7 +85,7 @@ CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_KMOD is not set
CONFIG_BLOCK=y
# CONFIG_LBD is not set
-CONFIG_BLK_DEV_IO_TRACE=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_LSF=y
CONFIG_BLK_DEV_BSG=y
@@ -631,7 +631,6 @@ CONFIG_CFG80211=y
CONFIG_WIRELESS_EXT=y
CONFIG_MAC80211=y
CONFIG_MAC80211_LEDS=y
-CONFIG_MAC80211_DEBUGFS=y
# CONFIG_MAC80211_DEBUG is not set
CONFIG_IEEE80211=m
CONFIG_IEEE80211_DEBUG=y
@@ -1689,7 +1688,7 @@ CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_UNUSED_SYMBOLS=y
-CONFIG_DEBUG_FS=y
+# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
@@ -1724,8 +1724,6 @@ CONFIG_FAULT_INJECTION=y
# CONFIG_FAILSLAB is not set
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_FAIL_MAKE_REQUEST=y
-CONFIG_FAULT_INJECTION_DEBUG_FS=y
-CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
* Ingo Molnar <[email protected]> wrote:
> -CONFIG_MAC80211_DEBUGFS=y
it's CONFIG_MAC80211_DEBUGFS=y causing the crash.
Ingo
On (03/10/07 10:21), Ingo Molnar didst pronounce:
>
> * Mel Gorman <[email protected]> wrote:
>
> > > > Nice one Ingo - got it first try. The problem commit was
> > > > dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the
> > > > code removed in this commit is put back by this latest patch.
> > > > When applied, profile=sleep works as long as CONFIG_SCHEDSTAT is
> > > > set.
> > > >
> > > And if it isn't set? I can easily see building a new kernel with
> > > stats off and forgetting to change the boot options.
> >
> > If CONFIG_SCHEDSTAT is off and profile=sleep is set, you see with
> > Ingo's patch and readprofile;
> >
> > 0 *unknown*
> > 0 total 0.0000
> >
> > That is a tad confusing hence my follow-up patch which would say
> > "/proc/profile" doesn't exist when readprofile is used and the warning
> > in dmesg.
>
> yep - that's the best we can do for the stable release.
>
Agreed. The less change the better this late in the game.
> We could improve quality of behavior here by not offering /proc/profile
> in that case and by printk-ing something if profile=sleep is specified
> on a !CONFIG_SCHEDSTATS kernel. I'm willing to apply patches that do
> that :)
>
I included a candidate patch in the last mail but it was shoved down at
the bottom so it could easily have been missed.
==============
Subject: Document profile=sleep requiring CONFIG_SCHEDSTATS
profile=sleep only works if CONFIG_SCHEDSTATS is set. This patch notes the
limitation in Documentation/kernel-parameters.txt and prints a warning at
boot-time if profile=sleep is used without CONFIG_SCHEDSTAT.
Signed-off-by: Mel Gorman <[email protected]>
---
Documentation/kernel-parameters.txt | 3 ++-
kernel/profile.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc9-005_ingo_profile_fix/Documentation/kernel-parameters.txt linux-2.6.23-rc9-010_document_profilesleep/Documentation/kernel-parameters.txt
--- linux-2.6.23-rc9-005_ingo_profile_fix/Documentation/kernel-parameters.txt 2007-10-02 04:24:52.000000000 +0100
+++ linux-2.6.23-rc9-010_document_profilesleep/Documentation/kernel-parameters.txt 2007-10-02 16:43:41.000000000 +0100
@@ -1395,7 +1395,8 @@ and is between 256 and 4096 characters.
Param: "schedule" - profile schedule points.
Param: <number> - step/bucket size as a power of 2 for
statistical time based profiling.
- Param: "sleep" - profile D-state sleeping (millisecs)
+ Param: "sleep" - profile D-state sleeping (millisecs).
+ Requires CONFIG_SCHEDSTATS
processor.max_cstate= [HW,ACPI]
Limit processor to maximum C-state
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc9-005_ingo_profile_fix/kernel/profile.c linux-2.6.23-rc9-010_document_profilesleep/kernel/profile.c
--- linux-2.6.23-rc9-005_ingo_profile_fix/kernel/profile.c 2007-10-02 04:24:52.000000000 +0100
+++ linux-2.6.23-rc9-010_document_profilesleep/kernel/profile.c 2007-10-02 16:44:50.000000000 +0100
@@ -60,6 +60,7 @@ static int __init profile_setup(char * s
int par;
if (!strncmp(str, sleepstr, strlen(sleepstr))) {
+#ifdef CONFIG_SCHEDSTATS
prof_on = SLEEP_PROFILING;
if (str[strlen(sleepstr)] == ',')
str += strlen(sleepstr) + 1;
@@ -68,6 +69,10 @@ static int __init profile_setup(char * s
printk(KERN_INFO
"kernel sleep profiling enabled (shift: %ld)\n",
prof_shift);
+#else
+ printk(KERN_WARNING
+ "kernel sleep profiling requires CONFIG_SCHEDSTATS\n");
+#endif /* CONFIG_SCHEDSTATS */
} else if (!strncmp(str, schedstr, strlen(schedstr))) {
prof_on = SCHED_PROFILING;
if (str[strlen(schedstr)] == ',')
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
>
> hm, i just triggered the procfs crash below with -rc9 on a testbox.
> Config attached. It's easy to reproduce it via 'service sshd restart'.
> The crash site is:
>
> (gdb) list *0xc017599d
> 0xc017599d is in seq_path (fs/seq_file.c:354).
> 349 if (m->count < m->size) {
> 350 char *s = m->buf + m->count;
> 351 char *p = d_path(dentry, mnt, s, m->size - m->count);
> 352 if (!IS_ERR(p)) {
> 353 while (s <= p) {
> 354 char c = *p++;
> 355 if (!c) {
> 356 p = m->buf + m->count;
> 357 m->count = s - m->buf;
> 358 return s - p;
> (gdb)
>
> any ideas? Fortunately i was able to do an strace of the incident:
Charming... So we get d_path() either returning junk or we get something
that isn't NUL-terminated. Which one it is? I.e. what does p look like
and what's in s?
* Al Viro <[email protected]> wrote:
> On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
> >
> > hm, i just triggered the procfs crash below with -rc9 on a testbox.
> > Config attached. It's easy to reproduce it via 'service sshd restart'.
> > The crash site is:
> >
> > (gdb) list *0xc017599d
> > 0xc017599d is in seq_path (fs/seq_file.c:354).
> > 349 if (m->count < m->size) {
> > 350 char *s = m->buf + m->count;
> > 351 char *p = d_path(dentry, mnt, s, m->size - m->count);
> > 352 if (!IS_ERR(p)) {
> > 353 while (s <= p) {
> > 354 char c = *p++;
> > 355 if (!c) {
> > 356 p = m->buf + m->count;
> > 357 m->count = s - m->buf;
> > 358 return s - p;
> > (gdb)
> >
> > any ideas? Fortunately i was able to do an strace of the incident:
>
> Charming... So we get d_path() either returning junk or we get
> something that isn't NUL-terminated. Which one it is? I.e. what does
> p look like and what's in s?
could be use-after-free as well, as CONFIG_PAGEALLOC was enabled.
Ingo
On Mon, 1 Oct 2007, Linus Torvalds wrote:
> So there's a final -rc out there, and right now my plan is to make this
> series really short, and release 2.6.23 in a few days. So please do give
> it a last good testing, and holler about any issues you find!
The r8169 nic performance regression is still there.
2.6.22: send 82MB/s, receive 86MB/s
2.6.23-rc9: send 32MB/s, receive 98MB/s
I debugged this with Francois Romieu but haven't heard from him since
testing his fixes.
I attached a patch from him which is a partial revert of commit
6dccd16b7c2703e8bbf8bca62b5cf248332afbe2.
With this patch I get 93MB send and 97MB receive and I have been running it
for a week but I don't know if the patch has any downsides on other
systems.
//T
> Linus
>From 34875931ba2e473e2867d941980131edd609dbe4 Mon Sep 17 00:00:00 2001
From: Francois Romieu <[email protected]>
Date: Wed, 26 Sep 2007 23:44:03 +0200
Subject: [PATCH] r8169: more revert
Part of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2.
Signed-off-by: Francois Romieu <[email protected]>
---
drivers/net/r8169.c | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index cb4c412..6d8611c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1905,7 +1905,11 @@ static void rtl_hw_start_8169(struct net_device *dev)
rtl_set_rx_max_size(ioaddr);
- rtl_set_rx_tx_config_registers(tp);
+ if ((tp->mac_version == RTL_GIGA_MAC_VER_01) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_02) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_03) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_04))
+ rtl_set_rx_tx_config_registers(tp);
tp->cp_cmd |= rtl_rw_cpluscmd(ioaddr) | PCIMulRW;
@@ -1926,6 +1930,14 @@ static void rtl_hw_start_8169(struct net_device *dev)
rtl_set_rx_tx_desc_registers(tp, ioaddr);
+ if ((tp->mac_version != RTL_GIGA_MAC_VER_01) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_02) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_03) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_04)) {
+ RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+ rtl_set_rx_tx_config_registers(tp);
+ }
+
RTL_W8(Cfg9346, Cfg9346_Lock);
/* Initially a 10 us delay. Turned it into a PCI commit. - FR */
@@ -1940,8 +1952,6 @@ static void rtl_hw_start_8169(struct net_device *dev)
/* Enable all known interrupts by setting the interrupt mask. */
RTL_W16(IntrMask, tp->intr_event);
-
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
}
static void rtl_hw_start_8168(struct net_device *dev)
--
1.5.3.2
On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
> > Charming... So we get d_path() either returning junk or we get
> > something that isn't NUL-terminated. Which one it is? I.e. what does
> > p look like and what's in s?
>
> could be use-after-free as well, as CONFIG_PAGEALLOC was enabled.
Umm... d_path() had just written there, so use-after-free is not too
likely to trigger page fault on read immediately afterwards - you'd
need a pretty tight race to hit it.
On Wed, 3 Oct 2007, Ingo Molnar wrote:
>
> hm, i just triggered the procfs crash below with -rc9 on a testbox.
You have a terminally buggy piece of shit compiler.
Lookie here:
- the bug happens on this:
char c = *p++;
- which has been compiled into
8b 3a mov (%edx),%edi
which is a *word* access.
- the pointer is at the end of a page (very much on purpose):
edx: f2a3fffe
- and as a result you get an exception on the *next* page:
BUG: unable to handle kernel paging request at virtual address f2a40000
and btw, there is no question what-so-ever about whether your compiler
might be doing a legal optimization - the compiler really is wrong, and is
total shit. You need to make a gcc bug-report. Because this is not a
question of "the standard is ambiguous", this is a question of "the
compiler turned good code into code that could SIGSEGV in user space too,
if 'malloc()' happened to return a pointer at the end of an allocation".
Linus
On Wed, 3 Oct 2007 15:26:01 +0100
Al Viro <[email protected]> wrote:
> On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
> > > Charming... So we get d_path() either returning junk or we get
> > > something that isn't NUL-terminated. Which one it is? I.e. what
> > > does p look like and what's in s?
> >
> > could be use-after-free as well, as CONFIG_PAGEALLOC was enabled.
>
> Umm... d_path() had just written there, so use-after-free is not too
> likely to trigger page fault on read immediately afterwards - you'd
> need a pretty tight race to hit it.
I suspect we want the following patch out of general principles; Ingo,
can you see if this one helps?
(if not, it's still worth considering; it looks like we're first
destroying the device object (which holds the name of the directory)
before we unregister the directory... if that fails then we have a mess.
Signed-off-by: Arjan van de Ven <[email protected]>
--- linux-2.6.23-rc2/net/wireless/core.c~ 2007-10-03 08:04:45.000000000 -0700
+++ linux-2.6.23-rc2/net/wireless/core.c 2007-10-03 08:04:45.000000000 -0700
@@ -133,8 +133,8 @@ void wiphy_unregister(struct wiphy *wiph
mutex_unlock(&drv->mtx);
list_del(&drv->list);
- device_del(&drv->wiphy.dev);
debugfs_remove(drv->wiphy.debugfsdir);
+ device_del(&drv->wiphy.dev);
mutex_unlock(&cfg80211_drv_mutex);
}
El Tue, 2 Oct 2007 16:32:00 -0700 (PDT), Linus Torvalds <[email protected]> escribi?:
> Heh. The "remove sk98lin driver" bullet is sadly wrong. We had to
> reinstate it because it supported some cards that the skge driver doesn't
> handle.
Thanks, fixed
* Linus Torvalds <[email protected]> wrote:
> On Wed, 3 Oct 2007, Ingo Molnar wrote:
> >
> > hm, i just triggered the procfs crash below with -rc9 on a testbox.
>
> You have a terminally buggy piece of shit compiler.
hm, it's 4.0.2. Not the latest & greatest but i've been using it for 2
years and this would be the first time it miscompiles a 32-bit kernel
out of tens of thousands of successful kernel bootups.
> - and as a result you get an exception on the *next* page:
>
> BUG: unable to handle kernel paging request at virtual address f2a40000
Hm, are you sure? This is a CONFIG_DEBUG_PAGEALLOC=y kernel, so even a
slight overrun of a non-NIL terminated string (as suspected by Al) could
run into a non-mapped kernel page. (which would indicate not a compiler
bug but use-after free)
i just found another config under which i get similar crashes, config
attached. One common theme is CONFIG_DEBUG_FS and DEBUG_PAGEALLOC - and
CONFIG_MAC80211_DEBUGFS is not enabled in this one so it's off the hook
i think. (the crashes are attached below)
(my serial log on this box goes back about 6 months, and that alone
shows more than 3500 successful kernel bootups on that particular
testsystem, each kernel built by this compiler - and there's another
testsystem that i use even more frequently. Despite that, a compiler bug
is still possible of course.)
Ingo
--------------->
kobject_uevent_env
fill_kobj_path: path = '/class/vc/vcsa8'
kobject vcsa8: cleaning up
BUG: unable to handle kernel paging request at virtual address f6207000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 0000000036207000
Oops: 0000 [#1]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 1
EIP: 0060:[<c016ecf1>] Not tainted VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f6206ffe ebx: c2de0f50 ecx: 0000002b edx: f6206ffe
esi: f6206007 edi: c2dddfb0 ebp: f6503f18 esp: f6503f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process awk (pid: 1160, ti=f6503000 task=f73a8390 task.ti=f6503000)
Stack: 00000ff9 f6e5cf70 f6206ffe c2dddf80 f6e5cf70 c2dddfb0 f6503f30 c016ce40
c05d71b5 f6730f38 f6e5cf70 c2dddfb0 f6503f70 c016f05d 00000400 08098f18
f6730f38 f6e5cf90 00000000 0806bc2e 00000003 08094320 f6503fb0 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f6503f00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#2]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 0000002c edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f6367f18 esp: f6367f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process MAKEDEV (pid: 1170, ti=f6367000 task=f776e390 task.ti=f6367000)
Stack: 00000ff9 f650ef70 f63d0ffe c2dddf80 f650ef70 c2dddfb0 f6367f30 c016ce40
c05d71b5 f6473f38 f650ef70 c2dddfb0 f6367f70 c016f05d 00000400 b7f13000
f6473f38 f650ef90 00000000 f65eb580 000b7f13 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f6367f00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#3]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 0000002c edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f6358f18 esp: f6358f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process MAKEDEV (pid: 1174, ti=f6358000 task=f73ae390 task.ti=f6358000)
Stack: 00000ff9 f650ef70 f63d0ffe c2dddf80 f650ef70 c2dddfb0 f6358f30 c016ce40
c05d71b5 f6274f38 f650ef70 c2dddfb0 f6358f70 c016f05d 00000400 b7f02000
f6274f38 f650ef90 00000000 f65eb7b0 000b7f02 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f6358f00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#4]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 0000002a edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f6080f18 esp: f6080f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process udevd (pid: 1176, ti=f6080000 task=f7346390 task.ti=f6080000)
Stack: 00000ff9 f650ef70 f63d0ffe c2dddf80 f650ef70 c2dddfb0 f6080f30 c016ce40
c05d71b5 f67b3f38 f650ef70 c2dddfb0 f6080f70 c016f05d 00000400 b7f89000
f67b3f38 f650ef90 00000000 f6bb5120 000b7f89 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f6080f00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#5]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 0000002b edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f597ef18 esp: f597ef00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process udevsend (pid: 1264, ti=f597e000 task=f778e390 task.ti=f597e000)
Stack: 00000ff9 f650ef70 f63d0ffe c2dddf80 f650ef70 c2dddfb0 f597ef30 c016ce40
c05d71b5 f67c5f38 f650ef70 c2dddfb0 f597ef70 c016f05d 00000400 b7f12000
f67c5f38 f650ef90 00000000 f6073510 000b7f12 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f597ef00
BUG: unable to handle kernel paging request at virtual address f6207000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 0000000036207000
Oops: 0000 [#6]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 1
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f6206ffe ebx: c2de0f50 ecx: 0000002b edx: f6206ffe
esi: f6206007 edi: c2dddfb0 ebp: f5929f18 esp: f5929f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process udevsend (pid: 1265, ti=f5929000 task=f77af390 task.ti=f5929000)
Stack: 00000ff9 f6e5cf70 f6206ffe c2dddf80 f6e5cf70 c2dddfb0 f5929f30 c016ce40
c05d71b5 f6352f38 f6e5cf70 c2dddfb0 f5929f70 c016f05d 00000400 b7f31000
f6352f38 f6e5cf90 00000000 f66c9740 000b7f31 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f5929f00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#7]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 0000002b edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f6a98f18 esp: f6a98f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process udevsend (pid: 1266, ti=f6a98000 task=f7397390 task.ti=f6a98000)
Stack: 00000ff9 f650ef70 f63d0ffe c2dddf80 f650ef70 c2dddfb0 f6a98f30 c016ce40
c05d71b5 f7359f38 f650ef70 c2dddfb0 f6a98f70 c016f05d 00000400 b7f8a000
f7359f38 f650ef90 00000000 f6376dd0 000b7f8a 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f6a98f00
BUG: unable to handle kernel paging request at virtual address f6207000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 0000000036207000
Oops: 0000 [#8]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 1
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f6206ffe ebx: c2de0f50 ecx: 0000002b edx: f6206ffe
esi: f6206007 edi: c2dddfb0 ebp: f60c0f18 esp: f60c0f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process udevsend (pid: 1267, ti=f60c0000 task=f6372390 task.ti=f60c0000)
Stack: 00000ff9 f6e5cf70 f6206ffe c2dddf80 f6e5cf70 c2dddfb0 f60c0f30 c016ce40
c05d71b5 f6145f38 f6e5cf70 c2dddfb0 f60c0f70 c016f05d 00000400 b7fd2000
f6145f38 f6e5cf90 00000000 f6aa4890 000b7fd2 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f60c0f00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#9]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 0000002a edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f64c1f18 esp: f64c1f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process udevstart (pid: 1269, ti=f64c1000 task=f6742390 task.ti=f64c1000)
Stack: 00000ff9 f650ef70 f63d0ffe c2dddf80 f650ef70 c2dddfb0 f64c1f30 c016ce40
c05d71b5 f6b22f38 f650ef70 c2dddfb0 f64c1f70 c016f05d 00000400 b7f47000
f6b22f38 f650ef90 00000000 f667ecf0 000b7f47 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f64c1f00
fill_kobj_path: path = '/class/input/input0'
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#10]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 00000057 edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f588cf18 esp: f588cf00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process ls (pid: 1289, ti=f588c000 task=f7346390 task.ti=f588c000)
Stack: 00000ff9 f59bef70 f63d0ffe c2dddf80 f59bef70 c2dddfb0 f588cf30 c016ce40
c05d71b5 f6f26f38 f59bef70 c2dddfb0 f588cf70 c016f05d 00000400 b7f48000
f6f26f38 f59bef90 00000000 f6376580 000b7f48 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f588cf00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#11]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 00000023 edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f55e6f18 esp: f55e6f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process lvm.static (pid: 1329, ti=f55e6000 task=f7769390 task.ti=f55e6000)
Stack: 00000ff9 f59bef70 f63d0ffe c2dddf80 f59bef70 c2dddfb0 f55e6f30 c016ce40
c05d71b5 f6592f38 f59bef70 c2dddfb0 f55e6f70 c016f05d 00000400 b7f77000
f6592f38 f59bef90 00000000 f66c9900 000b7f77 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c01028e2>] syscall_call+0x7/0xb
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f55e6f00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#12]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 0000002b edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f56e0f18 esp: f56e0f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process fsck.ext3 (pid: 1331, ti=f56e0000 task=f7769390 task.ti=f56e0000)
Stack: 00000ff9 f59bef70 f63d0ffe c2dddf80 f59bef70 c2dddfb0 f56e0f30 c016ce40
c05d71b5 f67f3f38 f59bef70 c2dddfb0 f56e0f70 c016f05d 00000400 b7dba000
f67f3f38 f59bef90 00000000 f60ce510 000b7dba 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c01028e2>] syscall_call+0x7/0xb
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f56e0f00
BUG: unable to handle kernel paging request at virtual address f63d1000
printing eip:
c016ecf1
*pdpt = 0000000000003001
*pde = 0000000000ac1067
*pte = 00000000363d1000
Oops: 0000 [#13]
SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c016ecf1>] Tainted: G D VLI
EFLAGS: 00010297 (2.6.23-rc9 #20)
EIP is at seq_path+0x60/0xca
eax: f63d0ffe ebx: c2de0f50 ecx: 00000026 edx: f63d0ffe
esi: f63d0007 edi: c2dddfb0 ebp: f5703f18 esp: f5703f00
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process sulogin (pid: 1335, ti=f5703000 task=f7397390 task.ti=f5703000)
Stack: 00000ff9 f59bef70 f63d0ffe c2dddf80 f59bef70 c2dddfb0 f5703f30 c016ce40
c05d71b5 f6058f38 f59bef70 c2dddfb0 f5703f70 c016f05d 00000400 b7fcf000
f6058f38 f59bef90 00000000 f60ce660 000b7fcf 00000073 00000000 00000000
Call Trace:
[<c0103c8d>] show_trace_log_lvl+0x19/0x2e
[<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
[<c0104083>] show_registers+0x1af/0x281
[<c0104338>] die+0x11a/0x1e8
[<c01138d1>] do_page_fault+0x632/0x715
[<c04e7372>] error_code+0x72/0x80
[<c016ce40>] show_vfsmnt+0x43/0x120
[<c016f05d>] seq_read+0xf1/0x269
[<c0159783>] vfs_read+0x90/0x10e
[<c0159f9e>] sys_read+0x3f/0x63
[<c0102876>] sysenter_past_esp+0x5f/0x89
=======================
Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f5703f00
> and btw, there is no question what-so-ever about whether your compiler
> might be doing a legal optimization - the compiler really is wrong, and is
Pedant: valid. Almost all optimizations are legal, nobody has yet written
laws about compilers. Sorry but I'm forever fixing misuse of the word
"illegal" in printks, docs and the like and it gets annoying after a bit.
> total shit. You need to make a gcc bug-report. Because this is not a
> question of "the standard is ambiguous",
Agreed - the standard is not ambiguous here. (For reference the standard
says that a valid pointer must point at an object _OR_ one past the end
of the object (in the latter case it is not dereferencable)). So its a
compiler bug.
Alan
On Wed, 3 Oct 2007, Linus Torvalds wrote:
>
> - the bug happens on this:
>
> char c = *p++;
>
> - which has been compiled into
>
> 8b 3a mov (%edx),%edi
Btw, this definitely doesn't happen for me, either on x86-64 or plain x86.
The x86 thing I tested was Fedora 8 testing (ie not even some stable
setup), so I wonder what experimental compiler you have.
Your compiler generates
movl -16(%ebp),%edx
movl (%edx),%edi /* this is _totally_ bogus! */
incl %edx
movl %edx,-16(%ebp)
movl %edi,%ecx
testb %cl,%cl
je ...
while I get (gcc version 4.1.2 20070925 (Red Hat 4.1.2-28)):
movl -16(%ebp), %eax # p,
movzbl (%eax), %edi #, c /* not bogus! */
movl %edi, %edx # c,
testb %dl, %dl #
je .L64 #,
incl %eax #
movsbl %dl,%ebx #, D.12414
movl %eax, -16(%ebp) #, p
where the difference (apart from doing the increment differently and
different register allocation) is that I have a "movzbl" (correct), while
you have a "movl" (pure and utter crap).
I *suspect* that the compiler bug is along the lines of:
(a) start off with movzbl
(b) notice that the higher bits don't matter, because nobody subsequently
uses them
(c) turn the thing into just a byte move.
(d) make the totally incorrect optimization of using a full 32-bit move
in order to avoid a partial register access stall
and the thing is, that final optimization can actually speed things up
(although it can also slow things down for any access that crosses a cache
sector boundary - 8/16 bytes), but it's seriously bogus, exactly because
it can cause an invalid access to the three next bytes that may not even
exist.
Linus
* Linus Torvalds <[email protected]> wrote:
> Your compiler generates
>
> movl -16(%ebp),%edx
> movl (%edx),%edi /* this is _totally_ bogus! */
> incl %edx
> movl %edx,-16(%ebp)
> movl %edi,%ecx
> testb %cl,%cl
> je ...
ah, ok.
> while I get (gcc version 4.1.2 20070925 (Red Hat 4.1.2-28)):
>
> movl -16(%ebp), %eax # p,
> movzbl (%eax), %edi #, c /* not bogus! */
> movl %edi, %edx # c,
> testb %dl, %dl #
> je .L64 #,
> incl %eax #
> movsbl %dl,%ebx #, D.12414
> movl %eax, -16(%ebp) #, p
>
> where the difference (apart from doing the increment differently and
> different register allocation) is that I have a "movzbl" (correct),
> while you have a "movl" (pure and utter crap).
i'll try with another compiler in a minute.
Ingo
On Wed, 3 Oct 2007, Ingo Molnar wrote:
>
> > - and as a result you get an exception on the *next* page:
> >
> > BUG: unable to handle kernel paging request at virtual address f2a40000
>
> Hm, are you sure? This is a CONFIG_DEBUG_PAGEALLOC=y kernel, so even a
> slight overrun of a non-NIL terminated string (as suspected by Al) could
> run into a non-mapped kernel page. (which would indicate not a compiler
> bug but use-after free)
I am 100% sure. I can look at the disassembly, and point to the fact that
your Oops happens on code that is simply totally bogus.
That string is NUL-terminated, which is why the access is to f2a3fffe in
the first place: we explicitly asked d_path() to create us a string at the
end of the page (it creates them backwards), so the path string has a NUL
a the end at address f2a3ffff, which is exactly what we'd expect.
Your compiler really does seem to be total crap.
Do a "make fs/seq_file.s" (and make sure you *disable* CONFIG_DEBUG_INFO
first, otherwise the result will be unreadable crud), and look at
seq_path(). It's going to be more readable than the disassembly that I got
through gdb, but I bet it's going to show it even more clearly.
> i just found another config under which i get similar crashes, config
> attached. One common theme is CONFIG_DEBUG_FS and DEBUG_PAGEALLOC - and
> CONFIG_MAC80211_DEBUGFS is not enabled in this one so it's off the hook
> i think. (the crashes are attached below)
.. of *course* DEBUG_PAGEALLOC is going to be implied in the problem. If
you don't have DEBUG_PAGEALLOC, you'll never see this, because you'll have
all pages mapped, and the only page that it could happen to is the very
last page in memory, and you'll never hit that one in practice.
> (my serial log on this box goes back about 6 months, and that alone
> shows more than 3500 successful kernel bootups on that particular
> testsystem, each kernel built by this compiler - and there's another
> testsystem that i use even more frequently. Despite that, a compiler bug
> is still possible of course.)
It's not about "possible". It's a fact. Send me your "seq_file.s" output
for that function to be sure - it *could* be memory corruption that
changes a "movb" into a "movl", and maybe the compiler did a byte move to
start with, but quite frankly, that is such a remote possibility that I
don't consider it realistic.
> BUG: unable to handle kernel paging request at virtual address f6207000
> printing eip:
> c016ecf1
> *pdpt = 0000000000003001
> *pde = 0000000000ac1067
> *pte = 0000000036207000
> Oops: 0000 [#1]
> SMP DEBUG_PAGEALLOC
> Modules linked in:
> CPU: 1
> EIP: 0060:[<c016ecf1>] Not tainted VLI
> EFLAGS: 00010297 (2.6.23-rc9 #20)
> EIP is at seq_path+0x60/0xca
> eax: f6206ffe ebx: c2de0f50 ecx: 0000002b edx: f6206ffe
> esi: f6206007 edi: c2dddfb0 ebp: f6503f18 esp: f6503f00
> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> Process awk (pid: 1160, ti=f6503000 task=f73a8390 task.ti=f6503000)
> Stack: 00000ff9 f6e5cf70 f6206ffe c2dddf80 f6e5cf70 c2dddfb0 f6503f30 c016ce40
> c05d71b5 f6730f38 f6e5cf70 c2dddfb0 f6503f70 c016f05d 00000400 08098f18
> f6730f38 f6e5cf90 00000000 0806bc2e 00000003 08094320 f6503fb0 00000000
> Call Trace:
> [<c0103c8d>] show_trace_log_lvl+0x19/0x2e
> [<c0103d3f>] show_stack_log_lvl+0x9d/0xa5
> [<c0104083>] show_registers+0x1af/0x281
> [<c0104338>] die+0x11a/0x1e8
> [<c01138d1>] do_page_fault+0x632/0x715
> [<c04e7372>] error_code+0x72/0x80
> [<c016ce40>] show_vfsmnt+0x43/0x120
> [<c016f05d>] seq_read+0xf1/0x269
> [<c0159783>] vfs_read+0x90/0x10e
> [<c0159f9e>] sys_read+0x3f/0x63
> [<c0102876>] sysenter_past_esp+0x5f/0x89
> =======================
> Code: f0 ff ff 76 77 eb 7a 8b 55 ec 8b 02 89 c2 8b 4d ec 03 51 0c 89 f7 29 c7 89 79 0c 89 f0 29 d0 eb 6c 89 f8 88 06 46 eb 54 8b 55 f0 <8b> 3a 42 89 55 f0 89 f9 84 c9 74 d0 0f be d9 89 da 8b 45 08 e8
This looks like *exactly* the same thing, except you're in
"show_vfsmnt()" this time.
Again: the oopsing instruction (8b 3a) is "movl". And again, the address
is f6206ffe, and it oopses because the (incorrect) 32-bit access will
touch the next page, so you get a paging request fault on f6207000 - which
is some *totally* different allocation, and one that isn't mapped because
it doesn't exist, so DEBUG_PAGE_ALLOC has removed it.
.. and again: exact same thing.
> EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f6503f00
> BUG: unable to handle kernel paging request at virtual address f63d1000
> eax: f63d0ffe ebx: c2de0f50 ecx: 0000002c edx: f63d0ffe
> Code: .. <8b> 3a ..
.. and again:
> EIP: [<c016ecf1>] seq_path+0x60/0xca SS:ESP 0068:f6367f00
> BUG: unable to handle kernel paging request at virtual address f63d1000
> eax: f63d0ffe ebx: c2de0f50 ecx: 0000002c edx: f63d0ffe
> Code: .. <8b> 3a ..
And I can even tell you exactly what path it is:
- it's going to be the first path that shows up in the path list, since
the seq_file interface will re-use that page, so if you hit it, you'll
hit it on the first entry (unless seq_file has *lots* of data and needs
more than a single-page allocation)
- it must be a single-byte path, because otheriwse you'd have oopsed one
byte earlier (you'd have oopsed already on access .....ffd, which would
*also* overflow to the next page
- ergo, it's "/".
but that doesn't really even matter. Disassembling the code stream from
your oops shows clearly that it's a 32-bit access. No ifs, buts or maybes
about it. If you don't trust the gdb disassembly (I didn't, entirely, so I
looked it up) byte 0x8b is "mov Gv,Ev" in the Intel opcode map.
A 8-bit move would have been 0x8a.
Linus
* Ingo Molnar <[email protected]> wrote:
>
> * Linus Torvalds <[email protected]> wrote:
>
> > Your compiler generates
> >
> > movl -16(%ebp),%edx
> > movl (%edx),%edi /* this is _totally_ bogus! */
> > incl %edx
> > movl %edx,-16(%ebp)
> > movl %edi,%ecx
> > testb %cl,%cl
> > je ...
>
> ah, ok.
>
> > while I get (gcc version 4.1.2 20070925 (Red Hat 4.1.2-28)):
> >
> > movl -16(%ebp), %eax # p,
> > movzbl (%eax), %edi #, c /* not bogus! */
> > movl %edi, %edx # c,
> > testb %dl, %dl #
> > je .L64 #,
> > incl %eax #
> > movsbl %dl,%ebx #, D.12414
> > movl %eax, -16(%ebp) #, p
> >
> > where the difference (apart from doing the increment differently and
> > different register allocation) is that I have a "movzbl" (correct),
> > while you have a "movl" (pure and utter crap).
>
> i'll try with another compiler in a minute.
i just tried:
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
and indeed the crash is gone. So you are completely right, it's a
compiler bug in 4.0.2 (it's vanilla gcc 4.0.2 built by me, not a distro
compiler). It should not affect normal kernels too much this bug needs
CONFIG_DEBUG_PAGEALLOC. (or it needs a _really_ unlucky allocation being
at the far upper end of RAM - but those are usually taken up by
boot-time allocations anyway).
i also just re-tried the other config as well - and crash is gone there
too. (not surprisingly)
Ingo
On Wed, 3 Oct 2007, Alan Cox wrote:
>
> > and btw, there is no question what-so-ever about whether your compiler
> > might be doing a legal optimization - the compiler really is wrong, and is
>
> Pedant: valid. Almost all optimizations are legal, nobody has yet written
> laws about compilers. Sorry but I'm forever fixing misuse of the word
> "illegal" in printks, docs and the like and it gets annoying after a bit.
Heh.
When I'm ruler of the universe, it *will* be illegal. I'm just getting a
bit ahead of myself.
Linus
On Oct 3 2007 09:09, Linus Torvalds wrote:
>On Wed, 3 Oct 2007, Alan Cox wrote:
>>
>> > and btw, there is no question what-so-ever about whether your compiler
>> > might be doing a legal optimization - the compiler really is wrong, and is
>>
>> Pedant: valid. Almost all optimizations are legal, nobody has yet written
>> laws about compilers. Sorry but I'm forever fixing misuse of the word
>> "illegal" in printks, docs and the like and it gets annoying after a bit.
>
>Heh.
>
>When I'm ruler of the universe, it *will* be illegal. I'm just getting a
>bit ahead of myself.
Any time frame when that will happen?
On Wed, 3 Oct 2007, Jan Engelhardt wrote:
>
> >When I'm ruler of the universe, it *will* be illegal. I'm just getting a
> >bit ahead of myself.
>
> Any time frame when that will happen?
I'm working on it, I'm working on it. I'm just as frustrated as you are.
It turns out to be a non-trivial problem.
Linus
Linus Torvalds wrote:
> Doing it as early as possible in the 2.6.24-rc4 series (basically I'll do
> it first thing) will mean that we'll have the maximum amount of time to
> sort out any issues, and the thing is, Thomas and Ingo already have a tree
> ready to go, so people can check their work against that, and don't need
> to think that they have to do any fixups after it his *my* tree. It would
> be much better if everybody was just ready for it, and not taken by
> surprise.
I'm a bit confused... you typed 2.6.24-rc4; I'm guessing you meant
2.6.24-rc1, but did you mean
"x86 merge as soon as 2.6.23 is released" (merge window opens)
or
"x86 merge as soon as 2.6.24-rc1 is released"
?
Thanks,
Jeff
On Wed, 3 Oct 2007, Jeff Garzik wrote:
>
> I'm a bit confused... you typed 2.6.24-rc4; I'm guessing you meant
> 2.6.24-rc1, but did you mean
No, I just meant "2.6.24 merge window", so:
> "x86 merge as soon as 2.6.23 is released" (merge window opens)
is the correct interpretation.
It will probably be a day or two after the 2.6.23 release, just because I
like evertybody to look at the release tree after a release, but it would
be the first set of changes that get merged (assuming there are no stupid
brown-paper-bag issues that would get priority).
Linus
Subject: net, 9p: build fix with !CONFIG_SYSCTL
From: Ingo Molnar <[email protected]>
found via make randconfig build testing:
net/built-in.o: In function `init_p9':
mod.c:(.init.text+0x3b39): undefined reference to `p9_sysctl_register'
net/built-in.o: In function `exit_p9':
mod.c:(.exit.text+0x36b): undefined reference to `p9_sysctl_unregister'
Signed-off-by: Ingo Molnar <[email protected]>
---
include/net/9p/9p.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: linux/include/net/9p/9p.h
===================================================================
--- linux.orig/include/net/9p/9p.h
+++ linux/include/net/9p/9p.h
@@ -412,6 +412,18 @@ int p9_idpool_check(int id, struct p9_id
int p9_error_init(void);
int p9_errstr2errno(char *, int);
+
+#ifdef CONFIG_SYSCTL
int __init p9_sysctl_register(void);
void __exit p9_sysctl_unregister(void);
+#else
+static inline int p9_sysctl_register(void)
+{
+ return 0;
+}
+static inline void p9_sysctl_unregister(void)
+{
+}
+#endif
+
#endif /* NET_9P_H */
On Wed, Oct 03, 2007 at 08:11:05AM -0700, Linus Torvalds wrote:
>...
> and btw, there is no question what-so-ever about whether your compiler
> might be doing a legal optimization - the compiler really is wrong, and is
> total shit. You need to make a gcc bug-report.
>...
Ingo can't send a gcc bug-report since gcc 4.0 is no longer supported
upstream and a 4.1.2 compiler was confirmed to work.
Our only options are to either stop supporting the broken gcc versions
as compiler for the kernel or to work around this compiler bug in the
kernel.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On 10/4/07, Adrian Bunk <[email protected]> wrote:
> On Wed, Oct 03, 2007 at 08:11:05AM -0700, Linus Torvalds wrote:
> >...
> > and btw, there is no question what-so-ever about whether your compiler
> > might be doing a legal optimization - the compiler really is wrong, and is
> > total shit. You need to make a gcc bug-report.
> >...
>
> Ingo can't send a gcc bug-report since gcc 4.0 is no longer supported
> upstream and a 4.1.2 compiler was confirmed to work.
Ingo can upgrade to 4.0.4. :-)
> Our only options are to either stop supporting the broken gcc versions
> as compiler for the kernel or to work around this compiler bug in the
> kernel.
Distro can backport a fix for miscompilation while leaving, say,
__GNUC_MINOR__ intact, so banning version numbers aren't terribly
useful.
Perhaps, someone should write a script/test program to check for known
miscompilations. to cure himself from deprecation disease.
Alexey "make cc_check" Dobriyan
On Thu, 2007-10-04 at 19:05 +0200, Mathieu Chouquet-Stringer wrote:
> Hey there,
>
> I've seen the changes you made in commit b6a2fea39318 and I guess they
> might be responsible for my xargs breakage...
>
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long
/me tries
yep works like a charm, and that is a tree with a full git repo and
several build dirs in it.
> Which is kind of annoying but I can work around it though make distclean in
> my kernel tree dies with the same symptom (aka -E2BIG).
>
> I run a vanilla 2.6.23-rc9 (Linux version 2.6.23-rc9 (mchouque@shookaylt)
> (gcc version 4.1.2 20070925 (Red Hat 4.1.2-27)) #1 Tue Oct 2 08:13:47 EDT
> 2007) on FC7...
>
> Let me know if I can do anything. I'm going to try to bisect the problem
> after I recompile the kernel without this patch...
what happens if you up the stack limit to say 128M ?
Also, do you happen to have execve syscall audit stuff enabled?
On Thu, 4 Oct 2007, Mathieu Chouquet-Stringer wrote:
>
> I've seen the changes you made in commit b6a2fea39318 and I guess they
> might be responsible for my xargs breakage...
>
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long
What does your "ulimit -s" say?
I suspect that you might hit the code that limits execve() arguments to
one quarter of the maximum stack size.
We could change that from 25% to something else (half? three quarters?),
but if you really are hitting that limit, it sounds like you may have a
really small stack size to begin with (ie if 25% is smaller than the old
argument size limit of 128kB, you're running with a stack limit of less
than half a meg, which sounds pretty dang small).
So I'd like to verify that the stack limit really is the issue, and not
something else.
Linus
Hey there,
I've seen the changes you made in commit b6a2fea39318 and I guess they
might be responsible for my xargs breakage...
In the kernel source tree, if I run a stupid find | xargs ls, I now get
this:
xargs: ls: Argument list too long
Which is kind of annoying but I can work around it though make distclean in
my kernel tree dies with the same symptom (aka -E2BIG).
I run a vanilla 2.6.23-rc9 (Linux version 2.6.23-rc9 (mchouque@shookaylt)
(gcc version 4.1.2 20070925 (Red Hat 4.1.2-27)) #1 Tue Oct 2 08:13:47 EDT
2007) on FC7...
Let me know if I can do anything. I'm going to try to bisect the problem
after I recompile the kernel without this patch...
Best,
Mathieu
[email protected] (Linus Torvalds) writes:
> I said I was hoping that -rc8 was the last -rc, and I hate doing this, but
> we've had more changes since -rc8 than we had in -rc8. And while most of
> them are pretty trivial, I really couldn't face doing a 2.6.23 release and
> take the risk of some really stupid brown-paper-bag thing.
> [...]
--
Mathieu Chouquet-Stringer [email protected]
The sun itself sees not till heaven clears.
-- William Shakespeare --
On Thu, 4 Oct 2007, Mathieu Chouquet-Stringer wrote:
>
> Anything else you'd like me to try?
Well, since others definitely don't see this, including me, and I can do
things like 62MB exec arrays:
[torvalds@woody linux]$ echo $(find /home/torvalds/) | wc
1 883304 63000962
without getting any overflows (much less just on the kernel sources, which
is less than a megabyte of pathnames), I think it would be good if you
were to just instrument the kernel and make it do a "printk()" when it
returns E2BIG in fs/execve.c (or the NULL returns from get_arg_page()).
Just to figure out *which* test fails for you but apparently nobody else.
Linus
Thank you for getting back to me.
On Thu, Oct 04, 2007 at 10:27:52AM -0700, Linus Torvalds wrote:
> What does your "ulimit -s" say?
That's actually the first thing I checked.
mchouque - /usr/src/kernel/linux %ulimit -s
unlimited
And for the record, ulimit -a yields:
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) unlimited
-c: core file size (blocks) 0
-m: resident set size (kbytes) unlimited
-u: processes 16375
-n: file descriptors 1024
-l: locked-in-memory size (kb) 32
-v: address space (kb) unlimited
-x: file locks unlimited
-i: pending signals 16375
-q: bytes in POSIX msg queues 819200
-N 13: 0
-N 14: 0
> I suspect that you might hit the code that limits execve() arguments to
> one quarter of the maximum stack size.
>
> We could change that from 25% to something else (half? three quarters?),
> but if you really are hitting that limit, it sounds like you may have a
> really small stack size to begin with (ie if 25% is smaller than the old
> argument size limit of 128kB, you're running with a stack limit of less
> than half a meg, which sounds pretty dang small).
>
> So I'd like to verify that the stack limit really is the issue, and not
> something else.
Anything else you'd like me to try?
--
Mathieu Chouquet-Stringer [email protected]
The sun itself sees not till heaven clears.
-- William Shakespeare --
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote:
> /me tries
>
> yep works like a charm, and that is a tree with a full git repo and
> several build dirs in it.
Well, what can I say? ;-)
> what happens if you up the stack limit to say 128M ?
It's unlimited.
> Also, do you happen to have execve syscall audit stuff enabled?
Nope.
--
Mathieu Chouquet-Stringer [email protected]
The sun itself sees not till heaven clears.
-- William Shakespeare --
On 10/04/2007 01:05 PM, Mathieu Chouquet-Stringer wrote:
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long
>
Can you strace it to see what syscall is failing?
On Thu, Oct 04, 2007 at 05:50:00PM -0400, Chuck Ebbert wrote:
> On 10/04/2007 01:05 PM, Mathieu Chouquet-Stringer wrote:
> > In the kernel source tree, if I run a stupid find | xargs ls, I now get
> > this:
> > xargs: ls: Argument list too long
> >
>
> Can you strace it to see what syscall is failing?
Sure:
25789 <... execve resumed> ) = -1 E2BIG (Argument list too long)
I'm going to reboot to a kernel that has Linus' printks...
--
Mathieu Chouquet-Stringer [email protected]
The sun itself sees not till heaven clears.
-- William Shakespeare --
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote:
> what happens if you up the stack limit to say 128M ?
>
> Also, do you happen to have execve syscall audit stuff enabled?
Actually, you were right, not only it's enabled but it's also the
culprit. If I stop it, all is well...
Sorry for the noise.
--
Mathieu Chouquet-Stringer [email protected]
The sun itself sees not till heaven clears.
-- William Shakespeare --
Linus Torvalds writes:
> Well, since others definitely don't see this, including me, and I can do
> things like 62MB exec arrays:
>
> [torvalds@woody linux]$ echo $(find /home/torvalds/) | wc
> 1 883304 63000962
That wouldn't actually do an exec, assuming you're using bash, since
echo is a shell builtin in bash. You'd need to do /bin/echo.
Paul.
On Fri, 5 Oct 2007, Paul Mackerras wrote:
> Linus Torvalds writes:
> >
> > Well, since others definitely don't see this, including me, and I can do
> > things like 62MB exec arrays:
> >
> > [torvalds@woody linux]$ echo $(find /home/torvalds/) | wc
> > 1 883304 63000962
>
> That wouldn't actually do an exec, assuming you're using bash, since
> echo is a shell builtin in bash. You'd need to do /bin/echo.
Right you are, silly me. But yes, it works for me even with that (and
since I downloaded the gcc source tree, it now has six more megs of
arguments).
I also tested that "ulimit -s" seems to do the right thing for me.
I'm also assuming Mathieu is running x86 (or x86-64): HP-PA has a stack
that grows upwards, and that has traditionally been exciting.
IA64 also has some strange things for the register backing store.
Linus
On Thu, Oct 04, 2007 at 05:12:11PM -0700, Linus Torvalds wrote:
> I also tested that "ulimit -s" seems to do the right thing for me.
>
> I'm also assuming Mathieu is running x86 (or x86-64): HP-PA has a stack
> that grows upwards, and that has traditionally been exciting.
Correct, x86 it is but as I said it's this stupid auditd thing that
breaks the whole process. I'm gonna file a bug against it.
Thanks for the help though.
--
Mathieu Chouquet-Stringer [email protected]
The sun itself sees not till heaven clears.
-- William Shakespeare --
* Alistair John Strachan <[email protected]> wrote:
> On Tuesday 02 October 2007 04:41:49 Linus Torvalds wrote:
> [snip]
> > In other words, people who know they may be affected and would want to
> > prepare can look at (for example)
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
> >
> > and generally get ready for the switch-over.
>
> This is certainly a tool issue, but if I use Debian's kernel-image "make-kpkg"
> wrapper around the kernel build system, it fails with:
>
> cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
>
> Obviously, this file has moved to arch/x86/boot, but it seems like
> possibly unnecessary breakage. I've been copying bzImage for years
> from arch/x86_64/boot, and I'm sure there's a handful of scripts
> (other than Debian's kernel-image) doing this too.
>
> For now, I hacked the tool[1]. Maybe, if we care, a symlink could be
> set up between arch/x86/boot and arch/$ARCH/boot ? Or would papering
> over this be more trouble than it's worth?
yeah, a symlink is the right solution i think. Our first-step goal is to
make the switchover seamless for all practical purposes, and a
compatibility symlink in arch/i386/boot/ will not hurt. (we shouldnt
worry about the really old zImage target though)
Ingo
* Glauber de Oliveira Costa <[email protected]> wrote:
> On 10/2/07, Alistair John Strachan <[email protected]> wrote:
> > This is certainly a tool issue, but if I use Debian's kernel-image "make-kpkg"
> > wrapper around the kernel build system, it fails with:
> >
> > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
> >
> > Obviously, this file has moved to arch/x86/boot, but it seems like possibly
> > unnecessary breakage. I've been copying bzImage for years from
> > arch/x86_64/boot, and I'm sure there's a handful of scripts (other than
> > Debian's kernel-image) doing this too.
>
> I believe most sane tools would be using the output of uname -m, so a
> possible way to fix this would be fixing the data passed to userspace
> from uname. However, that might be the case that it creates a new set
> of problems too, with tools relying on the output of uname -m to
> determine wheter the machine is 32 or 64 bit, and so on.
there are two problems with the use of uname -m:
- the build machine architecture is not necessarily the same as the
target architecture. (for example i cross-compile all my 32-bit
kernels on a 64-bit box.)
- we kept uname -m compatile. multilib depends on it, and other pieces
of userspace as well. So uname -m still outputs 'i386' on 32-bit and
'x86_64' on 64-bit - not 'x86'.
a symlink looks like the best solution to me.
Ingo
> > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
> >
> > Obviously, this file has moved to arch/x86/boot, but it seems like
> > possibly unnecessary breakage. I've been copying bzImage for years
> > from arch/x86_64/boot, and I'm sure there's a handful of scripts
> > (other than Debian's kernel-image) doing this too.
> >
> > For now, I hacked the tool[1]. Maybe, if we care, a symlink could be
> > set up between arch/x86/boot and arch/$ARCH/boot ? Or would papering
> > over this be more trouble than it's worth?
>
> yeah, a symlink is the right solution i think. Our first-step goal is to
> make the switchover seamless for all practical purposes, and a
> compatibility symlink in arch/i386/boot/ will not hurt. (we shouldnt
> worry about the really old zImage target though)
But when can we then get rid of it?
This is a simple question about when we take the noise..
And right now people know we are shifting to x86 - so it makes
sense to let the dependent userspace tools take the pain now and not later.
Starting to fill up a build kernel with symlinks for compatibility with
random progarms seems to be the wrong approach.
Sam - that dislike especially the asm symlink
On Fri, 2007-10-05 at 05:22 +0200, Mathieu Chouquet-Stringer wrote:
> On Thu, Oct 04, 2007 at 05:12:11PM -0700, Linus Torvalds wrote:
> > I also tested that "ulimit -s" seems to do the right thing for me.
> >
> > I'm also assuming Mathieu is running x86 (or x86-64): HP-PA has a stack
> > that grows upwards, and that has traditionally been exciting.
>
> Correct, x86 it is but as I said it's this stupid auditd thing that
> breaks the whole process. I'm gonna file a bug against it.
Eric Paris just posted patches to solve this.
On Fri, 5 Oct 2007, Sam Ravnborg wrote:
> > > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
> > >
> > > Obviously, this file has moved to arch/x86/boot, but it seems like
> > > possibly unnecessary breakage. I've been copying bzImage for years
> > > from arch/x86_64/boot, and I'm sure there's a handful of scripts
> > > (other than Debian's kernel-image) doing this too.
> > >
> > > For now, I hacked the tool[1]. Maybe, if we care, a symlink could be
> > > set up between arch/x86/boot and arch/$ARCH/boot ? Or would papering
> > > over this be more trouble than it's worth?
> >
> > yeah, a symlink is the right solution i think. Our first-step goal is to
> > make the switchover seamless for all practical purposes, and a
> > compatibility symlink in arch/i386/boot/ will not hurt. (we shouldnt
> > worry about the really old zImage target though)
>
> But when can we then get rid of it?
> This is a simple question about when we take the noise..
> And right now people know we are shifting to x86 - so it makes
> sense to let the dependent userspace tools take the pain now and not later.
>
> Starting to fill up a build kernel with symlinks for compatibility with
> random progarms seems to be the wrong approach.
>
> Sam - that dislike especially the asm symlink
Sam,
I completely agree with you, but we want to keep the migration noise
as low as possible. Adding the symlink right now along with an entry
into features-removal.txt (6 month grace period) allows a smoother
transition. The distro folks should better get their gear together
until then.
tglx
Am Donnerstag, 4. Oktober 2007 19:05 schrieb Mathieu Chouquet-Stringer:
> Hey there,
>
> I've seen the changes you made in commit b6a2fea39318 and I guess they
> might be responsible for my xargs breakage...
>
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long
Have you tried to remove xarg from the equation above, just in case that it
stumbles upon the elemination of the reason for its existence in the first
place..
Pete
Am Samstag, 6. Oktober 2007 10:29 schrieb Hans-Peter Jansen:
> Am Donnerstag, 4. Oktober 2007 19:05 schrieb Mathieu Chouquet-Stringer:
> > Hey there,
> >
> > I've seen the changes you made in commit b6a2fea39318 and I guess they
> > might be responsible for my xargs breakage...
> >
> > In the kernel source tree, if I run a stupid find | xargs ls, I now get
> > this:
> > xargs: ls: Argument list too long
>
> Have you tried to remove xarg from the equation above, just in case that
> it stumbles upon the elemination of the reason for its existence in the
> first place..
Sorry guys, filtering by "linus" in kmail suppressed the solution messages
in this thread.
Pete
Mathieu Chouquet-Stringer wrote:
> Hey there,
>
> I've seen the changes you made in commit b6a2fea39318 and I guess they
> might be responsible for my xargs breakage...
>
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long
>
> Which is kind of annoying but I can work around it though make distclean in
> my kernel tree dies with the same symptom (aka -E2BIG).
>
You can work around it many ways, using the options provided for xargs
or using ls directly being among them.
find . -ls
I don't see it with 2.6.23-rc8-git3 so it may be related to xargs
version as well, I have 4.2.27 in FC6.
> I run a vanilla 2.6.23-rc9 (Linux version 2.6.23-rc9 (mchouque@shookaylt)
> (gcc version 4.1.2 20070925 (Red Hat 4.1.2-27)) #1 Tue Oct 2 08:13:47 EDT
> 2007) on FC7...
>
> Let me know if I can do anything. I'm going to try to bisect the problem
> after I recompile the kernel without this patch...
>
> Best,
> Mathieu
>
> [email protected] (Linus Torvalds) writes:
>> I said I was hoping that -rc8 was the last -rc, and I hate doing this, but
>> we've had more changes since -rc8 than we had in -rc8. And while most of
>> them are pretty trivial, I really couldn't face doing a 2.6.23 release and
>> take the risk of some really stupid brown-paper-bag thing.
>> [...]
>
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Friday 05 October 2007 09:32:40 you wrote:
> On Fri, 5 Oct 2007, Sam Ravnborg wrote:
> > > > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
> > > >
> > > > Obviously, this file has moved to arch/x86/boot, but it seems like
> > > > possibly unnecessary breakage. I've been copying bzImage for years
> > > > from arch/x86_64/boot, and I'm sure there's a handful of scripts
> > > > (other than Debian's kernel-image) doing this too.
> > > >
> > > > For now, I hacked the tool[1]. Maybe, if we care, a symlink could be
> > > > set up between arch/x86/boot and arch/$ARCH/boot ? Or would papering
> > > > over this be more trouble than it's worth?
> > >
> > > yeah, a symlink is the right solution i think. Our first-step goal is
> > > to make the switchover seamless for all practical purposes, and a
> > > compatibility symlink in arch/i386/boot/ will not hurt. (we shouldnt
> > > worry about the really old zImage target though)
> >
> > But when can we then get rid of it?
> > This is a simple question about when we take the noise..
> > And right now people know we are shifting to x86 - so it makes
> > sense to let the dependent userspace tools take the pain now and not
> > later.
> >
> > Starting to fill up a build kernel with symlinks for compatibility with
> > random progarms seems to be the wrong approach.
> >
> > Sam - that dislike especially the asm symlink
>
> Sam,
>
> I completely agree with you, but we want to keep the migration noise
> as low as possible. Adding the symlink right now along with an entry
> into features-removal.txt (6 month grace period) allows a smoother
> transition. The distro folks should better get their gear together
> until then.
I'll certainly file a bug report with the Debian BTS, but the fix will
probably involve something as abortive as my original patch.
How did the PPC merge handle this? I can't see any similar hacks in
kernel-image for these architectures.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
* Mel Gorman <[email protected]> wrote:
> Subject: Document profile=sleep requiring CONFIG_SCHEDSTATS
>
> profile=sleep only works if CONFIG_SCHEDSTATS is set. This patch notes
> the limitation in Documentation/kernel-parameters.txt and prints a
> warning at boot-time if profile=sleep is used without
> CONFIG_SCHEDSTAT.
>
> Signed-off-by: Mel Gorman <[email protected]>
thanks, applied.
Ingo