Ramdisk failing on X5000

Hey guys,

I have huge problems with my drives at the moment. At first I thought it must be because of a blow on the machine about 1/2 year ago.

BUT now the ramdisk is starting to fail. I cannot read simple executables from it.

SO I remembered, that I updgraded dos.library and ramlib.kmod some weeks ago.

Does anyone of the betatesters know, if there are issues with versions of those two entities?

I think it is a better bet than both my usb stick and harddrive going bust at the same time. The machine boots fine 19 out of 20 times, and the last time I assume it is an issue with my beta elf.library.

@elfpipe
ramlib.kmod has nothing to do with the ram disk, that's for loading disk
based libraries and devices for Exec.

ram-handler.kmod is the filesystem that handles the RAM: volume.

dos.library handles calls to all filesystems and handlers for application requests,
if there was anything wrong with it, you'd soon be in deep trouble everywhere,
it would be quite obvious, you probably wouldn't even be able to boot up.

elf.library is responsible for loading PPC elf format file (executables) into
memory and that is likely an issue if you are using beta releases,
it could be executable specific if one was put together differently.

Revert to the last "official" elf library and other components and do a cold boot
to see if your issues fo away.

If you provide version numbers, we may be able to help you further,
but I would most strongly suggest you don't play mix-n-match with early
releases of kickstart components, as they may be release dependant on
each other and some may not work at all.

@colinw

Hi Colin, thanks for the assistence!

I am trying to upgrade ram-handler.kmod to version 54.26 (latest).

This one pops up requesters at boot. First 'Unknown volume RAM:', and then when pressing 'Mount', it says 'Failed to load DEVS:mountlist'.

I can see, that there is indeed no file called DEVS:mountlist.

Also, I can see in DEVS:DOSDrivers/, that there is no entry for RAM.

Is this a manual assignment now? I am not sure how to correctly create the entry for RAM.

Also I am curious : What is the ramdrive.device.kmod for ?

EDIT : I can boot from installation CD, and then the ramdisk seems to be fine.

@elfpipe
RAM: is mounted by dos.library, a mountlist or DOSDriver isn't required for it.

DEVS:Mountlist was the old way to mount other dos devices, a single file with all dos device entries. It was replaced (but is still supported) in AmigaOS version 2.1 by using separate files in DEVS:DOSDrivers for each dos device instead.

ramdrive.device is a floppy/HD like RAM based device, usual DOSDriver name RAD: or RAD0:, unlike ramhandler/RAM: it has a fixed size.
Additionally the contents survived a fast reboot (CTRL-Amiga-Amiga), but at least with current Radeon gfx drivers that doesn't work any more because you always have to do a cold reboot (CTRL-Alt-Alt) instead.

@elfpipe
ram-handler.kmod 54.26 requires a reasonably recent V54 dos.library for
the best results, it also requires V54.1+ of Exec if you want to have access
to the ExtMem features.

As Joerg indicated, the dos.library mounts all the RTF_AFTERDOS modules,
so if RAM: is not mounting, it can only be that the module is not being loaded
from the kickstart directory (check your kicklayout), or, there is something
failing during initialisation of the ram-handler itself.

Luckily, all failure points in ram-handler will print a message to the serial port using
IExec->DebugPrintF() in the form of like; "[RAM] Cannot allocate blabla...."
that sort of format, so check your serial debug by typing "dumpdebugbuffer"
in a shell.

Also, if you set the exec debuglevel to 5 (or higher), you will always get a
message in the serial debug; "[RAM] Handler has started successfully....".

@elfpipe

Don't know if this may make any difference but maybe your Kickstart/ram-handler.kmod may not have the 'read' attributes set?
Another idea: may it be possible that you have several kickstart and you somehow messed up with them? Ending up with mixing incompatible versions? On this last one please add asked by Colin provide version numbers of the listed kmod.

@abalaban @colinw

Versions :

- dos.library.kmod.debug 54.121
- kernel.debug 54.56
- ram-handler.kmod 54.26

I don't have a serial hook up, so I can't see serial output during boot.

try to update to the very latest. i also had a problem with elf.library. that was gone before i could check and write a bugreport with the latest updates.

we're not discussing beta software here now? are we?

regards...
michael

@elfpipe

Those are the latest beta release versions, they work here fine.
Also, you didn't mention the elf.library version.
And, you don't need a serial hookup, just type "dumpdebugbuffer" in a shell.
You can also flush the debug buffer with the "Clear" argument.

@MichaelMerkel

Actually this discussion should be on the hyperion beta list.
What it's doing here, I have no idea.

@colinw

Sorry, my bad. I don't have access to it. Let's just end the discussion here.

@elfpipe
The developer list will do, i've seen emails from you there recently.
Ask the list maintainer for beta list access.