aranym vs atafb

[Stephen R Marenka]

Howdy,

I've been trying to get d-i initrds to work with aranym without
trashing the screen [0]. I noticed something interesting in my testing
today.

[0] <http://people.debian.org/~smarenka/d-i/aranym/>

With the same kernel (2.6.18-4) and args ...

Args = root=/dev/ram load_ramdisk=1 ramdisk_size=20000 debug=par
video=atafb:vga16 stram_swap=0 console=tty
debian-installer/framebuffer=false init=/bin/sh

The result is a trashed screen when atafb loads.

| atafb: screen_base 01700000 real_screen_base 01700000 screen_len 311296
| Determined 640x480, depth 4
|    virtual 640x972
| Console: switching to colour frame buffer device 80x30


If I drop the Ramdisk = parameter from the aranym config, atafb loads as
follows, and works just fine.

| atafb: screen_base 00c80000 real_screen_base 00c80000 screen_len 311296
| Determined 640x480, depth 4
|    virtual 640x972
| Console: switching to colour frame buffer device 80x30


I tried all the atafb configurations listed, but I couldn't get a
working result and have a ramdisk. The Floppy setting doesn't trash
the screen but we don't have any initrd's small enough.

I don't suppose we can build a bootable cdrom for atari?

Any ideas?

Thanks,

Stephen

--
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@...>

[Michael Schmitz-6]

Hi,

> I've been trying to get d-i initrds to work with aranym without
> trashing the screen [0]. I noticed something interesting in my testing
> today.
>
> [0] <http://people.debian.org/~smarenka/d-i/aranym/>
>
> With the same kernel (2.6.18-4) and args ...
>
> Args = root=/dev/ram load_ramdisk=1 ramdisk_size=20000 debug=par
> video=atafb:vga16 stram_swap=0 console=tty
> debian-installer/framebuffer=false init=/bin/sh
>
> The result is a trashed screen when atafb loads.
>
> | atafb: screen_base 01700000 real_screen_base 01700000 screen_len 311296
> | Determined 640x480, depth 4
> |    virtual 640x972
> | Console: switching to colour frame buffer device 80x30

IIRC any addresses in that range (i.e. above 0xffffff) are aliased down to
fit in 24 bit (ST-RAM on the Falcon only decodes 24 bit, and the VIDEL
needs to use ST-RAM). Basically, you used up all available ST-RAM with the
ramdisk and now force the framebuffer to use an invalid address (one which
you can perfectly well write to, but the VIDEL cannot read from there).

What you see on the screen is whatever is located at address 0x00700000
and thereabouts (may be kernel memory, may be data/buffer cache).

The ramdisk load code needs to make sure a ramdisk is not loaded where it
might interfere with other uses of ST-RAM (i.e. frame buffer or DMA bounce
buffers for SCSI). Where does the ramdisk get loaded at, anyway? Is the
kernel loaded in ST-RAM also?

> If I drop the Ramdisk = parameter from the aranym config, atafb loads as
> follows, and works just fine.
>
> | atafb: screen_base 00c80000 real_screen_base 00c80000 screen_len 311296
> | Determined 640x480, depth 4
> |    virtual 640x972
> | Console: switching to colour frame buffer device 80x30

That screen base address is fine to use for atafb.

> I tried all the atafb configurations listed, but I couldn't get a
> working result and have a ramdisk. The Floppy setting doesn't trash
> the screen but we don't have any initrd's small enough.

We need to load them somewhere else, FWIS. Meaning in TT-RAM.

> I don't suppose we can build a bootable cdrom for atari?

Uh, nope. CD-ROM drivers are a bad can of worms as it were, no idea what
would even be supported by the CT60 (and it's all closed source). Unless
you count booting from MiNT (assuming that can even be done).

        Michael


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stephen R Marenka]

On Thu, Dec 27, 2007 at 04:21:13AM +0100, Michael Schmitz wrote:

> > I've been trying to get d-i initrds to work with aranym without
> > trashing the screen [0]. I noticed something interesting in my testing
> > today.

