OS2World OLD-STATIC-BACKUP Forum

WebSite Information => Comments, Suggestions & Questions => Topic started by: AAA on 2008.11.07, 17:05:07

Title: New kernel
Post by: AAA on 2008.11.07, 17:05:07
Looks like a new kernel is coming.

It would be great if those who are interested in this shared their opinion regarding what they want to see added and/or improved in a new kernel.

I believe, this would help the developers.
Title: Re: New kernel
Post by: djcaetano on 2008.11.07, 19:39:32
I don't know if this is possible, but an improved support to memory management would be great.
The kernel we are using now is too damn limited when it comes to upper memory management. It is very common (mainly when using ODIN apps) receive an "out-of-memory" error when only 300MB out of 2GB are being used by applications.

I don't know if it is possible, but another cool thing would be a way to update PATH, LIBPATH and other PATHs system-wide without the need to reboot the system.

Well, these are my first two wishes. :)
Title: Re: New kernel
Post by: MrJinx on 2008.11.07, 23:12:58
Being able to load and unload at least some .sys & .add type drivers without a reboot would be great.
Refreshing config space changes and snoop. All those things reboots are made of when trying to develop drivers and tweak resources. Since we are asking for the world here. ;D
Title: Re: New kernel
Post by: RobertM on 2008.11.07, 23:53:55
Quote from: MrJinx on 2008.11.07, 23:12:58
Being able to load and unload at least some .sys & .add type drivers without a reboot would be great.
Refreshing config space changes and snoop. All those things reboots are made of when trying to develop drivers and tweak resources. Since we are asking for the world here. ;D

I think that may be a nice option for the developer release of the kernel, but am happier with those drivers unchangeable during normal operations. The system is more secure that way - then with access rights applied to the config files, it would be very difficult to "hose" a system from an external (or externally loaded) location.

Though, for perception purposes, it is a nice thing to have, as end-users are used to such functionality on Windows. At the very least, screen resolution changing without reboots would be a nice touch. The rest I could do without.

Rob
Title: Re: New kernel
Post by: cytan on 2008.11.08, 00:12:57
Much, much larger shared memory space than we have now (512MB). OpenOffice, Mozilla, etc. all take up so much shared memory space that after a while shared memory gets exhausted or fragmented so that these apps cannot start and a reboot is required.

See the OS/2 voice article : http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html

cytan
Title: Re: New kernel
Post by: Saijin_Naib on 2008.11.08, 00:58:23
I vote for shared memory and Resolution/Bit-depth changes. That is insanely important especially on laptops or other computers where you hook up an external display for use on a projector.
Title: Re: New kernel
Post by: RobertM on 2008.11.08, 01:07:04
Quote from: Saijin_Naib on 2008.11.08, 00:58:23
I vote for shared memory and Resolution/Bit-depth changes. That is insanely important especially on laptops or other computers where you hook up an external display for use on a projector.

Hi Saijin/all,

I just posted this elsewhere in a slightly divergent topic - but it fits this category better:


Regarding the kernel (from http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html)...

"The kernel itself could address 64 terabytes of virtual memory. For instance to keep track of the virtual memory usage of the other protected mode processes that were not active. But this is not visible to the protected mode programs' virtual memory world. They experience their 4 GiB world as all there is. Unless they use some special kernel APIs like Theseus."

So, apparently, not just can the existing kernel see 64 terabytes, but programs calling those kernel APIs can as well.

Hmmm..... this article seems to confirm what I read on EDM/2 a while back.


Question is, what does that mean for the current kernel? Are those APIs usable for general-use type programming? And does that explain how OS/2 seems to map hardware (at least on my machine) outside of the 4GB arena?


Robert
Title: Re: New kernel
Post by: miturbide on 2008.11.08, 04:13:47
To be open source will be great. (or at least that the source code can be available too). I will be a tragedy that a new kernel could turn into abandonware in the future since it is proprietary.
Title: Re: New kernel
Post by: The Blue Warper on 2008.11.08, 12:07:11
Hi all!

AAA, IIRC, you usually report development news related to the OSfree project.  They're working very hard, as it seems.  So I'd like to thank them for all the efforts they're putting into this huge project.

As for my wishes, well, I have a not-so-short list of them.  But as we (actually, OSFree Team...) are in an earlier stage, I'd try to keep it short.
So, these are my wishes (not necessarily in the following order):

1) Fixing the SIQ problem at last.  I wonder why this wish wasn't mentioned in any of the previous posts...  Yes, Warp4 FP15 is more stable than Warp4 GA, and eCS is in general more stable than Warp4 FP15 (never had IBM OS/2 Warp 4.52 (MCP) though).  But we should get rid of this somehow.  I once read this shouldn't be too hard to fix or implement.
2) Providing a sort of Hardware Abstraction Layer.  This could result in the long term in better performance of the hardware sub-systems: video, audio, CPU, ACPI and so on.  AFAIK, the PSD-approach that IBM followed in its OS/2 server releases (and eventually in the desktop clients) looked like a sort of HAL.
3) The ability to restart PM (Presentation Manager) without rebooting.
4) Implementing in the kernel callings to the newer instruction sets that both Intel and AMD introduced in their CPUs after the Pentium era.
5) Compiling the kernel for CPU architectures newer than Intel 386...  I'd say Pentium architecture as a minimum.  Yes, I know the OS/2 kernel was thoroughly 'hand-written' around the 386 architecture, by extensively using assembly code.  But, as the new kernel should be compiled nonetheless, and this could result into losing some of the code optimizations that IBM put into the kernel at that time, why don't try to compile the new kernel with the CPU optimizations switches?  OSfree OS2LDR required a Pentium CPU architecture after all, so chances are that they'll enter this path for the kernel too.
6) As for memory management, a better way of handling the memory, by giving apps the space they need, would be fine.  But what RobertM said about "64 terabytes of virtual memory" is potentially significant, so OS/2 kernel might in fact be, in a certain way, ready for this memory amount.
7) Kernel-side support for hibernation (this is especially useful for notebooks).

These are OS/2 kernel areas where I'd personally wish to see some improvements.  They are not the only improvements possible (and I surely agree with what was said earlier in the other posts), but I think they're worth to be taken into consideration by the developers.
Although I'd say that for now the best thing that could happen to the OS/2 kernel is that it is being developed again.
My best wishes for your efforts!
Title: Re: New kernel
Post by: Fahrvenugen on 2008.11.08, 20:11:44
Did I miss something?  I don't recall reading anywhere about a new kernel being developped, other then the efforts of OSFree and (possibly) Voyager.

The only recent thing I saw was that eCS 2.0 RC6 would come with the SMP kernel, but the SMP kernel has been available for a while now.
Title: Re: New kernel; K42?
Post by: BigWarpGuy on 2008.11.08, 21:27:14
Would K42 from IBM be considered a new kernel?
Title: Re: New kernel
Post by: mobybrick on 2008.11.10, 11:47:32
Hi,

It's great to even think that there are those who are working hard on this to improve the OS for everyone.

I think we should be realistic and hopeful at the same time. There are, however, IMHO a number of important improvements that would be good to see to start with:

1. Support for power management/cool-n-quiet/CPU throttling across all ranges of new CPUs, chipsets and kernel types.
2. Improved assistance in the kernel for ACPI + VPIC support

Thereafter, second priority things should IMHO be:

3. Support for PAE and booting and using memory >4Gb
4. Enhanced shared memory support (moving more stuff to high memory) so that systems with large amounts of RAM can use it more

Longer term, new things will become important:

5. Support for IFS >2Tb (will need updates to IFS, DMDs and kernel)
6. 64-bit execution support (will mean elimination of all remaining 16-bit code in the kernel, IFSs and networking!)

But I don't yet see how these things will be achieved without access to the kernel source and documentation. But I'd love to be proved wrong!!

Regards,
Moby
Title: Re: New kernel
Post by: jjurban on 2008.11.10, 13:55:41
I'd like to see an expansion of "shared memory" available to users.  I'd like to see settings in CONFIG.SYS which can set the limits on shared memory.

My Object Rexx programs (as well as Chuck McGinnes's eCS maintenance Tool) crashes with SYS3175 in Rexx.dll.  I think it's because of shared memory limitations.

John


Title: Re: New kernel
Post by: warpcafe on 2008.11.10, 21:38:23
Hi all,

I agree with Fahrvenugen... and I am quite shocked to see that apparently nobody has asked before posting their wishes: Where have you got this information from, AAA ?

Cheers,
Thomas
Title: Re: New kernel
Post by: RobertM on 2008.11.10, 22:06:51
Quote from: jjurban on 2008.11.10, 13:55:41
I'd like to see an expansion of "shared memory" available to users.  I'd like to see settings in CONFIG.SYS which can set the limits on shared memory.

My Object Rexx programs (as well as Chuck McGinnes's eCS maintenance Tool) crashes with SYS3175 in Rexx.dll.  I think it's because of shared memory limitations.

John

John,

That actually seems to be a horrendous memory leak/bug in oREXX. A while back I discussed it with Serenity, and they were considering implementing the "solution" I had suggested until oREXX could be fixed.

That "solution" is simple. Downgrade oREXX to the earlier version on Hobbes. Same functionality (ie: the new calls), much slower memory issues.


I can replicate what you are describing with the version of oREXX that came with eCS v1.2MR using a very small amount of memory (large use of stems will cause it in no time, while not having used very much memory at all) - while the same code (1) runs far faster in cREXX, and (2) has never crashed. Under the earlier version of oREXX on Hobbes, the code is much more stable, and instead of crashing the REXX dll in a few minutes, can last days or weeks (but still eventually gets to that point) - which seems to indicate a big leak.

I am pretty sure of that because, each REXX program is simply a web server script, that gets loaded and exited. When I ran them separately from the commandline and closed the commandline and reopened, there was still a certain amount (of ever increasing) memory that was not freed - which eventually leads to the REXX dll crashing. Minutes to hours on the current version... days on the older one from Hobbes. Thus again, I suspect part of the issue is a memory leak (and worse, in the case of the oREXX that came with eCS 1.2) in that ever so critical memory arena.

Robert
Title: Re: New kernel
Post by: mobybrick on 2008.11.11, 01:09:47
I think that is because 'AAA' posted here about the replacement OS2LDR before it became officially available, and some of us suspect that 'AAA' is the name of a Russian developer by the name of Pavel.

Let's hope, anyway!

Regards,
Moby.

Quote from: warpcafe on 2008.11.10, 21:38:23
Hi all,

I agree with Fahrvenugen... and I am quite shocked to see that apparently nobody has asked before posting their wishes: Where have you got this information from, AAA ?

Cheers,
Thomas
Title: Re: New kernel
Post by: mobybrick on 2008.11.11, 19:47:38
Thinking about it, another new feature (probably as longer term) would be an INI file on the boot drive that contains extensions to the PATH, LIBPATH statements and any other settings you want to set.

A command could then be issued to ask the kernel to re-read this INI file, and append the values contained within to the settings held within CONFIG.SYS for all *new* processes that are started (changing the PSP of processes already running would be dangerous) - although obviously the changes to PATH and LIBPATH would need to be reflected in all DosExecPgm and WinLoad... calls straight away.

This would allow new apps to be installed without the need for re-boots - one of the weaknesses that OS/2 has lived with since the beginning.

Of course, using Run!, sometimes this issue can be worked around - but for others, not being able to install apps without a reboot is a right pain IMHO.

Regards,
Moby
Title: Re: New kernel
Post by: Criguada on 2008.11.13, 00:40:38
I vote for being able to kill those nasty unkillable processes (you know... the "exiting thread 1" issue).

Bye
Cris
Title: Re: New kernel
Post by: Criguada on 2008.11.13, 00:44:54
Hi Blue Warper!

Quote from: The Blue Warper on 2008.11.08, 12:07:11
1) Fixing the SIQ problem at last.  I wonder why this wish wasn't mentioned in any of the previous posts...  Yes, Warp4 FP15 is more stable than Warp4 GA, and eCS is in general more stable than Warp4 FP15 (never had IBM OS/2 Warp 4.52 (MCP) though).  But we should get rid of this somehow.  I once read this shouldn't be too hard to fix or implement.

This is not a problem in the kernel. It can't be fixed in the kernel. And BTW, I haven't seen a SIQ problem in years. A lot of ppl are confusing this issue with the "unkillable process" issue.

Quote from: The Blue Warper on 2008.11.08, 12:07:11
3) The ability to restart PM (Presentation Manager) without rebooting.

