Thanks for the reply. The only one from an obviously popular and busy
list.
I guessed this might be the case when it allowed me to allocate one huge
block of 24Meg, hence I tried mallocing small blocks and also using
calloc to see what would happen. That's when I crashed the machine.
This does not happen when the machine is running from a hard disk or
entirely from an NFS server (including root) I am sure this is a RAMDISK
related bug.
Do you know anything about the RAMDISK internals ?
Bill Melotti
Cognito Ltd UK
On Tue, 26 Jan 1999, John Alvord wrote:
> One aspect is that malloc() allocated storage does not consume (much) RAM
> until the program actually uses it. john alvord
>
>
> Music, Management, Poetry and more...
> http://www.candlelist.org/kuilema
>
> Cheap CDs @ http://www.cruzio.com/~billpeet/MusicByCandlelight
>
>
> On Tue, 26 Jan 1999, Bill Melotti wrote:
>
> >
> >
> > Hi
> >
> > Can anyone offer any suggestions on a possible RAMDISK bug I have seen.
> >
> > I wish to boot a system from a flash IDE drive into a 16Meg RAMDISK on a
> > system with 32 Meg installed. I have modified drivers/block/rd.c and
> > commented out the line that checks for a floppy as the root dev, this
> > allows me to at least load a compressed filesystem image from an HD into
> > RAMDISK.
> >
> > The system I have uses about 11 meg of the 16. You would imagine I have a
> > little less than 16Meg available for application use. Actually I have
> > a few processes running from boot and free reports only about 6Meg
> > left.
> >
> > I tried running some programs that would allocate memory until failure to
> > confirm what was really available (because I though 6 was a little low)
> >
> > I wrote a program that would malloc single large blocks. With this I can
> > malloc 23 Meg before failure. (malloc returns NULL)
> >
> > Thinking there was a problem, I changed this to use calloc instead. If I
> > tried to calloc more than 10 Meg, the machine locked up. Between 6 and 10 it
> > would usually keep going for a while, but lock up later. I tried running
> > these programs as nobody rather than root. Same result. If I were running any
> > other programs (eg 'top') in another session, this would usually bomb with a
> > bus error at the same time. The callocing app might also bomb with a bus
> > error before the machine locked. I am doing this stuff over a telnet session,
> > I haven't tried it on a console.
> >
> > It is as if the RAMDISK code as not marked the buffers it uses as
> > unavailable for app code. I looked through the code and see it sets the
> > BH_Protected flag in the file buffer structs. However I also see that
> > there are 2 or 3 places (fs/buffers.c and somewhere in ext2 hierarchy)
> > where these can be cleared.
> >
> >
> > Can anyone offer any help/comments/suggestions ?
> >
> > Many thanks
> >
> >
> > Bill Melotti
> > Cognito Ltd UK
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/