OS2World OLD-STATIC-BACKUP Forum

WebSite Information => Comments, Suggestions & Questions => Topic started by: pasha on 2010.03.02, 23:51:28

Title: kernel affinity bug
Post by: pasha on 2010.03.02, 23:51:28
Under working with acpi, VPC, Odin and Uniaud was found bug in os2 kernel. If your thread (program) has affinity setting - you have chance to freeze. Also if you run exe with set MPSAFE bit. In 2 core you have 50/50(to have) chance, in i7 4 core 25/75 chance e.t.c.
Title: Re: kernel affinity bug
Post by: Saijin_Naib on 2010.03.03, 00:15:11
Okay... so what does this mean?

It is something you are fixing in your custom patched kernel?

Does this mean that Os/2 will become more stable now?
Title: Re: kernel affinity bug
Post by: pasha on 2010.03.03, 00:22:48
Quote from: Saijin_Naib on 2010.03.03, 00:15:11
Okay... so what does this mean?

It is something you are fixing in your custom patched kernel?

Does this mean that Os/2 will become more stable now?
After svn2059 versions as well. Stable..... In ny i7 is very stable ;-)
Title: Re: kernel affinity bug
Post by: Saijin_Naib on 2010.03.03, 00:30:16
Good to know :) I don't have i7, only core 2 duo but this is only good news.
Title: Re: kernel affinity bug
Post by: cytan on 2010.03.03, 06:19:08
I'm sorry pasha, I cannot understand what you are saying. Can some one explain it to a non-tech guy like me what pasha fixed.

cytan
Title: Re: kernel affinity bug
Post by: Saijin_Naib on 2010.03.03, 06:36:34
From what I gather, beacuse Pasha was working with ACPI he found that some of the crashes in VPC, Odin, and Uniaud are due to a bug in the OS/2 Kernel. The applications that can control process affinity are affected. The more cores you have, the less chance you have of a hang?

Basically, with his new kernel expect less crashes with Odin, ACPI, Uniaud, VPC, etc on SMP eComStation installs.
Title: Re: kernel affinity bug
Post by: Sigurd on 2010.03.03, 08:30:42
Hi,

and where can one get this new kernel? Would like to test it. Thanks for this.
Title: Re: kernel affinity bug
Post by: AAA on 2010.03.03, 11:05:03
OS/4 kernels are always available  on ftp://ftp.Linking to this site is not permitted on our forums/
Title: Re: kernel affinity bug
Post by: Sigurd on 2010.03.03, 12:31:05
Thanks - gave it a try - seems to work so far.

Some questions for those involved:

It seems to me that it makes no difference for me if I boot with OS/4 or eComStation kernel. So, what does the OS/4 kernel miss I may have not identified? What prevents the OS/4 kernel so from being "not beta" anymore? License issues?

Is this OS/4 kernel probably 64-bit capable or can it overcome the 4GB RAM Limit?

Yes - sorry - this are a lot of questions though I did take a look at the OS/4 homepage. But this seems really interesting to me!

Thanks
Title: Re: kernel affinity bug
Post by: mobybrick on 2010.03.03, 15:53:47
From what I've heard, this is a patched version of the 14.104a *debug* kernel.

Because its a debug kernel, beware. Any ring 3 access violations will in fact call then IPE exception handler... meaning that you get a black 'Trap' screen (and system halt) even on application errors that would normally be handled by the OS. So, this kernel is not suitable for production use IMHO.

Regards,
Moby
Title: Re: kernel affinity bug
Post by: walking_x on 2010.03.04, 12:15:44
Quote from: mobybrick on 2010.03.03, 15:53:47Because its a debug kernel, beware. Any ring 3 access violations will in fact call then IPE exception handler... meaning that you get a black 'Trap' screen (and system halt) even on application errors that would normally be handled by the OS. So, this kernel is not suitable for production use IMHO.
Your are wrong :)
Ring 3 access violation work as usual, ring 3 debuggers too. Kernel suitable for everyday use, not for production, may be - but my home server uptime is a several weeks.
Title: Re: kernel affinity bug
Post by: mobybrick on 2010.03.04, 13:25:56
Er, wrong, IMHO.   :D

