OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: dbanet on January 31, 2014, 01:09:50 pm

Title: New OS/4 kernel :: SVN4227
Post by: dbanet on January 31, 2014, 01:09:50 pm
Hi OS/2World,

The Phoenix project proudly presents the new release of the OS/4 kernel that just has been made available at site.
Whatsnew list includes the new SCREEN03.SYS and SDDHELP.SYS drivers, bugfixes, enhancements and new features.

Due to the technical problems that will be fixed ASAP the new kernel releases are not available on Russian Underground/2 (http://ru2.halfos.ru) server.

They are posted at gus.biysk.ru server in the /os4 directory (http://www.gus.biysk.ru/os4/). For example, the current latest release, SVN4227, is available here as a zip file (http://gus.biysk.ru/os4/os2krnlSVN4227_unoff.zip).

I will also update this topic for every new release to keep the OS/2World community up to date with the Phoenix project.

To help new OS/4 users, I've created a page on OS/2World Wiki (http://www.os2world.com/wiki/index.php/OS/4), which consists of
Even if you are an experienced user (OS/2, or both OS/2 and OS/4), you are recommended to read it anyway, because there are lots of changes in the recent releases.
Also help on the page, especially if you are a native English speaker, is needed and appreciated (http://www.os2world.com/forum/index.php/topic,324.msg2912.html#msg2912).



20 Feb 2014.
SVN4168 released.
Don't know about changes in this release.

QSINIT loader full source code has just been made available -->
--> http://www.os2world.com/forum/index.php/topic,324.msg2882.html#msg2882



06 Mar 2014.
SVN4169 released.
Whatsnew list from 4166 to 4169 is as follows:



10 Mar 2014.
SVN4171 released.



12 Mar 2014.
SVN4172 released.



25 Mar 2014.
SVN4173 released.



19 Apr 2014.
SVN4177 released.



26 Apr 2014.
SVN4180 released.



03 May 2014.
SVN4182 released.



04 May 2014.
SVN4183 released.



23 May 2014.
SVN4188 released.



24 May 2014.
SVN4189 released.



03 June 2014 -- 04 June 2014
SVN4191, SVN4192, SVN4193, SVN4194 released.

These are test builds.



04 June 2014.
SVN4195 released.



06 June 2014.
SVN4198 released.




08 June 2014.
SVN4200 released.



15 June 2014 — 14 July 2014.
SVN revisions from 4202 to 4219 released.



04 Aug 2014.
SVN4221 released.



06 Aug 2014 — 22 Aug 2014.
SVN revisions from 4222 to 4224 released.



22 Aug 2014.
SVN4225 released.



24 Aug 2014.
SVN revisions from 4226 to 4227 released.

Regards,
dbanet.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: David McKenna on February 01, 2014, 12:56:27 am
Boris,

  Thanks for the link to the new kernel. It seems to work well here (Intel H55 chipset, i3 processor, Intel video, 4GB RAM). I do still get a POPUPLOG from DMISL.EXE on boot that I don't get with the IBM kernel, but so far there is no noticeable problem from that.

  I was wondering if this kernel can make use of Hyperthreading? Also, what does the new screen03.sys driver add? It would be good if the package came with a description of the enhancements the new kernel provides. Don't be shy about blowing your horn a little bit... it may make more people decide to try it....8-)
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Lars on February 01, 2014, 12:36:35 pm
The one thing that bothers me is that the OS/4 team decided to drop trace (static/dynamic tracing (TRACE) and as far as I understand also performance tracing (STRACE)) support and I don't know for which reason.
As a consequence that means that people using the OS/4 kernel will not be able to take a trace for the USB drivers that I have reworked and that David took over. There are other drivers like OS2DASD.DMD that also make use of tracing as well as the (original OS/2) kernel itself.
That said, we (David and I) will not be able to support people that use the OS/4 kernel who have problems with the USB drivers as they won't be able to take a trace. The best we can do is fix a trap in any of the USB drivers where a trap screen exists (this scenario does not require tracing to work, tracing is helpful if functional oddities occur that don't lead to a trap but rather to some odd malfunction).

I think users should be aware of that.


Lars
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: OS4User on February 01, 2014, 01:00:16 pm
I was wondering if this kernel can make use of Hyperthreading?

I have it tested on HT cpu  -  so far, no problem was found.

Also, what does the new screen03.sys driver add?

SCREEN03.SYS is mostly 32bit coded and uses new KEE entry:

KernAllocLDT & KernFreeLDT analog of  DHPhysToUVirt
KernVMProcessToGlobal analog of  DHVMProcessToGlobal
KernVMGlobalToProcess analog of  DHVMGlobalToProcess

KernVMAlloc2 same as  KernVMAlloc but recognizes cache control flags :
   VMDHA_UC
   VMDHA_UCMINUS
   VMDHA_WT
   VMDHA_WP
   VMDHA_WB
   VMDHA_WC

KernVMAlloc2 with VMDHA_WC is called from SCREEN$ IOCTL 80.B -  this way  mapping for Panorama LFB receives Write Combine caching.

Title: USBMSD
Post by: dbanet on February 01, 2014, 02:20:18 pm
USB drivers

So, did you see my email about usbmsd?
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 01, 2014, 02:27:00 pm
I was wondering if this kernel can make use of Hyperthreading? Also, what does the new screen03.sys driver add? It would be good

Yes, it can. For better performance turn on the ExtraKernelHlt key in the ACPID.CFG file.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: David McKenna on February 01, 2014, 03:08:58 pm
  Thanks for the info! This is exactly the kind of thing needed in the kernel package. Keep it coming...
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: R.M. Klippstein on February 01, 2014, 09:46:35 pm
So far ------Soooo Good! and many, many thanks for you're efforts Boris!

klipp
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 02, 2014, 08:20:01 pm
So far ------Soooo Good! and many, many thanks for you're efforts Boris!

klipp
Hi klipp,

I'm not a member of the OS/4 kernel development team, and I don't unfortunately have sufficient skills to participate in kernel development. I use and test the kernel on my OS/2 machines. You are welcome to the #os2russian (http://irc://efnet/os2russian) channel to thank the OS/4 developers directly, and participate in testing.

The reason I take part in discussion here at os2world forums, is that I find a significant part of OS/2 community being not enough informed about the progress of the Phoenix project.

Regards.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 04, 2014, 12:59:43 am
I gave OS/4 a try on my Lenovo ThinkPad L530. It has a 2 core I5 Intel processor, with 4 GB of memory, and UEFI BIOS.

If I try to use the os4krnl file, it always hangs hard (the mouse won't even move) when the blue screen first appears. The next thing that I expect to see, is the STARTUP.CMD window. The only way out is to hold the power switch for 5 seconds.

If I try using the os4krnlr file, it seems to boot okay, but I haven't tried everything yet.

The good news is that it gives me 3170 MB, where the IBM kernel gives me 512 MB.

I find the documentation to be somewhat confusing, and the OS2LDR.INI file is not all that helpful, but experimenting with it doesn't seem to do any damage.   :-\
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 04, 2014, 04:36:15 am
Well, after a bit more testing, I found that using os4krnlr boots okay, but trying to use UNIMIX.EXE causes a strange problem. It works, as expected, with the base eCS 2.2 beta II install (IBM kernel). If I try it with os4krnlr, UNIMIX.EXE responds with "SYS0193: UNIAUD cannot be run in a OS/2 session." (yes, it does say "UNIAUD"). I am not sure what that is all about, but something is wrong.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: OS4User on February 04, 2014, 07:01:31 am
I gave OS/4 a try on my Lenovo ThinkPad L530. It has a 2 core I5 Intel processor, with 4 GB of memory, and UEFI BIOS.

If I try to use the os4krnl file, it always hangs hard (the mouse won't even move) when the blue screen first appears. The next thing that I expect to see, is the STARTUP.CMD window. The only way out is to hold the power switch for 5 seconds.

If I try using the os4krnlr file, it seems to boot okay, but I haven't tried everything yet.

The good news is that it gives me 3170 MB, where the IBM kernel gives me 512 MB.

I find the documentation to be somewhat confusing, and the OS2LDR.INI file is not all that helpful, but experimenting with it doesn't seem to do any damage.   :-\

is it possible to see comport log file ?

try to start without STARTUP.CMD


Well, after a bit more testing, I found that using os4krnlr boots okay, but trying to use UNIMIX.EXE causes a strange problem. It works, as expected, with the base eCS 2.2 beta II install (IBM kernel). If I try it with os4krnlr, UNIMIX.EXE responds with "SYS0193: UNIAUD cannot be run in a OS/2 session." (yes, it does say "UNIAUD"). I am not sure what that is all about, but something is wrong.

I have just check it on my comp   -  UNIMIX.EXE works fine.

Does uniaud work ok with os/4 kernel on you comp ?
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 04, 2014, 01:01:31 pm
I gave OS/4 a try on my Lenovo ThinkPad L530. It has a 2 core I5 Intel processor, with 4 GB of memory, and UEFI BIOS.

If I try to use the os4krnl file, it always hangs hard (the mouse won't even move) when the blue screen first appears. The next thing that I expect to see, is the STARTUP.CMD window. The only way out is to hold the power switch for 5 seconds.

If I try using the os4krnlr file, it seems to boot okay, but I haven't tried everything yet.

The good news is that it gives me 3170 MB, where the IBM kernel gives me 512 MB.

I find the documentation to be somewhat confusing, and the OS2LDR.INI file is not all that helpful, but experimenting with it doesn't seem to do any damage.   :-\

os2krnl is the debug version, and os2krnlr is the release version. When the debug version hangs, try hitting Control-Alt-Shift-Scroll Lock-Scroll Lock, then if it prompts you to insert a diskette, then it is possible that it just falls into kernel debugger over a COM port (that looks like a hang) because of some not very important thing failing. The release version does not do that because lacks the kernel debugger feature. Also that may be just a bug in the non-release version. The thing is the release version of the kernel is not the master one, so it may lack some features and/or bugfixes, and/or, bugs.

Anyway, to avoid the debug version from falling into KDB, you may try writing this:
Code: [Select]
.b 115200t
g
g
g
g
g
ln
k
into \KDB.INI file on your boot drive. That helped me once.

It seems that your laptop does not have a hardware COM port, so I'm not actually sure how can one get a log if there is no COM port in a PC, and that is impossible to insert one.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 04, 2014, 05:07:51 pm
Quote
It seems that your laptop does not have a hardware COM port

True. There is no diskette either. Very few, if any, modern laptops have either one.

Quote
is it possible to see comport log file

I don't know of any way to see it. I do have a Belkin USB serial adapter, and a cable. I will give that a try later.

I did turn off the serial port address in the OS2LDR.INI file, but that didn't change anything.

Quote
Does uniaud work ok with os/4 kernel on you comp

UNIAUD appears to load okay, but I can't hear anything until UNIMIX turns on the proper controls. UNIAUD doesn't work right anyway (I think that has something to do with the Dolby feature), but it does make sound when using the kernel that comes with eCS 2.2 beta II (and the one in eCS 2.1), after UNIMIX turns on the proper controls.

I find it odd that UNIMIX can't run UNIAUD in OS/2.

Quote
Anyway, to avoid the debug version from falling into KBD, you may try writing this

I will try that, and  few other things, when I get a chance. I also need to try it on a different machine.

Thanks...
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 05, 2014, 12:32:11 am
Quote
Anyway, to avoid the debug version from falling into KDB, you may try writing this

I am not sure how that works, but it will boot if I do that.

I will try the USB to serial adapter, if I can find it. Meanwhile, I guess I will run the os4krnlr version, to see what else shows up.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: OS4User on February 05, 2014, 06:59:37 am
I will try the USB to serial adapter, if I can find it. Meanwhile, I guess I will run the os4krnlr version, to see what else shows up.

USB to serial adapter will not help you  if your test machine does not have com port.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 07, 2014, 07:43:27 pm
Well, after a bit more testing, I found that using os4krnlr boots okay, but trying to use UNIMIX.EXE causes a strange problem. It works, as expected, with the base eCS 2.2 beta II install (IBM kernel). If I try it with os4krnlr, UNIMIX.EXE responds with "SYS0193: UNIAUD cannot be run in a OS/2 session." (yes, it does say "UNIAUD"). I am not sure what that is all about, but something is wrong.

I've (accidentally) reproduced this problem on my machine and I had to report it to OS/4 kernel developers. Fortunately, the problem entirely resides in the uniaud.dll: the bug in it was being compensated by the bug in the original kernel causing uniaud.dll to work without any problems. When the bug in the kernel was fixed by Phoenix people, uniaud.dll stopped to work properly on the OS/4 kernel.

You are welcome to download another version of uniaud.dll (http://dbanet.org/libs/files/uniaud.dll/1), which does not contain the bug in it and which works fine with the OS/4 kernel, as well as with the original one. Replace the existing one, which resides in the \MMOS2\DLL directory, with the downloaded one. To accomplish this, you may (or may not) need the UNLOCK.EXE utility from lxLite, the opensource utility package (http://hobbes.nmsu.edu/h-search.php?key=lxlite&pushbutton=Search), to unlock and replace the DLL if it was locked by uniaud or someone else. After that, reboot your system.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 07, 2014, 09:06:26 pm
Quote
USB to serial adapter will not help you  if your test machine does not have com port.

I expect that you are right, but I will try it anyway, if I can find the device.   :(

Quote
You are welcome to download another version of uniaud.dll,

Did that, and yes, it does fix the problem (will that fix be submitted to the official sources?). The sound still doesn't work properly, but it works the same as it does with the IBM kernels. I guess I need to rattle Paul Smedley's chain, to get an updated UNIAUD.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Paul Smedley on February 07, 2014, 10:26:26 pm
Quote
You are welcome to download another version of uniaud.dll,

Did that, and yes, it does fix the problem (will that fix be submitted to the official sources?). The sound still doesn't work properly, but it works the same as it does with the IBM kernels. I guess I need to rattle Paul Smedley's chain, to get an updated UNIAUD.

IIRC the source for uniaud.dll isn't at netlabs. Which uniaud build are you running? and which device? I have a build using alsa 1.0.24 source, but was never able to get 1.0.25 working.  Later builds are integrated into the linux kernel and not available as standalone packages which makes things more problematic in terms of updates.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 07, 2014, 11:57:34 pm
Paul, the DLL was not fixed by the Phoenix project, that's just a DLL from one of the binary uniaud distributions, and actually I don't know from which one is it. I have to do further testing and figure out what releases posted on netlabs' Trac are broken, but the DLL in the latest release is reported to work just okay with OS/4, although I didn't test it myself.

The old broken DLL may still remain on some users' systems, for example, due to not updating uniaud on time, or due to other reasons, so updating uniaud manually may be a good thought.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 08, 2014, 07:30:13 am
Quote
Which uniaud build are you running?

It is from UniaudUpdate1.09.06-2.02.01.zip which is the latest that I know about. Earlier versions won't load at boot time (they pop up something about no hardware found, as I recall).

Quote
and which device?

It is in a Lenovo ThinkPad L530. From PCI.EXE:
Code: [Select]
Bus 0 (PCI Express), Device Number 27, Device Function 0
 Vendor 8086h Intel Corporation
 Device 1E20h 7 Series/C210 Series Chipset Family High Definition Audio Controller
 Command 0006h (Memory Access, BusMaster)
 Status 0010h (Has Capabilities List, Fast Timing)
 Revision 04h, Header Type 00h, Bus Latency Timer 00h
 Self test 00h (Self test not supported)
 Cache line size 64 Bytes (16 DWords)
 PCI Class Multimedia, type Unknown!
 Subsystem ID 21F717AAh Unknown
 Subsystem Vendor 17AAh Lenovo
 Address 0 is a Memory Address (64-bit) : F2610000h..F2613FFFh
 System IRQ 22, INT# A
 New Capabilities List Present:
   Power Management Capability, Version 1.1
     Does not support low power State D1 or D2
     Supports PME# signalling from mode(s) D0, D3hot, D3cold
     PME# signalling is currently disabled
     3.3v AUX Current required : 55 mA
     Current Power State : D0 (Device operational, no power saving)
   Message Signalled Interrupt Capability
     MSI is disabled
     MSI function can generate 64-bit addresses
   PCI Express Capability, Version 1
     Device/Port Type :
       Root Complex Integrated Endpoint Device
       Unsupported Request Severity is Non-Fatal
     Device Status :
       AUX Power Detected
     Link Capabilities :
       Maximum Link speed : Unknown (00h)!!
       Maximum Link Width : xReserved
       Link Port Number   : 0
     Link Control :
       Asynchronous Clocking in Use
     Link Status :
       Current Link speed : Unknown (00)!!
       Current Link Width : x0
but Win7 Pro 64 claims there is also a Realtek High Definition Audio device, that I don't see with PCI.EXE. I think one of them might be for the HDMI interface.

The other "complication", and what I think is causing my problem, is that windows uses a DOLBY driver for it. I think that may be the problem because I do hear sounds, but it is like being in an echo chamber. There is no sign of hangs, so I don't think it is IRQ related. I suspect that there may be a new control, that will turn the DOLBY off, and there are probably other controls that make the DOLBY feature do different things, that UNIMIX doesn't know about. There is no sound, at all, until I use UNIMIX to turn on the speakers, and turn the volume up.

Quote
The old broken DLL may still remain on some users' systems, for example, due to not updating uniaud on time, or due to other reasons, so updating uniaud manually may be a good thought.

The UNIAUD.DLL, that I had, is from eCS 2.2 beta 2. Bldlevel says:
Code: [Select]
Signature:       @#UNIAUD:0.3.0#@ Vladest Software
Vendor:          UNIAUD
Revision:        0.03.0
File Version:    0.3
Description:     Vladest Software
The one that works says there is no version information. The date on the file is today, so that is meaningless. The same "broken" file (bldlevel) is what came with eCS 2.1 as well (dated June 26, 2008), so anybody with a reasonably current eCS will have the broken file. I am pretty sure that reporting the problem to the eCS bug tracker would simply get discarded as being a problem with an unsupported kernel, unless we can find something else that fails with it.

FWIW, I do have Linux Mint 15, and the sound works properly. I will need to figure out what driver it uses.

Quote
Meanwhile, I guess I will run the os4krnlr version, to see what else shows up.

So far, everything else seems to work well, but I really haven't done a lot with it.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Paul Smedley on February 08, 2014, 09:21:03 am
Quote
Which uniaud build are you running?

It is from UniaudUpdate1.09.06-2.02.01.zip which is the latest that I know about. Earlier versions won't load at boot time (they pop up something about no hardware found, as I recall).

Quote
and which device?

It is in a Lenovo ThinkPad L530. From PCI.EXE:
Code: [Select]
Bus 0 (PCI Express), Device Number 27, Device Function 0
 Vendor 8086h Intel Corporation
 Device 1E20h 7 Series/C210 Series Chipset Family High Definition Audio Controller
 Command 0006h (Memory Access, BusMaster)
 Status 0010h (Has Capabilities List, Fast Timing)
 Revision 04h, Header Type 00h, Bus Latency Timer 00h
 Self test 00h (Self test not supported)
 Cache line size 64 Bytes (16 DWords)
 PCI Class Multimedia, type Unknown!
 Subsystem ID 21F717AAh Unknown
 Subsystem Vendor 17AAh Lenovo
 Address 0 is a Memory Address (64-bit) : F2610000h..F2613FFFh
 System IRQ 22, INT# A
 New Capabilities List Present:
   Power Management Capability, Version 1.1
     Does not support low power State D1 or D2
     Supports PME# signalling from mode(s) D0, D3hot, D3cold
     PME# signalling is currently disabled
     3.3v AUX Current required : 55 mA
     Current Power State : D0 (Device operational, no power saving)
   Message Signalled Interrupt Capability
     MSI is disabled
     MSI function can generate 64-bit addresses
   PCI Express Capability, Version 1
     Device/Port Type :
       Root Complex Integrated Endpoint Device
       Unsupported Request Severity is Non-Fatal
     Device Status :
       AUX Power Detected
     Link Capabilities :
       Maximum Link speed : Unknown (00h)!!
       Maximum Link Width : xReserved
       Link Port Number   : 0
     Link Control :
       Asynchronous Clocking in Use
     Link Status :
       Current Link speed : Unknown (00)!!
       Current Link Width : x0
but Win7 Pro 64 claims there is also a Realtek High Definition Audio device, that I don't see with PCI.EXE. I think one of them might be for the HDMI interface.

There are some fixes in ALSA 1.0.25 for a "Lenovo Y530" - I wonder if these would help?
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 08, 2014, 04:15:19 pm
Doug, your Lenovo Thinkpad seems to have one of the following graphic adapters: Intel GMA HD / Intel HD Graphics 3000 / Intel HD Graphics 4000. Each of them seem to be unsupported by SNAP, you are likely to use Panorama driver with it.

Please, report what Panorama driver version are you using, how does it work with the original kernel, and with OS/4 kernel.
Turning ACPI.PSD off and booting with OS/4 may be a good test for the new screen03.sys driver -- how then Panorama will work?
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Sigurd Fastenrath on February 08, 2014, 04:40:26 pm
There are some fixes in ALSA 1.0.25 for a "Lenovo Y530" - I wonder if these would help?

I would be happy as well with the X230T I have.   ::)
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 08, 2014, 06:31:11 pm
Quote
There are some fixes in ALSA 1.0.25 for a "Lenovo Y530" - I wonder if these would help?

I wouldn't be too surprised if they did. It seems that the 530 (perhaps the 520, 540, and 230) series started using some new hardware (keyboard, touchpad, stickmouse, sound). Some of them work okay, others only partly.

Quote
Please, report what Panorama driver version are you using, how does it work with the original kernel, and with OS/4 kernel.

I am currently using Panorama-1.06, and it works great with either kernel. It is AUDIO that doesn't work very well (apparently, no fault of OS/4). I tried SNAP, and it also works, in VESA mode, with the IBM kernel (I haven't tried it with OS/4). The video is described, by PCI.EXE, as:
Code: [Select]
Vendor 8086h Intel Corporation
 Device 0166h 3rd Gen Core processor Graphics Controller

Quote
Turning ACPI.PSD off and booting with OS/4 may be a good test for the new screen03.sys driver

I am using acpi-3.22.03 (no parameters), with no apparent problems. As far as I can tell, screen03.sys loads, and I have seen no video problems, so far. Timer0.sys, on the other hand, does fail, but that doesn't seem to hurt anything. I did turn off ACPI, and the only things that changed were that it uses 1 CPU, and it won't power off at shutdown (both expected).

I just tried os4apic. It works, as expected, using /APIC (two CPUs, and high IRQs), and without /APIC (two CPUs, and low IRQs).

There are also a couple of DOSCALL1 files in the package. I haven't tried to use them. What are they for?
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 08, 2014, 06:39:11 pm
Quote
and which device?

I should add, that it says "Mixer Intel ID 2806" while booting.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 08, 2014, 07:57:03 pm
Doug, as I recall, 16-bit timer0.sys fail is okay because its function is now fully substituted by the clock03b.sys system driver written by Phoenix.

I'm sorry I can't help you with the sound, maybe you may try messing with unimix controls more ;)

Thank you for your positive feedback, it's really appreciated.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 08, 2014, 08:58:42 pm
I just tried OS/4 on my Lenovo ThinkPad T510. This thing is a little different than the L530:

It does not have a real COM port (it does have a software modem), but it hangs after the first "Loading" line, if I don't enable the debug port.

Hmmm. eCS 2.2 beta 2, on the T510, does NOT have the new UNIAUD.DLL file. I guess I need to discover where that came from.  I remember that the UNIAUD driver was automatically detected on the T510 (in eCS 2.1, and eCS 2.2 beta 2), but I had to select it on the L530 (no sound chip was detected, in both versions of eCS). In all cases, I manually updated to UniaudUpdate1.09.06-2.02.01, after install, but that does not change UNIAUD.DLL.

Then, I tried loading OS/4 with the QSINIT loader. That works, and I can use the QSINIT RAMDISK. It works with the L530 too.

Quote
as I recall, 16-bit timer0.sys fail is okay because its function is now fully substituted by the clock03b.sys system driver

I was thinking that that was the case. I didn't see any indication that it should be REMed. I REMed it, and everything seems to be okay, so far (a few minutes).

Quote
I'm sorry I can't help you with the sound, maybe you may try messing with unimix controls more

I think that UNIMIX is missing a few controls that I need. Anyway, that all works the same as with the IBM kernel, so it is not an OS/4 problem.

Quote
Thank you for your positive feedback, it's really appreciated.

It would be more positive, if the documentation was a little better. Somebody who hasn't played with this stuff would be in real trouble, I think.

The OS/4 kernel, using the QSINIT loader, or the OS/4 loader,  seems to be working well, and it does enable all of my memory, which is a great breakthrough. I can use it with ACPI, with no parameters, which enables both processors, and uses high IRQs. I need to try hyperthreading.

Now, I need to get back to real life, for a while.   ;D
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 08, 2014, 10:32:24 pm
I just tried OS/4 on my Lenovo ThinkPad T510. This thing is a little different than the L530:

It does not have a real COM port (it does have a software modem), but it hangs after the first "Loading" line, if I don't enable the debug port.
Hm? Can you, please, describe more precisely? I think I didn't understand that much.
So, it hangs just after you select the kernel in the loader, and it does work if you comment out the dbport statement in os2ldr.ini, doesn't it?
What's with the software modem? Is it, urgh, connected to the COM port?


Quote
as I recall, 16-bit timer0.sys fail is okay because its function is now fully substituted by the clock03b.sys system driver

I was thinking that that was the case. I didn't see any indication that it should be REMed. I REMed it, and everything seems to be okay, so far (a few minutes).
There is no indication it should be REMed just because you don't actually need it to be REMed -- that's done for compatibility and prevents you from the necessity to have two different CONFIG.SYS files.


Quote
Thank you for your positive feedback, it's really appreciated.

It would be more positive, if the documentation was a little better. Somebody who hasn't played with this stuff would be in real trouble, I think.
That's the thing, unlike kernel developing, I think, I can do myself. At least documentation for the end-user, not a developer. I'll consider making somewhat a FAQ.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 08, 2014, 10:48:22 pm
All, there are actually two options of getting a kernel log, excluding using real COM port, which are very useful if you don't have one. The second option is experimental and allows obtaining the log even if it is impossible to load the system properly. Unfortunately, you are not able to use this now, because it is highly experimental and is not yet released.

The first one is old enough to be forgotten by everyone, but seems to work :). Just do
copy oemhlp$ log.txt
and read it
e log.txt
Voilà :)

UPD:
I've just been corrected.
You should read oemhlp$ if you do not have ACPI and
you should read ___hlp$ if you do have ACPI.PSD, and,
you should read oemhl_$ if you have ACPI4.SYS (well, you don't).
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 09, 2014, 04:22:12 am
Quote
Quote from: Doug Bissett on February 08, 2014, 08:58:42 pm

    I just tried OS/4 on my Lenovo ThinkPad T510. This thing is a little different than the L530:

    It does not have a real COM port (it does have a software modem), but it hangs after the first "Loading" line, if I don't enable the debug port.

Hm? Can you, please, describe more precisely? I think I didn't understand that much.
So, it hangs just after you select the kernel in the loader, and it does work if you comment out the dbport statement in os2ldr.ini, doesn't it?
What's with the software modem? Is it, urgh, connected to the COM port?

It seemed a little strange to me too. The section of the OS4 OS2LDR.INI file in question is:
Code: [Select]
; Debug port
; com port address
; no debug output if statment is omited (but log still accessible
; through copy from oemhlp$ - see below)
dbport=0x3f8
;dbport=0xEC00
If I leave it as it is, I don't have a problem. If I put a semi-colon in front of "dbport=0x3f8", the system simply stops at the first "Loading" line. The machine is not frozen, a Ctrl-Alt-Del causes a reboot. One odd thing is that if I use the QSINIT loader, without even having that line in the INI file, it does not hang. I should note, that I amusing os4krnlr when it hangs.

I think I know what is happening though. The T510 has a feature called  "Intel® Active Management Technology" (AMT). Part of that is a device that does "Serial over LAN" (SOL). From what I found out, the device is a serial port (as seen by the computer), but the communication path is redirected over the LAN interface as a TELNET terminal. Apparently, the OS4 loader is detecting that as a serial port, and is getting upset when it isn't told about it. There is some setup in the BIOS for SOL, but I am not sure what it actually does. Someday, I will play with it.

Quote
What's with the software modem? Is it, urgh, connected to the COM port?

No, it isn't. It is what we commonly call a "Winmodem". It does not use a normal serial port.

Quote
prevents you from the necessity to have two different CONFIG.SYS files.

Actually, the feature to be able to define a different CONFIG.SYS file is an interesting concept, and it works very well. I made one called CONFIG.os4 to use when testing OS/4. I may build a few more, for various reasons.

Quote
I'll consider making somewhat a FAQ.

After I learn more about all of this, I may contribute to that, but I am not ready yet.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: R.M. Klippstein on February 09, 2014, 05:38:02 pm
Hi Boris, If you could find the time, Some documentacion would sure make life a lot easier for a lot of us and would be REALLY appreciated!

Thanks,  klipp
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: OS4User on February 09, 2014, 06:03:49 pm
Doug, as I recall, 16-bit timer0.sys fail is okay because its function is now fully substituted by the clock03b.sys system driver written by Phoenix.

clock03b.sys contains two drivers:  CLOCK$ and TIMER0$  (having more than one driver per module is allowed in OS/2)

you may remove timer0.sys from your config.sys  or you may leave it as it is   -   a difference will be an appearance  of the error message only
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 09, 2014, 07:57:14 pm
Quote
Some documentacion would sure make life a lot easier for a lot of us

Actually, the documentation is mostly there. The problem is that there is little, or no explanation of what the documentation is trying to say. It is somewhat technical, and seems to assume that the user knows what a lot of that stuff is all about. Some extra samples of configuration, and an explanation of what they do, would probably help.

Quote
you may remove timer0.sys from your config.sys  or you may leave it as it is   -   a difference will be an appearance  of the error message only

Unexplained error messages are never good. A small note in the documentation (or FAQ), to make it clear that the error is expected, and how to eliminate it, would be a good thing.

I realize that the OS/4 project is still in the early development phase, but it would appear that the documentation needs to be expanded to make it possible for the average user to test it for you. I will be going through the documentation, after I learn a bit more, and I will suggest some changes.  If Boris creates a FAQ, I will contribute to that too. I may even create a WarpIn installer, if I find the time, but first, I have to learn more.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 10, 2014, 06:21:56 pm
When I boot the OS/4 kernel, I have noticed a line, that disappears very quickly. I finally saw part of it, but I don't know the whole thing. It is something to do with "VIRTUALADDRESSLIMIT". Any ideas about what that is?
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 11, 2014, 04:44:02 pm
When I boot the OS/4 kernel, I have noticed a line, that disappears very quickly. I finally saw part of it, but I don't know the whole thing. It is something to do with "VIRTUALADDRESSLIMIT". Any ideas about what that is?
Somewhere in SVN3xxx the VIRTUALADDRESSLIMIT tuning feature was broken. Now the VAL is fixed and set to 2048.
There's nothing bad in the error message; you can REM or remove the entire VAL statement in your CONFIG.SYS file -- it will always remain fixed to 2 GiBs.
Unfortunately I'm not aware of any plans to fix this issue and make the VAL changeable again.

Regards.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 11, 2014, 08:54:38 pm
Quote
There's nothing bad in the error message; you can REM or remove the entire VAL statement in your CONFIG.SYS file

Okay. This is another "expected" error that needs to be documented. Whether 2048 is a good default, or not, remains to be seen. I know that it has generally been accepted that 1536 seems to be best, for most users, but other things may have changed that.

FWIW, I am finding that using the QSINIT loader, with the OS/4 kernel, is working great. I am able to use the QSINIT RAMDISK (above 4 GB), and I am not seeing any hangs while loading.

I put OS/4 onto my main machine (Asus M3A78-EM, with quad core Phenom processor, and 4 GB of memory). I was having troubles with a hang at the first "Loading" line, but I didn't have time to mess with it, so I just replaced the OS/4 loader with the QSINIT loader, and all is working well. This one has a single COM port, at 0x3f8, which has an IBM Home Controller (X-10) attached. It seems that the OS/4 loader is not happy with that because it hung whether I had the line enabled, or not (of course, it may have been something else that was causing the problem).
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 11, 2014, 10:14:49 pm
I put OS/4 onto my main machine (Asus M3A78-EM, with quad core Phenom processor, and 4 GB of memory). I was having troubles with a hang at the first "Loading" line
So, if you want to, and ready for testing...

a single COM port, at 0x3f8, which has an IBM Home Controller (X-10) attached.
What's that device, Home Controller? Can you connect another PC via COM port instead of that device?

It seems that the OS/4 loader is not happy with that because it hung whether I had the line enabled, or not (of course, it may have been something else that was causing the problem).
Could you, please, connect the test PC to another one via COM port, and get the log? The settings are 115200, 8n1, hardware flow control enabled or not depending on the 'fullcable' statement in the os2ldr.ini file.
The loader logs itself to the COM port just as the kernel does, so that's the way to debug the loader.

DTerm (http://ftp://dbanet.org/dbanet/os2/util/dterm_b10.zip) is a very handy terminal program for Operating System/2. Features logging the port to a file.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Dave Yeo on February 12, 2014, 05:51:33 am
Quote
There's nothing bad in the error message; you can REM or remove the entire VAL statement in your CONFIG.SYS file

Okay. This is another "expected" error that needs to be documented. Whether 2048 is a good default, or not, remains to be seen. I know that it has generally been accepted that 1536 seems to be best, for most users, but other things may have changed that.


2048 will screw up with video cards with lots of memory and probably other hardware setups.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: OS4User on February 12, 2014, 04:34:59 pm
2048 will screw up with video cards with lots of memory and probably other hardware setups.

VAL does not have any connection to physical memory

panorama maps 16M only

SNAP could be tuned to map as much as necessary    -   for example "gaoption vidmem 8"  will restrict  memory usage to 8M (I use this setup to save _virtual_ memory on my PC)
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 12, 2014, 05:41:08 pm
Quote
So, if you want to, and ready for testing...

I want to, but I am not ready. I got cataract surgery scheduled for Thursday PM, so I won't be doing a lot until I get over that.

Quote
What's that device, Home Controller? Can you connect another PC via COM port instead of that device?

It allows me to computer control lights, and other devices. The one that is attached is used to turn on/off my USB hard disk, under program control. I can connect a cable to another PC (it will have to be my antique IBM ThinkPad A22e, which I have used before). The "problem" is that it is very difficult to access the cables, and I am not going to try it with one eye bandaged up.   :)

Quote
Could you, please, connect the test PC to another one via COM port, and get the log? The settings are 115200, 8n1, hardware flow control enabled or not depending on the 'fullcable' statement in the os2ldr.ini file.
The loader logs itself to the COM port just as the kernel does, so that's the way to debug the loader.

I will give it a try, sometime next week.

Quote
DTerm is a very handy terminal program for Operating System/2. Features logging the port to a file.

I will use ZOC. It has worked with other things, and I have it installed on the A22e.

Quote
2048 will screw up with video cards with lots of memory and probably other hardware setups.

This should not be a problem. I use SNAP, in VESA mode. It claims to use 16 meg (1920x1680x32). Other things may cause trouble, but not so far (not quite 2 days). I think the video adapter will actually use 256 meg, if the driver would use it. The biggest user of shared memory, that I have seen, is CLAMD.EXE. I had to quit using that.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 14, 2014, 05:59:31 pm
O-ookay, I think I've just started to work on the FAQ and somewhat installation instructions... hope I will produce useful output this weekend.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 14, 2014, 07:07:05 pm
Quote
I got cataract surgery scheduled for Thursday PM, so I won't be doing a lot until I get over that.

This got canceled. Apparently there is something else wrong, that needs to be fixed first, so I am waiting for a new appointment.

I will see what I can find time for, later...
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 14, 2014, 09:27:22 pm
Quote
I got cataract surgery scheduled for Thursday PM, so I won't be doing a lot until I get over that.

This got canceled. Apparently there is something else wrong, that needs to be fixed first, so I am waiting for a new appointment.

I will see what I can find time for, later...

Get well and soon!  :-\
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: Doug Bissett on February 15, 2014, 08:56:49 pm
Quote
Could you, please, connect the test PC to another one via COM port, and get the log? The settings are 115200, 8n1, hardware flow control enabled or not depending on the 'fullcable' statement in the os2ldr.ini file.
The loader logs itself to the COM port just as the kernel does, so that's the way to debug the loader.

Well, I got it connected, and I got a log, which simply shows that it all works okay.

I did some more testing. The hang occurs when I try to boot with the Home controller attached, but only after I use it, and only sometimes. Since it doesn't fail when I connect the Null modem cable, or leave the serial port disconnected, I am not able to trap the problem.

It seems that a timeout needs to be implemented, and the COM port needs to be ignored if it doesn't connect properly.

Quote
Get well and soon!

Not much chance of that, with our wonderful, government run, over priced, medical system. Next stop is on April 1. By then, the problem will probably be gone, or I will be blind in one eye.
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 18, 2014, 07:20:07 pm
I'm announcing that I've finally made the page about OS/4, that may be considered fairly useful, but it does not cover the complicated cases, as the troubleshooting section is not written. Also the FAQs section is not complete (I think it may be three times longer).

Here it is.

http://www.os2world.com/wiki/index.php/OS/4
Title: Re: New OS/4 kernel is available :: SVN4166 :: screen03.sys release
Post by: dbanet on February 20, 2014, 07:39:05 pm
Hooray!

Phoenix finally made a move towards open source software! @Martini

There is the FULL SOURCE CODE OF THE QSINIT KERNEL BOOTLOADER AVAILABLE at -->
--> ftp://dixieos2.tk/public/QS/QS_SDK.ZIP
Title: Re: The source code of QSINIT has been made AVAILABLE :: New OS/4 kernel :: SVN4168
Post by: Martin Iturbide on February 20, 2014, 10:23:18 pm
Thank you very much for releasing the source code to the public.

Even that the license is "Source code available for non-commercial use only" and does not qualify as open source, I feel that is a great first step for the collaborative growing of this loader.

Thanks !!
Title: Re: The source code of QSINIT has been made AVAILABLE :: New OS/4 kernel :: SVN4168
Post by: dbanet on February 23, 2014, 07:03:25 pm
Doug, and everyone else, help in writing (some sections are not finished) and editing (my English is not good enough) the wiki page about OS/4 is needed.
Title: Re: The source code of QSINIT has been made AVAILABLE :: New OS/4 kernel :: SVN4168
Post by: Doug Bissett on February 23, 2014, 11:51:43 pm
I haven't updated to the SVN4168 version, yet, but I seem to have found a problem that makes it undesirable to continue using the OS4 kernel. I use PROCDUMP to get process dumps when something crashes (specifically PMMail, but I trap all crashes). The dump seems to work, but the PM Dump Facility won't read the resulting dumps, making them useless.

Doug, and everyone else, help in writing (some sections are not finished) and editing (my English is not good enough) the wiki page about OS/4 is needed.

I have had time to take a quick look. What is there seems to be okay, but it does need work. I will poke away at it when I find time.  Thanks...
Title: Re: The source code of QSINIT has been made AVAILABLE :: New OS/4 kernel :: SVN4168
Post by: dbanet on February 24, 2014, 12:03:12 am
Doug, I will report this, but due to the situation in Ukraine, I'm afraid it may not get fixed very soon... please, be patient...
Title: Re: New OS/4 kernel :: SVN4169
Post by: arr531 on March 09, 2014, 08:07:08 pm
I just checked over at their server and the os/4 kernel is now at 4170 dated March 9 2014.
Title: Re: New OS/4 kernel :: SVN4169
Post by: dbanet on March 10, 2014, 10:55:45 am
I just checked over at their server and the os/4 kernel is now at 4170 dated March 9 2014.
And now 4171.
Title: Re: New OS/4 kernel :: SVN4171
Post by: arr531 on March 10, 2014, 03:21:01 pm
4171? Wow that was fast.  :)
Title: Re: New OS/4 kernel :: SVN4171
Post by: dbanet on March 10, 2014, 11:02:08 pm
4171? Wow that was fast.  :)

I mean, I know about every release, I'm just sometimes too lazy^Wbusy to update the first post.
Title: Re: New OS/4 kernel :: SVN4172
Post by: dbanet on March 11, 2014, 11:24:41 pm
4172.
Up!
Title: Re: New OS/4 kernel :: SVN4172
Post by: Dariusz Piatkowski on March 19, 2014, 09:59:05 pm
Boris,
I had previously attempted to get 4168 running, no luck. Now tried 4172, unfortunately no luck either, even more, I am seeing the same issue as with 4168.

Namely, upon selecting the configuration to book (os2ldr.ini) the line stating which configuration is booting is displayed and then....NUTHING...the screen sits there, no HARD lock, num-lock, caps-lock still works...but nothing actually happens on the screen.

Here is my os2ldr.ini:
=== START ===
[kernel]
os2ldr.104   =  IBM OS2LDR 14.104a_SMP ,Restart
os2ldr.105   =  IBM OS2LDR 14.105a_SMP ,Restart
os4krnlr     =  OS4 Current - RETAIL,PRELOAD,NOLOGO,CFGEXT=os4
os4krnl      =  OS4 Current - DEBUG,PRELOAD,NOLOGO,LOADSYM,CFGEXT=os4
os4krnl      =  OS4 Current - DEBUG - show driver names,ALTF2,NOLOGO,CFGEXT=os4
=== END ===

All the other files are present, doscall1.dll has been replaced with the one from the package, clock & screen drivers are present.

Any ideas what to try next? I have no idea how to even get some debug info up on the screen.

This is on a machine which successfully runs a 5-core Phenom II X6 CPU (MSI 880G-E45 motherboard) using the "OS2APIC.PSD /P=5 /APIC" driver.

Thanks!
Title: Re: New OS/4 kernel :: SVN4172
Post by: OS4User on March 20, 2014, 09:11:32 pm
Dariusz,

please  show com port log   -  it may help to understand where is hang
Title: Re: New OS/4 kernel :: SVN4172
Post by: dbanet on March 21, 2014, 01:03:31 pm
Can you please join IRC channel #netlabs on freenode, and PM me, dbanet?
I see you're having (http://www.os2world.com/forum/index.php/topic,301.msg3040.html#msg3040) issues (http://www.os2world.com/forum/index.php/topic,324.msg3039.html#msg3039) running OS/2 on your machine, but for me it's hard to understand your English, and also you've reported very small amount of information that is needed to debug your configuration -- it is almost impossible to help you while discussing offline (on a forum), or a lot of time more needed.

You won't get a live reaction of OS/4 kernel developers like that, but I'm here to support OS/4 kernel users, to promote this project, and to avoid wastage of kernel developers' time by providing them qualitative, useful, detailed bug reports from users.

Sorry for a huge delay -- didn't have time to open my RSS reader.
Title: Re: New OS/4 kernel :: SVN4172
Post by: Dariusz Piatkowski on March 22, 2014, 02:10:01 pm
Dariusz,

please  show com port log   -  it may help to understand where is hang

How do I do that? I see the DEBUG setup instructions, but nothing (as best as I can tell) about troubleshooting through the COM port.

I can only assume this requires me to hook up another OS/2 PC over the COM port? No problem there, I still have my old machine...but could use some detailed instructions to walk me through this.
Title: Re: New OS/4 kernel :: SVN4172
Post by: Dariusz Piatkowski on March 22, 2014, 02:17:41 pm
Can you please join IRC channel #netlabs on freenode, and PM me, dbanet?

Yes, will do...thank you, that I exactly what I was looking for. I understand that there may be a lot of debugging to do, but regardless of how much it is would it not be better to do so in this forum type environment? The benefit is that anyone else who may encounter a problem has an immediate reference to previous debugging activities....food for thought as they say.

I see you're having (http://www.os2world.com/forum/index.php/topic,301.msg3040.html#msg3040) issues (http://www.os2world.com/forum/index.php/topic,324.msg3039.html#msg3039) running OS/2 on your machine

The trouble I have is only powering up the 6th core of the CPU...I am running fine with the 5 cores...the forum post you showed was placed by me there because it appears the OS4 kernel hang I was seeing is very similar to what Lars was seeing. This is why I attached the output of the mptable...that is a whole bunch of info as you know that provides detailed snapshot of the SMP configuration on the PC. I'm trying to walk through it on my own to understand my 6th core hang...I am attaching the same output to this post, please take a look at it.
Title: Re: New OS/4 kernel :: SVN4172
Post by: dbanet on March 23, 2014, 07:21:22 pm
Hi Darusz,

There's already a section regarding getting the COM port log on the OS/4 kernel wiki page
http://www.os2world.com/wiki/index.php/OS/4#Getting_the_log
There's some information about the kernel, and a full installation instruction. If you haven't read it before, you may try doing it now -- maybe you will get some hints from there.

I'm now repeating myself from the first post, but the article is still incomplete. It needs some editing by a native English speaker, some sections are still not written, and some of already written ones are incomplete.

I will post an instruction of how to get the COM port log into the #Getting_the_log section on the wiki page later and then inform you.
Title: Re: New OS/4 kernel :: SVN4172
Post by: dbanet on March 23, 2014, 07:30:13 pm
Regarding the forum-is-the-best-place thing, you're wrong.

If we find a bug (which will take forever here), it will be fixed and it will be shown in the changelog, and everyone will be happy with this.

If we don't find a bug, we will waste a lot of space here in the thread.

If we find some tip or trick, that will be useful for everyone, it will eventually be posted by me (or you, if you want this so much) on the wiki page.
Title: Re: New OS/4 kernel :: SVN4172
Post by: Dariusz Piatkowski on March 23, 2014, 08:30:08 pm
...
I will post an instruction of how to get the COM port log into the #Getting_the_log section on the wiki page later and then inform you.

Yeah, the 'Getting_the_log' section is what I previously looked at...as well as the whole article that's posted there and the various txt/readmes supplied in the distro...if it was there, believe me, I would not be wasting everyone's time here..lol.

Alright...I will watch that link, if you want me to review the English version, no problem, send it over, PM, etc, etc...I'm happy to do that.

Regarding the 2nd issue raised you responded to: well, let's just agree to disagree. From my point of view, using your approach you are apparently equally 'wrong' then...but I hate to just state such things as if they were a fact, if you get my point. Let me explain further. I have some 15+ yrs experience in the IT industry, a good chunk of it in application development. A debugging process is typically repeatable once application reaches a certain level of maturity. Until that is achieved it is often very helpful to have as large of a team taking part in the process as possible in order to weed out all the various bugs/problems/design shortcomings and so on. In our case, if we/you treat each one of the reported issues as if these were merely 'once in a lifetime' events, non-repeatable occurencies, you are very likely to miss a whole gamut of configurations/hardware setups (given the kernel subject matter here) that other potential users of your software may in fact be deploying today. Meanwhile, by sharing this knowledge with everyone (separate thread can be started, no problem there) you are actually not only improving your software but at the same time educating the end-users, and that is priceless in a small community like our OS2 group is.

Anyways...happy to help as the OS4 approach holds promise. But if I'm going to spend my time doing this it is NOT merely for my benefit, but for the benefit of the community at large. Believe me, a 5-core CPU configuration with each core running at 4GHz is pretty darn sweet already...no complaints there...OS4 is more of a technological curiousity to me at this point in time.
Title: Re: New OS/4 kernel :: SVN4172
Post by: dbanet on March 23, 2014, 09:25:13 pm
I have some 15+ yrs experience in the IT industry
As you wish.

Connect the terminal, install debug kernel, add dbport=your com port address in hex like 0x3f8 in config section in \os2ldr.ini, terminal conf: 8n1 115200b no flow cntrl, post the log here.

I don't need to PM you the articles, because every1 can edit the wiki.
Title: Re: New OS/4 kernel :: SVN4173
Post by: dbanet on March 26, 2014, 02:40:51 pm
Up!
4173!
Title: Re: New OS/4 kernel :: SVN4173
Post by: dbanet on April 03, 2014, 08:12:36 pm
Dariusz and everyone else,

I've just wrote the "Getting the log (http://www.os2world.com/wiki/index.php/Phoenix_OS/4#Getting_the_log)" section of the OS/4 page on the OS2World Wiki.
You may now use it to learn how to get the kernel log over the COM port.
Other possibilities are not yet described there.

Also I've finally managed to get the trap on unloading DLLs marked as loading in high memory (I've used the latest highmem tool from Yuri based on January June's work) with 14.105_SMP.

I dunno why, but I'm unable to load 14.106_SMP on this system (getting hangs on OS2LVM.DMD), but, because the Phoenix kernel loads fine and works just fine here, I'll try to trap with it and report the bug.

So I hope a new version of the Phoenix kernel will appear soon with this bug fixed, allowing to drastically reduce low shared memory usage.

With marked DLLs (and dllbasing=off) I'm getting the following on a loaded system with lots of running applications:
Code: [Select]
Current free virtual address space in KiB (private / shared):
  316608 / 178880 below 512MB line, 1376256 / 662912 above 512MB line

Thank Yuri!
Title: Re: New OS/4 kernel :: SVN4177
Post by: dbanet on April 19, 2014, 07:35:21 pm
Up!
4177!
Title: Re: New OS/4 kernel :: SVN4180
Post by: dbanet on April 28, 2014, 04:11:01 pm
Up!
4180!

This release introduces a new SNAP helper driver (SDDHELP.SYS) built from sources, where a very dirty place in the code has been rewritten with use of modified OS/4 kernel API.
With this driver SNAP now sets write-combine caching of LFB on SMP machines correctly, which causes a significant improvement of video performance on multi-core machines. This is achieved by setting WC using PAT, that always sets up properly on SMP machines, unlike MTRR.

For all these to run, you need to use OS/4 kernel; it won't work with the original kernel.
There are no additional requirements (such as ACPI4.SYS, OS4APIC.PSD or Mensys' ACPI.PSD).

Please note, the known SMP bugs of SNAP (like moving VLC while playing video, etc) are not fixed in this release yet.

So, with this driver you should notice a conspicuous performance improvement while running SNAP with a supported graphics card.
If you have an unsupported card, you should better use Panorama; also if you have a UNI (single-core) machine, you don't need this -- it already works okay.
Testers are welcome.



Installation instructions:



Thank you!
Title: Re: New OS/4 kernel :: SVN4180
Post by: Dave Yeo on April 29, 2014, 04:05:50 am
Perhaps the OS/4 developers would be interested in this license, http://www.floodgap.com/software/ffsl/license.html (http://www.floodgap.com/software/ffsl/license.html).
Title: Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
Post by: dbanet on May 03, 2014, 10:53:56 pm
Up!
4183!
Title: Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
Post by: Andy Willis on May 16, 2014, 06:59:20 pm
Question about:
Q:    What is the purpose of the CLOCK03B.SYS driver?
   A:    The CLOCK03B.SYS was rewritten in 32-bit and now contains two drivers: CLOCK$ and TIMER0$ (having more than one driver per module is allowed in OS/2). That was made for better performance and code cleanup.

Does this new driver either recognize the clockscale=4 option (4 having been the max with the clock01.sys)? 
Title: Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
Post by: dbanet on May 16, 2014, 08:39:11 pm
Does this new driver either recognize the clockscale=4 option (4 having been the max with the clock01.sys)?

Yes, it does.
Title: Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
Post by: Dave Yeo on May 18, 2014, 05:27:02 am
Finally got around to testing the newest OS/4 kernel on my Warp V4+latest free fixes install. It hangs when it should go graphical. The new Doscall1.dll did seem to make the system more stable though, it's a somewhat crufty install from '96 or so and crashes if I enable more then one core but runs fine with one core and doesn't have the FPU problems that newer versions of OS/2 have
Title: Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
Post by: OS4User on May 18, 2014, 06:44:41 am
Finally got around to testing the newest OS/4 kernel on my Warp V4+latest free fixes install. It hangs when it should go graphical. The new Doscall1.dll did seem to make the system more stable though, it's a somewhat crufty install from '96 or so and crashes if I enable more then one core but runs fine with one core and doesn't have the FPU problems that newer versions of OS/2 have

os/4 is SMP kernel  and  cannot work with UNI doscall1 from Warp V4
you should use dc1 from os/4 package or from Warp 4.5 SMP

interesting to see comport log with that crash
Title: Re: New OS/4 kernel :: SVN4188 :: New SNAP helper driver (SDDHELP.SYS)
Post by: dbanet on May 24, 2014, 01:33:07 pm
Up! 4188!
Title: Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
Post by: Dave Yeo on May 24, 2014, 06:21:31 pm
Finally got around to testing the newest OS/4 kernel on my Warp V4+latest free fixes install. It hangs when it should go graphical. The new Doscall1.dll did seem to make the system more stable though, it's a somewhat crufty install from '96 or so and crashes if I enable more then one core but runs fine with one core and doesn't have the FPU problems that newer versions of OS/2 have

os/4 is SMP kernel  and  cannot work with UNI doscall1 from Warp V4
you should use dc1 from os/4 package or from Warp 4.5 SMP

interesting to see comport log with that crash

Missed this post until now  :)

I have the SMP kernel and SMP doscall1 as I've tried to enable both cores previously. No comport on this box. Wish there was if only for the modem.
Title: Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
Post by: OS4User on May 24, 2014, 06:49:55 pm
Finally got around to testing the newest OS/4 kernel on my Warp V4+latest free fixes install. It hangs when it should go graphical. The new Doscall1.dll did seem to make the system more stable though, it's a somewhat crufty install from '96 or so and crashes if I enable more then one core but runs fine with one core and doesn't have the FPU problems that newer versions of OS/2 have

os/4 is SMP kernel  and  cannot work with UNI doscall1 from Warp V4
you should use dc1 from os/4 package or from Warp 4.5 SMP

interesting to see comport log with that crash

Missed this post until now  :)

