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