Re: [SPAM] Re: [PATCH] HACK: Atari ST-RAM allocator using fixed pool of bootmem

2008-07-04 Thread Michael Schmitz
Hi Geert, Anyway, the patch seems to be required for ramdisk use, so I better clean it up one way or the other. Geert - do we need to be able to free allocated ST-RAM? Otherwise, I'd just remove the dead freelist stuff and submit that. Sorry, I'm a bit lost. Which patch(es) do you mean? My p

Re: m68k developer meeting in Kiel

2008-07-04 Thread Christian T. Steigies
On Wed, Jul 02, 2008 at 11:12:20AM -0500, Stephen R Marenka wrote: > On Wed, Jul 02, 2008 at 04:57:06PM +0200, Christian T. Steigies wrote: > > Hi, > > right now five people have shown interest in the m68k developer meeting on > > Aug 29-31 in Kiel: > > I may be able to get travel reimbursement, i

Re: [SPAM] Re: [PATCH] HACK: Atari ST-RAM allocator using fixed pool of bootmem

2008-07-04 Thread Geert Uytterhoeven
On Fri, 4 Jul 2008, Michael Schmitz wrote: > > > Slightly less hackish implementation of that hack attached. This (on top > > > of my max_dma_address patch before) does solve the ramdisk related atafb > > > problems without resorting to artificial RAM limits. Stephen, please try > > > this patch. >

Re: diablos, diablos2, and diablos3 online

2008-07-04 Thread Stephen R Marenka
On Fri, Jul 04, 2008 at 07:27:55AM -0400, Michael Casadevall wrote: > I've got three aranym instances now functional on siren. Running distcc (I > find ccache slows things down more on m68k then speeds up, but YMMV), the > 4.3 compiler patch, and nfblock (running nice and stable once I killed > ude

Re: [PATCH] HACK: Atari ST-RAM allocator using fixed pool of bootmem

2008-07-04 Thread Stephen R Marenka
On Fri, Jul 04, 2008 at 11:29:28AM +0200, Michael Schmitz wrote: >> The latest d-i images seem to require aranym FastRAM to be 48M which >> invokes low memory mode. I'd rather not have to go there. :) > > Well, that kind of rules out installing on a TT ever again... We like to support *real* hard

diablos, diablos2, and diablos3 online

2008-07-04 Thread Michael Casadevall
I've got three aranym instances now functional on siren. Running distcc (I find ccache slows things down more on m68k then speeds up, but YMMV), the 4.3 compiler patch, and nfblock (running nice and stable once I killed udev). Aranym reports it as a 195Mhz 68040, and its seriously flying on how fas

Bug#489234: *sigh*

2008-07-04 Thread Michael Casadevall
X-Debbugs-CC: debian-68k@lists.debian.org I should not send patches when I'm half alseep. Here's one that's actually appliable ;-) --- gcc-4.3.1/gcc/config/m68k/linux-old.h2008-07-04 04:02:21.0 -0400 +++ gcc-4.3.1/gcc/config/m68k/linux.h2008-07-04 05:23:21.0 -0400 @@ -37,6

Re: [PATCH] HACK: Atari ST-RAM allocator using fixed pool of bootmem

2008-07-04 Thread Michael Schmitz
Hi, Slightly less hackish implementation of that hack attached. This (on top of my max_dma_address patch before) does solve the ramdisk related atafb problems without resorting to artificial RAM limits. Stephen, please try this patch. I finally tried this patch and it seems to work fine. I kno

patch to allow gnu99 mode on m68k

2008-07-04 Thread Michael Casadevall
Package: gcc-4.3 Version: 4.3.1-2 Severity: important Tags: patch On m68k, gnu99 mode doesn't work correctly out of the box due to our woefully outdated glibc (we're currently stuck at 2.5-1). This is because the inline schematics changed between glibc 2.5 and 2.7, and gcc 4.2 to 4.3. This patch