Falcosoft wrote on 2025-12-14, 12:14:

thewhiteambit wrote on 2025-12-14, 12:03:

Falcosoft wrote on 2025-12-14, 11:37:

@Edit:
I have also tested this with an I7-4770k on a GA-Z97X-UD5H board and it works the 1st time after a cold boot. If I restart DOS with Ctrl+Alt+Del after 1st successful usage and start the TSR again then it does the same as on the Phenom II X4 system. That is it restarts the system after Step 3.

Strange observation. What happened when you try to run it a second time after successful run without rebooting?

It seems I can run many instances of the TSR without any problems in the same DOS session and the test application (DOS64USE.COM) can communicate with the active ones.
Maybe it's a BIOS quirk. I will try to determine what conditions are necessary exactly to reproduce the problem.

I didn't remember the step numbers correctly either, but initializing is a bit early/unexpected to crash. Crtl-Alt-Del not allowing to run sure sounds like a Bios quirk. What happens when you Reset, Boot to DOS, press Crtl-Alt-Del without running it and try it after that? Still crashing?

@Falconsoft or did you mean it crash reboots at "Step 3 (Start SMP)" or "(Step 2) Initialize AP"? I am confused now.

thewhiteambit wrote on 2025-12-14, 22:21:

@Falconsoft or did you mean it crash reboots at "Step 3 (Start SMP)" or "(Step 2) Initialize AP"? I am confused now.

It always reboots at 'Step 3: Start SMP'.
I always reported Step 3 as the problematic step but first time I made a mistake with the exact wording of the message.

But then you wrote this:

It is a bit strange the crash is happening at STEP 3 already (prepare SMP) and not at start of SMP.

I just mentioned 'STEP 2: Initialize AP' since according to the above sentence you remembered the actual order of steps wrongly:
There is no such step as 'prepare SMP' it's 'Initialize AP' instead, and it's not Step 3 but Step 2.

BTW, I could not reproduce the reboot problem on the I7-4770K system consistently.
During my testing it worked many times even after warm/soft reboots and rebooted once even after a cold reboot after I selected 'Option 0: Halt' in the DOS64USE.COM test application.

But on the Phenom II system the reboot after 'Step3: Start SMP' can be reproduced consistently.

Falcosoft wrote on 2025-12-15, 01:05:

It always reboots at 'Step 3: Start SMP'. I always reported Step 3 as the problematic step but first time I made a mistake with […]
Show full quote

thewhiteambit wrote on 2025-12-14, 22:21:

@Falconsoft or did you mean it crash reboots at "Step 3 (Start SMP)" or "(Step 2) Initialize AP"? I am confused now.

It always reboots at 'Step 3: Start SMP'.
I always reported Step 3 as the problematic step but first time I made a mistake with the exact wording of the message.

But then you wrote this:

It is a bit strange the crash is happening at STEP 3 already (prepare SMP) and not at start of SMP.

I just mentioned 'STEP 2: Initialize AP' since according to the above sentence you remembered the actual order of steps wrongly:
There is no such step as 'prepare SMP' it's 'Initialize AP' instead, and it's not Step 3 but Step 2.

BTW, I could not reproduce the reboot problem on the I7-4770K system consistently.
During my testing it worked many times even after warm/soft reboots and rebooted once even after a cold reboot after I selected 'Option 0: Halt' in the DOS64USE.COM test application.

But on the Phenom II system the reboot after 'Step3: Start SMP' can be reproduced consistently.

All right, it makes way more sense to me when crashing at start of SMP instead of when initializing AP (where it prepares SMP). I am a bit busy now but will try to give a solution or something that will provide deeper insights with a new binary, once I find some time. Thank you for providing the specific information.

thewhiteambit wrote on 2025-12-15, 08:05:

Falcosoft wrote on 2025-12-15, 01:05:

It always reboots at 'Step 3: Start SMP'. I always reported Step 3 as the problematic step but first time I made a mistake with […]
Show full quote

thewhiteambit wrote on 2025-12-14, 22:21:

@Falconsoft or did you mean it crash reboots at "Step 3 (Start SMP)" or "(Step 2) Initialize AP"? I am confused now.

It always reboots at 'Step 3: Start SMP'.
I always reported Step 3 as the problematic step but first time I made a mistake with the exact wording of the message.

But then you wrote this:

It is a bit strange the crash is happening at STEP 3 already (prepare SMP) and not at start of SMP.

I just mentioned 'STEP 2: Initialize AP' since according to the above sentence you remembered the actual order of steps wrongly:
There is no such step as 'prepare SMP' it's 'Initialize AP' instead, and it's not Step 3 but Step 2.

