• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

New kernel

Started by AAA, 2008.11.07, 17:05:07

Previous topic - Next topic

rwklein

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

djcaetano

  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.

Pete

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

djcaetano


  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. :)

pasha

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.

djcaetano


  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

rwklein

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

Pete

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

mobybrick

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

rwklein

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

rwklein

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

lewhoo

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.

AAA

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

Fahrvenugen

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.



DavidG

#59
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