VOGONS


mTCP NetDrive: network attached storage for DOS 2.0 or better

Topic actions

Reply 420 of 421, by mbbrutman

User metadata
Rank Oldbie
Rank
Oldbie

@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.

Last edited by mbbrutman on 2026-09-12, 02:59. Edited 2 times in total.

Reply 421 of 421, by mbbrutman

User metadata
Rank Oldbie
Rank
Oldbie

@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.