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.

Topics - mobybrick

Pages: [1]
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...


Programming / Flash
« on: 2009.07.22, 23:07:48 »
Any update on progress with the Flash development? It sounded a month ago like a beta might have been imminent...

I've heard horror stories on the web somewhere about the Flash development...

Programming / Don't open source the kernel, but...
« on: 2009.07.19, 23:46:29 »
... allow Mensys to sign an NDA.

We all know that IBM have said that they will not open source the kernel. This is the biggest problem facing eCS at the moment, IMHO.

There is another way.

How about a new petition to IBM, not to open source the kernel (which they will not do) but allow Serenity/MenSys to sign a non-disclosure agreement for access to the kernel source, so that they can work on the kernel, keeping it closed-source?

Before you laugh, the legal problems with the kernel becoming open-source dissappear with this method... after all, other companies (Lotus, Exigen Latvia, Tivoli) have, I believe, had access to the kernel source to do device driver and low-level development...

And the kernel would remain closed-source, which is the model that Mensys/Serenity seem to prefer...

How about it?


Programming / DASD Interface
« on: 2009.07.19, 23:25:55 »
Hi all,

Trying to do some research into the current 512Gb boot limitations.

- Look at  talks about the 32-bit strat 3 interface to OS2DASD

- Browsing the source code to the DANI driver (DANIS506,  it seems that it is only using the strat 2 (not 3) interface. This assumption is based on the source referencing the include file strat2.h

Questions: Would not the re-compiling of the code to use the strat3 interface improve performance, and would the using the newer API help with the 512Gb limits?

Of course, this may be well of course and I've made a lot of assumptions here... just trying to piece things together. Comments?



I was wondering if anyone had any information regarding the current state of eComStation development. It'd be good to know if..

a. Has, or will there, be any significant progress on fixing ACPI? e.g. The hang at the eCS boot logo (or shortly after) on a huge number of most chipsets, even common ones, still remains with the latest betas.

b. Has, or will there be any fixing of the 512Gb boot volume limitation fix for eCS?

c. Is there a timetable to release of the GA of v2.0?

Whilst we all, myself included, greatly appreciate the huge amount of work that must go into preparing an OS, and of the work of the various developers and managers (Bob, Roderick and Joachim et al) sometimes it appears that nothing seems to be happening. In the absence of information, users will make up their own horror storries or nightmares. We need re-assurance. Even a publicly viewable developers blog would be great :)


Dear all,

One of the primary objectives and selling points of eCS 2.0 was to add ACPI support to allow the OS to be maintained as a viable choice. It is now clear that the current ACPI implementation, for whatever reason, is flawed:

1. There are many bugs on the ACPI site that simple are/were never resolved, either because the reporter loses interest, or because of a technical limitation, or because the responder is too eager to close the call and/or come up with an excuse (or sometimes that it is the way it seems). The current ACPI team has worked hard, but maybe it requires more resource, manpower and expertise than they have currently got.

2. The current ACPI implementation is too fragile, and longer term will become a significant drain on the resources of SSI/Mensys, IMHO. An implementation that requires constant tweaking to work with even variants of the same motherboard/chipset, will be impossible to maintain for the thousands of types of PCs out there, and impossible to maintain into the future.

3. There are significant limitations that remain at the door of the kernel; for example, more chipsets are/will dropping INT13 support once the APIC tables have been initialised; as OS/2's mini FSD relies on the generic Int13 support then AMD/ATI machines never get as far as loading the correct hardware driver.

4. The current ACPI project seems to be lacking strict project management and should also have more than one technical lead on it, so that more refined and longer-term solutions can be found.

5. Strict architectural guidelines should be adhered to for 'how an operating system works.' This doesn't preclude inventive solutions, but individual programmers arbitrarily deciding to move OS functions between kernels, bootloaders and miniFSDs should be controlled. For example, implementing a workaround for the ATI/AMD problem by using the JFSBOOT miniFSD is a travesty, IMHO. Why? Not for any technical reason, but as a strategic one - it forces a long term decision on SSI/Mensys and indeed on all users to use JFSBOOT (and bootable JFS) on all systems if they want ACPI support. It is these kind of decisions that need fully investigating, if this has not already been done, to see if there is a cleaner way of doing it.

It's just my 2c worth, and obviously I am not privvy to all of the details/information, but I would suggest that SSI/Mensys do the following:

