Messages

691

Article Discussions / Re: Preview: eComStation 2.2 Beta, the legacy of OS/2 lives on

« on: March 01, 2013, 01:50:59 am »

I guess I can answer most of the questions since I'm doing the work with the other tech guys to keep eCS on thie move.

When it comes to public beta's my experience is the following.  A public beta is needed of the product. But I can speak from practical experience the beta cycles don't really give that much feedback.
For some projects we have closed mailing lists and dedicated testers. When I started working for example on integrating Chris Wolgemuth his MMOS/2 classes into eCS I got little to no feedback from people asking to test MMOS/2. These where people even interested. Since it are all volunteers you won't hear me complain. But over the years my guess is most bugs are found by following a logical development path. You follow what is done to a program and then test it. If you make a change then you test that program.

Basically my conclusion is that with public beta's we get little to very little feedback and if we do get feedback in the form that something does not work we far from always get proper log files back to drill to the bottom of a bug.
I hope that partly answers the questions about public beta's. So we will do a public beta of 2.2. Infact tomorow morning I will call David Azarwitz early in the morning his time and do some debug on a system with USB problems. But this requires time using the kernel debugger and him logging in via VNC to find the problem.

Roderick Klein
Mensys B.V.

692

Applications / Re: Whatever happened to...

« on: February 21, 2013, 02:46:56 pm »

We have an internal release ready.

We are working on trying to load the DLL's from Open office into the high memory area of OS/2. We are already having some success with Firefox.
By doing this the lower shared memory issue's with OS/2 and the associates hangs of the desktop should going away.

This is a a feature we have been trying to get in previous open office versions as the loading of these large DLL's into lower shared memory reduces the uptime of an OS/2 system.

Roderick Klein
Mensys B.V.

What should I expect with this answer?

- is there an already running Open Office 3.4 or not?
- when will it be public? (next month/year...?)
- loading the dlls in high memory - has open office to be changed for this or eCS?

That is what it makes hard to understand and follow or stay tuned: the (allways) avesive answers and non concrete informations and timetables - why can't there be an answer that is not a mystery/riddle or that is just simple?

 

There is a 3.4 version that is receiving final internal testing. It does not yet work with loading DLL into high memory.


The source code for open office does not have be modified for this feature. When you open a word document it already uses API calls to store the dats of that document into high kernel memory (effected by the virtualaddresslimit).  However with several different tools  you can modify the DLL headers to tell the kernel what portion to also load high of the DLL's into high memory itself.
Scott Garfunkel from IBM (before he stopped working on the OS/2 kernel) put that feature in very far.

Now you can use a tool such as highmem.exe and do *.dll. Once you do that on firefox/thunderbird/openoffice DLL. It works fine, until you exit the application. Then some memory clean up code in the kernel blows up and you get a system TRAP.
(As a warning don't start experimenting these on your system unless you know what your doing and keep track of which DLL's you modify!)

We are looking at the applications to find out if we can only use a subset of DLL's to load high memory. This is already working with Firefox partly. Instead of having 150 of lower shared memory we now end up in the lab with 260 MB or more. (These figures can change). This research is being done with memory dumps, theseus and the kernel debugger. This takes time and is not realy something you can translate into a time frame.

Can this highmem stuff be fixed in the long term, yes it can and we might get a sollution for eCS 2.2. We fixed plenty of other stuff in eCS without kernel sources. Sometimes a fix is easy sometimes its down right hard. For example look at the TCPIP32DLL.DLL that would crash on SMP systems. That new DLL version (gets installed with eCS 2.2 by default and all latest ACPI versions) reduces Firefox crashes on SMP systems. But it did take time to get it done.

If we don't make it then Open Office 3.4 will  be released with eCS 2.2 without the high load option with eCS 2.2 in the second week of april.
Thats also why you don't hear much about Open Office because more focus has been on eCS with all the new drivers. Currently I'm also working with David and Lars on the USB drivers.

Roderick Klein
Mensys B.V.

693

General Discussion / Re: Hybrid "64-Bit" eComStation

« on: February 20, 2013, 03:06:38 pm »

Or you can see if the DLL's can be loaded into high memory instead of trying to increase the shared memory of OS/2.
Thats what we are currently experimenting on and analyzing with memory dumps why this fail.

Regards,

Roderick Klein
Mensys B.V.

694

Applications / Re: Whatever happened to...

« on: February 20, 2013, 03:01:01 pm »

We have an internal release ready.