If you have a ring 3 debugger registered, then SYS3175s will be handled by the registered debugger. If you don't have one installed (and most people won't) then the kernel debugger will be called, resulting in either a trap screen (or, more likely) what resembles a system hang. The system won't actually have hung, it will be waiting for instructions on the serial port.

How many SYS3175 popups have you had *without* any debugging software running?
Title: Re: kernel affinity bug
Post by: walking_x on 2010.03.04, 15:03:21
Look here (ftp://212.12.30.18/public/sshot/sshot.gif) ;)
Especially to string "OS/4 kernel revision" ;)
Title: Re: kernel affinity bug
Post by: Fahrvenugen on 2010.03.04, 16:28:15
Quote from: walking_x on 2010.03.04, 12:15:44
...
Ring 3 access violation work as usual, ring 3 debuggers too. Kernel suitable for everyday use, not for production, may be - but my home server uptime is a several weeks.

For me server uptime doesn't tell me anything about this hacked kernel.

I have a server that has been running for around 18 months on a 14.103a kernel.

Title: Re: kernel affinity bug
Post by: mobybrick on 2010.03.04, 16:40:25
The point I am trying to make is that with the debug kernel, application exceptions are handled differently.

I'm not saying that SYS 3175s will happen more or less with the debug kernel - as these exceptions are ring 2/3 application exceptions - so supposed uptime availability should not change - but that the debug kernel will appear to 'hang', waiting for serial port input, instead of a SYS3175 popup being generated. Unless of course a debugging exception handler has been installed or configured via kdb.  Of course, I could be wrong....
Title: Re: kernel affinity bug
Post by: walking_x on 2010.03.04, 17:08:37
This is not "hacked" or "patched" debug kernel. It have many differences with it:
- boot time config.sys editor
- new logo
- optional preloading basdev/boot files to avoid bug in ATI chipset with ACPI
- fixed affinity (try to run HMM3 in Odin on 104a, 1/10 to catch dead lock)
- new KEE functions, common log
- new os2ldr (menu, options)
I'm think any one of those functions cannot be made by patching ;) Especially because of lacking LX EXE file format editors :)
Title: Re: kernel affinity bug
Post by: Fahrvenugen on 2010.03.04, 17:33:27
As for this being a patched kernel, if you read through the thread:

http://www.os2world.com/component/option,com_smf/Itemid,63/topic,1316.0/

it came out in that thread that yes, this is a patch to the IBM OS/2 debug kernel, not a new kernel.



Title: Re: kernel affinity bug
Post by: walking_x on 2010.03.04, 17:53:20
Quote from: Fahrvenugen on 2010.03.04, 17:33:27it came out in that thread that yes, this is a patch to the IBM OS/2 debug kernel, not a new kernel.
Yes, but I'm think they use some kind of another technology, no direct binary patching.
Title: Re: kernel affinity bug
Post by: mobybrick on 2010.03.04, 18:28:07
Here is where it will get interesting. I suspect Mensys/Serenity have been maneuvered into an impossible position.

ACPI was one of the mains goals of eCS 2.0, but now with the core ACPI developer also responsible for a hacked kernel, I can see the days possibly coming when something along the lines of...

'If you want ACPI to work (e.g. not hang on bootup) then you'll need the patched kernel from the OS/4 team. Oh, and this would need to be distributed with eCS for the eCS ACPI feature to work...'

Or maybe I am dreaming again. Time will tell.