a. Release eCS 2.0 now, focusing on highlighting to customers the changes and advancement in the CIFS/SMB support, and free CUPS upgrade when available. Include the current ACPI code, but leave it as an 'experimental' feature. So those that can get it to work can use it, but for others it remains an 'unsupported' feature. More long-term benefit will be acheived by cutting loses and being open and upfront about the technical challenges.

b. Focus on releasing an eCS 2.1 within 12-18 months of the 2.0 GA.

The future

1. For the eCS 2.1 release, starting now, a full review of the way ACPI is currently implementated should be performed.

2. More research should be done on the way Linux and Winblose approach ACPI, specifically Linux as the source is available.

3. There is a way of patching the kernel to solve issues such as the ATI/AMD kernel, and I gather this is being done by the ACPI developer. Rather than create a whole new set of headaches for SSI/Mensys, this kind of creative thinking should have been channelled and controlled from the start - so that an official patched kernel became the solution.

3. Ways of incorporating patched versions of the kernel, including the workarounds for the INT13 problem, should now be investigated.

4. The core ACPI routines in the code may be re-usable (aren't these from Intel sources anyway?), but it is clear that how the ACPI code interfaces with the hardware, and reads/writes various ESCD and PCI information, is not sufficient. Perhaps these portions of the code need to be reviewed and rewritten, by more than one developer. If there are issues where a kernel limitation is the problem - then rather than trying to fudge or force ahead with a impaired implementation, then patching of the kernel to add or modify kernel functions should be done. The (ACPI?) developers have shown what can be achieved by this, but it needs to be done in a more structured and controlled way.

5. A key set of features for the ACPI implementation needs to be drawn up from the start (e.g. Intel/AMD CPU support, chipset-unspecific implementation - i.e. solve the INT13 problem for ALL time), interrupt handling, CPU throttling ... and then a list of features that will not be available in the first release of v4 (e.g. suspend).

6. Devise an internal test suite on a broad range of hardware that each and every test release is run against, before public release. This will help prevent the many code regressions we see, and will lead to cleaner code.

It is clear that many people, including the ACPI team, have worked very hard at the current code, but to protect against one  individual leaving the team, and to provide breadth of expertise, the core development should not be left in the hands of one skilled yet overworked individual. Guidelines on how the OS is to work need to be adhered to.

Testing should be initially done by a test team of (volunteer?) individuals. A test suite of hardware also needs to be found, so that the development team can pre-test a beta on 10 or 20 systems BEFORE a public release. Sometimes the current test website is littered with problems - that may or not be real problems anyway. A project of this magnitude needs to be resourced with a test suite of PCs - PCs that the developers know work, before  they test.

This will be more expensive now, and will require more resource. But longer term a cleaner, more tested implementation will hopefully be developed. And by making a more broadly compatible, generic APCI driver, the longer-term support costs will be less, as the code will need far less tweaking on a regular basis.

Linux and Windows can do it, but for SSI/Mensys to do it, a more controlled and managed approach will be needed - and possibly more resource - and indeed, more creative and/or adventurous solutions will need to be found, ala kernel modifications. I would also like Mensys to consider making the ACPI code open-source, so that others can also help.

Hope this all make sense, just my opinion you understand. At least we'll have a discussion about it. But lastly, I/we should thank everyone for their continued hard work, skill and involvment in eCS, including Mensys and the developers.


Dear all,

On one or two different systems, running an application that cause heavy intensive disk I/O, I am experiencing a hang. Thereafter, a full JFS CHKDSK is performed on my E volumes (JFS) that takes nearly an hour.

I seem to recall an ancient problem that heavy JFS I/O could cause a hang - but this problem still seems to be with us.

Anyone else seen this? Any suggestions? Will Serenity JFS likely have the same issue?

I am using IBM JFS 14.105


Hardware / NVIDIA Driver 0.0.4 Problem
« on: 2008.03.11, 01:25:40 »
Dear all,

Has anyone tried Nickk's Nvidia MAC driver on a system board with TWO NICs?

Upon booting, the first instance of the driver loads OK, but the second copy of the driver complains about a missing DRIVERNAME entry. It seems that it must be hard-coded to always assume that as it loads, that it is the FIRST NIC.

Anyone else tried this?


Box set

In case anyone is interested. Please use the 'messages' feature in e-bay if you have any questions.

I will also include a copy of the WSeB HPFS386 SelectPak that includes HPFS386 for WSeB and that can also be manually installed onto eComStation. Also includes copy of free SMP upgrade, TME10 Netfinity Systems Management, and IBM PSnS Backup/Recovery software.


Pages: [1]