Aranym, more than 244MB FastRAM, garbled display

Aranym, more than 244MB FastRAM, garbled display

[Kolbjørn Barmen]

I have almost exclusevly been running Aranym "headless" with Linux/m68k on
it (console=nfcon), but the last couple of days I've been preparing a "how
to" for installing gentoo/m68k and so I need interactive console access,
and since nfcon is read-only (will this ever change?), I've had to use the
SDL window.

One thing I have noticed is that if I set FastRAM in aranym config to
something higher than 244 I get garbled display, kinda like frozen random
noise - the kernel does boot in the background though. I tried with
different kernels (only up to 2.6.34 though), and with different versions
of aranym, but it didn't make much difference.

I should perhaps give 2.6.35 or 2.6.36 a go before reporting a bug, but it
does take a while to build so I thought I'd ask anyhow, if this is a known
issue and if there perhaps are any workarounds. Aranym is set with default
video settings, which should correspond to "video=atafb:vga16" as kernel
option I think.

Screenshots:

http://amiga.nvg.org/moro/aranym-244M.png
http://amiga.nvg.org/moro/aranym-245M.png

-- kolla

Re: Aranym, more than 244MB FastRAM, garbled display

[Andreas Schwab]

Kolbjørn Barmen <linux-m68k@kolla.no> writes:

> One thing I have noticed is that if I set FastRAM in aranym config to
> something higher than 244 I get garbled display, kinda like frozen random
> noise - the kernel does boot in the background though. I tried with
> different kernels (only up to 2.6.34 though), and with different versions
> of aranym, but it didn't make much difference.

I have always been using FastRAM = 256 without problems.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Aranym, more than 244MB FastRAM, garbled display

[Kolbjørn Barmen]

On Fri, 1 Oct 2010, Andreas Schwab wrote:

> Kolbjørn Barmen <linux-m68k@kolla.no> writes:
> 
> > One thing I have noticed is that if I set FastRAM in aranym config to
> > something higher than 244 I get garbled display, kinda like frozen random
> > noise - the kernel does boot in the background though. I tried with
> > different kernels (only up to 2.6.34 though), and with different versions
> > of aranym, but it didn't make much difference.
> 
> I have always been using FastRAM = 256 without problems.

Hmf... great :)

Anything other than default in video settings or anything?

-- kolla

Re: Aranym, more than 244MB FastRAM, garbled display

[Thorsten Glaser]

Kolbjørn Barmen dixit:

>Anything other than default in video settings or anything?

I’m now seeing this too, with the vmlinuz-2.6.32-5-atari
(Debian 2.6.32-24+m68k) just built.

This WFM:
[GLOBAL]
FastRAM = 768
[LILO]
Kernel = vmlinuz-2.6.32-5-atari
# these Args for normal X operation
Args = root=/dev/hda1 console=tty debug=par video=atafb:vga2

HTH,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: Aranym, more than 244MB FastRAM, garbled display

[Geert Uytterhoeven]

On Mon, Oct 4, 2010 at 21:49, Thorsten Glaser <tg@mirbsd.de> wrote:
> Kolbjørn Barmen dixit:
>
>>Anything other than default in video settings or anything?
>
> I’m now seeing this too, with the vmlinuz-2.6.32-5-atari
> (Debian 2.6.32-24+m68k) just built.
>
> This WFM:
> [GLOBAL]
> FastRAM = 768
> [LILO]
> Kernel = vmlinuz-2.6.32-5-atari
> # these Args for normal X operation
> Args = root=/dev/hda1 console=tty debug=par video=atafb:vga2

Confirmed with yesterday's 2.6.36-rc6.
The problem starts happening as soon as FastRAM >= 512.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 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

Re: Aranym, more than 244MB FastRAM, garbled display

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>On Mon, Oct 4, 2010 at 21:49, Thorsten Glaser <tg@mirbsd.de> wrote:

>> This WFM:

>> Args = root=/dev/hda1 console=tty debug=par video=atafb:vga2

>The problem starts happening as soon as FastRAM >= 512.

I suspect atafb:vga2 reduces the amount of memory needed enough
for it to work.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: Aranym, more than 244MB FastRAM, garbled display

[Michael Schmitz]

>>> Args = root=/dev/hda1 console=tty debug=par video=atafb:vga2
>
>>The problem starts happening as soon as FastRAM >= 512.
>
> I suspect atafb:vga2 reduces the amount of memory needed enough
> for it to work.

Certainly - 640x480@1bit isn't much. Even less than sthigh IIRC.

