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 - Roderick Klein

Pages: 1 ... 43 44 [45] 46
661
That issue is fixed with the upcoming beta CD of the demo CD.  We did some SMALL fixes. But needs some more work.

Now testing on the last or second last internal beta of eCS 2.2 before it goes public :-)

Roderick Klein
Mensys B.V.

662
Hi all. Just my 2 cents: I booted my eCS workstation from eCS demo CD and all went OK. This is an AMD Phenom II X6 with 4GB of RAM and ATI X850 PCIe video. Runs very well under eCS 1.2R so far.

eCS 2 demo boots with standard settings. Afterloading the Intel PRO/1000 PCIe MAC driver it sits and waits for quite a while (~30 secs) with keyboard being unresponsive - I was almost about to do a reset. Eventually installation continues, boots into the desktop and is usable by and large. Firefox 10.0.11 comes up nicely and connects to the internet using my LAN connection.

What did not work and works in my eCS installation:
- sound did not work (I am using an old PCI Nightingale PRO)
- ACPI 3.21.07 only initializes one of the 6 CPU cores (this might be by design)
- Flash is not working (seems not to be installed)
- HTML5 did not work - maybe due to missing sound

Just a first impression - will do some more extensive tests.

Cheers
Andreas

We disabled THE smp support in THE boot by default. Some systems boot from cd trap when smp is enabled. This does not happen with the boot from hard disk. You can switch on the smp support in the preboot menu.

This hang you you experience for 30 seconds is most likely caused by a bug in the currently used USB drivers. We are down to 1 bug to replace the IBM
USB drivers. As mentioned this is a beta of the demo cd.

Roderick Klein
Mensys b.v.

663
One advantage of public transport compared to driving my motorcycle. I can work on eCS on my laptop in the express bus :-)

I'm currently running final tetss on the virtualbox hang on the geneproto.exe and virtualbox that should be fixed.As for Xwlan on the todo list. But for the gemac drivers.
The driver

A) Is not auto detected by the preboot.

B) My intel 3945 chipset in my T61 does not load correctly.

The primary reason to bring out the demo CD is to show some other things amoung Panorama and ACPI progress. While not there yet it shows we remain on the move...

Regards,

Roderick Klein
Mensys B.V.

664
Article Discussions / Re: Atheros card driver
« on: March 08, 2013, 03:53:13 pm »
From what we can tell the NIC driver uses a API interface they put in the OS/4 kernel.
If it will work on the OS/2 kernel I don't know.

665
Hi,


