Skip to contentSkip to conversation

sis900 Foxconn 661FX7MI-S PHY support

PATCH In review James Cameron 2 participants 2 messages May 10, 2006 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sis900 Foxconn 661FX7MI-S PHY support

This patch is required to get sis900 ethernet working well on a Foxconn 661FX7MI-S motherboard which uses the SiS 661FX chipset. The patch adds an entry to mii_chip_info for the transceiver.

The PHY ids were found using the sis900_c_122.diff patch from
http://brownhat.org/sis900.html but that patch didn't solve the problem, because the PHY at address 1 was already being chosen.

Without my patch, when bursts of packets arrive from other hosts on a LAN, the interface dropped one roughly 10% of the time, causing retransmits. There were fifth second pauses in refresh of large xterms, and it made Netrek suck. I can provide further test data.

Workaround in lieu of patch is to use mii-tool to advertise 100baseTx-HD, then force renegotiation.

I wasn't able to identify the actual transceiver, so the description field is a guess.

This patch is similar to Artur Skawina's patch:
http://marc.theaimsgroup.com/?l=linux-netdev&m=114297516729079&w=2

I'm not sure, but I wonder if it means the default behaviour should be changed, so as to better handle future transceivers.

Diff is against 2.6.16.13.

sis900.c renamed from sis900.c.orig +1 -0
@@ -127,6 +127,7 @@
 } mii_chip_table[] = {
 	{ "SiS 900 Internal MII PHY", 		0x001d, 0x8000, LAN },
 	{ "SiS 7014 Physical Layer Solution", 	0x0016, 0xf830, LAN },
+	{ "SiS 900 on Foxconn 661 7MI",         0x0143, 0xBC70, LAN },
 	{ "Altimata AC101LF PHY",               0x0022, 0x5520, LAN },
 	{ "AMD 79C901 10BASE-T PHY",  		0x0000, 0x6B70, LAN },
 	{ "AMD 79C901 HomePNA PHY",		0x0000, 0x6B90, HOME},

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw

Il giorno 10/mag/06, alle ore 19:31, Stephen Hemminger ha scritto:

Quoted 4 lines · On Wed, 10 May 2006 10:04:50 +1000 James Cameron <[email protected]> wrote:
Quoted 3 lines

I'm not sure, but I wonder if it means the default behaviour should be changed, so as to better handle future transceivers.

Well, my previous experience showed that the current default was the best, but obviously, when I decided that, things began to change. Since it is quite easy to add new transceivers this is hardly a big problem.

Quoted 1 line

I am waiting for a fixed patch and ack from driver maintainer.

Ack. :-)

Thanks.
--
Daniele Venzano
http://www.brownhat.org