Look for different versions of the packet driver ...

I just installed a 3C905C in a machine to try to debug a problem that NetDrive is having with it. The 3C905 series is very common and the 3C905C generally works well with the original mTCP programs. I'd tell you where to get the packet driver, but I'm traveling at the moment.

The NetDrive problem with it looks to be specific to the 3C905 series packet drivers; they are not re-entrant. It's a problem specifically for them because they hook the timer interrupt which NetDrive also needs to use. I can't imagine what they need to do 18.2 times per second, but if they were going to hook the timer interrupt they should have also been aware that other things need it too, and thus it should have been re-entrant or done a minimal amount of work. I have a work-around but I'm still trying to piece together what they are doing.

dionb wrote on 2024-05-02, 22:01:

Specs: P3-650 Tekram PB640-A4X (i440BX) S3 Virge GX2 AGP Orchid Voodoo 1 Aztech AZT2320 SBRpro2+MPU401 AWE64 Gold GUS 64MB RAM 1 […]
Show full quote

Specs:
P3-650
Tekram PB640-A4X (i440BX)
S3 Virge GX2 AGP
Orchid Voodoo 1
Aztech AZT2320 SBRpro2+MPU401
AWE64 Gold
GUS
64MB RAM
16GB DiskOnModule
ATAPI DVD ROM
ATAPI ZIP

OS:
DOS 7.1

And I'm trying to get network connectivity working. I need to use a PCI NIC as all ISA slots are in use for sound cards.

NICS:
Intel EtherExpress Pro 100B with Crynwr packet driver (E100BPKT.COM)
3Com 3C905C-TX with 3Com official DOS driver (3C90XPD.COM)

With either NIC the packet driver recognizes the NIC and loads successfully, defaulting to software driver 0x60. Then the trouble starts when I try to run DHCP.EXE (from mTCP) to get an IP. WIth the E100, DHCP runs fine, but times out with no response. In my switch I can see the packets going out and the response from the router coming back - and being retransmitted when no confirmation is received. Setting a manual fixed IP doesn't help - other applications (like PING.EXE) also don't get a response. With the 3Com NIC, the system hangs when trying to communicate.

Now, DHCP.EXE helpfully suggests to check the hardware IRQ as particularly the Crynwr drivers are known to . Neither driver has an option to set the IRQ in the driver. As PCI cards, these get their IRQ via PnP. If I don't configure anything specifc (other than reserving IRQs 3, 5, 7 and 9 for the ISA cards), the NICs get IRQ 11. However I can force it to IRQ10 by reserving 11 too. That does not change behaviour.

Changing cables did not help, and the NICs are known good, in fact they work in this same system if I boot with a Knoppix (Linux) LIveCD.

I have cleared out CONFIG.SYS and AUTOEXEC.BAT, not loading any memory managers, but to no avail. Given the issue occurs with two different NICs with very different packet drivers, that work perfectly under other conditions or indeed OS on the same PC, I'm suspecting the NICs themselves aren't the problem. But what is?

So, anyone have any suggestions how to get this working?

Have you tested this PC on Windows ( possibly 95)? I got similar but different problem and in mine issue problem persist on Windows

Im unable to add network Card to 486 Siemens Nixdorf Scenic 4L

kepak wrote on 2024-05-05, 06:30:

[...]

Have you tested this PC on Windows ( possibly 95)? I got similar but different problem and in mine issue problem persist on Windows

Im unable to add network Card to 486 Siemens Nixdorf Scenic 4L

No, no Windows on the system (I intend to install Windows for Workgroups 3.11 at some point, but the installer is on the other end of an FTP connection). Currently sourced a third card (another e100) but as expected no difference. Not been able to find different driver versions yet - although offline life has been busy so not been able to do very much at all really - I should have some time today for that and for trying different PCI slots, just in case.

dionb wrote on 2024-05-02, 22:01:

With the 3Com NIC, the system hangs when trying to communicate.