I have the SMP kernel and SMP doscall1 as I've tried to enable both cores previously. No comport on this box. Wish there was if only for the modem.

it is hard  to say what is wrong in your case  -  try some other hardware if possible
and do not forget use proper com.sys and other drivers  for SMP
Title: Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
Post by: OS4User on June 04, 2014, 05:52:01 pm
4195
Title: Re: New OS/4 kernel :: SVN4198 :: New SNAP helper driver (SDDHELP.SYS)
Post by: dbanet on June 06, 2014, 01:23:30 pm
Up! 4198!
Title: Re: New OS/4 kernel :: SVN4200
Post by: OS4User on June 07, 2014, 05:07:33 pm
4200

to set VIRTUALADDRESSLIMIT   use  VALIMIT  statement  in os2ldr.ini
for example  VALIMIT = 3072
Title: Re: New OS/4 kernel :: SVN4208
Post by: dbanet on June 25, 2014, 02:54:09 am
Up! 4202, 4203, 4204, 4205, 4206, 4207 and 4208!
Title: New OS/4 kernel :: SVN4221
Post by: OS4User on August 03, 2014, 09:28:38 pm
http://gus.biysk.ru/os4/os2krnlSVN4221_unoff.zip (http://gus.biysk.ru/os4/os2krnlSVN4221_unoff.zip)

