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 ... 71 72 [73] 74 75 ... 87
Maybe that also explains why AHCI won't work: if the AHCI controller should expect a 64-bit base address for its memory mapped register space then OS/2 won't work with it ...

The error message:

Detecting extended memory size ... using INT 15 EAX=E820 'SMAP'
  63 MB starting at 1 MB
Not enough memory

seems to imply that the SMAP call to determine amount of memory miserably fails. That may have more than one cause: either the BIOS implementation of that INT 15 call is broken or, more likely, there are more and more boards that have large "system memory gaps" in the lower 4 GB area that they then use for PCI address space (so they have plenty of addressing space for old PCI cards that can only address 32-bit addresses) instead of addressing system memory.
The assumption of these boards is that you are using a 64-bit operating system that can address memory beyond 4 GB without any problem. If it is the latter then you are sadly out of luck using OS/2.
I don't know if changing the processor on the very same board qualifies as changing the board in this respect. But I think that is possible.

Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 24, 2018, 12:33:57 pm »
The answer is that for the OS4 kernel there currently only exist an experimental driver for ACPI called ACPI4.BPD (I seem to remember).
However that does not necessarily mean that you cannot use multiple cores.
OS4 comes with OS4APIC.PSD which allows to use multiple cores if your system still has the old style Intel Multiprocessor tables (Intel MP spec version 1.4) along with the newer ACPI tables.
Have you tried just using OS4APIC.PSD (preferrably with the /APIC switch) or are you forced to using ACPI on the system that you have ?

Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 20, 2018, 01:32:14 pm »
2Lars: Where to get??? On Hobbes. If the kernel is not properly work on your system, you should report that to the developers, so that they will fix it. But you don't want. So, who is guilty?

All available stuff is either on Hobbes, or at official webpage, All, who needs it, knows about it. os4apic.psd is documented in kernel readme's. At least, available command line switches. What else is needed? It is not ACPI implementation, because ACPI is separate from PSD. ACPI is available for interested testers (including me). It is a special kind of driver (a PDD, but it is loaded before PSD, and it communicates to PSD, so that PSD gets ACPI tables info from it. Alternatively, IRQ routing info can be get from MPTable). Drivers like CLOCK03c.SYS are mandatory, but they are loaded by kernel without the need to be written into CONFIG.SYS (the same way as CLOCK01.SYS. CLOCK03c.SYS is loaded instead of CLOCK01.SYS, and contains both CLOCK and TIMER drivers. Plus, it contains support for hi-res timer, based on HPET). The same for SCREEN03.SYS. There are also OEMHLP.BPD and ACPI4.BPD, which contain OEMHLP$ and ACPICA$ implementations. All these should be not written into CONFIG.SYS. Everything should be described in readme's, otherwise you can ask developers. They are responsive.

How do you know that I don't want ? In fact, I did install the OS4 kernel and along with it the OS4APIC.PSD.
The problem is that the OS4 components are spread across different places (there is no common zip, left alone an installation package). And it's unclear when and if you need ACPI4.BPD and OEMHLP.BPD.

Just to let you know: I have a 40-hour job and it has nothing to do with PC SW development. I don't have all day to find out how things work or where to find them. Then I have some own OS/2 related SW development going on. And then I have to maintain my existing OS/2 main installation and device driver development installation to ensure it is operational. Plus I have a couple of additional hobbies ...

Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 19, 2018, 03:29:28 pm »
You already gave the answer why nobody uses emsFS.IFS:

1) I did not even know such a thing existed. I don't know where to get it. I am sure that others have the same problem.
2) it requires using the OS4 kernel. Unfortunately that kernel does not properly work on my system and tends to freeze my system.
For the VAC 3.0 profiler I have made a fix (a replacement for CPPOPA3.OBJ) to work around a bug in DOSCALL1.DLL so that the profiler finally works (at least with windowed applications). That works with the eCS and AN kernels but it fails with the OS4 kernel.

What I often lack for the OS4 project is some information page that tells me what stuff exists, how it works, what the restrictions are and where to get them. For example OS4APIC.PSD is largely undocumented and I only found it by chance on the OS4 web page. It allowed me to use multicore CPU but since it is not an ACPI implementation I don't know what the implications are.
There are a bunch of other drivers like CLOCK03.SYS etc. where it's also not clear if these drivers are mandatory or not and if they have to be added to config.sys or if they are loaded automatically by the kernel.

Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 18, 2018, 06:36:49 pm »
A lot of words that makes it yet more complicated. So my questions are:
1) do you ONLY have HPFS386 partitions on your HD ? Or do you also have JFS partitions ?
2) have you been copying from G: to ramdisk ?
3) What driveletter does your ramdisk have ? It seems that it is neither F: nor G: so what is it ?
4) What is the switch to cache386 to explicitely turn on/off caching for a specific drive letter ?

Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 18, 2018, 02:25:39 pm »
You would think you are correct in that thinking. I would not use HPFS386 on a ramdisk if I had a choice, but it is a HPFS or HPFS386 type of a decision, so I have no choice in this matter, I am forced to run HPFS386 only. Since HPFS386 allows you to shut the cache off for the ramdisk created by QSINIT itself, as best as I can tell this should not a problem.

..and yet the numbers I see tell an entirely different story...