Regards,
Moby.
Title: Re: kernel affinity bug
Post by: Fahrvenugen on 2010.03.05, 01:04:32
Quote from: walking_x on 2010.03.04, 17:53:20
Quote from: Fahrvenugen on 2010.03.04, 17:33:27it came out in that thread that yes, this is a patch to the IBM OS/2 debug kernel, not a new kernel.
Yes, but I'm think they use some kind of another technology, no direct binary patching.

Well, my suggestion is to read through the previously referenced thread.

Based on the information that has been put out there about this kernel, along with the limited information in the zip file, this appears to a binary patch (some would call it a hack) to the 14.104a debug kernel.  Since it apparently requires the SMP version of some DLL's, my guess is that it is the 14.104a debug SMP kernel that has been patched.

As for patching technology, it has also been discussed on other threads.  The truncated version of that discussion is, since IBM has not released source code for the kernel, from what I understand there are essentially there are 2 ways of patching the kernel:

1.  "On the fly" - commonly done with device drivers and / or loaders at boot time
2.  Binary patching - modifying the binary.

I'm sure that some of the modifications that have been done by the people who have released this unofficial kernel has been accomplished by the new loader that they also wrote.  And yes, some of the changes listed (changing the boot logo) are very easy to do.  However I suspect that other changes that have been done have been direct binary patching of IBM's kernel based on material found in the DDK, other OS/2 programming documentation and sources, looking through debug code, and just straight hacking the kernel binary.

Anyways, its been discussed to death, so not worth getting into much again.

Title: Re: kernel affinity bug
Post by: warpcafe on 2010.03.05, 14:46:51
Hey all,

for me, the most interesting part here is not "is that Kernel legal or not". Because:
The thing is (and you can twist your mind as far as you want, it will not change anything): It is illegal.
If you disagree, simply think
a) would IBM allow you distribute a patched Kernel (even if it is free)?
b) would Mensys gladly support your bug tickets with a patched kernel?

So unless there is a written official statement of IBM that "the authors" are allowed to distribute a patched kernel, it is illegal.
I know what will come from the east now: "Copyright law is different in Russia".
Okay, comrades. That might perhaps be true, but it simply doesn't fu**ing matter, because that Kernel is property of a U.S., stock noted, SOX-compliant company that employs more lawyers on their own than there are in Russia perhaps. Your laws don't apply. That kernel is illegal until IBM tells it isn't. Get it.

And for those who say "Well, I don't mind it's illegal. Let me use it for my purpose", one more thought:
What do you think can you expect from Mensys or the people working for their various projects (ACPI, JFS, Flash, OOO, Networking...) or from any 3rd party author if you create a bug report and they ask you
"...wait, _WHAT_ Kernel are you using?"

Cheers,
Thomas
Title: Re: kernel affinity bug
Post by: mobybrick on 2010.03.05, 17:35:07
Quote from: warpcafe on 2010.03.05, 14:46:51
Hey all,

for me, the most interesting part here is not "is that Kernel legal or not". Because:
The thing is (and you can twist your mind as far as you want, it will not change anything): It is illegal.
If you disagree, simply think
a) would IBM allow you distribute a patched Kernel (even if it is free)?
b) would Mensys gladly support your bug tickets with a patched kernel?

Cheers,
Thomas

Good post Thomas, but there is a perfectly legal way around this - distribute the patch file and mechanism that allows users to patch their own copy of 14.104a into the OS/4 kernel. Thereby no copyright binary code is distributed.


With regard to Mensys, my worry is that they will want a working ACPI - which, I suspect, will only be acheivable with the patched kernel. ACPI, on 14.104a, is broke and hangs badly. Besides, Mensys already have a 'beta' eComstation kernel, with the 'patched' extra HLT parts in it - but I suspect that the whole licensing argument (as per your post) prevents even Mensys from distributing it properly. Although, of course, only really Mensys are able to comment on that authoritatively!

