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 ... 8 9 [10] 11
Programming / Re: New OS/4 kernel :: SVN4222
« on: August 21, 2014, 11:25:29 am »
The latest  versions of Panorama also support PAT where MTRRs cannot be set up properly.
I'd appreciate a less biased information flow.
To be more precise: PAT support is in GRADD.SYS which is used by Panorama.

Hi Lars

I just pushed the files to github:

My only observation is that the git client didn't recognize any change on "hwman.xh" when I replace it over the original final.  Was it any change on it?

Thanks for sharing.

It's well possible that hwman.xh did not change. In any case, it would be regenerated from file hwman.idl by the SOM compiler.

I just took the chance to rework the HW Manager replacement WPS class (HWMAN) and uploaded to Hobbes.
Who cares about HW manager ? Probably nobody. So what's the real deal ?
It comes with full source code that is extensively commented. It's meant for everybody who is interested in starting WPS programming.
That said, I tried to comment the stuff that is not really documented anywhere ...

Martin (if you are reading), I think it is a good idea if you update GITHUB with this new update ...


Hardware / Re: ecs on actual desktop PC
« on: May 29, 2014, 08:48:47 pm »
pci.exe reports this for the graphics card:
Vendor 10DEh NVIDIA Corporation
Device 0FC6h GK107 [GeForce GTX 650]

I am using Panorama 1.06 (the latest version, currently).
I have not tried with SNAP but I expect problems on an SMP system. At least that's what is said about SNAP and SMP systems. I don't know if SNAP supports this NVidia chip. Is there a readme for SNAP that could tell me ?

Is there some BETA version of SNAP that has fixed SMP support that I could test ? I'd test even if SNAP only offers VESA support on this chipset.

Hardware / Re: ecs on actual desktop PC
« on: May 29, 2014, 11:29:46 am »
In the meantime I have found out this:

1) I had "AHCI BIOS" enabled in UEFI BIOS. What it does is to enable some AHCI BIOS that shows which hard disks/CD-ROMs are connected to the AHCI ports and if SMART is enabled for them, and obviously some other stuff. Once I disabled that I was able to boot the eCS 2.2 beta DVD even in AHCI mode.
Note: disabling "AHCI BIOS" did NOT mean to disable AHCI ! There was another UEFI BIOS configuration option to select among IDE compatibility/RAID/AHCI. THIS is the option that selects if you use AHCI (or IDE compatibility mode instead).

2) eCS 2.2 beta uses the 14.106 kernel. It looks like this kernel fixes a couple of things compared to the 14.105 kernel that came with eCS 2.1. I'd say it's the best kernel (and also the last kernel ever distributed). I am using all 8 cores and that works fine too.

3) On this MOBO, ACPI is a necessity. If I don't use ACPI.PSD on this MOBO, the kernel will trap right away already on system start.
The eCS 2.1 install CD does not enforce the use of ACPI.PSD and even if it did, the version of ACPI.PSD that was delivered with eCS 2.1 was still heavily broken. eCS 2.2 on the other hand selects ACPI.PSD as a default and it's also the 3.22.03 version which is the latest at present date. It works considerably better than early versions of ACPI.PSD.

4) if you have AHCI enabled you can and should set up the installation process to ONLY use the OS2AHCI.ADD driver. That is you neither need DANIS506.ADD nor DANIATAPI.FLT nor the IBM pendants and you can deselect these drivers already in the custom installation menu. However you might need to specify the /!r parameter on the OS2AHCI.ADD command line. This will prevent the AHCI ports from being reset. Resetting the AHCI ports results in a boot hang on my system.

In the meantime I have enabled "native command queueing" (NCQ) by specifying the /f /n parameters for OS2AHCI.ADD. Works like a charm. I am using OS2AHCI.ADD version 1.32 which is the latest one at current date. I seem to remember that eCS 2.2 beta DVD also has this version.


Utilities / Re: Flash 0.4.2 - 24.02.2014.
« on: March 05, 2014, 08:26:56 pm »
I know.  There is no trap screen. If it is possible to log something that would be helpful via the com port I can do that.

Do you have a sound driver installed ? If yes, I suggest to REM it out in config.sys and see if the trap/reboot goes away.

Hardware / Re: Two Sound Cards on OS/2-eCS
« on: March 05, 2014, 08:18:25 pm »
Thanks for the replies.

Sorry, I didn't actually mean two "cards" , I actually mean two "chipsets", I just noticed I was not clear. But I understand more about it now. But I think we are missing some tool to administrate the sound cards a Windows has.... but I think we need first to have more audio drivers :)

I also want to test the test USBAudio drivers, that's why I try to figure it out how to mnage two chipsets on OS/2-eCS. But I still can not make the USB audio devices that I have to work yet.

1) There IS a tool to administer sound cards in OS/2. You will find it as "Multimedia Configuration" in the "System Configuration" folder.

2) Multiple sound cards: this is a bit involved. When you install a sound driver, apart from other things, the MMPM2.INI file in the \MMOS2 folder will be updated. That file creates sound devices with names as Waveaudio01and associates these devices with the real device driver name like say USBAUD1$ and therefore with a real device driver.
If you had more than 1 of the very same sound card there is a logic to assign device driver names, the first one would be USBAUD1$, the next one would be USBAUD2$. Again, each device driver name is associated with a distinct device name: USBAUD1$ -> Waveaudio01, USBAUD2$-> Waveaudio02 etc.
The device names are subsequently used by applications and even the REXX MMPM API to say play a sound file on a specific sound device. For applications there exist API calls to query what devices (device names) exist in a system, an application can therefore build up a choice list to allow the user to pick a specific device.

Just to mention it: USBAUDIO.SYS has a fixed device driver device name of USBAUD1$. In short: you will only be able to load one instance of USBAUDIO.SYS.
However that is no limitation as USBAUDIO.SYS itself can handle multiple USB audio devices. However it will only ever pick the "first" (where "first" would be the one that was found first on the USB bus) USB device to play etc. as there is no selection logic in USBAUDIO.SYS to pick a specific USB audio device. If you unplug a device, USBAUDIO.SYS will pick the next available USB audio device remaining.


The one thing that bothers me is that the OS/4 team decided to drop trace (static/dynamic tracing (TRACE) and as far as I understand also performance tracing (STRACE)) support and I don't know for which reason.
As a consequence that means that people using the OS/4 kernel will not be able to take a trace for the USB drivers that I have reworked and that David took over. There are other drivers like OS2DASD.DMD that also make use of tracing as well as the (original OS/2) kernel itself.
That said, we (David and I) will not be able to support people that use the OS/4 kernel who have problems with the USB drivers as they won't be able to take a trace. The best we can do is fix a trap in any of the USB drivers where a trap screen exists (this scenario does not require tracing to work, tracing is helpful if functional oddities occur that don't lead to a trap but rather to some odd malfunction).

I think users should be aware of that.


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


Pages: 1 ... 8 9 [10] 11