Sporadic eepro(10) RX problems after reboot

Till Straumann <[email protected]> Thu, 21 Apr 2005 12:56:03 -0700

Newsgroups	gmane.network.etherboot.user,gmane.network.etherboot.devel
Message-ID	<[email protected]>

Hi.

This is about eepro [10 / 82595],  NOT eepro100.

Sporadically, after a reboot [Ctl-Alt-Del] etherboot would
not seem to receive any packets; TX worked OK (i.e., dhcp
reqs were seen on the wire).

Powering down for a few minutes remedied the problem.

It turns out that the RX buffer RAM was not initialized
and if eepro_poll found a leftover packet header there
it would get out of sync with the hardware.

Patch with detailed description attached.

NOTE: all versions of etherboot are affected

Regards
  -- Till Straumann

PS: I'm not a subscriber. CC me if there are any questions

eepro.diff (text/plain, 2.6 KB)

This patch fixes to problems:
 - delay after full reset too short (since full_reset is only used at
   shutdown this is normally not noticed. I had used full_reset elsewhere
   while tracking down the other problem described below and then stumbled
   over the insufficient delay issue).

 - RX buffer ram not initialized. If the 1st eepro_poll() finds a valid
   packet header there (leftover from a previous boot or OS) the driver
   software gets out of sync with the hardware resulting in a 'dead'
   etherboot.
   Three effects were observed:
	- garbage suggests there is no packet
      --> works OK
    - garbage suggests there is a packet but the header is invalid
      --> 1st poll rejects the packet; 1st dhcp/bootp anwer/response
          fails. Only the second (incurring backoff delay) succeeds.
    - garbage is a valid packet header (e.g. leftover after hitting reset)
      --> etherboot hangs; network seems to be dead. Power-cycle with
          power-off time long enough to scramble RAM is needed)

To Apply this patch, chdir to the etherboot top directory and issue

    patch -p1 < [this_file]

NOTES: 
  - It is always a good idea to try '--dry-run' first.
  - Patch recommended for all older versions of etherboot, too.
    Since the directory structure changed, you have to 
     
          chdir <directory holding eepro.c>
          patch -p4 < [this file]

Author: Till Straumann, <straumanATslacDOTstanfordDOTedu>
        4/20/2005

*** etherboot-5.4.0/src/drivers/net/eepro.c.orig	2005-04-21 12:19:56.000000000 -0700
--- etherboot-5.4.0/src/drivers/net/eepro.c	2005-04-21 12:31:51.000000000 -0700
***************
*** 259,266 ****
  #define eeprom_delay() { udelay(40); }
  #define EE_READ_CMD (6 << 6)
  
! /* do a full reset */
! #define eepro_full_reset(ioaddr)	outb(RESET_CMD, ioaddr); udelay(40);
  
  /* do a nice reset */
  #define eepro_sel_reset(ioaddr) 	{ \
--- 259,266 ----
  #define eeprom_delay() { udelay(40); }
  #define EE_READ_CMD (6 << 6)
  
! /* do a full reset; data sheet asks for 250us delay */
! #define eepro_full_reset(ioaddr)	outb(RESET_CMD, ioaddr); udelay(255);
  
  /* do a nice reset */
  #define eepro_sel_reset(ioaddr) 	{ \
***************
*** 328,333 ****
--- 328,336 ----
  	rx_start = (unsigned int)bus_to_virt(RCV_LOWER_LIMIT << 8);
  	outw(RCV_LOWER_LIMIT << 8, ioaddr + RCV_BAR);
  	outw(((RCV_UPPER_LIMIT << 8) | 0xFE), ioaddr + RCV_STOP);
+ 	/* Make sure 1st poll won't find a valid packet header */
+ 	outw((RCV_LOWER_LIMIT << 8), ioaddr + HOST_ADDRESS_REG);
+ 	outw(0,                      ioaddr + IO_PORT);
  	/* Intialise XMT */
  	outw((XMT_LOWER_LIMIT << 8), ioaddr + xmt_bar);
  	eepro_sel_reset(ioaddr);