You are not logged in.
Pages: 1
I've bought a VIA M'SERV s2100 mini server to use as NAS. I've had a QNAP before, but I could not do with the machine what I wanted, so a real pc with the lovely Archlinux seemed the best option.
While the installation went smooth, after a few hours after the installation when I was configuring the machine, I got problems with the network connectivity. Sometimes, I loose network connection because of "failed to detect cable link". Let me show you certain logfiles etc.
First I noticed that dmesg got flooded with messages about the via velocity driver:
[162436.977121] via-velocity 0000:03:00.0: BAR 0: set to [io 0xdc00-0xdcff] (PCI address [0xdc00-0xdcff])
[162436.977139] via-velocity 0000:03:00.0: BAR 1: set to [mem 0xdfdff000-0xdfdff0ff 64bit] (PCI address [0xdfdff000-0xdfdff0ff])
[162439.977118] via-velocity 0000:03:00.0: BAR 0: set to [io 0xdc00-0xdcff] (PCI address [0xdc00-0xdcff])
[162439.977136] via-velocity 0000:03:00.0: BAR 1: set to [mem 0xdfdff000-0xdfdff0ff 64bit] (PCI address [0xdfdff000-0xdfdff0ff])
[162442.980454] via-velocity 0000:03:00.0: BAR 0: set to [io 0xdc00-0xdcff] (PCI address [0xdc00-0xdcff])
[162442.980471] via-velocity 0000:03:00.0: BAR 1: set to [mem 0xdfdff000-0xdfdff0ff 64bit] (PCI address [0xdfdff000-0xdfdff0ff])This repeats every let's say one second, the whole time. However, as soon as both links are up (in this case eth1 is down), the messaging stops. An lspci -v shows following:
02:00.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 82)
Subsystem: VIA Technologies, Inc. Device 0110
Flags: bus master, fast devsel, latency 0, IRQ 28
I/O ports at ec00 [size=256]
Memory at df7ff000 (64-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 3
Capabilities: [90] Express Endpoint, MSI 00
Capabilities: [c0] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [100] Advanced Error Reporting
Capabilities: [130] Device Serial Number b0-d8-00-ff-ff-f2-1f-00
Kernel driver in use: via-velocity
Kernel modules: via-velocity
03:00.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 82)
Subsystem: VIA Technologies, Inc. Device 0110
Flags: bus master, fast devsel, latency 0, IRQ 36
I/O ports at dc00 [size=256]
Memory at dfdff000 (64-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 3
Capabilities: [90] Express Endpoint, MSI 00
Capabilities: [c0] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [100] Advanced Error Reporting
Capabilities: [130] Device Serial Number b3-d8-00-ff-ff-f2-1f-00
Kernel driver in use: via-velocity
Kernel modules: via-velocityAfter aquiring an ip by dhcp on eth0 and manualy bringing eth1 up to stop the messageflood, this shows up on ifconfig:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1
inet 10.3.26.2 netmask 255.255.0.0 broadcast 10.3.255.255
inet6 fe80::21f:f2ff:fe00:d8b0 prefixlen 64 scopeid 0x20<link>
ether 00:1f:f2:00:d8:b0 txqueuelen 1000 (Ethernet)
RX packets 2158 bytes 441593 (431.2 KiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 2849 bytes 692765 (676.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 28 base 0xec00
eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 metric 1
ether 00:1f:f2:00:d8:b3 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 36 base 0xdc00 Info about the via_velocity module shows:
filename: /lib/modules/3.2.0-2-ARCH/kernel/drivers/net/ethernet/via/via-velocity.ko.gz
description: VIA Networking Velocity Family Gigabit Ethernet Adapter Driver
license: GPL
author: VIA Networking Technologies, Inc.
alias: pci:v00001106d00003119sv*sd*bc*sc*i*
depends: crc-ccitt
intree: Y
vermagic: 3.2.0-2-ARCH SMP preempt mod_unload modversions
parm: RxDescriptors:Number of receive descriptors (array of int)
parm: TxDescriptors:Number of transmit descriptors (array of int)
parm: rx_thresh:Receive fifo threshold (array of int)
parm: DMA_length:DMA length (array of int)
parm: IP_byte_align:Enable IP header dword aligned (array of int)
parm: flow_control:Enable flow control ability (array of int)
parm: speed_duplex:Setting the speed and duplex mode (array of int)
parm: ValPktLen:Receiving or Drop invalid 802.3 frame (array of int)
parm: wol_opts:Wake On Lan options (array of int)
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)As you notice, I'm using a kernel from testing. I've tried installing kernel26-lts and it didn't help. Upgrading to a newer kernel didn't help either. And for now, I just kept the testing kernel.
Linux angara 3.2.0-2-ARCH #1 SMP PREEMPT Sat Jan 7 14:27:58 CET 2012 x86_64 VIA Nano processor U2250 (1.6GHz Capable) CentaurHauls GNU/LinuxLet me show the contents of /var/log/messages.log. It shows what is going wrong:
Jan 16 23:12:36 localhost dhcpcd[27829]: eth0: carrier lost
Jan 16 23:12:36 localhost kernel: [135679.413268] eth0: failed to detect cable link
Jan 16 23:12:42 localhost dhcpcd[27829]: eth0: carrier acquired
Jan 16 23:12:42 localhost kernel: [135685.251775] eth0: Link auto-negotiation speed 1000M bps full duplex
Jan 16 23:12:42 localhost dhcpcd[27829]: eth0: rebinding lease of 10.3.26.2
Jan 16 23:12:42 localhost dhcpcd[27829]: eth0: acknowledged 10.3.26.2 from 10.3.25.1
Jan 16 23:12:42 localhost dhcpcd[27829]: eth0: checking for 10.3.26.2
Jan 16 23:12:47 localhost dhcpcd[27829]: eth0: leased 10.3.26.2 for 86400 seconds
Jan 16 23:13:37 localhost kernel: [135739.858038] eth0: failed to detect cable link
Jan 16 23:13:37 localhost dhcpcd[27829]: eth0: carrier lost
Jan 16 23:13:39 localhost dhcpcd[27829]: eth0: carrier acquired
Jan 16 23:13:39 localhost kernel: [135742.638302] eth0: Link auto-negotiation speed 1000M bps full duplex
Jan 16 23:13:39 localhost dhcpcd[27829]: eth0: rebinding lease of 10.3.26.2
Jan 16 23:13:39 localhost dhcpcd[27829]: eth0: acknowledged 10.3.26.2 from 10.3.25.1
Jan 16 23:13:39 localhost dhcpcd[27829]: eth0: checking for 10.3.26.2
Jan 16 23:13:44 localhost dhcpcd[27829]: eth0: leased 10.3.26.2 for 86400 seconds
Jan 16 23:13:49 localhost dhcpcd[27829]: eth0: carrier lost
Jan 16 23:13:49 localhost kernel: [135752.649786] eth0: failed to detect cable link
Jan 16 23:13:52 localhost kernel: [135754.995886] eth0: Link auto-negotiation speed 1000M bps full duplex
Jan 16 23:13:52 localhost dhcpcd[27829]: eth0: carrier acquired
Jan 16 23:13:52 localhost dhcpcd[27829]: eth0: rebinding lease of 10.3.26.2
Jan 16 23:13:52 localhost dhcpcd[27829]: eth0: acknowledged 10.3.26.2 from 10.3.25.1
Jan 16 23:13:52 localhost dhcpcd[27829]: eth0: checking for 10.3.26.2
Jan 16 23:13:56 localhost dhcpcd[27829]: eth0: leased 10.3.26.2 for 86400 seconds
Jan 16 23:15:08 localhost kernel: [135831.214499] eth0: failed to detect cable link
Jan 16 23:15:08 localhost dhcpcd[27829]: eth0: carrier lost
Jan 16 23:15:10 localhost dhcpcd[27829]: eth0: carrier acquired
Jan 16 23:15:10 localhost kernel: [135833.538036] eth0: Link auto-negotiation speed 1000M bps full duplex
Jan 16 23:15:10 localhost dhcpcd[27829]: eth0: rebinding lease of 10.3.26.2
Jan 16 23:15:10 localhost dhcpcd[27829]: eth0: acknowledged 10.3.26.2 from 10.3.25.1
Jan 16 23:15:10 localhost dhcpcd[27829]: eth0: checking for 10.3.26.2
Jan 16 23:15:15 localhost kernel: [135837.829155] eth0: failed to detect cable link
Jan 16 23:15:15 localhost dhcpcd[27829]: eth0: carrier lostAfter the last carrier lost, the LEDs on the NIC went out, and the link never came back again. This however, can keep going a few hours as well. Sometimes, after the NIC got it's IP back, it can run just fine for a few days, and then suddenly, this issue comes back.
I've written a small script that seems to "reset" all this, and gets my network up and running again, but one doesn't know for how long. After the script, it can keep running for days, for hours or just a few minutes. The NAS is usually located next to my cable modem somewhere hidden, so I don't have a screen. With this script, I can just plug in a keyboard, run the script, and after a few seconds, I can ssh to the machine again (for now).
#!/bin/sh
ifconfig eth1 down
ifconfig eth0 down
rmmod via_velocity
rmmod crc-ccitt
modprobe crc-ccitt
modprobe via_velocity
ifconfig eth1 up
ifconfig eth0 up
dhcpcd eth0Jan 17 06:34:45 localhost dhcpcd[27829]: eth0: removing interface
Jan 17 06:34:45 localhost kernel: [162208.817765] eth0: VIA Networking Velocity Family Gigabit Ethernet Adapter
Jan 17 06:34:45 localhost kernel: [162208.817775] eth0: Ethernet Address: 00:1f:f2:00:d8:b0
Jan 17 06:34:46 localhost kernel: [162208.927698] eth1: VIA Networking Velocity Family Gigabit Ethernet Adapter
Jan 17 06:34:46 localhost kernel: [162208.927705] eth1: Ethernet Address: 00:1f:f2:00:d8:b3
Jan 17 06:34:46 localhost kernel: [162208.967349] ADDRCONF(NETDEV_UP): eth1: link is not ready
Jan 17 06:34:46 localhost kernel: [162208.994023] ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 17 06:34:46 localhost dhcpcd[31895]: eth0: waiting for carrier
Jan 17 06:34:48 localhost dhcpcd[31895]: eth0: carrier acquired
Jan 17 06:34:48 localhost kernel: [162211.380606] eth0: Link auto-negotiation speed 1000M bps full duplex
Jan 17 06:34:48 localhost kernel: [162211.381687] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jan 17 06:34:48 localhost dhcpcd[31895]: eth0: rebinding lease of 10.3.26.2
Jan 17 06:34:48 localhost dhcpcd[31895]: eth0: acknowledged 10.3.26.2 from 10.3.25.1
Jan 17 06:34:48 localhost dhcpcd[31895]: eth0: checking for 10.3.26.2
Jan 17 06:34:54 localhost dhcpcd[31895]: eth0: leased 10.3.26.2 for 86400 secondsI hope somebody can help me out? It's a very compact case, so I can't just add a new NIC that might work.
Offline
In the meantime, I've installed the old kernel26-lts again and compiled the latest velocityget module that I downloaded from the via site against the kernel. However, this changed nothing; the behavior kept going. Afterwards, I reverted back to the stable stock kernel (3.1.9-2 as we speak).
I'm now testing with a swtich in between the NAS and the router, in case it would be the router that breaks the link and is messing with the auto negotiation. In that case, I assume the connection between switch and router would be faulty, and the connection between NAS and switch would stay up and running. If the connection to the machine goes down again, but I can't see carrier lost messages on the NAS, it might be the router after all.
Offline
Pages: 1