@Grzyb:

So to summarize, you have two machines that are fine with the 2025-01-10 code but fail when doing writes on this code. Can you send me the TCPDump with the packet data inside of it? I see the three reads and a write there but I'd like to see the hex of the commands to see if something unusual happened.

Also, can you try limiting the maximum write size to 1KB? That effectively turns off the large write feature and makes it look like the old code.

Edit: Ignore everything .. it's broken for me too, and I have no idea how I could have broken it this badly. Small updates and files work, but above a certain size writes do not work.

@Ringding

I love virtual machines ... they make this so easy to debug.

When the machine freezes it is actually in a spin loop waiting for a write command to complete. I see the exact instructions that it is sitting on and they line up with the code. Interrupts are disabled, which is a bad thing. The packet driver can't deliver a packet to NetDrive when interrupts are disabled and the timeout mechanism doesn't work because it is based on timer ticks, which also don't work with interrupts disabled.

I added some debug code to record the state of the flags on entry to my code and interrupts were disabled before my code started running. That is a bug in whatever disabled interrupts and then called DOS to do something. I'm going to bet that this code doesn't work on any network type of drive if it is doing this. It is not safe to call DOS with interrupts disabled. I added another instruction to re-enable interrupts in the device driver, and everything was fine. That's fine for debug purposes, but I'm not going to ship code like that because I don't know what disabled the interrupts and what it was trying to protect. So blindly re-enabling interrupts is not safe either.

I'd say use SmartDrv, but don't enable the write caching feature - it is either broken, or there is a bad interaction between it and the Borland IDE. The Borland IDE is running under DPMI so who knows where the interaction is.

@Grzyb

I think I know what is going on. The code is sending packets to the packet driver faster than the card can put them on the wire. This is resulting in truncated packets and errors sending packets. If you do "nd s d:" (or whatever your drive is) you will probably see a counter for "Packet send errors" that is above zero.

Try use the nd command to limit the size of writes to 8KB or even 4KB and the problem should go away, at the expense of reduced performance.

Why didn't I see this? Because I test either on a virtual machine or on a slow machine. I actually did see this happen on a P133 back a few months ago but I didn't figure out what was going on - now it makes sense. The P133 did have the problem, and limiting the write size fixed it.