BTW, I could not reproduce the reboot problem on the I7-4770K system consistently.
During my testing it worked many times even after warm/soft reboots and rebooted once even after a cold reboot after I selected 'Option 0: Halt' in the DOS64USE.COM test application.

But on the Phenom II system the reboot after 'Step3: Start SMP' can be reproduced consistently.

All right, it makes way more sense to me when crashing at start of SMP instead of when initializing AP (where it prepares SMP). I am a bit busy now but will try to give a solution or something that will provide deeper insights with a new binary, once I find some time. Thank you for providing the specific information.

I just mention that the CpuSpd DOS utility works on my Phenom II system and CpuSpd also activates all application processors in order to be able to set the P-state transition MSRs on all CPU cores.
CpuSpd - A Hardware Based CPU Speed Control Utility for DOS/Win9X Retro Gaming

Falcosoft wrote on 2025-12-15, 09:01:

thewhiteambit wrote on 2025-12-15, 08:05:

Falcosoft wrote on 2025-12-15, 01:05:

It always reboots at 'Step 3: Start SMP'. I always reported Step 3 as the problematic step but first time I made a mistake with […]
Show full quote

It always reboots at 'Step 3: Start SMP'.
I always reported Step 3 as the problematic step but first time I made a mistake with the exact wording of the message.

But then you wrote this:

I just mentioned 'STEP 2: Initialize AP' since according to the above sentence you remembered the actual order of steps wrongly:
There is no such step as 'prepare SMP' it's 'Initialize AP' instead, and it's not Step 3 but Step 2.

BTW, I could not reproduce the reboot problem on the I7-4770K system consistently.
During my testing it worked many times even after warm/soft reboots and rebooted once even after a cold reboot after I selected 'Option 0: Halt' in the DOS64USE.COM test application.

But on the Phenom II system the reboot after 'Step3: Start SMP' can be reproduced consistently.

All right, it makes way more sense to me when crashing at start of SMP instead of when initializing AP (where it prepares SMP). I am a bit busy now but will try to give a solution or something that will provide deeper insights with a new binary, once I find some time. Thank you for providing the specific information.

I just mention that the CpuSpd DOS utility works on my Phenom II system and CpuSpd also activates all application processors in order to be able to set the P-state transition MSRs on all CPU cores.
CpuSpd - A Hardware Based CPU Speed Control Utility for DOS/Win9X Retro Gaming

While I never had doubts SMP is possible on AMD CPUs like the Phenom II, this is very interesting information for me in general. I was not aware of this tool.

The problem most likely is just a timing or a "for some CPUs also have to do this and that (like enabling SVR what I already prepared) and can't do bla..." kind of bug.

I let out some of the possible options because the current option set was enough for my CPUs and sometimes less is more.

thewhiteambit wrote on 2025-12-15, 09:21:

... While I never had doubts SMP is possible on AMD CPUs like the Phenom II, this is very interesting information for me in gene […]
Show full quote

...
While I never had doubts SMP is possible on AMD CPUs like the Phenom II, this is very interesting information for me in general. I was not aware of this tool.

The problem most likely is just a timing or a "for some CPUs also have to do this and that (like enabling SVR what I already prepared) and can't do bla..." kind of bug.

I let out some of the possible options because the current option set was enough for my CPUs and sometimes less is more.

The source code of CpuSpd is also available (unfortunately not for the latest version).
download/file.php?id=149510
I think the relevant parts are in:
smp.asm
smpap.asm

Falcosoft wrote on 2025-12-15, 11:00:

The source code of CpuSpd is also available (unfortunately not for the latest version). download/file.php?id=149510 I think the […]
Show full quote

thewhiteambit wrote on 2025-12-15, 09:21:

... While I never had doubts SMP is possible on AMD CPUs like the Phenom II, this is very interesting information for me in gene […]
Show full quote

...
While I never had doubts SMP is possible on AMD CPUs like the Phenom II, this is very interesting information for me in general. I was not aware of this tool.

The problem most likely is just a timing or a "for some CPUs also have to do this and that (like enabling SVR what I already prepared) and can't do bla..." kind of bug.

I let out some of the possible options because the current option set was enough for my CPUs and sometimes less is more.

The source code of CpuSpd is also available (unfortunately not for the latest version).
download/file.php?id=149510
I think the relevant parts are in:
smp.asm
smpap.asm

