OS/2, eCS & ArcaOS - Technical > Setup & Installation

Troubleshooting process trap/dump...how?

<< < (2/3) > >>

Dariusz Piatkowski:
Dave and Pete,

Gents, I'm thinking what you pointed out should not be the root cause simply due to the fact that I have about 3 monts on this box since my most recent CPU change, and even less so given the tuning I executed thereafter (memory, etc.). So I would say that the "dust has barely settled", but...point noted, I regularly (every three months or so) clean the various air filters on the case, so I will certainly review all of the above!

Neil,
Understand what you are saying, but what's weird is that I've been using RSYNC for a few years now to routinely do this nightly backup. Sure, RSYNC has had other issues (some of what you pointed to), but never this kind of a re-boot. I suspect RSYNC however is putting on some stress on a part of the system (could be hardware, could be software) that's most likely failing.

Both of the above suggestions have sent me on a bit of a manual maintenance run: CHKDSK all my drives (JFS), etc...about to start all of that actually!

Dariusz Piatkowski:
Hi Lars,


--- Quote from: Lars on May 05, 2025, 08:06:04 am ---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.

--- End quote ---

OK, so I need a little help here. The OS/2 Toolkit doc "Problem Determination Programmer's Guide" has a decent amount of details on how to USE the SYSTEM and PROCESS dumps, logs, etc...but nowhere does it actually spell out the required pieces that are needed to set this up.

In fact, the complete "PROC DUMP" section of my CONFIG.SYS is as follows:


--- Code: ---REM ******************************************
REM ***       OS/2 DUMP/TRACE - START      ***
REM ******************************************
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

REM RUN=G:\OS2\EPWROUT.EXE 1
REM RUN=G:\OS2\EPW.EXE

REM *** USB LARS DEBUG => 2 TRACEBUF lines below
REM TRACEBUF=128 /M=WRAP,QUEUED,NODTI /D=ALL
REM TRACE=ON 225,226
REM ******************************************
REM ***       OS/2 DUMP/TRACE - END        ***
REM ******************************************

--- End code ---

...where I actually have all of the above REM'ed out normally and unless I hit an issue I want to track I never have this turned on.

The only mention of FFST I have is in the Toolkit doc, stating the following:


--- Quote ---...The OS/2 Logging Facility device driver LOG$ is not loaded.  To activate logging enter DEVICE=\OS2\LOG.SYS and RUN=\OS2\SYSTEM\LOGDAEM.EXE in config.sys and reboot...

--- End quote ---

But at least that would imply having those two alone in CONFIG.SYS should be sufficient. I did go back to re-reading the notes and will remove the '/OFF' parameter of the LOG.SYS driver.

Strangely enough I have found no place on my machine where any FFST install/uninstal options exist. The standard 'Selective Uninstall' shows nothing there other than standard Warp4 stuff.


--- Quote from: Lars on May 05, 2025, 08:06:04 am ---...
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)...
--- End quote ---

I will go to this option as the last resort simply due to the fact that my RSYNC jobs have been executing on nightly basis for several years now, no misses.

Dave Yeo:
Hi Dariusz,
Check out http://www.warpcave.com/os2diags/index.html

Lars:
1) you will need LOGDAEMON.EXE so that (Ring 3) applications can use the "LogAddEntries" API to write to the System Log. Not many apps need it but it does not hurt to have it running. "LogAddEntries" API is only documented in the Debugging Handbook.

2) you will need LOG.SYS so that Ring 0 device drivers/IFS etc. can use the DevHlp_LogEntry device helper to write to the System Log. It is also required by LOGDAEMON.EXE to operate. Not many device drivers use it (if any) but it does not hurt to have it running

3) You can safely remove all that EP... stuff as it is the outdated FFST stuff which has been superseded long ago, see here:
https://www.edm2.com/index.php/First_Failure_Support_Technology/2
From the list, only keep the following as actually, that is the new FFST stuff (I will need to recheck just to be sure):
FFST.EXE
FFSTCONF.EXE
FFSTPCT.EXE
ERRLOG.DLL
FFCONFIG.DLL
FFDUMP.DLL
FFGUI.DLL
FFIPC.DLL
FFPCT.DLL
FFPROBE.DLL
FFST.DLL
FFST.HLP

4) FFST.EXE is the system log daemon, it is started by SMSTART.EXE (see what THESEUS.EXE reports). It seemingly replaces EPWDDE3.EXE, EPWROUT.EXE, EPW.EXE.

5) Finally, FFST.DLL contains routine "FFSTProbe" which effectively supersedes "LogAddEntries" (see above) to write to the System Log but both still coexist where "LogAddEntries" is easier to use but requires a handwritten DLL to format the logged data where "FFSTProbe" uses a text template formatting approach that however is overly complicated.


Dariusz Piatkowski:
OK, so a bit of an update, and this may ultimately be a RSYNC issue, or perhaps a samba client problem...?

Last night the machine died...TWICE...lol, within 10 mins of each reboot. As it happened my cron schedule has multiple RSYNC jobs scheduled (they do NOT run in parallel though) and the 1st reboot happened in the middle of the 1st RSYNC, and the 2nd during the next scheduled run (different SOURCE & TARGET locations though, but both copying from a LOCAL directory to the NAS box - which is accessed through a NetDrive samba share).

So seeing as I had just about touched on all the other things I could possibly think of, I decided to run the same RSYNC job manually (as in not scheduled).

The RSYNC CLI is this:

RSYNC --archive --delete --progress --stats --whole-file --no-xattrs --human-readable --quiet  --exclude-from=G:\mptn\etc\rsync_exclude --log-file=G:\tmp\log\rsync_REMOTE_backup.log G:/DESKTOP/Automotive V:/public/documents

...but having kicked off this very run manually after much much longer than it normally runs I eventually killed it with CTRL-C in the CLI window, which produced the following error message:


--- Code: ---...
2025/05/06 13:57:20 [126] rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
2025/05/06 13:57:20 [126] rsync: connection unexpectedly closed (78453 bytes received so far) [sender]
2025/05/06 13:57:20 [126] rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9.1]
...

--- End code ---

Soooo...I'm going to retry this again, but quite honestly I'm at a complete loss as to what's going on here.

This example here normally runs for all of two minutes...yup, that's all. Meanwhile today's run was 4 hrs. long and I suspect there was some kind of networking hangup that was encountered given that last error message.

This CTRL-C kill did not generate a process dump, which I think is the correct outcome.

EDIT #1
======
One more thing: take a look at the attached Theseus screenshot...RSYNC actually seems to create THREE processes, of which two have 2 threads, and the last one has a single thread...is that normal???


EDIT #2
======
...and yet the very next run of RSYNC, albeit with a different SOURCE & TARGET combo, completes just fine!!!

WHAT DA????

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version