SiS 190/191 on ASUS P5SD2-VM dont detect link status / dont send traffic
I have a motherboard ASUS P5SD2-VM (E3464) with SIS968 chipset and SIS190/191 10/100 ethernet controler. Using ubuntu 8.04.1-server (kernel 2.6.24-9) this device is found by kernel but dont send trafic.
Clables and connections are checked and orange led indicating 100Mbps are on.
What to do? it´s a problem with some configuration or is a driver problem?
more information:
uname -a
Linux ubuntu 2.6.24-19-server #1 SMP Wed Jun 18 15:18:00 UTC 2008 i686 GNU/Linux
modproble sis190 && dmes | tail -n 11
[ 259.833889] sis190: no version for "struct_module" found: kernel tainted.
[ 259.834785] sis190 Gigabit Ethernet driver 1.2 loaded.
[ 259.834823] ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 19 (level, low) -> IRQ 21
[ 259.834837] PCI: Setting latency timer of device 0000:00:04.0 to 64
[ 259.834846] 0000:00:04.0: Read MAC address from EEPROM
[ 259.834847] 0000:00:04.0: Error EEPROM read 0.
[ 259.834850] 0000:00:04.0: Read MAC address from APC.
[ 259.952632] 0000:00:04.0: Unknown PHY trans at address 0x1 phy->id[0]= 0x4d phy->id[1]=0xd021.
[ 261.310970] 0000:00:04.0: SiS 191 PCI Gigabit Ethernet adapter at f920ac00 (IRQ: 21), 00:1e:8c:a9:f9:9d
[ 261.310974] eth0: GMII mode.
[ 261.310977] eth0: Enabling Auto-negotiation.
/sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:1e:8c:a9:f9:9d
inet addr:xxx.
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:300 (300.0 B) TX bytes:0 (0.0 B)
note: pc recieves packets but dont send.
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Current message level: 0x00000037 (55)
Link detected: no
note: Link detected: no
lshw -C network
*-network:0
description: Ethernet interface
product: 191 Gigabit Ethernet Adapter
vendor: Silicon Integrated Systems [SiS]
physical id: 4
bus info: pci@0000:00:04.0
logical name: eth0
version: 02
serial: 00:1e:8c:a9:f9:9d
size: 100MB/s
capacity: 100MB/s
width: 32 bits
clock: 33MHz
mii-diag eth0 --force
Basic registers of MII PHY #0: ffff ffff ffff ffff ffff ffff ffff ffff.
No MII transceiver present!.
The autonegotiated capability is 03e0.
The autonegotiated media type is 100baseTx-FD.
Basic mode control register 0xffff: Auto-negotiation enabled.
Internal Collision-Test enabled!
Restarted auto-negotiation in progress!
Transceiver isolated from the MII!
Transceiver powered down!
Transceiver in loopback mode!
Transceiver currently being reset!
Basic mode status register 0xffff ... ffff.
Link status: established.
Remote fault detected!
*** Link Jabber! ***
Your link partner advertised ffff: Flow-control 100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
End of basic transceiver information.
Question information
- Language:
- English Edit question
- Status:
- Answered
- Assignee:
- No assignee Edit question
- Last query:
- 2008-07-24
- Last reply:
- 2010-11-09
| NixMan (kobusvdb) said : | #1 |
Ditto Leadro !!! Identical problem to the very last detail.
Loaded SEVENTEEN brand new PC's [ASUS P5SD2-VM] for our local school's computer center with Ubuntu 8.04 LTS [2.6.24-16] & Edubuntu when we discovered the problem connecting them to the network & not getting any reply from DHCP server.
We have tried:
-- loaded one PC with WinXP with m/b drivers; works perfectly
-- built new sis190.ko from sources on security.
-- loaded ndiswrapper & WinXP drivers; still no joy
-- tried forcing various settings with ethtool, mii-diag & mii-tool, according to what WinXP properties show; still no joy as most fail to set.
-- changed cables & switch (to eliminate negotiation/sync issues) but still not working.
-- loaded other LiveCD distro's who also complain about "no link" error
What bothers us most is
RX bytes:300 (300.0 B) TX bytes:0 (0.0 B)
Transceiver isolated from the MII!
Transceiver powered down!
Have you found anything more?
Hy NixMan!
Your tests is like mine. I have tryed kernel 2.6.25, but its sis900.c is the same of 2.6.24. I´ve tried nidswraper too... and... dont work.
I´m not a kernel programmer, but I understand something about it. The kernel module dont reconize "power" status of network.
So, I will use a offboard network adapter until the kernel team correct this bug.
Some onde more?
| NixMan (kobusvdb) said : | #3 |
Hi Leandro,
U're lucky to be able to use an offboard adapter. Our boxes are brand new and 'sealed' for warranty purposes, so we can't do the same. Also adding 17 NICs to the cost is significant, so we won't even go there.
Something that is funny, though it doesn't solve the problem, is that when we recompiled sis190.ko from the .c sources & .config on the distro, it ends up being 'huge' some 211kB whereas the one 'out-of-the-box' is only some 26kB ???
Go figure that one ??? One would have expected them to be the same size since they are compiled from the same source !!! Makes one wonder if the .c was actually used for the distro .ko ??
We also read up extensively on the net, and tried various patches/mods suggested to the sis190.c source, but without any luck. Must say that much of the stuff on the net is very outdated (referring to code no longer in the C source file). We even tried the 'original' SiS file [from 2005] but couldn't get it to compile. [understandably].
Hope the kernel team gets to it real soon !!
| NixMan (kobusvdb) said : | #4 |
And the plot thickens even further !!!!
Got hold of a Mandriva 2008.0 DVD [2.6.22.
So, also having the source rpms on the DVD, we thought our problems with Ubuntu was solved !!! WROONNNGGG !!!
Using the sis190.c from the Mandriva DVD and compiling it on Ubuntu makes ABSOLUTELY NO difference.
So we thought the problem could be in mii.ko, but also using the source from the DVD and compiling it on Ubuntu also makes NO difference.
So Ubuntu 8.04 LTS seems a lot more 'broken' than what meets the eye !!!
With ethtool, we interestingly also noted that under Mandriva the interface is indicated as PHYAD : 1 while under Ubuntu it's shown as PHYAD : 0.
Seems like Ubuntu misidentifies and then IS trying to talk to a non-existent interface !!!
Hi Nixman!
Mr Herton Ronaldo, from Mandriva, answer a post on kernel bugzilla. He said that problem is on phy link change status. See:
http://
http://
I cant try it because my server is arealy in production.
Good look!
Leandro
| john zhang (zhangx) said : | #6 |
Got this help from somewhere online forum. Forgot where. But it solved the problem of sis191
LAN port problem on ASUS P5SD2-VM motherboard. This involves re-compile kernel module.
In file drivers\
{ "Atheros PHY AR8012", { 0x004d, 0xd020 }, LAN, 0 },
to mii_chip_table[], make it look like
static struct mii_chip_info {
const char *name;
u16 id[2];
unsigned int type;
u32 feature;
} mii_chip_table[] = {
{ "Atheros PHY AR8012", { 0x004d, 0xd020 }, LAN, 0 },
{ "Broadcom PHY BCM5461", { 0x0020, 0x60c0 }, LAN, F_PHY_BCM5461 },
{ "Broadcom PHY AC131", { 0x0143, 0xbc70 }, LAN, 0 },
{ "Agere PHY ET1101B", { 0x0282, 0xf010 }, LAN, 0 },
{ "Marvell PHY 88E1111", { 0x0141, 0x0cc0 }, LAN, F_PHY_88E1111 },
{ "Realtek PHY RTL8201", { 0x0000, 0x8200 }, LAN, 0 },
{ NULL, }
};
then re-compile it to sis190.ko. Copy this sis190.ko to /lib/modules/
This is tried on both kernel source version 2.6.24 and version 2.6.26. And they both worked.
| pablomme (pablomme) said : | #7 |
I can confirm the patch posted by John Zhang fixes the issue on another ASUS P5SD2-VM motherboard.
Is there a bug associated with this question? (why is this a question in the first place?) The patch should certainly make its way into the Ubuntu and upstream kernels.
| Alex Bennée (ajbennee) said : | #8 |
I've added a number of links to reported bugs in the Sis190 that all look similar to the problems noted here.
| Tiago Carrondo (tcarrondo) said : | #10 |
You need to change the mtu value.
I've had the same problem, the solution is simple:
# ifconfig eth0 mtu 1492
on natty (11.04) the adapter works but has issue on certain connections. i confirm that changing mtu value to 1492 fixes the problem. i think this bug is relevant: https:/
Can you help with this problem?
Provide an answer of your own, or ask Leandro Oliveira for more information if necessary.