Again this is not a problem in the kernel

Quote from: The Blue Warper on 2008.11.08, 12:07:11
My best wishes for your efforts!

I agree with the rest of the points made!

Bye
Cris
Title: Re: New kernel
Post by: Blonde Guy on 2008.11.13, 02:55:25
Right now, the PATH is limited to 1024 chars before OS/2 starts to have problems. Either fix the problems, or truncate the PATH.
Title: Re: New kernel
Post by: AAA on 2008.12.14, 12:42:50
If somebody want to test ftp://Linking to this site is not permitted on our forums/os2krnlSVN1009.zip ;)
Title: Re: New kernel
Post by: chennecke on 2008.12.14, 13:18:21
This sure looks interesting.

Could you tell us a bit about the technical background? Depending on how this was done, I'm afraid of license issues that would unfortunately make using this nice piece of work a no-go for many people.
Title: Re: New kernel
Post by: mobybrick on 2008.12.14, 16:00:03
If we're all licensed OS/2 or eCS users, what is the no-go problem?

Thanks,
Moby
Title: Re: New kernel
Post by: chennecke on 2008.12.14, 17:34:46
Quote from: mobybrick on 2008.12.14, 16:00:03
If we're all licensed OS/2 or eCS users, what is the no-go problem?

If the new kernel is based on leaked source code, it's illegal to use it.
Title: Re: New kernel
Post by: mobybrick on 2008.12.14, 18:41:54
Quote from: chennecke on 2008.12.14, 17:34:46
Quote from: mobybrick on 2008.12.14, 16:00:03
If we're all licensed OS/2 or eCS users, what is the no-go problem?

If the new kernel is based on leaked source code, it's illegal to use it.

Let's hope that this is not the case. As I see it, there are three possible ways this might have been done:-

1. Access to the original source code. Parts of the original W4 source code was leaked once apparently - but this kernel is light years away from the 104a kernel this OS4kernel claims to be compatible with.

2. A new kernel re-written from scratch. But this is a huge feat and is unlikely - you simply wouldn't build a new kernel with all of the 'old' bugs - which according to the readme still need to be removed with legacy code cleanup.

3. A reverse engineer or decompile - theoretically possible with enough computing power, the debug kernel and the symbol files.

It is also theoretically possible to perform binary patching of the existing kernel, with no access to the source code - but there would be limits as to what could be modified - and the readme to this project does have a source code that it is using.

Any use of illegally obtained source code would render the files commercially and morally useless, at least. What worries me is that the source code for this newly built kernel is closed source - do the authors have something to hide?

Let's hope AAA can put our minds at rest. The work to pre-load critical boot files for AMD chipset ACPI support looks fantastic. If they can fix some of the other urgent problems, such as the 32-bit-only LBA boot support (which may also need changes to OS2DASD.DMD), then that would be brilliant.

Regards,
Moby.
Title: Re: New kernel
Post by: RobertM on 2008.12.14, 21:54:56
Quote from: mobybrick on 2008.12.14, 18:41:54
...

Any use of illegally obtained source code would render the files commercially and morally useless, at least. What worries me is that the source code for this newly built kernel is closed source - do the authors have something to hide?
...


One possibility is it's for an official IBM sanctioned project (ie: perhaps to fill a business requirement of one of their customers), and thus the requirement for everyone to have a copy of eCS/Warp to use it (ie: may not be just a technical reason). It wouldn't be the first project paid for by some IBM customer that IBM and/or others had a hand in writing/fixing/completing and then was subsequently released as an update...

As you said, hopefully we will get clarification at some point. Though, it is also quite possible that for contractual reasons, we wont at this point.

Rob
Title: Re: New kernel (realy legal ?)
Post by: rwklein on 2008.12.15, 00:48:36
With my technicall skill set I'm having real doubts if this kernel is legal. And it would certainly be usefull if they would clarify that.
But I have a very hard time believing that based on DDK code they wrote this kernel and that for first time it works so good.

Besides this its a debug kernel from IBM it seems:

I find this in kernel:

- set COM baud rate/port addr (1 = COM1, 2 = COM2) and more stuff you  get to see in PMDF when you use the kernel debugger. So thats very good kernel to even release for testing (unless the disabled the code). But when you load a debug kernel and it finds and INT 3 it will wait to jump to the seriel port specified in KDB.INI.

Title: Re: New kernel
Post by: Pete on 2008.12.15, 03:12:34
Quote from: AAA on 2008.12.14, 12:42:50
If somebody want to test ftp://Linking to this site is not permitted on our forums/os2krnlSVN1009.zip ;)


Hi AAA

While everyone else is discussing the legality I have downloaded and installed the kernel package.

Seems fairly stable and has not caused any problems in the 6 or so hours it has been in use.

If you want a log sent somewhere then it might be an idea if the url existed; I tried the url in the krnl_en.txt file  http://Linking to this site is not permitted on our forums/tracker/ and got a 404 - probably in Russian.

Keep up the good work

Pete

Title: Re: New kernel
Post by: lpino on 2008.12.15, 22:09:31
This is great news. I hope they continue their work on the updated kernel (it's not really a new kernel). Probably this is just the tip of the iceberg because one thing is to have the source and another is to be able to compile it. Consider all the dependencies, tools and missing parts, it would be like the movie "Jurasic Park", trying to put together the DNA sequence of an extinct dinasour (only on this case is a piece of software).

Well I hope this is the begining of something,,, whatever,, but something :)
Title: Re: New kernel
Post by: djcaetano on 2008.12.16, 15:11:32
Quote from: AAA on 2008.12.14, 12:42:50
If somebody want to test ftp://Linking to this site is not permitted on our forums/os2krnlSVN1009.zip ;)

  These are great news!
  I tested the new kernel, but my results are not-so-good.
  First of all, I would like to tell I am running eCS RC4 using SMP mode, in a Core2Quad machine, 2GB of RAM. The motherboard is a GA-G31M-S2L. I am using Panorama with the onboard Intel video. Network is an RTL8139.
  Also, I would like to tell eCS RC4 kernel usually hangs on boot, just before it executes the RUN statements. After some resets (three or four, usually) it boots ok.
  Well, the behavior with this new kernel is pretty much the same, besides the fact it *always* hangs in that place, no matter what.

  I was only able to boot to command line, where RTL8139 driver is not loaded, but I have not checked if it is the faulty one. I will do the test right now.