> IIRC any addresses in that range (i.e. above 0xffffff) are aliased down to
> fit in 24 bit (ST-RAM on the Falcon only decodes 24 bit, and the VIDEL
> needs to use ST-RAM). Basically, you used up all available ST-RAM with the
> ramdisk and now force the framebuffer to use an invalid address (one which
> you can perfectly well write to, but the VIDEL cannot read from there).
>
> What you see on the screen is whatever is located at address 0x00700000
> and thereabouts (may be kernel memory, may be data/buffer cache).

That totally makes sense.

> The ramdisk load code needs to make sure a ramdisk is not loaded where it
> might interfere with other uses of ST-RAM (i.e. frame buffer or DMA bounce
> buffers for SCSI). Where does the ramdisk get loaded at, anyway? Is the
> kernel loaded in ST-RAM also?

How do I find out?

I put all the relevant parts including the boot log at
<http://people.debian.org/~smarenka/d-i/aranym/>.

> > I tried all the atafb configurations listed, but I couldn't get a
> > working result and have a ramdisk. The Floppy setting doesn't trash
> > the screen but we don't have any initrd's small enough.
>
> We need to load them somewhere else, FWIS. Meaning in TT-RAM.

Is that kernel hacking or a parameter?

> > I don't suppose we can build a bootable cdrom for atari?
>
> Uh, nope. CD-ROM drivers are a bad can of worms as it were, no idea what
> would even be supported by the CT60 (and it's all closed source). Unless
> you count booting from MiNT (assuming that can even be done).

Pretty much what I figured.

Thanks,

Stephen

--
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@...>

[Michael Schmitz-6]

> > IIRC any addresses in that range (i.e. above 0xffffff) are aliased down to
> > fit in 24 bit (ST-RAM on the Falcon only decodes 24 bit, and the VIDEL
> > needs to use ST-RAM). Basically, you used up all available ST-RAM with the
> > ramdisk and now force the framebuffer to use an invalid address (one which
> > you can perfectly well write to, but the VIDEL cannot read from there).
> >
> > What you see on the screen is whatever is located at address 0x00700000
> > and thereabouts (may be kernel memory, may be data/buffer cache).
>
> That totally makes sense.

Well, no - that totally is borked hardware design. The Falcon is an
especially sick beast but the TT had the same limitation, only a
different video chipdet.
OTOH, borked hardware design may well have been a hallmark of m68k
personal computers (look at the Mac for the real weird stuff). Whatever.

> > The ramdisk load code needs to make sure a ramdisk is not loaded where it
> > might interfere with other uses of ST-RAM (i.e. frame buffer or DMA bounce
> > buffers for SCSI). Where does the ramdisk get loaded at, anyway? Is the
> > kernel loaded in ST-RAM also?
>
> How do I find out?

That's a parameter to ataboot (or the equivalent boot code in ARAnyM. IIRC
-s loads the kernel in ST-RAM. If there is no code to load the ramdisk in
TT-RAM we'd better add code to move it around after the kernel started to
initialize ....

On second thought, that would be a sick hack deserving of m68k hardware
designers. We did already have a provision to reserve a chunk of ST-RAM
for special purposes like framebuffer, you just have to disable that with
2.6 kernels (explicitly, by adding stram_swap=0 to the kernel parameters).

That code needs to be reactivated, it seems. Plus the bootstrap needs to
take the size of reserved ST-RAM into account when loading the initrd
image, I guess. At least we can then figure out that there is not enough
ST-RAM free to run Linux, and bail out. Or kick the ramdisk out of the way
instead :->

> I put all the relevant parts including the boot log at
> <http://people.debian.org/~smarenka/d-i/aranym/>.

Thanks, all I see from that is the ramdisk driver is initialized after the
framebuffer, but the ramdisk (non-compressed??) was already present prior
to that. I'll grab your kernel and ramdisk and play with it for a bit on
my Powerbook - incidentially, how much FastRAM have you specified for
ARAnyM?

> > We need to load them somewhere else, FWIS. Meaning in TT-RAM.
>
> Is that kernel hacking or a parameter?

A bootstrap parameter, rather. Might be easy enough to add in ARAnyM. If
that works (i.e. loading the ramdisk where it won't interfere with the
kernel drivers' needs) we could think about adding some code to relocate
the ramdisk. At the time when the framebuffer loads, the kernel memory
management has already been initialized so it's going to be more than just
moving stuff around and adjusting a few pointers.
Might be best to detect this situation early (in the early arch init) and
fix it before it really hurts. I'll look what I can come up with - for
anything memory management related I'd need RomanZ's help anyway.

        Michael


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Schmitz-6]

> > > The ramdisk load code needs to make sure a ramdisk is not loaded where it
> > > might interfere with other uses of ST-RAM (i.e. frame buffer or DMA bounce
> > > buffers for SCSI). Where does the ramdisk get loaded at, anyway? Is the
> > > kernel loaded in ST-RAM also?
> >
> > How do I find out?
>
> That's a parameter to ataboot (or the equivalent boot code in ARAnyM. IIRC
> -s loads the kernel in ST-RAM. If there is no code to load the ramdisk in
> TT-RAM we'd better add code to move it around after the kernel started to
> initialize ....

After consulting the source, I found the hidden bit of information in the
log:

Linux version 2.6.18-4-atari (Debian 2.6.18.dfsg.1-11) (waldi@...)
(gcc version 3.3.6 (Debian 1:3.3.6-15)) #1 Thu Feb 22 23:37:58 CET 2007
Atari hardware found: VIDEL STDMA-SCSI ST_MFP STND_DMA YM2149 PCM CODEC
DSP56K ANALOG_JOY Blitter tried to read byte from register ff8a00 at
0072ca
BLITTER IDE TT_CLK FDC_SPEED
initrd: 01000000 - 017e9000

(found in arch/m68k/kernel/setup.c)

That address is a virtual address, but (at least on my setup) the kernel
virtual addresses are identity mapped to physical. So the ramdisk
(compressed) resides in TT RAM or FastRAM. The shit hits the fan right
here, I presume:

checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like an initrd
Freeing initrd memory: 2025k freed

(happens in init/initramfs.c:populate_rootfs() as it were)

That does probably steal our precious ST-RAM space.

The good news: the ramdisk data is already where I suggested it should be,
so no changes to the bootstrap needed. The bad news: populate_rootfs()
just dumps the data to the buffer cache by generic sys_open()
and sys_write() - we cannot mess with those. So no easy workaround that I
can see.

I guess I'll have to just allocate the required ST-RAM for atafb early, or
make the stram_swap allocator work again, at least as DMA memory allocator
(swapping just won't work anymore without me learning more about VFS that
I can currently spend time on). I'll think about it some more ...

        Michael



--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stephen R Marenka]

