• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

A new plan of action for eCS

Started by mobybrick, 2009.05.10, 21:11:11

Previous topic - Next topic

mobybrick

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.

Moby.

Saijin_Naib

Don't forget VIA CPU/Chipset support. Oft left out :\

warpcafe

Hi,

first of all: Good write.

Secondly I have to bring your attention to one LARGE difference regarding ACPI "standards" in my mind:
If you are Microsoft, you can invent your own floavor of ACPI implementation. All board manufacturers will automatically try tro be compliant with what you invented, otherwise their systems will not run as intended and they risk to lose the whole Windows marketshare for their crap. That's simply the way it goes.
Why do youo think there are so many dirty ACPI hacks out there which are more or less not compliant to "standard" ACPI? It's because of Microsoft.

In turn that means that the eCS guys have to discover the deltas for standard ACPI in each and every mainboard / chipset out there. Or - recode "MS-ACPI" from scratch.

Next, in my mind the problem is not only the project management but also the way how people collaborate:
If ACPI developers aks for "report your model" and then sit and wait for people/users to give feedback, it will NEVER EVER work.
The only reasonable method to achieve a substantial coverage in hardware reports is to have a tool which is painfree: 1 program only - you run it and it gives a report of all relevant information - you send it to a web adress (best case would be to have the tool do the upload automatically).

In a perfect world, I would expect that tool to be integrated in the eCS setup automatically. Or even better: When you install eCS, the thing collects information and aska you if it can upload the data. Done.
For those who have access to modern machines on a more frequent basis (dealers, service providers) it would be handy to have thta tool an a bootable CD or USB thumb drive:
- you see a new machine somewhere
- you plug in the drive or boot it from the CD
- you collect the ACPI and system information
- you upload it online or save-to-file and upload it later

But: Having people to read 3 or more readmes, then run 5 or 7 programs and collect 3 to 4 files to report that on a russian website via copy and paste after having to create an account with their forum is just crap. Moreover it is simply unprofessional and outdated.
That's why there is not enough information about hardware.

Regards,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

cyber

I agree with You both, and You Warpcafe has just nailed-it !

rwklein

Quote from: cyber on 2009.05.11, 13:03:45
I agree with You both, and You Warpcafe has just nailed-it !

Well since eComStation RC 5 we do ship the feedback wizard. You can see it at this page:
http://ewiki.ecomstation.nl/ACPICompatibilityReport

So we already collect data. The data that came back is from RC 5 RC 6/6a.
Note that when the user elects to not to exit the wizard we do not get any data.

Roderick Klein
Mensys

mobybrick

Hi,

I think that is why I wrote

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

If Linux can crack ACPI on 90% of hardware, then it is possible - even if it is M$ setting the standard for ACPI, and not the manufacturers. The fact remains that Linux (and Windows) can install on most bits of hardware without significant issues, so there is a 'standard' out there, even if it is not well defined. There should not need to be a reason to get the 'delta' for each chipset, if the right 'standard' and approach can be found.

The main thrust of my piece is to suggest however a more structured and controlled delivery of the project. It might be already happening and for that I apologise - but there is little evidence of it. Test suites, structured design and planning should be part of any software design.

Regards,
Moby.


Quote from: warpcafe on 2009.05.11, 12:28:16
Secondly I have to bring your attention to one LARGE difference regarding ACPI "standards" in my mind:
If you are Microsoft, you can invent your own floavor of ACPI implementation. All board manufacturers will automatically try tro be compliant with what you invented, otherwise their systems will not run as intended and they risk to lose the whole Windows marketshare for their crap. That's simply the way it goes.
Why do youo think there are so many dirty ACPI hacks out there which are more or less not compliant to "standard" ACPI? It's because of Microsoft.

In turn that means that the eCS guys have to discover the deltas for standard ACPI in each and every mainboard / chipset out there. Or - recode "MS-ACPI" from scratch.

Next, in my mind the problem is not only the project management but also the way how people collaborate:
If ACPI developers aks for "report your model" and then sit and wait for people/users to give feedback, it will NEVER EVER work.
The only reasonable method to achieve a substantial coverage in hardware reports is to have a tool which is painfree: 1 program only - you run it and it gives a report of all relevant information - you send it to a web adress (best case would be to have the tool do the upload automatically).

In a perfect world, I would expect that tool to be integrated in the eCS setup automatically. Or even better: When you install eCS, the thing collects information and aska you if it can upload the data. Done.
For those who have access to modern machines on a more frequent basis (dealers, service providers) it would be handy to have thta tool an a bootable CD or USB thumb drive:
- you see a new machine somewhere
- you plug in the drive or boot it from the CD
- you collect the ACPI and system information
- you upload it online or save-to-file and upload it later