lanserver/requester (NETWKSTA.200)  test is  needed
Title: Re: New OS/4 kernel :: SVN4221
Post by: Sergey Posokhov on August 12, 2014, 01:43:31 pm
I've got a bug on ThinkPad 510.

Something hangs when PM starts on, so I can only see a mouse pointer.
Keyboard monitors (such as KEYBMON) works, NumLock and PC speaker works too.
WPS starts only in 10% of times, and then, OS/4 works fine.
Screen driver is faster that Panorama (seems that it has a bitmap cache).

There are OEMHLP$ and ___HLP$ log files.
Title: Re: New OS/4 kernel :: SVN4221
Post by: OS4User on August 19, 2014, 08:52:53 am
Something hangs when PM starts on, so I can only see a mouse pointer.
Keyboard monitors (such as KEYBMON) works, NumLock and PC speaker works too.
WPS starts only in 10% of times, and then, OS/4 works fine.

I also noticed such behavior but rarely.
It also happened on IBM kernels.
Until now I don't have an explanation for it.

Screen driver is faster that Panorama (seems that it has a bitmap cache).

Screen driver can't be faster than Panorama as they work on different levels. Screen driver is just a set of helpers that are used also by Panorama. Screen03 differs from Screen01 by mapping LFB using new kernel function and which sets a type of caching WC through PAT.

