red-ray wrote on 2025-11-15, 12:31:

when I boot NT 3.51 SP5

LSS10999 wrote on 2025-11-15, 15:46:

Is your NT 3.51 Workstation instance on Service Pack 5, or is it RTM or maybe a different service pack level? I wonder if there were any official NT 3.51 kernel binary that actually worked with more than 8 CPUs (cores). That is, with RegisteredProcessors set to higher than 8 and a CPU with more than 8 actual cores.

As I specified SP5. My NT 3.51 Workstation is from the official MSDN CDs and RegisteredProcessors is always 32 even before I install SP5

As to if > 8 will ever work I have no real idea, back then were there any systems that supported NT 3.51 with > 8 CPUs? I doubt it.

I don't have a system with > 4 CPUs that I could sensibly install NT 3.51 on. My DL580 Gen8 has 120 CPUs/60 Cores, but there is no way it's going to run NT 3.51 as there is no RAID disk driver and AFAIK it can't boot NVMe drives, same for my 24 core DL560 G5.

I tested HAL MPS in WinNT 4.0 SP6 on Haswell and no PCI or PCIe device works.

I tested standard HAL (HAL.DLL) on several machines - Haswell, Coffee Lake, Sandy Bridge, Core2Duo and it works fine on all of them, so why use another MPS HAL?
What are the benefits of using HAL MPS?
Are there any WinNT applications that can take advantage of multiple cores???

red-ray wrote on 2025-11-15, 16:00:

As I specified SP5. My NT 3.51 Workstation is from the official MSDN CDs and RegisteredProcessors is always 32 even before I ins […]
Show full quote

red-ray wrote on 2025-11-15, 12:31:

when I boot NT 3.51 SP5

LSS10999 wrote on 2025-11-15, 15:46:

Is your NT 3.51 Workstation instance on Service Pack 5, or is it RTM or maybe a different service pack level? I wonder if there were any official NT 3.51 kernel binary that actually worked with more than 8 CPUs (cores). That is, with RegisteredProcessors set to higher than 8 and a CPU with more than 8 actual cores.

As I specified SP5. My NT 3.51 Workstation is from the official MSDN CDs and RegisteredProcessors is always 32 even before I install SP5

As to if > 8 will ever work I have no real idea, back then were there any systems that supported NT 3.51 with > 8 CPUs? I doubt it.

I don't have a system with > 4 CPUs that I could sensibly install NT 3.51 on. My DL580 Gen8 has 120 CPUs/60 Cores, but there is no way it's going to run NT 3.51 as there is no RAID disk driver and AFAIK it can't boot NVMe drives, same for my 24 core DL560 G5.

Well... never mind, as even 4 cores are well enough for NT 3.51 use cases.

My main issue at the moment is to look for the reason why it takes this long (>50 min) to boot NT 3.51 with NVME2K.

Gelip wrote on 2025-11-15, 16:09:

I tested HAL MPS in WinNT 4.0 SP6 on Haswell and no PCI or PCIe device works.

My Dual Intel Pentium II Overdrive (Deschutes) @ 333MHz system has used the HAL MPS 1.4 - APIC platform ever since 2000-01-14 and everything works.

Maybe your MPS table has issues, what's in it?
Have you tried both MPS 1.1 and MPS 1.4?

LSS10999 wrote on 2025-11-15, 16:17:

My main issue at the moment is to look for the reason why it takes this long (>50 min) to boot NT 3.51 with NVME2K.

You probably has unworked IRQ. In such situation it takes 1 second for each I/O request (on firing Fallback Timer).

SweetLow wrote on 2025-11-15, 18:02:

LSS10999 wrote on 2025-11-15, 16:17:

My main issue at the moment is to look for the reason why it takes this long (>50 min) to boot NT 3.51 with NVME2K.

You probably has unworked IRQ. In such situation it takes 1 second for each I/O request (on firing Fallback Timer).

I wonder if PCICFG is good enough for checking info about the system's IRQ info? If so, what should I pay attention to about the NVMe devices, that may be the cause of the issue?

