On Tue, Jan 15, 2008 at 11:14:09PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > > make ARCH=x86_64 allyesconfig
> > > will set CONFIG_64BIT for you - no?
> >
> > Yes.
> >
> > But this still leaves the fact that when someone says 'allyesconfig'
> > it's no longer
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > make ARCH=x86_64 allyesconfig
> > will set CONFIG_64BIT for you - no?
>
> Yes.
>
> But this still leaves the fact that when someone says 'allyesconfig'
> it's no longer clear which configuration he has. And no, I do not
> consider it funny that thi
On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
>...
> > > And I will add a config option to:
> > > - set -fno-unit-at-a-time
> >
> > I was told future gcc versions would remove that. Why do you
> > want it?
> Are there any better way to tell gcc no to inline so agressively?
I haven
On Tue, Jan 15, 2008 at 07:29:04PM +0100, Andi Kleen wrote:
> On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
> > With default options to gcc my .config produces ~65 warnings
> > but with -fno-unit-a-time I get 112 warnings.
> > Solely due to less inlining done by gcc.
> >
> > So the
On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
> With default options to gcc my .config produces ~65 warnings
> but with -fno-unit-a-time I get 112 warnings.
> Solely due to less inlining done by gcc.
>
> So there are two sources for the 'randomization':
> a) The actual config
> b)
> >
> > The plan is to let section mismatch warnings become errors
> > after the merge window - so we hit -mm first.
>
> A lot of those I look at seem to be not really bugs; also my
> impression is that they sometimes crop up randomly. e.g. you
> change something completely unrelated and suddenl
On Tue, Jan 15, 2008 at 06:11:46PM +0100, Andi Kleen wrote:
> On Tue, Jan 15, 2008 at 05:25:13PM +0100, Sam Ravnborg wrote:
> > On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
> > >
> > > * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > >
> > > > > find below the current set of warnings
On Tue, Jan 15, 2008 at 05:25:13PM +0100, Sam Ravnborg wrote:
> On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
> >
> > * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> >
> > > > find below the current set of warnings on -git. There are 62.
> > >
> > > The correct figure is 112.
> > >
>
On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
>
> * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > > find below the current set of warnings on -git. There are 62.
> >
> > The correct figure is 112.
> >
> > You need to do a:
> > make KCFLAGS=-fno-unit-at-a-time
> > build to see the
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > find below the current set of warnings on -git. There are 62.
>
> The correct figure is 112.
>
> You need to do a:
> make KCFLAGS=-fno-unit-at-a-time
> build to see them all.
btw., please add a .config option to trigger the -fno-unit-at-a-time
fla
On Mon, Jan 14, 2008 at 09:27:40PM +0100, Sam Ravnborg wrote:
> > > > Can you fix the bug that menuconfig does not let me enable CONFIG_64BIT?
> > >
> > > make ARCH=x86_64 allyesconfig
> > > will set CONFIG_64BIT for you - no?
> >
> > Yes.
> >
> > But this still leaves the fact that when someone
> > > Can you fix the bug that menuconfig does not let me enable CONFIG_64BIT?
> >
> > make ARCH=x86_64 allyesconfig
> > will set CONFIG_64BIT for you - no?
>
> Yes.
>
> But this still leaves the fact that when someone says 'allyesconfig'
> it's no longer clear which configuration he has.
Assum
On Mon, Jan 14, 2008 at 09:01:26PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 14, 2008 at 09:52:58PM +0200, Adrian Bunk wrote:
> > On Mon, Jan 14, 2008 at 08:10:09PM +0100, Ingo Molnar wrote:
> > >
> > > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > > > for example, in current -git, could yo
On Mon, Jan 14, 2008 at 04:24:40PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > also, in theory we've got a pretty reliable set of the following
> > information:
> >
> > function X references symbol Y
> >
> > and we know what type of sections they are in, righ
On Mon, Jan 14, 2008 at 09:52:58PM +0200, Adrian Bunk wrote:
> On Mon, Jan 14, 2008 at 08:10:09PM +0100, Ingo Molnar wrote:
> >
> > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > > for example, in current -git, could you tell me why this triggers:
> > > >
> > > > WARNING: vmlinux.o(.text+0x
On Mon, Jan 14, 2008 at 04:01:03PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Would be great to have them automated - just dunno how to do it. Do
> > > you see a feasible way to do it?
> >
> > a good starting point would be to make the warnings a lot more
>
On Mon, Jan 14, 2008 at 08:10:09PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > > for example, in current -git, could you tell me why this triggers:
> > >
> > > WARNING: vmlinux.o(.text+0x87e2a): Section mismatch: reference to
> > > .init.text: (betwee
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > for example, in current -git, could you tell me why this triggers:
> >
> > WARNING: vmlinux.o(.text+0x87e2a): Section mismatch: reference to
> > .init.text: (between 'process_zones' and 'setup_per_cpu_pageset')
> >
> > and how to resolve
On Mon, Jan 14, 2008 at 04:01:03PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Would be great to have them automated - just dunno how to do it. Do
> > > you see a feasible way to do it?
> >
> > a good starting point would be to make the warnings a lot more
>
On Mon, Jan 14, 2008 at 03:58:54PM +0100, Ingo Molnar wrote:
>...
> a good way i see is to:
>...
> - quickly reach a close-to-100%-perfect stage, brute-force. Drop
>__init* annotations en masse if they are not perfectly layered.
>Whoever reintroduces them will then have to do it perfectl
On Mon, Jan 14, 2008 at 02:52:40PM +0100, Ingo Molnar wrote:
>...
> but longer-term, shouldnt these annotations be automated? We'll see a
> constant stream of them, all around the clock as people regularly get it
> wrong (because it's not intuitive).
Definitely.
Even more when you looking at wh
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> also, in theory we've got a pretty reliable set of the following
> information:
>
> function X references symbol Y
>
> and we know what type of sections they are in, right?
>
> could -ffunction-sections be used to delay the categorization of
> fun
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Would be great to have them automated - just dunno how to do it. Do
> > you see a feasible way to do it?
>
> a good starting point would be to make the warnings a lot more
> self-explanatory. Right now it's often non-obvious trying to figure
> out
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Would be great to have them automated - just dunno how to do it. Do
> > you see a feasible way to do it?
>
> a good starting point would be to make the warnings a lot more
> self-explanatory. Right now it's often non-obvious trying to figure
> out
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > ok, i've dropped this patch from x86.git for now:
> >
> > Subject: x86: force __cpuinit on for CONFIG_PM without HOTPLUG_CPU
> > From: Andi Kleen <[EMAIL PROTECTED]>
> >
> > but longer-term, shouldnt these annotations be automated? We'll see
> >
On Mon, Jan 14, 2008 at 02:52:40PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
> > > Adrian Bunk <[EMAIL PROTECTED]> writes:
> > > >
> > > > Technically you are the one who has to deal with problems in yo
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
> > Adrian Bunk <[EMAIL PROTECTED]> writes:
> > >
> > > Technically you are the one who has to deal with problems in your
> > > patches, not the people pointing at the problems.
> >
> > If you
On Thursday, 10 of January 2008, Andi Kleen wrote:
> On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
> > On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > > > But your patch does:
> > > >
> > > > +config PM_CPUINIT
> > > > + bool
> > > > + depends on PM
> > >
> >
[Sorry for not replying earlier, I missed your message.]
On Friday, 4 of January 2008, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > So you would need to fix that first. Would be fine for me, but is
> > > out of scope for my patch.
> >
> > OK, I'll fix that up l
On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
> >
> > Technically you are the one who has to deal with problems in your
> > patches, not the people pointing at the problems.
>
> If you believe that my patch adds a new problem then please des
Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> Technically you are the one who has to deal with problems in your
> patches, not the people pointing at the problems.
If you believe that my patch adds a new problem then please describe
it clearly so that I can understand it.
-Andi
--
To unsubscribe f
On Thu, Jan 10, 2008 at 12:42:53PM +0100, Andi Kleen wrote:
> On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
> > On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > > > But your patch does:
> > > >
> > > > +config PM_CPUINIT
> > > > + bool
> > > > + depends on PM
>
On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
> On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > > But your patch does:
> > >
> > > +config PM_CPUINIT
> > > + bool
> > > + depends on PM
> >
> > That is because arch/x86/power/cpu.c where this happens is current
On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > But your patch does:
> >
> > +config PM_CPUINIT
> > + bool
> > + depends on PM
>
> That is because arch/x86/power/cpu.c where this happens is currently
>
> obj-$(CONFIG_PM)+= cpu.o
>
> If it was changed
> But your patch does:
>
> +config PM_CPUINIT
> + bool
> + depends on PM
That is because arch/x86/power/cpu.c where this happens is currently
obj-$(CONFIG_PM)+= cpu.o
If it was changed to CONFIG_something else then yes that dependency
should be changed too.
-Andi
--
On Thu, Jan 10, 2008 at 10:58:57AM +0100, Andi Kleen wrote:
> > It seems the correct solution would be not to hijack __cpuinit
> > (as your patch does), but to create a new annotation.
>
> The rationale is that after suspend the CPU has to be reinitialized.
> That is because it is essentially like
> It seems the correct solution would be not to hijack __cpuinit
> (as your patch does), but to create a new annotation.
The rationale is that after suspend the CPU has to be reinitialized.
That is because it is essentially like a reboot. All the previous
CPU state is gone.
It doesn't need to tou
On Thu, Jan 03, 2008 at 07:43:43PM +0100, Andi Kleen wrote:
> On Thursday 03 January 2008 19:14:38 Adrian Bunk wrote:
> > On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
> > >
> > > This avoids the requirement to mark a lot of initialization functions not
> > > __cpuinit just for resu
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > So you would need to fix that first. Would be fine for me, but is
> > out of scope for my patch.
>
> OK, I'll fix that up later.
i'll apply Andi's patch to x86.git - or would like to maintain that
patch?
Ingo
--
To unsubscribe from t
On Thursday, 3 of January 2008, Andi Kleen wrote:
>
> > > +config PM_CPUINIT
> > > + bool
> > > + depends on PM
> >
> > Please make it PM_SLEEP (PM is more than suspend/hibernation).
>
> That was something that irritated me too while writing the patch, but the
> functions I
> am interested in
On Thursday 03 January 2008 19:14:38 Adrian Bunk wrote:
> On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
> >
> > This avoids the requirement to mark a lot of initialization functions not
> > __cpuinit just for resume from RAM.
> >
> > More functions could be converted now, didn't do
On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
>
> This avoids the requirement to mark a lot of initialization functions not
> __cpuinit just for resume from RAM.
>
> More functions could be converted now, didn't do all.
>...
Shouldn't this aready be handled by the following?
conf
> > +config PM_CPUINIT
> > + bool
> > + depends on PM
>
> Please make it PM_SLEEP (PM is more than suspend/hibernation).
That was something that irritated me too while writing the patch, but the
functions I
am interested in with this are referenced from arch/x86/power/cpu.c and that is
o
On Thursday, 3 of January 2008, Andi Kleen wrote:
>
> This avoids the requirement to mark a lot of initialization functions not
> __cpuinit just for resume from RAM.
>
> More functions could be converted now, didn't do all.
>
> Cc: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
>
> Signed-off-by: A
This avoids the requirement to mark a lot of initialization functions not
__cpuinit just for resume from RAM.
More functions could be converted now, didn't do all.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/Kconfig|
45 matches
Mail list logo