Panorama sets WC through MTRR which doesn't work always correctly. Thus you may see that with Screen03 Panorama works faster.

Of course Screen doesn't have anything in common with caching bitmap.
Title: Re: New OS/4 kernel :: SVN4222
Post by: Silvan Scherrer on August 19, 2014, 01:03:59 pm
* The pirates don't have access to Panorama VESA source code
I really wonder if such comments are either necessary or constructive. I personally have my doubts about both.

regards
Silvan
Title: Re: New OS/4 kernel :: SVN4222
Post by: Doug Bissett on August 20, 2014, 12:33:50 am
I've got a bug on ThinkPad 510.

Something hangs when PM starts on, so I can only see a mouse pointer.
Keyboard monitors (such as KEYBMON) works, NumLock and PC speaker works too.
WPS starts only in 10% of times, and then, OS/4 works fine.

That is an OLD OS/2 bug. It has been around, for years (long before OS4 was started), known as a "startup conflict". I rarely see it on my T510 after adjusting the boot sequence (use the LCSS package from HOBBES, with the documented update - be sure to READ the instructions). It also helps to put a file  called AltF2on.$$$ into the root of the boot drive (The contents don't matter, but it displays the drivers as they load, which slows down booting a little). I also use REXX Autostart so that all of the contents of the Startup folder don't try to start at the same time. From what I can tell, OS4 boots a little faster than the IBM kernel, which changes the timing when things load. If you get a bad combination, you will see exactly what you are describing.
Title: Re: New OS/4 kernel :: SVN4222
Post by: Lars on August 21, 2014, 11:25:29 am
The latest  versions of Panorama also support PAT where MTRRs cannot be set up properly.
I'd appreciate a less biased information flow.
To be more precise: PAT support is in GRADD.SYS which is used by Panorama.
Title: Re: New OS/4 kernel :: SVN4222
Post by: Eugene Gorbunoff on August 21, 2014, 12:33:38 pm
My message aimed to protect the developers of Panorama disappeared:

Support of PAT and MTRR is implemented in Panorama VESA and was improved in 2012:
http://ecomstation.ru/commentnews.php?id=2233
Title: Re: New OS/4 kernel :: SVN4222
Post by: OS4User on August 21, 2014, 05:08:06 pm
The latest  versions of Panorama also support PAT where MTRRs cannot be set up properly.
I'd appreciate a less biased information flow.
To be more precise: PAT support is in GRADD.SYS which is used by Panorama.

want  to draw your attention to a few points:
yes, the latest Panorama can use PAT to set WC for LFB,  but Panorama tries to use PAT when it is not able to use MTRR  - (I can hardly imagine when such a scenario may happen).

to use PAT or MTRR  it is necessary to program corresponding MSRs and it is very important to have the same value in these registers between CPU cores, unfortunately, original kernel never offers an API to do proper MSR programing, that is why Panorama uses chain Panorama -> GRADD.SYS -> ACPI.PSD,  this path does not give 100% guaranty that MSRs will be coherent (fortunately this missing coherency happens not very often,  but I saw it a few times).

to use PAT Panorama (GRADD.SYS)  hacks the PTEs corresponding to LFB (by the way SNAP is doing similar hack but for other reason). Yes it works  and there is no other way to use PAT with original kernel  -  but me personally, I do not like such hacks.

os/4 kernel provides KernVMAlloc2 and a programer is able to set any type of memory caching without hacking PTEs,  PAT MSRs are set during CPU start  -  this way coherency is provided.





Title: Re: New OS/4 kernel :: SVN4222
Post by: Lars on August 21, 2014, 11:25:21 pm
I can easily think of a scenario where use of MTRRs become a problem compared to PAT.
MTRR mem. type regions have to be of size "power of 2" and there are restrictions regarding overlapping regions. PAT is fine granular down to the 4 kByte memory page and it can"override" the underlying MTRR memory type to a certain extent.
Title: Re: New OS/4 kernel :: SVN4222
Post by: OS4User on August 22, 2014, 12:34:17 am
I can easily think of a scenario where use of MTRRs become a problem compared to PAT.
MTRR mem. type regions have to be of size "power of 2" and there are restrictions regarding overlapping regions. PAT is fine granular down to the 4 kByte memory page and it can"override" the underlying MTRR memory type to a certain extent.

to be fair, I haven't studied deeply how GRADD.SYS sets MTRR and I will belive you that it's sometimes a failure in setting. PAT in this case is much more convenient to use. But there is an issues here too - you have to have a proper bits in PTEs of each LFB mapping. Unfortunately when Panorama uses PAT for setting WC, then not all mapping get necessary bits in PTEs.
Title: Re: New OS/4 kernel :: SVN4221
Post by: Sergey Posokhov on August 22, 2014, 02:16:56 pm
I've got a bug on ThinkPad 510.
Something hangs when PM starts on, so I can only see a mouse pointer.

Finally, I removed from Config.sys:
Quote
RUN=C:\MMOS2\qrymmcd.exe

And bug has disappeared.
As usual, global variables, mutex semaphores and global shared memory are root of all evil.
Title: Re: New OS/4 kernel :: SVN4222
Post by: walking_x on August 22, 2014, 09:58:10 pm
I can easily think of a scenario where use of MTRRs become a problem compared to PAT.
MTRR mem. type regions have to be of size "power of 2" and there are restrictions regarding overlapping regions. PAT is fine granular down to the 4 kByte memory page and it can"override" the underlying MTRR memory type to a certain extent.
There is no problems with MTRR usage, if do it right (not like it was done in panorama before PAT version).

In QSINIT - registers reprogrammed to entire address space of video card (get  it from PCI) for 1st CPU and these values copied to secondary CPUs on early init stage.

I have no any problems with such method. And no  requirements  in  "New And Special" version of panorama or new screen  driver  as  in  later  OS/4.  Even,  no  need of synchronization on multiple CPUs in code :)
Title: Re: New OS/4 kernel :: SVN4221
Post by: Sergey Posokhov on August 28, 2014, 01:51:57 pm
Once upon a time, I changed a string in "os2ldr.ini" and set:
Quote
timeout=0
And loader refused to boot anything, so I changed it to:
Quote
timeout=1
BTW, with 4225 previous bug has disappeared. Thanks.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Sergey Posokhov on October 02, 2014, 05:51:46 pm
Version 4239 doesn't work:

