PAE/NX CPU swap in T42P (2373-HTU)

[surrealmode]

A couple reasons - it would've costed more than twice as much, and I wasn't sure it'd be completely compatible.

I've got the new fan attached using some Arctic Silver thermal adhesive. Going to let it cure overnight and possibly add a bit more epoxy/silicone for reinforcement/vibration dampening (need to check temperature ratings).

[Thinkpad4by3]

I know they spin faster and are louder

I have a strange feeling you answered your own question.

A couple reasons - it would've costed more than twice as much, and I wasn't sure it'd be completely compatible.

I've got the new fan attached using some Arctic Silver thermal adhesive. Going to let it cure overnight and possibly add a bit more epoxy/silicone for reinforcement/vibration dampening (need to check temperature ratings).

Ok maybe not. Also...its called thermal grease or thermal paste. It isn't an adhesive. It used to be known as that because old AMD CPUs would stick so well from very high temperatures sticking the paste to the CPU and heatsink so much that the CPU would be near impossible to remove.

Intel Chips don't suffer from this issue unless they are old PGA chips.

[surrealmode]

Ok maybe not. Also...its called thermal grease or thermal paste. It isn't an adhesive. It used to be known as that because old AMD CPUs would stick so well from very high temperatures sticking the paste to the CPU and heatsink so much that the CPU would be near impossible to remove.

No, I mean this stuff: http://www.arcticsilver.com/arctic_silv ... hesive.htm

Since I can't properly "mushroom" the fan pins into the holes in the copper heatsink I needed something to hold it together.

[Thinkpad4by3]

No, I mean this stuff: http://www.arcticsilver.com/arctic_silv ... hesive.htm

Since I can't properly "mushroom" the fan pins into the holes in the copper heatsink I needed something to hold it together.

Wow I didn't know that stuff existed. Interesting.

[surrealmode]

I found some motivation tonight and went ahead with the CPU swap. At first I'd tried to swap the 745A in without flashing Screamer's BIOS but I got no video. So, I made an iso based on the flasher from the original modded bios and gave it a go.

It froze up towards the end of the process which gave me a bit of a scare but all seems well. I ran the flash a second time and saw it freeze in the same place. The README.txt in the original iso mentioned something about the flash process erroring out with a false positive but didn't mention hanging entirely.

After confirming that the original CPU worked with the new BIOS, I reinstalled the 745A and it booted! A Slackware Linux CD whose default kernel failed on the 745 with a PAE error booted fine on the 745A. However, I couldn't get Windows 10 1809 or 1607 to boot past the Windows logo. The 745 would boot to the point of giving an error about unsupported CPU features, but the 745A just hangs indefinitely. There doesn't appear to be anything going on the background (e.g. disk i/o). I let it sit for 30+ minutes just to be sure.

For those interested I took a couple pictures including of /proc/cpuinfo from Slackware. They can be found here: https://photos.app.goo.gl/5Sqxrsc7DL8HPnGR6

[Screamer]

Good to know that it actually works, although I don't understand why would Windows 10 freeze or enter a soft lock-up.

Could you install XP or Vista or 7 and run coreinfo ("coreinfo /f" in command prompt)? It might be a good idea to check if PAE and NX is detected under those versions, and maybe it could lead us to the cause of the lock-up.

[surrealmode]

Good to know that it actually works, although I don't understand why would Windows 10 freeze or enter a soft lock-up.

Could you install XP or Vista or 7 and run coreinfo ("coreinfo /f" in command prompt)? It might be a good idea to check if PAE and NX is detected under those versions, and maybe it could lead us to the cause of the lock-up.

The Coreinfo output from Windows XP for the Pentium M 770 can be found in this pastebin. I swapped out the 745A for the 770 last night while trying to troubleshoot the issue. It shows that NX wasn't detected Maybe that means the IA32_EFER.NX register hasn't been set (by the BIOS)?

I did try to boot the latest Windows 8.1 installer on the 745A (via USB a la Rufus) and it got to the menus. I didn't go any further.

I used bcdedit to toggle some flags in the BCD of the Windows 10 installer USB such as legacy menus, sos on, forcelegacyplatform, nx alwayson, etc. It'd go through the menus, let me e.g. select Safe Mode, then show a black and white progress bar which took a few minutes to reach 100%. Then it'd show the full screen centered Windows logo and lock up. I didn't yet try doing a null modem debug. I'd need to dock the ThinkPad to get access to the serial port and it's kind of in pieces at the moment (well, keyboard bezel isn't attached) so I haven't done it.

