Date: Sun, 25 Nov 2001 17:06:15 +0530 From: Bruce Montague <brucem@cse.iitkgp.ernet.in> To: freebsd-small@freebsd.org Subject: sendudp()/readudp() delay() in pxe.c Message-ID: <200111251136.fAPBaFv05935@cse.iitkgp.ernet.in>
next in thread | raw e-mail | index | archive | help
File "/usr/src/sys/boot/i386/libi386/pxe.c"
routines "sendudp()" and "readudp()" both
contain the code fragment:
-------
pxe_call(PXENV_UDP_ {READ/WRITE} );
#if 0
/* XXX - I dont know why we need this. */
delay(1000);
#endif
------
I found a case where, to successfully load the
kernel via pxeboot, not only did I need it,
I needed something on the order of:
--------
#if 1
/* XXX - I dont know why we need this. */
delay(1000);
delay(10000);
#endif
-------
I was non-deterministically pxebooting a small
PC (a NatSemi Geode-based "reference system"
called the SP2GX00, aka Aries). It has an
XpressROM BIOS by Insyde Software and PXE (I'm
not sure what version, a boot message says
PXE-2.0, "pxe.c" prints out "PXE version 2.1"
based on a signature). The Ethernet is a
DP83815 "MacPHYTER" (sis driver).
About half the pxeboots, somewhere in the NFS
load of the kernel the loader would die, with
a BTX dump and "BTX halt". Nfsstat showed no
particular location, sometimes it would crash
almost at the start of the load, sometimes
later... If I ran tcpdump on the server perhaps
about 80% of the boots would work, suggesting
a timing or event ordering problem. I increased
the number of nfsd servers to 20, which did
not seem to have an effect; might have made
things slightly worse.
The large delays have made the pxeboot "100%"
successful. It has never crashed with the delays
as above (I've probably booted it 30 times by
now). Restoring the code to the original
readily reproduces the crashes. The original
"delay(1000)" calls did not seem to have any
effect, that is, the system would still crash.
The "delay()" calls here are PC BIOS calls
(int 15, eax=0x86).
I conclude the BIOS/BTX/pxeboot likes things
rather sedate and non-reentrant or some-such,
and that multiple events or events out of
order in the BIOS/BTX/pxeboot environment lead
to grief. Wish I had time to probe further...
Is there a version of PXE BIOS code that has
this as a known problem?
I was using 4.3 Stable. The "pxe.c" file has
not changed in over 8 months.
BTW, I also had to ifconfig the connection to
10BaseT; with autoselect or 100, the client
would not reliably send a DHCP Request even
though it was getting valid offers...
Various related screen dump output:
--------------------------------
Aries Version R1.02
XpressROM V3.2.1
Built 04/05/2001
...
PXE-M00: BootManage PXE-2.0 PROM 1.0, NS83815 3.1 SDK (build 077)
...
PXE Loader 1.00
Building the boot loader arguments
Relocating the loader the the BTX
Starting the BTX loader
BTX loader 1.00 BTX version is 1.01
Console: internal video/keyboard
BIOS drive C: is disk0
PXE version 2.1, real mode entry point @9716:0106
BIOS 549kB/27648kB available memory
FreeBSD/i386 bootstrap loader, Revision 0.8
(brucem@, Sun Nov 25 02:28:58 PST 2001)
pxe_open: server addr: <blah>
pxe_open: server path: <blah>
pxe_open: gateway ip: <blah>
Loading Kernel...
/kernel text=0xdfecb data=0x23d2dc+0x16cd4 |
int=0000000d err=00000000 efl=00010296 eip=01bb0026
eax=ffffffff ebx=12740100 ecx=0002aec0 edx=18450000
esi=c006904b edi=00026500 ebp=0000d93c esp=0000d93c
cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033
cs:eip=fb 01 82 17 fb 01 37 a2-fc 01 e8 f9 fc 01 c5 f8
ss:esp=00 e8 da b1 00 00 b8 ff-ff ff ff eb 24 8d 76 00
BTX halted
-----------------
This is not static. Sometimes it's int=6,
sometimes int=d, eip is not the same, etc...
- bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111251136.fAPBaFv05935>