Ok cool. But first, if you can try this altered Version:
-uses PID for timing
-stops AP first
-enables SVR
-only uses 32bit
-does not use pagetables
-places worker code at 1.6MB - 2.0MB in memory (so it will crash in DOOM, but can be also tested on a Dual Socket 5 with P54C Pentium)

luckybob wrote on 2025-12-13, 18:19:

thewhiteambit wrote on 2025-12-13, 17:55:

So a Dual-Socket 5? Then you would need to comment/disable USE_64BIT_LONG_MODE, USE_PAGETABLE and locate WORKER_BASE somewhere inside the available ram (currently at 768MB with enough space for the additional WORKER_SIZE (effectively where the stack starts growing to lower memory) and compile by yourself. USE_16BYTE_EXCEPTION_IDT and USE_12BYTE_EXCEPTION_IDTR could be problematic as well.

Chances are still bad this will work with the APIC, but I can't tell from my head. But it would tell you about missing APIC then.

yea... You're speaking Greek to me now. Programming is completely outside of my skill set. What was your target hardware for this? if I might be so bold to ask.

The version provided with my previous post has theoretical chances to also run on your Dual Socket 5 Pentium P54C, because it only uses 32bit and little ram. It would be great if you could try it.

thewhiteambit wrote on 2025-12-15, 21:29:

Ok cool. But first, if you can try this altered Version: -uses PID for timing -stops AP first -enables SVR -only uses 32bit -doe […]
Show full quote

Falcosoft wrote on 2025-12-15, 11:00:

The source code of CpuSpd is also available (unfortunately not for the latest version). download/file.php?id=149510 I think the […]
Show full quote

thewhiteambit wrote on 2025-12-15, 09:21:

... While I never had doubts SMP is possible on AMD CPUs like the Phenom II, this is very interesting information for me in gene […]
Show full quote

...
While I never had doubts SMP is possible on AMD CPUs like the Phenom II, this is very interesting information for me in general. I was not aware of this tool.

The problem most likely is just a timing or a "for some CPUs also have to do this and that (like enabling SVR what I already prepared) and can't do bla..." kind of bug.

I let out some of the possible options because the current option set was enough for my CPUs and sometimes less is more.

The source code of CpuSpd is also available (unfortunately not for the latest version).
download/file.php?id=149510
I think the relevant parts are in:
smp.asm
smpap.asm

Ok cool. But first, if you can try this altered Version:
-uses PID for timing
-stops AP first
-enables SVR
-only uses 32bit
-does not use pagetables
-places worker code at 1.6MB - 2.0MB in memory (so it will crash in DOOM, but can be also tested on a Dual Socket 5 with P54C Pentium)

Hi,
I would like to report that this version works on the Phenom II system!
The only way I can reproduce the reboot problem with this new version is to make it stay resident and then run DOS64USE.COM and then selecting '0: Halt Only' option and then finally start the TSR again. This way it always reboots the system at the same STEP 3 as before.

Falcosoft wrote on 2025-12-15, 22:37:

Hi, I would like to report that this version works on the Phenom II system! The only way I can reproduce the reboot problem wi […]
Show full quote

thewhiteambit wrote on 2025-12-15, 21:29:

Ok cool. But first, if you can try this altered Version: -uses PID for timing -stops AP first -enables SVR -only uses 32bit -doe […]
Show full quote

Falcosoft wrote on 2025-12-15, 11:00:

The source code of CpuSpd is also available (unfortunately not for the latest version). download/file.php?id=149510 I think the […]
Show full quote

The source code of CpuSpd is also available (unfortunately not for the latest version).
download/file.php?id=149510
I think the relevant parts are in:
smp.asm
smpap.asm

Ok cool. But first, if you can try this altered Version:
-uses PID for timing
-stops AP first
-enables SVR
-only uses 32bit
-does not use pagetables
-places worker code at 1.6MB - 2.0MB in memory (so it will crash in DOOM, but can be also tested on a Dual Socket 5 with P54C Pentium)

Hi,
I would like to report that this version works on the Phenom II system!
The only way I can reproduce the reboot problem with this new version is to make it stay resident and then run DOS64USE.COM and then selecting '0: Halt Only' option and then finally start the TSR again. This way it always reboots the system at the same STEP 3 as before.

Great news, so your Phenom II system probably just needed SVR enabled or PID timing. The sourcecode already had this prepared so I only needed to uncomment the macro flag definition.

I will make this default behavior in the next release, since it doesn't bother my CPUs. They run with and without these options.

What about the other CPU after Ctrl-Alt-Del, did it fix that too?

The minor inconvenience with restarting after HLT... no clue right now. We'll see but it's not my top priority right now.