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.