TASK_UNMAPPED_BASE

TASK_UNMAPPED_BASE

[Joakim Tjernlund]

Hi All

Currently TASK_UNMAPPED_BASE in PPC is defined to:
#define TASK_UNMAPPED_BASE (TASK_SIZE / 8 *3) which is 0x30000000

in glibc ldso's JMP_SLOT you have:

      {
        Elf32_Sword delta = finaladdr - (Elf32_Word) reloc_addr;
        if (delta << 6 >> 6 == delta)
          *reloc_addr = OPCODE_B (delta);
        else if (finaladdr <= 0x01fffffc || finaladdr >= 0xfe000000)
          *reloc_addr = OPCODE_BA (finaladdr);
        else
          {
            Elf32_Word *plt, *data_words;
            Elf32_Word index, offset, num_plt_entries;

            plt = (Elf32_Word *) D_PTR (map, l_info[DT_PLTGOT]);
            offset = reloc_addr - plt;

            if (offset < PLT_DOUBLE_SIZE*2 + PLT_INITIAL_ENTRY_WORDS)
              {
                index = (offset - PLT_INITIAL_ENTRY_WORDS)/2;
                num_plt_entries = (map->l_info[DT_PLTRELSZ]->d_un.d_val
                                   / sizeof(Elf32_Rela));
                data_words = plt + PLT_DATA_START_WORDS (num_plt_entries);
                data_words[index] = finaladdr;
                reloc_addr[0] = OPCODE_LI (11, index * 4);
                reloc_addr[1] = OPCODE_B ((PLT_LONGBRANCH_ENTRY_WORDS
                                           - (offset+1))
                                          * 4);
                MODIFIED_CODE_NOQUEUE (reloc_addr + 1);
              }
            else
              {
                reloc_addr[0] = OPCODE_LIS_HI (12, finaladdr);
                reloc_addr[1] = OPCODE_ADDI (12, 12, finaladdr);
                reloc_addr[2] = OPCODE_MTCTR (12);
                reloc_addr[3] = OPCODE_BCTR ();
                MODIFIED_CODE_NOQUEUE (reloc_addr + 3);
              }
          }
      }
      break;

The if (delta << 6 >> 6 == delta) is commonly false.

If finaladdr is <= 0x01fffffc then the relocation is much cheaper than the last else statement.
But since TASK_UNMAPPED_BASE is 0x30000000, finaladdr will never be <= 0x01fffffc unless
a shared library asks for a low address.

I changed TASK_UNMAPPED_BASE to well under 0x01fffffc and it worked as well.

My question: Why is TASK_UNMAPPED_BASE=0x30000000 and would changing it to something
less, say 0x00100000 be a problem?

 Jocke

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Franz Sirl]

At 14:05 03.02.2004, Joakim Tjernlund wrote:

>Hi All
>
>Currently TASK_UNMAPPED_BASE in PPC is defined to:
>#define TASK_UNMAPPED_BASE (TASK_SIZE / 8 *3) which is 0x30000000
>
>in glibc ldso's JMP_SLOT you have:
>
>       {
>         Elf32_Sword delta = finaladdr - (Elf32_Word) reloc_addr;
>         if (delta << 6 >> 6 == delta)
>           *reloc_addr = OPCODE_B (delta);
>         else if (finaladdr <= 0x01fffffc || finaladdr >= 0xfe000000)
>           *reloc_addr = OPCODE_BA (finaladdr);
>         else
>           {
>             Elf32_Word *plt, *data_words;
>             Elf32_Word index, offset, num_plt_entries;
>
>             plt = (Elf32_Word *) D_PTR (map, l_info[DT_PLTGOT]);
>             offset = reloc_addr - plt;
>
>             if (offset < PLT_DOUBLE_SIZE*2 + PLT_INITIAL_ENTRY_WORDS)
>               {
>                 index = (offset - PLT_INITIAL_ENTRY_WORDS)/2;
>                 num_plt_entries = (map->l_info[DT_PLTRELSZ]->d_un.d_val
>                                    / sizeof(Elf32_Rela));
>                 data_words = plt + PLT_DATA_START_WORDS (num_plt_entries);
>                 data_words[index] = finaladdr;
>                 reloc_addr[0] = OPCODE_LI (11, index * 4);
>                 reloc_addr[1] = OPCODE_B ((PLT_LONGBRANCH_ENTRY_WORDS
>                                            - (offset+1))
>                                           * 4);
>                 MODIFIED_CODE_NOQUEUE (reloc_addr + 1);
>               }
>             else
>               {
>                 reloc_addr[0] = OPCODE_LIS_HI (12, finaladdr);
>                 reloc_addr[1] = OPCODE_ADDI (12, 12, finaladdr);
>                 reloc_addr[2] = OPCODE_MTCTR (12);
>                 reloc_addr[3] = OPCODE_BCTR ();
>                 MODIFIED_CODE_NOQUEUE (reloc_addr + 3);
>               }
>           }
>       }
>       break;
>
>The if (delta << 6 >> 6 == delta) is commonly false.