On Fri, Dec 28, 2007 at 04:09:21AM +0100, Michael Schmitz wrote:

> (found in arch/m68k/kernel/setup.c)
>
> That address is a virtual address, but (at least on my setup) the kernel
> virtual addresses are identity mapped to physical. So the ramdisk
> (compressed) resides in TT RAM or FastRAM. The shit hits the fan right
> here, I presume:
>
> checking if image is initramfs...it isn't (bad gzip magic numbers); looks
> like an initrd
> Freeing initrd memory: 2025k freed
>
> (happens in init/initramfs.c:populate_rootfs() as it were)
>
> That does probably steal our precious ST-RAM space.

Would using an initramfs help? I can certainly build an initrd that way
(how well tested that all is on m68k is a different beast!).

> The good news: the ramdisk data is already where I suggested it should be,
> so no changes to the bootstrap needed. The bad news: populate_rootfs()
> just dumps the data to the buffer cache by generic sys_open()
> and sys_write() - we cannot mess with those. So no easy workaround that I
> can see.
>
> I guess I'll have to just allocate the required ST-RAM for atafb early, or
> make the stram_swap allocator work again, at least as DMA memory allocator
> (swapping just won't work anymore without me learning more about VFS that
> I can currently spend time on). I'll think about it some more ...

I guess I stepped in it good!

Thanks,

Stephen

--
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@...>

[Stephen R Marenka]

On Fri, Dec 28, 2007 at 12:19:18AM +0100, Michael Schmitz wrote:

> OTOH, borked hardware design may well have been a hallmark of m68k
> personal computers (look at the Mac for the real weird stuff). Whatever.

What else is there to say? ;)

Pushing the limits with underpowered hardware!

Peace,

Stephen

--
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@...>

[Petr Stehlik]

