T6x Anleitung: FSB 1066 CPUs inkl. Core 2 Quad in Thinkpad T61 benutzen + GPU undervolten

Beim X9100 sollte ja eigentlich der Mulitplikator unlocked sein oder? Ist trotzdem bei 15 Schluss? Ich komme leider mit TS/IBM_ECW nicht höher.
 
Would I be able to use these bios on a Thinkpad with Intel graphics. Many thank

- - - Beitrag zusammengeführt - - -

Wäre ich in der Lage, diese Bios auf einem Thinkpad mit Intel-Grafik zu verwenden.Vielen Dank
 
Yes, you can use all the BIOS files from the first post on any T61 with Intel graphics. Any GPU undervolting for Nvidia graphics that might be included in that BIOS does not apply then.
 
Hi !

Ich habe mich wegen dem thread hier angemeldet und möchte einen dankeschön dafür aussprechen.
Im Grunde war ich nur auf der suche nach einem Laptop mit rs-232...
Nach ein bisschen suche kam ich auf dem Entschluss das der t61 geeignet wäre , also ebay t61 15,4 Wide geschossen (das erst beste Angebot ) und den Ultrabay schacht rs232.

Nach ein bisschen google fand ich die Seite hier. Lange Rede kurzer Sinn , jetzt läuft ein q9100 in dem Ding und warte noch auf dem Backlight LED.
Bei der CPU stress komme ich um die 64 Grad Höchstwert und etwa 48 watt max. unter Manjaro mit tlp Einstellungen.

Auf jeden Fall, dank der Anleitung hat die Modifikation geklappt.
Was allerdings anders war als in der Beschreibung beschrieben ist, das der 0 Ohm Widerstand oder was das sein soll auf den Bildern um den FSB zu erhöhen, bei mir entfernt musste.
Zuerst habe ich den Kabel angelötet wie auf den Bilder zu sehen ist und es ging nichts. Nach mehreren versuchen zu starten habe ich den Kabel auf der andere Seite angelötet, also den Wiederstand ausgelassen und erst dann konnte ich booten.
Ich habe das Board mit der Nummer 41w6438 drinne, vielleicht hilft das jemanden der sich die mühe macht die 22 Seiten durchzulesen und das hier findet ,

Im nachhinein noch so viel, ich hätte mich besser für den x9100 entschieden, der q9100 lässt sich nicht so runtertakten und ich komme im besten Fall auf 16 watt .
Ich habe hier noch einen p8400 mit dem habe ich 9 watt geschafft!
Gruß
 
Zuletzt bearbeitet:
Zum Bootlogo:
* https://ittutorials.net/computer-repair/laptop/change-bios-boot-screen-logo-image-lenovo-laptops/
* https://thinkpad-forum.de/threads/1...Kinderleicht-(inkl-BIOS-Update-vom-USB-Stick)

Zu meiner Frage:
Da man für die GPU die Spannung mittels EC-Firmware-Patch absenken kann, müsste das doch auch für die CPU gehen? Das wäre doch mal eine Innovation, auch ohne Software-Tools gleich ab Boot kühler, länger, und leiser.
Dazu müsste man wissen, wie weit sich generell für alle Modelle, die von einer Bios-Version unterstützt werden, die Spannung pauschal absenken lässt, ohne daß dann einzelne Exemplare instabil werden. Evtl. kann man ja nach Tests per Software für sein individuelles Gerät dann noch eine weitere Absenkung vornehmen (alles über fertig gepatchte Bios-Dateien, so wie hier für die GPU).

Dazu bräuchte es jemanden, der sich mit der Modifikation dieser Dateien auskennt. el-sahef evtl.?
Oder geht sowas aus irgendwelchen Gründen garnicht per Firmware-Mod?
 
Hi all, I have a question if something like that happened to someone. I flashed the Highsun BIOS 0,95 into my T61 with NVS 140m graphics card, operation was successful, the CPU P9700 works on the board, but graphics card is not undervolted, still running with factory voltage. I reflashed BIOS several times, without any change, voltage is still factory. Did anyone encounter a problem?Any idea what can be a problem? Thanks.
 
Hardware mod is too complicated for me. I wonder if it is a difference in the board. I undervolted GPU using BIOS on many boards with FRU 44C3924, this board has FRU 42W7649.
 
I see other posts in English, hopefully nobody minds if I do!

I've done the quad core mod on a widescreen T61 and everything is working very well- except getting proper ACPI/voltage/multiplier settings working under linux. I'm hoping someone out there who has gotten things working under linux can point me in the right direction.

I'm running a Q9000 and I've modified the .aml files successfully as far as I can tell. They appear to be loaded by the kernel on boot, but I see differences between cores 0-1 and 2-3 from c2ctl, temperatures are higher than under windows with throttlestop, the multiplier changes on cores 0-1 under load but not on 2-3, and the voltage changes on 0-1 under load (which I think should remain steady?) while no changes occur on cores 2-3.

If anyone out there understands c2ctl and the specific needs of linux, I would dearly appreciate your insight. The machine runs great under Windows- but I don't :)
 
Did you do everything according to this post? Please post your SSDT6.

Normally, when the SSDT tables are loaded and Speedstep is activated with c2ctl on cores 2 and 3 frequency and voltage change should work on those too. So it seems that there is either a mistake in the SSDTs or they are not loaded properly.
 
Hi,
Thanks so much for helping.

edit: to be completely clear- yes, I did follow the instructions in that post.
I'm going to have to reboot into Linux to get the previous version of SSDT6 that I used, but I can tell you that the behavior was the same with this file as well as the earlier version where I made fewer edits. The first time, I only changed the few lines that you mentioned in your comments in a previous post. In this file I changed a few earlier values (in the SPSS section) to see if they had any effect. I have no experience with this acpi coding language.
edit: my instinct is that the code isn't being loaded properly. The kernel does report "loaded" though at 0.000 seconds in the log
Code:
 * Intel ACPI Component Architecture
 * AML Disassembler version 20130823-64
 * Copyright (c) 2000 - 2013 Intel Corporation
 * 
 * Disassembly of SSDT6.aml, Thu Jun  5 16:09:31 2014
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x00000240 (576)
 *     Revision         0x01
 *     Checksum         0xA5
 *     OEM ID           "PmRef"
 *     OEM Table ID     "Cpu0Ist"
 *     OEM Revision     0x00000100 (256)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20050513 (537199891)
 */
DefinitionBlock ("SSDT6.aml", "SSDT", 1, "PmRef", "Cpu0Ist", 0x00000100)
{

    External (_PR_.CPU0, ProcessorObj)
    External (_SB_.PCI0.LPC_.EC__.HT10, FieldUnitObj)
    External (_SB_.PCI0.LPC_.EC__.LPMD, MethodObj)    // 0 Arguments
    External (CFGD, IntObj)
    External (DT00, FieldUnitObj)
    External (LWST, FieldUnitObj)
    External (NPSS, IntObj)
    External (PDC0, IntObj)

    Scope (\_PR.CPU0)
    {
        Method (_PPC, 0, NotSerialized)  // _PPC: Performance Present Capabilites
        {
            Store (0x00, Local0)
            Store (\_SB.PCI0.LPC.EC.LPMD (), Local0)
            If (LNot (Local0))
            {
                If (LOr (\DT00, \_SB.PCI0.LPC.EC.HT10))
                {
                    Store (\LWST, Local0)
                }
            }

            Return (Local0)
        }

        Method (_PCT, 0, NotSerialized)  // _PCT: Performance Control
        {
            If (LAnd (And (CFGD, 0x01), And (PDC0, 0x01)))
            {
                Return (Package (0x02)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x00,               // Bit Width
                            0x00,               // Bit Offset
                            0x0000000000000000, // Address
                            ,)
                    }, 

                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x00,               // Bit Width
                            0x00,               // Bit Offset
                            0x0000000000000000, // Address
                            ,)
                    }
                })
            }

            Return (Package (0x02)
            {
                ResourceTemplate ()
                {
                    Register (SystemIO, 
                        0x10,               // Bit Width
                        0x00,               // Bit Offset
                        0x00000000000000B2, // Address
                        ,)
                }, 

                ResourceTemplate ()
                {
                    Register (SystemIO, 
                        0x08,               // Bit Width
                        0x00,               // Bit Offset
                        0x00000000000000B3, // Address
                        ,)
                }
            })
        }

        Method (XPSS, 0, NotSerialized)
        {
            If (And (PDC0, 0x01))
            {
                Return (NPSS)
            }

            Return (SPSS)
        }

        Name (SPSS, Package (0x03)
        {
            Package (0x06)
            {
                0x000007D0, 
                0x000088B8, 
                0x0000006E, 
                0x0000000A, 
                0x00000083, 
                0x00000000
            }, 

            Package (0x06)
            {
                0x00000640, 
                0x000088B8, 
                0x0000006E, 
                0x0000000A, 
                0x00000183, 
                0x00000001
            }, 

            Package (0x06)
            {
                0x000004B0, 
                0x00003E80, 
                0x0000006E, 
                0x0000000A, 
                0x00000283, 
                0x00000002
            }
        })
        Name (_PSS, Package (0x03)  // _PSS: Performance Supported States
        {
            Package (0x06)
            {
                0x000007D0, 
                0x000088B8, 
                0x0000000A, 
                0x0000000A, 
                0x0000471B, 
                0x0000471B
            }, 

            Package (0x06)
            {
                0x00000640, 
                0x000088B8, 
                0x0000000A, 
                0x0000000A, 
                0x0000461B, 
                0x0000461B
            }, 

            Package (0x06)
            {
                0x000004B0, 
                0x00003E80, 
                0x0000000A, 
                0x0000000A, 
                0x0000061B, 
                0x0000061B
            }
        })
        Method (_PSD, 0, NotSerialized)  // _PSD: Power State Dependencies
        {
            If (And (CFGD, 0x01000000))
            {
                If (And (PDC0, 0x0800))
                {
                    Return (Package (0x01)
                    {
                        Package (0x05)
                        {
                            0x05, 
                            0x00, 
                            0x00, 
                            0xFE, 
                            0x02
                        }
                    })
                }

                Return (Package (0x01)
                {
                    Package (0x05)
                    {
                        0x05, 
                        0x00, 
                        0x00, 
                        0xFC, 
                        0x02
                    }
                })
            }

            Return (Package (0x01)
            {
                Package (0x05)
                {
                    0x05, 
                    0x00, 
                    0x00, 
                    0xFC, 
                    0x01
                }
            })
        }
    }
}

- - - Beitrag zusammengeführt - - -

Just a couple follow-up questions...

In the speedstep-on.service, the startup command for c2ctl is:

ExecStart=/usr/sbin/c2ctl 3 -e

Should that in fact be ExecStart=/usr/sbin/c2ctl 2-3 -e or ExecStart=/usr/sbin/c2ctl 0-3 -e in order to activate speedstep on the last 2 cores? It seems to me that the command as-is will only start it on core 3. At any rate, I've tried to enable it manually and nothing changes on cores 2-3. The documentation for c2ctl seems to want binary values on the command line, but there's no mention of how to generate those values. In my case, what I've been able to determine is that in the lowest performance state, that appears to be "6" (which seems to correspond to the hex value of a multiplier of 6), medium is "7" (not what I specified in my SSDT6, but also seems to correspond to a multiplier of 7) and highest performance level is "71" which I assume is some kind of binary representation of the hex 47 from the file, which represents a 7.5 multiplier. Why 71? I'm sure none of this is relevant or related to my issue. I still suspect that due to some mistake I've made, the SSDT files either aren't being loaded or aren't being used.

Here is the output from c2ctl:

Code:
CPU0
      Current  Target    Min.    Max.
FID:       71      72       6      71
VID:       37      44      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE

CPU1
      Current  Target    Min.    Max.
FID:       71       6       6      71
VID:       37      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE

CPU2
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = FALSE

CPU3
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = FALSE

If I issue a "sudo c2ctl 0-3 6 27" from the command line, I get this output from c2ctl:
Code:
CPU0
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE

CPU1
      Current  Target    Min.    Max.
FID:        6      71       6      71
VID:       37      37      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE

CPU2
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = FALSE

CPU3
      Current  Target    Min.    Max.
FID:        6       6       6      71
VID:       27      27      27      37
ESIT_ENABLE = TRUE    ESIT_LOCK = FALSE

So, it appears that c2ctl is functioning to some extent.
In the current readme for c2ctl, in his DSDT example, he shows binary values for frequency and "power consumption" rather than hex. Does that indicate a change in newer versions of c2ctl? Are these values even relevant? Or are the only relevant values the FID/VID values?