But: Having people to read 3 or more readmes, then run 5 or 7 programs and collect 3 to 4 files to report that on a russian website via copy and paste after having to create an account with their forum is just crap. Moreover it is simply unprofessional and outdated.
That's why there is not enough information about hardware.

Regards,
Thomas

warpcafe

Quote from: rwklein on 2009.05.11, 13:39:45
Well since eComStation RC 5 we do ship the feedback wizard. You can see it at this page:
http://ewiki.ecomstation.nl/ACPICompatibilityReport

So we already collect data. The data that came back is from RC 5 RC 6/6a.
Note that when the user elects to not to exit the wizard we do not get any data.

Hey, wow - *that* is what the feedback wizard is used for?
Who came up with "feedback wizard" as the name?
I mean - when I read "feedback wizard" I thought "How should I give a feedback when I just *installed* that operating system? Let me use it first before I give feedback". Conclusion: The name is bad.
Secondly, on either RC5 or RC6 it was broken. When I clicked it, it gave me an error message like "form not found" or something, I don't remember. Anyway...

And why the heck ;) do you tell us the website with the feedback here?
That should be included in the feedback wizard's start screen like
"To get an impression of what we collect the data for and how your data will be used go:" <link>

Finally, yes... you should really think about a different name :))

Cheers, (Thanks!!)
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

warpcafe

Hi,

Quote from: mobybrick on 2009.05.11, 14:48:54
It might be already happening and for that I apologise - but there is little evidence of it.

yeah, *THAT* is one of the main issues I guess: Lack of transparency / updates.
I know it's hard to update 5 or more news sites on a regular basis, but 1 "networked" website would do.
Also I know how little resources are able to work on the code and that progress is very hard to achieve when you actually have to kernel-debug on every little code change. Not to mention regression testing with a non-existent hardware test bed.
But any news is good news. I also agree that it might be hard to have the few people working on the code all the time also be in charge of giving updates - but they should do it anyways, right? I mean from a "project management" point of view. But it needs to be done.

A one-line statement like "some tickets closed, 3 new ones opened" in a netlabs newsletter might not be enough for everybody... especially for those who have a board with hardware issues. An official plain-english status page (like a weblog?) is better than a Mantis or Trac landing page that contains a list of bugs instead of "status messages".

From my personal experience, I have to really express my thankfulness regarding how fast *my* problem with ACPI was taken care of and how it was fixed... so the ability is there - it just needs to be more transparent to the general public.
Normally I would say "what the heck, we don't need a status page for this little aspect of eCS", but given the fact that everyone knows that eCS 2.0 still is not here and that this is merely because of ACPI, then there *is* an overall (big) importance to have dedicated information on ACPI.

Just my 2 cents. And - in order to be not yet another NAGGER who's nothing but complaining:
I would offer to help in maintaining/updating such a webpage. Up yours! ;)

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

ivan

QuoteFor those who have access to modern machines on a more frequent basis (dealers, service providers) it would be handy to have thta tool an a bootable CD or USB thumb drive:
- you see a new machine somewhere
- you plug in the drive or boot it from the CD
- you collect the ACPI and system information
- you upload it online or save-to-file and upload it later

Now that is the way to go!  If such a tool was available - without having to install anything - then, I for one, could go round to various clients and get the information on about 30 different systems.

I think restricting information gathering to the installed base is very limiting.

cyber

60 brand new boxes from HP buyed here at my firm.  And bunch of "old" buyed this year.

rwklein

Quote from: warpcafe on 2009.05.11, 12:28:16
Hi,

first of all: Good write.

Secondly I have to bring your attention to one LARGE difference regarding ACPI "standards" in my mind:
If you are Microsoft, you can invent your own floavor of ACPI implementation. All board manufacturers will automatically try tro be compliant with what you invented, otherwise their systems will not run as intended and they risk to lose the whole Windows marketshare for their crap. That's simply the way it goes.
Why do youo think there are so many dirty ACPI hacks out there which are more or less not compliant to "standard" ACPI? It's because of Microsoft.

In turn that means that the eCS guys have to discover the deltas for standard ACPI in each and every mainboard / chipset out there. Or - recode "MS-ACPI" from scratch.

Next, in my mind the problem is not only the project management but also the way how people collaborate:
If ACPI developers aks for "report your model" and then sit and wait for people/users to give feedback, it will NEVER EVER work.
The only reasonable method to achieve a substantial coverage in hardware reports is to have a tool which is painfree: 1 program only - you run it and it gives a report of all relevant information - you send it to a web adress (best case would be to have the tool do the upload automatically).

