Automatic Restart Applied to device drivers as an option

[Belxjander]

I have a sam440flex and suffer the random crashes of input.device
As I lack a PS/2 keyboard/mouse option...

I have given this some thought,

Would it be possible to have a means to suspend the crashed device task, launch a new instance and optionally use an Env:.setting to save crashreports without user interaction?

Hopefully such a facility would aid in debugging any device level processes. or tasks without being a problem?

[ssolie]

Crashes are always output to the default serial port via the "Reaper" which is built into the kernel. For help on hooking up the serial port, etc. see the Advanced Serial Debugging Guide.

The "Grim Reaper" is a GUI application which is launched by the "Reaper" and is 100% optional.

There have also been some major improvements to the Reaper which have not yet made their way to the public. I was hoping to have these improvements released before AmiWest 2013 since debugging is a major focus of the seminars.

[Belxjander]

@S.Solie: My main concern with automation which I forgot to enter in my original post was the dead requester when input.device has crashed.

It is those times when things like requesters are a problem and alternate automation of the setting may be in order...


No Env var = requester
Empty Env var = no request/ no crashlog
Env var is path = crashlog only, no gui

[ssolie]

I still don't see a need to complicate things with GUI's when you have a perfectly useable way of the getting the crash logs via serial right now without waiting for anything.

[Belxjander]

Sorry for being completely unclear...

the *existing* GUI is something I want to switch off for getting a crashlog on disk and input.device restarted when it crashes and makes the keyboard, mice and other input non-responsive

[kas1e]

Writing anything on disk after crash mean the same complicated of things, because when you crash whatever know what else may happens and how junky your output file on disk will be (if it will works at all, as crash can kill and input.device, and dos itself, and anything else).

For that purposes there is serial debugging: you don't have any gui, you don't have any "write to anything", you don't have any OS kind operations, or calling of functions, just the kernel simple as it can throw information on serial involving as less as possible moves. The more you will add on top of it, the worse your chances to catch a roots of crash.

So, just build serial cable, hook it up to some windows machines, run putty over it , and all the info will be right in your putty window if you setup everything correctly. Exactly for that purposes "input crashes mouse/keyboard not works" you need serial cable. You will not need to operate with os, you just will have all the output on serial, without any other needs. Just read whole article on which Steven point out, there is everything as much as possible described.

[xenic]

I still don't see a need to complicate things with GUI's when you have a perfectly useable way of the getting the crash logs via serial right now without waiting for anything.

Really? In order to run our OS4 Amiga's you expect us to keep 2 computers running all the time; one to use and another to monitor the serial port from the Amiga? There must be a better way.

[xenic]

I have a sam440flex and suffer the random crashes of input.device
As I lack a PS/2 keyboard/mouse option...

Would it be possible to have a means to suspend the crashed device task, launch a new instance and optionally use an Env:.setting to save crashreports without user interaction?

I have similar problems with my SAM Flex and until I switched to an X1000 I had several workarounds:
1. I ran my SAM Flex at a lower speed with the HyperClock utility. It reduced the frequency of input crashes/freezes.
2. I set up an icon on AmiDock that calls a script to execute an "USBCtrl restart" command. That only helps in cases where either the keyboard or mouse input is lost but not both.

I also came up with a crazy method of soft rebooting AmigaDOS by sending a message to my Amiga through the network since the TCP/IP stack didn't crash when the input froze. I'd like to see someone come up with a cheap device to hook to the serial port which will send a message to a background program that will soft reboot the computer. When you push a button on the device it would send the message causing a soft reboot and then the debug output can be obtained from the debug buffer.

I have to agree with others that writing to disk after a freeze or crash could have bad consequences. I doubt if your suggestion would be implemented because of the risk of trashing a hard disk.

[nbache]

Really? In order to run our OS4 Amiga's you expect us to keep 2 computers running all the time; one to use and another to monitor the serial port from the Amiga?

Only if and when you need the debug output/crash log. Most end users won't need that ever, or very rarely. A beta tester or a developer will need it often. I have 5 NG machines (and one classic A1200/060) connected in pairs by serial cables, so I can turn the other one of a pair on and run Term whenever I need to save a serial output.

There must be a better way.

It's the best of all ways I can think of, since it is the way which gives you a capture of the sick and potentially crashing system safely captured on a stable and running system, so you can save it and study it after the crash.

Best regards,

Niels

[Belxjander]

To clarify my original request...

1: optional bypass of the *existing* GUI (I refer to the crash requester *BEFORE* GrimReaper launch...)

2: restart or reset of input.device on crash termination

Can input.device trigger a presetup recovery task to handle internal state crashes? Or have an exec private option to manage crash recovery given a device hook routine to clean and reset state?

3: possibly saving a crashlog (yes this is risky and least implimentable)

As for the "suggestions" about a second machine...
I'll revisit the idea when I have a second machine
Assumption of a second or other machine is something to query first I believe

How about a debug Dongle instead?

Easier for a custom Arduino to capture debugging.

It makes more sense to me then I can query it post reset