• 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

Raiko

It seems to run fine on my system. RC6a, acpi 3.14, Core2Quad and Panorama.

osw

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.


djcaetano

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.

Joachim

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

DavidG

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

djcaetano


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

osw

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

osw

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

djcaetano

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

osw

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

osw

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


djcaetano

 
  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

Pete

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

rwklein

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

djcaetano


  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.