In a perfect world, I would expect that tool to be integrated in the eCS setup automatically. Or even better: When you install eCS, the thing collects information and aska you if it can upload the data. Done.
For those who have access to modern machines on a more frequent basis (dealers, service providers) it would be handy to have thta tool an a bootable CD or USB thumb drive:
- you see a new machine somewhere
- you plug in the drive or boot it from the CD
- you collect the ACPI and system information
- you upload it online or save-to-file and upload it later

But: Having people to read 3 or more readmes, then run 5 or 7 programs and collect 3 to 4 files to report that on a russian website via copy and paste after having to create an account with their forum is just crap. Moreover it is simply unprofessional and outdated.
That's why there is not enough information about hardware.

Regards,
Thomas

The first thing Thomas writes is correct, the ACPI in daily live does not function as on paper. Infact the German computer magazine C'T did a test with 10 mainboards and installed nacked Windows XP on it. The test results where quite depressing (this was about 2 years ago). Only one board worked with the standard ACPI driver of Windows XP. The bother boards had difficult.

The opinions on this topic vary. But some people claim the so called AML tables (that contain the ACPI code in your BIOS) is sometimes not fixed by vendors. What they do in an OS preload on your system is sometimes ship an updated driver for Windows to work around the problem. Hence the problem for other OS'es like eCS and Linux. Next to that most Linux distro's still have a difficult experience with suspend resume (S3 sleepstate). Multiple people that work intens with Linux tell me its not a pretty picture either.

One good point is that eCS has a pretty generic small driver set.  The problems we are finding like the embedded controller seem to be happening on more machines (acpi 3.15). Also suspend resume seems to in range...

When it comes to having a tool that collects information for eComStation and ACPI. Ever seen the feedback wizard ?
This has been in eCS since RC 5. http://ewiki.ecomstation.nl/ACPICompatibilityReport

So there is being worked on the railway track at all sides.

Roderick Klein
Mensys

warpcafe

Roderick,

is there any chance to have a "standalone" version of the feedback wizard?
I mean - something that collects the same set of information and makes it possible to store the output in a plain-text file or whatever...

This would allow people to scan hardware and get information without having to install the full eCS on it.
Around here, I often have to deal with machines from family/friends/customers but I obviously cannot install eCS on it or swap drives and install eCS just for the sake of collecting information.

What I would like is a small thing that can be put on a USB thumb drive or perhaps a customized 1.2 bootable demo that can run the tool. It then outputs some kind of file that I can put on floppy / USB... or send it somewhere if internet access exists.
This would allow me (and others, it seems...) to collect much more data - even from machines we don't own.
Heck, I could even walk into a computer store and grab the information from the latest and hottest boxes if they didn't secure them (which they usually don't do. :) ).

If you tell me what the feedback wizard does, perhaps I can re-wrap this somehow. I could also make a win32 executable fi you tell me what is required... perhaps also use a re-wrapped output from "Belarc advisor" or the like - I simply need to know what the thing does.

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

Andi

Quote from: warpcafe on 2009.05.11, 19:31:40
...
What I would like is a small thing that can be put on a USB thumb drive or perhaps a customized 1.2 bootable demo that can run the tool. It then outputs some kind of file that I can put on floppy / USB... or send it somewhere if internet access exists.
This would allow me (and others, it seems...) to collect much more data - even from machines we don't own.
Heck, I could even walk into a computer store and grab the information from the latest and hottest boxes if they didn't secure them (which they usually don't do. :) ).
...
Thomas
Thomas, a prerequisite here is, the machine boots eCS from an USB stick and you set various bios options to do it the right way. How many people did succed in booting from USB-Sticks? Does USB boot work on different machines?

On the other hand, a tool which runs under Windoze and tries to collect some bios internals would never give any useful output for eCS when windoze drivers are between and windoze has made a lot of settings during boot up, I fear.

Please correct me if I'm wrong. But fear that you have to have a somehow running eCS on your system before you can collect usefull data like - suspend do/do not work and so on. Bootable DVD and writting results to a stick or floppy seems to me a viable path to go here.

Andi

ivan

Andi, I think the point Thomas is trying to get across is what do the developers need to know.  Obviously it must go beyond 'it doesn't work', the big question is why?  Until we know what they are looking for it is very difficult to help.  I don't have eCS but I do have access to a wide range of systems in the hands of friends and clients, a lot of them running OS/2, which means I might be able to use a live CD like some of the linux distros, except with eCS, to get the information.

That being said, until there is a clear statement of what information the developers want we will get nowhere.