Moby.
Title: Re: kernel affinity bug
Post by: walking_x on 2010.03.05, 21:10:25
Quote from: warpcafe on 2010.03.05, 14:46:51It is illegal.
I'm think, the only one, who make things legal or not - Mensys itself.
Because the common IBM position for OS/2 is to make it abandonware ;) Or forget at all.
Title: Re: kernel affinity bug
Post by: Fahrvenugen on 2010.03.06, 00:36:47
Quote from: walking_x on 2010.03.05, 21:10:25
Quote from: warpcafe on 2010.03.05, 14:46:51It is illegal.
I'm think, the only one, who make things legal or not - Mensys itself.
Because the common IBM position for OS/2 is to make it abandonware ;) Or forget at all.

That's a very ignorant way of looking at things and a severe lack of understanding of copywrite law.

Whether or not a company supports a product is irrelevant, the copywrites are still valid and fully enforceable.  Just because IBM no longer supports OS/2 does not mean they have given up their rights to it.  

Mensys has no say in this.  It is IBM's code, unless the copywrites for the code are transfered to Mensys (or Mensys has been given a license allowing for modified distribution, which they may very well have - I don't know what type of license they have with IBM, and it really doesn't matter to me).  

As a result, the way this has been distributed, it is illegal.
Title: Re: kernel affinity bug
Post by: David McKenna on 2010.03.06, 00:43:37
Quote from: mobybrick on 2010.03.05, 17:35:07


Good post Thomas, but there is a perfectly legal way around this - distribute the patch file and mechanism that allows users to patch their own copy of 14.104a into the OS/4 kernel. Thereby no copyright binary code is distributed.


  They do this occasionally - most recent: ftp://ftp.Linking to this site is not permitted on our forums/Archive/os2krnlSVN2021.zip

  However, I am sympathetic with walking-x; the whole 'illegal' argument is something only a lawyer in the Ministry of Silly Walks could love....
Title: Re: kernel affinity bug
Post by: Fahrvenugen on 2010.03.06, 01:46:46
Quote from: David McKenna on 2010.03.06, 00:43:37
Quote from: mobybrick on 2010.03.05, 17:35:07


Good post Thomas, but there is a perfectly legal way around this - distribute the patch file and mechanism that allows users to patch their own copy of 14.104a into the OS/4 kernel. Thereby no copyright binary code is distributed.


 They do this occasionally - most recent: ftp://ftp.Linking to this site is not permitted on our forums/Archive/os2krnlSVN2021.zip

 However, I am sympathetic with walking-x; the whole 'illegal' argument is something only a lawyer in the Ministry of Silly Walks could love....

I see what you're saying, but the legalities of this kernel are a little more significant then you may see.

If you're just using eCS / OS/2 at home, then you're likely correct in that it is unlikely that anyone will care - or even know - what kernel you are using.

However part of my use and involvement with OS/2 includes implementing and supporting OS/2 based solutions in businesses and professional environments.  Most recently I've found a number of situations where I've been able to implement effective OS/2 based solutions in non-profit groups.  Any time I set up such a solution I have a responsibility to ensure that it is legal.  This includes having a license for every copy of OS/2 that I set up, it also includes not using a kernel that I know violates IBM's copywrite.

I can only speak of my own professional use of OS/2, however I am sure you'd find others who are using OS/2 for businesses purposes who won't use this kernel for similar reasons.

Title: Re: kernel affinity bug
Post by: RobertM on 2010.03.06, 07:16:03
Quote from: Fahrvenugen on 2010.03.06, 01:46:46
Quote from: David McKenna on 2010.03.06, 00:43:37
Quote from: mobybrick on 2010.03.05, 17:35:07


Good post Thomas, but there is a perfectly legal way around this - distribute the patch file and mechanism that allows users to patch their own copy of 14.104a into the OS/4 kernel. Thereby no copyright binary code is distributed.


 They do this occasionally - most recent: ftp://ftp.Linking to this site is not permitted on our forums/Archive/os2krnlSVN2021.zip

 However, I am sympathetic with walking-x; the whole 'illegal' argument is something only a lawyer in the Ministry of Silly Walks could love....

