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

[rehsd.info]

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  
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

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

[C. Masloch]

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

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

[rehsd.info]

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. 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

Thanks!

Rich

-Original Message-
From: Eric Auer  
Sent: Friday, May 5, 2023 9:20 AM
To: Technical discussion and questions for FreeDOS developers.

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


Hi Rich,

> -My BIOS supports both CHS and LBA. FreeDOS is using CHS due to the 
> size of the CF card (~500MB). I will try forcing LBA.

Actually that should depend on partition type, not on disk size ;-)

> -I log interrupt calls out to my serial debugger on my 286. In 
> execrh(), I am not seeing any INT13H calls get called.

Interesting!

> -I will need to learn more about disk I/O drivers. I assume for the 
> IDE CF Card, that driver is part of the FreeDOS kernel code.

Yes, sort of. Everything which is supported by INT13 will be accessed by
INT13 calls which are done by built-in kernel disk drivers.

As you apparently got far enough to enumerate the partitions, your problem
does not seem to be with our initdisk.c and not in our boot.asm but you may
want to look in dsk.c, floppy.asm or (less likely) blockio.c (which just
calls the driver) etc.

Things happen for example in LBA_Transfer() which calls
fl_lba_ReadWrite() which is what actually calls int 13h.

> -My system does not support DMA at this stage. I am using PIO mode only.

Okay.

Regards, Eric




___
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

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

[Eric Auer]

Hi Rich,


-My BIOS supports both CHS and LBA. FreeDOS is using CHS due to the size of
the CF card (~500MB). I will try forcing LBA.


Actually that should depend on partition type, not on disk size ;-)


-I log interrupt calls out to my serial debugger on my 286. In execrh(), I
am not seeing any INT13H calls get called.


Interesting!


-I will need to learn more about disk I/O drivers. I assume for the IDE CF
Card, that driver is part of the FreeDOS kernel code.


Yes, sort of. Everything which is supported by INT13 will be
accessed by INT13 calls which are done by built-in kernel
disk drivers.

As you apparently got far enough to enumerate the partitions,
your problem does not seem to be with our initdisk.c and not
in our boot.asm but you may want to look in dsk.c, floppy.asm
or (less likely) blockio.c (which just calls the driver) etc.

Things happen for example in LBA_Transfer() which calls
fl_lba_ReadWrite() which is what actually calls int 13h.


-My system does not support DMA at this stage. I am using PIO mode only.


Okay.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

[rehsd.info]

Thank you, Eric!

-I will do some testing of reading the CF card outside of the FreeDOS
kernel, as you suggest.
-My BIOS supports both CHS and LBA. FreeDOS is using CHS due to the size of
the CF card (~500MB). I will try forcing LBA.
-I log interrupt calls out to my serial debugger on my 286. In execrh(), I
am not seeing any INT13H calls get called.
-I will need to learn more about disk I/O drivers. I assume for the IDE CF
Card, that driver is part of the FreeDOS kernel code. If I wanted to add
some debug code to the driver, where should I look to find the driver source
code? I see a "drivers" folder in the source, but the only thing that looks
related is floppy.asm. I can try adding some logging code in this file.
-My system does not support DMA at this stage. I am using PIO mode only.
-I have my system running quite slowly (8MHz system bus, 4MHz processor
clock) at this stage.

I have updated the following post with additional details:
https://www.rehsdonline.com/post/troubleshooting-freedos-boot-on-my-286-syst
em-hangs-on-execrh-call-in-kernel. I will continue to update this as I
(hopefully) progress in this troubleshooting.

I appreciate all the suggestions. Thank you again, Eric!

Rich


-Original Message-
From: Eric Auer  
Sent: Friday, May 5, 2023 3:07 AM
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


Hi Rich,

> I am trying to better understand the EXECRH function in execrh.asm 
>  3cf5ac 0/kernel/execrh.asm> . Could someone help me understand the 
> call being made in EXECRH of "call  far[.dhp]"? To where is it 
> calling, and should I have done something in my BIOS or elsewhere to 
> support this call?
> 
> Additional Details: During boot on my 286 build the system hangs...

> * The rqblockio() function then calls execrh() [execrh.asm].

Well, this is how the kernel calls drivers. Apart from the detail that it
does STI, CLD as a side effect, which should not disturb other parts of the
kernel, it will call some kind of disk I/O driver in the context you
describe.

You write that you use a custom built BIOS for your 286, and a compact flash
card on IDE adapter as drive. So I suggest that you do some testing of the
BIOS itself, without DOS. You could write a small test case and install it
as boot sector. Maybe the BIOS has issues with the mentioned flag changes or
maybe it simply does not yet have sufficiently foolproof disk error
handling, so it fails when there is more disk access? Does the BIOS support
both CHS and LBA? Which one is used for booting?

You can pass options to SYS to force one of the other and you can use SYS
CONFIG to patch the kernel to force that as well.
It might also be some issue related to stack usage, DMA or the address
ranges used by DOS, disk I/O and maybe other drivers?

Interesting project in any case, I like to hear about your progress when you
got FreeDOS to boot on your custom BIOS!

Regards, Eric

PS: CF cards in the past were meant to access few, large files.
So they had few I/O per seconds. Sometimes they had hiccups.




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

[rehsd.info]

Hello, everyone.

 

I am trying to better understand the EXECRH function in execrh.asm
 . Could someone help me understand the call being made
in EXECRH of "call  far[.dhp]"? To where is it calling, and should I have
done something in my BIOS or elsewhere to support this call?

 

Additional Details: During boot on my 286 build the system hangs during the
kernel loading, where a call to EXECRH is eventually made. I don't believe
this is a FreeDOS issue, but likely an issue with my BIOS. Possibly, I need
to populate some table structure in memory with system or disk information
that I'm failing to populate, or I have an issue with one of my interrupt
handlers for INT13H disk services. The leadup to the lockup goes something
like this:

 

*   The kernel starts its loading process.
*   .
*   The truename() function [newstuff.c] is called during the kernel
load/processing.
*   The truename function then calls media_check() [fatfs.c].
*   The media_check() function calls rqblockio() in the same file.
*   The rqblockio() function then calls execrh() [execrh.asm].

 

If it's helpful, I posted some print screens of a debug build bootup and
some additional information here
 .

 

If anyone has any guidance, suggestions, pointers to helpful reading
material, etc., I would be grateful.

 

Thank you!

 

Rich

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel