| View previous topic :: View next topic |
| Author |
Message |
aminalshmu
Tux's lil' helper
Joined: 13 Sep 2004
Posts: 78
Location: TX, USA
|
 Posted: Fri Aug 22, 2008 4:44 pm Post subject: realtek - two lspci-listed drivers don't work-r8169,8139too |
 |
|
from lspci -v:
| Code: | 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8129 (rev 01)
Subsystem: Coreco Inc Device 8129
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at be00 [size=256]
Memory at fdaff000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at fd900000 [disabled] [size=8K]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data <?>
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable-
Capabilities: [60] Express Endpoint, MSI 00
Capabilities: [84] Vendor Specific Information <?>
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [12c] Virtual Channel <?>
Capabilities: [148] Device Serial Number 19-08-74-19-27-03-76-19
Capabilities: [154] Power Budgeting <?>
Kernel driver in use: 8139too
Kernel modules: r8169, 8139too |
| Code: | jordan@jordan ~ $ sudo modprobe r8169
jordan@jordan ~ $ dmesg | tail
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:01:00.0 to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 173.14.12 Thu Jul 17 18:10:24 PDT 2008
EXT3 FS on sda2, internal journal
NTFS volume version 3.1.
Adding 2562356k swap on /dev/sdb2. Priority:-1 extents:1 across:2562356k
r8169 Gigabit Ethernet driver 2.2LK loaded
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
r8169 0000:03:00.0: region #1 not an MMIO resource, aborting
ACPI: PCI interrupt for device 0000:03:00.0 disabled |
| Code: | jordan@jordan ~ $ sudo modprobe 8139too
jordan@jordan ~ $ dmesg | tail
ACPI: PCI interrupt for device 0000:03:00.0 disabled
8139too Fast Ethernet driver 0.9.28
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:03:00.0 to 64
8139too 0000:03:00.0: unknown chip version, assuming RTL-8139
8139too 0000:03:00.0: TxConfig = 0xbb500600
eth0: RealTek RTL8129 at 0xbe00, 00:1c:25:e1:60:61, IRQ 17
eth0: Identified 8139 chip type 'RTL-8139'
eth0: No MII transceivers found! Assuming SYM transceiver.
eth0: link down |
eth0 only shows up after i modprobe 8139too, even though the adapter is really an onboard realtek 8169(?) or 8111c(?) gigabit on a new foxconn 45gmx mobo, which works flawlessly after updating the drivers in vista64 at 10/100/1000 (i'm assuming... router only supports 100).
| Code: | <M> RealTek RTL-8129/8130/8139 PCI Fast Ethernet Adapter support
[*] Use PIO instead of MMIO
[*] Support for older RTL-8129/8130 boards |
i have to enable these options in the kernel module just to get it to create eth0, but then i get the whole "link down" thing... i've tried playing with ethtool and mii-tool with minimal success... i seem to be unable to change any options:
| Code: | jordan@jordan ~ $ sudo ethtool eth0
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
Advertised auto-negotiation: No
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: no |
| Code: | jordan@jordan ~ $ sudo mii-tool -vv
Using SIOCGMIIPHY=0x8947
eth0: 10 Mbit, half duplex, no link
registers for MII PHY 32:
0000 fd02 0000 0000 0e31 20be 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
product info: vendor 00:00:00, model 0 rev 0
basic mode: 10 Mbit, half duplex
basic status: no link
capabilities: 100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseT4 10baseT-HD flow-control
link partner: 100baseTx-HD 10baseT-HD |
additionally, if i remove the 8139too module, i get a hard lockup after about 30 seconds every time. any ideas? |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Fri Aug 22, 2008 4:51 pm Post subject: |
|
|
aminalshmu,
| Code: | | Realtek Semiconductor Co., Ltd. RTL-8129 |
This wants the 8139 driver with the | Code: | | Support for older RTL-8129/8130 boards (NEW) |
option enabled. You may want to try the Use PIO instead of MMIO (NEW) and Use older RX-reset method (NEW) too.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
aminalshmu
Tux's lil' helper
Joined: 13 Sep 2004
Posts: 78
Location: TX, USA
|
| Posted: Sat Aug 23, 2008 2:27 am Post subject: |
|
|
i have tried all the different combinations of options in the kernel for 8139too module... without "Use PIO instead of MMIO (NEW)" i get this:
| Code: | 8139too Fast Ethernet driver 0.9.28
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
8139too 0000:03:00.0: region #1 not an MMIO resource, aborting
Trying to free nonexistent resource <000000000000be00-000000000000beff>
Trying to free nonexistent resource <00000000fdaff000-00000000fdafffff> |
which is basically the same as when i try to load the r8169 driver ("region #1 not an MMIO resource, aborting")
does not crash when i unload the module when compiled without this option - but also does not create eth0.
| Code: | jordan@jordan ~ $ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:1c:25:e1:60:61
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:4336233 dropped:0 overruns:0 frame:6
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:17 Base address:0xbe00 |
the errors keep piling up, and the link is still down - is there some way i can find out exactly what is going on here? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Sat Aug 23, 2008 11:41 am Post subject: |
|
|
aminalshmu,
hmm, maybe the lspci database is incorrect for your device.
Google shows that a lot of users have been having problems and I not seen any solutions.
What does lspci -n show for device that will be the vendor and device IDs
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
cwr
Veteran
Joined: 17 Dec 2005
Posts: 1969
|
| Posted: Sat Aug 23, 2008 2:30 pm Post subject: |
|
|
I had a problem with this driver on a new Asus motherboard, dual-booting with
Windows - the story is that Windows puts the hardware into a sleep state which
the Linux drivers can't handle. There's a setting (Wake on LAN?) in Windows
that allows you to change this, and then things work. The symptoms are no
symptoms, simply a dead network port on boot.
However, that assumes that the driver will actually compile, and I didn't have
any problems there; I got the latest from (?) Sourceforge, and compiled it
with ~x86.
Will |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Sat Aug 23, 2008 2:57 pm Post subject: |
|
|
cwr,
That feature only manifests itself if you attempt to switch from windows to linux without powering off.
For a sure way to test. Power the machine down and remove the power cord for a minute or two, so that the 5vSTB decays.
You may have a motherboard LED that indicates 5vSTBY being alive.
Now boot into Linux directly. If the card works, its this deep sleep issue.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
aminalshmu
Tux's lil' helper
Joined: 13 Sep 2004
Posts: 78
Location: TX, USA
|
| Posted: Sun Aug 24, 2008 4:23 am Post subject: |
|
|
lspci -nn:
| Code: | | 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8129 [10ec:8129] (rev 01) |
wake on lan is not the issue, that setting has been "enabled" in vista ever since I first checked after seeing that it was such a common problem.
even after powering down, removing the cord, pressing the power button, etc. the green light will come on when i boot into linux or windows... only windows will detect the link, however...
some (possibly) relevant dmesg:
| Code: | ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:04:02.0 to 64
ndiswrapper version 1.53 loaded (smp=yes, preempt=no)
ndiswrapper (link_pe_images:575): fixing KI_USER_SHARED_DATA address in the driver
ndiswrapper: driver netmw126 (Marvell,12/30/2005,3.2.3.2) loaded
ACPI: PCI Interrupt 0000:04:01.0[A] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:04:01.0 to 64
ndiswrapper: using IRQ 22
wlan0: ethernet device 08:10:74:16:ef:23 using NDIS driver: netmw126, version: 0x3020007, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 11AB:1FAA.5.conf
wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:01:00.0 to 64
8139too: Unknown symbol mii_ethtool_sset
8139too: Unknown symbol mii_link_ok
8139too: Unknown symbol mii_check_media
8139too: Unknown symbol mii_nway_restart
8139too: Unknown symbol generic_mii_ioctl
8139too: Unknown symbol mii_ethtool_gset
8139too: Unknown symbol mii_ethtool_sset
8139too: Unknown symbol mii_link_ok
8139too: Unknown symbol mii_check_media
8139too: Unknown symbol mii_nway_restart
8139too: Unknown symbol generic_mii_ioctl
8139too: Unknown symbol mii_ethtool_gset
8139too: Unknown symbol mii_ethtool_sset
8139too: Unknown symbol mii_link_ok
8139too: Unknown symbol mii_check_media
8139too: Unknown symbol mii_nway_restart
8139too: Unknown symbol generic_mii_ioctl
8139too: Unknown symbol mii_ethtool_gset
8139too Fast Ethernet driver 0.9.28
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:03:00.0 to 64
8139too 0000:03:00.0: unknown chip version, assuming RTL-8139
8139too 0000:03:00.0: TxConfig = 0xbb500600
eth0: RealTek RTL8129 at 0xbe00, 00:1c:25:e1:60:61, IRQ 17
eth0: Identified 8139 chip type 'RTL-8139'
eth0: No MII transceivers found! Assuming SYM transceiver.
eth0: Media type forced to Full Duplex.
Forcing 10Mbps half-duplex operation.
NETDEV WATCHDOG: eth0: transmit timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:222 dev_watchdog+0x113/0x130()
Modules linked in: 8139too mii nvidia(P) ndiswrapper snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_util_mem snd_hwdep
Pid: 0, comm: swapper Tainted: P 2.6.26-gentoo-r1 #75
Call Trace:
<IRQ> [<ffffffff802350a4>] warn_on_slowpath+0x64/0xc0
[<ffffffff804e43f5>] printk+0x4e/0x59
[<ffffffff8023fdba>] __mod_timer+0xaa/0xc0
[<ffffffff803fedc0>] rh_timer_func+0x0/0x10
[<ffffffff803fe765>] usb_hcd_poll_rh_status+0x125/0x160
[<ffffffff80490ab0>] dev_watchdog+0x0/0x130
[<ffffffff80490bc3>] dev_watchdog+0x113/0x130
[<ffffffff8023f4be>] run_timer_softirq+0x12e/0x200
[<ffffffff8024ebcc>] ktime_get+0xc/0x50
[<ffffffff8023b09a>] __do_softirq+0x7a/0xf0
[<ffffffff8020c8dc>] call_softirq+0x1c/0x30
[<ffffffff8020e925>] do_softirq+0x35/0x70
[<ffffffff8023ae55>] irq_exit+0x95/0xa0
[<ffffffff8021dd7d>] smp_apic_timer_interrupt+0x7d/0xc0
[<ffffffff80213250>] mwait_idle+0x0/0x50
[<ffffffff8020c386>] apic_timer_interrupt+0x66/0x70
<EOI> [<ffffffff80209410>] default_idle+0x0/0x50
[<ffffffff8021d700>] lapic_next_event+0x0/0x10
[<ffffffff8021328c>] mwait_idle+0x3c/0x50
[<ffffffff8020a728>] cpu_idle+0x68/0xe0
---[ end trace 5fa68e69b880e1b8 ]---
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 0c 0000 c07f media 00.
eth0: Tx queue start entry 4 dirty entry 0.
eth0: Tx descriptor 0 is 00080140. (queue head)
eth0: Tx descriptor 1 is 00080156.
eth0: Tx descriptor 2 is 00080156.
eth0: Tx descriptor 3 is 00080156.
eth0: Setting full-duplex based on MII #32 link partner ability of f068.
eth0: Setting full-duplex based on MII #32 link partner ability of f068.
eth0: Setting full-duplex based on MII #32 link partner ability of f068. |
| Code: | jordan@jordan /usr/src/linux $ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:1c:25:e1:60:61
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:25
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:17 Base address:0xbe00
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:44 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2200 (2.1 KiB) TX bytes:2200 (2.1 KiB)
wlan0 Link encap:Ethernet HWaddr 08:10:74:16:ef:23
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2042 errors:0 dropped:0 overruns:0 frame:0
TX packets:2171 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1799230 (1.7 MiB) TX bytes:470876 (459.8 KiB)
Interrupt:22 Memory:fddd0000-fdde0000
jordan@jordan /usr/src/linux $ sudo ethtool eth0
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: Not reported
Advertised auto-negotiation: No
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000001 (1)
Link detected: no
jordan@jordan /usr/src/linux $ sudo mii-tool -vv
Using SIOCGMIIPHY=0x8947
eth0: 10 Mbit, half duplex, no link
registers for MII PHY 32:
8000 5810 0000 0000 0010 f068 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
product info: vendor 00:00:00, model 0 rev 0
basic mode: software reset, 10 Mbit, half duplex
basic status: remote fault, no link
capabilities: 100baseTx-FD 10baseT-FD 10baseT-HD
advertising:
link partner: 10baseT-FD 10baseT-HD
jordan@jordan /usr/src/linux $ sudo /etc/init.d/net.eth0 restart
net.eth0 | * Bringing up interface eth0
net.eth0 | * No configuration specified; defaulting to DHCP
net.eth0 | * dhcp ...
net.eth0 | * Running dhcpcd ...
net.eth0 |eth0: dhcpcd 4.0.0-rc5 starting
net.eth0 |eth0: waiting for carrier
net.eth0 |eth0: timed out [ !! ]
net.eth0 | * ERROR: net.eth0 failed to start |
the good news is, my rosewill pci wireless card works flawlessly with ndiswrapper...
still wish i knew what was up with this onboard NIC though. windows doesn't have a problem with it, so why should gentoo?  |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Sun Aug 24, 2008 3:09 pm Post subject: |
|
|
aminalshmu,
| Code: | 8139too: Unknown symbol mii_ethtool_sset
8139too: Unknown symbol mii_link_ok |
is very relevant.
It says that the 8139too module, which should work for you, needs another kernel option turned on.
Check your | Code: | │ │ --- Ethernet (10 or 100Mbit) │ │
│ │ {M} Generic Media Independent Interface device support |
setting
The {M} means its been forced on by another setting. That option provides all the mii symbols you are missing.
Have you ever edited the kernel .config with a text editor?
Thats a strict nono as some menuconfig options control 3 or 4 kernel flags and inconsistent settings produce some very strange hard to diagnose problems.
Did you take the .config file from another kernel and omit make oldconfig ?
That produces strange hard to diagnose problems too, as some kernel options will not be set at all.
If everything looks good, rebuild your kernel anyway but start with make clean, so you know all the parts of the kernel were made at a sinle pass. make clean will not harm your .config file.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
cwr
Veteran
Joined: 17 Dec 2005
Posts: 1969
|
| Posted: Sun Aug 24, 2008 5:38 pm Post subject: |
|
|
| NeddySeagoon wrote: | cwr,
That feature only manifests itself if you attempt to switch from windows to linux without powering off.
For a sure way to test. Power the machine down and remove the power cord for a minute or two, so that the 5vSTB decays.
You may have a motherboard LED that indicates 5vSTBY being alive.
Now boot into Linux directly. If the card works, its this deep sleep issue. |
Yes, that's how I know what the problem was. However, when installing it was a real pain as you couldn't power the
machine off completely _without_ removing the cable, and it took me a while to realise that windows had put an odd
setup on the chip.
Will |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
