Thank you, ecm! The information you provided has been very helpful. I have
been able to insert debug output in the driver to better troubleshoot.
Related, I am now reading "Advanced MSDOS Programming" from Microsoft Press,
and I'm finding it quite helpful. Little by little, I'm making progress.
Rich
-----Original Message-----
From: C. Masloch <pus...@ulukai.org>
Sent: Tuesday, May 16, 2023 12:10 PM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] trying to understand execrh.asm -- calls to
EXECRH cause my 286 system to lock up
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-28
> 6-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
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