***UPDATE***

  I tested the system without RTL8139 driver, but the results were the same. Tried removing several drivers... but it was a no-go.
  Removing the "SMP" parameter on ACPI.PSD (causing the system to boot using only one processor, but still using SMP doscall1), the system boot "ok", but when I loaded OpenChat/2... the system hung... which is not normal. OC/2 has know problems when running which more than one processor (it will not always open without generating a SYS3175), but never presented any problems running on single processor (even with SMP kernels).
   Just to complete the system description, each core is running at 2.4GHz, and I am running ACPI 3.11 and APM 1.26 (they are somewhat old, but software subscription has ended and I had not updated it yet.

*** UPDATE2 ***
 
   I was just thinking... it would be nice to move some Kernel configuration parameters from CONFIG.SYS to OS4KRNL.INI, such as CLOCKSCALE, BUFFERS, EARLYMEMINIT...
Title: Re: New kernel
Post by: Raiko on 2008.12.16, 15:54:49
It seems to run fine on my system. RC6a, acpi 3.14, Core2Quad and Panorama.
Title: Re: New kernel
Post by: osw on 2008.12.16, 17:10:43
Hi!

I did install. Works ok. It also seems faster to load than 104a.
There are some new things mentioned in attached txt's, as well as fixes. So it is new thing.
Good work.

Title: Re: New kernel
Post by: djcaetano on 2008.12.16, 23:34:12
Quote from: Raiko on 2008.12.16, 15:54:49
It seems to run fine on my system. RC6a, acpi 3.14, Core2Quad and Panorama.

  Please, test if OpenChat/2 works.
  It (somewhat) works on IBM's SMP kernel. I got a bad hang state running it
on OS/4 kernel in two different machines. The first was the one I mentioned before...
And now I have tested it here, in my home machine (nForce2 chipset, Athlon XP 2600+;
running Warp ACP2 - 4.52) with the same result (running SMP DOSCALL1.DLL
and OS/4 Kernel). Replacing OS/4 Kernel with IBM OS/2 14.104a SMP kernel and
than running OpenChat/2 worked well*.

  It seems OS/4 kernel has some kind of "downgrade" which prevents OpenChat/2
from running.

Links to download openchat** + gemz:
http://hobbes.nmsu.edu/download/pub/os2/apps/internet/irc/client/ochat107.zip
http://hobbes.nmsu.edu/download/pub/os2/apps/internet/irc/script/gz-312a.zip

(*) Running SMP kernel on a single core machine is somewhat stupid and is not
as good as running UNI kernel. I did it only as a test.
(**) I am using OpenChat/2 1.08, but it is not available at Hobbes. I don't know
the reason. But I do not believe the result running 1.07 will be different from
running 1.08.
Title: Re: New kernel
Post by: Joachim on 2008.12.17, 00:47:59
Quote from: djcaetano on 2008.12.16, 23:34:12

  Please, test if OpenChat/2 works.


Since I added the following line to my config.sys I have had no more issues running OpenChat/2:

DLLBASING=ON

This is what configtool (http://www.os2world.com/goran/cfgtool/cfgdat05.htm) has on it:

==
The dllbasing parameter prevents fragmentation of the shared environment, allowing more efficient use of virtual memory. The dllbasing parameter may be set to ON or to OFF. If dllbasing is set to ON, then the system will attempt to honor the base addresses (preferred load addresses) for DLLs. Honoring base addresses for DLLs is preferred because it improves system performance for loading DLLs. However, sometimes there is an interaction between the DLL basing and an application's memory usage which will cause the system to run out of private memory. In this case, you should set dllbasing to OFF so that the system will ignore base addresses for DLLs. The system performance for loading DLLs may degread marginally, but there will be more free private memory.
==

Regards,

Joachim
Title: Re: New kernel
Post by: DavidG on 2008.12.17, 04:41:08
The new kernel works fine on my system (eCS 2 rc6).  However, with both the ethernet card driver and the genmac drivers loaded, I was unable to access the internet.  However, since the Genmac driver has never worked on my machine, I removed its driver and rebooted and I have internet access back.

David
Title: Re: New kernel
Post by: djcaetano on 2008.12.17, 14:31:26

  Hi Joachim,

Quote from: Joachim on 2008.12.17, 00:47:59
Since I added the following line to my config.sys I have had no more issues running OpenChat/2:
DLLBASING=ON

  Humm... I added DLLBASING=ON in my config.sys and it seems there
were some improvements (since OpenChat/2 trapped a little less
on IBM SMP Kernel), but no changes using OS/4 Kernel running with
SMP detection disabled on ACPI: a complete hang (no messages,
nothing... the system just freezes).

   Also, no changes on using SMP and OS/4 Kernel: enabling SMP
detection on ACPI caused the system to freeze when starting to
process the RUN statements of CONFIG.SYS.

   Anyway, thanks for you and for those working on this binary
kernel patch (as described on readme).
Title: Re: New kernel
Post by: osw on 2008.12.17, 15:47:00
hi!

djcaetano wrote "....(*) Running SMP kernel on a single core machine is somewhat stupid and is not
as good as running UNI kernel. I did it only as a test..."

well, it's not that stupid given the fact uni kernels are smp kernels with fixed number of processors set to 1...
so, I'm sitting here on single core of somewhat aging celeron 2.2ghz (northwood) which has turn out to be smp capable...
at least to os2 acpi subsystem routines (i saw this indication first time on ecs rc4 in acpi wizard - so no waiting a while i did install smp kernel and to my surprise everything worked like a charm) of course acpi needed smp switch as well apic  and cd (crazy devices) on. Once I did it I've never experience no problems from kernel. When I did install ecs rc5 the acpi wizard detected my system as non-smp capable... so I had to install smp kernel manually... and again not a single problem from kernel on boot...(genmac here with 3com905c, sblive! on sander driver 0.8.2 (smp capable), scitech snap driving radeon 9600)

Another interesting fact regarding kernel is in newer builds of ecs (rc6 and up - that needs checking I'm still on rc5) there will be smp kernel installed as default... on single core initializing 1 processor... so no more mess with doscall1.dll for both types of kernel.
That's attitude is not stupid at all, as you may wish to carry your harddisk to another machine with more cores than one - and you will have working system out of the box.
So my system was prepared and adjusted to sport smp kernel when I was trying the "new" one from os/4 - and no surprises what did work still do works. So dig a little more in acpi details as there might be a cue. Another thing is if openchat does run on smp kernel at all...   

bye
Title: Re: New kernel
Post by: osw on 2008.12.17, 16:28:10
hi! it's me again

after a short brake during which I tried whether openchat/2 will run... and it won't. It hung my system badly (hard reset was in use...)
After that I did look at \ecs\DOC\ACPI\ACPI_SMP_SOFT.doc and it contains...

#
Applications ready for SMP:

* OpenChat/2 traps sometimes
* PSI/2 running irc-plugin freezes computer periodically
#

Despite it reads "ready for smp" obviously there are not.
So now it looks like it won't be stable on original smp kernel too.

btw. I'm not on irc at all (I used to... but all my buddies switched to different communicators since)
anyway openchat/2 (I have  managed to grab a 1.08...) is over 8 years old...

bye
Title: Re: New kernel
Post by: djcaetano on 2008.12.17, 16:36:57
Quote from: osw on 2008.12.17, 15:47:00
djcaetano wrote "....(*) Running SMP kernel on a single core machine is somewhat stupid and is not
as good as running UNI kernel. I did it only as a test..."
...
well, it's not that stupid given the fact uni kernels are smp kernels with fixed number of processors set to 1...

  Humm... I don't believe so. If that were the case, it was just a matter of letting SMP kernel
detect only one processor and "that's all folks".
  In my experience along the years, I noticed performance problems when using SMP kernel
instead of UNI kernel (on a single-core machine). The most noticeable was achieved when
playing MP3 with Z! and using FireFox. Whenever a webpage "eats" 100% of CPU power,
the music being played by Z! stops until FireFox release some CPU power. This is not
what happens when using UNI (or even W4) kernel.
  I believe some scheduler rules are different on SMP kernel, optimized for two or more CPUs,
while UNI kernel scheduler rules are optimized for a single CPU.

  This thought is also based in my knowledge about operating systems internals and
based on what most IBM engineers said about OS/2 kernels along the history...
   ...and of course, because I do not believe IBM would spent time, money and workers
to develop and maintain two (or three) different kernels if they were all the same. :D

Quote from: osw on 2008.12.17, 15:47:00
so, I'm sitting here on single core of somewhat aging celeron 2.2ghz (northwood) which has turn out to be smp capable...
at least to os2 acpi subsystem routines (i saw this indication first time on ecs rc4 in acpi wizard - so no waiting a while i did install smp kernel and to my surprise everything worked like a charm) of course acpi needed smp switch as well apic  and cd (crazy devices) on. Once I did it I've never experience no problems from kernel. When I did install ecs rc5 the acpi wizard detected my system as non-smp capable... so I had to install smp kernel manually... and again not a single problem from kernel on boot...(genmac here with 3com905c, sblive! on sander driver 0.8.2 (smp capable), scitech snap driving radeon 9600)

  IBM's SMP kernel work ok on my single core machine (at home), despite these little
performance problems. Besides that, not a single problem arises.  ::)

Quote from: osw on 2008.12.17, 15:47:00
Another interesting fact regarding kernel is in newer builds of ecs (rc6 and up - that needs checking I'm still on rc5) there will be smp kernel installed as default... on single core initializing 1 processor... so no more mess with doscall1.dll for both types of kernel.
That's attitude is not stupid at all, as you may wish to carry your harddisk to another machine with more cores than one - and you will have working system out of the box.
So my system was prepared and adjusted to sport smp kernel when I was trying the "new" one from os/4 - and no surprises what did work still do works. So dig a little more in acpi details as there might be a cue. Another thing is if openchat does run on smp kernel at all...   

  Well, I believe that eCS should use SMP kernel only when multi-core is available,
but I understand that some reasons may lead Serenity to adopt only one version
of the kernel - in this case, the SMP one:

   a) It is easier and cheaper to maintain only one system configuration.
   b) SMP kernel runs on single-core CPUs.
   c) SMP kernel allows multi-core CPUs.
   d) ACPI seems to be happier about SMP kernel.
   e) Most computers sold nowadays are multi-core.
   f) Those unhappy with SMP can always switch to (maybe unsupported) UNI kernel.

  But, after all, what I am trying to say is:

  * At home (single core, ACP2) I do not run ACPI at all. OpenChat/2 works with W4, UNI and SMP kernels from IBM. OpenChat/2 hangs the system with OS/4 Kernel.
  * At work (quad core, eCSRC4 updated with elements of RC5) I run ACPI. OpenChat/2 works with W4, UNI and SMP, both in single core mode and multi-core mode. OpenChat/2 hangs the system with OS/4 Kernel.

   This can be translated as: "there is something weird on the patch applied to the SMP kernel", and I did tests to say that. The problem arises on two completely different machines with two completely different OS/2 setups, causing exactly the same behavior which is not desirable: a system hang when running a 100% ring 3 application.  :o

   Note: I am not saying there is a general protection fault (SYS3175) or any kind of error message: it is a complete hang situation. The system simply stops... not even pings are replied after the hang.  :-[

  I just mentioned this problem here because I think it is a relevant report. I do not complained at the site suggested in the readme for two reasons:

  a) The page returns 404 error
  b) The site is written entirely in russian language
 
  Anyway, I welcome any suggestions to try to avoid or correct something to make the system runs nicely (such as the good DLLBASING tip). :)
Title: Re: New kernel
Post by: osw on 2008.12.17, 18:49:44
hi!

djcaetano wrote:
(...)
  But, after all, what I am trying to say is:

  * At home (single core, ACP2) I do not run ACPI at all. OpenChat/2 works with W4, UNI and SMP kernels from IBM. OpenChat/2 hangs the system with OS/4 Kernel.

  * At work (quad core, eCSRC4 updated with elements of RC5) I run ACPI. OpenChat/2 works with W4, UNI and SMP, both in single core mode and multi-core mode. OpenChat/2 hangs the system with OS/4 Kernel.
(...)

How do you run smp kernel on singlecore with no acpi?
As I'm doing it only because acpi does...
btw. I think (but not sure, it hit my eyes in some docs) the recent releases of ecs2 come with slightly modified (i.e different) kernels - to work better,or obviously just work, with acpi - so they are no longer original ibm kernels from acp2...

Perhaps you will find it interesting what the attached to os/4 kernel doc says.

about kernel:
...Please use the OS/4 kernel with its new loader OS2LDR only, otherwise
the correct booting is not expected....

and about loader
...ACPI less than 3.7 may not work with OS2LDR (CB)

So it looks you must install acpi 3.7 at least to expect success with the os/4. 
Another thing is a fact that openchat/2 freezes my systems which meets all requirements. Why? No idea. But how can you see that program was on suspicious_list, at least to acpi_smp  developers, so it has impose some troubles in the past.

You wrote:
...It seems OS/4 kernel has some kind of "downgrade" which prevents OpenChat/2
from running...

Yes it might be the reason, but as long as the problem is only with openchat/2 - it is meaningless.
This downgrade can be also simply getting off some dirty_patches  or some undocumented stuff from ibm.
It might be also that openchat/2 use some dirty hacks... 

Anyway, to me such issues with backward compatibility are "normal" and are acceptable price for having kernel developed again after rather long brake. (the last official from ibm are over 3 years old....)

bye
Title: Re: New kernel
Post by: osw on 2008.12.17, 23:15:07
Hi! Once again (hope last one in that matter...)
djcaetano wrote:
(...)
  Humm... I don't believe so. If that were the case, it was just a matter of letting SMP kernel
detect only one processor and "that's all folks".
  In my experience along the years, I noticed performance problems when using SMP kernel
instead of UNI kernel (on a single-core machine). The most noticeable was achieved when
playing MP3 with Z! and using FireFox. Whenever a webpage "eats" 100% of CPU power,
the music being played by Z! stops until FireFox release some CPU power. This is not
what happens when using UNI (or even W4) kernel.
  I believe some scheduler rules are different on SMP kernel, optimized for two or more CPUs,
while UNI kernel scheduler rules are optimized for a single CPU.

  This thought is also based in my knowledge about operating systems internals and
based on what most IBM engineers said about OS/2 kernels along the history...
   ...and of course, because I do not believe IBM would spent time, money and workers
to develop and maintain two (or three) different kernels if they were all the same. Cheesy
(...)

Not to question your skills nor knowledge but to feed my curiousity monkey i dug a little with google
and found such info:
(...)
September 19, 2001 - On comp.os.os2.apps, Holger Veit finally tells us what the difference is between the Uni and W4 kernels that we see released from time to time on IBM's testcase site:

    Actually, there is only a single difference between W4 and UNI: Uni has the DosSetThreadAffinity (sp?) API implemented (which allows to associate a thread to a processor), while W4 returns 'invalid function'. This is a method to find out which kernel you have. Of course, since UNI is SMP for a single CPU only--a contradiction in terms, obviously--you won't be able to use this API really; but at least it will allow software which was specifically designed for SMP to run on a single CPU.
(...)

Just to close thread.

ps. still I'm very curious how did you use smp kernel on single core on pre acpi system?
will you give me a chance to enhance MY knowledge?

greetings osw

Title: Re: New kernel
Post by: djcaetano on 2008.12.18, 02:00:20
 
  Hi!

Quote from: osw on 2008.12.17, 18:49:44
How do you run smp kernel on singlecore with no acpi?

 There is nothing special about it. If you simply install SMP DOSCALL1.DLL,
SMP kernel and the loader that comes with SMP kernel, it will run (at least
on OS/2 versions 4.52 and above).  8)
  BTW, if UNI is really a "fixed" SMP for single processor, why one have
to exchange DOSCALL1.DLL to use SMP kernel? And why DOSCALL1.DLL
for SMP doesn't work with UNI kernel? ???
  (I am not talking about W4 kernel, which I abandoned a long time ago)

Quote from: osw on 2008.12.17, 18:49:44
btw. I think (but not sure, it hit my eyes in some docs) the recent releases of ecs2 come with slightly modified (i.e different) kernels - to work better,or obviously just work, with acpi - so they are no longer original ibm kernels from acp2...

 Well, OpenChat/2 worked with ACP2 SMP kernel (on ACP) and with
eCS 2.0 RC5 SMP kernel (on eCS).

Quote from: osw on 2008.12.17, 18:49:44
...Please use the OS/4 kernel with its new loader OS2LDR only, otherwise
the correct booting is not expected....
and about loader
...ACPI less than 3.7 may not work with OS2LDR (CB)
So it looks you must install acpi 3.7 at least to expect success with the os/4. 

 I had read and re-read the readmes. In fact, I always read and re-read every
doc before testing those things. :)
  I don't know if the new loader and kernel work with with ACPI 3.7 or
older... but it certainly work NOT using ACPI... but the only proof I have
about it is the fact I was able to run it here. :)
  In my single core machine It is able to boot UNI, SMP and OS/4 kernels.  :)

  But the problem I mentioned about openchat exists even using ACPI 3.11 (on
eCS, with multicore CPU running as single core, since I was not able to finish
the boot on multicore mode).
 It seems the problem is not on the loader, but probably with the patch on OS/4
