Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Russell King]

On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com wrote:
> I was building a kernel for an iPaq {SA1110} and ran into this.
> 
> linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
> Has a: #include <linux/cpufreq.h>
> Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
> defined(CONFIG_CPU_FREQ_SA1110)
> who's else section redefines the cpufreq_get function inhereited from
> the header....
> 
> I'm guessing no one ever ended up in the "else" section until now, and
> that the header was added some time ago and no one caught this.
> This patch worked for me to get rid of the compile time problems.  I'm
> having issues with the kernel, but as far as I can tell they are form
> the Frame buffer and not because of this.  If this assessment is correct
> {the not needing this code anymore} then please pass this along so it
> makes it into an upcoming release.
> 
> --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
> 17:36:21.000000000 -0500
> +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
> 17:40:02.000000000 -0500
> @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
>         return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  }
> 
> -#else
> -/*
> - * We still need to provide this so building without cpufreq works.
> - */
> -unsigned int cpufreq_get(unsigned int cpu)
> -{
> -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
> -}
> -EXPORT_SYMBOL(cpufreq_get);
>  #endif
> 
>  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel
clock divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_get(unsigned int cpu);
#else
static inline unsigned int cpufreq_quick_get(unsigned int cpu)
{
        return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu)
{
        return 0;
}
#endif

which utterly bogus.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Dave Jones]

