---------- Původní e-mail ----------
Od: Ladislav Lacina <la...@seznam.cz>
Komu: Bret Johnson <bretj...@juno.com>
Datum: 27. 2. 2025 1:06:04
Předmět: Re: [Freedos-devel] Problem with writes to NVMe disk
"Yes, I think that best approach is to write TSR which hooks INT 13h and
splits large writes into smaller chunks.
I only do not understand why there is no problem with reading but only with
writting.
By the way, I looked into FreeDOS sources because I wanted to know whether
is between INT 21h/40h and INT 13h a medium level INT 26h.
It seems that not.
Anyway, I am not sure whether I understand the source correctly but it seems
to me that code for INT 13h handling (at least for LBA access) is in file
FLOPPY.ASM (???) and one thing in the code seems to be a little bit
problematic.
The function does not check the CF flag after INT 13h.
Yes, I know that in case of success should be the AH zero but maybe in poor
written BIOSes it it not true and in case when CF is zero could be AH
undefined...
In such situation would be physicaly written the disk sector(s) but DOS
would think that it was unsuccessful.
===========================================================
FL_LBA_READWRITE:
push bp ; setup stack frame
mov bp,sp
push ds
push si ; wasn't in kernel < KE2024Bo6!!
mov dl,[bp+10] ; drive (if or'ed with 80h a hard drive)
mov ax,[bp+8] ; get the command
lds si,[bp+4] ; get far dap pointer
int 13h ; read from/write to drive
pop si
pop ds
pop bp
mov al,ah ; place any error code into al
mov ah,0 ; zero out ah
ret 8
=========================================================
---------- Původní e-mail ----------
Od: Bret Johnson <bretj...@juno.com>
Komu: la...@seznam.cz
Datum: 26. 2. 2025 21:19:33
Předmět: Re: [Freedos-devel] Problem with writes to NVMe disk
"Well, it seems pretty obvious from the symptoms that it is a CSM ("virtual
BIOS") problem and has nothing to do with DOS. I don't know if you can send
in a trouble ticket to the CSM vendor, and even if you do that they would
try and resolve it for you. I'm actually pretty surprised that a fairly
modern laptop even has CSM. My HP laptop is several years old now doesn't
have CSM. When I want to use DOS on the laptop I must use some kind of
virtualization.
Anyway, my _guess_ is that the CSM is using some kind of double-buffering
process. That is, instead of telling the PCIe bus to read the data directly
from the DOS memory and transfer it to the disk, it is is setting up an 8k
buffer, transferring the data from DOS memory to the buffer, and then
telling PCIe to transfer the data from the 8k buffer to the disk.
PCI (and PCIe) use Bus Mastering to transfer data in and out of memory which
requires a _physical_ memory address. Trying to obtain a physical memory
address from DOS is not always straightforward, especially with things like
UMBs and EMS and XMS and protected mode, so maybe the CSM is "playing it
safe' and not trying to convert a DOS segment:offset address to a physical
memory address. Again, that's just a guess, and I'm not sure why it would
work with reads and with USB (which also require physical memory addresses)
and not with NVMe writes or why the buffer would just be 8k in size.
The only ways I can think of to fix it would be to use some kind of VM, or
to create a TSR that subdivides the large writes into 8k chunks. This could
be done at the INT 21h level, the DOS block device driver level, or the INT
13h level. The INT 13h level would probably be the most "universal".
I should also say that in the modern world of virtualization, this really
shouldn't be all that surprising. Just like there are different "types" of
DOS and/or BIOS and/or hardware virtualization, and they are not all created
equally, there are different "types" of CSM and they are not created
equally, either. And, just like special accommodations must be made at times
when using certain DOS/BIOS/hardware virtualizers, we really should be
surprised that the same thing is true for certain CSMs.
""_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
