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 - Doug Bissett

Pages: [1] 2 3 ... 100
Setup & Installation / Re: OS2DASD hangs after 1st stage installation
« on: January 14, 2022, 06:37:22 pm »
I see three problems here.

First, Arca Noae cannot support eCS, in any flavor. ArcaOS is a different version of OS/2, and they are only licensed to work with what is in ArcaOS, for use with ArcaOS. They can distribute drivers, that were not produced by IBM, for use with any version of OS/2.

Second, it appears that the machine is not compatible with the requirements for ArcaOS. Is it possible, that there is a BIOS setting that prevents anything from writing to track 0? If so, make sure that it is turned OFF.

Third, OS2DASD.DMD has not been updated since IBM quit, in 2001 (that is about to change, but probably only for ArcaOS 5.1, and the change likely won't make any difference, in this case. it is for something else).

From the OS2DASD.DMD, in ArcaOS 5.0.7:
Code: [Select]
[C:\OS2\BOOT]bldlevel os2dasd.dmd
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#IBM:14.105#@ IBM DASD Manager
Vendor:          IBM
Revision:        14.105
File Version:    14.105
Description:     IBM DASD Manager

If there is no setting to prevent writing to track 0, my bet is that this is not a problem with OS2DASD.DMD, but with something that loaded previously. You might try making sure that you don't use AHCI. There was a time when the first loaded (AHCI, or IDE) would take control of the controller, when there is no BIOS setting. ArcaOS, by default, loads AHCI first, when the controller is capable (but it may not work that way. Early AHCI BIOS support was not very good).

Hardware / Re: Iomega ZIP 100 IDE
« on: December 30, 2021, 11:26:41 pm »
I am guessing, that you need to mount a disk, and use LVM to assign a drive letter (same as required by USB sticks). That would need to be done for every disk, if it is actually the answer.

Setup & Installation / Re: VirtualBox and Warpin (wic.exe)
« on: December 30, 2021, 11:22:05 pm »
A dumb question..

Are the OS/2 Additions even really changed that often, or does their build system just automatically bump the release version every time they cut a new one?

I’m basically wondering if it’s even worth updating them, really?

From what I have seen, the date, and time, on the files gets changed, at every release, but if you compare them to the previous ones, they are not really changed very often. They do get changed sometimes, but the only way to find out is to do a compare on the files. The safe, and easy, way is to always update, whether the files were actually changed, or not.

Setup & Installation / Re: VirtualBox and Warpin (wic.exe)
« on: December 28, 2021, 08:36:36 pm »
Haven't tried though.

I did try, a few years ago. It is actually pretty easy to build a WarpIn installer. The problem is, that you need the updated files, before they are released, so you can build the installer, and that installer needs to be included in the release. Oracle isn't interested in any of that because they don't have an OS/2 system to run WarpIn to build the package, and if they don't build it, they won't include it (you never know what might be in an externally produced package, so they won't do it).

After much experimenting, I decided that a REXX script was the answer, but they won't include that either. My script is now very much out of date (it doesn't include the access to shared folders), and it really isn't needed any more, since ArcaOS now installs that stuff for you (but only at an initial install, I think).

One very important thing, is: DO NOT copy the LIBC stuff into your system, unless you really want trouble. The stuff in the Extensions is way out of date, and you could replace the up to date stuff, if it is already installed.

Programming / Re: Can 64-bit programs run on OS/2?
« on: December 28, 2021, 08:14:07 pm »
It could be implemented as a kernel driver (like a RAM disk driver) that could do 4 MB page directory table remapping above 4 GB.

That already exists, and has been around for a number of years now. QSINIT can make memory, above 4 GB, available for other things (not just for a RAMDISK), but nobody has expanded on that capability, to actually make that memory usable by anything except the RAMDISK (it needs an API, to make it usable by other things).

ArcaOS uses the QSINIT base for a number of things, including UEFI support (not, yet, released) and a RAMDISK (I am using a 12 GB RAMDISK, formatted as JFS). Writing an API is not for beginners, and the very few people who might know what is needed, are far too busy trying to keep the base OS running on newer hardware.

FWIW, it should be possible to use the QSINIT memory support, without an API, but it means that somebody, who knows what they are doing, needs to actually do it.

Applications / Re: ArcaOS 5.0.7 Samba
« on: December 15, 2021, 11:23:32 pm »
Has anybody been able to make Samba work with 5.0.7? There is no lmhosts directory created on this install.

I have trouble with SAMBA, when there is a windows machine on the network, but it usually starts to work about 20 minutes after boot. If they are all ArcaOS machines, it usually starts to work in about a minute after boot.

lmhosts is a file, not a directory.  I have found that it works better if you put your machine names, with IP addresses, in the HOST file, and eliminate the lmhosts file. I also turn off the setting to create the lmhosts file. YMMV.

Internet / Re: PMMail - corrupted folders?
« on: December 08, 2021, 07:49:59 pm »
You probably just, accidentally, clicked the mouse button, as you went past the folder. I have done that a few times. It is easy to recover, just close PMMail, and move the folder (directory) back where it is supposed to be. Open PMMail, and it should be back.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 26, 2021, 11:10:59 pm »
Is XUL marked to load high? Otherwise the only follow-up is to see if it's been LXLITE compressed? (not sure if DLLs get processed by LXLITE, I think they do...?)

They are all marked for high code. LXLITE is whatever they were shipped as. I am going to stay with /cache:132000 on my main machine. That seems to work as well as anything else. Changing Lazy write to /LW:16,60,12 doesn't seem to increase performance much. but it does seem to smooth out some of the peaks and valleys. I think I will put that back to /LW:8,30,6 and see what happens. /MINBUFFER:4500 /MAXBUFFER:15000 seem to be good numbers, for me.

Right click on the preference and choose reset would probably work. Otherwise with the browser closed, edit prefs.js and delete the line, after backing up prefs.js.

Okay, that works. It is not exactly obvious what Reset is going to do.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 26, 2021, 05:58:22 pm »

I tried that, with the appropriate changes. I really don't notice any difference, but I do have Firefox set to clear everything at shut down anyway. My RAMDISK doesn't retain information over a reboot (my choice, and I never tried it), but that shouldn't change anything. I didn't spend much time with it, but now, how do I remove that entry properly?

I did up my cache to 256000, on my main machine. It created the cache, but then Firefox won't start, complaining that XUL is defective. I put it back to 132000 and it is working.

Then, I have been playing with LW, MIN and MAX buffers. That is possibly making some difference. I will know more on Monday morning, when I do my backups. There is an indication that the single processor machine doesn't like it much, so that will go back to what it was (the LW part anyway).

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 24, 2021, 09:50:54 pm »
I'm curious what you guys see for your running systems?

This is from my main system, with cache:132000:
Code: [Select]
Nonswappable Memory analysis:
Apps & DLLs      = 0003C000 ->     240K -> 0.234M
Process overhead = 002F1000 ->    3012K -> 2.941M
DD allocated     = 0D453000 ->  217420K -> 212.324M
DOS              = 0001B000 ->     108K -> 0.105M
VDisk            = 00000000 ->       0K -> 0.000M
File system      = 00051000 ->     324K -> 0.316M
Kernel code      = 000B1000 ->     708K -> 0.691M
Kernel data      = 01166000 ->   17816K -> 17.398M
Kernel heap      = 00190000 ->    1600K -> 1.563M

Total            = 0EB93000 ->  241228K -> 235.574M

I am a bit puzzled about the DOS entry. DOS/WINOS2 is not installed on this system.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 24, 2021, 07:24:04 pm »
Physical Memory:  2793 mb

Yeah. That seems to be common on newer machines (I have heard of one, that only leaves about 1 GB for the user). They fill up memory with stuff, and that leaves less room for the user. I don't think that has anything to do with what we are talking about though (I could be wrong). I should check to see what is left in UEFI mode.

In any case, it seems that all of this is very machine dependent, and the results of making changes can vary widely. The main problem is to determine if it is actually worth the effort.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 24, 2021, 04:05:52 am »
This was the latest beta with the updated NSPR and NSS so that may be part of it.

Yeah. That version is not doing well. This is a typical ExceptQ report:

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 22, 2021, 08:56:42 pm »
The cachesize field implies that actual data cache is only 256M, which is what I'm struggling with.

That would appear to be the number of 4K buffers (but that is only a guess). If true, it matches your defined cache size.

Quote from: Doug Bissett on November 01, 2021, 08:25:47 pm

        /MINBUFFER:16000 /MAXBUFFER:84000

    Did you find a description of what these actually do? I have run out of places to look, and can't find anything.

Yes and no. There were some Warpstock presentations that touched on this. See "Dynamically Tuning the JFS Cache for Your Job" by Sjoerd Visser from 2009. P22 of that deck starts getting into the details of the JFS cache design, which is really about the logic of how the different buffers are handled, and the differences between actual data and metadata.

Interesting. It seems that they are all numbers referring to 4K data blocks.

Anyways, previously I had found my system to run best with VAL=3072. However, that meant my JFS cache would only go to about 64M, any attempt at bigger value would produce that "out of memory" boot message and a default cache size being substituted.

This doesn't make any sense. It implies that the cache, over 64M, goes into unreserved upper shared memory space (above what VAL reserves). Could be possible, I suppose, and it might explain some of the weird crashes that I see when I try to use larger values for VAL.

I think we can safely assume that it does not use (or even know about) PAE memory, so any memory above about 3.5G is likely out of the picture, although it is quite likely that it could use PAE memory, if somebody programmed it to use it.

I use VAL=2560, and going larger causes instability in my system (don't know why). The biggest JFS cache, that I can use, seems to be 132M, no matter what larger value I set in the IFS startup line. However, I just tried setting it to 256M, in a new install that defaults VAL to 1536 (way too small for actual use), and it did take it. The Sentinel memory watcher (XCenter widget) appears to show that the memory was allocated (from somewhere). I tried 512M (then 384M, then your number 1048567), VAL is still 1536, but now cachejfs shows only 132M, and Sentinel seems to confirm that. I never see an "out of memory" boot message.

So, it seems that 256M is the largest value that doesn't default to 132M, for me (that is probably a bug, I expect that 132M is the maximum acceptable). I don't see any indication of where the cache memory is allocated (private low, private high, shared low, or shared high).

Since I seem to be able to use 8 times the default cache size, I would think that changing MAX and MIN to 8 times their default value, would make sense, but that is only a guess. I need to do more reading. Thanks for the reference.

Which version of JFS are you using? The one that I am using is v1.9.9 from AN.


I found that that is only needed by VBox. It can cause problems elsewhere. I also gave up on VBox 5.0.51, and went back to VBox 5.0.6. For me, it is much more stable (meaning usable). I still need that setting, or I get the COM message. I do not put it in CONFIG.SYS. I do put it in the DragText Environment tab (without "SET "), in the VBox icon. That way, it is only used with VBox.

Also, you have VAL=1536, which may be too low. Thry increasing up to 3072 or whatever.

Yes, 1536 is way too low (even 2048 is too low). I use 2560, for all of my systems (even my antique IBM ThinkPad A22e, which is maxed out at 256 MB of real memory, but I don't try to run VBox on it). I have two machines that will run with 3072, but I still use 2560. The rest of my systems become very unstable if I use more than 2560. I also monitor the free upper, and lower, shared memory space. If I run win XP in VBox, lower shared memory drops to the 100 KB range, and upper shared memory still has about 1,200 KB. If I run win 7 in VBox, lower shared memory drops to the 50 KB range, and upper shared memory still has about 800 KB available. If anything else tries to run, lower shared memory can (and does) drop to zero. If that happens NOTHING works any more. I had to eliminate the AOO Quick Start thing, and Firefox Turbo, to clear enough shared memory space to be able to run win 7 in VBox. Even then, I sometimes need to reboot, before running VBox, or lower shared memory can be fragmented enough that something can't get what it needs, and bad things happen.

VBox, under OS/2 , is a delicate balancing act, and almost anything can push it over the edge.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 01, 2021, 08:25:47 pm »
so I bumped the cache up to 768M

Since I haven't tried this, for a long time, I decided to give it a shot. How did you get it to take 768m (I would assume that you used 768000 (K) as the cache size. When I try that, CACHEJFS shows me:
Cache Size:  131072 kbytes
which I believe is the allowed max now.


Did you find a description of what these actually do? I have run out of places to look, and can't find anything.

Pages: [1] 2 3 ... 100