ACPI, ECS 2.1 und T60

[wilfried]

Hallo zusammen,

ich habe hier eine "Verschlimmbesserung" von ACPI beim Wechsel von 3.21.07 nach 3.22.03 beobachtet.
Nach dem Upgrade nutzt ECS nur noch eine der beiden erkannten CPU's. Die zweite CPU bleibt bei 0% auch wenn mehrere Anwendungen laufen und die erste CPU bis auf 100% Auslastung getrieben wird.

Ist das ein bekanntes Problem?

Ich werde dann mal auf 3.21.07 downgraden.

[ak120]

Eine endlose Geschichte - nach über 9 Jahren. Man muß sich wohl oder übel zwischen ACPI-Versionen entscheiden, welche entweder nicht alle Prozessoren unterstützen oder nicht alle Betriebsarten der Energieverwaltung beherrschen. Die Geräte sind leider nur für Windows XP geeignet.

[V. Weise]

Hallo,

eventuell könnte das der Grund sein:
Bei den neueren Versionen von ACPI ist der Schalter /SMP in der CONFIG.SYS nicht mehr zu setzen.

MfG
V. Weise

[wilfried]

eventuell könnte das der Grund sein:
Bei den neueren Versionen von ACPI ist der Schalter /SMP in der CONFIG.SYS nicht mehr zu setzen.

Leider nein. ACPI.PSD steht nach dem Upgrade ohne Parameter in der Config.sys.
Auch die Übernahme der Parameter /ST=0 /VW aus meiner ecs 2.2 beta II Testinstallation bringen keine Verbesserung.
Unter ecs 2.2 beta II läuft diese ACPI-Version einwandfrei auf meinem T60.
Möglicherweise liegt es am Kernel von ecs 2.1 GA DE.

[LotharS]

Möglicherweise liegt es am Kernel von ecs 2.1 GA DE.

Was spricht dann und sowieso dagegen, den Kernel upzugraden?
Hier aus meinem lückenhaften Gedächtnis:

Code: Alles auswählen

     
    1.
    Für alle Notfälle sicherstellen, dass "von aussen" aufs System zugegriffen werden kann, z.B. einer Wartungspartition.
    Die einzelnen Schritte sicherheitshalber nur einzeln nacheinander ausführen.

    2.
    Bezeichnung hier: "C:" = Bootlaufwerk eCS 2.1, "y:" = Bootlaufwerk/Quelle eCS 2.2b2; zur Ausführung anpassen. 
    Ein neues Verzeichnis C:\ecs\install22 anlegen, um Überschreibungs-Konflikte zu vermeiden 
    Dorthin aus der eCS2.2b2 die ganzen Verzeichnisse y:\os2\install\SMP sowie \UNI und \W4 als Unterverzeichnisse kopieren.      Die beiden letzteren ind eigentlich im weiteren nicht nötig, sondern nur zum Komplettieren gedacht.  

    3.
    Nach x:\os2\system\trace wechseln und
    md trace21
    copy * trace21  (einfach den gesamten Inhalt sichern)                                         

    4.
    Wechseln ins Root-Verzeichnis C:
    Sichern durch Umbenennen (soweit vorhanden), z.B.

    attrib -r -s -h os2krnl
    attrib -r -s -h os2ldr

    copy os2krnl os2krnl_21.sav
    copy os2ldr os2ldr_21.sav
    copy os2dump os2dump_21.sav

    copy \os2\dll\doscall1.dll           \os2\dll\doscall1_21.dll
    copy \os2\system\harderr.exe       \os2\system\harderr_21.exe1        
    copy \os2\sesdd32.sys       \os2\sesdd32_21.sys             
    copy \os2\boot\os2apic.psd    \os2\boot\os2apic_21.psd 


    5.
    Wechseln zu C:\ecs\install22\smp:

    copy *.tdf \os2.system\trace
    copy *.tff \os2\system\trace

    copy doscall1.dll C:\os2\dll
    copy harderr.exe  C:\os2\system
    copy sesdd32.sys  C:\os2
    copy os2apic.psd  C:\os2\boot

    copy os2krnl C:\
    copy os2ldr  C:\
    copy os2dump C:\

    6.
    Config.sys: Einträge zu sesdd32.sys und os2apic.psd scheinen entbehrlich, sind hier nicht vorhanden.         
    Die oben abgemeldeten Attribute werden beim folgenden Reboot eigentlich automatisch neu gesetzt.

    7. Reboot
     

Natürlich übernehme ich keine Haftung für fremde Rechner...

[wilfried]

Hallo Lothar,

danke für den Tipp. Da es um mein Produktionssystem geht war ich bisher zu ängstlich.
Aber eigentlich spricht nichts dagegen, hier gibt es, dank dfsee, ein funktionierendes Sicherungskonzept für die Bootpartition, falls etwas schief läuft ...
Ok, sobald hier wieder der Spieltrieb ausbricht, gehe ich es an.