On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
 > On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com wrote:
 > > I was building a kernel for an iPaq {SA1110} and ran into this.
 > > 
 > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 > > Has a: #include <linux/cpufreq.h>
 > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 > > defined(CONFIG_CPU_FREQ_SA1110)
 > > who's else section redefines the cpufreq_get function inhereited from
 > > the header....
 > > 
 > > I'm guessing no one ever ended up in the "else" section until now, and
 > > that the header was added some time ago and no one caught this.
 > > This patch worked for me to get rid of the compile time problems.  I'm
 > > having issues with the kernel, but as far as I can tell they are form
 > > the Frame buffer and not because of this.  If this assessment is correct
 > > {the not needing this code anymore} then please pass this along so it
 > > makes it into an upcoming release.
 > > 
 > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
 > > 17:36:21.000000000 -0500
 > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
 > > 17:40:02.000000000 -0500
 > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 > >         return cclk_frequency_100khz[PPCR & 0xf] * 100;
 > >  }
 > > 
 > > -#else
 > > -/*
 > > - * We still need to provide this so building without cpufreq works.
 > > - */
 > > -unsigned int cpufreq_get(unsigned int cpu)
 > > -{
 > > -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
 > > -}
 > > -EXPORT_SYMBOL(cpufreq_get);
 > >  #endif
 > > 
 > >  /*
 > 
 > No.  That code is required - the StrongARM 1100 framebuffer driver
 > *needs* to know what the CPU frequency is so it can set the pixel
 > clock divisor.
 > 
 > The real problem is the silly people who added this to cpufreq.h:
 > 
 > #ifdef CONFIG_CPU_FREQ
 > unsigned int cpufreq_quick_get(unsigned int cpu);
 > unsigned int cpufreq_get(unsigned int cpu);
 > #else
 > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
 > {
 >         return 0;
 > }
 > static inline unsigned int cpufreq_get(unsigned int cpu)
 > {
 >         return 0;
 > }
 > #endif
 > 
 > which utterly bogus.

Which came from ...

commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Wed May 2 19:27:08 2007 +0200

    [PATCH] x86-64: fix x86_64-mm-sched-clock-share
    
    Fix for the following patch. Provide dummy cpufreq functions when
    CPUFREQ is not compiled in.
    
    Cc: Andi Kleen <ak@suse.de>
    Cc: Dave Jones <davej@codemonkey.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Andi Kleen <ak@suse.de>

I don't remember seeing any problem here, so I'm not entirely sure what
this was supposed to be fixing.  Perhaps the -mm-esque patch name
will provide Andrew/Andi clues. It lacks sufficient information for
my brain to guess what the problem was.

"Fix for the following patch" is also something that really should
never be added to a git changelog too, because 'next' means absolutely
nothing to me, nor I expect 99% of changelog readers.


Cc's added.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Dave Jones]

On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
 > On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com wrote:
 > > I was building a kernel for an iPaq {SA1110} and ran into this.
 > > 
 > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 > > Has a: #include <linux/cpufreq.h>
 > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 > > defined(CONFIG_CPU_FREQ_SA1110)
 > > who's else section redefines the cpufreq_get function inhereited from
 > > the header....
 > > 
 > > I'm guessing no one ever ended up in the "else" section until now, and
 > > that the header was added some time ago and no one caught this.
 > > This patch worked for me to get rid of the compile time problems.  I'm
 > > having issues with the kernel, but as far as I can tell they are form
 > > the Frame buffer and not because of this.  If this assessment is correct
 > > {the not needing this code anymore} then please pass this along so it
 > > makes it into an upcoming release.
 > > 
 > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
 > > 17:36:21.000000000 -0500
 > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
 > > 17:40:02.000000000 -0500
 > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 > >         return cclk_frequency_100khz[PPCR & 0xf] * 100;
 > >  }
 > > 
 > > -#else
 > > -/*
 > > - * We still need to provide this so building without cpufreq works.
 > > - */
 > > -unsigned int cpufreq_get(unsigned int cpu)
 > > -{
 > > -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
 > > -}
 > > -EXPORT_SYMBOL(cpufreq_get);
 > >  #endif
 > > 
 > >  /*
 > 
 > No.  That code is required - the StrongARM 1100 framebuffer driver
 > *needs* to know what the CPU frequency is so it can set the pixel
 > clock divisor.
 > 
 > The real problem is the silly people who added this to cpufreq.h:
 > 
 > #ifdef CONFIG_CPU_FREQ
 > unsigned int cpufreq_quick_get(unsigned int cpu);
 > unsigned int cpufreq_get(unsigned int cpu);
 > #else
 > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
 > {
 >         return 0;
 > }
 > static inline unsigned int cpufreq_get(unsigned int cpu)
 > {
 >         return 0;
 > }
 > #endif
 > 
 > which utterly bogus.

Which came from ...

commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Wed May 2 19:27:08 2007 +0200

    [PATCH] x86-64: fix x86_64-mm-sched-clock-share
    
    Fix for the following patch. Provide dummy cpufreq functions when
    CPUFREQ is not compiled in.
    
    Cc: Andi Kleen <ak@suse.de>
    Cc: Dave Jones <davej@codemonkey.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Andi Kleen <ak@suse.de>

I don't remember seeing any problem here, so I'm not entirely sure what
this was supposed to be fixing.  Perhaps the -mm-esque patch name
will provide Andrew/Andi clues. It lacks sufficient information for
my brain to guess what the problem was.

"Fix for the following patch" is also something that really should
never be added to a git changelog too, because 'next' means absolutely
nothing to me, nor I expect 99% of changelog readers.


Cc's added.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Andrew Morton]

On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <davej@redhat.com> wrote:

> On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
>  > On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com wrote:
>  > > I was building a kernel for an iPaq {SA1110} and ran into this.
>  > > 
>  > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
>  > > Has a: #include <linux/cpufreq.h>
>  > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
>  > > defined(CONFIG_CPU_FREQ_SA1110)
>  > > who's else section redefines the cpufreq_get function inhereited from
>  > > the header....
>  > > 
>  > > I'm guessing no one ever ended up in the "else" section until now, and
>  > > that the header was added some time ago and no one caught this.
>  > > This patch worked for me to get rid of the compile time problems.  I'm
>  > > having issues with the kernel, but as far as I can tell they are form
>  > > the Frame buffer and not because of this.  If this assessment is correct
>  > > {the not needing this code anymore} then please pass this along so it
>  > > makes it into an upcoming release.
>  > > 
>  > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
>  > > 17:36:21.000000000 -0500
>  > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
>  > > 17:40:02.000000000 -0500
>  > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
>  > >         return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  > >  }
>  > > 
>  > > -#else
>  > > -/*
>  > > - * We still need to provide this so building without cpufreq works.
>  > > - */
>  > > -unsigned int cpufreq_get(unsigned int cpu)
>  > > -{
>  > > -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  > > -}
>  > > -EXPORT_SYMBOL(cpufreq_get);
>  > >  #endif
>  > > 
>  > >  /*
>  > 
>  > No.  That code is required - the StrongARM 1100 framebuffer driver
>  > *needs* to know what the CPU frequency is so it can set the pixel
>  > clock divisor.
>  > 
>  > The real problem is the silly people who added this to cpufreq.h:
>  > 
>  > #ifdef CONFIG_CPU_FREQ
>  > unsigned int cpufreq_quick_get(unsigned int cpu);
>  > unsigned int cpufreq_get(unsigned int cpu);
>  > #else
>  > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
>  > {
>  >         return 0;
>  > }
>  > static inline unsigned int cpufreq_get(unsigned int cpu)
>  > {
>  >         return 0;
>  > }
>  > #endif
>  > 
>  > which utterly bogus.
> 
> Which came from ...
> 
> commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
> Author: Andrew Morton <akpm@linux-foundation.org>
> Date:   Wed May 2 19:27:08 2007 +0200
> 
>     [PATCH] x86-64: fix x86_64-mm-sched-clock-share
>     
>     Fix for the following patch. Provide dummy cpufreq functions when
>     CPUFREQ is not compiled in.
>     
>     Cc: Andi Kleen <ak@suse.de>
>     Cc: Dave Jones <davej@codemonkey.org.uk>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Andi Kleen <ak@suse.de>
> 
> I don't remember seeing any problem here, so I'm not entirely sure what
> this was supposed to be fixing.  Perhaps the -mm-esque patch name
> will provide Andrew/Andi clues. It lacks sufficient information for
> my brain to guess what the problem was.

Oh geeze.  sched-clock-share went through about 18 different versions, was
merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
this mess the above fix was inserted, sorry.

> "Fix for the following patch" is also something that really should
> never be added to a git changelog too, because 'next' means absolutely
> nothing to me, nor I expect 99% of changelog readers.

184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
actually.  I intended that Andi fold it into the base patch prior to
sending it to Linus.  He normally does that, but it looks like this
one was handled as a standalone commit for some reason.

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Andrew Morton]

On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <davej@redhat.com> wrote:

> On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
>  > On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com wrote:
>  > > I was building a kernel for an iPaq {SA1110} and ran into this.
>  > > 
>  > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
>  > > Has a: #include <linux/cpufreq.h>
>  > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
>  > > defined(CONFIG_CPU_FREQ_SA1110)
>  > > who's else section redefines the cpufreq_get function inhereited from
>  > > the header....
>  > > 
>  > > I'm guessing no one ever ended up in the "else" section until now, and
>  > > that the header was added some time ago and no one caught this.
>  > > This patch worked for me to get rid of the compile time problems.  I'm
>  > > having issues with the kernel, but as far as I can tell they are form
>  > > the Frame buffer and not because of this.  If this assessment is correct
>  > > {the not needing this code anymore} then please pass this along so it
>  > > makes it into an upcoming release.
>  > > 
>  > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
>  > > 17:36:21.000000000 -0500
>  > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
>  > > 17:40:02.000000000 -0500
>  > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
>  > >         return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  > >  }
>  > > 
>  > > -#else
>  > > -/*
>  > > - * We still need to provide this so building without cpufreq works.
>  > > - */
>  > > -unsigned int cpufreq_get(unsigned int cpu)
>  > > -{
>  > > -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  > > -}
>  > > -EXPORT_SYMBOL(cpufreq_get);
>  > >  #endif
>  > > 
>  > >  /*
>  > 
>  > No.  That code is required - the StrongARM 1100 framebuffer driver
>  > *needs* to know what the CPU frequency is so it can set the pixel
>  > clock divisor.
>  > 
>  > The real problem is the silly people who added this to cpufreq.h:
>  > 
>  > #ifdef CONFIG_CPU_FREQ
>  > unsigned int cpufreq_quick_get(unsigned int cpu);
>  > unsigned int cpufreq_get(unsigned int cpu);
>  > #else
>  > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
>  > {
>  >         return 0;
>  > }
>  > static inline unsigned int cpufreq_get(unsigned int cpu)
>  > {
>  >         return 0;
>  > }
>  > #endif
>  > 
>  > which utterly bogus.
> 
> Which came from ...
> 
> commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
> Author: Andrew Morton <akpm@linux-foundation.org>
> Date:   Wed May 2 19:27:08 2007 +0200
> 
>     [PATCH] x86-64: fix x86_64-mm-sched-clock-share
>     
>     Fix for the following patch. Provide dummy cpufreq functions when
>     CPUFREQ is not compiled in.
>     
>     Cc: Andi Kleen <ak@suse.de>
>     Cc: Dave Jones <davej@codemonkey.org.uk>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Andi Kleen <ak@suse.de>
> 
> I don't remember seeing any problem here, so I'm not entirely sure what
> this was supposed to be fixing.  Perhaps the -mm-esque patch name
> will provide Andrew/Andi clues. It lacks sufficient information for
> my brain to guess what the problem was.

Oh geeze.  sched-clock-share went through about 18 different versions, was
merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
this mess the above fix was inserted, sorry.

> "Fix for the following patch" is also something that really should
> never be added to a git changelog too, because 'next' means absolutely
> nothing to me, nor I expect 99% of changelog readers.

184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
actually.  I intended that Andi fold it into the base patch prior to
sending it to Linus.  He normally does that, but it looks like this
one was handled as a standalone commit for some reason.

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Dave Jones]

On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
 > On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <davej@redhat.com> wrote:
 > > 
 > > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
 > > Author: Andrew Morton <akpm@linux-foundation.org>
 > > Date:   Wed May 2 19:27:08 2007 +0200
 > > 
 > >     [PATCH] x86-64: fix x86_64-mm-sched-clock-share
 > >     
 > >     Fix for the following patch. Provide dummy cpufreq functions when
 > >     CPUFREQ is not compiled in.
 > >     
 > >     Cc: Andi Kleen <ak@suse.de>
 > >     Cc: Dave Jones <davej@codemonkey.org.uk>
 > >     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 > >     Signed-off-by: Andi Kleen <ak@suse.de>
 > > 
 > > I don't remember seeing any problem here, so I'm not entirely sure what
 > > this was supposed to be fixing.  Perhaps the -mm-esque patch name
 > > will provide Andrew/Andi clues. It lacks sufficient information for
 > > my brain to guess what the problem was.
 > 
 > Oh geeze.  sched-clock-share went through about 18 different versions, was
 > merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
 > this mess the above fix was inserted, sorry.
 > 
 > > "Fix for the following patch" is also something that really should
 > > never be added to a git changelog too, because 'next' means absolutely
 > > nothing to me, nor I expect 99% of changelog readers.
 > 
 > 184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
 > actually.  I intended that Andi fold it into the base patch prior to
 > sending it to Linus.  He normally does that, but it looks like this
 > one was handled as a standalone commit for some reason.

So lets see what happens if we revert it ?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Andrew Morton]

On Tue, 25 Sep 2007 12:58:34 -0400 Dave Jones <davej@redhat.com> wrote:

> On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
>  > On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <davej@redhat.com> wrote:
>  > > 
>  > > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
>  > > Author: Andrew Morton <akpm@linux-foundation.org>
>  > > Date:   Wed May 2 19:27:08 2007 +0200
>  > > 
>  > >     [PATCH] x86-64: fix x86_64-mm-sched-clock-share
>  > >     
>  > >     Fix for the following patch. Provide dummy cpufreq functions when
>  > >     CPUFREQ is not compiled in.
>  > >     
>  > >     Cc: Andi Kleen <ak@suse.de>
>  > >     Cc: Dave Jones <davej@codemonkey.org.uk>
>  > >     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>  > >     Signed-off-by: Andi Kleen <ak@suse.de>
>  > > 
>  > > I don't remember seeing any problem here, so I'm not entirely sure what
>  > > this was supposed to be fixing.  Perhaps the -mm-esque patch name
>  > > will provide Andrew/Andi clues. It lacks sufficient information for
>  > > my brain to guess what the problem was.
>  > 
>  > Oh geeze.  sched-clock-share went through about 18 different versions, was
>  > merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
>  > this mess the above fix was inserted, sorry.
>  > 
>  > > "Fix for the following patch" is also something that really should
>  > > never be added to a git changelog too, because 'next' means absolutely
>  > > nothing to me, nor I expect 99% of changelog readers.
>  > 
>  > 184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
>  > actually.  I intended that Andi fold it into the base patch prior to
>  > sending it to Linus.  He normally does that, but it looks like this
>  > one was handled as a standalone commit for some reason.
> 
> So lets see what happens if we revert it ?
> 

<grep flurry>

OK, here: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch

So I guess what we want to do here is to revert that patch, test i386
allnoconfig and then fix up anything which breaks.

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Andrew Morton]

On Tue, 25 Sep 2007 12:58:34 -0400 Dave Jones <davej@redhat.com> wrote:

> On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
>  > On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <davej@redhat.com> wrote:
>  > > 
>  > > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
>  > > Author: Andrew Morton <akpm@linux-foundation.org>
>  > > Date:   Wed May 2 19:27:08 2007 +0200
>  > > 
>  > >     [PATCH] x86-64: fix x86_64-mm-sched-clock-share
>  > >     
>  > >     Fix for the following patch. Provide dummy cpufreq functions when
>  > >     CPUFREQ is not compiled in.
>  > >     
>  > >     Cc: Andi Kleen <ak@suse.de>
>  > >     Cc: Dave Jones <davej@codemonkey.org.uk>
>  > >     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>  > >     Signed-off-by: Andi Kleen <ak@suse.de>
>  > > 
>  > > I don't remember seeing any problem here, so I'm not entirely sure what
>  > > this was supposed to be fixing.  Perhaps the -mm-esque patch name
>  > > will provide Andrew/Andi clues. It lacks sufficient information for
>  > > my brain to guess what the problem was.
>  > 
>  > Oh geeze.  sched-clock-share went through about 18 different versions, was
>  > merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
>  > this mess the above fix was inserted, sorry.
>  > 
>  > > "Fix for the following patch" is also something that really should
>  > > never be added to a git changelog too, because 'next' means absolutely
>  > > nothing to me, nor I expect 99% of changelog readers.
>  > 
>  > 184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
>  > actually.  I intended that Andi fold it into the base patch prior to
>  > sending it to Linus.  He normally does that, but it looks like this
>  > one was handled as a standalone commit for some reason.
> 
> So lets see what happens if we revert it ?
> 

<grep flurry>

OK, here: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch

So I guess what we want to do here is to revert that patch, test i386
allnoconfig and then fix up anything which breaks.

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Dave Jones]

On Tue, Sep 25, 2007 at 10:08:39AM -0700, Andrew Morton wrote:
 > On Tue, 25 Sep 2007 12:58:34 -0400 Dave Jones <davej@redhat.com> wrote:
 > 
 > > On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
 > >  > On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <davej@redhat.com> wrote:
 > >  > > 
 > >  > > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
 > >  > > Author: Andrew Morton <akpm@linux-foundation.org>
 > >  > > Date:   Wed May 2 19:27:08 2007 +0200
 > >  > > 
 > >  > >     [PATCH] x86-64: fix x86_64-mm-sched-clock-share
 > >  > >     
 > >  > >     Fix for the following patch. Provide dummy cpufreq functions when
 > >  > >     CPUFREQ is not compiled in.
 > >  > >     
 > >  > >     Cc: Andi Kleen <ak@suse.de>
 > >  > >     Cc: Dave Jones <davej@codemonkey.org.uk>
 > >  > >     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 > >  > >     Signed-off-by: Andi Kleen <ak@suse.de>
 > >  > > 
 > >  > > I don't remember seeing any problem here, so I'm not entirely sure what
 > >  > > this was supposed to be fixing.  Perhaps the -mm-esque patch name
 > >  > > will provide Andrew/Andi clues. It lacks sufficient information for
 > >  > > my brain to guess what the problem was.
 > >  > 
 > >  > Oh geeze.  sched-clock-share went through about 18 different versions, was
 > >  > merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
 > >  > this mess the above fix was inserted, sorry.
 > >  > 
 > >  > > "Fix for the following patch" is also something that really should
 > >  > > never be added to a git changelog too, because 'next' means absolutely
 > >  > > nothing to me, nor I expect 99% of changelog readers.
 > >  > 
 > >  > 184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
 > >  > actually.  I intended that Andi fold it into the base patch prior to
 > >  > sending it to Linus.  He normally does that, but it looks like this
 > >  > one was handled as a standalone commit for some reason.
 > > 
 > > So lets see what happens if we revert it ?
 > > 
 > 
 > <grep flurry>
 > 
 > OK, here: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
 > 
 > So I guess what we want to do here is to revert that patch, test i386
 > allnoconfig and then fix up anything which breaks.

Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
(which should be the same as a native build).

The functions that complain in that patch header don't seem to actually
exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
Did this patch perhaps jump the gun, and these are -mm only ?

	Dave

-- 
http://www.codemonkey.org.uk

RE: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Greg.Chandler]

Well then, now I guess I know why the FB isn't working...
Sorry to open up the can of worms this turned out to be {after reading
all the other replies first}...

 

-----Original Message-----
From: Russell King [mailto:rmk@arm.linux.org.uk] On Behalf Of Russell
King
Sent: Tuesday, September 25, 2007 2:32 AM
To: Chandler, Greg; cpufreq@lists.linux.org.uk; davej@redhat.com
Cc: linux-kernel@vger.kernel.org; dan.j.williams@intel.com
Subject: Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more}
ARM/StrongARM

On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com
wrote:
> I was building a kernel for an iPaq {SA1110} and ran into this.
> 
> linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
> Has a: #include <linux/cpufreq.h>
> Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
> defined(CONFIG_CPU_FREQ_SA1110)
> who's else section redefines the cpufreq_get function inhereited from 
> the header....
> 
> I'm guessing no one ever ended up in the "else" section until now, and

> that the header was added some time ago and no one caught this.
> This patch worked for me to get rid of the compile time problems.  I'm

> having issues with the kernel, but as far as I can tell they are form 
> the Frame buffer and not because of this.  If this assessment is 
> correct {the not needing this code anymore} then please pass this 
> along so it makes it into an upcoming release.
> 
> --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24 
> 17:36:21.000000000 -0500
> +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
> 17:40:02.000000000 -0500
> @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
>         return cclk_frequency_100khz[PPCR & 0xf] * 100;  }
> 
> -#else
> -/*
> - * We still need to provide this so building without cpufreq works.
> - */
> -unsigned int cpufreq_get(unsigned int cpu) -{
> -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
> -}
> -EXPORT_SYMBOL(cpufreq_get);
>  #endif
> 
>  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel clock
divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu); unsigned int
cpufreq_get(unsigned int cpu); #else static inline unsigned int
cpufreq_quick_get(unsigned int cpu) {
        return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu) {
        return 0;
}
#endif