TRAP0008

Internal processing error at location
##0168:fff9bfe0 - 000f:00090fe0
3464, 0 trap.asm

06860655 - (no datetime)
internal revision 15.1_SMP.4239
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on October 03, 2014, 05:13:03 pm
I got 4243. It boots up to the GUI, then reboots, on my Lenovo ThinkPad L530 (UEFI). It does TRAP0008, almost immediately, on my Lenovo ThinkPad T510.

FWIW, I have quit using the OS/4 kernel, now that QSINIT has been fixed to work with our ACPI. Since it is easy to switch, I will continue to test, but I don't see any advantage to using OS/4, at the moment (even if it would work).
Title: Re: New OS/4 kernel :: SVN4227
Post by: Sergey Posokhov on November 12, 2014, 05:56:37 pm
Now 4248 (http://www.os2world.com/wiki/index.php/OS/4) works with Lenovo T410.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on November 13, 2014, 03:50:53 am
Quote
Now 4248 works with Lenovo T410.

Seems to work with my Lenovo ThinkPad T510, and L530, now.
Title: Re: New OS/4 kernel :: SVN4262
Post by: OS4User on December 03, 2014, 12:33:54 am
started from SVN4262  -  needs patched acpi.psd (http://gus.biysk.ru/os4/Patches/acpipsdpatch.RAR) and /ST=0 in command line or os4apic.psd

started from SVN4250  is no more compatible with alternative loader



Title: Re: New OS/4 kernel :: SVN4262
Post by: guzzi on December 03, 2014, 01:50:14 am

started from SVN4250  is no more compatible with alternative loader

That's the second major compatibility break. Not a good thing, imho.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on December 03, 2014, 04:27:36 am
Quote
started from SVN4250  is no more compatible with alternative loader

I assume you mean that it is not compatible with QSINIT. Until that gets fixed, I have lost interest in OS/4.

Quote
needs patched acpi.psd

Another good reason to avoid OS/4, IMO.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Andreas Schnellbacher on December 05, 2014, 01:27:06 am
Doug, the point is not about avoiding something, but about getting the best out of the available options. Actually, you can't compare directly one option with another, because each of them has its own case of usage.
Title: Re: New OS/4 kernel :: SVN4227
Post by: guzzi on December 05, 2014, 03:02:26 am
Doug, the point is not about avoiding something, but about getting the best out of the available options. Actually, you can't compare directly one option with another, because each of them has its own case of usage.

Very true. However, I do think that loss of compatibility is in the end crippling for an alternative kernel. I'd like to see OS/4 develop as a 'drop in' kernel that remedies some of the limitations of the original one, much in the same way that QSinit is more or less a drop in replacement for the original loader. That would mean compatibility with ACPI and standard loader, com port debug output, etc.. The way it goes now the developers seem to divert more and more from the standard. No doubt they have good reasons for that, but imho it's a mistake.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on December 05, 2014, 04:34:11 am
Doug, the point is not about avoiding something, but about getting the best out of the available options. Actually, you can't compare directly one option with another, because each of them has its own case of usage.

So far, OS/4 has added nothing that seems to be useful. It does break system dumps, which is a major handicap for those who develop software for eCS. Add the questionable legal status, and I don't see any reason to use it. That doesn't mean that I will stop testing it, but I won't spend much time trying to figure out problems, until it offers some advantage. One must also remember that it is not guaranteed to work in all cases (or even work, at all). I find that those releases which work, work well. Those that don't work, are completely broken, but there is no clue what was changed, and it should be obvious to the programmers that there is a problem. It seems that they just make the package available, whether it works, or not.

Quote
The way it goes now the developers seem to divert more and more from the standard. No doubt they have good reasons for that, but imho it's a mistake.

If they are doing that to figure out exactly what works, and doesn't work, I cannot find fault (even when it doesn't work, at all). However, if they intend to make a proper release in that state, I agree that it is a mistake.

QSINIT, on the other hand has solved a serious problem with memory being limited to 512 meg (4 GB installed), on some machines. As a bonus, it adds the RAMDISK that uses memory above what OS/2 can normally access, which also offers the possibility of using that memory for other things. There is also no question about the legality, even though the license is not very good. I suspect that that is a misunderstanding on the author's part. The intent seems to be to prevent somebody from profiting from the project, but it puts the project into a gray area, where it is not clear if it is meant to prevent inclusion in eCS (which could be argued to be non profit), or if it is meant to prevent General Motors (for example) from using it to make a profit by using eCS with QSINIT. Either way, it makes QSINIT mostly useless, and therefore irrelevant because no business, or government, can take the chance on what a judge might think about it. Then again, the license is probably unenforceable anyway. Oh yeah, you can play a couple of games with it, but I am not too sure why anybody would want to do that. I can see the possibility of adding a "standard interface" to the machine, making things like video adapters, or disk drives, more compatible to the eCS drivers (much like what virtual machines do).
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on December 06, 2014, 10:19:06 am
If they are doing that to figure out exactly what works, and doesn't work, I cannot find fault (even when it doesn't work, at all). However, if they intend to make a proper release in that state, I agree that it is a mistake.

