Re: [Etherboot-developers] UNDI driver

[<ebi...@ln...>]

Marty Connor <md...@et...> writes:

> I've been doing some testing of the UNDI driver with 5.1.8, and have  some
> results that I hope will help with debugging.

A couple of quick comments.
1) The failure modes between the two cases appear to be different
   with the exception that etherboot looses control of the execution.


2) It looks for allocating low memory we may have an interface that is
   more complex than necessary.

> Freed 2 kB base memory, 610 kB now free
> Freed 20 kB base memory, 630 kB now free
> Freed 8 kB base memory, 638 kB now free
> Freed 1 kB base memory, 639 kB now free

   The allot primitive in etherboot while it is like malloc it is modeled
on objstacks, and the forth where forget on an object frees that object and all
objects allocated after it.  Which tends to make the code simpler as individual
allocation do not need to be tracked.

3) A very interesting test would be load unzi.zfd0 and point it at a file that
   is not served by the tftp server.  But to point it at a valid tftp server.
   This would stress the initialize and clean up paths, of the driver.
   As etherboot loops repeatedly trying to load an absent image off of the 
   network, initializing and shutting down the driver every couple of seconds.

   At the very least this would give a good clue about how stable the base
   UNDI driver is.

   And a basic question is:  Is the problem the UNDI driver or are we not properly
   cleaning up the PXE stack.

Eric