The RAD (And logging serial output techniques)

RAD is meant to surive warm restarts.

If your RAD: is not in devs:dosdrivers



CNTRL-ALT-ALT



I would have expected to see "theFile" in the listing after the CNTRL-ALT-ALT?

If it worked on a classic machine and not the AmigaOne, then the AmigaOne CNTRL-ALT-ALT is a cold reboot versus a classic amiga warm reboot?

I get the same issue if instead of CNTRL-ALT-ALT I use Workbench>Shutdown>Restart Computer.

I also get the same issue if I copy the RAD: to devs:dosdrivers which saves me the manual mounting.

If the only "warm" reboot is by Workbench>Shutdown>Restart Amiga OS, then AmigaOne users using Polaris cannot use RAD: effectively.

@rjd324

CTRL+ALT+ALT is a cold boot
(reloads kirckstart, and reinitializes all memory.).

you need to do a warm reboot for this to work

CTRL+WIN+WIN is a warm boot
(restarts kickstarts)

(Windows key is the Amiga key)

If you have a RX card your out of luck, as it does not support warm reboots, you need a HD card and 3.x driver for it to work.

But how about putting this in your user-startup

Assign RAD: IDF4: DEFER

and use diskimage to host your files.
and move rad into storage.

The RAD is so cool man.

I can see what the issue is. The Ctrl-Alt-Alt is doing a hard reset and the RAD disk won't survive. I suppose they could have programmed it to scan memory if possible but they didn't.

It's supported only in soft reset. So you need the Ctrl-Amiga-Amiga combo or depending on keyboard Ctrl-Logo-Logo. And in the menu you found.

It's a recent problem that the Radeon driver and especially V5 cannot support soft reboot because the cards don't like it. Some cards do support it, like my R7 250, but it only works in V1-V3 driver. Soft reboot doesn't work when using the V5 driver. Which Polaris card do you have?

I don't know why but the driver resets the card when Amiga OS reboots. I think at this point they will need to stop this process. The screen needs blanking so I wonder if it can be simply blanked out and kept active while it reboots.

@rjd324

If you are trying to debug something, you should consider using RS232 port.

Echo something > AUX:

If something is crashing, it can corrupt the memory, and stop device IO or GUI from working, RAD: device can be unreliable

I am using an X5000 with RadeonHD 3.7, and for me the RAD never survived a (warm) reboot.

And yes, with warm reboot I mean CRTL+WIN+WIN, or the "reboot fast" cli command, or using "Restart AmigaOS" of the Shutdown option in the menu.

Okay, thanks for the information. So, when we say "cold" in this context we mean the fact that the OS is flushed out - not that there is no longer power being supplied to components.

The reason I wanted this was to have a background Sashimi process logging all debugging to a file. I felt like having a RAD: would be appropriate in the case of a freeze since there would be no overhead with writing to a disk.

I guess I will have to just log the output of Sashimi to a disk.

The reason I want to use Sashimi is because I want to be able to capture the serial output in the case of any freezes. This is not happening often, but I just want to be able to see what happened.

Is there a better way to capture the output of the serial in the case of a freeze?

The best way is to use a second PC/laptop.

But I understand that most people do not have additional hardware or space for that.

When I am thinking about it, you could use ssh2-handler or SMBFS to store your logs on a different PC or NAS. That will prevent corrupting your local filesystems if the system freezes.

@rjd324

You most defeat need a PC or raspberry PI, to capture the RS232 output.

I understand that, but what I do not want to have is a computer (even a RP) running at all times to capture the output.

I have have my X5000 connected to my A600 via Serial and I use the TERM program on the A600.

To me it just seems more preferable and convenient to capture the serial to a file without the need to have another machine turned on, although, I seem to be in a minority so there must be something I do not understand.

@rjd324

You can use C:DumpDebugBuffer for that. It survives a soft reboot. Or it should as it did on the XE but on some kernels like X1000 they messed it up and broke it.

For redirecting to serial you can use KDebug as so:


By default it should be set to memory. In case of hard crash you will need serial debug. There should be no need for tools Sashimi as the functionality is built in.

Right, but there is no such thing as a "soft" reboot for AmigaOne using Polaris, right?

I guess my question can be put like this:

In the event that my system freezes: whether this is a full lockup with the OS locked up or whether it is just a GFX freeze where the OS is still running in the background... whatever - just a freeze. How can I get the generated serial debugging information in such a way that it does not require an external computer?

@rjd324

You can't. Any sort of freeze is going to make it impossible to save (and close) an output file on the same machine. You can sometimes save a file after a crash if you are lucky, but a lot of stuff has to still be running, and usually Workbench is hung up and crashed because it was Workbench that ran the program in the first place.

In the case where you ran the crashed program from a Shell, I have sometimes had a second Shell already open when the first Shell crashed, and then I can leave the first program crashed (don't touch the Reaper window) and click in the second shell to save the debug file; but just clicking in another Shell can lock the machine totally if it's a bad crash.

Your only reliable method is to use a second machine to receive and save the debug output.

On second thoughts, if you had a very, very, very long cable, you could reboot the machine after the crash and be ready to capture and save the crash log when it finally finished the round trip...

@rjd324

Speaking of serial debugging, there is another small trick to do to catch a crashlog even if intuition and workbench have died and you can't type anything while the kernel and network stack are still alive by luck:

On OS4, you run:



that will run a console on your_ip:1024 to which you can connect from another machine of any kind. But if it's PC, then via Putty, with only the difference that you need to set "sessions/protocol" to "raw" and "terminal/implicit" to "CR in every LR: on."

But, once again, if the memory of the kernel or the network stack was corrupted, you out of luck.

Finally, as everyone says, another terminal for pure serial debugging is required anyway, and nothing can be done about it. Because some crashes are less severe, and you even have GUI-based GR popups, but many times you will have just a total freeze or a very hard-core bug, so GUI-based GR has no time or ability to show up itself, but, at the same time, the kernel's "reaper" still throws some information to serial.

There are times when there are so many bugs that even the kernel's reapers don't have time to throw anything on serial, so you have to experiment with debug levels and other things even then. But at this time machine of course is "die" state with all those "dumpdebugbuffers" or this GUI GR.

I just quoted what I wrote in "advanced_serial_debugging_guide" on wiki:

Quote:

So, as you can see, serial debugging is the only way. All of those "kdebug" and "dumpdebugbuffer" methods are for very simple bugs that do not destroy the entire system. Instead, always connecting a serial cable to a terminal that is always working (like a PC notebook with a USB2Serial cable) is the really good stuff. Even taking a slightly larger seat at the table will be worthwhile in the end.

But if you really don't want to use serial debugging but just want to collect the tricks you can do to at least try to save something without serial, then this "tcp" trick may be useful.

@rjd324

Ahhh RAD:

I remember Xmas 2004, got my µA1 and AmigaOS 4.0 developer pre-release.
I used RAD: to write the Tv-Paint .adf disks to and install the app.

18 years ago! :)

@tonyw

Quote:Now there's an interesting idea.

Perhaps we could combine it with this: https://en.wikipedia.org/wiki/Slow_light - or maybe send the data over a network which includes this: https://www.ietf.org/rfc/rfc1149.txt

Best regards,

Niels

@rjd324

Quote:
You could always get a Sentinel X-Logger!