Author Topic: New OS/4 kernel :: SVN4227  (Read 148873 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: New OS/4 kernel :: SVN4172
« Reply #60 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 issues 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.

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4172
« Reply #61 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.

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4172
« Reply #62 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.
« Last Edit: March 23, 2014, 07:32:41 pm by Boris »

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: New OS/4 kernel :: SVN4172
« Reply #63 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.

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4172
« Reply #64 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.
« Last Edit: March 23, 2014, 09:31:07 pm by Boris »

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4173
« Reply #65 on: March 26, 2014, 02:40:51 pm »
Up!
4173!

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4173
« Reply #66 on: April 03, 2014, 08:12:36 pm »
Dariusz and everyone else,

I've just wrote the "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!

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4177
« Reply #67 on: April 19, 2014, 07:35:21 pm »
Up!
4177!

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4180
« Reply #68 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:
  • Download the driver (direct link).
  • Unpack the driver somewhere, e. g. \OS2\BOOT, near to the original SDDHELP.SYS. You may rename it -- the name does not matter.
  • Now you have several options:
    • To try to run with this driver once, you may use the CONFIG.SYS editor feature of OS/4 loader or, alternatively, QSINIT:
      • Reboot.
      • Select the new (=>4180) OS/4 kernel in the kernel loader menu.
      • Hit Alt-E.
      • Edit the path in the SDDHELP.SYS driver loading statement (DEVICE=X:\OS2\BOOT\SDDHELP.SYS usually, where X: is your boot drive), so that it will now point to the new driver, where you unpacked it.
      • Continue booting (for example, hit F2, Enter).
      So, the CONFIG.SYS file itself is not modified, and if you run into a problem, a simple reboot will fix this.
    • If you don't always use OS/4 but want to test the new driver, you may set OS/4 kernel to use a different CONFIG.SYS. Read more about this feature on the wiki page. Scroll to the kernel options table: you need the CFGEXT option.
    • You may also completely replace the old SDDHELP.SYS with the new one if you trust us. ;)
  • Now test the video: try moving windows with the Full window dragging option on -- they should now move flawlessly, without the "tearing" effect and/or lags; also try scrolling some content (but it still depends on the speed of your computer and graphics card).
  • If you run into a problem, please contact us.



Thank you!
« Last Edit: April 28, 2014, 05:05:12 pm by Boris »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: New OS/4 kernel :: SVN4180
« Reply #69 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.

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
« Reply #70 on: May 03, 2014, 10:53:56 pm »
Up!
4183!

Andy Willis

  • Sr. Member
  • ****
  • Posts: 292
  • Karma: +7/-0
    • View Profile
Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
« Reply #71 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)? 

dbanet

  • Guest
Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
« Reply #72 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.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
« Reply #73 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

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: New OS/4 kernel :: SVN4183 :: New SNAP helper driver (SDDHELP.SYS)
« Reply #74 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