Well, if that is true for you, then you must have a really large app, since
this covers relative branches +/-32M.

>If finaladdr is <= 0x01fffffc then the relocation is much cheaper than the
>last else statement.
>But since TASK_UNMAPPED_BASE is 0x30000000, finaladdr will never be <=
>0x01fffffc unless
>a shared library asks for a low address.

But nearly nothing loads at 0x30000000, usually only ld.so. The executable
itself (note that I haven't looked at PIE executables yet) is at 0x10000000
and the shared libs are loaded initially below that until that space is
filled and then above ld.so IIRC.

>I changed TASK_UNMAPPED_BASE to well under 0x01fffffc and it worked as well.
>
>My question: Why is TASK_UNMAPPED_BASE=0x30000000 and would changing it to
>something
>less, say 0x00100000 be a problem?

Hmm, might work, but it can also break in subtle ways, cause the shared lib
loading algorithm makes a few assumptions about the used address ranges
IIRC. But I don't see any use for it if you consider what I said above.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Joakim Tjernlund]

Hi Franz

Thanks for replying.

> At 14:05 03.02.2004, Joakim Tjernlund wrote:
>
> >Hi All
> >
> >Currently TASK_UNMAPPED_BASE in PPC is defined to:
> >#define TASK_UNMAPPED_BASE (TASK_SIZE / 8 *3) which is 0x30000000
> >
> >in glibc ldso's JMP_SLOT you have:

[SNIP]

> >
> >The if (delta << 6 >> 6 == delta) is commonly false.
>
> Well, if that is true for you, then you must have a really large app, since
> this covers relative branches +/-32M.

32M == 0x2000000 which is <  0x30000000-0x10000000
So "branches" to any library function will not fit into the 32M space, right?

>
> >If finaladdr is <= 0x01fffffc then the relocation is much cheaper than the
> >last else statement.
> >But since TASK_UNMAPPED_BASE is 0x30000000, finaladdr will never be <=
> >0x01fffffc unless
> >a shared library asks for a low address.
>
> But nearly nothing loads at 0x30000000, usually only ld.so. The executable
> itself (note that I haven't looked at PIE executables yet) is at 0x10000000
> and the shared libs are loaded initially below that until that space is
> filled and then above ld.so IIRC.

Yes, thats true for glibc. I wonder why glibc supply its own load address for all
libs but ld.so?

However, I forgot to mention uClibc. UClibc does not insist on its own load address, but lets
the kernel handle that.  So for uClibc, ld.so will load at 0x30000000 and the rest will follow
after ld.so.

>
> >I changed TASK_UNMAPPED_BASE to well under 0x01fffffc and it worked as well.
> >
> >My question: Why is TASK_UNMAPPED_BASE=0x30000000 and would changing it to
> >something
> >less, say 0x00100000 be a problem?
>
> Hmm, might work, but it can also break in subtle ways, cause the shared lib
> loading algorithm makes a few assumptions about the used address ranges
> IIRC. But I don't see any use for it if you consider what I said above.

OK, but are there other considerations as well? What is the address space below 0x10000000 used for?

 Jocke
>
> Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Peter Bergner]

On Tue, 2004-02-03 at 09:22, Franz Sirl wrote:
> At 14:05 03.02.2004, Joakim Tjernlund wrote:
>> I changed TASK_UNMAPPED_BASE to well under 0x01fffffc and it worked as well.
>>
>> My question: Why is TASK_UNMAPPED_BASE=0x30000000 and would changing it to
>> something less, say 0x00100000 be a problem?
>
> Hmm, might work, but it can also break in subtle ways, cause the shared lib
> loading algorithm makes a few assumptions about the used address ranges
> IIRC. But I don't see any use for it if you consider what I said above.

I've seen problems with HPC apps/benchmarks with huge bss's that fail to
run because TASK_UNMAPED_BASE is set too low.  I'll admit they fail to
run due to a bug in the fs/binfmt_elf.c, but the fix has never been
accepted yet.  The bug is that we don't reserve the bss region for the
app (via a set_brk/do_brk call) until after we've loaded the loader so
they get mapped to overlapping memory locations.  The fix is to move the
update to current->mm.* and the set_brk/do_brk call to before the point
we call load_elf_interp().

Another bug is that the calls to set_brk/do_brk in fs/binfmt_elf.c fail to
check whether the set_brk/do_brk calls succeeded or not, so they implicitly
assume they do.  With an app with a huge bss, the set_brk/do_brk call actually
returns -ENOMEM which is then ignored.  The fix is to test for failure from
the set_brk/do_brk calls.

Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Anton Blanchard]

