Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Lars

Pages: 1 ... 70 71 [72] 73
Programming / Re: OS/4 kernel and extended KEE
« on: January 18, 2014, 04:02:53 pm »
And one remark for all. If you downloaded QSINIT to "look at later" - update it.
At least for ram disk (a lot of serious bugs was fixed since "new year release" of it).

It would be helpful to state where exactly the up to date version can be found.
There is one version here:

but obvously the current version can be found here:

Are you going to move this latest version to ?


Programming / Where do I find hd4disk.add, acpi4.sys ?
« on: January 15, 2014, 12:24:30 am »
I have read about these drivers but they are not contained in the OS/4 package ? Is there any place I can find them ?


Programming / Re: OS/4 kernel - my first impressions
« 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).

1) STRACE is something different than TRACE. STRACE performance tracing is not all that important. But ordinary tracing via TRACE is important.

2) getting COM output via serial port is not a viable replacement for tracing. How will I get output from an end customer's system ? Asking the customer to create a COM port log ? He is just going to show me the stiff little finger ...

Why do you think did I add tracing to the USB drivers ?


OS/4 kernel does not support the TRACE and TRACEBUF statements. It displays that these statements are not valid and continues to boot (the same holds true for VIRTUALADDRESSLIMIT but I guess that was intentional).
This is even true with the OS/4 debug as well as retail kernels.
This is a serious limitation because for example it's the only way for David's / my USB drivers to log operational info on a user's end machine. Without any tracing, it's impossible to determine why a driver won't work on a user's machine (except for flat HW traps which can be located by other means).
Again, this renders the OS/4 kernel incompatible with the existing OS/2 kernels.


Programming / Re: OS/4 kernel - my first impressions
« 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.

Programming / OS4APIC.PSD - /APIC switch does not work
« on: January 08, 2014, 11:12:17 am »

I could eventually attribute the OS/4 kernel hang to OS4APIC.PSD when I use the /APIC switch (and I did have "preload=1" set in OS2LDR.INI).
Apparently this switch is supposed to bring the system into "symmetric mode", that is, using the IOAPIC instead of the good old PIC controller of stoneage PCs and support > IRQ 15.

Unfortunately, on my system because of either broken MP tables or IRQ router chip incorrectly set up by BIOS, this is the ONLY mode I can run this system.
Therefore "PIC mode" or "virtual wire mode" (/PIC and /VW switches for ACPI.PSD) do not work for me.

When I tried to use ACPI.PSD (with no switches / in "symmetric mode") it would again lead to a hung system, much like using OS4APIC.PSD /APIC.
But I think problems with ACPI.PSD could be expected as ACPI.PSD patches the kernel in memory (for reasons I forgot) and therefore only supports a handful of kernels (I don't know what it does if it finds it cannot patch a kernel). Certainly not the OS/4 kernels.
In short: ACPI.PSD with no switches (in "symmetric mode") is the only thing that works for me. And that precludes use of the OS/4 kernel.

I would believe that OS4APIC.PSD does not properly enable symmetric mode when using /APIC switch.

Note: at one point in time I read the MP tables and "translated" the contents regarding interrrupt assignment into a documentation text file. If any developer is interested ...
I could also dump the MP configuration table from Theseus in binary form ...


Programming / OS/4 kernel - my first impressions
« on: January 08, 2014, 10:29:15 am »

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):
; Kernel number from kernel list section to be loaded by default

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

; Debug options

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

; 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

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

; 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!

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

; 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:

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

; 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,
preload = 1

[kernel]   =  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


Programming / Re: OS/4 kernel and extended KEE
« on: January 07, 2014, 09:42:38 am »
Forgot to say:
1) I have IBM bootmanager installed as I have 2 OS/2 installations on this machine: 1 for debugging, 1 for normal use, both of which use the SMP kernel (debug and retail respectively). I replaced OS2LDR on the debugging partition.

2) the debugging partition where I tried to run OS/4 kernel is formatted to HPFS

Programming / Re: OS/4 kernel and extended KEE
« on: January 07, 2014, 09:17:58 am »

By the way, does the debug kernel (os4krnl) support:
1) the full KDB command set ?
2) also work with UDP instead of serial interface ?

1) yes

2) I do not know if anybody test it.

It would be great if you can show comport log.

I do have a com port on this machine, unfortunately I don't have a com port on any other of my machines available. Therefore I cannot create a log.
That's why I am using ICAT via UDP and not via serial interface ...
ICAT via UDP DOES have a window to capture all KDB output, unfortunately it is limited in the way that the system must be fully up and running (network driver loaded, netbind.exe loaded ...)


Programming / Re: OS/4 kernel and extended KEE
« on: January 07, 2014, 08:26:00 am »
I got the SVN revision 4160 (assuming it's the most available up to date). I started off with a system that had the 14.104a_SMP debug kernel running (and therefore the SMP version of DOSCALL1.DLL installed) and also ACPI.PSD installed:

1) I copied OS4LOGO, OS4KRNL, OS4KRNLR, OS4KRNL.SYM, OS4KRNL.INI, OS2LDR, OS2LDR.INI to root directory

