pasha
Newbie

Posts: 21
|
 |
« 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.
|
|
|
|
|
Logged
|
|
|
|
|
Saijin_Naib
|
 |
« Reply #1 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?
|
|
|
|
|
Logged
|
|
|
|
pasha
Newbie

Posts: 21
|
 |
« Reply #2 on: 2010.03.03, 00:22:48 » |
|
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 ;-)
|
|
|
|
|
Logged
|
|
|
|
|
Saijin_Naib
|
 |
« Reply #3 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.
|
|
|
|
|
Logged
|
|
|
|
|
cytan
|
 |
« Reply #4 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
|
|
|
|
|
Logged
|
|
|
|
|
Saijin_Naib
|
 |
« Reply #5 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.
|
|
|
|
|
Logged
|
|
|
|
|
Sigurd
|
 |
« Reply #6 on: 2010.03.03, 08:30:42 » |
|
Hi,
and where can one get this new kernel? Would like to test it. Thanks for this.
|
|
|
|
|
Logged
|
|
|
|
AAA
Newbie

Posts: 29
|
 |
« Reply #7 on: 2010.03.03, 11:05:03 » |
|
OS/4 kernels are always available on http://ftp://ftp. Linking to this site is not permitted on our forums/
|
|
|
|
|
Logged
|
|
|
|
|
Sigurd
|
 |
« Reply #8 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
|
|
|
|
« Last Edit: 2010.03.03, 14:14:58 by Sigurd »
|
Logged
|
|
|
|
|
mobybrick
|
 |
« Reply #9 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
|
|
|
|
|
Logged
|
|
|
|
walking_x
Newbie

Posts: 9
|
 |
« Reply #10 on: 2010.03.04, 12:15:44 » |
|
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. 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.
|
|
|
|
|
Logged
|
|
|
|
|
mobybrick
|
 |
« Reply #11 on: 2010.03.04, 13:25:56 » |
|
Er, wrong, IMHO.  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?
|
|
|
|
|
Logged
|
|
|
|
walking_x
Newbie

Posts: 9
|
 |
« Reply #12 on: 2010.03.04, 15:03:21 » |
|
Look here  Especially to string "OS/4 kernel revision" 
|
|
|
|
|
Logged
|
|
|
|
|
Fahrvenugen
|
 |
« Reply #13 on: 2010.03.04, 16:28:15 » |
|
... 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.
|
|
|
|
|
Logged
|
|
|
|
|
mobybrick
|
 |
« Reply #14 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....
|
|
|
|
|
Logged
|
|
|
|
|