> I've seen problems with HPC apps/benchmarks with huge bss's that fail to
> run because TASK_UNMAPED_BASE is set too low.  I'll admit they fail to
> run due to a bug in the fs/binfmt_elf.c, but the fix has never been
> accepted yet.  The bug is that we don't reserve the bss region for the
> app (via a set_brk/do_brk call) until after we've loaded the loader so
> they get mapped to overlapping memory locations.  The fix is to move the
> update to current->mm.* and the set_brk/do_brk call to before the point
> we call load_elf_interp().
>
> Another bug is that the calls to set_brk/do_brk in fs/binfmt_elf.c fail to
> check whether the set_brk/do_brk calls succeeded or not, so they implicitly
> assume they do.  With an app with a huge bss, the set_brk/do_brk call actually
> returns -ENOMEM which is then ignored.  The fix is to test for failure from
> the set_brk/do_brk calls.

A patch went into 2.6 that should fix both of these problems. Give all
those nasty test cases another run :)

Anton

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Peter Bergner]

On Wed, 2004-02-04 at 08:47, Anton Blanchard wrote:
> A patch went into 2.6 that should fix both of these problems. Give all
> those nasty test cases another run :)

Ahh, good.  I must have blinked at the wrong time and missed it getting
merged! :-)  Do you know whether it got pushed to 2.4 as well?


Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Joakim Tjernlund]

> On Tue, 2004-02-03 at 09:22, Franz Sirl wrote:
> > At 14:05 03.02.2004, Joakim Tjernlund wrote:
> >> I changed TASK_UNMAPPED_BASE to well under 0x01fffffc and it worked
> >> as well.
> >>
> >> My question: Why is TASK_UNMAPPED_BASE=0x30000000 and would
> >> changing it to something less, say 0x00100000 be a problem?
> >
> > Hmm, might work, but it can also break in subtle ways, cause the
> > shared lib loading algorithm makes a few assumptions about the used
> > address ranges IIRC. But I don't see any use for it if you consider
> > what I said above.
>
> I've seen problems with HPC apps/benchmarks with huge bss's that fail
> to run because TASK_UNMAPED_BASE is set too low.

Too low, does that mean TASK_UNMAPED_BASE < 0x00100000 will fail with
huge bss's as well? Or will it just fail for
0x30000000 => TASK_UNMAPED_BASE <= 0x10000000?

To me it seems like it is a good idea to change(at least in 2.6
where the bugs you mentioned has been fixed) TASK_UNMAPED_BASE to
0x00100000(or lower).