2) I copied CLOCK03B.SY? to \OS2\BOOT

3) I copied OS4APIC.PSD and OS4APIC.SYM to \OS2\BOOT

4) initially I did not copy DOSCALL1.DLL to \OS2\DLL but I tried later

5) I modified OS2LDR.INI (only the changed parts):
preload = 1
os2krnl      =  OS/2 debug,ALTF2
os4krnl      =  OS/4 debug using config.os4,LOGSIZE=4096,PRELOAD,CFGEXT=OS4,ALTF2,CTRLC
os4krnlr     =  OS/4 retail using config.os4,LOGSIZE=4096,PRELOAD,CFGEXT=OS4,ALTF2

6) in root dir I created a CONFIG.OS4, I removed all of ACPI.PSD, added OS4APIC.PSD /APIC, removed TIMER01.SYS, added BASEDEV=CLOCK03B.SYS

The result was an IPE for os4krnl as well as os4krnlr and a hang for os2krnl. It was the very same after I also replaced DOSCALL1.DLL with the one from the OS4 zip file.

What am I doing wrong ? I took a dump when the IPE for the os4krnlr happened (I have TRAPDUMP=R0,X: set in config.sys or config.os4, however this did not work for the os4krnl) but PMDF will not even let me read the created dump. Looks like PMDF cannot find a proper kernel revision string in the dump, after looking into the dump I identified it to be 15.1_SMP.4160 but I am not sure about that either.
Not being able to read a dump file is a severe limitation for me, I use this system as a MUT for device driver debugging.
By the way, does the debug kernel (os4krnl) support:
1) the full KDB command set ?
2) also work with UDP instead of serial interface ?


Programming / Re: OS/4 ? QSINIT ?
« on: January 06, 2014, 08:48:44 pm »
Veit's PCIBUS.SNP causes problems with QSINIT, not OS/4. Ok, I can contact Veit or fix it in available code. But who will replace current version in ALL eCS installations?

I could always address this to Roderick Klein from Mensys. I once wrote a REXX script to patch a (minor) problem in OS2LDR. They took it and eventually ran it against all copies of OS2LDR on the installation CD-ROM. The patched OS2LDR became part of the build tree for the CD-ROM.

For updates of drivers like PCIBUS.SNP: a WPI could be created from it and then installed via the eCS Update utility that was written by Chuck McKinnis. That is exactly what it was created for.


Programming / Re: OS/4 ? QSINIT ?
« on: January 06, 2014, 08:41:38 pm »
2) from the website, it's completely unobvious of what the latest version is for the OS4 core project. I'd go with the SVN revision numbers but I could never be sure. It's also not clear what version was reasonably stable and what version was not. I would also think it would be a good idea to remove all versions that proved to be too unstable for most testers.

3) it's completely unobvious in how far the QSINIT project relates to the OS4 project. Does QSINIT "overwrite" the OS2LDR contained in the OS/4 zips ? What would be the benefit to use QSINIT in favor of the OS2LDR that comes with the OS/4 kernel zip ? Is that the same group of developers of these 2 projects ?

4) there is no FAQ that would collect common problems or such. Also there is about no documentation. All the information is contained in the few postings floating around on the os2world website. Who is going to bother and go through the effort to test the OS/4 kernel if he is more or less completely on his own ? Not too many people I would think ...

For me, 2) and 3) and 4) are the most pressing problems

2) latest ver is here

3) you can use QSINIT instead of OS2LDR contained in the OS/4 zips

4) if os2word  wants,   it is possible to do a kind of wiki

Why does the QSINIT kernel not become part of OS/4 and replaces the one from the OS/4 package ?


Programming / Re: OS/4 kernel and extended KEE
« on: January 06, 2014, 08:34:53 pm »

how did you enable OS2APIC? I added it as PSD=OS2APIC.PSD in config.sys, but boot hangs at CLOCK01.SYS, both with standard loader and QSINIT. Any parameter required?


Why would you want to use OS2APIC.PSD ?  If you use the OS/4 kernel you might as well use OS4APIC.PSD which is contained in the OS/4 zip file. Or is there any good reason not to do so ?

OS2APIC.PSD is rather limited in that it does not support IRQs > 15 which I believe is equivalent to the /PIC (or maybe /VW) mode of David's ACPI.PSD. Also OS2APIC.PSD has not worked on my system. My system seems to have broken MP tables. It only works properly in symmetric mode (using the IOAPIC instead of the old-fashioned PIC).
I believe the /APIC switch of OS2APIC.PSD was never completely implemented. It just does nothing on my system.


Programming / Re: OS/4 ? QSINIT ?
« on: January 06, 2014, 01:21:35 pm »
About the problems with Veit's PCIBUS.SNP, see:,176.msg1453.html#msg1453


Pages: 1 ... 70 71 [72] 73