I am basing this last conclusion on the output I see from 'cache386 /o' command and throughput numbers I see from 'Lars Commander' during a file copy operation. If I then compare the speed throughput for the ramdisk with the cache ON and OFF I see the following:

1) HPFS386 cache ON - 600 Meg file copy from HD to ramdisk
Peak => 108,586K
Avg => 104,278K
Last => 108,420K

2) HPFS386 cache OFF
Peak => 53,079K
Avg => 26,325K
Last => 27,736K

You leave it completely unclear if "cache386 /o" turns off the cache for ALL HPFS386 formatted partitions or only for the Ramdisk. Then you leave it completely unclear if you were copying from/to a HPFS386 formatted partition to/from a HPFS386 formatted partition or to/from a partition unaffected by the cache setting.
I have the impression that both source and target partitions were HPFS386 partitions ...

Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 17, 2018, 08:22:37 am »
Why would you use HPFS386 on a ramdisk anyway ?
Optimizing sector accesses is irrelevant for a ram disk. Caching will even make things worse: you waste additional memory for no gain in speed (after all, on a ram disk, each data sector is already in memory ...)
And it does not look like the OP cares about the file access protection features that HPFS386 offers on top of HPFS.

However, I don't know if you can load HPFS.IFS and HPFS386.IFS at the same time. Most likely not ...

As to STRAT1 method: as far as I can remember from the OpenJFS code I think JFS.IFS will fall back to the STRAT1 method when it cannot find a STRAT3 (flat addressing) entry point. Of course that is irrelevant nowadays as the 32-bit (most recent) OS2DASD.DMD supports the STRAT3 entry point. But the old 16-bit version of OS2DASD.DMD did not.
On the other hand, I think that JFS.IFS will only work with the new OS2DASD.DMD + OS2LVM.DMD.

Also: VFDISK.SYS (the virtual floppy disk driver, a legacy block device driver) only supports the STRAT1 entry point. But given the fact that you can only format virtual floppies to FAT anyways that should not be a problem.

Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 15, 2018, 11:13:32 pm »
You are missing the point. QSINIT uses physical memory beyond the 4GB border. And THAT makes it so valuable. RAMIFS steals from the memory available to the OS.

Internet / Re: Firefox and Traps
« on: April 12, 2018, 12:42:49 pm »

I am beginning to believe that Andi is right about the problems with LIBPATHSTRICT.

there exists a kernel data structure called "PTDA" (per task data area") that effectively exists for each process started.
Within that structure there are 2 pointer fields that can take a pointer to the BEGINLIBPATH and ENDLIBPATH strings respectively.
This effectively means that each process can define its own BEGINLIBPATH and ENDLIBPATH. However, I can see no such field for the LIBPATHSTRICT setting (which can take on 2 values: TRUE and FALSE).

That leads to the conclusion that there must be a GLOBAL list somewhere in the kernel that remembers which process asked for LIBPATHSTRICT in which case, when the process execution leads to loading of DLLs, the process will, if LIBPATHSTRICT is TRUE, preferrably load from its BEGINLIBPATH setting before it loads from any location defined in LIBPATH even if a DLL of the same name has already been loaded (and is still loaded) from a different directory.

A GLOBAL list will likely have a limit ...


I would love to believe that. However I also have these problems when I don't run Firefox at all.
But again, memory is the problem. When I run EPM.EXE and subsequently close it, I can observe that it leaves an endless sequence of memory "holes" in upper shared memory. That is due to the fact that the DLL that it loads (ETKE603.DLL) specifies trillions of small memory objects (it contains 234 memory objects: who compiled and linked that stuff ?). And for each memory object, 64 kByte of memory is allocated (even though they are considerably smaller).
When EPM is closed the DLL is unloaded but the fragmentation remains.

Are you sure it is a Firefox problem ?

Sometimes I have reboots if I just open the Master volume control (volume.exe). And I had it on other occasions starting applications. But I also had occasions where I would get a "page fault" exception in Ring 0 (for which I generated a system dump).
I think there is a fundamental flaw in some very basic system component. That could be the OS virtual memory manager. But it can also be DOSCALL1.DLL as that is used by about any process that is started.
I think the virtual memory manager is the more likely culprit. And it much looks like it is a serialization issue (access not properly serialized on updating memory structures etc.) as it only happens occasionally.
If you have Theseus: run "getws.exe" and watch your system reboot ...

Comments, Suggestions & Questions / Re: Censorship complaints
« on: February 23, 2018, 09:25:59 am »

I dare to disagree. I am losing more and more interest in this forum because there is so much "white noise". And I am a native german speaker and often enough I don't understand one single word of what Andreas is trying to say (also when he answers on the german forum).
Especially if the real solution to the problem of the original OP is very easy to answer. Andreas tends to flood people with information they have not asked for.

Article Discussions / Re: OS2VOICE RPM Server
« on: February 21, 2018, 10:21:11 pm »
WIC.EXE can do the same from a commandline.

Article Discussions / Re: OS2VOICE RPM Server
« on: February 21, 2018, 03:26:05 pm »
I don't know. But why don't you look here:

? That should give you an idea, at least. I think everybody has read-only access to that directory ...

Pages: 1 ... 71 72 [73] 74 75 ... 87