OS/2, eCS & ArcaOS - Technical > Setup & Installation
Troubleshooting process trap/dump...how?
Dariusz Piatkowski:
So I've got a weird problem that just seemingly has shown up about a couple of weeks ago: I've seen three separate RSYNC jobs die part-way through a LOCAL backup, and as best as I can tell my OS/2 box reboots at the same time.
Now the strange part is that I can't find anything listed in places like POPUPLOG.OS2 or as TRP files...so it's rather tough to figure out whether this is a hardware or a software issue. At the moment I am leaning towards this being a hardware thing.
Having said that, I know that this is not a CPU cooling problem as I am running a pretty capable setup here and that's something I've been through multiple times so I know there is spare room there...but it could be something else, such as memory, or even CPU/core problems.
Sooo...I went back to my CONFIG.SYS and re-enabled the system LOG stuff I had previously enabled:
--- Code: ---...
DEVICE=G:\OS2\LOG.SYS /OFF
RUN=G:\OS2\SYSTEM\LOGDAEM.EXE /E:g:\tmp\trp
DUMPPROCESS=G:\tmp\trp /F=10240
RUN=G:\OS2\EPWDDR3.EXE
DEVICE=G:\OS2\EPWDD.SYS
...
--- End code ---
Not sure though if there is anything else I should be looking at to try to maximize the data capture should RSYNC cause either that hardware or perhaps software fault again.
What have you used in your previous attempts to narrow this kind of a problem down?
Thanks!
Dave Yeo:
Sometimes reseating the ram and any other cards fixes these types of issues as wears off any oxidation.
Pete:
Hi Dariusz
Try reseating ram and any cards, disconnect and reconnect drive and power cables .
If that does not help: How old is PSU and when did you last open it and give it a clean?
Had a problem a few years ago where lengthy disk access caused system hangs. Took a few hours but traced that to a dying PSU - dust buildup had caused overheating. Replaced PSU and all worked fine.
Regards
Pete
Lars:
Hi Dariusz,
you are not alone with the "my system suddenly reboots without any trace" problem. I have experienced the same more than once.
1) you are using a very outdated version of FFST (RUN=G:\OS2\EPWDDR3.EXE, DEVICE=G:\OS2\EPWDD.SYS) that predates the stuff that came with Warp 4 (and after, of course). Do not do that. I suggest to deinstall it. >= Warp 4 comes with everything you need.
2) Lower your VIRTUALADDRESSLIMIT value. I suggest to start with 512 (which is the lowest value and equivalent to having no high memory at all) and then, raise up to a value that is still lower than your current value. If 512 is too low, you will need to start with a value that works for your system. VIRTUALADDRESSLIMIT can only be raised in chunks of 512 MB (0x20000000). XWorkplace kernel object will only select values that are possible. The default value for VIRTUALADDRESSLIMIT is 1024 (MB).
My suspicion is that 2) is the most likely culprit. The problem with a too high value is that OS/2 seemingly can run into problems on memory allocation (be it the system arena located above the VIRTUALADDRESSLIMIT value, or the user area below this value). And OS/2 does a very bad job of detecting this problem with the result that it does not even stop with a critical error message and a system trap dump. Obviously, the failure to allocate memory in the system arena is a fatal problem that renders the system completely unusable.
An alternative behaviour to these sudden reboots seems to be a complete system freeze (with the same effect as if all HW interrupts are being disabled).
Lowering this value has still not completely eliminated the problem for me but it has lowered the frequency with which these sudden reboots occur.
Neil Waldhauer:
Rsync would crash here, too. I was doing a pretty large network rsync, but reliability improved greatly when I removed a lot of EA from my files. I used eaclean to remove the unnecessary UID, GID, MODE, INO, RDEV, GEN, FLAGS EAs. A side benefit was that my rsync ran several times quicker.
Navigation
[0] Message Index
[#] Next page
Go to full version