Try a different packet driver. 3Com software for DOS has issues, their various versions of that driver can work only with certain cards but not others and problems like hangs or packets not being received or transmitted (or just the first one) is what you get. I had an issue with packet drivers that worked with 900B but not 900, and I can imagine your 905C might not work with the driver that I'm using for 905B.

For 900 series I use two drivers, one from Ehter CD 5.1 and the other from 5.4 - usually one works well. That being said I do not have any 905C so you might have to look for even newer stuff than this, but again keep in mind that newer doesn't mean it'll work properly with older cards so keep previous, tested versions as well.

Isn't the IRQ used by the NIC shared with some other device?
It would be logical to cause problems in DOS, but not in Windows: Windows drivers may properly support IRQ sharing, but DOS drivers - not necessarily.

Well, it seems I'm underestimating DOS...
Just did this experiment: set some IRQs to "Legacy ISA", to force three PCI devices to share one IRQ:
- LAN - CNET Pro200, based on some Davicom chip
- sound - SB PCI 128
- USB

And it still works fine, both the packet driver with mTCP, and the NDIS2 driver with Microsoft Network Client.
I can even use LAN and sound at the same time - Mpxplay has no problems playing sound files from a network drive.

Also don't suspect IRQ sharing or even the number as such - using similar means I force the card to a different IRQ (10 vs 11) and no change.

Btw, while digging for more versions I found this:
3Com Etherdisk 5.1 to Vogons drivers library?

The 3C90XPD.COM packet driver from that package loaded fine, but when trying to run any of the MTPC applications, the system just froze. Recovery possible only via hard reset.

[...]

I mounted the BIN/CUE image, extracted 3C90XPD.COM from there, and that's that: with the older version, MTCP now works perfectly.

As soon as I get out of the interminable meeting I'm in now, that's what I'm trying.

Update:
Lots of frustrating stuff, but eventually managed to fix it.

Etherdisk 5.1 version of 3C90XPD.COM didn't help.
Tried two other PCI slots. Did change IRQ situation, but still 3C90XPD.COM hangs.
Disabled COM1 (IRQ4) and IDE2 (IRQ15). Did change IRQ situation, but still hangs.
Replaced Aztech AZT2320 PnP card with onboard modem with AZT2316A non-PnP card. Saves two IRQs, but still hangs.
Tried the other PCI slots again. Nope.
Disabled L1 and L2 cache to rule out speed issues. Nope.

Then tried the Intel card again with the situation above. And now it works!

One by one reverted the changes to see what made the difference:
- Re-enabled L1 and L2 cache. Still works.
- enabled COM1 and IDE2 again. Still works.
- put the other sound card back: Doesn't work.
- replaced non-PnP sound card, tried original PCI slot again: also doesn't work.

So it looks like the saving of PnP IRQs by swapping to non-PnP sound card without onboard modem combined with a different PCI slot (PCI2) is what made the Intel card with E100BPKT.COM 0x60 work. No idea what's up with the 3Com card drivers, but card is good as it works under Linux. But I'm not wasting any more time on it - everything in this system works as desired, so I'm happy now.

Great ! Glad you got something working. Wonder if that PnP audio card uses some odd resource that the Intel nic did not like. Not sure why a diff PCI slot would matter but odd things can happen 😀

Horun wrote on 2024-05-10, 01:02:

Great ! Glad you got something working. Wonder if that PnP audio card uses some odd resource that the Intel nic did not like. Not sure why a diff PCI slot would matter but odd things can happen 😀

The AZT2320 card was being assigned two IRQs (one for sound, one for the Rockwell modem chip) by PnP BIOS, then UNISOUND moved the sound to values I had reserved in BIOS and configured in AUTOEXEC.BAT - so effectively this card was rendering three IRQs unusable for PCI PnP at boot when I only needed one for it to work. The two extra IRQs this swap freed up avoided unnecessary sharing. Added bonus is that the card has an ICS wavetable on a daughterboard which is not on by default- letting me choose whether to use it or external modules connected to the cards DA15 output.

With the slots it was the PCI interrupt lines that were different. Apparently where the driver didn't mind sharing an actual IRQ (it ended up on 11 together with the serial controller) it did balk at sharing an interrupt line.