I see what you're saying, but the legalities of this kernel are a little more significant then you may see...

I have a question... (because I have no clue), but what if after the kernel they are working on is complete, they did a diff, and then created a script/program that simply modified the user's existing, legal kernel?
Title: Re: kernel affinity bug
Post by: Sigurd on 2010.03.07, 18:45:53
Hi,
thanks to all to you who cleared my mind (especially Thomas) - I will not use this kernel any more. I totally agree with those who say that if there is no clear legal status it is not O.K. to use it. And I have to admit: I did not research enough the backgrounds here and should have done this BEFORE using the kernel.

Sigurd
Title: Re: kernel affinity bug
Post by: AAA on 2010.03.08, 12:29:47
Quote from: RobertM on 2010.03.06, 07:16:03
I have a question... (because I have no clue), but what if after the kernel they are working on is complete, they did a diff, and then created a script/program that simply modified the user's existing, legal kernel?

I think you won't get such an answer, I never managed to get one.  :)

It looks like there are some people who are seriously against the new kernel for some known and unknown reasons.

It looks like for OS/4 team it is not a problem to distribute the new kernel as a patch to the official one. And this scares the opponents the most.
Title: Re: kernel affinity bug
Post by: Andi on 2010.03.08, 14:10:26
Quote
I think you won't get such an answer, I never managed to get one.  :)

It looks like there are some people who are seriously against the new kernel for some known and unknown reasons.

It looks like for OS/4 team it is not a problem to distribute the new kernel as a patch to the official one. And this scares the opponents the most.
I don't think there are much people who are against a new kernel. But most people do not want to do something illegal. And as long as some issues are not clear, they want to stay on the safe side.

My conclusion from all I've read is -
- patching your legally bought kernel is no problem
- share your knowledge how to patch the kernel, how to remove bugs or circumvent specific shortcomings is no problem
- patching in memory is preferred
- but distribute a patched kernel is illegal

Title: Re: kernel affinity bug
Post by: Andi on 2010.03.08, 15:21:05
Quote
Okay, comrades. That might perhaps be true, but it simply doesn't fu**ing matter, because that Kernel is property of a U.S., stock noted, SOX-compliant company that employs more lawyers on their own than there are in Russia perhaps. Your laws don't apply. That kernel is illegal until IBM tells it isn't. Get it.
You reverse a principle in law off most modern countries. 'Something is illegal when it is not stated as legal' - is wrong. It's the other way around. As long as not explicitly stated illegal, it's legal!

Only having a lot of lawyers doesn't assure all things they do are legal and others doing is illegal. f.i. think about some Microsoft and Intel judgments in the early past (yes even judgments not only illegal activities never brought to the court). Sure the OS/2 I use is restricted to the license agreements of IBM but _only_ that parts that do not violate the laws of the country I'm living. See applied law on Windows OEM license agreements in your country. Another example - as my country allows me to take backup copies of software and allows me to make limited copies of films/music for personal use, some restrictions the studios or software makers in the USA do impose on films/musics on that specific point do _not_ apply for me in my country!

Some sort of code analyzing may be prohibited by the license and/or law. Disassembly and re engineering is sometimes explicitly forbidden with some software. But I don't know if such activities were necessary for this kernel patch. I don't even know the appropriate kernel license on this point. Who knows that point of the license? And isn't there another point in the agreement which allows to patch some piece of code to circumvent bugs/drawbacks?

Another point when using this kernel will be, how much do you trust a program/patch which alters such a vital piece of your system? Is there a clear documentation what will be changed when you run the patch? And as warpcafe pointed out, does these changes have a negative impact on your other programs and how much testing was made at which quality level? And will be official support for your system if you use this kernel? This has to be answered by everyone by them self.

