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

Pages: [1] 2 3 ... 7
Networking / Re: Reset the default os/2 password
« on: 2011.01.26, 19:37:58 »
Hi Jan,

I think that trick is for the OS/2 WPS lockup password, not for the LAN account?

Anyway, I'll send the util to those who have requested it...



Networking / Re: Reset the default os/2 password
« on: 2010.10.22, 21:09:32 »

Just sent it to you... let us know how you get on!


Moby -  Can I get a copy of your utility please?  Thanks...

(his forum username)

Current limits:

* 65,535 cylinder limit for OS/2 kernel on bootable devices (16-bit address in OS2KRNL)
* 2 TB maximum *size* supported by OS/2 ADD architecture for all block IO/DASD

I guess that there is no chance that IBM would give source ASM for OS2KRNL? We don't need code for the entire OS, just the kernel would be a start!


And why not. We still have some years in front of us. So if UEFI get large portion of the MB market there will be onli one solution: To make eCS UEFI compatible. And BTW Roderic did not mentioned SIZE of the HD but LAYOUT.

Hardware / Re: eCS 1.2 and 64 bit motherboard
« on: 2010.08.13, 01:40:33 »
If OriAl is using 1.2MR, there should be no problem. Best to use last Dani drivers tho.

But using original 1.2 on AMD64, IIRC, is fraught with problems. 1.2MR has updated APM and TESTCFG to work properly.


Single-core Atom's might work... but our ACPI solution doesn't yet work any dual-core Atom board that I've been able to find, even genuine Intel ones. Over a year ago I logged a ticket on the ACPI svn system, but no progress.

Dual-core Atoms will usually hang at startup or shutdown.


Thankfully Atom is just a weak-ass x86 intel chip with SSE so its not a big departure and runs fine already. ARM sounds tricky..

Yes, it should. But why static linking is not used, I do not know. If this was an pure OS/2 library then it would and OS/2 provides a static facility. The size of the program executables would grow (and overall, memory consumption would increase) and how items such as libc_sharedmem would work would need effort.

KLIBC needs a bit of an update IMHO, to fix some of the long-outstanding bugs and to work on the memory and pthreads situation.


2. Building apps with static linking under GCC - reducing reliance on a shared DLL in memory. Whether or not this is feasible I don't know - but it would appear to solve other problems IMHO.


Moby, do you think simply number 2 would alleviate these issues? I've gotten some info from RXU and am seeing the following:

After a few hours of running:
- Free Shared Memory: 44MB
- Free Memory in Private Arena that the process can allocate: 291MB

After shutting down services:
- Free Shared Memory: 245MB
- Free Memory in Private Arena that the process can allocate: 291MB

After restarting services:
- Free Shared Memory: 223MB
- Free Memory in Private Arena that the process can allocate: 291MB

The key being it seems that the private arena has a big chunk of available memory - currently more so than the shared arena starts with. If each (PHP, MySQL and Apache) had LIBC063 functionality statically linked, would that mean that EACH would have that 291MB available to it?

I am also suspecting that on most systems, the amount will be more... as I am allocating a bit of memory for JFS cache and such.

Storage / Re: JFS eating CPU resources?
« on: 2010.04.29, 00:01:23 »
JFS is subject to fragmentation far more than HPFS - this could cause a lot more work for the disk. Remember, JFS tries to get its performance by maintaining the disk head near where the next read/write will be and if there is heavy fragmentation then this performance objective is lost.

JFS is a ring 3 FSD (rather than a ring 0 for HPFS386) but this shouldn't cause the problem that you are seeing as the JFS code is much more tuned for SMP.

I'd look at the disk driver... I remember that some of the Adaptec drivers prevented the drives own cache working...


Interesting... but the script will need to make sure that MySQL is shut down nicely or db corruption could occur (or transactions borked)... but I guess you already thought of this :)

Look forward to see what you get cooked up. Doesn't solve my problems tho where one or two big requests need 3-400Mb of memory - and OS/2 can never provide it...

First, it's not just that LIBC063 exhausts the low memory arena on a single request (that isn't my problem). It also seems that (whether by design or by accident) under certain circumstances (for instance, when in use by Apache/MySQL/PHP) it does not clean up used memory.

That seems to be evidenced by the fact that under at least my setup, it's not a single large memory request causing the issue (that has never happened yet under my setup), but a collection of smaller ones over time that cumulatively exceed the available memory in the low memory arena. Otherwise, my "workaround" would not have alleviated my problem.

That's further evidenced by the fact that on my setup, no single request causes it. I can start a fresh copy of everything after a fresh boot and perform ONE certain medium sized (memory allocation wise) request with no problems. If the server is running half a day though, and I try the exact same single request with little to no activity on the server, things start to crash because of resource depletion.

So, perhaps the situation is some aspect of how Web/2 serves requests is different than the way Apache does. My guess is that Web/2 serves each in it's own process, and thus is freeing what memory is being used by LIBC063 upon the process's completion; while Apache perhaps is serving them all in one process via multiple threads, and thus not freeing the resources between requests until eventually the memory resources are depleted.

Possibly, but I have an alternative theory on this. You will need to use Theucus to confirm it, however.

Firstly, Web/2 uses a single process for webserving - it's Apache2 that uses multiple processes. I suspect that Apache2 simply gives you another 50Mb of working space in the shared memory arena, so the system will last long.