Stephen R Marenka píše v St 26. 12. 2007 v 15:40 -0600:

> I've been trying to get d-i initrds to work with aranym without
> trashing the screen [0]. I noticed something interesting in my testing
> today.
>
> [0] <http://people.debian.org/~smarenka/d-i/aranym/>
>
> With the same kernel (2.6.18-4) and args ...
>
> Args = root=/dev/ram load_ramdisk=1 ramdisk_size=20000 debug=par
> video=atafb:vga16 stram_swap=0 console=tty
> debian-installer/framebuffer=false init=/bin/sh
>
> The result is a trashed screen when atafb loads.

I have noticed that you have 256 MB of FastRAM. When you change it to 64
MB it starts working correctly (that's what I have just found by trial
and error). I don't know (yet) if it's bug in ARAnyM LILO or somewhere
in linux-m68k...

Petr



--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Stehlik]

Michael Schmitz píše v Pá 28. 12. 2007 v 04:09 +0100:

> That does probably steal our precious ST-RAM space.
>
> I guess I'll have to just allocate the required ST-RAM for atafb early

Look at this:

64 MB of FastRAM:
  Memory: 68184k/68252k available (1956k kernel code, 9568k data, 100k
init)
  atafb: screen_base 00680000 real_screen_base 00680000 screen_len
311296

128 MB: screen_base 00b00000
192 MB: screen_base 01700000
256 MB: screen_base 01600000

So the question is how the atafb decides where to put the videoram and
why is it related to FastRAM size...

BTW, by further playing with the -F parameter of ARAnyM I've noticed
that if the total RAM is <= 64 MB (i.e. FastRAM is <= 50 MB) then the
screen_base is at 0x600000 but as soon as total RAM is 65 MB the
screen_base moves up by 0x080000. And when it hits 108 MB of total RAM
it moves the screen_base up by another 0x080000 (to 0x700000). So there
seems to be a "clever" algorithm somewhere in atafb that was not tested
for real large FastRAM sizes?

Petr



--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Stehlik]

Petr Stehlik píše v Pá 28. 12. 2007 v 10:42 +0100:
> 128 MB: screen_base 00b00000
> 192 MB: screen_base 01700000
> 256 MB: screen_base 01600000
>
> So the question is how the atafb decides where to put the videoram and
> why is it related to FastRAM size...

I have just 2.6.22 source and there the screen_base is set as follows:

screen_base = atari_stram_alloc(mem_req, "atafb");

so if this is in 2.6.18-m68k then it looks like a bug in the
atari_stram_alloc() to me.

Petr



--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Geert Uytterhoeven]

On Fri, 28 Dec 2007, Petr Stehlik wrote:

> Petr Stehlik p�e v P� 28. 12. 2007 v 10:42 +0100:
> > 128 MB: screen_base 00b00000
> > 192 MB: screen_base 01700000
> > 256 MB: screen_base 01600000
> >
> > So the question is how the atafb decides where to put the videoram and
> > why is it related to FastRAM size...
>
> I have just 2.6.22 source and there the screen_base is set as follows:
>
> screen_base = atari_stram_alloc(mem_req, "atafb");
>
> so if this is in 2.6.18-m68k then it looks like a bug in the
> atari_stram_alloc() to me.

atari_stram_alloc() allocates GFP_DMA'ble memory using __get_dma_pages(), as atafb is initialized after memory initialization.

If Fast RAM doesn't support DMA, it should be added as non-DMA'ble
memory.

Gr{oetje,eeting}s,

                                                Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

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

[Stephen R Marenka]

On Fri, Dec 28, 2007 at 10:25:14AM +0100, Petr Stehlik wrote:

> Stephen R Marenka píše v St 26. 12. 2007 v 15:40 -0600:
>
> > I've been trying to get d-i initrds to work with aranym without
> > trashing the screen [0]. I noticed something interesting in my testing
> > today.
> >
> > [0] <http://people.debian.org/~smarenka/d-i/aranym/>
> >
> > With the same kernel (2.6.18-4) and args ...
> >
> > Args = root=/dev/ram load_ramdisk=1 ramdisk_size=20000 debug=par
> > video=atafb:vga16 stram_swap=0 console=tty
> > debian-installer/framebuffer=false init=/bin/sh
> >
> > The result is a trashed screen when atafb loads.
>
> I have noticed that you have 256 MB of FastRAM. When you change it to 64
> MB it starts working correctly (that's what I have just found by trial
> and error). I don't know (yet) if it's bug in ARAnyM LILO or somewhere
> in linux-m68k...

