Distribution: Hardware Environment: Software Environment: Problem Description: Steps to reproduce: I have a motherboard ASUS P5SD2-VM (E3464) with SIS968 chipset and SIS190/191 10/100 ethernet controler. Using kernel 2.6.24-9 (ubuntu 8.04.1-server) 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.xxx.xxx.xxx Bcast:xxx.xxx.xxx.255 Mask:255.255.255.0 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 collisions:0 txqueuelen:1000 RX bytes:300 (300.0 B) TX bytes:0 (0.0 B) Interrupt:21 Base address:0xdead note: pc recieves packets but dont send. Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on 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 capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=sis190 driverversion=1.2 duplex=full ip=xxx.xxx.xxx.xxx latency=0 link=no module=sis190 multicast=yes port=MII speed=100MB/s 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.
Created attachment 16963 [details] patch to do polling for link status I have the same problem here, it's a sis190 with realtek phy in a Clevo notebook. Here hardware doesn't report LinkChange inside iterrupt handler, so I used the already present phy timer to do polling for link status.
I have a motherboard ASUS P5SD2-VM with SIS968 chipset and SIS190/191 10/100 ethernet controler. Using kernel 2.6.25.x - 2.6.26.2 (Plamo linux 4.5alpha) this device is found by kernel send trafic at sis190.c mii_chip_table 1 line insert. { "Atheros PHY AR8012", { 0x004d, 0xd020 }, LAN, 0 },
Created attachment 18069 [details] Patch for SiS191 LAN chip I've attached what nagura shouichi suggests, in patch form. The patch can be applied to 2.6.24 as well as 2.6.27 (and presumably anything in between), and I can confirm that this fixes the issue for another SiS 191 on an Asus P5SD2-VM motherboard.
The patch I posted here is for another bug then, by the bug description I thought it was the same, didn't paid attention for the "don't send traffic" part, my bad. The problem I experienced wasn't because of missing phy id like this ticket, but only a problem in link detection, for example not detecting removal of ethernet cable, network traffic always worked, while debugging I found the issue (LinkChange not reported inside interrupt handler) and posted the patch. Should I open a new ticket, is the patch good, is more info needed?
Are you sure its not just missing the PHY link as per https://answers.launchpad.net/ubuntu/+question/38994 I had the same problem on the same board, and patched the sis190.c file by adding a line: } mii_chip_table[] = { ++ { "Atheros PHY AR8012", { 0x004d, 0xd020 }, LAN, 0 }, { "Broadcom PHY BCM5461", { 0x0020, 0x60c0 }, LAN, F_PHY_BCM5461 }, Works perfectly now, detects link, etc... Havent tried the patch posted earlier... sounds dodgy, especially for "the worlds most advanced GbE PHY..."... Hopefully it's not just using the chip in a compatibility mode, but I can confirm that it transmits and detects link status on a 100mbit connection. Possibly duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=10994
The fix for http://bugzilla.kernel.org/show_bug.cgi?id=10994 went in mainline. Can somebody check if the bug still exists in 2.6.28-rc2 ? -- Ueimor
(In reply to comment #5) > Are you sure its not just missing the PHY link as per > https://answers.launchpad.net/ubuntu/+question/38994 Yes, sis190 here is using a realtek phy that is detected looking at kernel log, unrelated issue to this ticket. I opened a new one now: http://bugzilla.kernel.org/show_bug.cgi?id=11926
This bug has been split in two: The fix for http://bugzilla.kernel.org/show_bug.cgi?id=10994 went in mainline. (FIXED) http://bugzilla.kernel.org/show_bug.cgi?id=11926 (UNFIXED) FYI, Anybody free to confirm... ;)
Closing this as the two split bugs are sufficient now