kernel, which fails in a specific situation on two completely different machines
and OS/2 configurations (three, after your test). It should *run* or *not run*
OpenChat/2..., but never freeze and hang.  :-\

Quote from: osw on 2008.12.17, 18:49:44
Another thing is a fact that openchat/2 freezes my systems which meets all requirements. Why? No idea. But how can you see that program was on suspicious_list, at least to acpi_smp  developers, so it has impose some troubles in the past.

 On previous SMP kernels OpenChat/2 sometimes report an error upon loading and
is closed by the operating system. This is the behavior I would expect... not a
"system freeze" behavior.  :o

Quote from: osw on 2008.12.17, 18:49:44
Yes it might be the reason, but as long as the problem is only with openchat/2 - it is meaningless.
This downgrade can be also simply getting off some dirty_patches  or some undocumented stuff from ibm.
It might be also that openchat/2 use some dirty hacks... 
Anyway, to me such issues with backward compatibility are "normal" and are acceptable price for having kernel developed again after rather long brake. (the last official from ibm are over 3 years old....)

 I am not criticizing the new kernel, I am trying to help it to evolve.
 About being meaningless, I do not think it is meaningless when a ring 3 app can freeze the
entire Operating System, no mater what "dirty tricks" it does, no mater how few people uses
this application. It is kernel's job to configure the CPU environment so an application
cannot freeze the system this way.  ::)

  The system has to resist even when applications are miserably programmed. This is
the core of "memory protection" feature. :D
Title: Re: New kernel
Post by: Pete on 2008.12.18, 04:51:02
Hi djcaetano

You state earlier in this thread "Also, no changes on using SMP and OS/4 Kernel: enabling SMP
detection on ACPI caused the system to freeze when starting to process the RUN statements of CONFIG.SYS."

Can I ask what switches were in use on the PSD= line? and also what mainboard chipset is involved?

Might also be worth checking exactly where the system gets stuck... do you have an empty text file called ALTF2ON.$$$ in the root directory of your boot drive?  If not create 1 with a text editor - simply save an empty file to that drive:\path\filename - and see if that helps identify where the boot stops.

I also note that you are using ACPI v3.11 - might be worth updating that to v3.14 (the latest, v3.7 is awhile away I think :-)

Regards

Pete
Title: Re: New kernel
Post by: rwklein on 2008.12.18, 13:39:34
Quote from: djcaetano on 2008.12.17, 16:36:57
Quote from: osw on 2008.12.17, 15:47:00
djcaetano wrote "....(*) Running SMP kernel on a single core machine is somewhat stupid and is not
as good as running UNI kernel. I did it only as a test..."
...
well, it's not that stupid given the fact uni kernels are smp kernels with fixed number of processors set to 1...

  * At home (single core, ACP2) I do not run ACPI at all. OpenChat/2 works with W4, UNI and SMP kernels from IBM. OpenChat/2 hangs the system with OS/4 Kernel.
  * At work (quad core, eCSRC4 updated with elements of RC5) I run ACPI. OpenChat/2 works with W4, UNI and SMP, both in single core mode and multi-core mode. OpenChat/2 hangs the system with OS/4 Kernel.

   This can be translated as: "there is something weird on the patch applied to the SMP kernel", and I did tests to say that. The problem arises on two completely different machines with two completely different OS/2 setups, causing exactly the same behavior which is not desirable: a system hang when running a 100% ring 3 application.  :o

   Note: I am not saying there is a general protection fault (SYS3175) or any kind of error message: it is a complete hang situation. The system simply stops... not even pings are replied after the hang.  :-[

  I just mentioned this problem here because I think it is a relevant report. I do not complained at the site suggested in the readme for two reasons:

  a) The page returns 404 error
  b) The site is written entirely in russian language
 
  Anyway, I welcome any suggestions to try to avoid or correct something to make the system runs nicely (such as the good DLLBASING tip). :)


What they distributed was a patched 104a SMP kernel from IBM. Its a DEBUG kernel! This means when an application crashes the debugger inside the kernel kicks in (unless they patched that out some how).  The kernel is  trying to talk to the serial port. If you connect a serial cable to another system and run a terminal program like ZOC you will most likely get a debug prompt.

I could be wrong but basicly with every application crash your system seems to freeze. But the debug kernel is doing its job. Its just not documented in the docs this type of behavior.
So your system seems frozen...

In my view its also very silly to distribute a debug kernel to the general public. Its a debug kernel and it has a purpose. A debug kernel is clearly something you should not install on system "just as".

Roderick Klein
Title: Re: New kernel
Post by: djcaetano on 2008.12.18, 14:23:08

  Hi Pete,

Quote from: Pete on 2008.12.18, 04:51:02
Hi djcaetano
You state earlier in this thread "Also, no changes on using SMP and OS/4 Kernel: enabling SMP
detection on ACPI caused the system to freeze when starting to process the RUN statements of CONFIG.SYS."

  Just to clear my statement, using SMP with IBM's SMP kernel sometimes causes a freeze.
Using SMP with OS/4 SMP kernel always causes a freeze.

Quote from: Pete on 2008.12.18, 04:51:02
Can I ask what switches were in use on the PSD= line? and also what mainboard chipset is involved?

  No problem. My PSD line is:

  PSD=ACPI.PSD /SMP /APIC

  I had tested other parameters some months ago, but no luck. Any suggestions?
  The chipset is Intel G31 Express (north bridge) and Intel ICH7 (south bridge).

Quote from: Pete on 2008.12.18, 04:51:02
Might also be worth checking exactly where the system gets stuck... do you have an empty text file called ALTF2ON.$$$ in the root directory of your boot drive?  If not create 1 with a text editor - simply save an empty file to that drive:\path\filename - and see if that helps identify where the boot stops.

  Well, in fact I had already did this test. It freezes always in the moment it will execute the first RUN statement. I had already tried to change the order of previous statements and it freezes in the same place (on the first RUN statement). I modified the order of RUN lines on config.sys and the boot keeps freezing on the first RUN statement.
  I seems a problem related to the way RUN statement is processed by the kernel. Weird, huh?
  I'll do some more tests later. With OS/4 kernel it is easier to test, since it always hangs in that
place.

Quote from: Pete on 2008.12.18, 04:51:02
I also note that you are using ACPI v3.11 - might be worth updating that to v3.14 (the latest, v3.7 is awhile away I think :-)

   Yes, I have to renew the eCS "software subscription".
   Anyway, this boot-freeze problem is being a constant since earlier versions of ACPI, never changed a bit. And the freeze only happens when using SMP kernel. With UNI kernel the boot is always flawlessly completed.
   As soon as possible (probably next month) I will renew my subscription and test the new ACPI version.
Title: Re: New kernel
Post by: rwklein on 2008.12.18, 14:28:33
Quote from: jjurban on 2008.11.10, 13:55:41
I'd like to see an expansion of "shared memory" available to users.  I'd like to see settings in CONFIG.SYS which can set the limits on shared memory.

My Object Rexx programs (as well as Chuck McGinnes's eCS maintenance Tool) crashes with SYS3175 in Rexx.dll.  I think it's because of shared memory limitations.

John




What you are forgetting is that some these shared memory buffers are for legacy support. Some programs have certain sizes in address limits they can access. Increase the size break the old programs.

This is why virtual addresslimit has been introduced. And with special flags people can call access this memory. But from object rexx or plain rexx this can not be done.

And that memory leak you encounter with your application john, by loading it high will only prolong the memory leak for some time and then it will die of anyway again...

Roderick Klein
Title: Re: New kernel
Post by: djcaetano on 2008.12.18, 14:30:06
  Hi Roderick!

Quote from: rwklein on 2008.12.18, 13:39:34
What they distributed was a patched 104a SMP kernel from IBM. Its a DEBUG kernel! This means when an application crashes the debugger inside the kernel kicks in (unless they patched that out some how).  The kernel is  trying to talk to the serial port. If you connect a serial cable to another system and run a terminal program like ZOC you will most likely get a debug prompt.
I could be wrong but basicly with every application crash your system seems to freeze. But the debug kernel is doing its job. Its just not documented in the docs this type of behavior.
So your system seems frozen...
In my view its also very silly to distribute a debug kernel to the general public. Its a debug kernel and it has a purpose. A debug kernel is clearly something you should not install on system "just as".

 Oh, I know that debug kernel provides serial output, but never tried it myself... I didn't know about this "freeze" behavior.
 That means the readme should mention this, at least. But I agree with you: is a debug kernel has this behavior, I do not
see the point of releasing it, since it is not safe to be used on a daily basis.
 If the intent is testing the kernel in a "semi-production" situation, then the "release" version of the kernel would be the way.

  Thanks for this explanation.

 BTW, do you believe the freeze (not trap) in the boot process is the same situation? I ask this because that freeze sometimes happens even with IBM's release SMP kernel.
Title: Re: New kernel
Post by: Pete on 2008.12.18, 15:10:19
Hi djcaetano

Sorry, no experience of using ACPI with Intel chipsets - I was under the impression that most Intel chipsets worked OK with ACPI but there are obviously exceptions.

I have several systems based on nVidia chipsets, 1 * nForce430/MCP61 and 2* nForce4

These slightly different chipsets require different switches on the PSD= line.

nForce430/MCP61
PSD=ACPI.PSD /SMP /CD /TMR /APIC /!NOD

nForce4
PSD=ACPI.PSD /SMP /CD /APIC


I think my 1st suggestion would be to add the /!NOD switch to the PSD line there and see what happens. Might also be worth hunting through the ACPI docs to see if there is any mention of the chipsets involved.

Do you have the following line in your config.sys file?
EARLYMEMINIT=TRUE

If not it could be that 1 of the drivers when loading is overwriting an already loaded driver - I get problems with that on all the above systems using Uniaud audio drivers and nveth nic driver; the nic driver loads then Uniaud loads and the nic is not useable when the system is booted. REMming the uniaud lines means no audio but the nic works. Paul, 1 of the uniaud porters/developers, recommended the above line due to uniaud "driver bloat" and it cures the problem here.

My thinking is that maybe something in your Run section needs a driver that is no longer available but the system "thinks" it is and you end up with a freeze or hang.

Hope something in the above helps  :-)

Pete
Title: Re: New kernel
Post by: djcaetano on 2008.12.18, 15:58:54

  Hi again, Pete,

Quote from: Pete on 2008.12.18, 15:10:19
Sorry, no experience of using ACPI with Intel chipsets - I was under the impression that most Intel chipsets worked OK with ACPI but there are obviously exceptions.

  :(

Quote from: Pete on 2008.12.18, 15:10:19
I have several systems based on nVidia chipsets, 1 * nForce430/MCP61 and 2* nForce4
These slightly different chipsets require different switches on the PSD= line.
nForce430/MCP61
PSD=ACPI.PSD /SMP /CD /TMR /APIC /!NOD
nForce4
PSD=ACPI.PSD /SMP /CD /APIC
I think my 1st suggestion would be to add the /!NOD switch to the PSD line there and see what happens. Might also be worth hunting through the ACPI docs to see if there is any mention of the chipsets involved.

  No mention on this chipset (at least on the docs I had installed in this eCS RC4).
  But you pointed it correctly: /!NOD killed the "boot freeze" bug... I didn't noticed
it solved the problem before because this hang was not always observed on IBM's
SMP kernel, but since OS/4 always froze in the same place, I could notice the !NOD
effect.
  Now I have a new problem: with /!NOD my UniAud is not working correctly
anymore... it keeps repeating the first miliseconds of a sound, continuously. :(
If I can't fix this, I'll have to live with the boot hangs. :p

Quote from: Pete on 2008.12.18, 15:10:19
Do you have the following line in your config.sys file?
EARLYMEMINIT=TRUE

  Enabled it also, but alone had no effect.

Quote from: Pete on 2008.12.18, 15:10:19
Hope something in the above helps  :-)

  It helped a lot. At least, your and Roderick's posts cleared that the problems
presented on my computers (home and work) are not OS/4 kernel's fault, which
I believe it is a very good thing. :)
Title: Re: New kernel
Post by: pasha on 2008.12.18, 17:45:42
Quote from: djcaetano on 2008.12.18, 14:30:06
 Hi Roderick!