which utterly bogus.

--
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

RE: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Greg.Chandler]

Well then, now I guess I know why the FB isn't working...
Sorry to open up the can of worms this turned out to be {after reading
all the other replies first}...

 

-----Original Message-----
From: Russell King [mailto:rmk@arm.linux.org.uk] On Behalf Of Russell
King
Sent: Tuesday, September 25, 2007 2:32 AM
To: Chandler, Greg; cpufreq@lists.linux.org.uk; davej@redhat.com
Cc: linux-kernel@vger.kernel.org; dan.j.williams@intel.com
Subject: Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more}
ARM/StrongARM

On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com
wrote:
> I was building a kernel for an iPaq {SA1110} and ran into this.
> 
> linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
> Has a: #include <linux/cpufreq.h>
> Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
> defined(CONFIG_CPU_FREQ_SA1110)
> who's else section redefines the cpufreq_get function inhereited from 
> the header....
> 
> I'm guessing no one ever ended up in the "else" section until now, and

> that the header was added some time ago and no one caught this.
> This patch worked for me to get rid of the compile time problems.  I'm

> having issues with the kernel, but as far as I can tell they are form 
> the Frame buffer and not because of this.  If this assessment is 
> correct {the not needing this code anymore} then please pass this 
> along so it makes it into an upcoming release.
> 
> --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24 
> 17:36:21.000000000 -0500
> +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
> 17:40:02.000000000 -0500
> @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
>         return cclk_frequency_100khz[PPCR & 0xf] * 100;  }
> 
> -#else
> -/*
> - * We still need to provide this so building without cpufreq works.
> - */
> -unsigned int cpufreq_get(unsigned int cpu) -{
> -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
> -}
> -EXPORT_SYMBOL(cpufreq_get);
>  #endif
> 
>  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel clock
divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu); unsigned int
cpufreq_get(unsigned int cpu); #else static inline unsigned int
cpufreq_quick_get(unsigned int cpu) {
        return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu) {
        return 0;
}
#endif