You're totally awesome! That's what I really needed at the moment.

Thanks,

Stephen

--
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@...>

[Petr Stehlik]

Geert Uytterhoeven píše v Pá 28. 12. 2007 v 14:27 +0100:

> If Fast RAM doesn't support DMA

VIDEL has just 23 address wires...

> it should be added as non-DMA'ble memory.

where can this be set? The bootstrap uses the following struct for
passing the available memory to kernel and it doesn't contain any flags
like DMA:

struct mem_info {
        uint32 addr; /* physical address of memory chunk */
        uint32 size; /* length of memory chunk (in bytes) */
};

Petr



--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Schmitz-6]

Hi,

> > > So the question is how the atafb decides where to put the videoram and
> > > why is it related to FastRAM size...

Because __get_free_pages and friends allocate memory off the top of RAM?
Would that explain the behavior?

> >
> > I have just 2.6.22 source and there the screen_base is set as follows:
> >
> > screen_base = atari_stram_alloc(mem_req, "atafb");
> >
> > so if this is in 2.6.18-m68k then it looks like a bug in the
> > atari_stram_alloc() to me.
>
> atari_stram_alloc() allocates GFP_DMA'ble memory using __get_dma_pages(), as atafb is initialized after memory initialization.

Indeed. The only clean way out is to guarantee that __get_dma_pages() only
returns memory below the ST-RAM limit. max_dma_addr used tio reflect that
in the early days, but recent kernels treat the whole of RAM as DMA
memory. ISTR there was a reason for this ...

> If Fast RAM doesn't support DMA, it should be added as non-DMA'ble
> memory.

I'll try and see if that does work, now. Might have been changed as a
result of discontig memory support been broken in early 2.6.

The other way out is to allocate ST-RAM for atafb early (i.e. in setup.c)
and use that. Tried it, it does work. I can send a patch for Stephen to
get ahead with d-i testing if I cannot get the distinction between DMA
memory and FastRAM to work out.

        Michael



--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Schmitz-6]

> > If Fast RAM doesn't support DMA
>
> VIDEL has just 23 address wires...

Sure, that's why we need to make sure the frame buffer is addressable by
these 23 bits.

> > it should be added as non-DMA'ble memory.
>
> where can this be set? The bootstrap uses the following struct for
> passing the available memory to kernel and it doesn't contain any flags
> like DMA:

It does not matter where the bootstrap places the ramdisk data. It's
copied to a different (allocated) spot later by the kernel. It just so
happens that that spot falls into ST-RAM, and steals our precious ST-RAM.

Several fixes are possible; I'll try the most generic one next.

        Michael



--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Stehlik]

Michael Schmitz píše v So 29. 12. 2007 v 00:50 +0100:
> > > If Fast RAM doesn't support DMA
> >
> > VIDEL has just 23 address wires...
>
> Sure, that's why we need to make sure the frame buffer is addressable by
> these 23 bits.

Sure. I just didn't want to say that Fast RAM doesn't support DMA
generally - it might, for some chips, who knows :-)

> > > it should be added as non-DMA'ble memory.
> >
> > where can this be set? The bootstrap uses the following struct for
> > passing the available memory to kernel and it doesn't contain any flags
> > like DMA:
>
> It does not matter where the bootstrap places the ramdisk data.

I wasn't talking about ramdisk data but about the way the bootstrap
reports to kernel the available memory.

> copied to a different (allocated) spot later by the kernel. It just so
> happens that that spot falls into ST-RAM, and steals our precious ST-RAM.

Do you think we ran out of ST-RAM by adding more Fast RAM? I doubt that.

> Several fixes are possible; I'll try the most generic one next.

I am curious what the fix will be (with regard to that Geert's remark).

Petr



--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Schmitz-6]

Hi all,