Quote from: rwklein on 2008.12.18, 13:39:34
What they distributed was a patched 104a SMP kernel from IBM. Its a DEBUG kernel! This means when an application crashes the debugger inside the kernel kicks in (unless they patched that out some how).  The kernel is  trying to talk to the serial port. If you connect a serial cable to another system and run a terminal program like ZOC you will most likely get a debug prompt.
I could be wrong but basicly with every application crash your system seems to freeze. But the debug kernel is doing its job. Its just not documented in the docs this type of behavior.
So your system seems frozen...
In my view its also very silly to distribute a debug kernel to the general public. Its a debug kernel and it has a purpose. A debug kernel is clearly something you should not install on system "just as".

 Oh, I know that debug kernel provides serial output, but never tried it myself... I didn't know about this "freeze" behavior.
 That means the readme should mention this, at least. But I agree with you: is a debug kernel has this behavior, I do not
see the point of releasing it, since it is not safe to be used on a daily basis.
 If the intent is testing the kernel in a "semi-production" situation, then the "release" version of the kernel would be the way.

  Thanks for this explanation.

 BTW, do you believe the freeze (not trap) in the boot process is the same situation? I ask this because that freeze sometimes happens even with IBM's release SMP kernel.

This kernel + loader can provide next output:

- to serial as IBM
- to screen/keyboard (don't ending keyboard)
- to other plugins for loader

See about "dbport" in os2ldr docs

Also you can create kdb.ini and place to it some string with letter g, for example:

g
g
g
g
g
g

This give you continue working with some crazy R3 application, OpenChat for example. About crazy and why you can see in kernel log (see in docs how give kernel log). Also check your config.sys for TRAPDUMP= setting. Must be TRAPDUMP=R0,xxx for user. And .... This is only beta and first beta ;-)

About speed. This fix is near with retail SMP kernel for speed.  And we are beleive it will be faster.
Title: Re: New kernel
Post by: djcaetano on 2008.12.18, 20:36:59

  Hi Pasha!

  First of all, thanks for your work and also for your answer to my questions. :)

Quote from: pasha on 2008.12.18, 17:45:42
This kernel + loader can provide next output:
- to serial as IBM
- to screen/keyboard (don't ending keyboard)
- to other plugins for loader
See about "dbport" in os2ldr docs

  Ah! :) I thought that config was about some kind of loader debug... no kernel
debug. :)
  I'll look for it soon.

Quote from: pasha on 2008.12.18, 17:45:42
Also you can create kdb.ini and place to it some string with letter g, for example:
This give you continue working with some crazy R3 application, OpenChat for example.

  I understood what to do, but I am not so sure about why... :p But I'll read more about
it on the readmes.

Quote from: pasha on 2008.12.18, 17:45:42
About crazy and why you can see in kernel log (see in docs how give kernel log). Also check your config.sys for TRAPDUMP= setting. Must be TRAPDUMP=R0,xxx for user.

  Ah, this is not there for sure.

Quote from: pasha on 2008.12.18, 17:45:42
And .... This is only beta and first beta ;-)
About speed. This fix is near with retail SMP kernel for speed.  And we are beleive it will be faster.

  Pasha, the results are impressive indeed. After all, the problems were configuration problems,
not on the kernel.
  About speed, this is something maybe you could answer us: there is noticeable difference
of speed (specially in boot time - at least on my machine) when exchanging UNI kernel to
SMP kernel on a single-core machine. Do you know the real reason behind this difference?
Also, you said you are improving speed of SMP kernel... this is related to the end of support
to older hardware (pre-pentium)?

   Once more, thanks and continue the incredible work.

  Regards,

   Daniel Caetano
Title: Re: New kernel
Post by: rwklein on 2008.12.18, 23:32:12
Let me first of all state that Mensys does support and does not endorse the usage of this kernel.
Mensys and Serenity Systems see legal problems with the current way the OS/4 kernel is implemented.
We see this kernel as outright piracy.

Best regards,

Roderick Klein
Mensys
Title: Re: New kernel
Post by: Pete on 2008.12.19, 00:48:00
Hi djcaetano

Ah, the Uniaud "repeating sound" problem.

Using uniaud114RC6 as the "base package" you need to experiment with the various HDA builds of uniaud32.sys available here http://download.smedley.info/

Start with the hda 1.0.16 build and if necessary work back towards 1.0.11 - hopefully 1 of those builds will help.

Also updating ACPI may be beneficial.

Regards

Pete
Title: Re: New kernel
Post by: mobybrick on 2008.12.19, 00:54:31
Hi Roderick,

Please do not take this as disputing or arguing with your stated position - far from it - but perhaps it might be helpful to all, for you to spell out exactly what the legal problems could possibly be and why you think the availability of this kernel is an act of piracy - especially from the viewpoint of a licensed OS/2 or eCS user. If you can detail what the authors of this patched kernel would have to do to correct the situation, it might give the authors something to think about and/or help everyone.

Regards,
Moby.

Quote from: rwklein on 2008.12.18, 23:32:12
Let me first of all state that Mensys does support and does not endorse the usage of this kernel.
Mensys and Serenity Systems see legal problems with the current way the OS/4 kernel is implemented.
We see this kernel as outright piracy.

Best regards,

Roderick Klein
Mensys
Title: Re: New kernel
Post by: rwklein on 2008.12.19, 10:34:42
Quote from: mobybrick on 2008.12.19, 00:54:31
Hi Roderick,

Please do not take this as disputing or arguing with your stated position - far from it - but perhaps it might be helpful to all, for you to spell out exactly what the legal problems could possibly be and why you think the availability of this kernel is an act of piracy - especially from the viewpoint of a licensed OS/2 or eCS user. If you can detail what the authors of this patched kernel would have to do to correct the situation, it might give the authors something to think about and/or help everyone.

Regards,
Moby.

Quote from: rwklein on 2008.12.18, 23:32:12
Let me first of all state that Mensys does support and does not endorse the usage of this kernel.
Mensys and Serenity Systems see legal problems with the current way the OS/4 kernel is implemented.
We see this kernel as outright piracy.

Best regards,

Roderick Klein
Mensys

Will reply later to this.

Roderick Klein
Mensys
Title: Re: New kernel
Post by: rwklein on 2008.12.19, 10:36:22
Quote from: mobybrick on 2008.12.19, 00:54:31
Hi Roderick,

Please do not take this as disputing or arguing with your stated position - far from it - but perhaps it might be helpful to all, for you to spell out exactly what the legal problems could possibly be and why you think the availability of this kernel is an act of piracy - especially from the viewpoint of a licensed OS/2 or eCS user. If you can detail what the authors of this patched kernel would have to do to correct the situation, it might give the authors something to think about and/or help everyone.

Regards,
Moby.

Quote from: rwklein on 2008.12.18, 23:32:12
Let me first of all state that Mensys does support and does not endorse the usage of this kernel.
Mensys and Serenity Systems see legal problems with the current way the OS/4 kernel is implemented.
We see this kernel as outright piracy.

Best regards,

Roderick Klein
Mensys

That should have been:

Let me first of all state that Mensys does *not* support and does not endorse the usage of this kernel.
Mensys and Serenity Systems see legal problems with the current way the OS/4 kernel is implemented.
We see this kernel as outright piracy.

Best regards,

Roderick Klein
Mensys

*not* was missing
Title: Re: New kernel
Post by: lewhoo on 2008.12.19, 10:58:38
I wonder if there is any possible legal way to implement this kernel without IBM's... good will. Perhaps standard IBM kernel could be loaded first, and than, "patch" could be loaded on top of it, "patch" being a separate file, with separate code not violating any copyrights. But that is just a blind idea, for I know close to nothing about kernel implementation, legal issues etc.
Title: Re: New kernel
Post by: AAA on 2008.12.20, 01:38:24
Hi, rwklein

I am a legal user of eCS. Somehow I don't quite understand what kind of endorsement I need from Mensys or whatever. If I've missed something, please advise. After I bought eCS it's only my business what kind of software I will run on/with it . In that sense I am  going to consider your statement not more than an advise.

In fact, what was done by OS/4 team is the first real movement forward for the last 10 years. Yes, what has been done for today looks funny and let us hope that they don't stop there but will continue do serious and useful improvement. I think, the community should give them maximum support and welcome.

Concerning your statement about piracy, it would be definitely great if you showed some evidence of that and, what would be even better, mention the ways how to avoid it. As for me I still have big doubt that this new kernel is somehow connected to piracy.

Regards,
AAA


Quote from: rwklein on 2008.12.18, 23:32:12
Let me first of all state that Mensys does *not* support and does not endorse the usage of this kernel.
Mensys and Serenity Systems see legal problems with the current way the OS/4 kernel is implemented.
We see this kernel as outright piracy.

Best regards,

Roderick Klein
Mensys

*not* was missing
Title: Re: New kernel
Post by: Fahrvenugen on 2008.12.20, 19:12:37
Hi,

I think where the questions arise is there is little information on how this kernel was developed, and so it is difficult to know what the legalities of this kernel are.

From what I see, there are a few ways this kernel could have been developed (again, without more information from those who put it together, it is difficult to know for sure).  They include:

1.  Taking the current 104a kernel and applying patches and adding additional code to it, without any source code or decompiling the kernel.   And modifying the kernel loader to allow other stuff to be loaded  up before the kernel and hook into it.   This would be similar to how Dani's Patchldr file on Hobbes used to be needed to patch the OS/2 loader to get it to recognize installed memory above 64 MB on some motherboards.  This is the most likely method that has been used to develop this kernel.

2.  Somehow getting the source code from IBM (via leaked source or other legitimate channels) and then modifying / recompiling it.

3.  Somehow decompiling the current kernel to develop a source code, and then modifying that.

As for legalities, I do agree with Roderick that any of these options would pose questionable legalities and licenses.  Here's why, I'll discuss each option separately:

Option 1:
1.  If the current 104a SMP kernel was just patched and then redistributed, then those distributing this "patched" kernel are unlikely to have a license to distribute this kernel.  The bulk of the kernel is IBM's, and unless you have a license agreement with IBM to distribute a patched kernel, then any distribution of this kernel is illegal, even if it is distributed only to those who already have OS/2 licenses to run the original kernel. 

This does not prevent you from distributing the code that has been used to patch the kernel, provided you have a license to distribute that code (or if you have written it yourself), and then end users could run that "patching" code against their own 104a kernel to create a "patched" kernel themselves (similar to how the Patchldr fix works).  I'm not sure what the license restrictions are on patching your own kernel, I'll have to check that. 

But I do know that to distribute a complete "patched" kernel package yourselves without a license to do so, yes - it is from a legal perspective considered piracy.

From my understanding of the ZIP, there is no license file included in it, so I am guessing that you don't have a license to distribute a patched kernel.  IBM's legal team is pretty good about such things, so if there had been such a license granted, I'm sure a copy of that license would have been included in the ZIP distribution file.

Option 2:
2.  If the 104a source code somehow was somehow used to develop this kernel and then compiled, then again I question its legality.  If the source code was leaked from IBM and leaked code is being used, then it is obvious that you won't have a license to modify this and redistribute.  If IBM has legitimately provided access to the source code, then there would be a license file included in the ZIP from IBM, explaining the rights and license that comes with this distribution.  As a result it is likely that if 104a kernel source code has been used for this kernel then it is an illegal use, and thus would fall under the category of piracy.

Option 3:
3.  If the current 104a kernel was somehow decompiled, modified, and then compiled and distributed, then this definitely is piracy. 

So any way that I look at it, there are serious legal questions that arise from this kernel.


Title: Re: New kernel
Post by: DavidG on 2008.12.20, 19:25:58
If I remember correctly, a few years back, there was illegal source code circulating around the internet for a much earlier kernel than 1.04a.  It did not contain any of the fixes that went into making the Warp 4 kernel work with newer machines.

