Author Topic: OS/4 (technical details only)  (Read 18814 times)

OS4User

  • Full Member
  • ***
  • Thank You
  • -Given: 28
  • -Receive: 6
  • Posts: 216
    • View Profile
Re: OS/4 (technical details only)
« Reply #45 on: July 03, 2018, 01:21:44 pm »
Please tell me how to get such a log. I need a Com-null modem cable and some software on the other side (Windows OS & with logging software, perhaps)? This type of testing, I have not yet conducted.

Here is some info how to get com port log https://www.os2world.com/wiki/index.php/Phoenix_OS/4

David Graser

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 61
  • Posts: 515
    • View Profile
Re: OS/4 (technical details only)
« Reply #46 on: March 04, 2019, 06:44:50 am »
I use OS/4 kernel on one of my partitions.

Presently, I have been using test build SVN5447.

i noticed that when I try to use FF 45.9.0, it always traps at this web page.   It occurs with FFTurbo enabled or disabled.

https://beforeitsnews.com/v3/

If I boot using the OS/2 loader and kernel, the traps disappear.

Attached are a couple of trap logs.

The traps occur on earlier test builds of the OS/4 kernel also.
« Last Edit: March 04, 2019, 06:50:36 am by David Graser »

Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 43
  • Posts: 427
    • View Profile
Re: OS/4 (technical details only)
« Reply #47 on: March 04, 2019, 07:23:12 am »
1) looks like you have an out of date EXCEPTQ package. It does not properly decode the real instruction.

2) the failing instruction starts with a VEX prefix (and is incorrectly decoded in the following). It is likely an SSE or AVX instruction that fails due to unaligned memory (memory accesses need to be 16-byte aligned for SSE (128 bit) registers and 32-byte aligned for AVX (256 bit) registers).
That said I think there is a problem wtih libcn0.dll that needs a rebuild with a new compiler so that data used with SSE/AVX instructions is properly aligned (for all stack based references and also all static data in the data segment). You might want to try a newer test build of the new "libc" package (which contains libcn0).

Question is why does it only appear with the OS/4 kernel ? I can only guess: the code takes a different code path with the OS/2 kernel and the OS/4 kernel. Maybe because OS/4 kernel signals AVX support (if of course the CPU supports it) and the OS/2 kernel does not.

Lars
« Last Edit: March 04, 2019, 07:28:56 am by Lars »

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2168
    • View Profile
Re: OS/4 (technical details only)
« Reply #48 on: March 04, 2019, 08:00:16 am »
Hi David, can you install the FFmpeg debug package (ffmpeg-debug) as well as the libc debug package and produce another trp?
I take it you were playing a video or other media when it crashed?
Perhaps also try playing some videos with FFplay and see if it crashes. I don't think the Netlabs build has exceptq support so it'll just print some exception info.
Lars may well be right about libcn, be interesting if the same crash occurs with kLIBC.
The SSE and VEX code in libavcodec is all handwritten assembler, so unless there is a bug in our nasm port, libcn seems like a candidate for the failure.

OS4User

  • Full Member
  • ***
  • Thank You
  • -Given: 28
  • -Receive: 6
  • Posts: 216
    • View Profile
Re: OS/4 (technical details only)
« Reply #49 on: March 04, 2019, 08:31:49 am »
https://beforeitsnews.com/v3/

Hi David

I have just checked this site on my os/4 based system  - it works ok, but my avcode56.dll has different size  (6 053 546) inspite of the same date. May be it is because of deferent platform.
And I still use libc066-38(oc00).


What CPU do you use in your comp? And which platform your avcode56 is compiled for?


Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 43
  • Posts: 427
    • View Profile
Re: OS/4 (technical details only)
« Reply #50 on: March 04, 2019, 09:18:01 am »
Looking at it again:

If it is true that all SSE/AVX code in AVCODE56.DLL is handwritten in assembler then I suspect either one of 2 possibilities:

1) some dynamic memory is passed to AVCODE56.DLL which is not aligned: but from the used registers, EAX and EDI point to memory allocated by LIBCN0 which aligns to 32-bytes. That would be enough for both, SSE and also AVX.

2) the data used in AVCODE56.DLL itself is not properly aligned (even if coded by hand). Maybe someone forgot that AVX code needs data to be 32-byte aligned when some code was upgraded from SSE to AVX. The incorrectly decoded code seems to imply that some constant seems to be taken directly from the code segment (address: 0x0cd22e50). That is, this constant is directly embedded in the code. And this constant is only 16-byte aligned where AVX code requires 32-byte alignment. If somebody had the AVCODE56 code, it would be easy to check.

If I had to guess I would think that the incorrectly decoded instruction is a VMOVDQA or VMOVAPD, VMOVAPS instruction:
VMOVAPD ymm0,[0x0cd22e50). And according to Intel manual, this instruction requires 32-byte data alignment.

Lars
« Last Edit: March 04, 2019, 10:01:40 am by Lars »

OS4User

  • Full Member
  • ***
  • Thank You
  • -Given: 28
  • -Receive: 6
  • Posts: 216
    • View Profile
Re: OS/4 (technical details only)
« Reply #51 on: March 04, 2019, 10:09:23 am »
Looking at it again:
If it is true that all SSE/AVX code in AVCODE56.DLL is handwritten in assembler then I suspect either one of 2 possibilities:
....

To Lars:

What you saying is quite possible. One more way to check it -  is test OS/4 kernel without AVX support.

To David:

Pls, open  your site   on this test kernel http://gus.biysk.ru/os4/os4krnl_noAVX.zip

David Graser

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 61
  • Posts: 515
    • View Profile
Re: OS/4 (technical details only)
« Reply #52 on: March 04, 2019, 12:37:27 pm »
Looking at it again:
If it is true that all SSE/AVX code in AVCODE56.DLL is handwritten in assembler then I suspect either one of 2 possibilities:
....

To Lars:

What you saying is quite possible. One more way to check it -  is test OS/4 kernel without AVX support.

To David:

Pls, open  your site   on this test kernel http://gus.biysk.ru/os4/os4krnl_noAVX.zip

Thanks for all the responses.

I just installed the noAVX kernel and my traps have disappeared.  This is just preliminary but I have no problem going to that web site and others so far.  So far, so good.

My avcode56.dll is the same size and date on both my ArcaOS 5.02 and ArcaOS 5.03 partitions.

Attached a pic of my type of CPU info.  While modifying this message, I had another trap which I have attached.  I just remembered that this is another instance when a trap occurred. However, so far, this one trap is all I have encountered so far with the noAVX.

By the way Dave, I just installed the debug versions you recommended after this last trap.  So far though, Firefox is much more stable with the noAVX kernel version.  It feels good to be able to use FF again without it continually crashing when using the OS/4 kernel. 
« Last Edit: March 04, 2019, 01:36:11 pm by David Graser »

OS4User

  • Full Member
  • ***
  • Thank You
  • -Given: 28
  • -Receive: 6
  • Posts: 216
    • View Profile
Re: OS/4 (technical details only)
« Reply #53 on: March 04, 2019, 02:39:35 pm »
I just installed the noAVX kernel and my traps have disappeared.

It looks like Lars was correct and the issue is related to AVX instruction. Meanwhile, the bug is not in kernel, but probably in AVCODE56.DLL or in the code which calls it.

If OS/4 kernel detects AVX hardware it installs support for AVX  and sets proper bit in CR4.

The software may detects this bit later on and engages own AVX code branch. (There are a few progs which successfully use AVX.  For ex. https://bitbucket.org/dryeo/dry-comm-esr31/downloads/firefox-45.9.0.en-US.os2.SandyBridge.zip)

P.S.
It was suggested by BWW to remove libc-debug 0.6.6-40  and install libc-debuginfo instead of it.
« Last Edit: March 04, 2019, 05:06:05 pm by OS4User »

Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 43
  • Posts: 427
    • View Profile
Re: OS/4 (technical details only)
« Reply #54 on: March 04, 2019, 05:00:46 pm »

Thanks for all the responses.

I just installed the noAVX kernel and my traps have disappeared.  This is just preliminary but I have no problem going to that web site and others so far.  So far, so good.

My avcode56.dll is the same size and date on both my ArcaOS 5.02 and ArcaOS 5.03 partitions.

Attached a pic of my type of CPU info.  While modifying this message, I had another trap which I have attached.  I just remembered that this is another instance when a trap occurred. However, so far, this one trap is all I have encountered so far with the noAVX.

Yes, the "new" trap is not AVX related at all. It is something completely different. Looks like EBX is supposed to contain a full address but it seems to contain only an address offset (or an offset summed up on top of a NULL pointer which is more likely ...)

Too bad, your screen shot does not show the feature flags. That would have been more interesting ...

Lars
« Last Edit: March 04, 2019, 05:28:58 pm by Lars »

David Graser

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 61
  • Posts: 515
    • View Profile
Re: OS/4 (technical details only)
« Reply #55 on: March 04, 2019, 06:18:02 pm »
Hi Lars

I have attached a picture of the CPU flags.

David Graser

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 61
  • Posts: 515
    • View Profile
Re: OS/4 (technical details only)
« Reply #56 on: March 04, 2019, 06:24:40 pm »
I just installed the noAVX kernel and my traps have disappeared.

P.S.
It was suggested by BWW to remove libc-debug 0.6.6-40  and install libc-debuginfo instead of it.

Done.  Thanks OS4User.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2168
    • View Profile
Re: OS/4 (technical details only)
« Reply #57 on: March 05, 2019, 01:00:30 am »
Hi David, that crash looks like one I get now and again, I believe font related.
Have you tested with the Firefox build that OS4USER mentioned? Perhaps with the AVX enabled kernel? You can get a list of CPU capabilities with this program, http://hobbes.nmsu.edu/download/pub/os2/util/misc/cpuinfo.zip
If needed, I could build FFmpeg with AVX disabled. Be nice to know which function it is crashing in too.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2168
    • View Profile
Re: OS/4 (technical details only)
« Reply #58 on: March 05, 2019, 01:13:29 am »
Hi Lars, FFmpeg is pretty well tested with the fate suite of tests, probably a couple of thousand test now. See (currently not loading) http://fate.ffmpeg.org/
I used to run it and pass all the tests. Unluckily our tool chain is just too buggy now. Problems with GCC, problems with libc, problems with git, even problems with the PMSHELL at least.
To pass I was using an early build of GCC 4.4.6, libc065 on Warp v4.
Problems included. At one point using the official nasm built with OpenWatcom, I had four H264 conformance tests failing, there were quite a few at the time. This was fixed by recompiling nasm with GCC. Weird subtle failure.
Upgrading GCC caused various transcoding failures as well filter errors.
Upgrading to eCS caused floating point crashes without patching to restore the FPU control word.
Upgrading to libc066 fixed the floating point errors but caused errors transcoding to MP2 and failures with other tests that depended on the MP2 file.
Currently running the testsuite causes git to fail and I believe output its help, at least it is actually less that hangs waiting for input. IIRC, this is a test to make sure all code has correct licensing and cats the output of git through grep or similar.
There are other tests where the ffmpeg binary hangs, killing it allows the test suite to continue.
Most platforms usually pass all the tests.

David Graser

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 61
  • Posts: 515
    • View Profile
Re: OS/4 (technical details only)
« Reply #59 on: March 05, 2019, 01:43:05 am »
Hi David, that crash looks like one I get now and again, I believe font related.
Have you tested with the Firefox build that OS4USER mentioned?

Dave, I tried the SandyBridge port of FF and the program would not start when using the OS/4 kernel and loader. This is when I decided to post here to see what could be done. I did not try it with the OS/2 kernel.  The noAVX version is working great with the OS/4 kernel. The lastest build of your FF 45.9.0 pentium is the best yet.  I am having no problems watching videos and accessing web pages.  I no longer have to boot to Windows to get reliable internet.  Again, thanks to all who continue to donate their time and effort to make using ArcaOS and other versions more enjoyable.

PS- I posted another graphic of the CPU cabilities (feature flags) above at reply #55.

David
« Last Edit: March 05, 2019, 01:45:37 am by David Graser »