I'm going to go back and try to verify that my dsl file for SSDT6 actually compiled properly. I know that it gave no errors and there are no error messages "loading" it at boot (I'm not sure if it's actually being loaded) but perhaps it compiled in such a way that the kernel can't use it and so it just ignores it?

edit: It appears that the .aml file is properly compiled... here is the output:
Code:
~/Documents/t61$ iasl -tc SSDT6uv.dsl

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20180105
Copyright (c) 2000 - 2018 Intel Corporation

SSDT6uv.dsl     96:         Method (XPSS, 0, NotSerialized)
Warning  4089 -                       ^ Object is not referenced

ASL Input:     SSDT6uv.dsl - 218 lines, 5871 bytes, 32 keywords
AML Output:    SSDT6.aml - 581 bytes, 7 named objects, 25 executable opcodes
Hex Dump:      SSDT6uv.hex - 5809 bytes
 
Zuletzt bearbeitet:
I think it should be like this for a Q9000:

Code:
Name (SPSS, Package (0x03)
        {
            Package (0x06)
            {
                0x000007D1, 
                0x000088B8, 
                0x0000006E, 
                0x0000000A, 
                0x00000083, 
                0x00000000
            }, 

            Package (0x06)
            {
                0x000007D0, 
                0x000088B8, 
                0x0000006E, 
                0x0000000A, 
                0x00000183, 
                0x00000001
            }, 

            Package (0x06)
            {
                0x00000640, 
                0x00003E80, 
                0x0000006E, 
                0x0000000A, 
                0x00000283, 
                0x00000002
            }
        })
        Name (_PSS, Package (0x03)  // _PSS: Performance Supported States
        {
            Package (0x06)
            {
                0x000007D1, 
                0x000088B8, 
                0x0000000A, 
                0x0000000A, 
                0x0000481B, 
                0x0000481B
            }, 

            Package (0x06)
            {
                0x000007D0, 
                0x000088B8, 
                0x0000000A, 
                0x0000000A, 
                0x0000471B, 
                0x0000471B
            }, 

            Package (0x06)
            {
                0x00000640, 
                0x00003E80, 
                0x0000000A, 
                0x0000000A, 
                0x0000061B, 
                0x0000061B
            }
        })

You have to specify the minimum (6x for Q9000), maximum (7.5x for Q9000) and IDA state (8.5x for Q9000). The IDA state has 1 MHz higher frequency stated than the max state (don't know why, it's just how they do it in the tables that the BIOS provides) and a multiplier 1 higher than in maximum state.

ExecStart=/usr/sbin/c2ctl 3 -e is correct, those scripts worked for me when I had the T61 with the quadcore. There is no need to explicitly enable EIST on core 2 because it can only be enabled or disabled for a group of 2 cores (a core 2 quad is just two dual cores on the same package). There is nothing else that you need c2ctl for. The first two cores should have EIST enabled by the BIOS already. The Linux kernel handles the voltage and multiplicator changes when it gets the correct SSDT tables loaded by the bootloader and EIST is enabled for all cores.

If it does not work, there is either a mistake in the tables, they do not get loaded properly or EIST is not enabled with c2ctl on cores 2 and 3 (enabling it on core 3 will also enable it on core 2 and vice versa).
 
Zuletzt bearbeitet:
Thanks so much for the clarifications... it's very helpful as I feel like I'm mostly flying blind. I feel like I'm starting to develop enough of a sense of what's supposed to be going on that I can at least try to approach the problem scientifically.

