2.6.13-git10 was OK (read: allmodconfig still broken, but not _that_
early).
If anybody want to see full logs, they are at
ftp://ftp.berlios.de/pub/linux-sparse/logs/2.6.13-git11/W_sparse_{parisc,sh}.bz2
-----------------------------------------------------------------------
parisc:
2.6.13-git11
hppa-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1)
which: no palo in ($PATH)
CHK include/linux/version.h
UPD include/linux/version.h
SYMLINK include/asm -> include/asm-parisc
which: no palo in ($PATH)
scripts/kconfig/conf -s arch/parisc/Kconfig
#
# using defaults found in .config
#
SPLIT include/linux/autoconf.h -> include/config/*
CC arch/parisc/kernel/asm-offsets.s
In file included from include/asm/spinlock.h:4,
from include/asm/bitops.h:5,
from include/linux/bitops.h:77,
from include/linux/thread_info.h:20,
from include/linux/spinlock.h:53,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from arch/parisc/kernel/asm-offsets.c:31:
include/asm/system.h:174: error: parse error before "pa_tlb_lock"
...
-----------------------------------------------------------------------
sh:
2.6.13-git11
sh-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1)
CHK include/linux/version.h
UPD include/linux/version.h
Generating include/asm-sh/machtypes.h
SPLIT include/linux/autoconf.h -> include/config/*
SYMLINK include/asm-sh/cpu -> include/asm-sh/cpu-sh4
SYMLINK include/asm-sh/mach -> include/asm-sh/unknown
SYMLINK include/asm -> include/asm-sh
CC arch/sh/kernel/asm-offsets.s
In file included from include/linux/spinlock_types.h:13,
from include/linux/spinlock.h:80,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from include/linux/mm.h:4,
from arch/sh/kernel/asm-offsets.c:13:
include/asm/spinlock_types.h:16: error: parse error before "atomic_t"
...
-----------------------------------------------------------------------
Hi Alexey.
On Tue, Sep 13, 2005 at 09:47:54PM +0400, Alexey Dobriyan wrote:
> 2.6.13-git10 was OK (read: allmodconfig still broken, but not _that_
> early).
>
> If anybody want to see full logs, they are at
> ftp://ftp.berlios.de/pub/linux-sparse/logs/2.6.13-git11/W_sparse_{parisc,sh}.bz2
> -----------------------------------------------------------------------
> parisc:
>
> 2.6.13-git11
> hppa-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1)
> which: no palo in ($PATH)
> CHK include/linux/version.h
> UPD include/linux/version.h
> SYMLINK include/asm -> include/asm-parisc
> which: no palo in ($PATH)
> scripts/kconfig/conf -s arch/parisc/Kconfig
> #
> # using defaults found in .config
> #
> SPLIT include/linux/autoconf.h -> include/config/*
> CC arch/parisc/kernel/asm-offsets.s
> In file included from include/asm/spinlock.h:4,
> from include/asm/bitops.h:5,
> from include/linux/bitops.h:77,
> from include/linux/thread_info.h:20,
> from include/linux/spinlock.h:53,
> from include/linux/capability.h:45,
> from include/linux/sched.h:7,
> from arch/parisc/kernel/asm-offsets.c:31:
> include/asm/system.h:174: error: parse error before "pa_tlb_lock"
> ...
> -----------------------------------------------------------------------
> sh:
>
> 2.6.13-git11
> sh-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1)
> CHK include/linux/version.h
> UPD include/linux/version.h
> Generating include/asm-sh/machtypes.h
> SPLIT include/linux/autoconf.h -> include/config/*
> SYMLINK include/asm-sh/cpu -> include/asm-sh/cpu-sh4
> SYMLINK include/asm-sh/mach -> include/asm-sh/unknown
> SYMLINK include/asm -> include/asm-sh
> CC arch/sh/kernel/asm-offsets.s
> In file included from include/linux/spinlock_types.h:13,
> from include/linux/spinlock.h:80,
> from include/linux/capability.h:45,
> from include/linux/sched.h:7,
> from include/linux/mm.h:4,
> from arch/sh/kernel/asm-offsets.c:13:
> include/asm/spinlock_types.h:16: error: parse error before "atomic_t"
> ...
> -----------------------------------------------------------------------
I have tried to understand why this happens with no success..
Not much has changed in how we actually compile the .c -> .s files.
In both cases it looks like gcc is warning that a sane typedef is not
present.
Have you tried to dive more into this, or have you just reported the
breakage?
Sam
On Tue, Sep 13, 2005 at 08:57:59PM +0200, Sam Ravnborg wrote:
> On Tue, Sep 13, 2005 at 09:47:54PM +0400, Alexey Dobriyan wrote:
> > 2.6.13-git10 was OK (read: allmodconfig still broken, but not _that_
> > early).
> > parisc:
> >
> > 2.6.13-git11
> > CC arch/parisc/kernel/asm-offsets.s
> > In file included from include/asm/spinlock.h:4,
> > from include/asm/bitops.h:5,
> > from include/linux/bitops.h:77,
> > from include/linux/thread_info.h:20,
> > from include/linux/spinlock.h:53,
> > from include/linux/capability.h:45,
> > from include/linux/sched.h:7,
> > from arch/parisc/kernel/asm-offsets.c:31:
> > include/asm/system.h:174: error: parse error before "pa_tlb_lock"
> > In file included from include/linux/spinlock_types.h:13,
> > from include/linux/spinlock.h:80,
> > from include/linux/capability.h:45,
> > from include/linux/sched.h:7,
> > from include/linux/mm.h:4,
> > from arch/sh/kernel/asm-offsets.c:13:
> > include/asm/spinlock_types.h:16: error: parse error before "atomic_t"
> I have tried to understand why this happens with no success..
> Not much has changed in how we actually compile the .c -> .s files.
> In both cases it looks like gcc is warning that a sane typedef is not
> present.
>
> Have you tried to dive more into this, or have you just reported the
> breakage?
fb1c8f93d869b34cacb8b8932e2b83d96a19d720 is first bad commit
diff-tree fb1c8f93d869b34cacb8b8932e2b83d96a19d720 (from 4327edf6b8a7ac7dce144313947995538842d8fd)
Author: Ingo Molnar <[email protected]>
Date: Sat Sep 10 00:25:56 2005 -0700
[PATCH] spinlock consolidation
This patch (written by me and also containing many suggestions of Arjan van
de Ven) does a major cleanup of the spinlock code. It does the following
things:
[snip]
arm, i386, ia64, ppc, ppc64, s390/s390x, x64 was build-tested via
crosscompilers. m32r, mips, sh, sparc, have not been tested yet, but should
be mostly fine.
P. S.: git bisect absolutely rocks! 10 minutes.
Hi Alexey.
> > > parisc:
> > >
> > > 2.6.13-git11
>
> > > CC arch/parisc/kernel/asm-offsets.s
> > > In file included from include/asm/spinlock.h:4,
> > > from include/asm/bitops.h:5,
> > > from include/linux/bitops.h:77,
> > > from include/linux/thread_info.h:20,
> > > from include/linux/spinlock.h:53,
> > > from include/linux/capability.h:45,
> > > from include/linux/sched.h:7,
> > > from arch/parisc/kernel/asm-offsets.c:31:
> > > include/asm/system.h:174: error: parse error before "pa_tlb_lock"
>
> > > In file included from include/linux/spinlock_types.h:13,
> > > from include/linux/spinlock.h:80,
> > > from include/linux/capability.h:45,
> > > from include/linux/sched.h:7,
> > > from include/linux/mm.h:4,
> > > from arch/sh/kernel/asm-offsets.c:13:
> > > include/asm/spinlock_types.h:16: error: parse error before "atomic_t"
>
...
>
> fb1c8f93d869b34cacb8b8932e2b83d96a19d720 is first bad commit
> diff-tree fb1c8f93d869b34cacb8b8932e2b83d96a19d720 (from 4327edf6b8a7ac7dce144313947995538842d8fd)
> Author: Ingo Molnar <[email protected]>
> Date: Sat Sep 10 00:25:56 2005 -0700
>
> [PATCH] spinlock consolidation
>
> This patch (written by me and also containing many suggestions of Arjan van
> de Ven) does a major cleanup of the spinlock code. It does the following
> things:
>
> [snip]
>
> arm, i386, ia64, ppc, ppc64, s390/s390x, x64 was build-tested via
> crosscompilers. m32r, mips, sh, sparc, have not been tested yet, but should
> be mostly fine.
>
> P. S.: git bisect absolutely rocks! 10 minutes.
I was chasing a bug in asm-offsets.h handling and looked at a far to old
tree (read: 24 hour old).
I leave this to Ingo and friends.
Sam
On Wed, Sep 14, 2005 at 12:37:20AM +0400, Alexey Dobriyan wrote:
> > > 2.6.13-git11
...
> > > include/asm/system.h:174: error: parse error before "pa_tlb_lock"
...
> fb1c8f93d869b34cacb8b8932e2b83d96a19d720 is first bad commit
> diff-tree fb1c8f93d869b34cacb8b8932e2b83d96a19d720 (from 4327edf6b8a7ac7dce144313947995538842d8fd)
> Author: Ingo Molnar <[email protected]>
> Date: Sat Sep 10 00:25:56 2005 -0700
>
> [PATCH] spinlock consolidation
If someone can give me a recipe how to access 2.6.13-git11 source tree,
I should be able to unravel this and submit a tested patch in < 48h.
I'm pretty sure it's just an issue of parisc being slightly behind
the main tree. Ingo's patch is clearly a step in the right direction.
thanks,
grant
* Grant Grundler <[email protected]> wrote:
> > [PATCH] spinlock consolidation
>
> If someone can give me a recipe how to access 2.6.13-git11 source
> tree, I should be able to unravel this and submit a tested patch in <
> 48h. I'm pretty sure it's just an issue of parisc being slightly
> behind the main tree. Ingo's patch is clearly a step in the right
> direction.
git snapshots dont seem to be working right now, so either you download
git and sync up to kernel.org, or try 2.6.14-rc1 to trigger the same
problem:
http://kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.14-rc1.tar.bz2
Ingo
* Ingo Molnar <[email protected]> wrote:
> git snapshots dont seem to be working right now, [...]
looked into the wrong place. You can get -git11 from:
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.13-git11.bz2
or -git12 (the latest Linus tree) from:
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.13-git12.bz2
Ingo
On Wed, Sep 14, 2005 at 09:43:09AM +0200, Ingo Molnar wrote:
> > If someone can give me a recipe how to access 2.6.13-git11 source
> > tree, I should be able to unravel this and submit a tested patch in <
> > 48h. I'm pretty sure it's just an issue of parisc being slightly
> > behind the main tree. Ingo's patch is clearly a step in the right
> > direction.
>
> git snapshots dont seem to be working right now, so either you download
> git and sync up to kernel.org, or try 2.6.14-rc1 to trigger the same
> problem:
>
> http://kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.14-rc1.tar.bz2
thanks!
I already had 2.6.14-rc1 and used that to base this patch.
I *think* the appended patch will fix the problem by moving
the definition of the pa_tlb_lock into it's main user: asm/tlbflush.h.
I'm not certain because the parisc build now fails with:
CC arch/parisc/kernel/drivers.o
arch/parisc/kernel/drivers.c: In function 'next_dev':
arch/parisc/kernel/drivers.c:65: error: 'struct device' has no member named 'children'
arch/parisc/kernel/drivers.c:66: warning: implicit declaration of function 'list_to_dev'
...
Looks like parisc/kernel/drivers.c is out of sync with the
parisc-linux.org CVS tree. The p-l.o tree doesn't define "next_dev()"
in drivers.c. It might be obvious to willy what's up here.
ISTR he wanted to sync up tomorrow with linus again anyway.
Willy?
But I'm pretty sure this patch is the first correct step
to unraveling this original build failure.
I didn't see any other spinlocks defined in asm-parisc/system.h.
ISTR the original problem report flagged another lock and I'll
take care of it as well when it pops up again.
thanks,
grant
Signed-off-by: Grant Grundler <[email protected]>
--- linux-2.6.14-rc1/arch/parisc/kernel/pci-dma.c 2005-09-12 20:12:09.000000000 -0700
+++ pa_tlb_lock-moved/arch/parisc/kernel/pci-dma.c 2005-09-14 01:21:29.000000000 -0700
@@ -26,6 +26,7 @@
#include <linux/types.h>
#include <asm/cacheflush.h>
+#include <asm/tlbflush.h>
#include <asm/dma.h> /* for DMA_CHUNK_SIZE */
#include <asm/io.h>
#include <asm/page.h> /* get_order */
diff -urp linux-2.6.14-rc1/include/asm-parisc/system.h pa_tlb_lock-moved/include/asm-parisc/system.h
--- linux-2.6.14-rc1/include/asm-parisc/system.h 2005-09-12 20:12:09.000000000 -0700
+++ pa_tlb_lock-moved/include/asm-parisc/system.h 2005-09-14 01:25:47.000000000 -0700
@@ -165,24 +165,6 @@ static inline void set_eiem(unsigned lon
#define KERNEL_START (0x10100000 - 0x1000)
-/* This is for the serialisation of PxTLB broadcasts. At least on the
- * N class systems, only one PxTLB inter processor broadcast can be
- * active at any one time on the Merced bus. This tlb purge
- * synchronisation is fairly lightweight and harmless so we activate
- * it on all SMP systems not just the N class. */
-#ifdef CONFIG_SMP
-extern spinlock_t pa_tlb_lock;
-
-#define purge_tlb_start(x) spin_lock(&pa_tlb_lock)
-#define purge_tlb_end(x) spin_unlock(&pa_tlb_lock)
-
-#else
-
-#define purge_tlb_start(x) do { } while(0)
-#define purge_tlb_end(x) do { } while (0)
-
-#endif
-
#define arch_align_stack(x) (x)
#endif
diff -urp linux-2.6.14-rc1/include/asm-parisc/tlbflush.h pa_tlb_lock-moved/include/asm-parisc/tlbflush.h
--- linux-2.6.14-rc1/include/asm-parisc/tlbflush.h 2005-09-12 20:12:09.000000000 -0700
+++ pa_tlb_lock-moved/include/asm-parisc/tlbflush.h 2005-09-14 01:26:42.000000000 -0700
@@ -45,7 +45,27 @@ static inline void flush_tlb_mm(struct m
extern __inline__ void flush_tlb_pgtables(struct mm_struct *mm, unsigned long start, unsigned long end)
{
}
+
+
+/* This is for the serialisation of PxTLB broadcasts. At least on the
+ * N class systems, only one PxTLB inter processor broadcast can be
+ * active at any one time on the Merced bus. This tlb purge
+ * synchronisation is fairly lightweight and harmless so we activate
+ * it on all SMP systems not just the N class. */
+#ifdef CONFIG_SMP
+extern spinlock_t pa_tlb_lock;
+
+#define purge_tlb_start(x) spin_lock(&pa_tlb_lock)
+#define purge_tlb_end(x) spin_unlock(&pa_tlb_lock)
+
+#else
+
+#define purge_tlb_start(x) do { } while(0)
+#define purge_tlb_end(x) do { } while (0)
+
+#endif
+
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long addr)
{
On Wed, Sep 14, 2005 at 03:17:22AM -0600, Grant Grundler wrote:
> Looks like parisc/kernel/drivers.c is out of sync with the
> parisc-linux.org CVS tree. The p-l.o tree doesn't define "next_dev()"
> in drivers.c. It might be obvious to willy what's up here.
> ISTR he wanted to sync up tomorrow with linus again anyway.
> Willy?
The parisc tree hasn't been merged with Linus in a long time because I
find git completely impossible to use. The howtos are all out of date
and contradict each other. They don't tell me what I need to know.
Everybody who uses them has their own collection of private scripts that
work around the worst misfeatures. It's a complete fucking disaster.
The Debian cogito package doesn't have half the tools mentioned in the
howtos, as well as being months out of date. Last time I had the energy
to fight with it, it didn't even support pack files.
I'd love to stop using CVS and just use git. But it simply doesn't work.
On Wed, 14 Sep 2005, Matthew Wilcox wrote:
>
> The parisc tree hasn't been merged with Linus in a long time because I
> find git completely impossible to use. The howtos are all out of date
> and contradict each other. They don't tell me what I need to know.
> Everybody who uses them has their own collection of private scripts that
> work around the worst misfeatures. It's a complete fucking disaster.
Actually, that's not true. I was asking people what scripts they use the
other day, and was surprised to learn that they don't use any at all.
And especially if you use git itself - _without_ any special scripts, the
git mailing list is actually active and quite helpful. I haven't seen you
ask anything there.. Hint hint..
> The Debian cogito package doesn't have half the tools mentioned in the
> howtos, as well as being months out of date. Last time I had the energy
> to fight with it, it didn't even support pack files.
Now _that_ is true. You can't depend on vendor packaging. They are _way_
too slow. For now, you absolutely have to do it yourself.
(Well, "absolutely have to" may not be true - you can find RPM's etc, but
you might as well resign yourself to it for the next few months).
Just do this:
- get the last daily snapshot from
http://www.codemonkey.org.uk/projects/git-snapshots/git/
(this is mentioned in the overview, btw, directly reachable from
http://www.kernel.org/git, so it's even well documented)
- compile and install it: "make" + "make install"
- just as an exercise (and because it's a lot smaller than the kernel
and thus downloads much faster), get the git.git tree:
git clone rsync://rsync.kernel.org/pub/scm/git/git.git git-tree
cd git-tree
git checkout
make
make install
and you've now gotten the most up-to-date git there is. The nice thing
about this is that going an update is now
git pull origin
so you can trivially keep track of it forever after.
- now you're getting ready to get a _real_ project. This will take some
time.
git clone \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
kernel-tree
cd kernel-tree
git checkout
and you have the kernel sources. On my 1.5Mbps DSL line, it takes about
ten minutes, because you're downloading about 80MB of stuff (and
the checkout unpacks 17,000 files and takes 5 seconds for me, but a
_lot_ more if you don't have tons of memory to cache the thing). But
it's not horrible.
- play around.
And git really isn't that hard to use any more. If you tried it two months
ago, it was a _lot_ more complicated. These days, if you can work with
CVS, it's a hell of a lot more pleasant than that ;)
(It doesn't have a really nice graphical merge tool like BK did, for
example: you end up having to resolve merge clashes the CVS way by
searching for "<<<<<"/"======"/">>>>>>" markers.. The good news is that
it gets merge clashes pretty infrequently - I get them maybe once a week,
and I merge a _lot_)
Linus