OS/4 Team does not have big enough "test department". Of course before uploading it is tested  internally. But this internal testing  cannot give a guaranty  that kernel will work for every case.

I assume you mean that it is not compatible with QSINIT. Until that gets fixed, I have lost interest in OS/4.

It is very pity, but nothing to fix in OS/4 (in this case)  because it is not broken. The kernel has changes in the internal organization and QSINIT no more recognize it  as SMP.

QSINIT can be easily fixed:  line 168 in https://github.com/OS2World/SYSTEM-LOADER-QSINIT/blob/master/system/src/ldrapps/bootos2/bootos2.c (https://github.com/OS2World/SYSTEM-LOADER-QSINIT/blob/master/system/src/ldrapps/bootos2/bootos2.c) has to be
Code: [Select]
isSMP = mi->obj[0].size<=PAGESIZE*4;
Title: Re: New OS/4 kernel :: SVN4227
Post by: walking_x on December 07, 2014, 10:10:30 pm
   Ok, I made changes in new revision, but with more strictive check.
   It must work until next "great changes".
   In addition VALIMIT key now supported too (but only for later OS/4 kernels, of course).

   And HD4DISK.ADD must be updated to one from this revision, older versions will have troubles in detection of disk with non-default parameters (sorry, OS4User infected me with his "traditional incompatibility" ;) ).
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on December 08, 2014, 04:33:01 am
Quote
Ok, I made changes in new revision, but with more strictive check.

I don't care who fixes it. At the moment, I don't need anything that OS/4 provides, while I do need the QSINIT fix for the 512 meg memory limit, when 4 GB is installed (also fixed by OS/4), and I REALLY like the RAMDISK. That means that I will use the latest QSINIT (I always use a matching HD4DISK.ADD), as long as it works. I will also test OS/4, when it works with the current QSINIT package, but I probably won't actually use it, until there is a reason to do so.

Thanks to all of you...
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on December 10, 2014, 06:56:07 am
4270  -  a bug in clock03b.sys  was fixed. the issue were sporadic traps
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on December 11, 2014, 05:37:01 am
4270  -  a bug in clock03b.sys  was fixed. the issue were sporadic traps

Well, I get TRAP0008 immediately after the first 'PIC' message, on both machines where I try OS/4. It is definitely not "sporadic".

