Re: [Etherboot-developers] UNDI driver

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

> [UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
> Hunting for pixies...none found
> Hunting for ROMs...found 55AA at 000cc000...PCI:8086:1229...ok
> ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
> Located UNDI ROM supporting revision 2.1.0
> Installing UNDI driver code to 9d80:0000, data at 9a80:0000
> UNDI driver created a pixie at 9d80:0070...ok
> API 9d80:0106 St 9430:0800 UD 9a80:4d30 UC 9d80:1e70 BD 0000:37c0 BC  
> 0000:563a
> UNDI API call 0x000a failed with status 0x0000
> <snip> 
> Looks like an UNDI call failed. Please let me know if I can help debug  
> this one further.

Call 0x000a is PXENV_UNDI_SET_STATION_ADDRESS (you can find the numbers in 
arch/i386/include/pxe.h; I left textual descriptions of the API numbers 
out of the code to save space).  Interestingly, status 0x0000 is 
PXENV_STATUS_SUCCESS, so there's a bug in the Intel code if it's returning 
exit = PXENV_EXIT_FAILURE with status = PXENV_STATUS_SUCCESS.

I suspect this means that PXENV_UNDI_SET_STATION_ADDRESS isn't properly 
implemented.  You can try commenting out the call as follows:



--- arch/i386/drivers/net/undi.c        24 May 2003 20:16:25 -0000      1.12
+++ arch/i386/drivers/net/undi.c        29 May 2003 01:17:30 -0000
@@ -443,7 +443,7 @@
 }

 int eb_pxenv_undi_set_station_address ( void ) {
-       return undi_call ( PXENV_UNDI_SET_STATION_ADDRESS );
+       return 1; /* undi_call ( PXENV_UNDI_SET_STATION_ADDRESS ); */
 }

 int eb_pxenv_undi_get_information ( void ) {



PXE spec requires that we make this call, so it may be a case of "make the 
call, ignore failures and continue".

> Chaining didn't go so well for me. I wasn't able to get it to work.  
> Here's a relevant part of my dhcpd.conf file:
> # 3COM PXE Card
>      host ws137 {
>          hardware ethernet     00:01:02:59:03:d5;
>          fixed-address         192.168.2.137;
>          if        substring (option vendor-class-identifier, 0, 9) =  
> "PXEClient" {
>              filename "/undi.zpxe";
>          } else if substring (option vendor-class-identifier, 0, 9) =  
> "Etherboot" {
>              filename              "/lts/vmlinuz-2.4.19-ltsp-1";
>              option vendor-encapsulated-options  
> 3c:09:45:74:68:65:72:62:6f:6f:74:ff;
>          }
>      }
> Here's the output using the 3Com Card:
> Managed PC Boot Agent (MBA) v4.00
> (C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com  
> Corporation
> All rights reserved.
> Pre-boot eXecution Environment (PXE) v2.00
> (C) Copyright 1999 Intel Corporation.
> (C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com  
> Corporation
> All rights reserved.
> DHCP MAC ADDR: 00 01 02 59 03 D5
> CLIENT IP: 192.168.2.137  MASK: 255.255.255.0  DHCP IP: 192.167.2.37
> GATEWAY IP: 192.168.2.15
> PXE loader for etherboot
> 0x27FK low memory
>   PXENV+ unloaded
> ROM segment 0x0000 length 0x0000 reloc 0x00020000
> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> Relocating _text from: [0000c070,0001b780) to [07eb08f0,07ec0000)
> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
> Probing pci nic...
> [UNDI]Hunting for PnP BIOS... found $PnP at f000:2c30...ok
> Hunting for pixies...found !PXE at 0009d7a0...ok
> It hangs here.
> Please let me know how I can help debug this. It would be way cool to  
> make this work such that any PXE card could use Etherboot just by  
> chaining the Etherboot PXE loader.

Hmmm, it looks as though the PXE loader is unloading the stack but leaving 
the empty shell of the !PXE structure resident in memory, so that we pick 
it up on a scan and try to use memory that has already been freed.  
Two-stage fix:

1. Possibly perform further validity checks on the !PXE structure,
   although we're already checking the signature and checksum.

2. PXE loader should trash the UNDI code segment if it unloads the PXE 
   stack.

You might get it to work if you define PXELOADER_KEEP_UNDI when compiling 
pxeprefix.S; this should prevent the PXE loader from unloading the PXE 
stack.  I haven't tested this, just an idea.

I am off to Manchester for the next two days, but I'll take a look at the 
weekend.

> P.S. The screen texts above might have minor typos as I copied them by  
> hand. I tried my best to check the numbers to give you the best  
> information I could.

Many thanks; it's always useful to get detailed bug reports.

Michael