NetBSD Problem Report #58624

From www@netbsd.org  Wed Aug 21 21:17:10 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 6B1AB1A923F
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 21 Aug 2024 21:17:10 +0000 (UTC)
Message-Id: <20240821211709.3E59E1A9242@mollari.NetBSD.org>
Date: Wed, 21 Aug 2024 21:17:09 +0000 (UTC)
From: vezhlys@gmail.com
Reply-To: vezhlys@gmail.com
To: gnats-bugs@NetBSD.org
Subject: dosboot(8) fails to load kernel through eXtended Memory Specification API (XMS)
X-Send-Pr-Version: www-1.0

>Number:         58624
>Category:       port-i386
>Synopsis:       dosboot(8) fails to load kernel through eXtended Memory Specification API (XMS)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-i386-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 21 21:20:00 +0000 2024
>Closed-Date:    Sat Sep 14 20:00:53 +0000 2024
>Last-Modified:  Wed Sep 18 00:45:01 +0000 2024
>Originator:     Andrius V
>Release:        NetBSD 10 and lower
>Organization:
>Environment:
>Description:
Distribution provides a dosboot.com application which allows to load kernel in real mode. It works, when DOS is not loaded with so called eXtended Memory Specification (XMS) API support, but fails if it does. dosboot.com application, if detected, will use XMS code, however it seems to be broken for ages (likely after "Merge XMS changes from exec_fromdos.c" in this commit https://github.com/NetBSD/src/commit/e58bb7948317c81664b47ff2d86b21df13f69251), potentially worked back in 1.3.x releases. Currently bootloader reboots on ppbcopy() call (https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#450). There are some multiple problems I can observe now:

1) https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#446 has duplication loadaddr subtraction for MARK_END and no for MARK_ENTRY and MARK_DATA, likely this part should be similar to efi part:
		marks[MARK_START] -= loadaddr;
		marks[MARK_ENTRY] -= loadaddr;
		marks[MARK_DATA] -= loadaddr;
		marks[MARK_SYM] -= loadaddr;
		marks[MARK_END] -= loadaddr;

or at least MARK_END not subtracted twice.
2) origaddr passed to ppbcopy() is 0x0, since original loadaddr is 0 coming from the dosboot main(), which seemingly causes reboot. I would assume this value should not be 0.

3) As a result of passing higher, code will reach startprog(), but will either hang or reboot (I assume entry is not calculated properly). 

And at this point I am already not sure how to move forward besides wild guesses with little chance of successful results.

This bug has a negligible priority, considering nobody really complained in years, and unlikely booting netbsd from DOS in real mode is preferred way for any imaginable reasons, but application is still provided and works in certain conditions, described above... Maybe somebody will have an interest in fixing XMS code too.
>How-To-Repeat:
The way I was testing by running qemu with FreeDOS 1.3 installed:
qemu-img create c.hd 100M
qemu-system-i386  -hda c.hd -cdrom FD13LIVE.iso -boot d
install FreeDOS to HD
create and mount c.hd on vnd0 
mount /dev/vnd0e /mnt
copy dosboot.com and any i386 kernel (e.g. install)
qemu-system-i386 -hda c.hd -boot d
Choose "4 - Load FreeDOS low with some drivers (Safe Mode)" in FreeDOS booloader selection menu
(should load DOS in real-mode with XMS)
dosboot.com netbsd 
observe reboot

As alternative
"5 - Load FreeDOS without drivers (emergency mode)"
dosboot.com netbsd will boot system successfully (XMS code is not used).
>Fix:

>Release-Note:

>Audit-Trail:
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: gnats-bugs@netbsd.org, port-i386-maintainer@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, vezhlys@gmail.com
Cc: 
Subject: Re: port-i386/58624: dosboot(8) fails to load kernel through eXtended
 Memory Specification API (XMS)