I wish the WhatNew file would get updated, so a user might have some idea about what the developers are messing around with.
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on December 11, 2014, 06:55:56 am
4270  -  a bug in clock03b.sys  was fixed. the issue were sporadic traps

Well, I get TRAP0008 immediately after the first 'PIC' message, on both machines where I try OS/4. It is definitely not "sporadic".

what PSD do you use ?  in case ACPI.PSD,  hope  it is patched  and /ST=0   is added to command line
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on December 11, 2014, 05:38:12 pm
Quote
what PSD do you use ?  in case ACPI.PSD,  hope  it is patched  and /ST=0   is added to command line

I use the latest ACPI from Arca Noae (3.22.06).

I think somebody had better smarten up, and at least document things like that, if they want users to do testing for them.

Meanwhile, OS/4 is, again, broken IMO.
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on December 11, 2014, 07:17:06 pm
Quote
what PSD do you use ?  in case ACPI.PSD,  hope  it is patched  and /ST=0   is added to command line

I use the latest ACPI from Arca Noae (3.22.06).

I think somebody had better smarten up, and at least document things like that, if they want users to do testing for them.

Meanwhile, OS/4 is, again, broken IMO.

Hi Doug :)

It was mentioned in the previous post that ACPI.PSD has to be patched and to be use  with /ST=0 in it's command line.

In case you are not making a joke of it, here is a patches for ACPI.PSD http://gus.biysk.ru/os4/Patches/AcpiPsdPatches.rar (http://gus.biysk.ru/os4/Patches/AcpiPsdPatches.rar).  Now, it includes a patch for your 3.22.06 too.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on December 12, 2014, 01:23:43 am
Quote
It was mentioned in the previous post that ACPI.PSD has to be patched and to be use  with /ST=0 in it's command line.

So it was. Unfortunately, I didn't think to read through this thread again, to find vital information, that needs to be in a README.

I am not inclined to use a patched PSD for normal operation. I am also not inclined to maintain a separate CONFIG.SYS. I tried that for a while, and it was turning into a nightmare. Updating ACPI would also turn into a problem.

I need to evaluate what needs to happen. Perhaps I will put OS/4 into a virtual machine, and test it there.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Doug Bissett on December 12, 2014, 05:51:50 am
Quote
Perhaps I will put OS/4 into a virtual machine, and test it there.

Okay, I made an eCS 2.2 (with updates)  boot system in VBox. Added QSINIT and OS/4. Modified ACPI.PSD (3.22.03), and added the "/ST=0" parameter. It then stopped at RESOURCE.SYS. The "fix" for that was to add the PRELOAD parameter to the OS/4 startup selection in OS2LDR.INI (I don't find that to be a requirement, in the docs).
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on January 04, 2015, 10:40:53 am
Quote
Perhaps I will put OS/4 into a virtual machine, and test it there.

Okay, I made an eCS 2.2 (with updates)  boot system in VBox. Added QSINIT and OS/4. Modified ACPI.PSD (3.22.03), and added the "/ST=0" parameter. It then stopped at RESOURCE.SYS. The "fix" for that was to add the PRELOAD parameter to the OS/4 startup selection in OS2LDR.INI (I don't find that to be a requirement, in the docs).

Tnx, Doug

This case has to be investigated.  I am always using PRELOAD so have never seen this issue with ACPI.PSD.
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on January 18, 2015, 06:27:31 pm
sddhelp.sys for os/4 is updated http://gus.biysk.ru/os4/test/sddhelp/sddhelp_v01a.RAR

irq monitor for os/4 http://gus.biysk.ru/os4/test/irqmon.exe 

os/4 kernel is updated to 4293  http://gus.biysk.ru/os4/os2krnlSVN4293_unoff.zip
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on June 11, 2015, 09:33:13 am
os/4 kernel is updated to 4369  http://gus.biysk.ru/os4/os2krnlSVN4369_unoff.zip

to get kernel log  type:      copy KERNLOG$  mykernel.log
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on June 12, 2015, 07:09:33 pm
os/4 kernel is updated to 4370  http://gus.biysk.ru/os4/os2krnlSVN4370_unoff.zip

Starting from this rev OS/4 requests an external oemhlp.bpd. Do not forget to copy it to \OS2\BOOT of the boot drive.

oemhlp.bpd is supplied together with kernel.
Title: Re: New OS/4 kernel :: SVN4227
Post by: neozeed on August 01, 2015, 02:42:20 pm
It's not open sourced at all is it?  I never can find a SVN server, should I even look?
Title: Re: New OS/4 kernel :: SVN4227
Post by: dbanet on August 01, 2015, 03:36:46 pm
It's not open sourced at all is it?  I never can find a SVN server, should I even look?

No, unfortunately, not.
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on August 27, 2015, 07:39:23 pm
 OS/4 tested HW list is updated http://www.os2world.com/wiki/index.php/Phoenix_OS/4#OS.2F4_Tested_Hardware_List (http://www.os2world.com/wiki/index.php/Phoenix_OS/4#OS.2F4_Tested_Hardware_List)

current   svn version  is 4410
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on December 20, 2015, 09:46:19 pm
OS/4 kernel svn4500 is released. Starting from this ver OS/4 kernel loads clock03c.sys instead of  clock03b.sys
New clock driver is in a package with kernel.
Title: Re: New OS/4 kernel :: SVN4502
Post by: OS4User on December 25, 2015, 08:56:14 pm
OS/4 kernel svn4502 is released. The changes have occurred mostly in clock$.
If HPET is available in the computer, clock$ will use it for providing DosTmrQueryTime/Freq with 64bit time stamp.
Title: Re: New OS/4 kernel :: SVN4502
Post by: Dariusz Piatkowski on January 02, 2016, 02:04:02 am
OS/4 kernel svn4502 is released. The changes have occurred mostly in clock$.
If HPET is available in the computer, clock$ will use it for providing DosTmrQueryTime/Freq with 64bit time stamp.

Re-tried this latest release...I am currently successfully running SMP in 5-core mode with ACPI 3.22.08, so that is my starting point.

Here are some brief results:

1) booting with OS4krnl produces a hard trap right after PMSHELL (I can not tell at all what is going on, so this looks like a candidate for a COM port debug, I need to get this organized though)

2) booting with OS4krnl but ACPI.PSD produces a trap with a complaint regarding missing ACPI4.BPD file...did some researching here but best I could do was to find an earlier forum post (http://www.os2world.com/forum/index.php?topic=785.0 (http://www.os2world.com/forum/index.php?topic=785.0)) and having re-read the on-line docs multiple times I still can not tell whether I should be attempting to patch the ACPI.PSD driver with the patch files supplied at the OS4 site (I am guessing the answer is a NO because those patches are meant for 3.22.06 release whereas I'm running 3.22.08 here)

I will a couple more combinations here, like RETAIL vs DEBUG kernels and /APIC vs none for OS4APIC.PSD driver.
Title: Re: New OS/4 kernel :: SVN4502
Post by: OS4User on January 02, 2016, 10:42:13 am
1) booting with OS4krnl produces a hard trap right after PMSHELL (I can not tell at all what is going on, so this looks like a candidate for a COM port debug, I need to get this organized though)

Similar stuff sometimes happens on  my computer as well. In the comport log it looks like this:

Code: [Select]
DelayHardError SYS3171: 4 string(s):
 Pid 0020  Tid 0001  Slot 0045  HobMte 053A
 C:\OS2\PMSHELL.EXE
c0000005
1f93b94a
P1=00000002  P2=0003ff14  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=00000000  EBX=1f93b93c  ECX=00040028  EDX=0004f564
ESI=00000000  EDI=0004f3f4 
DS=0053  DSACC=d0f3  DSLIM=ffffffff 
ES=0053  ESACC=d0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1f93b94a  CSACC=d0df  CSLIM=ffffffff
SS:ESP=0053:0003ff18  SSACC=d0f3  SSLIM=ffffffff
EBP=00040054  FLG=00010206

PMWP.DLL 0001:0000b94a
This happens once every 100 boots approx. I don't know the reason and it happens much later after the init of the kernel has finished.

It's possible that it's some old bug that has no relation to OS/4. I remember on the original kernel there sometimes happened situations when there appeared PMshell background and nothing more. Somebody offered a solution with organizing a kind of delay  before PMshell start, but I cannot find that post.

Of course, this can be something else, in this situation comport log should help.

2) booting with OS4krnl but ACPI.PSD produces a trap with a complaint regarding missing ACPI4.BPD file...did some researching here but best I could do was to find an earlier forum post (http://www.os2world.com/forum/index.php?topic=785.0 (http://www.os2world.com/forum/index.php?topic=785.0)) and having re-read the on-line docs multiple times I still can not tell whether I should be attempting to patch the ACPI.PSD driver with the patch files supplied at the OS4 site (I am guessing the answer is a NO because those patches are meant for 3.22.06 release whereas I'm running 3.22.08 here)

Yes, ACPI.PSD has to be patched and used with /ST=0. Indeed,  the patch does very simple thing:
in ACPI.PSD there is something like this:
Code: [Select]
if (ST==0)
{
    ST=4096
}

patch makes this code out of it:
Code: [Select]
if (ST==0)
{
    ST=0
}

thus, if one asks for ST=0 he does get ST=0. I would like to stress that this patch does not "spoil"  ACPI.PSD and it still can be used with original kernel.

ACPI4.BPD - it is an optional acpi driver. It is not obligatory for booting the system.

It is true that there are patches only for 3.22.06 and 3.22.03, that's because nobody had asked for something else. If you insist,  patch for 08 will also be produced. At the same time you may try OS/4 with 06 (ACPI.PSD only  the rest may remain 08)

I will a couple more combinations here, like RETAIL vs DEBUG kernels and /APIC vs none for OS4APIC.PSD driver.

waiting for result  (better with comport log ;) )
Title: Re: New OS/4 kernel :: SVN4502
Post by: Dariusz Piatkowski on January 02, 2016, 03:14:00 pm
1) booting with OS4krnl produces a hard trap right after PMSHELL (I can not tell at all what is going on, so this looks like a candidate for a COM port debug, I need to get this organized though)

Similar stuff sometimes happens on  my computer as well. In the comport log it looks like this:

Code: [Select]
DelayHardError SYS3171: 4 string(s):
 Pid 0020  Tid 0001  Slot 0045  HobMte 053A
 C:\OS2\PMSHELL.EXE
c0000005
1f93b94a
P1=00000002  P2=0003ff14  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=00000000  EBX=1f93b93c  ECX=00040028  EDX=0004f564
ESI=00000000  EDI=0004f3f4 
DS=0053  DSACC=d0f3  DSLIM=ffffffff 
ES=0053  ESACC=d0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1f93b94a  CSACC=d0df  CSLIM=ffffffff
SS:ESP=0053:0003ff18  SSACC=d0f3  SSLIM=ffffffff
EBP=00040054  FLG=00010206

PMWP.DLL 0001:0000b94a
This happens once every 100 boots approx. I don't know the reason and it happens much later after the init of the kernel has finished.

It's possible that it's some old bug that has no relation to OS/4. I remember on the original kernel there sometimes happened situations when there appeared PMshell background and nothing more. Somebody offered a solution with organizing a kind of delay  before PMshell start, but I cannot find that post.

What you describe is precisely what I see with my standard 3.22.08 setup upon nearly every re-boot. Meaning, the PMSHELL window displays (the blue background) and halts...CTL-ALT-DEL still reboots the PC though. I find that if I hit the CTL-ESC key combination repeatedly as the PMSHELL window is coming up I can sucessfully boot though. This procedure works pretty well when I run my 6-core CPU in 5-core mode, as soon as I enable all the cores the PMSHELL nearly always hangs regardless of what I do during bootup. So this certainly appers to be some type of timing issue...