So, I made the changes you suggested- and while the behavior _may_ have changed slightly (I'll explain that after) the key problems still persist. Cores 2-3 stay locked at a multiplier of 6 (or whatever I set them at) while cores 0-1 do change according to load, including the voltage - which is exactly what I don't want. I could live with the multipliers on 2-3 being stuck at 6, but as I know that my CPU will run at 1.05V (stress tested under prime95 for hours) I'd much prefer to keep the cores all running at minimum voltage, mainly for heat but also safety reasons. I say safety because, as you may have noticed, on my system, under load, the reported VIDs go up to 37, and occasionally appear to be trying to hit 44 (!) I have no idea how accurate these readings are, or if they're even accurate, but I certainly don't want the CPU running at 1.2-1.3V

I believe I have a few clues in the kernel log.

The kernel is at least attempting to load the aml files.

However, I'm wondering if this is an important clue:

[ 0.000000] ACPI: 6 ACPI AML tables successfully acquired and loaded

There are actually 7 .aml files in /boot/acpi. Does this mean that it's failing on one (maybe SSDT6.aml)? Or is this normal behavior?

My assumption, without fully understanding the code involved, is that we're setting the max and min values for both multiplier and core voltage (in 3 FID/VID pairs, high, medium, low) so if things were working properly, I would not only see EIST working on all 4 cores, but the actual/target/min/max voltage values reported by c2ctl should always be the same, in my case, 27. Is that right?

I feel like I'm very close, and yet I'm really worried about running the machine under linux at all until this is resolved as I don't want to kill the CPU with 1.3V!
 
Zuletzt bearbeitet:
edit: old post was unlocked, this became redundant.
 
Zuletzt bearbeitet:
I've been messing around with the ACPI tables trying to figure out what's going on, and it's almost 100% certain that my tables aren't being loaded. I dumped the ACPI tables on my machine and found that they're quite different from those in the archive linked in the instructions. I'm guessing that's perfectly normal as my BIOS might be different than that of the original machine. The power state settings in my ACPI tables are in ssdt9. I decided to edit that file and try to get it to load all on its own (not even sure this is possible) and in the process realized that my kernel log still says "6 ACPI tables found and loaded"... So, I'm guessing that they're being loaded from the firmware, not from my files. Why? I'm stumped. I tried moving the location of the acpi command around in grub - nothing has any effect.

Is it possible my kernel doesn't support dynamically loading ACPI tables? Is this something that needs to be enabled at compile-time?

This also raises another question: how many of these ACPI tables actually need to be edited in order to set the voltage and clock multipliers? Could I theoretically just edit the one SSDT file on my machine with those parameters and override the one in the firmware? Or do you need a certain set of files, all as one unit? Would there be any advantage (assuming I can ever get the files to load) to modifying my own ACPI tables (i.e. newer feature set or something?)

At any rate, I'm stuck with the files refusing to load for some reason. I'll try to look at the kernel. For the record, I'm doing all this on Lubuntu 18.04, so it's a current kernel (maybe too current??)

Thanks again for the help.

edit: status update


I have done some more experimentation and I think I've isolated the "problem", if it is in fact a problem. The issue I'm having seems to be related to grub. When I tried to load the acpi command the normal way, with /etc/default/grub and putting the command in GRUB_CMDLINE_LINUX_DEFAULT="" or GRUB_CMDLINE_LINUX="", the acpi command seemed to have no effect at all.

I decided to force the issue and put the acpi command directly into grub.cfg, and voila! It's definitely doing something different- in fact, it seems to be working as expected, other than that it's throwing lots of ACPI errors on boot such as:

Code:
[    0.000000] ACPI: Core revision 20170831
[    0.000000] ACPI Error: [_TPC] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.000000] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.000000] ACPI Exception: AE_ALREADY_EXISTS, (SSDT:TP-7V   ) while loading table (20170831/tbxfload-228)
[    0.000000] ACPI Error: [SSDT] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.000000] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.000000] ACPI Exception: AE_ALREADY_EXISTS, (SSDT:TP-7V   ) while loading table (20170831/tbxfload-228)
[    0.000000] ACPI Error: 2 table load failures, 10 successful (20170831/tbxfload-246)

and

