Re: [Freedos-devel] trying to understand execrh.asm -- calls to EXECRH cause my 286 system to lock up

[C. M. <pu...@ul...>]

On at 2023-05-09 21:02 -0500, reh...@gm... 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