Also, when I tested Win98SE installed on NVMe disk, even after applying all necessary patches (rloew's as well as PATCH9X), as well as copying all additional disk drivers, the startup process would hang at a relatively early phase (boot animations stopped), likely before any disk drivers are involved. It's still first boot after finishing the initial installation and nothing have been configured yet. I wonder if this hang is also due to IRQ problem? Not sure if it will eventually proceed after waiting long enough (like hours)...

A side topic: This board (ASRock X99M Killer/3.1) is my first test board for dISAppointment v0.2. Using its TPM port and with its LDRQ1# brought out using a wire, the LPC-ISA adapter works as expected after configuring the decoding ranges. It currently has a Sound Blaster 16 PnP (CT2950) installed, and is fully operational once it has been initialized, preferably with UNISOUND. Of several boards I experimented, this is the only board that can use ISA PnP cards (whereas other boards can only use non-PnP ones). ISA PnP probably works with other ASRock boards as well.

The board's UEFI BIOS offers very few options regarding IRQ. To free IRQ7 for the CT2950 I had to primarily disable the onboard audio, which wants that IRQ most. Later on I discovered I have to additionally disable onboard Intel LAN as that will also take IRQ7 if the board's serial port (which is on 3F8h/IRQ4) is enabled. The board has an additional network adapter (Atheros Killer E2200) which happened to have wider OS support, such as usable Packet and NDIS2 drivers, and it does not take an additional IRQ. IRQ5, on the other hand, is hopeless to free as it's wanted by pretty much everyone as far as I've tested.

I checked the system's PIRQ registers (00:1f.0, registers 60h and 68h) and right now only 3, 5, 10, 11 are taken by first four PIRQs with current setup. The other 4 PIRQs are inactive, including one exclusively for the onboard audio, and one exclusively for the Intel LAN.

My boot process is like, booting to DOS, just set up the LPC-ISA bridge and initialize the card with UNISOUND, then run GRUB4DOS to launch the NTLDR meant for NT 3.51. This process works, and CT2950 will work with NT 3.51's default SNDBLST driver (which is non-PnP) if already configured via UNISOUND. However, on this board, NT 3.51 seems to suggest IRQ7 is also being taken by something, but it allowed me to use IRQ2, so I adjusted UNISOUND to configure the sound card as such. After installing the driver, reboot, and wait long enough, I get to hear "Tada" after logging in. The sound card is working great!

And here's the question... Could it be NT 3.51's MPS HAL (APIC) is somehow configuring the IRQs differently? AFAICT IRQ7 should have been available under this circumstance, as back then the card did work correctly (including in Creative's DIAGNOSE) when I configured it to use IRQ7 while in DOS, Win3.x and 9x (even WinXP). The OSes were previously installed on SATA disks back then, yet I was not able to get UniATA to work with NT 3.51, so I had no idea of how NT 3.51's HAL works on this system until now.

And back to the IRQ fallback timer question... I wonder if this is tweakable in case of IRQ-broken environments like this, to hopefully improve performance and reduce startup delay, while avoiding breakage if possible...

Has anyone seen NVMe2K ATA SMART working on Windows 2003 please?

For me it works on W2K + WXP, but on 2003 error 1 (invalid function) is reported when SIV does the DeviceIoControl( SMART_RCV_DRIVE_DATA ) with IDE_COMMAND_IDENTIFY.

On W2K NVMe SMART still fails, but least ATA SMART works.

LSS10999 wrote on 2025-11-16, 02:59:

I wonder if PCICFG is good enough for checking info about the system's IRQ info? If so, what should I pay attention to about the […]
Show full quote

I wonder if PCICFG is good enough for checking info about the system's IRQ info? If so, what should I pay attention to about the NVMe devices, that may be the cause of the issue?

Also, when I tested Win98SE installed on NVMe disk, even after applying all necessary patches (rloew's as well as PATCH9X), as well as copying all additional disk drivers, the startup process would hang at a relatively early phase (boot animations stopped), likely before any disk drivers are involved. It's still first boot after finishing the initial installation and nothing have been configured yet. I wonder if this hang is also due to IRQ problem? Not sure if it will eventually proceed after waiting long enough (like hours)...

A side topic: This board (ASRock X99M Killer/3.1) is my first test board for dISAppointment v0.2. Using its TPM port and with its LDRQ1# brought out using a wire, the LPC-ISA adapter works as expected after configuring the decoding ranges. It currently has a Sound Blaster 16 PnP (CT2950) installed, and is fully operational once it has been initialized, preferably with UNISOUND. Of several boards I experimented, this is the only board that can use ISA PnP cards (whereas other boards can only use non-PnP ones). ISA PnP probably works with other ASRock boards as well.

The board's UEFI BIOS offers very few options regarding IRQ. To free IRQ7 for the CT2950 I had to primarily disable the onboard audio, which wants that IRQ most. Later on I discovered I have to additionally disable onboard Intel LAN as that will also take IRQ7 if the board's serial port (which is on 3F8h/IRQ4) is enabled. The board has an additional network adapter (Atheros Killer E2200) which happened to have wider OS support, such as usable Packet and NDIS2 drivers, and it does not take an additional IRQ. IRQ5, on the other hand, is hopeless to free as it's wanted by pretty much everyone as far as I've tested.

I checked the system's PIRQ registers (00:1f.0, registers 60h and 68h) and right now only 3, 5, 10, 11 are taken by first four PIRQs with current setup. The other 4 PIRQs are inactive, including one exclusively for the onboard audio, and one exclusively for the Intel LAN.

My boot process is like, booting to DOS, just set up the LPC-ISA bridge and initialize the card with UNISOUND, then run GRUB4DOS to launch the NTLDR meant for NT 3.51. This process works, and CT2950 will work with NT 3.51's default SNDBLST driver (which is non-PnP) if already configured via UNISOUND. However, on this board, NT 3.51 seems to suggest IRQ7 is also being taken by something, but it allowed me to use IRQ2, so I adjusted UNISOUND to configure the sound card as such. After installing the driver, reboot, and wait long enough, I get to hear "Tada" after logging in. The sound card is working great!

And here's the question... Could it be NT 3.51's MPS HAL (APIC) is somehow configuring the IRQs differently? AFAICT IRQ7 should have been available under this circumstance, as back then the card did work correctly (including in Creative's DIAGNOSE) when I configured it to use IRQ7 while in DOS, Win3.x and 9x (even WinXP). The OSes were previously installed on SATA disks back then, yet I was not able to get UniATA to work with NT 3.51, so I had no idea of how NT 3.51's HAL works on this system until now.

And back to the IRQ fallback timer question... I wonder if this is tweakable in case of IRQ-broken environments like this, to hopefully improve performance and reduce startup delay, while avoiding breakage if possible...

>And here's the question... Could it be NT 3.51's MPS HAL (APIC) is somehow configuring the IRQs differently?
Of course. It not could, it should. So try usual HAL ISA PIC first.

>The board's UEFI BIOS offers very few options regarding IRQ.
For ISA HAL & Windows 9x setting "PNP OS [Installed]" or somthing similar BIOS setup option to No is good idea.

>when I tested Win98SE installed on NVMe disk
I already answered this question in this topic. In any case nothing to talk about without bootlog.txt & ios.log (if it is created).

>I wonder if PCICFG is good enough for checking info about the system's IRQ info?
What is PCICFG? Ralph Brown DOS tool?

>And back to the IRQ fallback timer question... I wonder if this is tweakable in case of IRQ-broken environments like this, to hopefully improve performance and reduce startup delay, while avoiding breakage if possible...
It's possible, but working with device with IRQ through the polling is one of the dumbest engeenering idea. Timer is called "Fallback" rigtly, it's only workaround against lossing one IRQ request from millions, not every one.

red-ray wrote on 2025-11-16, 08:45:

Has anyone seen NVMe2K ATA SMART working on Windows 2003 please?

How many times can you write? >>> Re: NVMe2k - SCSIport miniport NVMe driver for NT4/2K/XP (9x version needs testing)

red-ray wrote on 2025-11-15, 14:23:

For stock NT 3.51 use the ASCII SIV32O.exe, if newshell2 is installed use the Unicode SIV32N.exe.

Just tested. SIV32O doesn't work. SIV32L works on NT 3.51.

UPDATE: It does work, but it complains about something being not MZ. SIV32L, on the other hand, starts without any error.

red-ray wrote on 2025-11-16, 08:45:

Has anyone seen NVMe2K ATA SMART working on Windows 2003 please?

For me it works on W2K + WXP, but on 2003 error 1 (invalid function) is reported when SIV does the DeviceIoControl( SMART_RCV_DRIVE_DATA ) with IDE_COMMAND_IDENTIFY.

On W2K NVMe SMART still fails, but least ATA SMART works.

With SIV 5.84 (SIV32L) on NT 3.51, SMART isn't working for nvme2k (1.0.0.2). Other than disk's model name and capacity, all I get is IO Status 1 (Incorrect function).

SweetLow wrote on 2025-11-16, 10:29:

>And here's the question... Could it be NT 3.51's MPS HAL (APIC) is somehow configuring the IRQs differently? Of course. It not […]
Show full quote

>And here's the question... Could it be NT 3.51's MPS HAL (APIC) is somehow configuring the IRQs differently?
Of course. It not could, it should. So try usual HAL ISA PIC first.

>The board's UEFI BIOS offers very few options regarding IRQ.
For ISA HAL & Windows 9x setting "PNP OS [Installed]" or somthing similar BIOS setup option to No is good idea.

The UEFI BIOS offers no such option regarding PnP OS Installed, nor IRQ/DMA "Available/Reserved".

In fact, even on boards that do have such options, I usually leave it Yes, and lately I haven't really encountered anything that required me to set it to No.

SweetLow wrote on 2025-11-16, 10:29:

>when I tested Win98SE installed on NVMe disk
I already answered this question in this topic. In any case nothing to talk about without bootlog.txt & ios.log (if it is created).

Just checked... I did ask it to log a BOOTLOG.TXT, but sadly it was empty, and neither BOOTLOG.PRV had anything in it.

Most likely the system hung at a very early phase. After reboot, I would be asked if I want to start in Safe Mode, but since Windows is just installed and haven't booted to complete the rest of the installation yet, it's pointless to do so.

Note that even with Windows installed on SATA disk back then, patches such as PATCHMEM must be applied, and cannot rely on things like LIMITMEM to limit available memory in order to avoid patching, as unpatched Windows would reboot right away when starting.

SweetLow wrote on 2025-11-16, 10:29:

>I wonder if PCICFG is good enough for checking info about the system's IRQ info?
What is PCICFG? Ralph Brown DOS tool?

Yes. That's what I've been using to print out info of all PCI/PCIe devices (be it onboard or discrete). I used this a few times mainly to check the IRQ usage, which helped me to figure out which onboard device to disable in order to make IRQ7 available for my CT2950 behind dISAppointment.

SweetLow wrote on 2025-11-16, 10:29:

>And back to the IRQ fallback timer question... I wonder if this is tweakable in case of IRQ-broken environments like this, to hopefully improve performance and reduce startup delay, while avoiding breakage if possible...
It's possible, but working with device with IRQ through the polling is one of the dumbest engeenering idea. Timer is called "Fallback" rigtly, it's only workaround against lossing one IRQ request from millions, not every one.

I understand this. There's something else that's bugging me, actually. Even in DOS, when I'm patching the newly installed Win98SE instance, disk operations take much longer to complete, comparable to the time it would take on an old mechanical HDD. I wonder if this "unworked IRQ" has anything to do with my board's UEFI CSM?

On the other hand, disk operations on SATA drives, be it IDE or AHCI mode, are blazing fast, that many disk operations which usually takes a while, are done almost immediately.

>I did ask it to log a BOOTLOG.TXT, but sadly it was empty
1. The first lines in boot log is responsibility of real mode IO.SYS, no Windows at all.
2. Could you boot to the Safe Mode Command Prompt?

SweetLow wrote on 2025-11-16, 11:40:

2. Could you boot to the Safe Mode Command Prompt?

I can enter command prompt, or Safe Mode command prompt (without processing any config).

Though I doubt the hang has anything to do with the NVME9x driver... as it happens before these drivers would get involved.

>the hang has anything to do with the NVME9x driver
Of course, nothing related to driver. But I am trying to insulate you real problem with BIOS Int 13 handler for NVMe drives. Trust me, I am "happy " to collect literally all of them on my systems. But OTOH some of them can be corrected after the root of problem is known.
Ok, boot to command prompt and try to copy large file (few hundred kilobytes) from one place (directory) on NVMe drive to other place on the same drive.

LSS10999 wrote on 2025-11-16, 11:18:

red-ray wrote on 2025-11-15, 14:23:

For stock NT 3.51 use the ASCII SIV32O.exe, if newshell2 is installed use the Unicode SIV32N.exe.

Just tested. SIV32O doesn't work. SIV32L works on NT 3.51.

Thank you for checking things out, what happens with SIV32O.exe? Does crash? Please do SIV32O -DBGINI -DBGSDM > SIV32O_DBGOUT.log from a command window.

LSS10999 wrote on 2025-11-16, 11:18:

red-ray wrote on 2025-11-16, 08:45:

Has anyone seen NVMe2K ATA SMART working on Windows 2003 please?

For me it works on W2K + WXP, but on 2003 error 1 (invalid function) is reported when SIV does the DeviceIoControl( SMART_RCV_DRIVE_DATA ) with IDE_COMMAND_IDENTIFY.

On W2K NVMe SMART still fails, but least ATA SMART works.

With SIV 5.84 (SIV32L) on NT 3.51, SMART isn't working for nvme2k (1.0.0.2). Other than disk's model name and capacity, all I get is IO Status 1 (Incorrect function).

This sounds like what I see on 2003, but I need to see the file generated by doing SIV32L -DBGSDM > SIV32L_DBGOUT.log from a command window to be sure, this should trace what is happening in enough detail so I stand a chance of figuring things out.

I am waiting for a PCI to PCIe adapter so I can't easily try it here, maybe I will install NT 3.51 on a system with PCIe slots.

SweetLow wrote on 2025-11-16, 12:11:

>the hang has anything to do with the NVME9x driver
Of course, nothing related to driver. But I am trying to insulate you real problem with BIOS Int 13 handler for NVMe drives. Trust me, I am "happy " to collect literally all of them on my systems. But OTOH some of them can be corrected after the root of problem is known.
Ok, boot to command prompt and try to copy large file (few hundred kilobytes) from one place (directory) on NVMe drive to other place on the same drive.

Did some tests on my first NVMe disk:
- First copied a single 1MB file. Finished very quickly.
- Copied files from C:\WINDOWS\SYSTEM to another place (not recursive). It's about ~840 files and most files are below 1MB. The first ~100 files copied very fast, but it gradually slows down, and the slowdown has little to do with file size in this case.
- After that, I tried copying a large enough file. The only file I can find right now is a swap file about 512MB. Copying it took about 20-22 seconds.
- Listing files (DIR) doesn't seem to have any issue at the moment.

I also conducted a few tests on other NVMe disks and noticed for some reasons, when I first make a test directory using MD command, it waited about 5 seconds. Subsequent operations finished without delay. Perhaps the disks were "asleep", that they need time to "wake up".

Test files were deleted afterwards. Deleting a single file is fine, but deleting a lot of files takes much longer, possibly the same slowdown when copying a lot of files.

I guess some power management stuffs are involved, causing disk performance to fluctuate. Still, the performance of the UEFI CSM's handler for NVMe drives is indeed not as optimal compared to SATA (IDE or AHCI), be it when copying a single large file or multiple small files.

Ok, the last test - boot with EMM386.EXE (NOEMS NOVCPI parameters enough, and HIMEM.SYS /NUMHANDLES=64 (or 80) if you have much RAM, of course )

SweetLow wrote on 2025-11-16, 12:57:

Ok, the last test - boot with EMM386.EXE (NOEMS NOVCPI parameters enough, and HIMEM.SYS /NUMHANDLES=64 (or 80) if you have much RAM, of course )

Bad news... the partition has been fscked up after this.

I made a CONFIG.SYS as instructed, setting HIMEM.SYS with /NUMHANDLES=64 and EMM386.EXE (NOEMS NOVCPI). Then I rebooted.

On next boot the Windows logo froze (animations stopped) immediately after showing. Thought the system must have hung, I reset the system. After that it reported that Windows files (HIMEM.SYS, EMM386.EXE, etc.) as well as command interpreter went missing.

Note that I've set it not to directly boot into GUI (set BootGUI in MSDOS.SYS to 0), so it should drop to command prompt unless I manually enter WIN, as I was also testing NT 3.51 during the meantime. As such, the culprit is likely EMM386. AFAIK MS EMM386 has always been problematic on modern hardware compared to JEMM, so I rarely use it nowadays. After all, Windows doesn't load EMM386 by default, only HIMEM.

I booted a Linux image to check what exactly happened, and found the partition's label is gone (!). Ran fsck and it reported invalid label (offering me the option to reassign it), a large number of bad entries, as well as starting cluster (4294967295 that would be 0xFFFFFFFF) beyond limit, and I said yes to correct them. While I can access the partition again after fsck, all installed Windows 98SE files were indeed gone, but somehow the NT 3.51 files I copied later were still there.

Will have to clean up the mess and try reinstalling Win98SE if I ever want to continue testing... Nothing was lost anyway, as I've already backed the stuffs up, including the most recent state of NT 3.51 system files.

http://sweetlow.orgfree.com/download/nvme9x.zip
- algorithm of guard timer was changed to not slowdown requests queueing
As I fixed all problems I found (which I had enough possibility to fix, of course) and did do all additions I want - it is prerelease version.

>As such, the culprit is likely EMM386
No, culprit is the same as described in my previous post - Int 13h BIOS handler does not support protected mode at all. But intead of refusing to work as in the mild level of problem it is trying to work even if it can not work really - the hard level. Probably it is completely ignoring both Virtual 8086 Mode and VDS.

SweetLow wrote on 2025-11-16, 18:22:

>As such, the culprit is likely EMM386
No, culprit is the same as described in my previous post - Int 13h BIOS handler does not support protected mode at all. But intead of refusing to work as in the mild level of problem it is trying to work even if it can not work really - the hard level. Probably it is completely ignoring both Virtual 8086 Mode and VDS.

Consider the partition's bootsector is still intact (I suppose) I may consider testing a bit further, notably:
- Will JEMM (preferably JEMMEX) still work?
- Will protected mode software (e.g. DOS4GW powered) still work (with and without JEMM)?

These are what matters more at the moment. On the other hand, on some other systems, I do notice some DOS4GW programs randomly crash with errors if JEMM was loaded, but perfectly fine if only XMS driver (e.g. XMGR) is used.

SweetLow wrote on 2025-11-16, 18:22:

http://sweetlow.orgfree.com/download/nvme9x.zip
- algorithm of guard timer was changed to not slowdown requests queueing
As I fixed all problems I found (which I had enough possibility to fix, of course) and did do all additions I want - it is prerelease version.

I'm not sure if this is specific to NVME9X, or it can also help with NVME2K (WinNT) so boot time may be shortened a bit perhaps?

Amazing work, people!

I have another question (and possible feature request) w.r.t. both NVMe2K and NVMe9x.

Revision 1.3 of the NVMe spec includes some (optional) improvements that makes NVMe more virtualization-friendly:

• NVMe revision 1.3 section 8.5 and section 5.26 (Virtualization Management command)
• NVMe revision 1.3 section 7.13 and section 5.7 (Doorbell Buffer Config command)

From what I could find out on-line from some benchmarks, videos and technical blogs, these enhancements (and the Doorbell Buffer feature in particular) make NVMe device emulation competititive (or even better) in terms of performance and overhead compared to paravirtualized disk device standards such as virtio-blk and virtio-scsi.

So long story short, if these virtualization- and emulation-specific features of NVMe revision 1.3 are supported by the NVMe2K and NVMe9x drivers, then they would make these older Windows versions perform better in VMs as well as on physical machines.

For VMs to take advantage of this, this would of course require the VM host to support this functionality as well, but at least with recent versions of QEMU this should be the case.

Do these drivers support these optional features yet? And if not, would you maybe consider adding support for these features to NVMe2K and NVMe9x?

Let me know if you would like me to formally open a feature request issue for this on GitHub.

Thanks for considering! 😇