Of course Mensys will never sell a patched kernel until IBM allows it to do (which is not likely cause why should IBM invest only 5 minutes into this?). They simply can not sell something if there's the slightest possibility that IBM dislikes it if the do not want not lose the contract with them. I said 'dislike', beside all legal/illegal issues. But this is not a valid argument for the 'normal' user who do not need to take care off IBM in this respect as IBM do not take care about the 'normal' users since more than 10 years now.   

This is not to mislead someone to do something illegal. But I think the legal/illegal state of using a patched kernel is by far not as clear as the above statement may sound.
Title: Re: kernel affinity bug
Post by: Fahrvenugen on 2010.03.08, 19:24:48
Quote from: RobertM on 2010.03.06, 07:16:03

I have a question... (because I have no clue), but what if after the kernel they are working on is complete, they did a diff, and then created a script/program that simply modified the user's existing, legal kernel?

Hi,

That's a good question.  I'm not a lawyer, but from what I understand in normal circumstances I believe you should be okay patching your own kernel.  However given the history of this project and how things have been released, there are still questions in my mind.

Normally with copywrite law (and again, I'm not a lawyer so this is just what I've come to understand):

1.  If you install / use something you know is in violation (for example, if you downloaded an ISO of OS/2 that you don't have a license for) then you are the one who is at fault.

2.  If you use software that as far as you know is in compliance and you have a valid license for, but then it is later found to have code that has not been legitimately used, then it is the software provider that is at fault (a good example of this is when Microsoft released MS-DOS 6.0 with compression technology owned and develoeped by Stacker, and Microsoft did not have the license to include it in MS-DOS, but did so anyways). 

In this situation with the kernel patch things are a little less clear.  Distributing a patched kernel that IBM has not licensed for patched distribution is clearly illegal.  Distributing a patch file that you then apply to your own (licensed) kernel normally I'd guess should be okay, however given the history and limited information on this project, questions still arise in my mind of:

1.  Who owns the code contained in the patch?  Was it fully developed by the folks distributing it (in which case, they are free to do whatever they wish with their own code), or is there also code in it that they didn't develop themselves (in which case, they'd be bound by whatever license came with that code)?

2.  If there is code in the "patch" that was not developed by the people distributing the patch, presuming the people who developed this patch have a license to distribute code which mighht not be theirs, what license is it released under?  Does it allow for use in commercial settings?  Does it allow for use in  non-commercial/home settings?  Does it allow for further modification and redistribution, or is it a "take it and don't mess with it" type of situation?

Again, I have no clue if this is even an issue - it could very well  be that everything in the patch has been developed by the people distributing the patch itself, in which case there shouldn't be any issues that I know of.  And normally I wouldn't even ask these questions (the questions have never occurred to me when using a patch such as Patchldr from Daniela Engert for allowing memory recognition above 64 MB.  I have no doubt that she wrote the code for Patchldr).  However it all seems to be a somewhat grey area right now.

Don't get me wrong though - I would love to see further improvements in the kernel, I love to see bugs fixed and the feature set expanded.  However the current practice that just seems to be along the lines of "here's a file, try it out" without any real information on who developed the code and what license it is being released under (other then saying it is "free"), it has led me to ask some of these questions.

Also please note that I'm not trying to advise people one way or another on whether to try out this kernel or not.  That's entirely up to you if you want to do that, not for me to say.



Title: Re: kernel affinity bug
Post by: RobertM on 2010.03.09, 00:19:52
Quote from: Fahrvenugen on 2010.03.08, 19:24:48
Also please note that I'm not trying to advise people one way or another on whether to try out this kernel or not.  That's entirely up to you if you want to do that, not for me to say.

I cannot, unless enough information clearly establishes the legality of either a patcher or released kernel. Personally, I wouldnt... and most definitely on behalf of my customers, I cannot (I do work for and provide licenses for various county organizations).

Hoping some sort of legal solution to this comes up - otherwise it simply is not an option for me either professionally or personally.