January 28, 201412 yr I then only copied bzroot and bzimage and not the .cfg file, and it worked fine. However, I've noticed that my server doesn't do the beeping sound anymore when I turn it off or on. So, I am thinking of doing a clean re-install to the latest UnRaid. I noticed when I upgraded to 5.0.4 that my server also stopped beeping. Were you able to fix this with a clean install or does anyone know if the beeping was disabled in 5.0.x?
January 29, 201412 yr I'm glad I saw this. Known issues in this release ---------------------------- - slack: the time setting "(UTC+10:00) Brisbane" is wrong: Brisbane does not use daylight savings time like (UTC+10:00) Camberra, Melbourne, Sydney. I'll be giving this one a miss until that's fixed just incase it causes issues.
January 29, 201412 yr I'm glad I saw this. Known issues in this release ---------------------------- - slack: the time setting "(UTC+10:00) Brisbane" is wrong: Brisbane does not use daylight savings time like (UTC+10:00) Camberra, Melbourne, Sydney. I'll be giving this one a miss until that's fixed just incase it causes issues. You could just move to Camberra (sic)!
January 29, 201412 yr I then only copied bzroot and bzimage and not the .cfg file, and it worked fine. However, I've noticed that my server doesn't do the beeping sound anymore when I turn it off or on. So, I am thinking of doing a clean re-install to the latest UnRaid. I noticed when I upgraded to 5.0.4 that my server also stopped beeping. Were you able to fix this with a clean install or does anyone know if the beeping was disabled in 5.0.x? I haven't been able to do the clean install. I've been waiting for my new USB flash drives to get here, which both of them just did.
January 29, 201412 yr I was having an issue with 5.0.4 where doing a new Parity update would cause the box to eventually hit over 120 in usage reports. The usage would go up, but never down. Upgraded to 5.0.5 and so far the issue appears to be gone. Will post more if it occurs again. Only been running about an hour with the new setup.
January 30, 201412 yr I just picked up a SM X9-scm-iif board with the same intel chipset dual lans. I disabled lan 1 and I am using lan 2 but I am noticing a lot of dropped RX packets in testing. I have read several of the posts here about it and as well there seems to be several bugs posted across the net with several workarounds. Tom, which e1000 driver are we currently using I noticed there is a 2.54 revision driver that a lot of bug posters have said seems to help. Anyone else seeing this on there intel based nics. Thanks, Dave
January 30, 201412 yr Author I just picked up a SM X9-scm-iif board with the same intel chipset dual lans. I disabled lan 1 and I am using lan 2 but I am noticing a lot of dropped RX packets in testing. I have read several of the posts here about it and as well there seems to be several bugs posted across the net with several workarounds. Tom, which e1000 driver are we currently using I noticed there is a 2.54 revision driver that a lot of bug posters have said seems to help. Anyone else seeing this on there intel based nics. Thanks, Dave I'll look into this for 5.0.6 release.
January 30, 201412 yr This was a known bug last I checked. According to e1000 linux driver authors below is latest driver. Their bug tracker seems as if it was resolved. e1000 driver: The e1000 driver is changed to a kernel only support model. (The latest release of e1000 driver was version 8.0.35)
January 31, 201412 yr I just picked up a SM X9-scm-iif board with the same intel chipset dual lans. I disabled lan 1 and I am using lan 2 but I am noticing a lot of dropped RX packets in testing. I have read several of the posts here about it and as well there seems to be several bugs posted across the net with several workarounds. Tom, which e1000 driver are we currently using I noticed there is a 2.54 revision driver that a lot of bug posters have said seems to help. Anyone else seeing this on there intel based nics. Thanks, Dave I'll look into this for 5.0.6 release. Would be good if it could be resolved - I'm sure that there must be some performance hit from the dropped packets.
January 31, 201412 yr I just picked up a SM X9-scm-iif board with the same intel chipset dual lans. I disabled lan 1 and I am using lan 2 but I am noticing a lot of dropped RX packets in testing. I have read several of the posts here about it and as well there seems to be several bugs posted across the net with several workarounds. Tom, which e1000 driver are we currently using I noticed there is a 2.54 revision driver that a lot of bug posters have said seems to help. Anyone else seeing this on there intel based nics. Thanks, Dave I'll look into this for 5.0.6 release. Would be good if it could be resolved - I'm sure that there must be some performance hit from the dropped packets. I agree, here is a LP thread I was following and comment 22 has a link to SF and what I thought that was the latest module. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018561 My machine is setup for testing right beside me and I have the network plugged into a 2nd 1GB switch and I am seeing a lot of idle activity even with all drives spun down. I saw 80K plus dropped errors on lan 1, so I disabled it and switched to lan 2 and it is much less 700-800 within 10-15 Minutes I copied about 50 gb of data in testing the backplanes and it has stayed around that number but my lan light on the case is pretty much on solid, I am not sure if ipmi heartbeat causing some of that but I would not think so since I have it set to dedicated port and not shared. Dave
January 31, 201412 yr I just picked up a SM X9-scm-iif board with the same intel chipset dual lans. I disabled lan 1 and I am using lan 2 but I am noticing a lot of dropped RX packets in testing. I have read several of the posts here about it and as well there seems to be several bugs posted across the net with several workarounds. Tom, which e1000 driver are we currently using I noticed there is a 2.54 revision driver that a lot of bug posters have said seems to help. Anyone else seeing this on there intel based nics. Thanks, Dave I'll look into this for 5.0.6 release. Would be good if it could be resolved - I'm sure that there must be some performance hit from the dropped packets. I agree, here is a LP thread I was following and comment 22 has a link to SF and what I thought that was the latest module. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018561 My machine is setup for testing right beside me and I have the network plugged into a 2nd 1GB switch and I am seeing a lot of idle activity even with all drives spun down. I saw 80K plus dropped errors on lan 1, so I disabled it and switched to lan 2 and it is much less 700-800 within 10-15 Minutes I copied about 50 gb of data in testing the backplanes and it has stayed around that number but my lan light on the case is pretty much on solid, I am not sure if ipmi heartbeat causing some of that but I would not think so since I have it set to dedicated port and not shared. Did you find my old comments on this subject? I found that if I added another Gb switch between unRAID and the rest of my network, the dropped packet count fell to near zero.
January 31, 201412 yr I just picked up a SM X9-scm-iif board with the same intel chipset dual lans. I disabled lan 1 and I am using lan 2 but I am noticing a lot of dropped RX packets in testing. I have read several of the posts here about it and as well there seems to be several bugs posted across the net with several workarounds. Tom, which e1000 driver are we currently using I noticed there is a 2.54 revision driver that a lot of bug posters have said seems to help. Anyone else seeing this on there intel based nics. Thanks, Dave I'll look into this for 5.0.6 release. Would be good if it could be resolved - I'm sure that there must be some performance hit from the dropped packets. I agree, here is a LP thread I was following and comment 22 has a link to SF and what I thought that was the latest module. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018561 My machine is setup for testing right beside me and I have the network plugged into a 2nd 1GB switch and I am seeing a lot of idle activity even with all drives spun down. I saw 80K plus dropped errors on lan 1, so I disabled it and switched to lan 2 and it is much less 700-800 within 10-15 Minutes I copied about 50 gb of data in testing the backplanes and it has stayed around that number but my lan light on the case is pretty much on solid, I am not sure if ipmi heartbeat causing some of that but I would not think so since I have it set to dedicated port and not shared. Did you find my old comments on this subject? I found that if I added another Gb switch between unRAID and the rest of my network, the dropped packet count fell to near zero. yes I did read through that thread and as many others as I could find here and abroad, that is how my lan is setup. I have a 24 port switch in the rack that all of my servers as well as the distributed panel wiring runs into and then in my office I have a 2nd 8 port gb switch that I have 2 machines, my network printer and I am plugged into it for testing. this is after about 48 hours since I last rebooted the machine. eth0 Link encap:Ethernet HWaddr 00:25:90:ad:6c:95 inet addr:192.168.1.59 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7811986 errors:0 dropped:2024 overruns:0 frame:0 TX packets:330295 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11805474817 (10.9 GiB) TX bytes:36832264 (35.1 MiB) Interrupt:19 Memory:df900000-df920000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:10 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:758 (758.0 B) TX bytes:758 (758.0 B) root@Tower:~# pete on another note, do you see any acpi (minor errors) in your syslog. I have one that I have trying to research although I can find several none of them have the same code as mine. Jan 30 07:23:43 Tower kernel: e1000e: Intel(R) PRO/1000 Network Driver - 2.2.14-k Jan 30 07:23:43 Tower kernel: e1000e: Copyright(c) 1999 - 2013 Intel Corporation. Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: Disabling ASPM L0s L1 Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: irq 40 for MSI/MSI-X Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: irq 41 for MSI/MSI-X Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: irq 42 for MSI/MSI-X Jan 30 07:23:43 Tower kernel: ACPI Warning: 0x00000580-0x0000059f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130117/utaddress-251) Jan 30 07:23:43 Tower kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
January 31, 201412 yr this is after about 48 hours since I last rebooted the machine. eth0 Link encap:Ethernet HWaddr 00:25:90:ad:6c:95 inet addr:192.168.1.59 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7811986 errors:0 dropped:2024 overruns:0 frame:0 TX packets:330295 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11805474817 (10.9 GiB) TX bytes:36832264 (35.1 MiB) Interrupt:19 Memory:df900000-df920000 Haha - that's nothing. Here are my stats (without the extra switch): eth0 Link encap:Ethernet HWaddr 00:25:90:a2:e7:92 inet addr:10.2.0.100 Bcast:10.2.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7389255 errors:0 dropped:5412643 overruns:0 frame:0 TX packets:13051290 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:595499869 (567.9 MiB) TX bytes:17852340618 (16.6 GiB) Interrupt:18 Memory:df700000-df720000 pete on another note, do you see any acpi (minor errors) in your syslog. I have one that I have trying to research although I can find several none of them have the same code as mine. Jan 30 07:23:43 Tower kernel: e1000e: Intel(R) PRO/1000 Network Driver - 2.2.14-k Jan 30 07:23:43 Tower kernel: e1000e: Copyright(c) 1999 - 2013 Intel Corporation. Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: Disabling ASPM L0s L1 Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: irq 40 for MSI/MSI-X Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: irq 41 for MSI/MSI-X Jan 30 07:23:43 Tower kernel: e1000e 0000:02:00.0: irq 42 for MSI/MSI-X Jan 30 07:23:43 Tower kernel: ACPI Warning: 0x00000580-0x0000059f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130117/utaddress-251) Jan 30 07:23:43 Tower kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Yes, I do, but have no idea what the problem is: Jan 27 10:21:44 Tower kernel: ACPI Warning: 0x00000580-0x0000059f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130117/utaddress-251) Jan 27 10:21:44 Tower kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
January 31, 201412 yr As a x9scm owner running 5.0.4 i can confirm this i guess: root@UNRAID:/boot/custom# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:25:90:24:21:fb inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:184535543 errors:6 dropped:4257546 overruns:0 frame:3 TX packets:174391691 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:167360230858 (155.8 GiB) TX bytes:152357047663 (141.8 GiB) Interrupt:20 Memory:f7800000-f7820000
January 31, 201412 yr I am seeing the same problem on two different Supermicro motherboards, One bare metal, nVidia chipset, the other virtualized in ESXi 5.0 intel chipset. Both are running unRaid 5.0, Other Linux VM's sharing the same physical NIC do not have a single dropped RX packet. Bare Metal H8DME-2 On-chip (nVidia MCP55) Ethernet controller: eth0 Link encap:Ethernet HWaddr 00:30:48:c4:18:b2 inet addr:192.168.20.161 Bcast:192.168.20.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4810937 errors:0 dropped:484 overruns:0 frame:0 TX packets:1667577 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4466347123 (4.1 GiB) TX bytes:2079465308 (1.9 GiB) VM under ESXI 5.0, X9SCM-F-O, Intel 82574L, vmxnet3: eth0 Link encap:Ethernet HWaddr 00:0c:29:47:99:5c inet addr:192.168.20.160 Bcast:192.168.20.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:31843250 errors:0 dropped:2356 overruns:0 frame:0 TX packets:7905757 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9693042243 (9.0 GiB) TX bytes:94625686720 (88.1 GiB)
January 31, 201412 yr SuperMicro X8DTH-iF unRAID 5.05 running in an ESXi 5.5 VM Linux 3.9.11p-unRAID. root@unRAID:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:0c:29:7b:19:58 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:31531861 errors:0 dropped:736 overruns:0 frame:0 TX packets:61626174 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:81278010710 (75.6 GiB) TX bytes:298039802265 (277.5 GiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:127 errors:0 dropped:0 overruns:0 frame:0 TX packets:127 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:10792 (10.5 KiB) TX bytes:10792 (10.5 KiB)
January 31, 201412 yr SUPERMICRO MBD-X8SIL-F-O Linux 3.9.11p-unRAID. root@Tower:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:25:90:69:44:42 inet addr:192.168.0.222 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:113028557 errors:0 dropped:2627 overruns:0 frame:0 TX packets:82137354 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:114413550893 (106.5 GiB) TX bytes:105962295138 (98.6 GiB) Interrupt:16 Memory:fb5e0000-fb600000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:6733 errors:0 dropped:0 overruns:0 frame:0 TX packets:6733 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:972850 (950.0 KiB) TX bytes:972850 (950.0 KiB)
January 31, 201412 yr Supermicro - X7DB8-X eth0 Link encap:Ethernet HWaddr 00:30:48:7b:c1:3c inet addr:192.168.1.88 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:4500 Metric:1 RX packets:583726571 errors:0 dropped:69190 overruns:0 frame:0 TX packets:357217658 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:800983719598 (745.9 GiB) TX bytes:185075890958 (172.3 GiB) Interrupt:18 Memory:d8800000-d8820000
January 31, 201412 yr Author Here is the Intel e1000e 2.5.4 driver (for unRaid 5.0.5 only): https://s3.amazonaws.com/dnld.lime-technology.com/temp/e1000e.ko 1. download the file and put in the root of your flash (the root of the flash is mounted at /boot on the linux side) 2. FROM THE CONSOLE type this sequence: /etc/rc.d/rc.inet1 stop rmmod e1000e insmod /boot/e1000e.ko /etc/rc.d/rc.inet1 start This needs to be via console because you will lose your network connection when the original driver is removed. You can verify the new version by looking for this line in /var/log/syslog (it will be near the end): kernel: e1000e: Intel(R) PRO/1000 Network Driver - 2.5.4-NAPI Let me know if this solves the problem! If it does, you can put those commands in your 'go' file, or wait for 5.0.6.
February 1, 201412 yr I have run this, although it seems both my mic cards are now active with the same ip... eth0 Link encap:Ethernet HWaddr 00:30:48:7b:c1:3c inet addr:192.168.1.88 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:376 errors:0 dropped:11 overruns:0 frame:0 TX packets:365 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:61448 (60.0 KiB) TX bytes:112329 (109.6 KiB) Interrupt:18 Memory:d8800000-d8820000 eth1 Link encap:Ethernet HWaddr 00:30:48:7b:c1:3d inet addr:192.168.1.88 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10460 errors:0 dropped:38 overruns:0 frame:0 TX packets:55269 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:805977 (787.0 KiB) TX bytes:82969366 (79.1 MiB) Interrupt:19 Memory:d8820000-d8840000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:6591 errors:0 dropped:0 overruns:0 frame:0 TX packets:6591 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:177513520 (169.2 MiB) TX bytes:177513520 (169.2 MiB)
February 1, 201412 yr Author I have run this, although it seems both my mic cards are now active with the same ip... eth0 Link encap:Ethernet HWaddr 00:30:48:7b:c1:3c inet addr:192.168.1.88 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:376 errors:0 dropped:11 overruns:0 frame:0 TX packets:365 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:61448 (60.0 KiB) TX bytes:112329 (109.6 KiB) Interrupt:18 Memory:d8800000-d8820000 eth1 Link encap:Ethernet HWaddr 00:30:48:7b:c1:3d inet addr:192.168.1.88 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10460 errors:0 dropped:38 overruns:0 frame:0 TX packets:55269 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:805977 (787.0 KiB) TX bytes:82969366 (79.1 MiB) Interrupt:19 Memory:d8820000-d8840000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:6591 errors:0 dropped:0 overruns:0 frame:0 TX packets:6591 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:177513520 (169.2 MiB) TX bytes:177513520 (169.2 MiB) Using DHCP or static? From console if you type: /etc/rc.d/rc.inet1 stop ifconfig eth0 0.0.0.0 down ifconfig eth1 0.0.0.0 down /etc/rc.d/rc.inet1 start ifconfig Does it still report same IP on both NIC's?
February 1, 201412 yr I have a static ip set, the command you specified fixed the issue, only one nic is reporting an ip. Thanks Tom!! Every 2.0s: ifconfig Fri Jan 31 19:27:18 2014 eth0 Link encap:Ethernet HWaddr 00:30:48:7b:c1:3c inet addr:192.168.1.88 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25022 errors:0 dropped:44 overruns:0 frame:0 TX packets:140266 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1989897 (1.8 MiB) TX bytes:210795346 (201.0 MiB) Interrupt:18 Memory:d8800000-d8820000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:16122 errors:0 dropped:0 overruns:0 frame:0 TX packets:16122 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:393485221 (375.2 MiB) TX bytes:393485221 (375.2 MiB)
February 1, 201412 yr Author I have a static ip set, the command you specified fixed the issue, only one nic is reporting an ip Yes this in an artifact of removing old driver/installing new. Probably it would work better with this: /etc/rc.d/rc.inet1 stop rmmod e1000e insmod /boot/e1000e.ko /etc/rc.d/rc.inet1 start I'll update my previous post.
Archived
This topic is now archived and is closed to further replies.