David
Title: Re: New kernel
Post by: rwklein on 2008.12.20, 22:56:18
Quote from: Fahrvenugen on 2008.12.20, 19:12:37
Hi,

I think where the questions arise is there is little information on how this kernel was developed, and so it is difficult to know what the legalities of this kernel are.

From what I see, there are a few ways this kernel could have been developed (again, without more information from those who put it together, it is difficult to know for sure).  They include:

1.  Taking the current 104a kernel and applying patches and adding additional code to it, without any source code or decompiling the kernel.   And modifying the kernel loader to allow other stuff to be loaded  up before the kernel and hook into it.   This would be similar to how Dani's Patchldr file on Hobbes used to be needed to patch the OS/2 loader to get it to recognize installed memory above 64 MB on some motherboards.  This is the most likely method that has been used to develop this kernel.

2.  Somehow getting the source code from IBM (via leaked source or other legitimate channels) and then modifying / recompiling it.

3.  Somehow decompiling the current kernel to develop a source code, and then modifying that.

As for legalities, I do agree with Roderick that any of these options would pose questionable legalities and licenses.  Here's why, I'll discuss each option separately:

Option 1:
1.  If the current 104a SMP kernel was just patched and then redistributed, then those distributing this "patched" kernel are unlikely to have a license to distribute this kernel.  The bulk of the kernel is IBM's, and unless you have a license agreement with IBM to distribute a patched kernel, then any distribution of this kernel is illegal, even if it is distributed only to those who already have OS/2 licenses to run the original kernel. 

This does not prevent you from distributing the code that has been used to patch the kernel, provided you have a license to distribute that code (or if you have written it yourself), and then end users could run that "patching" code against their own 104a kernel to create a "patched" kernel themselves (similar to how the Patchldr fix works).  I'm not sure what the license restrictions are on patching your own kernel, I'll have to check that. 

But I do know that to distribute a complete "patched" kernel package yourselves without a license to do so, yes - it is from a legal perspective considered piracy.

From my understanding of the ZIP, there is no license file included in it, so I am guessing that you don't have a license to distribute a patched kernel.  IBM's legal team is pretty good about such things, so if there had been such a license granted, I'm sure a copy of that license would have been included in the ZIP distribution file.

Option 2:
2.  If the 104a source code somehow was somehow used to develop this kernel and then compiled, then again I question its legality.  If the source code was leaked from IBM and leaked code is being used, then it is obvious that you won't have a license to modify this and redistribute.  If IBM has legitimately provided access to the source code, then there would be a license file included in the ZIP from IBM, explaining the rights and license that comes with this distribution.  As a result it is likely that if 104a kernel source code has been used for this kernel then it is an illegal use, and thus would fall under the category of piracy.

Option 3:
3.  If the current 104a kernel was somehow decompiled, modified, and then compiled and distributed, then this definitely is piracy. 

So any way that I look at it, there are serious legal questions that arise from this kernel.




I was writing a reply but you have stated already what the problems are. This is binary patched kernel, the docs also state this. The previous kernel also had certain portions of the copyright modified. Next to the license missing this was also problem (they seem to "fixed") this now. But the way they distribute these patches is illegal.

The stuff for example the os2ldr patch was done by Daniela is very different.

The OS/4 team does not seem to have much knowledge of legal stuff if none at all...
Title: Re: New kernel
Post by: rwklein on 2008.12.20, 23:02:53
Quote from: djcaetano on 2008.12.18, 14:23:08

  Hi Pete,

Quote from: Pete on 2008.12.18, 04:51:02
Hi djcaetano
You state earlier in this thread "Also, no changes on using SMP and OS/4 Kernel: enabling SMP
detection on ACPI caused the system to freeze when starting to process the RUN statements of CONFIG.SYS."

  Just to clear my statement, using SMP with IBM's SMP kernel sometimes causes a freeze.
Using SMP with OS/4 SMP kernel always causes a freeze.

Quote from: Pete on 2008.12.18, 04:51:02
Can I ask what switches were in use on the PSD= line? and also what mainboard chipset is involved?

  No problem. My PSD line is:

  PSD=ACPI.PSD /SMP /APIC

  I had tested other parameters some months ago, but no luck. Any suggestions?
  The chipset is Intel G31 Express (north bridge) and Intel ICH7 (south bridge).

Quote from: Pete on 2008.12.18, 04:51:02
Might also be worth checking exactly where the system gets stuck... do you have an empty text file called ALTF2ON.$$$ in the root directory of your boot drive?  If not create 1 with a text editor - simply save an empty file to that drive:\path\filename - and see if that helps identify where the boot stops.

  Well, in fact I had already did this test. It freezes always in the moment it will execute the first RUN statement. I had already tried to change the order of previous statements and it freezes in the same place (on the first RUN statement). I modified the order of RUN lines on config.sys and the boot keeps freezing on the first RUN statement.
  I seems a problem related to the way RUN statement is processed by the kernel. Weird, huh?
  I'll do some more tests later. With OS/4 kernel it is easier to test, since it always hangs in that
place.

Quote from: Pete on 2008.12.18, 04:51:02
I also note that you are using ACPI v3.11 - might be worth updating that to v3.14 (the latest, v3.7 is awhile away I think :-)

   Yes, I have to renew the eCS "software subscription".
   Anyway, this boot-freeze problem is being a constant since earlier versions of ACPI, never changed a bit. And the freeze only happens when using SMP kernel. With UNI kernel the boot is always flawlessly completed.
   As soon as possible (probably next month) I will renew my subscription and test the new ACPI version.


The problem with the hang on run and call statements is the following. What happens is that when all device driver are loaded some stuff happens in the kernel. At this time of the evening I forgot what :-) It does some switching in modes. Thats why you are seeing frequent hangs with ACPI. But this close to being fixed.

The machine is most cases does hang it just ULTRA busy hanging in a loop somewhere in some kernel/acpi code
because something goes wrong.

Roderick Klein
Mensys
Title: Re: New kernel
Post by: AAA on 2008.12.21, 01:34:36
Quote from: Fahrvenugen on 2008.12.20, 19:12:37
Hi,

I think where the questions arise is there is little information on how this kernel was developed, and so it is difficult to know what the legalities of this kernel are.

From what I see, there are a few ways this kernel could have been developed (again, without more information from those who put it together, it is difficult to know for sure).  They include:

1.  Taking the current 104a kernel and applying patches and adding additional code to it, without any source code or decompiling the kernel.   And modifying the kernel loader to allow other stuff to be loaded  up before the kernel and hook into it.   This would be similar to how Dani's Patchldr file on Hobbes used to be needed to patch the OS/2 loader to get it to recognize installed memory above 64 MB on some motherboards.  This is the most likely method that has been used to develop this kernel.

2.  Somehow getting the source code from IBM (via leaked source or other legitimate channels) and then modifying / recompiling it.

3.  Somehow decompiling the current kernel to develop a source code, and then modifying that.

As for legalities, I do agree with Roderick that any of these options would pose questionable legalities and licenses.  Here's why, I'll discuss each option separately:

Option 1:
1.  If the current 104a SMP kernel was just patched and then redistributed, then those distributing this "patched" kernel are unlikely to have a license to distribute this kernel.  The bulk of the kernel is IBM's, and unless you have a license agreement with IBM to distribute a patched kernel, then any distribution of this kernel is illegal, even if it is distributed only to those who already have OS/2 licenses to run the original kernel. 

This does not prevent you from distributing the code that has been used to patch the kernel, provided you have a license to distribute that code (or if you have written it yourself), and then end users could run that "patching" code against their own 104a kernel to create a "patched" kernel themselves (similar to how the Patchldr fix works).  I'm not sure what the license restrictions are on patching your own kernel, I'll have to check that. 

But I do know that to distribute a complete "patched" kernel package yourselves without a license to do so, yes - it is from a legal perspective considered piracy.

From my understanding of the ZIP, there is no license file included in it, so I am guessing that you don't have a license to distribute a patched kernel.  IBM's legal team is pretty good about such things, so if there had been such a license granted, I'm sure a copy of that license would have been included in the ZIP distribution file.

Option 2:
2.  If the 104a source code somehow was somehow used to develop this kernel and then compiled, then again I question its legality.  If the source code was leaked from IBM and leaked code is being used, then it is obvious that you won't have a license to modify this and redistribute.  If IBM has legitimately provided access to the source code, then there would be a license file included in the ZIP from IBM, explaining the rights and license that comes with this distribution.  As a result it is likely that if 104a kernel source code has been used for this kernel then it is an illegal use, and thus would fall under the category of piracy.

Option 3:
3.  If the current 104a kernel was somehow decompiled, modified, and then compiled and distributed, then this definitely is piracy. 

So any way that I look at it, there are serious legal questions that arise from this kernel.


As far as I understood, the problem is in the distribution ways only.

They have distributed a kind of software to patch the original kernel but not the kernel itself? If this is the only problem, then the legality issue is off, I hope. It should be easy for them to do it this way. But complications may arise for those who want to do patching :) . Of course, not very big.

Regards,
AAA
Title: Re: New kernel
Post by: Pete on 2009.03.10, 01:37:51
Hi Pasha

I've finally run into a problem with this kernel - it does not seem to want to work with UDF formatted discs.

When I try to access a UDF formatted disc from either the WPS drive object or the command line the system appears to have crashed - maybe it is trying to do the debug bit but as I'm not trying to debug I would not know - requiring a press of the Reset button.

What seems to confirm that the problem is with the os4 kernel is that if I select to boot using 14.104a_SMP then there is no problem accessing UDF formatted discs.

I have yet to test other CD/DVD writing software.

Regards

Pete

Title: Re: New kernel
Post by: Pete on 2009.03.15, 03:50:44
Hi All

Just to correct my previous post: None of the test kernels available will work with UDF formatted DVD+RW; All seem to work fine with UDF formatted DVDRAM; DVD-RW untested as I do not use these discs.

By "UDF" I mean the OS/2 (UDF216) UDF.IFS not the format option included with dvddao - which works fine to format a DVD+RW during the dvd copy process.

RSJ works fine with CDs; cdrecord2 seems to work fine as well.

So, the only "burning issue" is UDF and DVD+RW discs.

If anyone has any "fine tuning" suggestions to overcome this problem I'm interested  :-)

Regards

Pete

Title: Re: New kernel
Post by: IBManners on 2009.03.19, 13:57:48
You could try reverting to an earlier kernel.

Cheers
Title: Re: New kernel
Post by: alstaszko on 2009.03.19, 17:18:17
The package doesn't contain the file "os2ldr" but contains "os2ldr.ini" and "os2ldr.read.me".
The install instructions assume it's in that package.

Is this correct i.e. "os2ldr" is in a separate package or does it imply that one should use one from an earlier package?

Andy Staszko
Title: Re: New kernel
Post by: Pete on 2009.03.19, 17:27:02
Hi

Quote from: IBManners on 2009.03.19, 13:57:48
You could try  ftp://Linking to this site is not permitted on our forums/os2krnlSVN1098.zip


Sadly the problem is common to all the "test" kernels available  :-(

As there is no problem when using kernel 14.104a_SMP I can only guess that something to do with "tweaking" the debug kernel used causes this problem. This may not be common to other systems and could involve other "test" software such as ACPI.

I see the "test" kernels claim to have fixed the problem that stopped nVidia chipsets using OS2APIC.PSD so will give that a try in an attempt to more closely identify where the problem occurs and report back in the near future.

Regards

Pete
Title: Re: New kernel
Post by: Pete on 2009.03.20, 04:01:02
Hi

I can now confirm the problem exists when using os2apic.psd instead of acpi.psd

Seems to indicate the problem is in the test kernels.

Regards

Pete
Title: Re: New kernel
Post by: AAA on 2009.05.02, 15:24:58
Next version has arrived.

ftp://Linking to this site is not permitted on our forums/os2krnlSVN1313.zip
Title: Re: New kernel
Post by: rwklein on 2009.05.02, 19:38:16
Quote from: AAA on 2009.05.02, 15:24:58
Next version has arrived.

ftp://Linking to this site is not permitted on our forums/os2krnlSVN1313.zip

The humor in the binary :-)