What's happening over time is that I suspect that the bits of memory that Apache uses for working memory (remember, Apache spawns a new process, a 'fork' for each client) and this grows over time as clients are serviced. These will use more memory and this is fine. They might leak memory, but I have not seen it. What does happen though is that the shared memory arena becomes fragmented - OS/2 can't find enough *contiguous* memory in the shared arena for a large request. So your large request fails at the end of the day because the shared memory is a mess - used by a DLL, LIBC063, which never drops out memory but is constantly alloc/freeing memory - there might (or not) be a leak, but the biggest chunk of free memory becomes too small.

The fixes are this are twofold, IMHO

1. Building LIBC063 so that apps use high memory
2. Building apps with static linking under GCC - reducing reliance on a shared DLL in memory. Whether or not this is feasible I don't know - but it would appear to solve other problems IMHO.

We need to start  bounty to get some work done on kLibC as there have been no updates for a while. Getting some of the memory issues sorted, plus some of the bugs, and even maybe full support for pthreads would be very desirable.



The problem is likely due to with problems in the low-memory arena. Many of the LIBC063 calls, in particularly PHP5, consume large amounts of low memory.

In one PHP5 app, I can exhaust OS/2 Apache2/PHP5/MySQL/LIBC063 in a single request. The request consumes 300Mb of low memory, and then exhausts with a weird error - sometimes a SYS3171 - but usually a LIC063 exception - but Thecus shows the shared memory arena as reaching 64Kb free and then PHP5 dies. On Win the calls run fine and consume 600Mb of RAM - but OS/2 can't allocate this and dies :( even on a 4Gb system.  As soon as exception occurs, the shared memory reverts to being free.

Under Win32 and Linux, PHP5 can routinely use 4-700Mb of RAM on busy systems - something we can't give it. Under OS/2, setting the PHP max memory limits aren't the problem as it is OS/2 that runs out memory.

Updating the PHP5/MySQL/Apache2 builds doesn't really help - remember, that even the order of things started in the startup.cmd can affect the amount of low memory available in the shared memory arena.

With some of the situations described above, it isn't how many concurrent threads or web sockets that are the problems per see, it is how much shared memory is being used - i.e. many clients can be supported if they use little memory, but few (or one) clients can be supported if that single request uses a lot of shared memory.

kLIBC, IMHO, needs re-working to make most of its calls use high-memory. Simply marking LIBC063.DLL to loadhigh doesn't working because all of the compiled apps that use the library need re-compiling AFAICS.

This needs fixing soon as soon the 300Mb of shared memory (its actually 512Mb, but 300Mb or so is all that is left once the system is booted to the desktop on most systems) is going to become a big problem.


Applications / Re: HELP!!!!!!!
« on: 2010.03.22, 16:45:39 »
Also, how big is your HPFS volume?

Hi Dennis,

Can you boot from the installation CD and go to the maintenance console?
Do a check disk?
First without writing corrections to the disk, then use dfsee.
Perhaps check how much data you have left free on the drive?
Is it possible that the disk may be failing?

Hardware / Re: The advent of 4096 byte/sector drives
« on: 2010.03.14, 01:24:42 »
For the moment there is. But this is only likely to be the case as long as drive manufacturers estimate that they will sell more drives this way. Once most people have begun migration from XP, this functionality will be dropped to save production and development costs of the equipment. Relying on this jumper is not a strategically wise decision, IMHO.


yes not all is lost if they will add a compatibility mode in the firmware of the drive. This utiliy program offered for xp users is a joke, easier to buy a non 4096sec formatted disk  ;) This problem will be for all software that cant handle this new formatting its not limited to warp only.

There is a jumper setting so the HDD controller translates things into 512B sectors for such OS's.

Hardware / Re: The advent of 4096 byte/sector drives
« on: 2010.03.11, 13:19:59 »
This is where some serious investment is going to be needed... not just paches IMHO  :)

This change will require, AFAICS, changes to

- OS2BOOT (likely rewrite as it will now have to support both disk types)
- OS2KRNL (prossibly, but actually the number of sectors reported per disk will become lower)
- HPFS.IFS (historically always aligned the FS layout alongside the 512 byte/sector)
- Boot Manager
- OS2LVM ?


Daniella warned me (Roderick) about 2 or 3 years ago for this. This might effect more then just
os2dasd. It can have effect on the minifsd (os2boot), os2ldr.

We are already skimming threw DDK code and to look what the best route is to deal with this.

This might be the end for HPFS/HPFS386 file systems (maybe ?). I don't know.
But it should be possible upload the os2boot file for bootable JFS and other needed drivers.

AHCI development will be resumed in Juni/July and this hooks into that that, size of sectors
on the disc. The source code of the DANIS506.ADD driver needed for the AHCI project.

So when we come to the disc storage part this is also something to put be put on the table :-)

Roderick Klein

Intel stated in 2005 when the Pro Set/10 was released, in its changelog, that this would be their last OS/2 driver release, unfortunately.

Hardware / The advent of 4096 byte/sector drives
« on: 2010.03.09, 16:26:09 »
Seems that the standard 512 bytes/sector of harddisks will be replaced soon, by disks that use 4096 bytes/sector. The first wave of the new disks will support software emulation (by the drives firmware?) but thereafter, old operating systems, such as XP (and I guess OS/2) will be unable to use the new disks.


So, within a few years - and starting as early as 2011 - you will be unable to use eCS on new hardware.

Looks like if there ever was a time for a rewrite of OS2DASD.DMD (and I guess a patch for os2krnl would also probably be needed, if only to overcome the 16-bit sector count limitation) it is now.

Seems like eCS needs some heavy investment...


Pages: [1] 2 3 ... 7