Is there a way I can tell glibc to load it's libs around TASK_UNMAPED_BASE?
Currently only ld.so follows TASK_UNMAPED_BASE, the other libs always
loads at 0x0fxxxxxx. Glibc/ld.so version is 2.2.3

   Jocke

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Peter Bergner]

On Thu, 2004-02-05 at 02:57, Joakim Tjernlund wrote:
> Too low, does that mean TASK_UNMAPED_BASE < 0x00100000 will fail with
> huge bss's as well? Or will it just fail for
> 0x30000000 => TASK_UNMAPED_BASE <= 0x10000000?
>
> To me it seems like it is a good idea to change(at least in 2.6
> where the bugs you mentioned has been fixed) TASK_UNMAPED_BASE to
> 0x00100000(or lower).

The problem with a TASK_UNMAPPED_BASE that was "too low" was referring to
the bug where we always loaded ld.so at TASK_UNMAPPED_BASE even though
that adress was in the middle of the bss.  Now that has been fixed, "too low"
isn't a concern anymore.

However, I'm not sure moving the TASK_UNMAPPED_BASE below the text section
will work.  It's used for more than just loading shared libs.  Anonymous mmap
areas and the heap are all located relative to it.


> Is there a way I can tell glibc to load it's libs around TASK_UNMAPED_BASE?
> Currently only ld.so follows TASK_UNMAPED_BASE, the other libs always
> loads at 0x0fxxxxxx. Glibc/ld.so version is 2.2.3

IIRC, only ppc32 loads it's libs this way.  For example, ppc64 loads all
its libs above TASK_UNMAPPED_BASE.


Hälsningar,

Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Anton Blanchard]

> The problem with a TASK_UNMAPPED_BASE that was "too low" was referring to
> the bug where we always loaded ld.so at TASK_UNMAPPED_BASE even though
> that adress was in the middle of the bss.  Now that has been fixed, "too low"
> isn't a concern anymore.
>
> However, I'm not sure moving the TASK_UNMAPPED_BASE below the text section
> will work.  It's used for more than just loading shared libs.  Anonymous mmap
> areas and the heap are all located relative to it.

That reminded me of a patch wli did to rearrange how things are
allocated. I wonder if doing something radical like this will work on
ppc32.

Anton

diff -purN -X /home/mbligh/.diff.exclude 400-less_bouncy/arch/i386/Kconfig 410-topdown/arch/i386/Kconfig
--- 400-less_bouncy/arch/i386/Kconfig	2003-11-24 16:36:16.000000000 -0800
+++ 410-topdown/arch/i386/Kconfig	2003-11-25 14:24:37.000000000 -0800
@@ -1542,6 +1542,15 @@ config SCHEDSTATS
 	  application, you can say N to avoid the very slight overhead
 	  this adds.

+config MMAP_TOPDOWN
+	bool "Top-down vma allocation"
+	help
+	  Say Y here to have the kernel change its vma allocation policy
+	  to allocate vma's from the top of the address space down, and
+	  to shove the stack low so as to conserve virtualspace. This is
+	  risky because various apps, including a number of versions of
+	  ld.so, depend on the kernel's bottom-up behavior.
+
 config X86_EXTRA_IRQS
 	bool
 	depends on X86_LOCAL_APIC || X86_VOYAGER
diff -purN -X /home/mbligh/.diff.exclude 400-less_bouncy/arch/i386/mm/pgtable.c 410-topdown/arch/i386/mm/pgtable.c
--- 400-less_bouncy/arch/i386/mm/pgtable.c	2003-10-01 11:34:29.000000000 -0700
+++ 410-topdown/arch/i386/mm/pgtable.c	2003-11-25 14:24:37.000000000 -0800
@@ -237,3 +237,60 @@ void pgd_free(pgd_t *pgd)
 	/* in the non-PAE case, clear_page_tables() clears user pgd entries */
 	kmem_cache_free(pgd_cache, pgd);
 }
