Re: [Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

On Mon, 1 Jun 2003, Eric W. Biederman wrote:
> 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.

Our code has to interoperate with anything else that might allocate base
memory.  The code is remarkably simple and robust; it doesn't leak memory
even when stress-tested with a dodgy PXE ROM that likes to sometimes
refuse to unload.  With debugging disabled it's 225 bytes of code.

The long sequence of "Freed" message you see there doesn't imply that
those blocks were freed in that order.  You can call forget_base_memory()  
on blocks in any order; they will then be automatically freed as soon as
it becomes possible to do so.

To implement a "free this block and everything below it" strategy would 
cause problems in the case of an UNDI driver refusing to unload.  This 
does happen often; my Intel PXE ROM does it every other time.  The current 
strategy copes perfectly, a "free myself and below" strategy would have a 
choice of either (a) marking as free memory that was still in use, 
risking a crash later, or (b) leaking memory.

The only part of the interface that I don't like is that it is necessary 
to pass the size of the block to forget_base_memory().  There's no easy 
way around this; we can't do the normal trick of allocating an extra four 
bytes and using it to store the block size, because BIOS memory allocation 
granularity is 1kB.

> 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.

As part of the development, I've done this stress test a few hundred times
with a floppy boot, with an unplugged cable / invalid file to prevent it
booting.  Initialisation and cleanup is stable, including memory
allocation/deallocation.

Since my PXE ROM doesn't like unloading properly, I've been involuntarily
testing both the "find a loaded UNDI driver" and the "install an UNDI
driver from ROM" code paths.

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

I'm fairly certain it's the latter.  I *will* get around to debugging it 
properly, but it'll have to wait until after I get back from Norway on 
Thursday.

Michael