Problem booting from with a "PCnet/PCI II 79C970A"

[Dave Garry <daveg@pavilion.co.uk>]

I have a problem when etherbooting from a "PCnet/PCI II 79C970A"
onboard ethernet controller that is attached to a Xycom 654
single board computer. Booting from the test floppy works fine.

Xycom have supplied me a custom BIOS with a "hole" in it, this
is where I put an image of "lance_pci.rom" from the etherboot
package. The new bios is then loaded into flash, which all seems
to work OK. I can see the "55 AA" magic at the correct location
within the BIOS, and the BIOS does execute etherboot correctly
at boot time.

We have other diskless clients, with NE2000 cards, that boot fine
from EPROM and from the same server...

The server configuration is OK, bootp is configured correctly, tftp
works correctly, and I have a number of root file systems exported
to a number of diskless clients.

The server is running Caldera OpenLinux 1.3, with kernel 2.0.36.

The problem is as follows:

a) First I made a tagged image using:

   "mknbi-linux -x -k <KERNEL> -o <TAGGED_KERNEL>"

   The client performs the usual bootp, and loads the kernel via tftp,
   the kernel then starts and reaches the stage where it performs
   another bootp to obtain details from the server before mounting
   the root filesystem via NFS - but it stops there, and eventually
   times out with the error message:

   "Root-NFS: Unable to contact NFS server for root fs, using /dev/fd0 instead"
   "VFS: Insert root floppy and press ENTER"

   On the server I _CAN_ see the bootp requests from the client, which
   are sent a number of times before the timeout. The messages in my
   log files look OK, example:

   -------------------------------------------------------------------------------------
   Jul 15 14:38:32 SERVER bootpd[21093]: recvd pkt from IP addr 0.0.0.0
   Jul 15 14:38:32 SERVER bootpd[21093]: bootptab mtime: Thu Jul  8 11:37:53 1999
   Jul 15 14:38:32 SERVER bootpd[21093]: request from Ethernet address nn:nn:nn:nn:nn:nn
   Jul 15 14:38:32 SERVER bootpd[21093]: found 192.168.xxx.xxx (CLIENT)
   Jul 15 14:38:32 SERVER bootpd[21093]: bootfile="/tftpboot/diskless_kernel"
   Jul 15 14:38:32 SERVER bootpd[21093]: vendor magic field is 99.130.83.99
   Jul 15 14:38:32 SERVER bootpd[21093]: request message length=364
   Jul 15 14:38:32 SERVER bootpd[21093]: extended reply, length=364, options=128
   Jul 15 14:38:32 SERVER bootpd[21093]: sending reply (with RFC1048 options)
   Jul 15 14:38:32 SERVER bootpd[21093]: setarp 192.168.xxx.xxx - nn:nn:nn:nn:nn:nn
   -------------------------------------------------------------------------------------

   This seems odd to me, as the client obviously is cabable of transmitting
   the bootp request, but seems unable to hear the reply from the server.

   How can this be when the initial bootp/tftp DOES work correctly ?

b) Then made another tagged image as follows:

   "mknbi-linux -x -k <KERNEL> -o <TAGGED_KERNEL> -d rom -i rom"

   This of course supplies the IP address information to the kernel
   via the command line. This time the client starts the kernel and
   when it tries to mount the root filesystem it displays the error
   message:

   "NFS server 192.168.xxx.xxx not responding, still trying"

   The client then just sits there doing nothing!

   No entries are present in the servers log file indicating an
   attempt to NFS mount from the client... suggesting that the
   mount request does not reach the server.

   If the client is left long enough (about ten minutes) then a 
   screenfull of errors are generated:

   -------------------------------------------------------------------------------------
   eth0: transmit timed out, status 97f3, resetting.
   Ring data dump: dirty_tx 0 cur_tx 16 (full) cur_rx 0.
   <FOLLOWED BY A SCREEN OF HEX NUMBERS>
   -------------------------------------------------------------------------------------


I've even resorted to adding trace in the clients kernel in files
"fs/nfs/nfsroot.c" and "drivers/net/pcnet32.c" but I can't figure
out what is wrong.

>From what I can see the following functions in "drivers/net/pcnet32.c"
NEVER get called: "pcnet32_interrupt" or "pcnet32_rx"

The function "pcnet32_xmit" IS called each time the clients kernel
sends a bootp request prior to the NFS mount request.

The "PCnet/PCI II 79C970A" onboard NIC is assigned IRQ 15 by
the BIOS, and I can see that the "pcnet32_open" function also
finds the device at that interrupt...

By the way, I've tried this with Etherboot 4.2.3 and 4.2.4 with
exactly the same results. The "lance_pci.rom" file is different
between these versions, but the problem is the same for the client.

I also tried this some time ago using Etherboot 4.0, 4.1pre6
and 4.1pre7 with similar results (on Debian 1.3, with kernel 2.0.30)

What could be wrong ?

Is the "lance_pci.rom" image stable ?

Does anybody else out there use a "PCnet/PCI II 79C970A" ?

Any advice would be useful...

Thanks in advance for any help, and apologies about the size of
this message.

-- 
Dave Garry
===========================================================================
This Mail was sent to netboot mailing list by:
Dave Garry <daveg@pavilion.co.uk>
To get help about this list, send a mail with 'help' as the only string in
it's body to majordomo@baghira.han.de. If you have problems with this list,
send a mail to netboot-owner@baghira.han.de.