+
+#define GLIBC_BUFFER	(32*1024*1024)
+
+/*
+ * This is total crap; it needs to use the free area cache to mitigate
+ * catastrophic O(n) search with many vmas.
+ */
+unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
+					unsigned long len, unsigned long pgoff,
+					unsigned long flags)
+{
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma, *prev;
+
+	len = PAGE_ALIGN(len);
+	addr = PAGE_ALIGN(addr);
+
+	if (len > TASK_SIZE)
+		return -ENOMEM;
+
+	if (addr) {
+		struct vm_area_struct *vma;
+		vma = find_vma(mm, addr);
+		if (TASK_SIZE - len >= addr &&
+				(!vma || addr + len <= vma->vm_start))
+			goto out;
+	}
+
+	if (!mm->mmap) {
+		if (len > TASK_SIZE - GLIBC_BUFFER)
+			addr = TASK_SIZE - len;
+		else
+			addr = TASK_SIZE - GLIBC_BUFFER - len;
+		goto out;
+	}
+
+	addr = -ENOMEM;
+	for (prev = NULL, vma = mm->mmap; vma; prev = vma, vma = vma->vm_next) {
+		unsigned long lo, hi;
+		lo = prev ? prev->vm_end : 0;
+		hi = vma->vm_start;
+		if (hi - lo >= len && (addr == -ENOMEM || addr < hi - len))
+			addr = hi - len;
+	}
+	/*
+	 * We're at the last one; let's try the top, but only if nothing
+	 * else can be found (to respect GLIBC_BUFFER).
+	 */
+	if (prev && TASK_SIZE - prev->vm_end >= len) {
+		if (TASK_SIZE - GLIBC_BUFFER - prev->vm_end >= len)
+			addr = TASK_SIZE - GLIBC_BUFFER - len;
+		else if (addr == -ENOMEM)
+			addr = TASK_SIZE - len;
+	}
+out:
+	return addr;
+}
diff -purN -X /home/mbligh/.diff.exclude 400-less_bouncy/fs/binfmt_elf.c 410-topdown/fs/binfmt_elf.c
--- 400-less_bouncy/fs/binfmt_elf.c	2003-11-24 16:34:48.000000000 -0800
+++ 410-topdown/fs/binfmt_elf.c	2003-11-25 14:24:37.000000000 -0800
@@ -7,6 +7,7 @@
  * Tools".
  *
  * Copyright 1993, 1994: Eric Youngdale (ericy@cais.com).
+ * Top-down vma allocation support, William Irwin, IBM, 2003
  */

 #include <linux/module.h>
@@ -329,8 +330,13 @@ static unsigned long load_elf_interp(str
 	if (retval < 0)
 		goto out_close;

+#ifndef CONFIG_MMAP_TOPDOWN
 	eppnt = elf_phdata;
 	for (i=0; i<interp_elf_ex->e_phnum; i++, eppnt++) {
+#else
+	eppnt = &elf_phdata[interp_elf_ex->e_phnum - 1];
+	for (i = interp_elf_ex->e_phnum - 1; i >= 0; --i, --eppnt) {
+#endif
 	  if (eppnt->p_type == PT_LOAD) {
 	    int elf_type = MAP_PRIVATE | MAP_DENYWRITE;
 	    int elf_prot = 0;
@@ -344,7 +350,8 @@ static unsigned long load_elf_interp(str
 	    if (interp_elf_ex->e_type == ET_EXEC || load_addr_set)
 	    	elf_type |= MAP_FIXED;

-	    map_addr = elf_map(interpreter, load_addr + vaddr, eppnt, elf_prot, elf_type);
+	    map_addr = load_addr_set ? load_addr + vaddr : 0;
+	    map_addr = elf_map(interpreter, map_addr, eppnt, elf_prot, elf_type);
 	    if (BAD_ADDR(map_addr))
 	    	goto out_close;

diff -purN -X /home/mbligh/.diff.exclude 400-less_bouncy/include/asm-i386/a.out.h 410-topdown/include/asm-i386/a.out.h
--- 400-less_bouncy/include/asm-i386/a.out.h	2002-12-09 18:45:54.000000000 -0800
+++ 410-topdown/include/asm-i386/a.out.h	2003-11-25 14:24:37.000000000 -0800
@@ -19,7 +19,16 @@ struct exec

 #ifdef __KERNEL__

+/*
+ * Typical ELF load address is 0x8048000, which is 128MB + 288KB.
+ * Shoving the stack very close to it lets smaller programs fit in
+ * a single pagetable page's worth of virtualspace.
+ */
+#ifdef CONFIG_MMAP_TOPDOWN
+#define STACK_TOP	((128 << 20) + (256 << 10))
+#else
 #define STACK_TOP	TASK_SIZE
+#endif

 #endif

diff -purN -X /home/mbligh/.diff.exclude 400-less_bouncy/include/asm-i386/pgtable.h 410-topdown/include/asm-i386/pgtable.h
--- 400-less_bouncy/include/asm-i386/pgtable.h	2003-10-14 15:50:32.000000000 -0700
+++ 410-topdown/include/asm-i386/pgtable.h	2003-11-25 14:24:37.000000000 -0800
@@ -25,6 +25,10 @@
 #include <linux/list.h>
 #include <linux/spinlock.h>

+#ifdef CONFIG_MMAP_TOPDOWN
+#define HAVE_ARCH_UNMAPPED_AREA
+#endif
+
 /*
  * ZERO_PAGE is a global shared page that is always zero: used
  * for zero-mapped memory areas etc..


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Joakim Tjernlund]

> On Thu, 2004-02-05 at 02:57, Joakim Tjernlund wrote:
> > Too low, does that mean TASK_UNMAPED_BASE < 0x00100000 will fail
> > with huge bss's as well? Or will it just fail for 0x30000000 =>
> > TASK_UNMAPED_BASE <= 0x10000000?
> >
> > To me it seems like it is a good idea to change(at least in 2.6
> > where the bugs you mentioned has been fixed) TASK_UNMAPED_BASE to
> > 0x00100000(or lower).
>
> The problem with a TASK_UNMAPPED_BASE that was "too low" was referring
> to the bug where we always loaded ld.so at TASK_UNMAPPED_BASE even
> though that adress was in the middle of the bss. Now that has been
> fixed, "too low" isn't a concern anymore.

OK, thanks.

> However, I'm not sure moving the TASK_UNMAPPED_BASE below the text
> section will work. It's used for more than just loading shared libs.
> Anonymous mmap areas and the heap are all located relative to it.

hmm, I have tried several values, for instance anything 0x2000 between
(0x10000000-0x16000) appears to work. (0x10000000-0x15000) don't boot,
but then I am on 2.4, so maybe it's the huge bss bug that bites me.

> > Is there a way I can tell glibc to load it's libs around
> > TASK_UNMAPED_BASE? Currently only ld.so follows TASK_UNMAPED_BASE,
> > the other libs always loads at 0x0fxxxxxx. Glibc/ld.so version is
> > 2.2.3
>
> IIRC, only ppc32 loads it's libs this way. For example, ppc64 loads
> all its libs above TASK_UNMAPPED_BASE.

Well, I am ppc32.

 Jocke

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: TASK_UNMAPPED_BASE

[Joakim Tjernlund]

> > The problem with a TASK_UNMAPPED_BASE that was "too low"
> > was referring to the bug where we always loaded ld.so at
> > TASK_UNMAPPED_BASE even though that adress was in the middle of the
> > bss. Now that has been fixed, "too low" isn't a concern anymore.
> >
> > However, I'm not sure moving the TASK_UNMAPPED_BASE below the text
> > section will work. It's used for more than just loading shared libs.
> > Anonymous mmap areas and the heap are all located relative to it.
>
> That reminded me of a patch wli did to rearrange how things are
> allocated. I wonder if doing something radical like this will work on
> ppc32.
[SNIP patch]

Hi Anton

I tried your patch on my 2.4 kernel.
uClibc boots fine with the libs loaded towards lower addresses.

glibc won't boot, hangs direcly after mount.

 Jocke

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/