Copyright 1986,1997 IBM Corp.
Copyright 2008 OS/4 Team.

I wish the eComStation team could do something with the kernel. But its still shady this whole project.
BTW don't be surprised it this kernel hangs when an application has a crash. Because its a patched debug kernel.
Unless they disabled  this code.

On the point of working with Mensys (If this project would be legal). It seems the OS/4 people do try to hide something ?! The interesting thing is that the main IP address of the Mensys ADSL line does not get FTP access to the OS/4 FTP server.
Funny enough when I walk over to a work station that has access to internet via a different ISP with a different IP address it does get access. To make matters even more interesting if you think its an ISP malfunction at home I have the same ADSL ISP as we have in the Mensys office and at home half hour later when I tried the FTP at home it worked :-) Tried the next day again, and presto still blocked. On top of that I know that Eugene Gorbunov also can not access the FTP server...

Weird stuff ?

Roderick Klein
Mensys
Title: Re: New kernel
Post by: lewhoo on 2009.05.02, 21:46:03
Well, from this forum, it seemed that the situation was tense on both sides - Mensys and OS/4 team. Not getting into who is responsible for what... it's obvious that the whole OS/2 community would benifit from this kernel. Thus I hope both sides will somehow manage to cooperate in the future to get it into ecs.

I am sure that Mensys or Serenity has no special interest in blocking this kernel and ment no wrong, and also I am sure that OS/4 team has only good intentions in developing this kernel.
Title: Re: New kernel
Post by: rwklein on 2009.05.02, 22:47:03
Quote from: lewhoo on 2009.05.02, 21:46:03
Well, from this forum, it seemed that the situation was tense on both sides - Mensys and OS/4 team. Not getting into who is responsible for what... it's obvious that the whole OS/2 community would benifit from this kernel. Thus I hope both sides will somehow manage to cooperate in the future to get it into ecs.

I am sure that Mensys or Serenity has no special interest in blocking this kernel and ment no wrong, and also I am sure that OS/4 team has only good intentions in developing this kernel.

To a large extend the kernel is the ticking clockwork for OS/2. However the continued belief that everything has to be fixed inside
the kernel itself is kind of not true. If you take a close look at the old WIN32K.SYS that Knut wrote for the ODIN project! This patches the kernel in memory without distributing a single patched IBM binary code. It modifies the OS2 loader in the kernel that makes OS/2 load an executable. Its true that some patches can not be done in the memory but a lot can be done!

Until that time OS/4 kernel by making a disassembly of the kernel, patching it with such a large collection of and then distributing it with OS/4 copyright its illegal. And Mensys can not work with the team.

Roderick Klein
Mensys
Title: Re: New kernel
Post by: walking_x on 2009.05.02, 23:30:31
From my point of view, Mensys position is clear: "this guys must work for us for free and give us all, what they done" ;) And copyrights only is a good shield for main idea ;)
And as far as i know, no one is specially hide something from Mensys ;) - this effect is result of long term holy war between Eugene Gorbunov and maintainer of Linking to this site is not permitted on our forums ;)
Title: Re: New kernel
Post by: AAA on 2009.05.03, 11:57:27
I agree with lewhoo  - OS/2 community definitely  would benefit from this kernel.
And that is why it is better to support OS/4 Team rather than criticize.

Rwklein, once (#62) I have already asked about your suggestions - how you see it should be - unfortunately, there was no answer.

It looks like you really have something in your mind but you don't want to share it.
Please, advise what is illegal in OS/4 kernel:
- presence of OS/4 copyright
- distribution of patched kernel
- etc.

It's a pity, but from your posts it  is absolutely unclear what you consider illegal. I think OS/4 team will appreciate all your suggestions.

From my point of view, for example, it should not be a big deal for them to remove the copyright string or distribute a not patched kernel but a software to patch the original one.

At the same time I would not want to believe walking_x, who said that Mensys might have some hidden motifs.
Title: Re: New kernel
Post by: rwklein on 2009.05.03, 15:21:48
Quote from: walking_x on 2009.05.02, 23:30:31
From my point of view, Mensys position is clear: "this guys must work for us for free and give us all, what they done" ;) And copyrights only is a good shield for main idea ;)
And as far as i know, no one is specially hide something from Mensys ;) - this effect is result of long term holy war between Eugene Gorbunov and maintainer of Linking to this site is not permitted on our forums ;)

In that respect Mensys does not want something for free. If something is done properly and in a legal sense. Then Mensys pays for it. Infact I would hire the OS/4 team if its legal.

We want all for free ?  look at this presentation I gave at Warpstock 2008 ?

http://wse2008.warpevents.eu/uploads/tx_wseevents/wse2008_all08_ecomstation_2.0_and_beyond.pdf

Page 5. We hire Pasha to work on ACPI. Is ACPI performing we would like it to work, not yet. But its a very complex project. And we have hired more developers on a project basis.

Roderick Klein
Mensys
Title: Re: New kernel
Post by: Pete on 2009.05.03, 15:24:50
Hi

Quote from: AAA on 2009.05.02, 15:24:58
Next version has arrived.

ftp://Linking to this site is not permitted on our forums/os2krnlSVN1313.zip


Sadly no change with regard to accessing UDF formatted DVD+RW discs.


Regards

Pete
Title: Re: New kernel
Post by: rwklein on 2009.05.03, 15:47:11
Quote from: AAA on 2009.05.03, 11:57:27
I agree with lewhoo  - OS/2 community definitely  would benefit from this kernel.
And that is why it is better to support OS/4 Team rather than criticize.

Rwklein, once (#62) I have already asked about your suggestions - how you see it should be - unfortunately, there was no answer.

It looks like you really have something in your mind but you don't want to share it.
Please, advise what is illegal in OS/4 kernel:
- presence of OS/4 copyright
- distribution of patched kernel
- etc.

It's a pity, but from your posts it  is absolutely unclear what you consider illegal. I think OS/4 team will appreciate all your suggestions.

From my point of view, for example, it should not be a big deal for them to remove the copyright string or distribute a not patched kernel but a software to patch the original one.

At the same time I would not want to believe walking_x, who said that Mensys might have some hidden motifs.


I would really like to support this kernel. But when it comes to copyright law in Western Europe and the United States. The kernel is indeed a violation of the law because the remove/ added the copyright statement of IBM. But they pay no royalties to IBM even. Mensys and Serenity Systems do so.

Second distributing the kernel in such a fashion with patches in it is also a violation of the law.
A patch as win32k.sys does from a legal point of view is clean.

If the community would this kernel to be of us it needs to be legal. Otherwhise it useful for private usage.
Guess why Mensys did not include MP3 support and other video codecs. Everything that is included in eComStation is licensed from vendors or in depth research has been done to make certain no intellectually rights property where violated.
Including the OS/4 kernel in the eComStation distribution would do so.

When it comes to working with the community Mensys and Serenity Systems try to there best to do so. And eComStation has always been a community/company effort. With Mensys/Serenity systems investing money. For example we hired a developer for 20.000 Dollars who is ex IBM to debug UNIAUD. Paul Smedley can confirm that the developer Richard Jerant removed bugs that would have been difficult to find by other people. Mensys will pay a developer to get AHCI support to eComStation.
We pay for ACPI support, we pay for Flash development and the Open Office port.  We run the VOICE mailing lists, provide Paul Smedley with FTP space for his software, CVS netlabs runs on our server. We work with Netlabs

Mensys people like me and Joachim have always been closely involved with the community like me doing www.warpweekend.com and involved with Warpstock and many other items we sponsor and infrastructure we provide.
I'm just listing some of these things because I know very well the importance of the community. We need the community and some the work the community needs us. (If you want more details I can explain why the community needs us.)
So it goes both ways in call kinds of ways.

The comment I have on the kernel in my view is 100% justified since its illegal (I just pointed out why) and we could support the developers but we do not and can not endorse illegal software.

Roderick Klein
Mensys



Title: Re: New kernel
Post by: lewhoo on 2009.05.03, 18:51:51
So... can Mensys help to make OS/4 kernel legal? As, being no developer, I understand, it shouldn't be that difficult: no copyright violations, in-memory patching. It would be nice to see one day, that Mensys and OS/4 team cooperation resulted in legal, good new kernel :)
Title: Re: New kernel
Post by: walking_x on 2009.05.03, 19:24:21
Yes, I am understand legal/formal reasons, but another side look - OS/2 story is a story of child, who killed by own parent. May be, not by IBM itself, but with help of some .... like Lou Gerstner or any other "big chief". Kernel story is a good demonstration too (even Mensys can`t get sources).
In-memory patching is "legal", but bad idea ;) 1) it forbids original IBM os2ldr, 2) it is not easy to find memory for patch file on boot ;)
Title: Re: New kernel
Post by: AAA on 2009.05.03, 20:20:08
Quote from: rwklein on 2009.05.03, 15:47:11

...The kernel is indeed a violation of the law because the remove/ added the copyright statement of IBM...

...Second distributing the kernel in such a fashion with patches in it is also a violation of the law...


Coming back to OS/4 kernel, if I understood you correctly, they have to remove OS/4 copyright and distribute a not patched kernel but a software to patch the original kernel, right?
Title: Re: New kernel
Post by: rwklein on 2009.05.03, 21:09:01
Quote from: walking_x on 2009.05.03, 19:24:21
Yes, I am understand legal/formal reasons, but another side look - OS/2 story is a story of child, who killed by own parent. May be, not by IBM itself, but with help of some .... like Lou Gerstner or any other "big chief". Kernel story is a good demonstration too (even Mensys can`t get sources).
In-memory patching is "legal", but bad idea ;) 1) it forbids original IBM os2ldr, 2) it is not easy to find memory for patch file on boot ;)


If you dig back to OS/2 and what I all did on the platform and MMOS/2 with other people I have also invested a few years of live to it. Sometimes upto 120 hours a week, during week and weekends and nights. OS/2 has a history with IBM and it went the way it went. OS/2 is business for IBM and it has partly gone the way because of certain things that happened...

So there is a harsh side to the story of how OS/2 has lived its live so far. As I typed before a lot (not everything) can be fixed without kernel sources. I have talked to a lot of people about this, experts like Daniela. And kernel sources are handy but there are plenty of ways around current kernel problems. I wrote that before! Look what we did to eComStation over the past 8 years. I wish it would have all gone faster instead of so slow. But it was all done with kernel source code!

And more is possible! If you want to keep OS/2 alive I hope we can do it in the form of eComStation.  IBM has the copyright on OS/2 and we can buy licenses. Hence why we can still sell it to companies that need it.

If this new OS/4 kernel would just sit in a legal corner the way its now we can not even *start* consider to use it.

Roderick Klein
Mensys
Title: Re: New kernel
Post by: rwklein on 2009.05.03, 21:12:29
Quote from: lewhoo on 2009.05.03, 18:51:51
So... can Mensys help to make OS/4 kernel legal? As, being no developer, I understand, it shouldn't be that difficult: no copyright violations, in-memory patching. It would be nice to see one day, that Mensys and OS/4 team cooperation resulted in legal, good new kernel :)

I still don't have a clear understanding of who Team/OS/4 is. And I have some questions in there directions how they did certain things. Mensys/Serenity Systems has a business relationship with IBM and our private users and companies. The legal aspect is a very important  one of that relationship with our customers and with IBM.

Roderick Klein
Mensys
Title: Re: New kernel
Post by: rwklein on 2009.05.03, 21:16:27
Quote from: AAA on 2009.05.03, 20:20:08
Quote from: rwklein on 2009.05.03, 15:47:11

...The kernel is indeed a violation of the law because the remove/ added the copyright statement of IBM...

...Second distributing the kernel in such a fashion with patches in it is also a violation of the law...


Coming back to OS/4 kernel, if I understood you correctly, they have to remove OS/4 copyright and distribute a not patched kernel but a software to patch the original kernel, right?


