2.3.27 on CHRP Longtrail

2.3.27 on CHRP Longtrail

[Geert Uytterhoeven]

Plain 2.3.27 panics right after calibrating the delay loop. At first sight, it
seems to crash in clear_bit() on address 0xa058, hence probably a NULL pointer
problem somewhere at a higher level. This is being investigated.

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: 2.3.27 on CHRP Longtrail

[Geert Uytterhoeven]

On Fri, 12 Nov 1999, Geert Uytterhoeven wrote:
> Plain 2.3.27 panics right after calibrating the delay loop. At first sight, it
> seems to crash in clear_bit() on address 0xa058, hence probably a NULL pointer
> problem somewhere at a higher level. This is being investigated.

The problem is in free_all_bootmem(): we have MAX_DMA_ADDRESS == 0xffffffff
and virt_to_phys() subtracts KERNELBASE from it. I don't understand (yet)
what's all that bootmem stuff doing...

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Bootmem problem (was: Re: 2.3.27 on CHRP Longtrail)

[Geert Uytterhoeven]

On Fri, 12 Nov 1999, Geert Uytterhoeven wrote:
> On Fri, 12 Nov 1999, Geert Uytterhoeven wrote:
> > Plain 2.3.27 panics right after calibrating the delay loop. At first sight, it
> > seems to crash in clear_bit() on address 0xa058, hence probably a NULL pointer
> > problem somewhere at a higher level. This is being investigated.
> 
> The problem is in free_all_bootmem(): we have MAX_DMA_ADDRESS == 0xffffffff
> and virt_to_phys() subtracts KERNELBASE from it. I don't understand (yet)
> what's all that bootmem stuff doing...

Woops, misguided by the macros... Forget about this.

The real problem is even earlier: ClearPageReserved() is a macro around
clear_bit(), and it crashes at the first invocation (i == 0), with a bad access
at address 0xa058. As I'm no mm expert, I'm clueless.

| unsigned long __init free_all_bootmem (void)
| {
|         struct page * page;
|         unsigned long i, count, total = 0;
| 
|         if (!bootmem_map) BUG();
| 
|         page = mem_map;
|         count = 0;
|         for (i = 0; i < max_low_pfn; i++, page++) {
|                 if (!test_bit(i, bootmem_map)) {
|                         count++;
|                         ClearPageReserved(page);
                          **BANG***
|                         set_page_count(page, 1);
|                         if (i >= (virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT))
|                                 clear_bit(PG_DMA, &page->flags);
|                         __free_page(page);
|                 }
|         }
|         total += count;

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: 2.3.27 on CHRP Longtrail

[Ani Joshi]

On Fri, 12 Nov 1999, Geert Uytterhoeven wrote:

> The problem is in free_all_bootmem(): we have MAX_DMA_ADDRESS == 0xffffffff
> and virt_to_phys() subtracts KERNELBASE from it. I don't understand (yet)
> what's all that bootmem stuff doing...

	this is interesting because I recently had a problem sorta like
this on pmacs with some recent 2.3's.  in do_init_bootmem() a call to
remove_mem_piece() uses boot_mapsize as the "size", this locks up on old
non-b&w/imac/g4 powermacs, but I changed the size to boot_mapsize+start
and it fixed it.  I didn't bother debugging remove_mem_piece() since i got
it working, perhaps i'll switch it back adn see where it dies.
	also on a side note, boot_mapsize is initialized through an
init_bootmem() call wich uses __pa(), i recently saw a post from linus
saying that __pa/__va should not ever be used in "real" code as they are
only used in the headers for internal stuff, and he's considering removing
them.  think this is a problem?



ani


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

Re: 2.3.27 on CHRP Longtrail

[Benjamin Herrenschmidt]

Not directly related, but...

While working on OF booting with the iBook (I really want to get rid of
BootX with those new machines, on of the reason beeing a nightmare
compatibiliy problem with the new iMac DV and Swathoo G4s), I quickly
hacked my early boot text mode to work with the OF display.

Basically, that means that it's possible to display debugging text from
almost every point of the kernel initialisation (using mostly
xmon_printf) before the fb is up and running, even while OF output can no
more be used (after MMU init).

It's too hackish for now, and I have no time to post a patch before later
today or this week end, I'll try to clean this a little bit and separate
it from the main bunch of iBook patches since i could be useful for
others too.


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

Re: 2.3.27 on CHRP Longtrail

[Michael Schmitz]

> Basically, that means that it's possible to display debugging text from
> almost every point of the kernel initialisation (using mostly
> xmon_printf) before the fb is up and running, even while OF output can no
> more be used (after MMU init).
> 
> It's too hackish for now, and I have no time to post a patch before later
> today or this week end, I'll try to clean this a little bit and separate
> it from the main bunch of iBook patches since i could be useful for
> others too.

Please do. I tried to use xmon_printf for this very purpose on my Lombard
with 2.3.13 with no success. 

	Michael


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

Re: 2.3.27 on CHRP Longtrail

[BenH]

On Fri, Nov 12, 1999, Michael Schmitz
<schmitz@simul.biophys.uni-duesseldorf.de> wrote:

>Please do. I tried to use xmon_printf for this very purpose on my Lombard
>with 2.3.13 with no success. 

You can do this currently if you have a recent version of xmon (I don't
remember when Paul actually changed xmon to use the early boot text).
Boot with BootX (with no video driver). Make sure the init code in
arch/ppc/xmon/start.c will map the fb and use prom_print().

I've just added the capability to do this when booting from Open Firmware.


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

Re: 2.3.27 on CHRP Longtrail

[Michael Schmitz]

> On Fri, Nov 12, 1999, Michael Schmitz
> <schmitz@simul.biophys.uni-duesseldorf.de> wrote:
> 
> >Please do. I tried to use xmon_printf for this very purpose on my Lombard
> >with 2.3.13 with no success. 
> 
> You can do this currently if you have a recent version of xmon (I don't
> remember when Paul actually changed xmon to use the early boot text).
> Boot with BootX (with no video driver). Make sure the init code in
> arch/ppc/xmon/start.c will map the fb and use prom_print().

I think prom_print was actually what I tried to use but it wasn't
producing any output. I'll try xmon_printf as soon as I find time to play
with 2.3 kernels again. (I'm currently beating on mon to make it play with 
the PMU on Powerbooks ...)

	Michael


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