[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070925175156.GG2769@redhat.com>
Date: Tue, 25 Sep 2007 13:51:56 -0400
From: Dave Jones <davej@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Russell King <rmk+lkml@....linux.org.uk>,
Greg.Chandler@...lsfargo.com, cpufreq@...ts.linux.org.uk,
linux-kernel@...r.kernel.org, dan.j.williams@...el.com,
Andi Kleen <ak@...e.de>
Subject: Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more}
ARM/StrongARM
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@...hat.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists