Subject: Re: kern/33651: bge doesn't work after reboot from windows until
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Chris Tribo <ctribo@dtcc.edu>
List: netbsd-bugs
Date: 10/04/2006 01:05:02
The following reply was made to PR kern/33651; it has been noted by GNATS.

From: Chris Tribo <ctribo@dtcc.edu>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/33651: bge doesn't work after reboot from windows until
 it is PXE booted
Date: Tue, 03 Oct 2006 21:03:32 -0400

 According to the FreeBSD bge driver commit logs, this problem has been 
 fixed in their version. They point out two problems:
 
 1. - We're not properly resetting the chip and in the case where 
 PXE/UNDI/RPL or other boot agent is enabled, the chip is coming back 
 with the PXE/UNDI stack loaded and not ready for operation. Their fix is 
 to write a magic code to the mailbox which tells the chip not to load 
 the netboot stack on reset.
 
 We already have code to do this but it doesn't appear to me that it is 
 being written before bge_reset is being called subsequent to the initial 
 attachment (I am probably mistaken):
 
          /*
           * Prevent PXE restart: write a magic number to the
           * general communications memory at 0xB50.
           */
          bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER);
 
 The FreeBSD driver has this immediately before resetting the chip. This 
 is supposed to fix the firmware handshake failed message on some chips.
 
 
 2. - Insufficient locking to prevent concurrent PHY access. Which they 
 view as being the root cause of some of the problems I'm seeing:
 
 - Packets don't TX when autonegotiation is not present and media has not 
 been forced
 - block failed to stop errors
 - watchdog timeout errors
 
 I've previously confirmed that on a hub with no autonegotiate, packets 
 will not TX if the phy is set to auto, you have to force the speed and 
 duplex even though the phy reports the correct speed was detected and 
 selected.