DOS ain't dead

I just observed a strange behaviour on my DOS configuration on new MB Gigabyte GA-P67-DS3-B3. I used JEMMEX and DOS 6.22 without problems for years. I have a line in autoexec.bat that delete some leftover file after Win98 run that is sometimes created. Now I found that computer hangs if file exist and DOS is trying to delete the file. It waits about a minute and then display disk access error message abort/retry/fail...
If I step the autoexec, break before delete and type del file command manually it hangs too. I tracked the problem and found that if I skip loading JEMMEX in my config.sys then it works fine. I tried various safe options but none helps, e.g.:
DEVICE=C:\DOS\JEMMEX.EXE X=A000-FFFF NOHI NOVME NOINVLPG NOEMS NOVCPI VERBOSE
What's interesting is that if I load the UIDE or XIDE driver later in autoexec it will fix it and write access works. So I just moved the del line behind loading xide but I don't have a good feeling about it. It's indicating something is rotten in JEMMEX or BIOS (I use SATA in IDE legacy mode). Any idea what JEMMEX option could help to avoid this?

UPDATE:
further bug tracking found that it's NOT Jemmex specific but also happen with QEMM386 and EMM386 but only when I do write access to partitions on SSD drive attached to SATA3 controller. No problem with writting on partitions on HDD attached to SATA2.
So I assume that's some BIOS bug which affects only SATA3 ports (It may be linked with setting IDE legacy mode that may not work properly) and triggers only under V86 mode. It's interesting that loading of UIDE/XIDE fix it. I'd like to isolate what operation XIDE do that fix it.

It also explains me why Win98 couldn't boot from SATA3 attached SSD (no problem on SATA2 port) because it switches to V86 mode and triggers the bug. I just tried to load XIDE in Win98's autoexec.bat and it booted to desktop (before it just hanged in textmode screen) but then immediatelly crashed the explorer.exe - I don't wonder that XIDE is not compatible with Win98 but just to demonstrate it fixed SATA3 issue some way and moved further in boot process...

---
DOS gives me freedom to unlimited HW access.

Strange. It looks as a problem with BIOS. What happens if you load XIDE with parameter /E ?
(with this parameter does not try to use ATA/ATAPI commands but fully relies on BIOS)

---
DOS-u-akbar!

> Strange. It looks as a problem with BIOS. What happens if you load XIDE
> with parameter /E ?
> (with this parameter does not try to use ATA/ATAPI commands but fully
> relies on BIOS)

Yes, it's some BIOS bug, read the update in 1st post. With /E option the XIDE doesn't fix the problem so it's necessay to touch some IDE registers directly...

---
DOS gives me freedom to unlimited HW access.

After a discussion with Jack it become clear that the problem lies in BIOS DMA implementation. For some reason (probably a need to save space) the BIOS DMA support was simplified to not support v86 mode logic BUT only on two SATA3 ports. So the proper solution is to load xhdd driver before switching to v86 mode which takes DMA control over BIOS and prevent failure. In my case read mode still seems to work also in v86 mode so I load xhdd just after v86 memory manager.
Unfortunatelly there's no solution for Win9x as they don't like xhdd and there's no special SATA driver that will bypass the BIOS DMA logic. So as a workaround I moved Win98 to second HDD attached to SATA2 port and I use BIOS boot manager to swap boot drives, it works.

---
DOS gives me freedom to unlimited HW access.

In theory should be possible to write small INT13 BIOS patch which cures the DMA control but still allows to run windows.
But it is not realistic because only few people are enough skilled to do such job.

---
DOS-u-akbar!