I wonder why it does depend on FastRAM size, though. ST-RAM eaten up
by page tables?

BTW: browsing Geert's git tree online, I noticed that my old patch to
reserve some of ST-RAM for use by atafb etc. has never made it into
git. I'll clean that up and resubmit unless Geert has objections.

See: http://marc.info/?l=linux-m68k&m=124072556805722&w=2

The amount of ST-RAM reserved is hardcoded and might need to be increased.

Cheers,

  Michael


>
> bye,
> //mirabilos
> --
> I believe no one can invent an algorithm. One just happens to hit upon it
> when God enlightens him. Or only God invents algorithms, we merely copy them.
> If you don't believe in God, just consider God as Nature if you won't deny
> existence.              -- Coywolf Qi Hunt
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Aranym, more than 244MB FastRAM, garbled display

[Geert Uytterhoeven]

On Thu, Oct 7, 2010 at 09:47, Michael Schmitz <schmitzmic@googlemail.com> wrote:
> BTW: browsing Geert's git tree online, I noticed that my old patch to
> reserve some of ST-RAM for use by atafb etc. has never made it into

That's correct.

> git. I'll clean that up and resubmit unless Geert has objections.

I'm blocked on this follow-up you sent me afterwards (without CC to the list):

| Plus there's still a bug in stram_free_block, let's see if you can spot it :-)

> See: http://marc.info/?l=linux-m68k&m=124072556805722&w=2
>
> The amount of ST-RAM reserved is hardcoded and might need to be increased.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 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

Re: Aranym, more than 244MB FastRAM, garbled display

[Michael Schmitz]

Hi Geert,

>> BTW: browsing Geert's git tree online, I noticed that my old patch to
>> reserve some of ST-RAM for use by atafb etc. has never made it into
>
> That's correct.
>
>> git. I'll clean that up and resubmit unless Geert has objections.
>
> I'm blocked on this follow-up you sent me afterwards (without CC to the list):
>
> | Plus there's still a bug in stram_free_block, let's see if you can spot it :-)

Does not ring any bells ... I'll check my old mbox as soon as I have
access again. I'll add a kernel parameter as well.

Cheers,

  Michael

[PATCH] m68k atari: reserve some ST-RAM early on for device buffer use (was: Re: Aranym, more than 244MB FastRAM, garbled display)

[Michael Schmitz]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

Hi All,
>>> git. I'll clean that up and resubmit unless Geert has objections.
>>>       
>> I'm blocked on this follow-up you sent me afterwards (without CC to the list):
>>
>> | Plus there's still a bug in stram_free_block, let's see if you can spot it :-)
>>     
>
> Does not ring any bells ... I'll check my old mbox as soon as I have
> access again. I'll add a kernel parameter as well.
>   

See attached - hope the patch format is left intact by Thunderbird.

Tested on ARAnyM only so far ...

Cheers,

  Michael


