Issues on copying files on PC-98 with LOADALL?

[tyama501]

This is sub issue from
#2389 (comment)

I have booted from 1232k floppy and confirmed
mount /dev/hda1 /mnt
cp /bin/* /mnt/tmp

gets the same stuck problem if
hma=kernel
xms=on
#xms=int15

It succeeded if
#hma=kernel
#xms=on
#xms=int15
or
hma=kernel
#xms=on
#xms=int15
or
#hma=kernel
xms=on
xms=int15

So, it looks LOADALL problem.

Thank you.

[tyama501]

I have tried one more variation, using LOADALL

#hma=kernel
xms=on
#xms=int15

Unexpectedly this succeeded.

It might only occurrs when hma=kernel and LOADALL both are enabled.

[tyama501]

Hmm, something still might be wrong with above case too. I couldn't remove some files properly.
(EDIT: some wrong files have been created)

[ghaerr]

Perhaps try copying floppy to floppy (instead of hard disk) or to same floppy to make sure problem isn't the hard disk driver or differing sector sizes.

[tyama501]

Hello @ghaerr ,

I need to prepare another floppy disk so I will try that later but
is there difference using int1F or LOADALL on the driver?
(It looks int1F is working.)

Thank you.

[ghaerr]

Hello @tyama501,

There shouldn't be any explicit difference in the driver between INT 1F and LOADALL, they are both handled underneath the xms_fmemcpy function call. We can take a deeper look at that when a more definitive error case is found.

From your screenshot above, it looks like the /mnt/tmp directory entries have been written with garbage. You might try ls /mnt/tmp to get a better look.

Whether this is related to INT 1F, LOADALL or possibly sector size differences between FD1232k and HD is hard to tell at this point. LOADALL is a non-BIOS rewrite of the BIOS INT 1F call. I had thought we tested LOADALL pretty heavily, but it's always possible a register was not saved or perhaps another area of memory being overwritten (IIRC the LOADALL CPU buffer is directly next to DMA buffer?) Also could be related to HMA as you have seen. At this point, reducing variables and keeping error reproduction as simple as possible will help.

Does this occur only on real hardware, or can you duplicate on Neko or DosBox-X?

Thank you!

[tyama501]

Neko looks ok. It is using UNREAL mode.

EDIT:
fsck-dos.os2 after copying files from fd1232 to hda1 on Neko.

Thank you.

[drachen6jp]

Hello.@ghaerr. Hello.@tyama501
I wrote Loadall code before.
I did find bug on loadall.S.
line 174
mov %bx,%es:(0x30) #BX is block operation code
830h does'nt mean BX register
and line 176
//mov %dx,%es:(0x2e) #the following not required to be preserved
82eh also doesn7t mean DX register.

these are reverse.
thank you!

[ghaerr]

Hello @drachen6jp,

Wow! Very nice catch on incorrect registers being setup in loadall routine!!! What is most surprising to me is that this ever worked in the first place, since the value of DX (instead of BX) was being used to determine the BX operations code (0=copy, 1=clear).

Hello @tyama501, I have made the following patch for your testing and will commit it shortly:

diff --git a/elks/arch/i86/lib/loadall.S b/elks/arch/i86/lib/loadall.S
index cce9a833..a8c32335 100644
--- a/elks/arch/i86/lib/loadall.S
+++ b/elks/arch/i86/lib/loadall.S
@@ -171,9 +171,9 @@ loadall_block_op:
        mov     %sp,%es:(0x2c)
        //mov   %di,%es:(0x26)  #comment out sets SI, DI zero for REP MOVS
        //mov   %si,%es:(0x28)
-       mov     %bx,%es:(0x30)  #BX is block operation code
+       mov     %bx,%es:(0x2e)  #BX is block operation code
        mov     %cx,%es:(0x32)  #CX is byte count for block operation
-       //mov   %dx,%es:(0x2e)  #the following not required to be preserved
+       //mov   %dx,%es:(0x30)  #the following not required to be preserved
        //mov   %ax,%es:(0x34)
        .byte   0x0F,0x05       #loadall opcode - execution continues at new IP
        # not reached

Hopefully this fix the problem you are seeing with the copy.

Thank you!

[ghaerr]

Hello @drachen6jp,

What is most surprising to me is that this ever worked in the first place

After studying a bit more, I think the reason it worked with wrong programming is that the DX value was never saved (for speed reasons, since it is allowed be clobbered), thus the value of BX was always being set to 0 since 0830 was always 0. This caused operation to always be COPY. When filesystem sometimes issued command for CLEAR, this would either corrupt buffer by not zeroing or copy to invalid locations in passed GDT, crashing system.

Thank you!

[ghaerr]

fsck-dos.os2 after copying files from fd1232 to hda1 on Neko.

It would be interesting to see the results of fsck-dos.os2 on hda1 damaged by LOADALL problem on real hardware or Neko running LOADALL mode. This would tell us more about how good a disk checker fsck-dos really is.

[tyama501]

Hello @ghaerr and @drachen6jp ,

I got a good news and a bad news.

First of all, here is the fsck-dos.os2 result requested by @ghaerr of the broken files.
Does the fsck modify the boot block signature? It says so after running it once although it can still boot.

[good news]
I could install and copy files using LOADALL when
#hma=kernel
xms=on
#xms=int15
Thank you!

[bad news]
It still get stuck if I enable hma=kernel when copying.

I tried cp -v /bin/* /mnt/tmp/ a couple of times
and once I have gotten A20 LINE ERROR (hardware message from PC-98).

Other time it just stuck here.

[ghaerr]

[good news]
I could install and copy files using LOADALL when
#hma=kernel
xms=on

That is good news, so @drachen6jp's LOADALL fix is working.

[bad news]
It still get stuck if I enable hma=kernel when copying.
once I have gotten A20 LINE ERROR (hardware message from PC-98).

I am guessing this is a separate issue from LOADALL. This could easily be caused by the PC98 BIOS if it switches A20 line for any reason while ELKS is running.

Did PC-98 work well before using xms=on (not xms=int15?).

Next step would be testing without XMS but with HMA:

hma=kernel
#xms=on
#xms=int15

I would also guess that hma=kernel will work fine with xms=int15, but that should also be tested. If BIOS uses A20 switch ever, then running kernel in HMA won't work, as the timer interrupt could cause interrupt into HMA area when A20 is OFF.