I tried to find some examples of the NX register being set in coreboot, seabios, grub, etc., and eventually came across this section of edk2 (aka tianocore). It's highly abstracted though. My thoughts are that to set that I'd need to modify something like the grub bootloader to flip that bit before chainloading the WIndows bootloader.

[Screamer]

Darn. Just as I had suspected, the BIOS was not made to handle or support an NX-capable processor. In this case, you are right about the NX register (bit 11) in the IA32_EFER model specific register (0xC0000080) that has not been set to 1 by the BIOS.

Nice idea, but before you chain GRUB and Windows' bootloader together, please take note that there is something that might prevent you from flipping the NX register.

There is a strange model specific register that goes by the name of IA32_MISC_ENABLE (0x01A0), which controls the NX register's capability of being disabled or enabled. If bit 34 in the IA32_MISC_ENABLE model specific register is set to 1 by default, that might prevent you from enabling the NX bit. You would need to set bit 34 to 0 to set the NX register to 1, in this case.

The 0x01A0 model specific register only prevents the NX bit flag (bit 20 in the EDX register) from being enabled or disabled, though. I have no idea if it has any effect on setting bit 11 in the IA32_EFER model specific register.

When "XD Bit Disable" in the IA32_MISC_ENABLE MSR (1A0H) bit 34 is set to 1, it should not be possible to enable the "execute disable" feature by setting IA32_EFER.NXE.

EDIT: Nevermind, it seems that it does have an effect on bit 11.

[surrealmode]

I thought I'd found something significant when seeing that Linux has the NX bit set:

Code: Select all

root@deep-thought:~# rdmsr 0xC0000080
800

That's both when booting from a Live CD (Ubuntu 12.04) and with a HDD install (Debian Stretch).

Turns out that arch/x86/kernel/head_32.S does the following, even when passing noexec=off to the kernel:

Code: Select all

        /* Clear bogus XD_DISABLE bits */
        call verify_cpu

        mov $0x80000001, %eax
        cpuid
        /* Execute Disable bit supported? */
        btl $(X86_FEATURE_NX & 31), %edx
        jnc enable_paging

        /* Setup EFER (Extended Feature Enable Register) */
        movl $MSR_EFER, %ecx
        rdmsr

        btsl $_EFER_NX, %eax
        /* Make changes effective */
        wrmsr

So, my plan to test grub modifications with Linux will require extra steps. I'll need to compile a kernel that *doesn't* set the bit, so I can see if grub does when I modify it to.

My first attempt at chainloading a Win10 USB installer via grub wasn't successful. Got something along the lines of "a disk read error has occurred".

The addition, possibly to the stub that resides in the MBR if there is enough space, will look something like this:

Code: Select all

mov $0xC0000080, %ecx  # setup EFER address-index
rdmsr                  # read EFER into (EDX,EAX)
bts $11, %eax          # set the NX-bit’s image to 1
wrmsr                  # write (EDX,EAX) into EFER

That was derived from a .ppt I found here.

[surrealmode]

Just to touch base, I'm still stuck at the logo with the Windows 10 installer.

I did go ahead and modify the grub MBR stub to set the NX bit, but apparently that is either the BIOS/firmware or OS's job to turn it on. Enabling it caused the system to immediately hang until a hard power off. The same USB stick I made with the modified MBR stub booted fine on a 64-bit system (with NX obviously enabled by the time grub flipped it on).

There's also the XD or execute disable bit which I tried clearing as well. Setting only this didn't cause a lockup but didn't fix the Windows 10 installer.

For reference, here is what I slipped into grub-core/boot/i386/pc/startup_raw.S:

Code: Select all

    /* enable NX */
    mov $0xC0000080, %ecx  /* setup EFER address-index */
    rdmsr                  /* read EFER into (EDX,EAX) */
    bts $11, %eax          /* set the NX-bit’s image to 1 */
    wrmsr                  /* write (EDX,EAX) into EFER */
    movl %cr4, %eax
    btc $7, %eax
    movl %eax, %cr4
    btc $7, %eax
    movl %eax, %cr4

    mov $0x000001A0, %ecx  /* disable NXD */
    rdmsr
    btr $(34-32), %edx
    wrmsr

I haven't given up entirely on this but Microsoft sure does make early boot issues tough to debug.