The number of permutations that makes sense is just 4 (NVIDIA in #1, Audigy is #2 to #5), because even if things worked with NVIDIA in a slot different than #1, it is not useful because it only works in 640x480 16 color mode. Sure, I'll reset the BIOS and post /proc/interrupts with Audigy in #2-#5.

I assume with "remove Audigy2 drivers from Linux", you mean blacklist the *_emu10k1 modules, why is this useful?

Didn't do too extensive testing, but the USB worked OK without Audigy plugged in. If the NEC PCI-USB card works (which should arrive in a couple of days), I'd say lack of the on-board USB is a non-issue anyway.
PCI-SATA card, on the other hand,...well 20MB/s writes and 30MB/s reads aren't bad at all for an old W98SE machine, but could've been much (4x-5x) better with a PCI card.

hydraphone wrote on 2025-12-06, 15:03:

The number of permutations that makes sense is just 4 (NVIDIA in #1, Audigy is #2 to #5), because even if things worked with NVIDIA in a slot different than #1, it is not useful because it only works in 640x480 16 color mode. Sure, I'll reset the BIOS and post /proc/interrupts with Audigy in #2-#5.

Didn't do too extensive testing, but the USB worked OK without Audigy plugged in. If the NEC PCI-USB card works (which should arrive in a couple of days), I'd say the USB is a non-issue anyway.
PCI-SATA card, on the other hand,...well 20MB/s writes and 30MB/s reads aren't bad at all for an old W98SE machine, but could've been much (4x-5x) better with a PCI card.

Yes but no - because you are not only moving around the controllers that are attached to PCI slots.

The right slot for Audigy is going to be #2 or #3 or #4 to #5 (normally #3 is the most isolated) but there is another level of complexity.

The actual permutations is higher than 4 PCI slots because those PCI slots do not exist in isolation. The IRQs assigned to those PCI slots are not exclusively assigned to those PCI slots.

You have seen PCI slot #2 sometimes assigned IRQ 10, sometimes IRQ11, and maybe it will sometimes be assigned something else. There are multiple permutations with Audigy staying in PCI slot #2!

Why the IRQ assigned to PCI#2 not static? Because the BIOS has a table of IRQs and it assigns those IRQs to each component that ask for an IRQ (Serial ports, Parallel port, USB 1.1, Legacy USB, IDE ports, FDD ports, PCI slots/ports, etc.)

That dynamic allocation matters a lot because it means the controllers on the PCI bus are "competing" with lots of other controllers on lots of other busses. There is a pool of ~16 IRQs, but more than 16 controllers seeking an IRQ!

Unfortunately, we cannot see the hardcoded logic that the BIOS is using to allocate those IRQs - all we know is that when we switch something off in the BIOS, the IRQs assigned to PCI slots can change. That is why changing a BIOS setting and the PCI slot at the same can create the illusion of random permutations.

The total number of permutations available to you is greater than 4, and you have seen this with USB: IRQ11 assigned to Audigy and IRQ11 assigned USB is different to IRQ11 assigned to Audigy and IRQ3 assigned to USB.

And, two users with identical sets hardware might each discover they disagree on which PCI slot works best for an Audigy card - because those users had different BIOS settings, hence different IRQ assignments!

That is before we get to the OS adding more IRQ assignments for virtual devices - extra complexity that can make your debugging even harder, which is why I suggested debugging in Linux with minimal drivers.

You're conflating IRQ and PCI slot configuration. IRQ assignment by the OS is a separate, software thing. For the physical PCI slot assignments there are only 4 configurations that make sense.

Going back to IRQs, for a fixed OS & BIOS settings (and fixed PCI slot configuration), I don't remember seeing any boot-to-boot randomness in IRQ so far with this motherboard.
As for BIOS settings for a given PCI slot assignment, all on-board ports/devices that can be disabled from the BIOS have always been disabled, so they also don't factor in. Tthe only relevant levers in the BIOS that I have are "Assign IRQ For USB", "IRQ-X assigned to" from "PCI/ISA PnP" to "Legacy ISA", and "Modem use IRQ", which I will check. As a reminder, Linux and Windows 98 react differently to those settings.

You haven't answered my question from the last time: what is the point of blocking audigy-related modules and collecting /proc/interrupts for different Audigy PCI assignments? If the module is not loaded, an IRQ won't be assigned to Audigy either and /proc/interrputs will be the same regardless of where I put the Audigy card (for a given software/BIOS configuration). A device whose module is blacklisted doesn't "compete" for an IRQ assignment, and the IRQ assignments will be identical to the hardware configuration with Audigy card not inserted at all.
If you are curious about how each relevant BIOS setting influence the IRQ assignments of other devices in Linux, there is no point of juggling the Audigy card between PCI slots for that.

Linux IRQ assigments for USB, with Audigy modules blacklisted.

All "IRQ-X assigned to" set to "PCI/ISA PnP" in the BIOS, and two settings are varied: "Assign IRQ For USB" and "Modem use IRQ" (there is no modem present at all, by the way). Their factory-default values are "Enabled" and "3", respectively.
(Audigy in Slot #5, but as expected, removing it doesn't change any of the results below)

• Assign IRQ For USB: Disabled
  Modem use IRQ: 3
  Assigned USB IRQ (Linux): 3
• Assign IRQ For USB: Enabled
  Modem use IRQ: 3
  Assigned USB IRQ (Linux): 11
• Assign IRQ For USB: Disabled
  Modem use IRQ: NA
  Assigned USB IRQ (Linux): 3
• Assign IRQ For USB: Enabled
  Modem use IRQ: NA
  Assigned USB IRQ (Linux): 3

The remaining IRQ assignments (for timer, i8042, cascase, rtc0, ata_piix) are static, and the same as given in old one.

NVIDIA in PCI slot #1, Audigy rotated (software settings fixed)

Settings (unless stated otherwise):
BIOS settings: "Assign IRQ For USB": "Disabled". "Modem use IRQ": "NA". All "IRQ-X assigned to" set to "PCI/ISA PnP"
USB and FireWire are disabled from Windows 98 device manager.

• #2 Audigy is recognized, devices (with the exception of 1394) are added to the device manager. Music playback appears to be working, all volumes are up, but there is no sound coming from any of the physical output ports. Audigy #11, NVIDIA #03.
• #3 NVIDIA #10, Audigy #11. Same as before with #3. Sound working, no lock ups for 3 minutes of music play. Enabled USB from device manager, reboot. USB got #11. Random replaying of previous played sounds, sudden random noises, crackling is back. Changed "Assign IRQ For USB" to "Enable", everything remains identical. Changed "IRQ-11 assigned to" set to "Legacy ISA", reboot. NVIDIA #3, Audigy #10, USB #10, same sound issues persist. "Assign IRQ For USB" back to "Disable", nothing changes. Changed "IRQ-10 assigned to" set to "Legacy ISA" as well, reboot. NVIDIA #4, Audigy #3, USB #3, same sounds issues persist.
• #4 NVIDIA #11, Audigy #11, USB #5. Slightly different from before with the same hardware configuration and slightly different BIOS configuration. Sounds works OK when USB is disabled from the device manager. Enabled USB, Windows freezes after several minutes of music play.
• #5 Windows starts, after cancelling New Hardware Found dialog for 1394 (it was disabled in a different hardware configuration, but New Hardware Found gets triggered when moved to a different PCI slot), Windows reboots instantly (before I get a chance to check the IRQ assignments, or to disable 1394 completely)

These are identical to the results I posted before for each PCI slot configuration, but they are from new tests and collected in a single post.

So unless some has some sharp insight, I consider all PCI slot options for Audigy have been explored with the current hardware. Replacing the PCI NVIDIA with an AGP might open up a configuration in which Audigy doesn't share IRQ with any other hardware.

hydraphone wrote on 2025-12-06, 18:33:

You're conflating IRQ and PCI slot configuration. IRQ assignment by the OS is a separate, software thing. For the physical PCI slot assignments there are only 4 configurations that make sense.

I have not conflated them.

Generation 1: IRQs set by jumpers on PCBs.
Generation 2: IRQs set in Firmware.
Generation 3: IRQS set in Software/OS.

Your 440LX/Win98 system is ~Generation 2.5 and that is why I raised the matter of drivers and virtual devices trigger extra IRQ assignments that contribute to the challenges of debugging in Windows. You raise an important point, you want Linux to align to Gen2 and not Gen3.

Firmware is also software.

Where does it say I'm at Gen 2.5?

hydraphone wrote on 2025-12-06, 21:10:

Firmware is also software.

Sure, but it's embedded and makes its IRQ assignments before the OS loads. The decision you saw to assign IRQ3 or IRQ11 to USB was made by the BIOS firmware, and its meaningful because IRQ11 is also assigned to a PCI slot.

Which firmware are you referring to specifically, and where does it say I'm at "Gen 2.5"?

hydraphone wrote on 2025-12-06, 21:13:

Which firmware are you referring to specifically, and where does it say I'm at "Gen 2.5"?

I am referring to the firmware that controls your mainboard and that you manage through your BIOS settings.

I made up the Generations 1/2/3 because AFIAK nobody has coined a term that helpfully describes the evolution of IRQ assignments in PCs.

Your 440LX + Windows 98 system splits the logic for assigning IRQs between the BIOS and Win98. In my Generation 1/2/3 nomenclature that would be >2 and <3.

On your 440LX + Windows 98 system the BIOS assigns IRQs first, and the OS can override those assignments. However, Win98SE does not override much - it mostly appends. Linux I'm not sure about, but I'm sure Linux can be configured at startup to behave like Windows98SE.

And the only control I have over that "firmware" is through BIOS config (this is a "jumperless design" motherboard, in the word of the motherboard manual, there are jumpers but not for anything related to what I'm doing), which I put in the software configuration, because it is software.
For my test methodology, I separate the BIOS+OS config and the hardware PCI configuration. That's the methodological thing to do. There are 4 viable PCI configurations for it, and BIOS+OS has a multitude of knobs. I vary them separately. That's it. No need to conflate them or introduce further pointless definitions.

NEC PCI-USB card arrived. With Audigy removed, and only NVIDIA present in slot #1. NEC didn't work in any configuration.
PCI slots #2, #3: Windows boots, New Hardware Detected, next next next, freeze.
PCI slot #4: doesn't post.
PCI slot #5: same as #2 and #3 except instead of a freeze, hard-reset.

hydraphone wrote on 2025-12-06, 21:27:

And the only control I have over that "firmware" is through BIOS config (this is a "jumperless design" motherboard, in the word […]
Show full quote

And the only control I have over that "firmware" is through BIOS config (this is a "jumperless design" motherboard, in the word of the motherboard manual, there are jumpers but not for anything related to what I'm doing), which I put in the software configuration, because it is software.
For my test methodology, I separate the BIOS+OS config and the hardware PCI configuration. That's the methodological thing to do. There are 4 viable PCI configurations for it, and BIOS+OS has a multitude of knobs. I vary them separately. That's it. No need to conflate them or introduce further pointless definitions.

NEC PCI-USB card arrived. With Audigy removed, and only NVIDIA present in slot #1. NEC didn't work in any configuration.
PCI slots #2, #3: Windows boots, New Hardware Detected, next next next, freeze.
PCI slot #4: doesn't post.
PCI slot #5: same as #2 and #3 except instead of a freeze, hard-reset.

Maybe double check the PCI versions of 440LX chipset and NEC USB controller. Probably both PCI 2.1 but better to know than not.

Yes, your BIOS is jumperless - I outlined the evolution to highlight that constraints in IRQ assignments are determined by the actual copper in the motherboard, because - even though we cannot see the switches - your firmware is working within the same old constraints. I not once told you to look for jumpers 😉

Anyway, I don't have more to share. I am just going over the same ideas with different language.

Sure, thanks nonetheless.

440LX is PCI 2.1, NEC's 720101 is 2.2, but according to NeoG_ it is backward compatible with PCI 2.1 and should work on 440LX (which I why I ordered a NEC).

I'm convinced that this motherboard is a waste of time, I'll get a different one.

Take 440BX if you can, i have 440EX mATX and i am happy with it (CT-6ESA2 with 0827 rom.by patched bios).
Celeron 533MHz is fastest for those 440LX/440EX chipsets at most cases and its enough for me at old ATi VGA.

I looked for a 440BX with 370 socket (no adapter) but couldn't find one for a reasonable price (especially after wasting a lot more than necessary money, with shipping + obscene ~140% import duties from EU, on this Lucky Star; I did try to appeal to UPS BTW following what happened in this similar case but no response from UPS so far).
I'm considering ECS P6VAP-A+ with VIA chipset VT82C596B. I don't think I ever had one with a VIA chipset though, are those recommended?

hydraphone wrote on 2025-12-06, 22:41:

I looked for a 440BX with 370 socket (no adapter) but couldn't find one for a reasonable price (especially after wasting a lot more than necessary money, with shipping + obscene 150% import duties, on this Lucky Star).
I'm considering ECS P6VAP-A+ with VIA chipset VT82C596B. I don't think I ever had one with a VIA chipset though, are those recommended?

ECS and old VIA is not good combo. Take at least 686B, its has udma100, but its still USB 1.1, not USB 2.0 what you want. 😀
Take newer chipset if you can and if you want USB 2.0,why dont you buy one of those,that already has USB 2.0 integrated?
Socket 370 and USB 2.0 combo is rare, if you take just faster PIII Tualatin, then USB 2.0 add in does not take all CPU power.

I already have 2 Socket 370 CPUs and 512 SDRAM lying around, that's the main reason. Tualatin 1000MHz doesn't draw too much power (~30W), so probably fan won't be noisy, so it also sounds reasonable. Any chipset suggestions for it?

For USB 2.0 (which would be useful for USBODE-CIRCLE), I already bought 2 PCI cards (VIA and NEC), and 2 SATA PCI cards (no-brand and Rosewill, latter with PCI BIOS), so a USB 1.1-only or UDMA66 motherboard wouldn't be a deal breaker.
I haven't confirmed whether it will use CPU power or not with the cards that I have, but if it indeed bogs the system down, I can make do with Daemon Tools.

Thanks for the suggestions, 686B (or better) sounds good, if I find one, I'll get that instead.

First, dont buy Tualatin CPU, just take board that support it, theres always time to upgrade later if mb supports it and if you reallly need it. Intel i815 will do fine, just some i815 go up to Coppermine and some take Tualatins as well. I have used VIA, but if you skip Socket370, then i can recommend 865. With VIA it can be about boards bios and motherboard quality questions more. Take well known brand, Intel original, Epox, Abit, Asus, then there should be less trouble i think, Chaintech board are not the best, but i have one or two and it works well for me. There are many options, Gigabyte, MSI also good. More matters chipset and bios and the motherboard condition. With some older boards i have to use weaker cpu or change capasitors to get them going better and one of my boards integrated sound does not work, issues can be different, just buy motherboard that posts and works.

Good luck with your next motherboard!

marxveix, thanks a bunch!
For nostalgia reasons, my priority is socket 370 motherboard with AWARD BIOS that accepts Mendocino Celerons.
If I can't find one online for a reasonable price, I probably will buy the ECS P6VAP-A+ with VT82C596B.

hydraphone wrote on 2025-12-07, 02:53:

For nostalgia reasons, my priority is socket 370 motherboard with AWARD BIOS that accepts Mendocino Celerons.

Celeron 300A i had good memories at 450Mhz, My buget 440EX and Mendocino 533MHz OC is at 8x75=600Mhz

maxtherabbit wrote on 2025-11-29, 20:45:

The issue with the USB 2.0 cards isn't that they occupy the CPU when you're actively doing file transfers, it's that they do it when you're not. There have been many threads here on it over the years.

I got the VIA card (VT6212L) working on a ASUS CUV-NT Rev. 1.04 motherboard with Pentium III Coppermine CPU. I don't see any CPU usage in the System Monitor without any USB devices connected, with a USB mouse or a RPi0 with USBODE-CIRCLE connected to it. I also don't see any meaningful change in wall power draw of the computer at idle (in case this is something that wouldn't show up in the System Monitor).

Update: Did benchmarks with 3DMark2001 SE: 3801 with the card, 3772 without the card plugged in, seems equal within normal "noise".