> > Several fixes are possible; I'll try the most generic one next.
>
> I am curious what the fix will be (with regard to that Geert's remark).

I'm getting a bit confused - the good old mach_max_dma_address variable
does not seem to get used in the recent kernels anymore at all. Could a mm
expert please unravel this mystery?

Cooked up the following patch to make the m68k mm code honor the DMA limit
as it used to:

--- arch/m68k/mm/motorola.c.maxdma.org 2007-12-31 20:10:18.000000000 +1300
+++ arch/m68k/mm/motorola.c 2007-12-31 20:12:00.000000000 +1300
@@ -43,6 +43,8 @@
 EXPORT_SYMBOL(mm_cachebits);
 #endif

+extern unsigned long mach_max_dma_addr;
+
 /* size of memory already mapped in head.S */
 #define INIT_MAPPED_SIZE (4UL<<20)

@@ -296,7 +298,15 @@
  printk ("before free_area_init\n");
 #endif
  for (i = 0; i < m68k_num_memory; i++) {
- zones_size[ZONE_DMA] = m68k_memory[i].size >> PAGE_SHIFT;
+ /* MSch Hack */
+ if ( m68k_memory[i].addr < mach_max_dma_addr
+ && (m68k_memory[i].addr+m68k_memory[i].size) <= mach_max_dma_addr ) {
+ zones_size[ZONE_DMA]    = m68k_memory[i].size >> PAGE_SHIFT;
+ zones_size[ZONE_NORMAL] = 0;
+ } else {
+ zones_size[ZONE_DMA]    = 0;
+ zones_size[ZONE_NORMAL] = m68k_memory[i].size >> PAGE_SHIFT;
+ }
  free_area_init_node(i, pg_data_map + i, zones_size,
     m68k_memory[i].addr >> PAGE_SHIFT, NULL);
  }

I'm blatantly assuming I can set the DMA vs. normal zone sizes for memory
nodes here to achieve flagging certain zones for no DMA action.

Using this patch on my kernel results in a panic when atafb_init attempts
to allocate screen memory, with the following diagnostics from the
allocator:

Mem-info:
DMA per-cpu:
CPU    0: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:   1
usd:   0
Normal per-cpu:
CPU    0: Hot: hi:   90, btch:  15 usd:   0   Cold: hi:   30, btch:   7
usd:   0
Active:128 inactive:1897 dirty:0 writeback:0 unstable:0
 free:65505 slab:109 mapped:0 pagetables:0 bounce:0
DMA free:0kB min:108kB low:132kB high:160kB active:512kB inactive:7580kB
present:14212kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Normal free:262020kB min:1980kB low:2472kB high:2968kB active:0kB
inactive:8kB present:259840kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 0*4096kB = 0kB
Normal: 1*4kB 4*8kB 2*16kB 0*32kB 1*64kB 0*128kB 1*256kB 1*512kB 1*1024kB
1*2048kB 63*4096kB = 262020kB
Swap cache: add 0, delete 0, find 0/0, race 0+0
Free swap  = 0kB
Total swap = 0kB
Free swap:            0kB
69120 pages of RAM
65535 free pages
1389 reserved pages
0 pages shared
0 pages swap cached
Kernel panic - not syncing: Cannot allocate screen memory

(I am using 256 MB of FastRAM here)

>From the diagnostics it appears that 14 MB of ST-RAM are present, 7.5MB of
which are inactive (is that the ramdisk, perhaps?). Why is there no free
RAM in the DMA zone?
Booting with no ramdisk does still work with the patched kernel, so I
cannot have totally messed up memory management.

Anyway, what would be the correct way to set up the FastRAM zone as
non-DMA memory? I must have made some mistake in the code above.

Looking at the bright side: we now do at least get the framebuffer to
confess it's not going to work :-)

Regarding booter options: is there an option to load the kernel to FastRAM
as opposed to ST-RAM, Petr? What is the default here?

As to your question regarding the most generic fix: if there really is not
enough ST-RAM (i.e. the available space is taken by the kernel and the
ramdisk, after 'unpacking' the ramdisk to the buffer cache) we'd need to
either make the ramdisk unpack go to non-DMA memory (no idea here;
ideally the buffer cache should not have a preference for DMA memory in
this case), or reserve a chunk of memory up front (tried that in a hackish
way).

Awaiting the verdict of the mm experts...

Happy New Year to y'all

        Michael




--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...