#317 FreeDOS 13-rc4 freezes when loaded through iPXE

[Jacek]

FreeDOS 13-rc4 freezes after CD-ROM driver loading step when loaded through iPXE using sanboot.
There's a screenshot of VM with using FD13FULL.img:

The same is for FD13LIVE.iso

I can successfully boot FD12FULL.img and FD12CD.iso using this method, so it's a regression:

[Shidel]

Thanks for the report. Based on your images, I think I may know what the problem may be. While it is new problem and so not a regression, that isn't really relavant and still needs fixed.

What I think is happening in your case involves a hardware compatibility issue regarding timers and delays at the end of the CD initialization.

To insure this issue is fixed for the next release, I would like you to verify the problem...

using the 1.2 release, boot the install media.
quit the installer and return to the DOS prompt.
run vdelay 2000
there should be an approximate 2 second delay and then returned to the command line.
run vdelay /D 2000
If my diagnosis is correct, the command prompt will not return and VM will hang.

Please let me know your test results.

Thanks.

[Jacek]

It's exactly as you said - first command did sleep for 2 seconds and second doesn't return. VM doesn't hang tho, as prompt is blinking. It's just not returning.

[Shidel]

Yes, it's not as true "hang". More of a sit and wait for something that never happens. Basically, a standard timer function SET EVENT WAIT INTERVAL that has existed since the PC-AT doesn't function on some virtiual machines on some hardware. When /D optiong is used with VDELAY, the current version of checks if the machine is a 286 or better. If so, it assumes the function works.

I've just added a test for the return results of that function. Hopefully, it will report to VDELAY that it could not set a timer. If that happens, VDELAY will fall back to timer tick counting.

I've attached this new version of VDELAY. Please do me a favor and try it with both "VDELAY 2000" and "VDELAY /D 2000" in your VM and see if it still gets stuck with the /D option. I'm hoping that by adding the additional check it makes VDELAY more compatible.

Thanks

[Shidel]

Updated CD startup delay to use more compatible method in VDELAY.

[Jacek]

It didn't fix the issue.

EDIT: I even removed vdelay from setup directory to be sure it runs from disk. Still the same issue.

[Shidel]

Oh, well. I was hoping the VM woulds respond to VDELAY that it can't set the timer. But apparently, it reports that it set one successfully, fails to return after the call or some other issue preventing it from functioning correctly.

[Jacek]

Is there something I can provide to try helping?

[Shidel]

I've just reworked the BIOS precision timer based delay in VDELAY to attempt to compensate for the issue. Basically, it will set the timer and moniter clock ticks. If more clock ticks occur than should have elapsed while waiting for the timer, it will assume the timer failed and return.

So in this new version, if the BIOS reports that the timer cannot be set it will fall back to simple tick counting. However, as long as the BIOS timer function returns control back to VDELAY, it will also watch the tick counts and will not get stuck waiting for the event that never occurs.

Give this one a try with and without the /D option.
:-)

[Shidel]

There was a bug in the VDELAY2.ZIP I found... Pulled that version and fixed it. Please give this one a try. :-)

[Jacek]

It works ;D

[Shidel]

Awesome, thanks. :-)

[Jacek]

There's some problem with what iPXE changes in OS.
When I boot FD12CD.iso directly from VM's CD-ROM - even original vdelay work.
Problem appears when I sanboot it through http.
To replicate:
- get QEMU
- run iPXE in QEMU
- run local http server supporting range requests in directory with FD iso file
eg.

python -m RangeHTTPServer

• in iPXE call command:

sanboot -d 0xe0 http://local_server:port/FD_path.iso

In booted FreeDOS try running vdelay /d 2000 - it blocks forever.

And please. Next time don't close issue after 7 hours without response...

[Jim Hall]

Can you reconfirm this is an issue in FereDOS 1.3?