Date: Thu, 2 Sep 2004 17:00:52 GMT From: Thomas Pornin <pornin@bolet.org> To: freebsd-i386@FreeBSD.org Subject: Re: i386/70525: [boot] boot0cfg: -o packet not effective Message-ID: <200409021700.i82H0qcY061992@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/70525; it has been noted by GNATS.
From: Thomas Pornin <pornin@bolet.org>
To: freebsd-gnats-submit@FreeBSD.org, hampi@rootshell.be
Cc:
Subject: Re: i386/70525: [boot] boot0cfg: -o packet not effective
Date: Thu, 2 Sep 2004 18:59:41 +0200
Hello,
I got a similar problem with 5.3-BETA1 (from August 21st) and I have found
the cause: boot0cfg gets the "packet" option reversed. If the most
significant bit in byte 0x1BB is set, then the "packet" option is
activated, since this is what is tested in sys/boot/i386/boot0.S:
testb $0x80,_FLAGS(%bp) # Use packet interface?
jz intx13.1 # No
But in usr/sbin/boot0cfg/boot0cfg.c, the following array is set:
static const struct {
const char *tok;
int def;
} opttbl[] = {
{"packet", 1},
{"update", 1},
{"setdrv", 0}
};
where the integer is set to 1 if the flag works in "reverse" (bit
whecleared n the option is activated). The integer for "packet" is
wrong: it makes boot0cfg believe that the "packet" option is set when
the most significant bit in byte 0x1BB is cleared, and that the option
is unset when the bit is set, whereas the assembly code in boot0.S
believes otherwise.
Therefore, right now, the quick workaround is to pass "-o nopacket" to
boot0cfg to _activate_ the packet option, and to remember that when
"boot0cfg -v" returns "nopacket", it means that the option is activated.
A relatively clean fix would be to change line 64 in boot0cfg.c back to:
{"packet", 0},
but maybe it would be better to make the "packet" option the default,
at least for new installations of the boot manager.
--Thomas Pornin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409021700.i82H0qcY061992>