which utterly bogus.

--
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Andrew Morton]

On Tue, 25 Sep 2007 13:22:55 -0400 Dave Jones <davej@redhat.com> wrote:

>  > 
>  > OK, here: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
>  > 
>  > So I guess what we want to do here is to revert that patch, test i386
>  > allnoconfig and then fix up anything which breaks.
> 
> Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
> (which should be the same as a native build).

Was that with allnoconfig?

> The functions that complain in that patch header don't seem to actually
> exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
> Did this patch perhaps jump the gun, and these are -mm only ?

Could be that this patch fixed version 17 of sched-clock-share and we ended
up merging verion 56.  It was awful.

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Andrew Morton]

On Tue, 25 Sep 2007 13:22:55 -0400 Dave Jones <davej@redhat.com> wrote:

>  > 
>  > OK, here: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
>  > 
>  > So I guess what we want to do here is to revert that patch, test i386
>  > allnoconfig and then fix up anything which breaks.
> 
> Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
> (which should be the same as a native build).

Was that with allnoconfig?

> The functions that complain in that patch header don't seem to actually
> exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
> Did this patch perhaps jump the gun, and these are -mm only ?

Could be that this patch fixed version 17 of sched-clock-share and we ended
up merging verion 56.  It was awful.

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Dave Jones]

On Tue, Sep 25, 2007 at 10:31:42AM -0700, Andrew Morton wrote:
 > On Tue, 25 Sep 2007 13:22:55 -0400 Dave Jones <davej@redhat.com> wrote:
 > 
 > >  > 
 > >  > OK, here: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
 > >  > 
 > >  > So I guess what we want to do here is to revert that patch, test i386
 > >  > allnoconfig and then fix up anything which breaks.
 > > 
 > > Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
 > > (which should be the same as a native build).
 > 
 > Was that with allnoconfig?

yeah.

 > > The functions that complain in that patch header don't seem to actually
 > > exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
 > > Did this patch perhaps jump the gun, and these are -mm only ?
 > 
 > Could be that this patch fixed version 17 of sched-clock-share and we ended
 > up merging verion 56.  It was awful.

heh.

I think just reverting that change for .23 makes sense. It doesn't
seem that anything breaks by not having it there, and we know it
definitly breaks arm at least.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Dave Jones]

On Tue, Sep 25, 2007 at 10:36:51AM -0400, Dave Jones wrote:
 > On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
 >  > On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com wrote:
 >  > > I was building a kernel for an iPaq {SA1110} and ran into this.
 >  > > 
 >  > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 >  > > Has a: #include <linux/cpufreq.h>
 >  > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 >  > > defined(CONFIG_CPU_FREQ_SA1110)
 >  > > who's else section redefines the cpufreq_get function inhereited from
 >  > > the header....
 >  > > 
 >  > > I'm guessing no one ever ended up in the "else" section until now, and
 >  > > that the header was added some time ago and no one caught this.
 >  > > This patch worked for me to get rid of the compile time problems.  I'm
 >  > > having issues with the kernel, but as far as I can tell they are form
 >  > > the Frame buffer and not because of this.  If this assessment is correct
 >  > > {the not needing this code anymore} then please pass this along so it
 >  > > makes it into an upcoming release.
 >  > > 
 >  > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
 >  > > 17:36:21.000000000 -0500
 >  > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
 >  > > 17:40:02.000000000 -0500
 >  > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 >  > >         return cclk_frequency_100khz[PPCR & 0xf] * 100;
 >  > >  }
 >  > > 
 >  > > -#else
 >  > > -/*
 >  > > - * We still need to provide this so building without cpufreq works.
 >  > > - */
 >  > > -unsigned int cpufreq_get(unsigned int cpu)
 >  > > -{
 >  > > -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
 >  > > -}
 >  > > -EXPORT_SYMBOL(cpufreq_get);
 >  > >  #endif
 >  > > 
 >  > >  /*
 >  > 
 >  > No.  That code is required - the StrongARM 1100 framebuffer driver
 >  > *needs* to know what the CPU frequency is so it can set the pixel
 >  > clock divisor.
 >  > 
 >  > The real problem is the silly people who added this to cpufreq.h:
 >  > 
 >  > #ifdef CONFIG_CPU_FREQ
 >  > unsigned int cpufreq_quick_get(unsigned int cpu);
 >  > unsigned int cpufreq_get(unsigned int cpu);
 >  > #else
 >  > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
 >  > {
 >  >         return 0;
 >  > }
 >  > static inline unsigned int cpufreq_get(unsigned int cpu)
 >  > {
 >  >         return 0;
 >  > }
 >  > #endif
 >  > 
 >  > which utterly bogus.
 > 
 > Which came from ...
 > 
 > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
 > Author: Andrew Morton <akpm@linux-foundation.org>
 > Date:   Wed May 2 19:27:08 2007 +0200
 > 
 >     [PATCH] x86-64: fix x86_64-mm-sched-clock-share
 >     
 >     Fix for the following patch. Provide dummy cpufreq functions when
 >     CPUFREQ is not compiled in.
 >     
 >     Cc: Andi Kleen <ak@suse.de>
 >     Cc: Dave Jones <davej@codemonkey.org.uk>
 >     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 >     Signed-off-by: Andi Kleen <ak@suse.de>
 > 

Following up on this from yesterday, Linus please revert the above cset.
It doesn't seem to be necessary (it was added to fix a miscompile in
'make allnoconfig' which doesn't seem to be repeatable with it reverted)
and actively breaks the ARM SA1100 framebuffer driver.

(If you'd prefer a patch reverting it, I'll send one, but I'm
 hoping that git-revert will just dtrt).

Thanks,

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Dave Jones]

On Tue, Sep 25, 2007 at 10:36:51AM -0400, Dave Jones wrote:
 > On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
 >  > On Mon, Sep 24, 2007 at 05:53:57PM -0500, Greg.Chandler@wellsfargo.com wrote:
 >  > > I was building a kernel for an iPaq {SA1110} and ran into this.
 >  > > 
 >  > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 >  > > Has a: #include <linux/cpufreq.h>
 >  > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 >  > > defined(CONFIG_CPU_FREQ_SA1110)
 >  > > who's else section redefines the cpufreq_get function inhereited from
 >  > > the header....
 >  > > 
 >  > > I'm guessing no one ever ended up in the "else" section until now, and
 >  > > that the header was added some time ago and no one caught this.
 >  > > This patch worked for me to get rid of the compile time problems.  I'm
 >  > > having issues with the kernel, but as far as I can tell they are form
 >  > > the Frame buffer and not because of this.  If this assessment is correct
 >  > > {the not needing this code anymore} then please pass this along so it
 >  > > makes it into an upcoming release.
 >  > > 
 >  > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
 >  > > 17:36:21.000000000 -0500
 >  > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c       2007-09-24
 >  > > 17:40:02.000000000 -0500
 >  > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 >  > >         return cclk_frequency_100khz[PPCR & 0xf] * 100;
 >  > >  }
 >  > > 
 >  > > -#else
 >  > > -/*
 >  > > - * We still need to provide this so building without cpufreq works.
 >  > > - */
 >  > > -unsigned int cpufreq_get(unsigned int cpu)
 >  > > -{
 >  > > -       return cclk_frequency_100khz[PPCR & 0xf] * 100;
 >  > > -}
 >  > > -EXPORT_SYMBOL(cpufreq_get);
 >  > >  #endif
 >  > > 
 >  > >  /*
 >  > 
 >  > No.  That code is required - the StrongARM 1100 framebuffer driver
 >  > *needs* to know what the CPU frequency is so it can set the pixel
 >  > clock divisor.
 >  > 
 >  > The real problem is the silly people who added this to cpufreq.h:
 >  > 
 >  > #ifdef CONFIG_CPU_FREQ
 >  > unsigned int cpufreq_quick_get(unsigned int cpu);
 >  > unsigned int cpufreq_get(unsigned int cpu);
 >  > #else
 >  > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
 >  > {
 >  >         return 0;
 >  > }
 >  > static inline unsigned int cpufreq_get(unsigned int cpu)
 >  > {
 >  >         return 0;
 >  > }
 >  > #endif
 >  > 
 >  > which utterly bogus.
 > 
 > Which came from ...
 > 
 > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
 > Author: Andrew Morton <akpm@linux-foundation.org>
 > Date:   Wed May 2 19:27:08 2007 +0200
 > 
 >     [PATCH] x86-64: fix x86_64-mm-sched-clock-share
 >     
 >     Fix for the following patch. Provide dummy cpufreq functions when
 >     CPUFREQ is not compiled in.
 >     
 >     Cc: Andi Kleen <ak@suse.de>
 >     Cc: Dave Jones <davej@codemonkey.org.uk>
 >     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
 >     Signed-off-by: Andi Kleen <ak@suse.de>
 > 

Following up on this from yesterday, Linus please revert the above cset.
It doesn't seem to be necessary (it was added to fix a miscompile in
'make allnoconfig' which doesn't seem to be repeatable with it reverted)
and actively breaks the ARM SA1100 framebuffer driver.

(If you'd prefer a patch reverting it, I'll send one, but I'm
 hoping that git-revert will just dtrt).

Thanks,

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Russell King]

On Wed, Sep 26, 2007 at 04:53:14PM -0400, Dave Jones wrote:
> Following up on this from yesterday, Linus please revert the above cset.
> It doesn't seem to be necessary (it was added to fix a miscompile in
> 'make allnoconfig' which doesn't seem to be repeatable with it reverted)
> and actively breaks the ARM SA1100 framebuffer driver.
> 
> (If you'd prefer a patch reverting it, I'll send one, but I'm
>  hoping that git-revert will just dtrt).

Dave,

Thanks for checking this out on x86, and getting it reverted.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Russell King]

On Wed, Sep 26, 2007 at 04:53:14PM -0400, Dave Jones wrote:
> Following up on this from yesterday, Linus please revert the above cset.
> It doesn't seem to be necessary (it was added to fix a miscompile in
> 'make allnoconfig' which doesn't seem to be repeatable with it reverted)
> and actively breaks the ARM SA1100 framebuffer driver.
> 
> (If you'd prefer a patch reverting it, I'll send one, but I'm
>  hoping that git-revert will just dtrt).

Dave,

Thanks for checking this out on x86, and getting it reverted.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

arm root filesystem.

[Greg.Chandler]

I was wondering if I could pick your brain with a couple of questions?
{any of you?}

I have an ipaq h3600, and I was able to put familiar on it just to make
sure it all worked.  What I am trying to do is build a base system that
I can use as an embedded controller for something else I'm building.

I have built a current kernel {with a cross-compiler} and it seems to
work.  {after submitting a patch {which really wasn't} to the kernel
list}

The kernel loads and has all it's output to both the serial or tty
consoles.  It uncompresses the ramdisk {initrd not initramfs} and it
recognizes it.
Booting the kernel from compact flash, it can see the partitions
correctly, and recognizes the devices correctly. I've played with the
params to give it invalid options to make sure it panics when the
options are wrong.

When the options are right, the last thing I see is "freeing init
memory: 132k".

Right after that it's supposed to have mounted read-only the ram disk
and be launching whatever init= is set to from the parameters.
If I eject the cf card it scrolls read/write errors, but I don't see it
actually doing anything...

I've also compiled in kernel-auto-conf options and NFS root as a 2nd
try.  If I switch the CF packpack with the PCMCIA one, while the kernel
is uncompressing /loading after it is read from the CF card, it will
detect the 3c589{or whatever it is} card.  I gave it all the appropriate
ip= root= and nfsroot options...  The IP is static so I don't have to
deal with DHCP/bootp/RARP.  I also had to force the PHY type to the
10baseT since it auto sets to 10base2.

Getting all that right, I can't ping the device {don't know if I should
be able to or not} and it scrolls RPC garbage until finally panicing
since it can't mount the NFS root. {I've set up hundreds of NFS root
boxes so I know the configs are all good}

No matter what I do, it seems to not like the root filesystem or not
like the init... I can't really tell which.....

I'm wondering if there is a memeory address problem.  I gave it both:
mem=16M and mem=32M even though the device has 64M, and that didn't
work.
I don't know if there is some offset that the FS needs to be loaded from
or if it MUST be jffs2, but familiar runs from and ext2...  {neither
ext2 or nfs seem to be working for me}

I've also read blurbs about similar issues {if not the same} were people
building with a cross-compiler aren't building correctly and have the
wrong binaries and such...  I'm pretty sure that I have all that right,
and that I have the right binary types {elf, a.out} compiled into the
kernel.


Any ideas?  I'm stuck...  Out of all the platforms I've worked on, I've
never gotten stuck before so this is a weird one for me.

Re: arm root filesystem.

[Dave Jones]

On Wed, Oct 10, 2007 at 06:18:18PM -0500, Greg.Chandler@wellsfargo.com wrote:

 > I have an ipaq h3600, and I was able to put familiar on it just to make
 > sure it all worked.  What I am trying to do is build a base system that
 > I can use as an embedded controller for something else I'm building.
 > 
 >  ...
 > 
 > Any ideas?  I'm stuck...  Out of all the platforms I've worked on, I've
 > never gotten stuck before so this is a weird one for me.

You may have more luck posting this to an ipaq or ARM specific mailing list
(Or even linux-kernel).   Whilst there are some ARM users on the cpufreq
list, it's off-topic here for many other readers.

	Dave

-- 
http://www.codemonkey.org.uk