Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Fixpak file mapping - how to get a good DEBUG/TRACE/DUMP ?
Skip to first unread message
Dariusz Piatkowski
Nov 24, 2011, 9:59:36 AM11/24/11
to
Hi Folks!
Ever since my upgrade to the '21st century computing' (lol - a move from an AMD
Barton to Phenom X4 setup) I have been experiencing an odd freeze here and
there. These are not hard locks, rather the WPS stops responding, mouse cursor
is still OK, CPU monitor (v 1.17) chugs along, but the WPS interface seems to
stop working. This is always brought on by something a given application has
attempted to do, once such app is AVXCAT, which I would love to use. The 2nd on
is the latest PMView install program (WPI based). Both will soft-lock the WPS,
only CAD helps.
One thing I have been able to narrow this down to is the utilization of the 4
cores...if I shut-off the 3 remaining cores (using setproc utility) I am able to
breeze through these processes.
So...what's the config I'm using? Warp4.52, CP2 with FP6 applied, using the SMP
doscall, os2krnl, etc, PSD=OS2APIC.PSD /P=4 /APIC, although I have tried a bunch
of different /PIC and /PREC options, none of which had made a difference.
What to do next? Well, using a nifty fixpak decode utility I decided to go
through FP6 again and make sure that the correct SMP specific code was deployed
on my machine. I am making the assumption that the "5639A5550 - CP2 for Warp
Server for e-business (SMP)" is the final setup I want to duplicate to support
my SMP switch. Since I do not have the correct SYSLEVEL file for that OS/2
revision and therefore can not simply re-apply FP6 against that SYSLEVEL I'm
taking a somewhat of a longer path here.
I had previously applied FP6 when still using the Barton cpu, which was a
non-SMP system. Specifically, I find that the FP6 OS2.2 subdirectory in the FIX
directory tree decodes to the following deployments (just a sample record):
KRNLRDEV.TDF @SMPDIR KRNLRDEV.SD_ 13 10/17/06 08:42 4307 8598E6BB
Packed, Add \OS2\INSTALL\SMP
KRNLRDEV.TDF @UNIDIR KRNLRDEV.UD_ 13 10/17/06 08:31 4232 819A1896
Packed, Add \OS2\INSTALL\UNI
KRNLRFS.TDF @SMPDIR KRNLRFS.SD_ 13 10/17/06 08:42 4927 1B715B3D
Packed, Add \OS2\INSTALL\SMP
KRNLRFS.TDF @UNIDIR KRNLRFS.UD_ 13 10/17/06 08:31 4874 A40C5818
Packed, Add \OS2\INSTALL\UNI
...so the TDF files are being tossed into the SMP or UNI subdirectories of the
\os2\install path, and thus my question, is this the FINAL resting place for
these? Previously, I had the UNI processor stuff going to G:\os2\system\TRACE,
but is the SMP configuration different?
I ask because as I'm attempting to debug the hanging applications I'm trying to
get a good working DUMP/DEBUG/TRACE environment...
Thanks!
-Dariusz
Ever since my upgrade to the '21st century computing' (lol - a move from an AMD
Barton to Phenom X4 setup) I have been experiencing an odd freeze here and
there. These are not hard locks, rather the WPS stops responding, mouse cursor
is still OK, CPU monitor (v 1.17) chugs along, but the WPS interface seems to
stop working. This is always brought on by something a given application has
attempted to do, once such app is AVXCAT, which I would love to use. The 2nd on
is the latest PMView install program (WPI based). Both will soft-lock the WPS,
only CAD helps.
One thing I have been able to narrow this down to is the utilization of the 4
cores...if I shut-off the 3 remaining cores (using setproc utility) I am able to
breeze through these processes.
So...what's the config I'm using? Warp4.52, CP2 with FP6 applied, using the SMP
doscall, os2krnl, etc, PSD=OS2APIC.PSD /P=4 /APIC, although I have tried a bunch
of different /PIC and /PREC options, none of which had made a difference.
What to do next? Well, using a nifty fixpak decode utility I decided to go
through FP6 again and make sure that the correct SMP specific code was deployed
on my machine. I am making the assumption that the "5639A5550 - CP2 for Warp
Server for e-business (SMP)" is the final setup I want to duplicate to support
my SMP switch. Since I do not have the correct SYSLEVEL file for that OS/2
revision and therefore can not simply re-apply FP6 against that SYSLEVEL I'm
taking a somewhat of a longer path here.
I had previously applied FP6 when still using the Barton cpu, which was a
non-SMP system. Specifically, I find that the FP6 OS2.2 subdirectory in the FIX
directory tree decodes to the following deployments (just a sample record):
KRNLRDEV.TDF @SMPDIR KRNLRDEV.SD_ 13 10/17/06 08:42 4307 8598E6BB
Packed, Add \OS2\INSTALL\SMP
KRNLRDEV.TDF @UNIDIR KRNLRDEV.UD_ 13 10/17/06 08:31 4232 819A1896
Packed, Add \OS2\INSTALL\UNI
KRNLRFS.TDF @SMPDIR KRNLRFS.SD_ 13 10/17/06 08:42 4927 1B715B3D
Packed, Add \OS2\INSTALL\SMP
KRNLRFS.TDF @UNIDIR KRNLRFS.UD_ 13 10/17/06 08:31 4874 A40C5818
Packed, Add \OS2\INSTALL\UNI
...so the TDF files are being tossed into the SMP or UNI subdirectories of the
\os2\install path, and thus my question, is this the FINAL resting place for
these? Previously, I had the UNI processor stuff going to G:\os2\system\TRACE,
but is the SMP configuration different?
I ask because as I'm attempting to debug the hanging applications I'm trying to
get a good working DUMP/DEBUG/TRACE environment...
Thanks!
-Dariusz
Peter Brown
Nov 24, 2011, 10:36:39 AM11/24/11
to
Hi Dariusz
Dariusz Piatkowski wrote:
> Hi Folks!
>
> Ever since my upgrade to the '21st century computing' (lol - a move from an AMD
> Barton to Phenom X4 setup) I have been experiencing an odd freeze here and
> there. These are not hard locks, rather the WPS stops responding, mouse cursor
> is still OK, CPU monitor (v 1.17) chugs along, but the WPS interface seems to
> stop working. This is always brought on by something a given application has
> attempted to do, once such app is AVXCAT, which I would love to use. The 2nd on
> is the latest PMView install program (WPI based). Both will soft-lock the WPS,
> only CAD helps.
>
> One thing I have been able to narrow this down to is the utilization of the 4
> cores...if I shut-off the 3 remaining cores (using setproc utility) I am able to
> breeze through these processes.
>
> So...what's the config I'm using? Warp4.52, CP2 with FP6 applied, using the SMP
> doscall, os2krnl, etc, PSD=OS2APIC.PSD /P=4 /APIC, although I have tried a bunch
> of different /PIC and /PREC options, none of which had made a difference.
>
Maybe os2apic.psd is not that capable with modern hardware.
You may need to purchase eCS to get current apic support - when eCS
finally get a good working version of their acpi.psd released.
You could try using markexe.exe (from the os/2 toolkit) or execmode.exe
(should be in bootdrive:\os2) to mark apps that do not work with > 1 cpu
and, hopefully, overcome problems.
Regards
Pete
Dariusz Piatkowski wrote:
> Hi Folks!
>
> Ever since my upgrade to the '21st century computing' (lol - a move from an AMD
> Barton to Phenom X4 setup) I have been experiencing an odd freeze here and
> there. These are not hard locks, rather the WPS stops responding, mouse cursor
> is still OK, CPU monitor (v 1.17) chugs along, but the WPS interface seems to
> stop working. This is always brought on by something a given application has
> attempted to do, once such app is AVXCAT, which I would love to use. The 2nd on
> is the latest PMView install program (WPI based). Both will soft-lock the WPS,
> only CAD helps.
>
> One thing I have been able to narrow this down to is the utilization of the 4
> cores...if I shut-off the 3 remaining cores (using setproc utility) I am able to
> breeze through these processes.
>
> So...what's the config I'm using? Warp4.52, CP2 with FP6 applied, using the SMP
> doscall, os2krnl, etc, PSD=OS2APIC.PSD /P=4 /APIC, although I have tried a bunch
> of different /PIC and /PREC options, none of which had made a difference.
>
You may need to purchase eCS to get current apic support - when eCS
finally get a good working version of their acpi.psd released.
You could try using markexe.exe (from the os/2 toolkit) or execmode.exe
(should be in bootdrive:\os2) to mark apps that do not work with > 1 cpu
and, hopefully, overcome problems.
Regards
Pete
Lars Erdmann
Nov 24, 2011, 11:33:22 AM11/24/11
to
The .TDF and .TFF always go into directory \os2\system\trace.
On the other hand and as you have observed they will for some reason or the
other
also show up in other directories (as duplicates I suppose).
The .TDF, .TFF are a black hole. You will need to make sure they match
the corresponding DLLs (or OS2KRNL) for example. The .TDF files specify at
what machine instruction
to set a dynamic tracepoint and what register values/memory location to add
to the tracing buffer
once the dynamic tracepoint is hit.
It should be obvious to you that there needs to be an EXACT match
between .TDF and corresponding DLL(s) / OS2KRNL for this to work.
For one reason or the other, an FP or CP install will not necessarily
install the .TDF,.TFF files when it updates
the DLLs. You might want to consider finding these files in the CP,unpacking
them by
hand and moving them to the \os2\system\trace directory. You might need to
distinguish between W4, SMP and UNI
kernel for those .TDFs that set dynamic tracepoints in OS2KRNL.
Even worse, some updates like for example (I think) JFS might come with
updated .TDF files so you will
have to make sure you also catch these.
What is CP2 with FP6 ? And is there no newer CP for you ?
You should consider upgrading to eCS. That will give you CP4 and CP5.
There even is a CP6 but it is unofficial, you would be on your own ...
Lars
"Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net> schrieb im Newsbeitrag
news:Qg5I6Bo2seGy-pn2-dfemiKMkQyD6@neurobox...
On the other hand and as you have observed they will for some reason or the
other
also show up in other directories (as duplicates I suppose).
The .TDF, .TFF are a black hole. You will need to make sure they match
the corresponding DLLs (or OS2KRNL) for example. The .TDF files specify at
what machine instruction
to set a dynamic tracepoint and what register values/memory location to add
to the tracing buffer
once the dynamic tracepoint is hit.
It should be obvious to you that there needs to be an EXACT match
between .TDF and corresponding DLL(s) / OS2KRNL for this to work.
For one reason or the other, an FP or CP install will not necessarily
install the .TDF,.TFF files when it updates
the DLLs. You might want to consider finding these files in the CP,unpacking
them by
hand and moving them to the \os2\system\trace directory. You might need to
distinguish between W4, SMP and UNI
kernel for those .TDFs that set dynamic tracepoints in OS2KRNL.
Even worse, some updates like for example (I think) JFS might come with
updated .TDF files so you will
have to make sure you also catch these.
What is CP2 with FP6 ? And is there no newer CP for you ?
You should consider upgrading to eCS. That will give you CP4 and CP5.
There even is a CP6 but it is unofficial, you would be on your own ...
Lars
"Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net> schrieb im Newsbeitrag
news:Qg5I6Bo2seGy-pn2-dfemiKMkQyD6@neurobox...
Steve Wendt
Nov 24, 2011, 2:45:23 PM11/24/11
to
On 11/24/11 08:33 am, Lars Erdmann wrote:
> What is CP2 with FP6 ? And is there no newer CP for you ?
CP2 = Convenience Pak 2, FP6 = FixPak 6. There is nothing newer.
> What is CP2 with FP6 ? And is there no newer CP for you ?
> You should consider upgrading to eCS. That will give you CP4 and CP5.
> There even is a CP6 but it is unofficial, you would be on your own ...
Alex Taylor
Nov 25, 2011, 7:36:01 AM11/25/11
to
On Thu, 24 Nov 2011 14:59:36 UTC, "Dariusz Piatkowski"
<dariusz@_NO-SPAM_mnsi.net> wrote:
> Ever since my upgrade to the '21st century computing' (lol - a move from an AMD
> Barton to Phenom X4 setup) I have been experiencing an odd freeze here and
> there. These are not hard locks, rather the WPS stops responding, mouse cursor
> is still OK, CPU monitor (v 1.17) chugs along, but the WPS interface seems to
> stop working. This is always brought on by something a given application has
> attempted to do, once such app is AVXCAT, which I would love to use. The 2nd on
> is the latest PMView install program (WPI based). Both will soft-lock the WPS,
> only CAD helps.
>
> One thing I have been able to narrow this down to is the utilization of the 4
> cores...if I shut-off the 3 remaining cores (using setproc utility) I am able to
> breeze through these processes.
This sounds very similar to what happens on my new Phenom X4 system.
<dariusz@_NO-SPAM_mnsi.net> wrote:
> Ever since my upgrade to the '21st century computing' (lol - a move from an AMD
> Barton to Phenom X4 setup) I have been experiencing an odd freeze here and
> there. These are not hard locks, rather the WPS stops responding, mouse cursor
> is still OK, CPU monitor (v 1.17) chugs along, but the WPS interface seems to
> stop working. This is always brought on by something a given application has
> attempted to do, once such app is AVXCAT, which I would love to use. The 2nd on
> is the latest PMView install program (WPI based). Both will soft-lock the WPS,
> only CAD helps.
>
> One thing I have been able to narrow this down to is the utilization of the 4
> cores...if I shut-off the 3 remaining cores (using setproc utility) I am able to
> breeze through these processes.
In my case, it's SeaMonkey generally that causes the lockup, although
whether or not that's simply because it's the program I've been using
most often on that system or not, I don't know. For me it seems to be
a pretty hard lockup in that nothing responds and I need to reboot.
For me, too, the "fix" is to either disable all but the first core in
the BIOS, or disable SMP. (If I leave two cores running, the problem
happens less often than it does with four, but still happens.)
I've tried with both OS2APIC.PSD and ACPI.PSD, both exhibit the exact
same behaviour here.
Interestingly, however, I've observed the SAME behaviour under Windows XP
on the same box. In this case, running on two cores instead of four
virtually eliminates the problem under Windows, although I have seen it
at least once.
This has led me to suspect a hardware problem rather than an OS one.
OTOH, if you have the same issue, maybe I'm wrong about that.
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.
Dariusz Piatkowski
Nov 25, 2011, 10:38:50 AM11/25/11
to
Hi Seymour,
On Thu, 24 Nov 2011 15:26:37 UTC, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote:
> In <Qg5I6Bo2seGy-pn2-dfemiKMkQyD6@neurobox>, on 11/24/2011
> application. There's an application that will trap C-A-D and includes
> Top and Kill.
I'm usign CAD-Popup here as well...in the lock situations I experience Popup is
unable to respond to the CAD key stroke. Otherwise, the app works great in many
other instances.
Thanks!
On Thu, 24 Nov 2011 15:26:37 UTC, Shmuel (Seymour J.) Metz
<spam...@library.lspace.org.invalid> wrote:
> In <Qg5I6Bo2seGy-pn2-dfemiKMkQyD6@neurobox>, on 11/24/2011
> at 02:59 PM, "Dariusz Piatkowski" <dariusz@_NO-SPAM_mnsi.net> said:
>
> >Ever since my upgrade to the '21st century computing' (lol - a move
> >from an AMD Barton to Phenom X4 setup) I have been experiencing an
> >odd freeze here and there. These are not hard locks, rather the WPS
> >stops responding, mouse cursor is still OK, CPU monitor (v 1.17)
> >chugs along, but the WPS interface seems to stop working. This is
> >always brought on by something a given application has attempted to
> >do, once such app is AVXCAT, which I would love to use. The 2nd on
> >is the latest PMView install program (WPI based). Both will soft-lock
> >the WPS, only CAD helps.
>
> I've sometimes been able to break the lock by killing the offending
>
> >Ever since my upgrade to the '21st century computing' (lol - a move
> >from an AMD Barton to Phenom X4 setup) I have been experiencing an
> >odd freeze here and there. These are not hard locks, rather the WPS
> >stops responding, mouse cursor is still OK, CPU monitor (v 1.17)
> >chugs along, but the WPS interface seems to stop working. This is
> >always brought on by something a given application has attempted to
> >do, once such app is AVXCAT, which I would love to use. The 2nd on
> >is the latest PMView install program (WPI based). Both will soft-lock
> >the WPS, only CAD helps.
>
> application. There's an application that will trap C-A-D and includes
> Top and Kill.
I'm usign CAD-Popup here as well...in the lock situations I experience Popup is
unable to respond to the CAD key stroke. Otherwise, the app works great in many
other instances.
Thanks!
Dariusz Piatkowski
Nov 25, 2011, 10:45:17 AM11/25/11
to
Hi Peter!
On Thu, 24 Nov 2011 15:36:39 UTC, Peter Brown <losepeteS...@ntlworld.com>
wrote:
> Hi Dariusz
>
> Dariusz Piatkowski wrote:
> > Hi Folks!
> >
> > Ever since my upgrade to the '21st century computing' (lol - a move from an AMD
> > Barton to Phenom X4 setup) I have been experiencing an odd freeze here and
> > there. These are not hard locks, rather the WPS stops responding, mouse cursor
> > is still OK, CPU monitor (v 1.17) chugs along, but the WPS interface seems to
> > stop working. This is always brought on by something a given application has
> > attempted to do, once such app is AVXCAT, which I would love to use. The 2nd on
> > is the latest PMView install program (WPI based). Both will soft-lock the WPS,
> > only CAD helps.
> >
> > One thing I have been able to narrow this down to is the utilization of the 4
> > cores...if I shut-off the 3 remaining cores (using setproc utility) I am able to
> > breeze through these processes.
> >
> > So...what's the config I'm using? Warp4.52, CP2 with FP6 applied, using the SMP
> > doscall, os2krnl, etc, PSD=OS2APIC.PSD /P=4 /APIC, although I have tried a bunch
> > of different /PIC and /PREC options, none of which had made a difference.
>
> Maybe os2apic.psd is not that capable with modern hardware.
>
> You may need to purchase eCS to get current apic support - when eCS
> finally get a good working version of their acpi.psd released.
>
> You could try using markexe.exe (from the os/2 toolkit) or execmode.exe
> (should be in bootdrive:\os2) to mark apps that do not work with > 1 cpu
> and, hopefully, overcome problems.
Yes, I suspect OS2APIC has some limitations as well. My MSI BIOS supports MPS
table configuration in 1.1 or 1.4 version...I'm currently trying both
combinations...so far not much luck though.
eCS? Yes....but only if the general concensus out there in the OS2 community is
that the ACPI is stable enough...so far I haven't seen that, but I'm certainly
open to this possibility.
I have both of the EXE marking utilities here...tried them both, the known
applications are still locking the system...so I'm guessing the problem lies
somewhere underneath the covers...meaning, setting a single CPU execution mode
only and shutting off the remaining CPUs do not seen to have the same result.
Thanks!
On Thu, 24 Nov 2011 15:36:39 UTC, Peter Brown <losepeteS...@ntlworld.com>
wrote:
> Hi Dariusz
>
> Dariusz Piatkowski wrote:
> > Hi Folks!
> >
> > Ever since my upgrade to the '21st century computing' (lol - a move from an AMD
> > Barton to Phenom X4 setup) I have been experiencing an odd freeze here and
> > there. These are not hard locks, rather the WPS stops responding, mouse cursor
> > is still OK, CPU monitor (v 1.17) chugs along, but the WPS interface seems to
> > stop working. This is always brought on by something a given application has
> > attempted to do, once such app is AVXCAT, which I would love to use. The 2nd on
> > is the latest PMView install program (WPI based). Both will soft-lock the WPS,
> > only CAD helps.
> >
> > One thing I have been able to narrow this down to is the utilization of the 4
> > cores...if I shut-off the 3 remaining cores (using setproc utility) I am able to
> > breeze through these processes.
> >
> > So...what's the config I'm using? Warp4.52, CP2 with FP6 applied, using the SMP
> > doscall, os2krnl, etc, PSD=OS2APIC.PSD /P=4 /APIC, although I have tried a bunch
> > of different /PIC and /PREC options, none of which had made a difference.
>
> Maybe os2apic.psd is not that capable with modern hardware.
>
> You may need to purchase eCS to get current apic support - when eCS
> finally get a good working version of their acpi.psd released.
>
> You could try using markexe.exe (from the os/2 toolkit) or execmode.exe
> (should be in bootdrive:\os2) to mark apps that do not work with > 1 cpu
> and, hopefully, overcome problems.
table configuration in 1.1 or 1.4 version...I'm currently trying both
combinations...so far not much luck though.
eCS? Yes....but only if the general concensus out there in the OS2 community is
that the ACPI is stable enough...so far I haven't seen that, but I'm certainly
open to this possibility.
I have both of the EXE marking utilities here...tried them both, the known
applications are still locking the system...so I'm guessing the problem lies
somewhere underneath the covers...meaning, setting a single CPU execution mode
only and shutting off the remaining CPUs do not seen to have the same result.
Thanks!
Dariusz Piatkowski
Nov 25, 2011, 11:01:20 AM11/25/11
to
Hi Lars!
On Thu, 24 Nov 2011 16:33:22 UTC, "Lars Erdmann" <lars.e...@arcor.de> wrote:
> The .TDF and .TFF always go into directory \os2\system\trace.
> On the other hand and as you have observed they will for some reason or the
> other also show up in other directories (as duplicates I suppose).
>
> The .TDF, .TFF are a black hole. You will need to make sure they match
> the corresponding DLLs (or OS2KRNL) for example.
Yes sir...I completely understand what you are describing above and that was my
impression of how this was designed. This is why as I switched over to SMP
execution and encountered my problems I wanted to make sure that the FP6 level
of my software was correctly setup to debug at the SMP level as well. Glad to
hear this confirmation though.
> For one reason or the other, an FP or CP install will not necessarily
> install the .TDF,.TFF files when it updates the DLLs. You might want to consider finding these files > in the CP,unpacking them by hand and moving them to the \os2\system\trace directory. You might > need to distinguish between W4, SMP and UNI kernel for those .TDFs that set dynamic tracepoints > in OS2KRNL. Even worse, some updates like for example (I think) JFS might come with
> updated .TDF files so you will have to make sure you also catch these.
>
> What is CP2 with FP6 ? And is there no newer CP for you ?
> You should consider upgrading to eCS. That will give you CP4 and CP5.
> There even is a CP6 but it is unofficial, you would be on your own ...
As Steve Wendt pointed out in another post, CP2 is Convenience Pack2 and FP6 is
the latest, although unofficial fixpack available for this level.
My thinking behind this process is exactly as you pointed out. I am physically
re-doing the FP6 install, only picking up the SMP specific stuff.
The SRV_PROD.OS2 file contained in each FP 'disk' sub-directory contains the
mapping of the actual compressed files to where they need to go, along many
other things, such as version checks and so on. The script to decode this was
provided to me by Chuck McKinnis a few months back and really allows one to
understand what the heck the FP is trying to do.
Here is an example of the OS2.2 subdirectory (small sub-set of the report):
=== START ===
Fixpak name: XR_C006
Product location on CSD: G:\TEST\FP6\fix\OS2.2\
..\..\OS2\INSTALL\UNI Stub File: @UNIDIR
..\..\OS2\INSTALL\SMP Stub File: @SMPDIR
..\..\OS2\PDPSI\PMDF\WARP45_U Stub File: @WARP45U
..\..\OS2\PDPSI\PMDF\WARP45_S Stub File: @WARP45S
Filename Companion Name On CSD D# Date Time Size Checksum Notes
------------ ------------ ------------ -- -------- ----- ------- --------
--------------...
DF_DEB.EXE @WARP45S DF_DEB.SM_ 12 10/17/06 09:19 144355 860D333F
Packed, Add, Ver Check IBM:14.105 \OS2\PDPSI\PMDF\WARP45_S
DF_DEB.EXE @WARP45U DF_DEB.UN_ 13 10/17/06 09:03 136237 04DC1503
Packed, Add, Ver Check IBM:14.105 \OS2\PDPSI\PMDF\WARP45_U
DF_RET.EXE @WARP45S DF_RET.SM_ 11 10/17/06 08:45 144323 89D6EE31
Packed, Add, Ver Check IBM:14.105 \OS2\PDPSI\PMDF\WARP45_S
DF_RET.EXE @WARP45U DF_RET.UN_ 12 10/17/06 08:34 136205 C3BE3148
Packed, Add, Ver Check IBM:14.105 \OS2\PDPSI\PMDF\WARP45_U
DOSCALL1.DLL @SMPDIR DOSCAL1S.DL_ 11 10/17/06 08:44 144677 B0478942
Packed, Same Trg \OS2\INSTALL\SMP
DOSCALL1.DLL @UNIDIR DOSCAL1U.DL_ 12 10/17/06 08:33 137659 5A078A43
Packed, Same Trg \OS2\INSTALL\UNI
DOSCALL1.SYM @WARP45S DOSCAL1S.SY_ 13 10/17/06 08:44 43828 499AE7EB
Packed, Add \OS2\PDPSI\PMDF\WARP45_S
DOSCALL1.SYM @WARP45U DOSCAL1U.SY_ 13 10/17/06 08:33 43476 A0EBEFD9
Packed, Add \OS2\PDPSI\PMDF\WARP45_U
DOSCALL1.TDF @SMPDIR DOSCALL1.SD_ 13 10/17/06 08:44 5534 A2F6C73F
The @UNIDIR placeholder is then decoded to an appropriate disk location and
shows up in the 'Companion' column of the report. This is how I can tell what
compressed file belongs to where and in particular, which level of OS2. SMP vs
UNI is a great example as you can see above. I'm not quite sure what the
@WARP45U and @WARP45S are, but as best as I can tell they may reference the UNI
and SMP enabled version of Warp4.5, which would effectively be an installation
like mine: CP2 on top of the regular Warp4 (but this is just a hypothesis).
So...at this point in time, I have ucompressed all the corresponding files and
have them sitting in their destination locations, this has been done for SMP
stuff ONLY. The curiosity arose becase I have no idea what the \OS2\INSTALL\SMP
location is used by, and as you pointed out, I have always looked at the
\OS2\SYSTEM\TRACE as the final destination for the TDF/TFF files.
Thanks!
On Thu, 24 Nov 2011 16:33:22 UTC, "Lars Erdmann" <lars.e...@arcor.de> wrote:
> The .TDF and .TFF always go into directory \os2\system\trace.
> On the other hand and as you have observed they will for some reason or the
> other also show up in other directories (as duplicates I suppose).
>
> The .TDF, .TFF are a black hole. You will need to make sure they match
> the corresponding DLLs (or OS2KRNL) for example.
impression of how this was designed. This is why as I switched over to SMP
execution and encountered my problems I wanted to make sure that the FP6 level
of my software was correctly setup to debug at the SMP level as well. Glad to
hear this confirmation though.
> For one reason or the other, an FP or CP install will not necessarily
> install the .TDF,.TFF files when it updates the DLLs. You might want to consider finding these files > in the CP,unpacking them by hand and moving them to the \os2\system\trace directory. You might > need to distinguish between W4, SMP and UNI kernel for those .TDFs that set dynamic tracepoints > in OS2KRNL. Even worse, some updates like for example (I think) JFS might come with
> updated .TDF files so you will have to make sure you also catch these.
>
> What is CP2 with FP6 ? And is there no newer CP for you ?
> You should consider upgrading to eCS. That will give you CP4 and CP5.
> There even is a CP6 but it is unofficial, you would be on your own ...
the latest, although unofficial fixpack available for this level.
My thinking behind this process is exactly as you pointed out. I am physically
re-doing the FP6 install, only picking up the SMP specific stuff.
The SRV_PROD.OS2 file contained in each FP 'disk' sub-directory contains the
mapping of the actual compressed files to where they need to go, along many
other things, such as version checks and so on. The script to decode this was
provided to me by Chuck McKinnis a few months back and really allows one to
understand what the heck the FP is trying to do.
Here is an example of the OS2.2 subdirectory (small sub-set of the report):
=== START ===
Fixpak name: XR_C006
Product location on CSD: G:\TEST\FP6\fix\OS2.2\
..\..\OS2\INSTALL\UNI Stub File: @UNIDIR
..\..\OS2\INSTALL\SMP Stub File: @SMPDIR
..\..\OS2\PDPSI\PMDF\WARP45_U Stub File: @WARP45U
..\..\OS2\PDPSI\PMDF\WARP45_S Stub File: @WARP45S
Filename Companion Name On CSD D# Date Time Size Checksum Notes
------------ ------------ ------------ -- -------- ----- ------- --------
--------------...
DF_DEB.EXE @WARP45S DF_DEB.SM_ 12 10/17/06 09:19 144355 860D333F
Packed, Add, Ver Check IBM:14.105 \OS2\PDPSI\PMDF\WARP45_S
DF_DEB.EXE @WARP45U DF_DEB.UN_ 13 10/17/06 09:03 136237 04DC1503
Packed, Add, Ver Check IBM:14.105 \OS2\PDPSI\PMDF\WARP45_U
DF_RET.EXE @WARP45S DF_RET.SM_ 11 10/17/06 08:45 144323 89D6EE31
Packed, Add, Ver Check IBM:14.105 \OS2\PDPSI\PMDF\WARP45_S
DF_RET.EXE @WARP45U DF_RET.UN_ 12 10/17/06 08:34 136205 C3BE3148
Packed, Add, Ver Check IBM:14.105 \OS2\PDPSI\PMDF\WARP45_U
DOSCALL1.DLL @SMPDIR DOSCAL1S.DL_ 11 10/17/06 08:44 144677 B0478942
Packed, Same Trg \OS2\INSTALL\SMP
DOSCALL1.DLL @UNIDIR DOSCAL1U.DL_ 12 10/17/06 08:33 137659 5A078A43
Packed, Same Trg \OS2\INSTALL\UNI
DOSCALL1.SYM @WARP45S DOSCAL1S.SY_ 13 10/17/06 08:44 43828 499AE7EB
Packed, Add \OS2\PDPSI\PMDF\WARP45_S
DOSCALL1.SYM @WARP45U DOSCAL1U.SY_ 13 10/17/06 08:33 43476 A0EBEFD9
Packed, Add \OS2\PDPSI\PMDF\WARP45_U
DOSCALL1.TDF @SMPDIR DOSCALL1.SD_ 13 10/17/06 08:44 5534 A2F6C73F
Packed, Add \OS2\INSTALL\SMP
DOSCALL1.TDF @UNIDIR DOSCALL1.UD_ 13 10/17/06 08:33 5534 6FBFC3B9
Packed, Add \OS2\INSTALL\UNI
=== STOP ===
The @UNIDIR placeholder is then decoded to an appropriate disk location and
shows up in the 'Companion' column of the report. This is how I can tell what
compressed file belongs to where and in particular, which level of OS2. SMP vs
UNI is a great example as you can see above. I'm not quite sure what the
@WARP45U and @WARP45S are, but as best as I can tell they may reference the UNI
and SMP enabled version of Warp4.5, which would effectively be an installation
like mine: CP2 on top of the regular Warp4 (but this is just a hypothesis).
So...at this point in time, I have ucompressed all the corresponding files and
have them sitting in their destination locations, this has been done for SMP
stuff ONLY. The curiosity arose becase I have no idea what the \OS2\INSTALL\SMP
location is used by, and as you pointed out, I have always looked at the
\OS2\SYSTEM\TRACE as the final destination for the TDF/TFF files.
Thanks!
Dariusz Piatkowski
Nov 25, 2011, 11:08:29 AM11/25/11
to
Hi Alex!
On Fri, 25 Nov 2011 12:36:01 UTC, "Alex Taylor" <mai...@reply.to.address>
wrote:
I do not have a working install of Windows here...well, I used to, but haven't
ventured into that partition for quite some time now...not since the overall
hardware change, so the Windows device drivers certainly need to be re-worked,
etc. I do need to do this sometime, just so I can have some type of a comparison
if anything.
I had used 'OS/2 API Trace' v2.45.40 (by Dave Blaschke) on AVxCAT specifically.
Great tool, however I have found that as the freeze occurs the trace (which is
being logged into a disk file) just stops dead smack in the middle of a
stream...so its' as if something gets completely blocked and even the API Trace
can no longer write to the disk.
There are a couple of things I want to try with the trace, beyond this I am
thinking of attempting the DEBUG kernel run as I still have my old OS2 machine
standing by. This is all new to me though...so time will tell if I can make any
progress on this.
Thanks!
On Fri, 25 Nov 2011 12:36:01 UTC, "Alex Taylor" <mai...@reply.to.address>
wrote:
ventured into that partition for quite some time now...not since the overall
hardware change, so the Windows device drivers certainly need to be re-worked,
etc. I do need to do this sometime, just so I can have some type of a comparison
if anything.
I had used 'OS/2 API Trace' v2.45.40 (by Dave Blaschke) on AVxCAT specifically.
Great tool, however I have found that as the freeze occurs the trace (which is
being logged into a disk file) just stops dead smack in the middle of a
stream...so its' as if something gets completely blocked and even the API Trace
can no longer write to the disk.
There are a couple of things I want to try with the trace, beyond this I am
thinking of attempting the DEBUG kernel run as I still have my old OS2 machine
standing by. This is all new to me though...so time will tell if I can make any
progress on this.
Thanks!
Peter Brown
Nov 27, 2011, 2:17:00 PM11/27/11
to
"goodie" that is not yet publicly available.
As I understand it it cures problems with SMP "spinlocks" - and, no, I
have no idea what that means. I do know that I have been experiencing
less system hangs at boot when the Desktop should be starting since
installing this new doscall1.dll file though.
Regards
Pete
Peter Flass
Nov 28, 2011, 7:42:07 AM11/28/11
to
multicore systems: different CPUs can have different versions of the
same data. This might mean, for example, that one CPU can free a lock
on some resource while the other CPU thinks it's still locked and waits
forever.
0 new messages