We are working on trying to load the DLL's from Open office into the high memory area of OS/2. We are already having some success with Firefox.
By doing this the lower shared memory issue's with OS/2 and the associates hangs of the desktop should going away.

This is a a feature we have been trying to get in previous open office versions as the loading of these large DLL's into lower shared memory reduces the uptime of an OS/2 system.

Roderick Klein
Mensys B.V.

695

Hardware / Re: New hardware that works with ECS2.X

« on: February 16, 2013, 10:33:13 pm »

Intel Video Chip-set is pretty broad statement, you need to be more specific. I have not found any of the current B, H, or Z series to work correctly or post for that matter... and I build a lot of systems.  I actually have gave up trying anymore. Trap errors or system hangs. Of course that relates to version 2.1

Well I was writing about eCS 2.2. also. And if you have had TRAPS or hangs we get very little to now feedback from customers. So if you opened a ticket, then oke I said nothing. If you did not open a ticket then I can not help you. And most of these traps adn hangs the knowledge in the forums here is lacking.

As for the TRAPS you have been getting on recent Intel equipment I guess that was just about after the preboot menu came up !?
Thats the TRAP D OEM HLP problem resolved with eCS 2.2.

And when you get hangs read the eCS 2.1 quickguide and specify where the hang is.  Its a free world but so many people talk about getting a "hang". But eCS 2.1 and 2.0 have a chapter about what is helpful information to post.  Look at chapter 6, again if you did open a ticket a said nothing :-)

Is the hang when you enable ACPI or when the last device driver is loaded., etc.

About the Intel claim.

All TRAP'd people get on modern equipment when eCS boots are duo to an OEM HLP defect fixed with the latest ACPI version. But you need to have a new ACPI version on the boot CD.
That will be fixed with eCS 2.2. Also with the new Panorama driver video performance will improve on these modern chipsets.

Currently our techteam is working on taking the last bugs out of the drivers that Lars Erdmann worked on over the last 1 to 2 years. Its clear the old IBM USB stack had its limitations the new stack is much better. A public beta of eCS 2.2 will follow in 2 1/2 weeks itme now.

eCS 2.2 beta has been tested on a lot of new current desktop and laptops and desktops. A lot of system simply work without any hassle.

Regards,

Roderick Klein
Mensys B.V.

P.S. I'm the technical manager in charge of the tech team at Mensys to do device driver development

696

Networking / Re: Trap000E in AFINETK module

« on: February 16, 2013, 10:10:07 pm »

Hi folks,

I have a problem with above mentioned module. Situation is as follow. system trap with TRAP000E in AFINETK module. Only power down works. Time between traps are not regular, from few minutes to few hours. I tried everything what I found on inet but no joy.
Strange thing is that when the system is connected to the instrument (collecting data) over LAN but not to the server, all is OK for weeks without trap. When system is connected to the server (via switch or router) trap will happen in above mentioned intervals (irregularly). Any new ideas? Lan card in the system is 8163, IP static, server run windows, eCS v2.1.     

Take a look at netstat -s and keep an eye on the amount of open sockets.

You get to see something like this:
  2108 STREAM               0               0         0.0.0.0  CLOSED
  2110 STREAM               0               0         0.0.0.0  CLOSED
  2112 STREAM               0               0         0.0.0.0  CLOSED
  2114 STREAM               0               0         0.0.0.0  CLOSED
  2116 STREAM               0               0         0.0.0.0  CLOSED
  2118 STREAM               0               0         0.0.0.0  CLOSED
  2131 STREAM               0               0         0.0.0.0  CLOSED

Also look at netstat -m.

Look for some more information and what type of services are you running ?
Regards,

Roderick Klein
Mensys B.V.

697

Hardware / Re: New hardware that works with ECS2.X

« on: February 15, 2013, 10:47:34 am »

Basicly buy a system with an Intel ethernet and video chipset. With the upcoming eCS 2.2 (beta will start in 2 or 3 weeks).
You should have native resolution for your LCD screen (panorama driver), ACPI working properly and the NIC.
You can also buy something with ATI video card. Realtek gigabit cards work very reliable, some don't but does same chipsets don't work under Linux either (it are revisions of the same chipsets).
But systems with none Intel mainboard chipsets will work reliable with the new ACPI 3.21.xx (included in eCS 2.2).

Its important to pick Intel/ATI video and grab an Intel gigabit NIC. The Intel NIC driver simply works everywhere.

Regards,

Roderick Klein
Mensys B.V.