[-- Attachment #2: 2.6.36-stram-pool.diff --]
[-- Type: text/x-patch, Size: 6807 bytes --]

 arch/m68k/atari/stram.c |  110 +++++++++++++++++++++++++++++++++++++++++++----
 1 files changed, 101 insertions(+), 9 deletions(-)

 Signed-off-by: Michael Schmitz <schmitz@debian.org>

--
diff --git a/arch/m68k/atari/stram.c b/arch/m68k/atari/stram.c
index 6ec3b7f..58891ab 100644
--- a/arch/m68k/atari/stram.c
+++ b/arch/m68k/atari/stram.c
@@ -30,7 +30,7 @@
 #include <asm/atari_stram.h>
 #include <asm/io.h>
 
-#undef DEBUG
+#define DEBUG
 
 #ifdef DEBUG
 #define	DPRINTK(fmt,args...) printk( fmt, ##args )
@@ -68,6 +68,23 @@
  * no provision now for freeing ST-Ram buffers. It seems that isn't
  * really needed.
  *
+ * MSch 22/10/10: Because mem_init is now called before device init, 
+ * devices that rely on ST-RAM may find all ST-RAM already allocated to 
+ * other users by the time device init happens. In particular, a large 
+ * initrd RAM disk may use up enough of ST-RAM to cause stram_alloc to
+ * resort to get_dma_pages allocation.
+ * In the current state of Atari memory management, all of RAM is marked 
+ * DMA capable, so get_dma_pages may well return RAM that is not in actual
+ * fact DMA capable. Using this for frame buffer or SCSI DMA buffer causes 
+ * subtle failure. 
+ *
+ * The ST-RAM allocator has been changed to allocate memory from a pool of 
+ * reserved ST-RAM of configurable size, set aside on ST-RAM init (i.e. 
+ * before mem_init). As long as this pool is not exhausted, allocation of
+ * real ST-RAM can be guaranteed. 
+ * Currently, pool ST-RAM freed is not returned to the pool free list so 
+ * it will be lost. Code to move such freed ST-RAM from alloc_list to 
+ * stram_free_list may be added if needed.
  */
 
 /* Start and end (virtual) of ST-RAM */
@@ -91,11 +108,15 @@ typedef struct stram_block {
 /* values for flags field */
 #define BLOCK_FREE	0x01	/* free structure in the BLOCKs pool */
 #define BLOCK_KMALLOCED	0x02	/* structure allocated by kmalloc() */
+#define BLOCK_POOL	0x04	/* block allocated from static pool */
 #define BLOCK_GFP	0x08	/* block allocated with __get_dma_pages() */
 
 /* list of allocated blocks */
 static BLOCK *alloc_list;
 
+static BLOCK *stram_free_list;
+static unsigned long stram_pool, stram_pool_start, stram_pool_end;
+
 /* We can't always use kmalloc() to allocate BLOCK structures, since
  * stram_alloc() can be called rather early. So we need some pool of
  * statically allocated structures. 20 of them is more than enough, so in most
@@ -116,6 +137,27 @@ static int remove_region( BLOCK *block );
 /*							   Public Interface								*/
 /* ------------------------------------------------------------------------ */
 
+static int pool_size = 1024*1024;
+
+static int __init atari_stram_setup(char *arg)
+{
+        int rc=0;
+
+        if (!MACH_IS_ATARI)
+                return 0;
+
+        if (!(rc = sscanf(arg, "%d", &pool_size))) {
+                DPRINTK("atari_stram: pool size parse error(%d)\n", rc);
+                return 0;
+        }
+
+        pool_size *= 1024;
+
+        return 0;
+}
+
+early_param("stram_pool", atari_stram_setup);
+
 /*
  * This init function is called very early by atari/config.c
  * It initializes some internal variables needed for stram_alloc()
@@ -156,6 +198,10 @@ void __init atari_stram_reserve_pages(void *start_mem)
 	if (!kernel_in_stram)
 		reserve_bootmem(0, PAGE_SIZE, BOOTMEM_DEFAULT);
 
+        stram_pool       = (unsigned long) alloc_bootmem_low(pool_size);
+        stram_pool_start = stram_pool;
+        stram_pool_end   = stram_pool + pool_size - 1;
+	DPRINTK("atari_stram pool: size=%d bytes, start=%08lx, end=%08lx\n", pool_size, stram_pool, stram_pool_end);
 }
 
 void atari_stram_mem_init_hook (void)
@@ -163,6 +209,38 @@ void atari_stram_mem_init_hook (void)
 	mem_init_done = 1;
 }
 
+/* find a region (by size) in the free list */
+static void *find_free_stram( long size )
+{
+	BLOCK *p,*q,*r;
+	unsigned long item;
+
+	q=NULL;
+	r=stram_free_list;
+	for( p = stram_free_list; p; p = p->next ) {
+		if (p->size >= size) {
+		        q=p;
+			break;
+                }
+                r=p;
+	}
+
+	/* remove from free list */
+        if (q) {
+          item = (unsigned long) q->start;
+          r->next = q->next;
+          return (void *) item;
+        }	
+	/* nothing found on free list? take from pool */
+	if ( (stram_pool_end - stram_pool) > size) {
+	  item = stram_pool;
+	  stram_pool += size;
+	  return (void *) item;
+	}
+
+	return( NULL );
+}
+
 
 /*
  * This is main public interface: somehow allocate a ST-RAM block
@@ -184,16 +262,25 @@ void *atari_stram_alloc(long size, const char *owner)
 	BLOCK *block;
 	int flags;
 
-	DPRINTK("atari_stram_alloc(size=%08lx,owner=%s)\n", size, owner);
+	DPRINTK("atari_stram_alloc(size=%08lx,owner=%s) ... ", size, owner);
 
 	if (!mem_init_done)
+	        /* this will trigger a section mismatch warning which is actually harmless: 
+	          once mem_init has run (before free_initdata), we will not call this code path anymore */ 
 		return alloc_bootmem_low(size);
 	else {
-		/* After mem_init(): can only resort to __get_dma_pages() */
-		addr = (void *)__get_dma_pages(GFP_KERNEL, get_order(size));
-		flags = BLOCK_GFP;
-		DPRINTK( "atari_stram_alloc: after mem_init, "
-				 "get_pages=%p\n", addr );
+		/* After mem_init(): can only resort to allocating from reserved pool ... */
+	        if ((addr = find_free_stram(size)) != NULL) {
+		  flags = BLOCK_POOL;
+		  DPRINTK( "after mem_init, allocating from pool, "
+                           "find_free_stram=%p\n", addr );
+	        } else {
+		/* or resort to __get_dma_pages() !! */
+		  addr = (void *)__get_dma_pages(GFP_KERNEL, get_order(size));
+		  flags = BLOCK_GFP;
+		  DPRINTK( "after mem_init, allocating dma pages, "
+                           "get_dma_pages=%p\n", addr );
+                }
 	}
 
 	if (addr) {
@@ -226,12 +313,15 @@ void atari_stram_free( void *addr )
 	DPRINTK( "atari_stram_free: found block (%p): size=%08lx, owner=%s, "
 			 "flags=%02x\n", block, block->size, block->owner, block->flags );
 
-	if (!(block->flags & BLOCK_GFP))
+	if (!(block->flags & BLOCK_GFP || block->flags & BLOCK_POOL))
 		goto fail;
 
 	DPRINTK("atari_stram_free: is kmalloced, order_size=%d\n",
 		get_order(block->size));
-	free_pages((unsigned long)addr, get_order(block->size));
+
+        /* pages allocated from stram pool cannot be freed - only pages allocated by get_free_pages can */
+	if ((block->flags & BLOCK_GFP))
+	  free_pages((unsigned long)addr, get_order(block->size));
 	remove_region( block );
 	return;
 
@@ -340,6 +430,8 @@ static int stram_proc_show(struct seq_file *m, void *v)
 			   p->owner);
 		if (p->flags & BLOCK_GFP)
 			PRINT_PROC( "page-alloced)\n" );
+		else if (p->flags & BLOCK_POOL)
+			PRINT_PROC( "pool-alloced)\n" );
 		else
 			PRINT_PROC( "??)\n" );
 	}

Re: [PATCH] m68k atari: reserve some ST-RAM early on for device buffer use (was: Re: Aranym, more than 244MB FastRAM, garbled display)

[Andreas Schwab]

Michael Schmitz <schmitzmic@googlemail.com> writes:

> +static int __init atari_stram_setup(char *arg)
> +{
> +        int rc=0;
> +
> +        if (!MACH_IS_ATARI)
> +                return 0;
> +
> +        if (!(rc = sscanf(arg, "%d", &pool_size))) {

           pool_size = memparse(arg, NULL);

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] m68k atari: reserve some ST-RAM early on for device buffer use (was: Re: Aranym, more than 244MB FastRAM, garbled display)

[Michael Schmitz]

On Fri, Oct 22, 2010 at 10:05 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Michael Schmitz <schmitzmic@googlemail.com> writes:
>
>> +static int __init atari_stram_setup(char *arg)
>> +{
>> +        int rc=0;
>> +
>> +        if (!MACH_IS_ATARI)
>> +                return 0;
>> +
>> +        if (!(rc = sscanf(arg, "%d", &pool_size))) {
>
>           pool_size = memparse(arg, NULL);

Thanks, that's a lot more elegant.

  Michael

Re: [PATCH] m68k atari: reserve some ST-RAM early on for device buffer use (was: Re: Aranym, more than 244MB FastRAM, garbled display)

[Geert Uytterhoeven]

On Sun, Oct 24, 2010 at 06:11, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> On Fri, Oct 22, 2010 at 10:05 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Michael Schmitz <schmitzmic@googlemail.com> writes:
>>
>>> +static int __init atari_stram_setup(char *arg)
>>> +{
>>> +        int rc=0;
>>> +
>>> +        if (!MACH_IS_ATARI)
>>> +                return 0;
>>> +
>>> +        if (!(rc = sscanf(arg, "%d", &pool_size))) {
>>
>>           pool_size = memparse(arg, NULL);
>
> Thanks, that's a lot more elegant.

Applied, but I'm wondering if there's no way to reuse an existing
allocator instead
of writing our own...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 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

Re: Aranym, more than 244MB FastRAM, garbled display

[Petr Stehlik]

Michael Schmitz píše v Thu 07. 10. 2010 v 09:47 +0200:
> >>> Args = root=/dev/hda1 console=tty debug=par video=atafb:vga2
> >
> >>The problem starts happening as soon as FastRAM >= 512.
> >
> > I suspect atafb:vga2 reduces the amount of memory needed enough
> > for it to work.
> 
> Certainly - 640x480@1bit isn't much. Even less than sthigh IIRC.

sthigh is 640x400@1bit, I believe, i.e. even less than vga2.

> I wonder why it does depend on FastRAM size, though. ST-RAM eaten up
> by page tables?

why anything is stored in ST-RAM? Besides there's 14 MB of ST-RAM on
ARAnyM, that should be plenty (compare with Falcon's 4 MB).

Petr

Re: Aranym, more than 244MB FastRAM, garbled display

[Michael Schmitz]

Hi Petr,

>> Certainly - 640x480@1bit isn't much. Even less than sthigh IIRC.
>
> sthigh is 640x400@1bit, I believe, i.e. even less than vga2.
>

I stand corrected.

>> I wonder why it does depend on FastRAM size, though. ST-RAM eaten up
>> by page tables?
>
> why anything is stored in ST-RAM? Besides there's 14 MB of ST-RAM on
> ARAnyM, that should be plenty (compare with Falcon's 4 MB).

Due to some problem with memory management, the kernel treats all RAM
as equal, and allocates from the bottom up apparently.

The frame buffer is initialized rather late in the kernel init
procedure, and both kernel, ramdisk image and ramdisk will go into
ST-RAM. Maybe it's due to fragmentation of memory more than actual
memory usage in the end.

Ideally you would want to have the kernel, ramdisk etc. in FastRAM.
This would require FastRAM to be placed as the first memory chunk in
the bootinfo struct (for reasons of memory management setup that I've
forgotten the details of - maybe it's time to revisit that ...).
Anything I tried to remedy that has just failed to boot, so we seem
stuck with kernel in ST-RAM.

Cheers,

  Michael

Re: Aranym, more than 244MB FastRAM, garbled display

[Geert Uytterhoeven]

On Fri, Oct 1, 2010 at 19:07, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Kolbjørn Barmen <linux-m68k@kolla.no> writes:
>
>> One thing I have noticed is that if I set FastRAM in aranym config to
>> something higher than 244 I get garbled display, kinda like frozen random
>> noise - the kernel does boot in the background though. I tried with
>> different kernels (only up to 2.6.34 though), and with different versions
>> of aranym, but it didn't make much difference.
>
> I have always been using FastRAM = 256 without problems.

Just checked, /me too!

I have `video=atafb:tthigh` but removing that doesn't change anything.
Ah yes, it emulates a Falcon, so the tthigh is bogus ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 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

Re: Aranym, more than 244MB FastRAM, garbled display

[Michael Schmitz]

Hi,

>>> One thing I have noticed is that if I set FastRAM in aranym config to
>>> something higher than 244 I get garbled display, kinda like frozen random
>>> noise - the kernel does boot in the background though. I tried with
>>> different kernels (only up to 2.6.34 though), and with different versions
>>> of aranym, but it didn't make much difference.
>>
>> I have always been using FastRAM = 256 without problems.
>
> Just checked, /me too!
>
> I have `video=atafb:tthigh` but removing that doesn't change anything.
> Ah yes, it emulates a Falcon, so the tthigh is bogus ;-)

I've always used sthigh myself (force of habit, my Falcon wasn't too
happy with faster pixel clocks). tthigh used to work (sort of) when
the driver was ported to 2.6, but that's a few years back.

If I recall this right, allocation of boot memory changed later in 2.6
and drivers initializing after boit memory had been freed could not be
guaranteed to receive enough low memory for things like DMA buffers or
screen buffers.

The kernel will reserve a chunk of ST-RAM early on during arch init,
and I may have set that chunk size too small for high resolution. If
the ST-RAM allocator cannot resort to the reserved chunk of low
memory, it will allocate high memory for you. VIDEL then masks off the
high byte of the framebuffer address, and the screen will show
whatever the kernel happens to write to the 24 bit alias of the frame
buffer address.

FastRAM should not be declared DMA-able so the allocator can properly
distinguish between the memory kinds. Doing this triggered some
problems in the memory management code that I could not disentangle,
hence the 'reserve some amount of boot memory' hack.

There might even be a kernel parameter like 'stram_reserve' to control
this behaviour, check the ST-RAM allocator code (my home PC is
unreachable, there's probably been a power outage again so I can't
check my git repo right now).

Cheers,

  Michael

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>