...Yes, ACPI.PSD has to be patched and used with /ST=0. Indeed,  the patch does very simple thing:
in ACPI.PSD there is something like this:
Code: [Select]
if (ST==0)
{
    ST=4096
}

patch makes this code out of it:
Code: [Select]
if (ST==0)
{
    ST=0
}

thus, if one asks for ST=0 he does get ST=0. I would like to stress that this patch does not "spoil"  ACPI.PSD and it still can be used with original kernel.

ACPI4.BPD - it is an optional acpi driver. It is not obligatory for booting the system.

It is true that there are patches only for 3.22.06 and 3.22.03, that's because nobody had asked for something else. If you insist,  patch for 08 will also be produced. At the same time you may try OS/4 with 06 (ACPI.PSD only  the rest may remain 08)

Well, I will try 3.22.06, but if at all possible (not sure how much work this is) I'd prefer to run the matching 3.22.08 instead.

I will a couple more combinations here, like RETAIL vs DEBUG kernels and /APIC vs none for OS4APIC.PSD driver.

waiting for result  (better with comport log ;) )

...nah, no go here...all other combinations produced the same result...a hang at PMSHELL, so I will focus on teh comport log and will attempt to re-test with the patched 3.22.06 first.

Co-incidentally, what is the reason for the different version of DOSCALL1.DLL? I repeated all my tests with both versions (14.106 SMP and the one included in the 4502 drop) but the results were the same.

Thanks for the quick response!!!
Title: Re: New OS/4 kernel :: SVN4227
Post by: Sergey Posokhov on January 02, 2016, 08:34:19 pm
It looks like a bug in VBE2GRAD.DLL, also known as Panorama.
Version "3 Dec 2015" works with OS/4 SVN4506 (both debug and retail), previous doesn't... even with SVN4200.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Lars on January 04, 2016, 05:56:57 pm
It remains a secret of the OS4Krnl developer team why they removed the trace and strace facilities.
Without that none of the USB drivers can be traced as they are making good use of OS/2 built in tracing mechanism. Tracing is about the only chance for a developer to do offline analysis of problems surfacing at the user's site (unless you want to recode your own tracing facility).
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on January 04, 2016, 09:37:15 pm
It remains a secret of the OS4Krnl developer team why they removed the trace and strace facilities.
Without that none of the USB drivers can be traced as they are making good use of OS/2 built in tracing mechanism. Tracing is about the only chance for a developer to do offline analysis of problems surfacing at the user's site (unless you want to recode your own tracing facility).

I have never use trace facilities, same time KernPrintf was sufficient  to debug clock03 and some other drivers.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Lars on January 05, 2016, 12:49:42 am
That's because you obviously love to reinvent the wheel.
And enabling trace for the kernel components of OS/2 can help, for example, in order to investigate when OS2DASD is called with what parameters. You cannot replace that with your home brewn way of outputting text to whereever.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Martin Iturbide on January 05, 2016, 01:05:05 pm
Hi Lars

It remains a secret of the OS4Krnl developer team why they removed the trace and strace facilities.

You can always create your own kernel and then you can add the trace functionality.

Quote
That's because you obviously love to reinvent the wheel.
Or you can suggest it to the OS4 team in a more constructive way.... or offer yourself to help on that project.

Regards
Title: Re: New OS/4 kernel :: SVN4227
Post by: Lars on January 05, 2016, 10:41:09 pm
Hi Lars

It remains a secret of the OS4Krnl developer team why they removed the trace and strace facilities.

You can always create your own kernel and then you can add the trace functionality.

Quote
That's because you obviously love to reinvent the wheel.
Or you can suggest it to the OS4 team in a more constructive way.... or offer yourself to help on that project.

Regards

Create my own kernel ? You must be kidding. What sense does it make if every OS/2 user (guess there are about 250 left on planet earth) creates his own kernel ?
Suggesting anything to the OS4 team is lost ground. They are proud of their own proprietary solution.
They have given NO reason whatsoever why they removed something that worked just fine and that is WELL DOCUMENTED to exist.
Two things are for sure:
1) I am certainly not wasting any time testing their kernel
2) ArcaNoae is certainly not wasting any time to get things working also with the OS4 kernel

The sad thing is that these guys could really help in developing sensible things for OS/2: USB3 Support, help fix UNIAUD, whatever.
What they do is wasting time but of course they can waste all the time they want, after all, it's their time.

Lars
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on January 06, 2016, 12:21:22 am
With due respect to you, I can't agree with all your statements.

Suggesting anything to the OS4 team is lost ground.

On the contrary. OS/4 team will gladly hear reasonable advice, suggestions, bug reports, etc.

They have given NO reason whatsoever why they removed something that worked just fine and that is WELL DOCUMENTED to exist.

May be one day trace facility will be re-enabled.

What they do is wasting time but of course they can waste all the time they want, after all, it's their time.

There are people who use OS/4 and find it useful. Moreover, there are several HW where the original kernel wasn't able to run at all(in any configurations with any loaders), only OS/4 could run there. Thus OS/4 isn't that much of a waste of time as it may seem.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Martin Iturbide on January 06, 2016, 04:19:57 am
Hi Lars

I regret your attitude, you are not being constructive.  If you don't like OS4 kernel and you can not give constructive feedback, just move on.

Quote
2) ArcaNoae is certainly not wasting any time to get things working also with the OS4 kernel
Now you speak for Arca Noae? Are they paying your to thrash other projects?  Or is it that Arca Noea has an interest on seeing OS4Kernel fail? Should we expect to see on Arca Noae's next announcement something like "Do not use OS4 Kernel"?

Quote
The sad thing is that these guys could really help in developing sensible things for OS/2: USB3 Support, help fix UNIAUD, whatever.
You can suggest but people does with their time whatever they like. I had seen many developers choking on their own arrogance telling others what to do (for free and in their own time) in very "ugly" ways. It is better to ask for things in a constructive way.

Quote
What they do is wasting time...
Sorry Lars, but it even sounds like you are talking to bad influences over the phone, you must chill out and understand that everybody does with their time whatever they want. This is a community and people does what they want.

Regards.

Title: Re: New OS/4 kernel :: SVN4227
Post by: Lars on January 06, 2016, 10:03:14 am
1) I am not paid by ArcaNoae, at least up to this point. I am free to say and do what I want.
2) I neither have the time nor the interest to thrash any project. I am stating an opinion.
3) you need not expect any statement from ArcaNoae. But I am in discussion with David every now and then. And he is certainly not monitoring this group. And he tests all his stuff with a limited set of kernels. If they find a problem with the kernel they will concentrate on patching the official kernels.
4) the next ACPI.PSD is in the queue. Do you think it is sensible for the OS4 team to offer patches to ACPI.PSD to make it work with their kernel ad infinitum ?

Yes, I'll move on.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Martin Iturbide on January 06, 2016, 02:13:54 pm
Hi Lars

I also have accumulated frustration of all the things that I want for the platform, but telling other projects and people that "your project is a waste of time, you better do this" it is not polite and you are getting that people blocked to any suggestions you may have.

You are free to create your own forum thread and specify what should be the agenda for the platform under your own opinion and try to motivate people to help you.
If you ask me to organize any documentation on the EDM/2 wiki, to request IBM republishing permission for some OS/2 documentation, to help raising money for an OSS project, to post anything on OS2World to help your projects or anything that is on my hands, I will help you for sure. But it has to be a positive collaborative thing.

The final word Lars, is that I really want to help you and do something for the benefits for platform users, but it needs to be positive.

Regards
Title: Re: New OS/4 kernel :: SVN4227
Post by: Dariusz Piatkowski on January 07, 2016, 02:23:34 am
Lars,

...
4) the next ACPI.PSD is in the queue. Do you think it is sensible for the OS4 team to offer patches to ACPI.PSD to make it work with their kernel ad infinitum ?
...

So here is a real-world example why alternative approaches may be worth pursuing.

I have directly benefitted by subscribing to the Arca Noae's DRIVER package, thanks to that I now have a pretty stable SMP environment, although (and this is the big enough of a justification in my mind) of the total of 6 CPU cores I can only boot the machine up with 5, otherwise I end up with the dreadful "PMSHELL blue screen". Having logged a ticket with support organization it was prompty written of as a "known PMSHELL issue"...hmm...so really?...no further debug, no additional follow-up, just a plain "...can't be fixed..."? And this is for software that I actually paid money for...

Now, from my point of view, I am literally locked-out of using nearly 20% of my computing power simply b/c the current de-facto SMP solution won't let me do it. I'm not saying that this is the SOLE reason...heck, I am no os2ldr/krnl/PMSHELL guru, but as long as I have apparently reached the end of the road in one approach I will pursue others if they arise so that maybe in the course of testing/researching I will learn something and maybe someone else in our tiny community will benefit from.

Beyond just that very selfish reason above, here is a more precise one: if the /ST=0 parameter in the ACPI.PSD drive does in fact get ignored, and the authors have set some arbitrary value for the size of the stack, then I would consider this to be a defect. So if the OS4 team patches the binary to actually correct this behaviour then I'm actually questioning why the "core" OS2 maintainer team refuses to fix the code itself?
Title: Re: New OS/4 kernel :: SVN4227
Post by: OS4User on January 07, 2016, 11:09:38 am
Beyond just that very selfish reason above, here is a more precise one: if the /ST=0 parameter in the ACPI.PSD drive does in fact get ignored, and the authors have set some arbitrary value for the size of the stack, then I would consider this to be a defect. So if the OS4 team patches the binary to actually correct this behaviour then I'm actually questioning why the "core" OS2 maintainer team refuses to fix the code itself?

The case is a bit more complicated. OS/2 kernel offers to PSD very small stack (2672 bytes). It is ok for os2apic.psd and  it looks like not enouph for ACPI.PSD. That is why ACPI.PSD does some actions to increase PSD stack offered by the kernel. It is not an easy thing since PSD stack is organized on per processor base. At the same time ACPI.PSD recognizes /ST key to set desirable PSD stack size on user demand.  ACPI.PSD does not allow the user to set stack size = 0 (as it is really senseless), but if one finds a way (the patch helps) to set "ST=0", ACPI.PSD will not go through the procedure of increasing PSD stack offered by the kernel.

OS/4 starting from svn ver 4250 has unified PSD/interrupt stack with 12k size thus ACPI.PSD has no need to increase it. At the same time, "not easy" ASPI.PSD procedure for increasing PSD stack, simply spoils internal data structure of OS/4 kernel. That is way ACPI.PSD has to be patched and /ST=0 has to be used in order to work with OS/4.
Title: Re: New OS/4 kernel :: SVN4227
Post by: Sergey Posokhov on January 14, 2016, 10:49:41 pm
SVN 4508.
http://www.youtube.com/watch?v=v36l7eVXvZc
Title: Re: New OS/4 kernel :: SVN4227
Post by: Sergey Posokhov on January 14, 2016, 10:54:05 pm
SVN 4508.
http://www.youtube.com/watch?v=v36l7eVXvZc
Title: Re: New OS/4 kernel :: SVN4227
Post by: muffetta on January 14, 2016, 11:16:02 pm
..SVN4512, 2Core, HD(1080p). Both in range 50% - 80%, max 97% (CPU 1)
Title: Re: New OS/4 kernel :: SVN4227
Post by: Sergey Posokhov on January 15, 2016, 10:58:05 pm
SVN 4512.
http://www.youtube.com/watch?v=LiyS-DnkMeY
100% sadness (endogenous depression).
Title: Re: New OS/4 kernel :: SVN4227
Post by: muffetta on January 25, 2016, 11:34:18 am
..SVN4515. The same test running in flash and html5, using both OS4 and original eCS kernels: in this case the high CPU load seems not connected to OS/4. For the html5, obviously is light, since 1028HD is not available (max av. 360p).