Author Topic: OS/4 kernel - my first impressions  (Read 4424 times)

Lars

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 20
  • Posts: 140
    • View Profile
OS/4 kernel - my first impressions
« on: January 08, 2014, 10:29:15 am »
Hallo,

ok I went through it. I tried SVN revision 4160. I copied OS4APIC.PSD and CLOCK03b.SYS to \OS2\boot. I created a custom CONFIG.OS4 file to load OS4APIC.PSD with the /APIC switch.
I enabled "preload=1" in os2ldr.ini

1) both, the OS/4 debug and also retail kernel trapped when they encountered valid CONFIG.SYS statements. In my case, that was the STRACE statement. It's the statement to control performance tracing in OS/2, see \OS2\BOOK\STRACE.INF.
That leads me to believe that the kernel will also trap on other statements it does not recognize and therefore it is incompatible with the existing kernel.
It should also be stated that with the performance tracing, IBM added a bit array to control which strace codes will be active or not (much like the bit array that exists for the trace codes) to the global info segment. I wonder if the OS/4 kernel also has this addition ...

2) I then removed the STRACE statements. The kernel would start to load showing it has initialized 1 CPU at "stage 2". Then it would sit there doing nothing. This was true for both, the debug and retail kernel. I had to power down the system.

3) I then stripped down CONFIG.SYS to the bare minimum. This time the kernel would start to load drivers but would hang when loading IBMKBD.SYS. Again, I had to power down the system.

I had the boot logo turned off via os2ldr.ini but I doubt that that would make a difference.

I have a pretty old box, about 5 to 7 years old, nothing fancy. It has only 1 (Intel) core. It's with MMX and SSE.

From what I can say, I would think that the new loader OS2LDR is ok (this was also true for QSINIT) but the OS/4 kernel is not.


This is my os2ldr.ini (beware of messed up line breaks):
[config]
; Kernel number from kernel list section to be loaded by default
default=1

; Waiting time (in seconds) after which kernel mentioned in "default"
; will be loaded
timeout=15

; Debug options
;dbflags=0x11
dbflags=0

; Debug port
; com port address
; no debug output if statment is omited (but log still accessible
; through copy from oemhlp$ - see below)
;dbport=0x3f8
;dbport=0xEC00

; Enable Ctrl-C check for kernel debugger. This is optional for kernels
; beginning from revision 2970. Older kernels always have this check enabled.
; This option ignored if no debug port specified.
; Ctrl-C check allows KDB popup when Ctrl-C is passed via serial link but
; adds two problems:
; - frequent serial port reads cause overall performance degradation
; - the serial port can't be used for something else except KDB because these
;   reads destroy data which are received by the port
;ctrlc=1

; You have full COM port link cable (with hardware flow control support)
fullcable=1

; Show PC memory table as it reported by BIOS, do nothing if absent
; or defined as 0.
; Warning: this option will make PAUSE on boot!
;showmem=1

; Hide from OS/2 one of memory blocks from list above.
; Block specified by start address (>1Mb, block at 1Mb required for OS/2
; boot).
; You can add up to five such keys into [config] section.
; note: OS2LDR ignore too small blocks (<64k) by itself.
;removemem=0x20000000

; Color values for the startup menu
; byte 0 - text color
; byte 1 - color of selected row
; byte 2 - background color
; byte 3 - border color
; defauls are:
;menupalette=0x0F070F01

; Show b/w tty style menu with ugly kernel selection by numeric key ;)
; It use BIOS text output only, so suitable for some strange reasons.
;ttymenu = 1

; Reset video mode to default 80x25, before menu output (fix for some
; strange BIOS bugs too)
;resetmode=1

; OS/4 kernel only (rev>=2075)
; Turn on memory files. Kernel will preload all files, located in:
; - BASEDEV and PSD statements of config.sys
; - os4krnl.ini
; - snoop.lst
; - and predefined list of files: PREVIOUS.DAT, ISAPNP.SYS, ISAPNP.SNP,
;   RESOURCE.SYS, CLOCK01.SYS, SCREEN01.SYS, KBDBASE.SYS, SNOOP.LST,
;   PNP.SYS, ACPI.CFG, IBMKBD.SNP, PCIBUS.SNP, PREVIOUS.ACP, PCIDEV.TBL
;
preload = 1

[kernel]
os2ldr.ibm   =  IBM OS2LDR,RESTART
os4krnl      =  OS/4 dbg kernel,LOGSIZE=4096,PRELOAD,CFGEXT=OS4,DBPORT=0,LOADSYM,CTRLC,ALTF2
os4krnlr     =  OS/4 retail kernel,LOGSIZE=4096,PRELOAD,CFGEXT=OS4,DBPORT=-1,ALTF2



Lars



ff4

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 13
    • View Profile
Re: OS/4 kernel - my first impressions
« Reply #1 on: January 11, 2014, 01:10:52 pm »
When you also had the chance to use the debug kernel, you also connected a debug terminal? There should be a sign what caused the hang, in case there is no output configure the dbgflags and dbgport config options. You might also want to try without the psd driver.

Lars

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 20
  • Posts: 140
    • View Profile