Date: Mon, 26 Aug 2024 17:14:20 +0900

 Hi Andrius, thanks for analysis!

 On 2024/08/22 6:20, vezhlys@gmail.com wrote:
  > however it seems to be broken for ages (likely after "Merge XMS 
 changes from exec_fromdos.c" in this commit 
 https://github.com/NetBSD/src/commit/e58bb7948317c81664b47ff2d86b21df13f69251), 
 potentially worked back in 1.3.x releases.

 When I cleaned up dosboot.com recently, I had the same impression.
 I thought about trying PC DOS 2000 for sure, but I haven't yet
 (probably never)...

 Let us drop XMS support entirely. It has been broken over the
 last quarter century (!!!), and we can safely assume there are
 no user needs... As a bonus, we can unifdef some `XMS` blocks
 outside dosboot directory.

 Here, I note again that dosboot.com successfully works without XMS.
 We can drop himem.sys nor himemx.exe from config.sys, or skip
 config.sys itself. Then, we can use extended memory by ourselves.

 Thanks,
 rin

From: Andrius V <vezhlys@gmail.com>
To: Rin Okuyama <rokuyama.rk@gmail.com>
Cc: gnats-bugs@netbsd.org, port-i386-maintainer@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-i386/58624: dosboot(8) fails to load kernel through eXtended
 Memory Specification API (XMS)
Date: Tue, 27 Aug 2024 22:40:45 +0300

 On Mon, Aug 26, 2024 at 11:14=E2=80=AFAM Rin Okuyama <rokuyama.rk@gmail.com=
 > wrote:
 >
 > Let us drop XMS support entirely. It has been broken over the
 > last quarter century (!!!), and we can safely assume there are
 > no user needs... As a bonus, we can unifdef some `XMS` blocks
 > outside dosboot directory.
 >

 Sure, I can remove the code if nobody else is against that.
 I would assume the fix would have been few lines of code here and there,
 however I agree that removing it gives more practical advantages,
 including the cleaner code.

 > Here, I note again that dosboot.com successfully works without XMS.
 > We can drop himem.sys nor himemx.exe from config.sys, or skip
 > config.sys itself. Then, we can use extended memory by ourselves.
 >

 True!

 > Thanks,
 > rin

 Thank you for your response!

 Regards,
 Andrius V

From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Andrius V <vezhlys@gmail.com>
Cc: gnats-bugs@netbsd.org, port-i386-maintainer@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-i386/58624: dosboot(8) fails to load kernel through eXtended
 Memory Specification API (XMS)
Date: Fri, 30 Aug 2024 17:40:10 +0900

 On 2024/08/28 4:40, Andrius V wrote:
 > On Mon, Aug 26, 2024 at 11:14 AM Rin Okuyama<rokuyama.rk@gmail.com>  wrote:
 >> Let us drop XMS support entirely. It has been broken over the
 >> last quarter century (!!!), and we can safely assume there are
 >> no user needs... As a bonus, we can unifdef some `XMS` blocks
 >> outside dosboot directory.
 >>
 > Sure, I can remove the code if nobody else is against that.
 > I would assume the fix would have been few lines of code here and there,
 > however I agree that removing it gives more practical advantages,
 > including the cleaner code.

 Thanks, please go ahead!

 // If you are really interested to fix it, I will gladly offer testing;
 // I will excavate my copy of PC DOS from somewhere in my room :)
 //
 // Retro computing is always fun. I do not definitely mean to impose,
 // of course, although ;)

 Thanks,
 rin

From: Martin Husemann <martin@duskware.de>
To: Rin Okuyama <rokuyama.rk@gmail.com>
Cc: Andrius V <vezhlys@gmail.com>, gnats-bugs@netbsd.org,
	port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: port-i386/58624: dosboot(8) fails to load kernel through
 eXtended Memory Specification API (XMS)
Date: Fri, 30 Aug 2024 10:54:58 +0200

 Maybe a bit of historical context: back in the days the "easiest" way to
 test NetBSD on a machine that usually booted into Windows 95 was: download
 the install kernel, reboot and while rebooting press some function key
 to abort boot and drop into the DOS command line.

 Then you could run dosboot and let it loaded the NetBSD kernel.

 Most Win9x installations had some EMMS/XMS manager installed
 and properly talking to those was important to get the kernel loaded.

 Nowadays (with bootable USB sticks) this scenario is (as) obsolete (as Win9x),
 you would simply boot the full image from USB and not touch anything already
 installed on the machine. 

 Martin
 P.S.: I had to look it up but USB really happened only 1996, and firmware that
 could boot from it even (slightly) later.

From: "Andrius Varanavicius" <andvar@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/58624 CVS commit: src/sys/arch/i386/stand
Date: Wed, 11 Sep 2024 20:15:37 +0000

 Module Name:	src
 Committed By:	andvar
 Date:		Wed Sep 11 20:15:37 UTC 2024

 Modified Files:
 	src/sys/arch/i386/stand/dosboot: Makefile main.c start_dos.S version
 	src/sys/arch/i386/stand/lib: exec.c

 Log Message:
 dosboot(8): remove XMS-specific code. The boot process has been broken for over
 a decade, and its relevance has diminished due to the availability of other boot
 options.

 PR port-i386/58624


 To generate a diff of this commit:
 cvs rdiff -u -r1.38 -r1.39 src/sys/arch/i386/stand/dosboot/Makefile
 cvs rdiff -u -r1.33 -r1.34 src/sys/arch/i386/stand/dosboot/main.c
 cvs rdiff -u -r1.1 -r1.2 src/sys/arch/i386/stand/dosboot/start_dos.S
 cvs rdiff -u -r1.11 -r1.12 src/sys/arch/i386/stand/dosboot/version
 cvs rdiff -u -r1.80 -r1.81 src/sys/arch/i386/stand/lib/exec.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Andrius V <vezhlys@gmail.com>
To: Martin Husemann <martin@duskware.de>
Cc: Rin Okuyama <rokuyama.rk@gmail.com>, gnats-bugs@netbsd.org, 
	port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org
Subject: Re: port-i386/58624: dosboot(8) fails to load kernel through eXtended
 Memory Specification API (XMS)
Date: Fri, 13 Sep 2024 08:40:19 +0300

 On Fri, Aug 30, 2024 at 11:54=E2=80=AFAM Martin Husemann <martin@duskware.d=
 e> wrote:
 >
 > Maybe a bit of historical context: back in the days the "easiest" way to
 > test NetBSD on a machine that usually booted into Windows 95 was: downloa=
 d
 > the install kernel, reboot and while rebooting press some function key
 > to abort boot and drop into the DOS command line.
 >
 > Then you could run dosboot and let it loaded the NetBSD kernel.
 >
 > Most Win9x installations had some EMMS/XMS manager installed
 > and properly talking to those was important to get the kernel loaded.
 >
 > Nowadays (with bootable USB sticks) this scenario is (as) obsolete (as Wi=
 n9x),
 > you would simply boot the full image from USB and not touch anything alre=
 ady
 > installed on the machine.
 >
 > Martin
 > P.S.: I had to look it up but USB really happened only 1996, and firmware=
  that
 > could boot from it even (slightly) later.

 Thank you for insightful historical context! Yes, it seems not much
 people would do that in this way now. I removed the code for now, but
 as we discussed in IRC, if someone has passion to fix it, the code can
 be restored. I tried few patches, unfortunately with no success...

State-Changed-From-To: open->closed
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Sat, 14 Sep 2024 20:00:53 +0000
State-Changed-Why:
XMS code was removed.

From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/58624 CVS commit: src/sys/arch/i386/stand/lib
Date: Wed, 18 Sep 2024 00:44:03 +0000

 Module Name:	src
 Committed By:	rin
 Date:		Wed Sep 18 00:44:03 UTC 2024

 Modified Files:
 	src/sys/arch/i386/stand/lib: libi386.h

 Log Message:
 i386/stand: Remove XMS leftover from libi386.h, NFC

 PR port-i386/58624


 To generate a diff of this commit:
 cvs rdiff -u -r1.53 -r1.54 src/sys/arch/i386/stand/lib/libi386.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search