Who owns the intellectual rights to OS/2 and hence the OS/4 kernel. That is IBM not OS/4 team.  Well take a look up close at the source code of the WIN32K.SYS driver. I just tried to find it. The code for ODIN must be somewhere with the WIN32K.SYS driver from Knut. Thats one way of doing certain updates to the kernel.

Roderick Klein
Mensys
Title: Re: New kernel
Post by: AAA on 2009.05.03, 21:47:52
Quote from: rwklein on 2009.05.03, 21:16:27

Who owns the intellectual rights to OS/2 and hence the OS/4 kernel. That is IBM not OS/4 team.  Well take a look up close at the source code of the WIN32K.SYS driver. I just tried to find it. The code for ODIN must be somewhere with the WIN32K.SYS driver from Knut. Thats one way of doing certain updates to the kernel.

Roderick Klein
Mensys

I have never met that OS/4 team has ever declared any rights to OS/2 kernel. Of course, it is the intellectual property of IBM. Moreover, in the documentation that goes with the kernel from OS/4 team it is clearly stated : You can use this packet only having valid license to run OS2KRNL.

At the same time, I have to note that you keep saying that it is illegal and continue to ignore my repeated question what exactly is illegal.

Here I go trying to ask once again: if OS/4 distributes a software to do the patching of the original and not an already patched kernel, will this take the legal issue off?

If you don't give clear answers now, I will have to consider all your declarations about illegality as such that have no grounds.
Title: Re: New kernel
Post by: abwillis on 2009.05.03, 22:26:00
Quote from: rwklein on 2009.05.03, 21:16:27
Who owns the intellectual rights to OS/2 and hence the OS/4 kernel. That is IBM not OS/4 team.  Well take a look up close at the source code of the WIN32K.SYS driver. I just tried to find it. The code for ODIN must be somewhere with the WIN32K.SYS driver from Knut. Thats one way of doing certain updates to the kernel.

Roderick Klein
Mensys
One piece that win32k.sys already can patch is allowing DLL files to not be bound by the 8.3 naming convention. 
Title: Re: New kernel
Post by: rwklein on 2009.05.04, 00:34:38
Quote from: AAA on 2009.05.03, 21:47:52
Quote from: rwklein on 2009.05.03, 21:16:27

Who owns the intellectual rights to OS/2 and hence the OS/4 kernel. That is IBM not OS/4 team.  Well take a look up close at the source code of the WIN32K.SYS driver. I just tried to find it. The code for ODIN must be somewhere with the WIN32K.SYS driver from Knut. Thats one way of doing certain updates to the kernel.

Roderick Klein
Mensys

I have never met that OS/4 team has ever declared any rights to OS/2 kernel. Of course, it is the intellectual property of IBM. Moreover, in the documentation that goes with the kernel from OS/4 team it is clearly stated : You can use this packet only having valid license to run OS2KRNL.

At the same time, I have to note that you keep saying that it is illegal and continue to ignore my repeated question what exactly is illegal.

Here I go trying to ask once again: if OS/4 distributes a software to do the patching of the original and not an already patched kernel, will this take the legal issue off?

If you don't give clear answers now, I will have to consider all your declarations about illegality as such that have no grounds.

From my point of view I have given pretty clear answers to your answers. I don't think you understand strictly how copyright works ? If you place a copyright on piece of software or music  you also have certain legal rights to defend this copyright.
Its clear the OS/4 team has not developed the kernel for 100%. I have asked 2 people who looked at it and its clearly to a large degree its a patched IBM kernel code.  Hence that they may not intend to do it in that fashion but by putting a copyright claim on it for OS/4 Team 2008. Is clearly a violation of international copyright laws.

So to mention that you should have a valid license to run the OS2krnl  in the readme is like saying. He here is a re-mix of a house CD, I Roderick put the copyright on it. But I put a note on it. "If you have a purchased a copy of the CD of this artist its still oke".

IBM has never given permission to sub-license the OS/4 kernel and modify it to such a large extend. As to the patching I did not fully answer that question but did answer indirectly. That WIN32K.SYS answer I gave. An executable that the would send out to allow people to patch the kernel on there own would be less illegal that is certainly the case. But still a bit on a slippery slope.

What I know is that WIN32K.SYS method (patching in memory) (as Andy Willes explains) has the least to none of the technicall problems. A patch tool to patch the kernel on your private hard disc, don't know would need todo more research.

Roderick Klein
Mensys
Title: Re: New kernel
Post by: walking_x on 2009.05.04, 14:34:30
Quote from: rwklein on 2009.05.04, 00:34:38
What I know is that WIN32K.SYS method (patching in memory) (as Andy Willes explains) has the least to none of the technicall problems.
This method is suitable only for small, second boot phase patches.
How you can patch kernel from driver to show another (vesa) boot logo?
Title: Re: New kernel
Post by: rwklein on 2009.05.04, 15:13:42
Quote from: walking_x on 2009.05.04, 14:34:30
Quote from: rwklein on 2009.05.04, 00:34:38
What I know is that WIN32K.SYS method (patching in memory) (as Andy Willes explains) has the least to none of the technicall problems.
This method is suitable only for small, second boot phase patches.
How you can patch kernel from driver to show another (vesa) boot logo?

I never stated that the WIN32K.SYS patching method is a sollution for all. But the point is how to keep the current project legal ?

Roderick Klein
Mensys
Title: Re: New kernel
Post by: Pete on 2009.05.04, 15:58:50
Hi Roderick

What is the legal difference between the os4 kernel and the kernels produced by the acpi developers?

Regards

Pete
Title: Re: New kernel
Post by: IBManners on 2009.05.04, 16:23:21
Hi Pete,

QuoteWhat is the legal difference between the os4 kernel and the kernels produced by the acpi developers?

The ACPI developers are not producing Kernels, just an additional driver.

Cheers
Title: Re: New kernel
Post by: Pete on 2009.05.04, 17:34:01
Hi

What exactly is the acpi kernel package found in the ecs betazone? - http://betazone.ecomstation.com/fileviewer.php?file_id=268
This is described as "eComStation kernel for ACPI. Highly experimental."

ACPI315 - login at Mensys downloads - also contains a kernel.

Regards

Pete
Title: Re: New kernel
Post by: Criguada on 2009.05.05, 12:32:19
Hi walking_x!

Quote from: walking_x on 2009.05.04, 14:34:30
Quote from: rwklein on 2009.05.04, 00:34:38
What I know is that WIN32K.SYS method (patching in memory) (as Andy Willes explains) has the least to none of the technicall problems.
This method is suitable only for small, second boot phase patches.
How you can patch kernel from driver to show another (vesa) boot logo?

If I understand correctly this (vesa boot logo) is handled by OS2LDR, not by OS2KRNL; and (again if I understand correctly) OS2LDR has been completely rewritten, it is not a patch over the original one, so there is no problem adopting it.

Bye
Cris
Title: Re: New kernel
Post by: walking_x on 2009.05.05, 14:34:15
Quote from: Criguada on 2009.05.05, 12:32:19
If I understand correctly this (vesa boot logo) is handled by OS2LDR, not by OS2KRNL; and (again if I understand correctly) OS2LDR has been completely rewritten, it is not a patch over the original one, so there is no problem adopting it.
No, kernel load and show logo during first init phase, in protected mode. Then you press AltF1 - it handled in kernel before logo.
Title: Re: New kernel
Post by: Pete on 2009.06.03, 16:29:25
Hi All

Looks like someone is listening to Roderick as the current release of the os4 kernel ftp://Linking to this site is not permitted on our forums/os2krnlSVN1359.zip does not contain a kernel, it contains an os2krnl.pat file that is used to patch the 14.104a debug kernel http://www.os2site.com/sw/upgrades/kernel/smp20050811d.zip

Seems to be working - so far.

Regards

Pete
Title: Re: New kernel
Post by: AAA on 2009.07.20, 20:34:21
Next test version is available ftp://ftp.Linking to this site is not permitted on our forums/os2krnlSVN1425_unoff.zip
Title: Re: New kernel
Post by: djcaetano on 2009.07.22, 02:57:20
Quote from: AAA on 2009.07.20, 20:34:21
Next test version is available ftp://ftp.Linking to this site is not permitted on our forums/os2krnlSVN1425_unoff.zip

  It would be very nice if the file included an updated version of "WhatsNew". :)
Title: Re: New kernel
Post by: AAA on 2009.09.08, 19:41:00
ftp://ftp.Linking to this site is not permitted on our forums/os2krnlSVN1564_unoff.zip
Title: Re: New kernel
Post by: cytan on 2009.09.09, 17:23:25
Hi all,
   It seems that our kernel is being improved (not only the ldr). From the WhatsNew:

- Fixed some previously undetected IBM bugs

Hmmm ... this is really interesting which brings up some questions in my mind about source acess ...

However, I'm not going to look at a gift horse in the mouth.

What I really would like is the lifting of the 512MB limit on shared memory in the kernel. With all the current apps eating this place up (like OpenOffice etc). Is there a plan to improve this?

cytan

Title: Re: New kernel
Post by: warpcafe on 2009.09.09, 17:49:05
Hey,

Quote from: cytan on 2009.09.09, 17:23:25
Hmmm ... this is really interesting which brings up some questions in my mind about source acess ...

Wooooaaaaah! Would you _PLEASE_ stop talking about this?? :)
I am sure someone I know from Mensys is exactly _now_ falling off his chair.
And his front is hitting the desk... ;) I can hear very heavy dutch insults sounding up to my place (approx. 300 km away)... please don't put out the fire with gasoline... :)

Cheers,
Thomas
Title: Re: New kernel
Post by: AAA on 2009.09.11, 13:58:03
Quote from: warpcafe on 2009.09.09, 17:49:05
I can hear very heavy dutch insults sounding up to my place

You probably heard some other dutch insults  :D

As far as I know, OS/4 copyrights was removed from the new kernel as well as OS/4 kernel was distributed as a patch to official one. So all Mensys objections were satisfied (at least those that they announced).

It's most probable that Mensys is unhappy because the new kernel is being developed without their involvement and new objections will arise soon.

Title: Re: New kernel
Post by: warpcafe on 2009.09.11, 14:12:50
AAA,

well, that's something I don't want to discuss in public :P
But yes, these are "different" durch insults :)
I have sent you a private mail - see "my messages" on top when logged-in here.

Cheers,
Thomas
Title: Re: New kernel
Post by: AAA on 2009.11.18, 18:50:19
ftp://ftp.Linking to this site is not permitted on our forums/os2krnlSVN1660_unoff.zip

fixed some bugs in loader
Title: Re: New kernel
Post by: lpino on 2009.11.18, 21:09:03
Quote from: AAA on 2009.11.18, 18:50:19
ftp://ftp.Linking to this site is not permitted on our forums/os2krnlSVN1660_unoff.zip

fixed some bugs in loader
It would be very nice if they documented the changes included in each release.

Thanks.

Title: Re: New kernel
Post by: DougB on 2009.11.19, 21:00:23
I tried os2krnlSVN1660_unoff.zip on my Asus M3A78-EM, with quad core AMD Phenom processor. Nothing has changed, it still freezes at loading DBCS.FNT (doesn't exist) - long before the eCS, or OS/4, logo shows up.

QuoteIt would be very nice if they documented the changes included in each release.

I agree. far too many test releases are made, of far too many programs, without giving the user/tester any clue what to expect, or test. That wastes a LOT of time on the part of the user/tester. It also results in many missed, or unnecessary,  problem reports which wastes a lot of developer time.
Title: Re: New kernel
Post by: Pete on 2009.11.19, 21:16:31
Hi

SVN1660 seems to work as well as previous builds tested on my nForce430/MCP system - and like all previous kernel builds it is totally incompatible with UDF formatted DVD+RW discs.

Some earlier kernel builds simply crashed the system when trying to access the DVD+RW disc; more recent builds cause the system to reboot when trying to access the DVD+RW disc.

If the developers could get rid of that problem it would probably be a good kernel to use but as it is it is no use here.


Regards

Pete