On at 2023-05-09 21:02 -0500, rehsd.i...@gmail.com wrote:
Thanks again, Eric, for the previous info. I've done a bit more digging but
haven't found the root cause of the issue yet. I have tried forcing LBA
(using sys & sys config). I have also added a bit more debugging info on
boot. I added more details to the following webpage, including a video
walkthrough trying to better describe the issue, in case anyone is bored or
just looking for a challenge. In execrh(), there are a pair of calls (likely
to a disk driver); the first of these calls ("call far the strategy") is
where I run into the issue. I'm not sure what "strategy" means in this
context.
The so-called strategy and interrupt entrypoints to DOS device drivers
are just part of the device interface, used by both block device drivers
(sector-based) and character device drivers (text-/byte-based).
You can read more about the device driver header in the interrupt list
[1], and also about the request header contents used by the various
function numbers [2]. There are some books describing this, too.
Technically, the two entrypoints are always far-called from the kernel
back to back, and the actual work by the device driver can happen in the
strategy entrypoint or in the interrupt entrypoint. Traditionally, the
strategy only ever saves the pointer it received into a buffer internal
to the device, and then the interrupt actually carries out the requested
command.
Possibly, the right information isn't being passed into the
execrh() routine, due to a failure at an earlier point. I plan to start
stripping down the kernel next -- to simplify testing and see what I can
learn.
https://www.rehsdonline.com/post/troubleshooting-freedos-boot-on-my-286-syst
em-hangs-on-execrh-call-in-kernel
If the strategy call doesn't return to the kernel soon it probably
called a bad pointer. Look at the source for the block device header
[3]. It uses GenStrategy as its strategy entrypoint, this only saves the
pointer [4]. The interrupt entrypoint is specific to the block device
[5], and it dispatches into a table in the C sources [6]. If you use a
kernel debugger you can break on and step into the far calls to the
strategy and interrupt entries to make sure they work as expected.
Regards,
ecm
[1]: https://fd.lod.bz/rbil/interrup/dos_kernel/2152.html#table-01646
[2]: https://fd.lod.bz/rbil/interrup/dos_kernel/2f0802.html#table-02595
[3]:
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L165
[4]:
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L202
[5]:
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L521
[6]:
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/dsk.c#L132
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
