The SiS900 is an Ethernet chip commonly found on many integrated network interfaces. Many different manufacturers use the SiS900 on their motherboards, each one of them often has different set-ups for the accessory chips (i.e. PHY transceivers).
On these pages:
The following is a list of all the known bugs to the sis900 driver available in the 2.6 series of Linux kernel. Before asking for help it is wise to check with what’s written here. If a solution is not described, be patient, something will come out soon.
The sis900 chipset can be used with different transceivers of different brands, the driver knows about some of them, and should behave correctly even with an unknown transceiver. If you see during boot or in dmesg the following lines:
eth0: Unknown PHY transceiver found at address 0. eth0: Realtek RTL8201 PHY transceiver found at address 1. eth0: Unknown PHY transceiver found at address 2. <...> eth0: Unknown PHY transceiver found at address 31. eth0: Using transceiver found at address 31 as default
Then your PHY table is confusing the driver that is seeing 32 transceivers, only one known (at address 1) and is trying to use the last one detected, that is non existent in reality.
This issue is known and is fixed by the sis900-phy-detection patch (see the archived patches).
Another mutation of this problem happens when no known transceivers are detected. In this case the drivers always chooses the last detected (the 31st) because it can’t do anything better. In this case you should run with the sis900-list-phy-ids.diff (see below) and send me the output of dmesg. In most cases the patch should also provide a temporary fix.
Wake on Lan support
The patch available below adds support for the WoL feature of the sis900 hardware. It only works:
- on link status change
- using magic packets
- if you have hardware support for WoL
This new patch should solve all reported issues with the previous patches. If you don’t have hardware support (additional power supply for the sis900 chipset) a message in the boot logs should state so. The feature is controlled by ethtool and can be activated by link status change or magic packet receipt.
MTU problem with VLANs (8021q.o)
sis900 is broken when used together with VLANs as it doesn’t recognize correctly the MTU size of the passing packets. These two links, provided by Alex Reinhold, explain the problem in bigger detail:
A patch that fixes this is available below. It needs testing.
I have received a report where the driver would start to run into transmit timeouts after a few days of operations on a 2.6.24/25 kernel, 64bit. Inquires with the reporter led to no useful hints, so if you can reproduce this problem or have a working sis900, 64bit box, please contact me.
Warnings on module reload
A report with a 2.6.26-rc6-git3 kernel was received. The kernel would print a warning in dmesg during module unload/reload, but the driver would work fine afterwards. This seems a spurious problem in a development kernel, but additional reports are well accepted.
|sis900_check_mac.diff||Check if MAC address read form the hardware is invalid, generate a random one and warn the user. See Bugzilla ID 10201||2.6.28||I||None|
|802q.diff||Add support for VLANs (802.1q)||2.6.16||I||None|
|sis900_c_102.diff||More support for ethtool ops||2.6.11-bk7||I (2.6.12)||None|
|sis900-netpoll.diff||Netpoll/netconsole support||2.6.10||I (2.6.11-bk)||None|
|sis900_c_127.diff||Add support for Wake on Lan via Magic Packet and PHY activity||2.6.13||I (2.6.16)||None|
|sis900-phy-detection||Prints the PHY ids and force selection of PHY at address 1||2.6.12||N||None|
|sis900-maintainers.diff||Change of maintainership of sis900 driver||2.6.11||I (2.6.12-rc2)||None|
Meaning of the Status column:
- I: the patch got Included in Linus’ tree
- P: the patch is Pending review by some kernel guru
- KJ: Kernel Janitor patch (or set of patches)
- N: Not for inclusion
If you have a problem with your sis900 NIC that is not listed in the section above called known issues you should send a bug report to me and to the netdev mailing list. In this mail you must include:
- Full description of the problem
- Cut ‘n Paste of eventual error/warning messages
- output of dmesg