Code:
[    0.068340] ACPI: Added _OSI(Module Device)
[    0.068340] ACPI: Added _OSI(Processor Device)
[    0.068340] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.068340] ACPI: Added _OSI(Processor Aggregator Device)
[    0.068340] ACPI: Added _OSI(Linux-Dell-Video)
[    0.068340] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.068340] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[    0.068340] ACPI: EC: EC started
[    0.068340] ACPI: EC: interrupt blocked
[    0.069671] ACPI: \: Used as first EC
[    0.069674] ACPI: \: GPE=0x12, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.069676] ACPI: \: Used as boot ECDT EC to handle transactions
[    0.069830] ACPI: Executed 1 blocks of module-level executable AML code
[    0.076009] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[    0.088943] ACPI: Dynamic OEM Table Load:
[    0.088953] ACPI: SSDT 0xFFFF94BDF66BE800 000240 (v01 PmRef  Cpu0Ist  00000100 INTL 20050513)
[    0.088969] ACPI Error: [_PPC] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.088978] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.089355] ACPI: Dynamic OEM Table Load:
[    0.089364] ACPI Exception: AE_NO_MEMORY, SSDT 0xFFFF94BDF66C1000 Table is duplicated (20170831/tbdata-562)
[    0.089375] No Local Variables are initialized for Method [GCAP]
[    0.089377] Initialized Arguments for Method [GCAP]:  (1 arguments defined for method invocation)
[    0.089378]   Arg0:           (ptrval) <Obj>           Buffer(8) 00 00 00 00 BF 0B 00 00
[    0.089392] ACPI Error: Method parse/execution failed \_PR.CPU0.GCAP, AE_ALREADY_EXISTS (20170831/psparse-550)
[    0.089420] ACPI Error: Method parse/execution failed \_PR.CPU0._PDC, AE_ALREADY_EXISTS (20170831/psparse-550)
[    0.089428] ACPI: Marking method _PDC as Serialized because of AE_ALREADY_EXISTS error
[    0.089886] ACPI: Dynamic OEM Table Load:
[    0.089894] ACPI: SSDT 0xFFFF94BDF6691F00 0000C8 (v01 PmRef  Cpu1Ist  00000100 INTL 20050513)
[    0.089908] ACPI Error: [_PPC] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.089915] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.090091] ACPI: Dynamic OEM Table Load:
[    0.090099] ACPI: SSDT 0xFFFF94BDF66AF240 000085 (v01 PmRef  Cpu1Cst  00000100 INTL 20050513)
[    0.090113] ACPI Error: [_CST] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload-378)
[    0.090119] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252)
[    0.091348] ACPI: Interpreter enabled
[    0.091374] ACPI: (supports S0 S3 S4 S5)
[    0.091376] ACPI: Using IOAPIC for interrupt routing

So, my very amateur interpretation of these errors is that there's some kind of conflict between my existing bios ACPI tables and the ones being loaded. In the interest of experimentation, I dumped my own ACPI tables and edited the file SSDT9 which contains the relevant code in my bios and loaded _only_ that file, thinking maybe it would simply overwrite that one file in memory. Interestingly, the system _still works_ as expected, i.e. the voltage seems to stay at minimum (27) regardless of load and all 4 cores do appear to function with EIST. (I need to do some scientific tests, but the values do change logically according to load).

However, I still have the same errors as posted above, so somehow the kernel isn't totally happy with this situation.

As always, any insight is most appreciated!
 
Zuletzt bearbeitet:
Moin, zunächst mal vielen Dank für die Anleitung!

Habe das modifizierte Bios geflasht und den Hardwaremod gemäß der Anleitung durchgeführt. Bedauerlicherweise liegt der FSB immer noch bei 800 MHz. Woran kann das liegen?
Getestet wurde mit T9600 und P8700, Gerät ist ein T61 14,1" Widescreen mit Intel Grafik.

Gruß, Jonas
 

Anhänge

  • Gurkensalat.jpg
    Gurkensalat.jpg
    244,3 KB · Aufrufe: 14
Zuletzt bearbeitet:
Habe das modifizierte Bios geflasht und den Hardwaremod gemäß der Anleitung durchgeführt. Bedauerlicherweise liegt der FSB immer noch bei 800 MHz. Woran kann das liegen?
Getestet wurde mit T9600 und P8700, Gerät ist ein T61 14,1" Widescreen mit Intel Grafik.
Gruß, Jonas


Hallo Jonas,
Haben Sie die Schaltung neben dem Widerstand durchgeschnitten?
 
Hallo, danke für die rasche Antwort!
Ja, habe die Lane durchtrennt (denke ich). Wie tief muss man denn dafür schneiden? Bin so 2-3 mal mit einem Teppichmesser drübergegangen.
 
Hallo, danke für die rasche Antwort!
Ja, habe die Lane durchtrennt (denke ich). Wie tief muss man denn dafür schneiden? Bin so 2-3 mal mit einem Teppichmesser drübergegangen.


Gern geschehen. Entschuldigung für mein schreckliches Deutsch :)
Am besten prüfen Sie mit einem Multimeter die Durchgängigkeit zwischen dem Widerstand, an dem Sie den Draht angeschlossen haben, und dem Durchkontakt ("via") direkt daneben. Es sollte keine Kontinuität geben.
 
  • ok1.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen
Zurück
Oben