Frankly: I don't care if APM or ACPI versus suspend/resume works. I don't care that the lame Panorama now is faster than before (and still slower than my crappy Android phone while we're at it). I don't care about these incredibly improved, groundshakingly different desktop icons. And heck, I don't even care about USB improvements if I could trade all this for an OOTB WIFI support.


you are right.   wifi, wifi, wifi !!!!!!!!


hi


Let me answer Andreas his point. I wrote on os2.org as well. Tests an a T42 and T40 with suspend and resume have so far worked.
You can switch to legacy mode. As for the hot CPU. What version of ACPI was this that you tested with ?
I don't know with which version you tested.

All recent versions of ACPI  implement HLT support on the SMP kernel. So you should get the same result my T61 is right now 44 degrees celcius.
But we have not really received bug reports if recent version of ACPI don't work with the HLT on older notebooks to keep the CPU cool.
The HLT instruction has been implemented in the x86 CPU's since the first versions of the CPU (earlier then the 286).

So either you are running an older version of ACPI (pre-dating  3.20 version) or we do have a bug. But as long as there is no bug report
its guess work what you report is based on.

And as I have written before. The whole ACPI upgrade and USB was needed. So the wifi support is in the beta demo CD (the website also mentions this as a beta!).
I will look at this over the weekend. Final release of the eCS demo CD will be in the second week of April together with eCS 2.2 German and English final version.
Beta of eCS 2.2 will be released next week.

Roderick Klein
Mensys B.V.

666
Hi,

I know I'm late for ranting, and certainly this is not related to the context of the last posts, but:

Is it just me or is it completely ridiculuous and unprofessional (sorry, Mensys) to publish a demo for an operating system without WIFI support, especially if the actual OS in fact HAS support for Wifi? Were you not granted permission to include it?

I mean, hey, we're 2013, folks! I'm doing ten times more on wireless connections with phone, tablet or notebook/laptop than with an RJ45 cable attached to some plug. I wasn't upset, perhaps a bit disappointed on the inside, but I definitely was ... speechless. When the demo started up, I went like "hey, no, wait... this can't be real. Am I doing something wrong? No, they must be kidding". I sincerely cross fingers and light a candle that we'll soon see a demoCD refresh with a "WiFi supported!" sticker attached.

Frankly: I don't care if APM or ACPI versus suspend/resume works. I don't care that the lame Panorama now is faster than before (and still slower than my crappy Android phone while we're at it). I don't care about these incredibly improved, groundshakingly different desktop icons. And heck, I don't even care about USB improvements if I could trade all this for an OOTB WIFI support.

Regards,
Thomas

The genmac drivers are in the detection logic of OS2CSM and are in the driver collection on the CD. They however not seem to load. Our internal testing this did worked on a T42.
So I'm suprised it did not work. Hence the reason its also a beta.

667
Just slightly OT Roderick, but when do we see the real eCS 2.2 beta?

Next week. As we want to release the final product in the second week of april. But we have been slashing bugs out of it our self. We know what was modified so we have a pretty good estimate what needs to be fixed.

A new version of the USB stack I just need to trace one bug with David and we switch away from the IBM USB host controller drivers.
As bug 3221 we found a bug in the danis506.add dealing with disk geometries. This is now being tested and fixed.
(Yes that bug has always been there).

But it are bugs like this when we discover it. We rather fix this then release a beta. ACPI and Panorama will remain at the current version. Unless we find serious flaws on mayor amounts of equipment.

Regards,

Roderick Klein
Mensys B.V.

668
The NIF file used for the NIC driver in Virtualbox is kind of not standard. There are two entry fields in the NIF file that lack a so called range filed.
OTOH hand the genproto code should deal with it. Defect found, fixed in the NIF file and genproto is being updated to work around.

The reason the crash at this moment in time is so serious is because (basically the only point in eCS where this happens) a small device driver is being loaded that loads a script to generate a protocol.ini on the fly. This has to happen at device driver load time as we need to load the proper NIC driver on the fly.

Would genproto be loaded as a run or call statement via the config.sys you could then CTRL C out of there.
So another bug fixed in the demo CD. Now I understand why the demo CD in virtualbox did not work :-)
New eCS 22 beta demo CD might be released this week or next week. With more fixes.

The people that select to boot with own value's and have a hang on genproto. The option to edit the fields for the NIF file
will be taken out. The hang is most likely happening as some modern PC's the BIOS keyboard support is switched off.
And in some cases in genproto you don't have keyboard input yet. This happens after the so called dev_init completes by the kernel.
(After the last device driver is loaded. That should also be fixed in the internal build today.

Roderick Klein
Mensys


669
Pretty much useless. Very disappointed. I tried it on a  (UEFI Off) Z77, B75, AM3+, A75, and A55 board. No go on any of them. Just hangs or traps. Same old stuff. I am sure I could get the AM3+ to go but no time to play around. It runs I my eCS rig but I expected that.

What would be usefull to know is when it traps !? When PM comes up when the PSD loads (press ALT F2 key combination the preboot menu).

Roderick Klein
Mensys B.V.

670
Well Sigurd sorry to see you leave. It was a pleasure working with you. About some of the bugs where you got no response. I sometimes called you or send you an email to give you access to the latest internal test versions of eCS and ACPI.  So that might have not been documented, I can't remember.

What I meant with fairytale is the ever lasting discussion about using APM laptops.  I call it fairytale because does machines have in my opinion died out. Certainly some people use them but the vast majority of people that preload eCS on native hardware use somehting new. Now that suspend resume does not on all machines is also something we still need to fix. But looking how eCS 2.2 is now working. We also don't have unlimited human and financial resources.

About the differences between Warp MCP 4.52 and eCS. Well yes if you patch in our current drivers I don't realy see where MCP is then that much different compared to MCP.
Apart from all of the other updated system components and downright old installer the *core* differences between kernel and other systems components from IBM such as workplace shell is almost no difference. So I don't realy know how eCS 2.x would be far more unstable then MCP 2. If you have that observation, then oke.

Also don't forget that eCS 2.x is also way more advanced then MCP 2 in terms of supported devices and installer.  But at its core is almost not the a different OS except bug fixes from IBM.
Infact the MCP 2 has know defects with fixpaks.

As for the fact that Apple is so successful. We don't have an Apple hardware factory. We get cooperate customers that simply knock on the door and ask if machine X,Y.Z. works.
There are basically no companies that ask for a specific model if its supported. They just ask if a model they have is supported.

Anyway thank you for your years of contribution Sigurd.

Roderick Klein
Mensys B.V.

671
Thanks Sigurd for a thoughtful response.

You bring up a very interesting point: the strategy choices for the development for eCS.  Here, I agree with you that a clear strategy choice has not been made, and that one can make a lot of damage to oneself by overselling (it works on all modern software when in reality it does not), and by not sticking to time tables.

On proper beta testing: with the small eCS community, it would be difficult to test all new computers.  Some of this is probably not even the fault of eCS but of computer producers who fail to document the hardware that make up their computers.  This is a problem not only for eCS -- Linux developers face many of the same problems.  As indicated by my previous posting, things work on my workplace because the computer and network department document things.  Hence, odd guys like me know which solutions to look for.

So, there have two challenges:
  • Proper documentation by hardware producers
  • A clear development strategy for eCS, followed by proper documentation on which hardware that works.  And then this documentation needs to be more detailed: several computer models come in multiple editions, and one needs to be clear on which edition = which hardware
When I buy new hardware, I try to get as exact info. as possible.  Drivers is a huge challenge.  The ongoing ACPI development will solve some of that, but not all as some computer producers neither adhere to standards nor document what's in their box.  PCI produces this documentation once you have bought a computer, but for most of us, that is a bit late.

Eirik

I commented on selecting certain hardware for eCS and making a list public for that. From my point of view it won't really work.
Infact to make the specific point even more clear. Most companies that contact us say simply "he I have this peace of hardware, make it work with eCS".
Most companies don't ask us "what hardware is supported".

Also with not all equipment being sold by suppliers for a long time its not always possible to say use model X from manufacturer Y.
We had it with a very big OS/2 customer from Europe. They just knocked on the door and said "he want this HP workstation to work". We got it to work and 2 months later it was off the market.
Then again some computer vendors do have business models that are sold longer so companies can plan.

See my other posting for some of the issue's with sticking to a small sub list of hardware.

Roderick

672
Hi Martin,

My intention is to tell people what is possible and what not. If you use google translater I would like you to follow some discussions at os2.org about the following topics regarding ecomstation I did not mention:

- No response from Mensys if asked for support
- No response for postings at bugtracker

And that leads me to the old, so often (so often that I am tired of writing it but it is sadly proved so often...)written facts:

If there would have been the decission to concentrate on selected hardware (at least since 2006) what have lead to:

- a full supported selected hardware
- less hardware problems
- less questions
- less support needed
- less bugtracker entries
- less frustrated users
........

But -yes - lets be happy for waiting for the new release, but do not let people with no knowledge of this OS to expect that it will run out of the box and could compete with Linux or Windows - this will lead to much more frustrated users and bad press and will loose the last credit of what is left of OS/2............

Let me first address this item that I have seen before on forums that we point a selected subset of hardware.
I will type it again. The suggestion is not and will never have worked. Let me explain you why it is flawed and not a 100%
proper strategy.

In theory it sounds nice but in practice here are some of the pitfalls of sticking to specific models/brands of computers.

1. Not every hardware vendor has the same model on sale everywhere around the world. I can mention one example we needed an HP workstation for a large customer.
It had different part numbers and different models world wide. Or some PC brands are not even for sale worldwide!

2. Some companies Mensys does business with has a preferred brand they want to use for example Dell. Such a list would then not work.

3. if we focus on a subset of hardware its still not going to safe us. Because how long will hardware be for sale and what happens if the vendor brings out a new BIOS with an ACPI in the BIOS that is suddenly broken. Years back I once had it with a T42 that had APM suspend/resume problems and another T42 did not. Turned out it was a BIOS revision problem...

As for support missing ? What tickets are outstanding in the bugtracker. I have given you access to eCS beta's in the past for testing to see if things where fixed.

Thanks,

Roderick

673
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.

674
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.

675
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.

Pages: 1 ... 43 44 [45] 46