Re: OS/4 kernel - my first impressions
« Reply #2 on: January 12, 2014, 02:09:22 pm »
1) When I use the debug kernel, I always use ICAT via UDP (I don't have the need to debug INIT or INIT_COMPLETE). Unfortunately my host machine does not have a serial interface (only the MUT does). I am thinking about buying a USB to serial converter cable.

2) I cannot try without the PSD driver. Unfortunately, either my ACPI or my MP tables or the HW layout is broken to the extent that all interrupt lines only work properly when I am running the box in symmetric mode (IOAPIC instead of PIC) but the BIOS sets up virtual wire mode initially.
This is also true if I use ACPI.PSD: it will only work without any switch set. I guess this is due to the fact that this machine had WinXP installed initially and WinXP also runs in symmetric mode (provided the machine has an IOAPIC but this has now been so for a long,long time). And this HW was most likely not tested with anything else.

But ACPI.PSD does not work with the OS/4 kernel as ACPI.PSD needs to patch some places in the in memory copy of the kernel so that setting CPU offline and halting CPU will work properly (it injects its own processing).
Unfortunately, IBM did not export the relevant entry points into the kernel and that's why ACPI.PSD has to patch the in memory copy.
These patch points are obviously tied to specific addresses and ACPI.PSD only supports these kernels: 14.104a SMP debug, 14.104a SMP retail, 14.105 SMP retail, 14.106 SMP retail.

Boris

  • Sr. Member
  • ****
  • Thank You
  • -Given: 11
  • -Receive: 16
  • Posts: 310
    • View Profile
OS/4 kernel -- my own impressions
« Reply #3 on: January 14, 2014, 05:02:37 pm »
OS/4 kernel runs on my Intel Xeon server with two CPUs with OS4APIC.PSD /APIC driver very well.
Also it runs here on my laptop.

I also have an another non-SMP system running ACP2 and native non-SMP kernel -- I don't think I need to migrate to OS/4 or the latest kernel from Mensys, because both are SMP kernels.

Also I run the kernel from Mensys on my main SMP desktop, because I don't really need to migrate to OS/4 there, and I am too lazy to do it.

The primary goal of OS/4 kernel is to make OS/2 run on PCs that it does not run with the native kernel.
Actually you can get support from the Phoenix team and report bugs that are likely to be corrected, while no one develops the native kernel now.

The OS/4 kernel is rewritten in a lot of places, and its modernized source code is a good start to finally resolve the most well-known OS/2 issues.
LIABILITY DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! There are no claims, promises, or guarantees about the accuracy, completeness, or adequacy of the contents of my posts. Think on your own!

ff4

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 13
    • View Profile
Re: OS/4 kernel - my first impressions
« Reply #4 on: January 14, 2014, 06:45:06 pm »
1) When I use the debug kernel, I always use ICAT via UDP (I don't have the need to debug INIT or INIT_COMPLETE). Unfortunately my host machine does not have a serial interface (only the MUT does). I am thinking about buying a USB to serial converter cable.

I already replied in the other thread about strace. Better would be a com card as nobody can be sure that the usb serial adapter will work, esp in boot stage 1 & 2.

Boris

  • Sr. Member
  • ****
  • Thank You
  • -Given: 11
  • -Receive: 16
  • Posts: 310
    • View Profile
Re: OS/4 kernel - my first impressions
« Reply #5 on: January 14, 2014, 09:32:10 pm »
1) When I use the debug kernel, I always use ICAT via UDP (I don't have the need to debug INIT or INIT_COMPLETE). Unfortunately my host machine does not have a serial interface (only the MUT does). I am thinking about buying a USB to serial converter cable.

I already replied in the other thread about strace. Better would be a com card as nobody can be sure that the usb serial adapter will work, esp in boot stage 1 & 2.

I think the test machine does have the com port, but Lars is unable to get the log, because his main machine does not have the com port, so buying a usbserial adapter will help.
« Last Edit: January 15, 2014, 07:20:00 pm by Boris »
LIABILITY DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! There are no claims, promises, or guarantees about the accuracy, completeness, or adequacy of the contents of my posts. Think on your own!

Lars

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 20
  • Posts: 140
    • View Profile
Re: OS/4 kernel - my first impressions
« Reply #6 on: January 15, 2014, 12:03:57 am »
That's correct. My MUT (test machine) has a real COM port, my host machine (a notebook) does not.
The host machine is Windows 7 with eCS running in VirtualBox (and this setup DOES work with ICAT via UDP).
If it does not work with eCS under VirtualBox I will still be able to capture a log in Windows 7 (the USB to serial converter will surely contain support for Windows 7).

Boris

  • Sr. Member
  • ****
  • Thank You
  • -Given: 11
  • -Receive: 16
  • Posts: 310
    • View Profile
Re: OS/4 kernel - my first impressions
« Reply #7 on: January 16, 2014, 07:55:18 pm »
1) both, the OS/4 debug and also retail kernel trapped when they encountered valid CONFIG.SYS statements. In my case, that was the STRACE statement.
The latest (SVN revision 4163) version of the Phoenix kernel now does not trap because of the STRACE statement in the CONFIG.SYS, although the tracing support is still discontinued and will never (or soon) be implemented again.
« Last Edit: January 16, 2014, 08:01:23 pm by Boris »
LIABILITY DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! There are no claims, promises, or guarantees about the accuracy, completeness, or adequacy of the contents of my posts. Think on your own!