PeterB Posted February 1, 2014 Share Posted February 1, 2014 This needs to be via console because you will lose your network connection when the original driver is removed. ... or IPMI, which uses a different port and doesn't go through the O/S? Quote Link to comment
limetech Posted February 1, 2014 Author Share Posted February 1, 2014 This needs to be via console because you will lose your network connection when the original driver is removed. ... or IPMI, which uses a different port and doesn't go through the O/S? Sure. I have found that if IPMI is "sharing" a port, say eth0, you lose connectivity for several seconds but it does come back. Many of the Supermicro m/b's include a 3rd dedicated IPMI ethernet port for which this is not an issue. Quote Link to comment
PeterB Posted February 1, 2014 Share Posted February 1, 2014 Unforunately the new driver doesn't help me at all: root@Tower:~# grep NAPI /var/log/syslog Feb 1 10:51:55 Tower kernel: e1000e: Intel(R) PRO/1000 Network Driver - 2.5.4-NAPI root@Tower:~# ifconfig eth0 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:27185 errors:0 dropped:20576 overruns:0 frame:0 TX packets:48157 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2150014 (2.0 MiB) TX bytes:66354497 (63.2 MiB) Interrupt:18 Memory:df700000-df720000 Edit: Other things I have done, following advice found from the sourceforge Intel network drivers pages: I have modified the network microcode (something to do with powersaving?). I have checked that ASPM is disabled ... it already was. Quote Link to comment
clowrym Posted February 1, 2014 Share Posted February 1, 2014 still seem to be getting dropped packets with this new driver, until i changed my mtu to 4500 which drastically reduces them from 20-50 every 2s to 1-2 every 6-10s.... same result on the previous driver 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:3584096 errors:0 dropped:397 overruns:0 frame:0 TX packets:1813753 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5004697071 (4.6 GiB) TX bytes:1822615607 (1.6 GiB) 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:101733 errors:0 dropped:0 overruns:0 frame:0 TX packets:101733 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2119301602 (1.9 GiB) TX bytes:2119301602 (1.9 GiB) Quote Link to comment
crankbearing Posted February 1, 2014 Share Posted February 1, 2014 here is a good read that I found for SM board owners - ftp://ftp.supermicro.com/CDR-NIC_1.30_for_Add-on_NIC_Cards/Intel/LAN/PROXGB/DOCS/LINUX/e1000.htm. I know it's for older Kernels but still may help in some cases, I did not know there were several e1K driver revs. rgds, Dave Quote Link to comment
jowi Posted February 1, 2014 Share Posted February 1, 2014 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 With the other driver things look like they've improved: 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:1500 Metric:1 RX packets:1173731 errors:0 dropped:133 overruns:0 frame:0 TX packets:742456 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1542232683 (1.4 GiB) TX bytes:341258090 (325.4 MiB) Interrupt:20 Memory:f7800000-f7820000 I'll keep an eye on it... Quote Link to comment
Fuggin Posted February 2, 2014 Share Posted February 2, 2014 I completely goofed and didn't backup my flash before updating to 5.0.5. I think there is something with the final version that is affecting my drive speeds with controller cards. If someone could link me the RC16c version, so I can redo my flash with that version to test the differences between the two. I would appreciate it. Quote Link to comment
nars Posted February 2, 2014 Share Posted February 2, 2014 @Fuggin: You can get it at my mirrors on my signature and you can confirm md5 with the one at: http://lime-technology.com/wiki/index.php/Release_Notes Quote Link to comment
Fuggin Posted February 2, 2014 Share Posted February 2, 2014 Thanks... When I try to download them on the main server, I get this: http://download.lime-technology.com/cgi-sys/suspendedpage.cgi Quote Link to comment
nars Posted February 2, 2014 Share Posted February 2, 2014 Yes, that's why I told you to use my mirror links on my post(s) signature I just posted the wiki link so you could confirm the file md5. Quote Link to comment
jowi Posted February 2, 2014 Share Posted February 2, 2014 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 With the other driver things look like they've improved: 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:1500 Metric:1 RX packets:1173731 errors:0 dropped:133 overruns:0 frame:0 TX packets:742456 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1542232683 (1.4 GiB) TX bytes:341258090 (325.4 MiB) Interrupt:20 Memory:f7800000-f7820000 I'll keep an eye on it... A day later, did not help a lot, or at all... 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:1500 Metric:1 RX packets:232891863 errors:0 dropped:2202804 overruns:0 frame:0 TX packets:197053560 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:207539152110 (193.2 GiB) TX bytes:216461632427 (201.5 GiB) Interrupt:20 Memory:f7800000-f7820000 Quote Link to comment
clowrym Posted February 2, 2014 Share Posted February 2, 2014 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 With the other driver things look like they've improved: 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:1500 Metric:1 RX packets:1173731 errors:0 dropped:133 overruns:0 frame:0 TX packets:742456 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1542232683 (1.4 GiB) TX bytes:341258090 (325.4 MiB) Interrupt:20 Memory:f7800000-f7820000 I'll keep an eye on it... A day later, did not help a lot, or at all... 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:1500 Metric:1 RX packets:232891863 errors:0 dropped:2202804 overruns:0 frame:0 TX packets:197053560 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:207539152110 (193.2 GiB) TX bytes:216461632427 (201.5 GiB) Interrupt:20 Memory:f7800000-f7820000 An MTU of 4500 reduced mine substantially , I tried 1500 & 9000 but both resulted in dropped packets every 2 second update with "watch ifconfig" with 4500 I get about 5000 dropped packets /day, which is less then 1%...I bought all new cat6 cables, so thats on my agenda this weekend Quote Link to comment
jowi Posted February 2, 2014 Share Posted February 2, 2014 I'll give that mtu value a try Quote Link to comment
bkastner Posted February 2, 2014 Share Posted February 2, 2014 I am not sure how concerned I should be. I upgraded to 5.0.5 earlier last week, and since then I've installed a new 4TB parity drive. After doing the preclear I replaced the 3TB parity drive with the new one and then let UnRAID re-calculate parity. Once that was done I ran check parity - which is taking forever (usually around 10-11 hours, but it reported 2400 minutes or so required). It appears it's found and corrected 256 sync errors, which surprises me since I only created the parity drive?? Should it not have been perfect? I've attached the syslog in case that helps. The syslog is 244kb, so I can't attach as one file. I am uploading 2 posts each with part of the syslog. Part 1 includes the boot process up til it starts the GO script. Part 2 starts right after that when UnRAID reports it's version number. syslog-2014-02-02_-_boot_up.txt Quote Link to comment
bkastner Posted February 2, 2014 Share Posted February 2, 2014 Here is the syslog part 2. syslog-2014-02-02_-_running.txt Quote Link to comment
jphipps Posted February 2, 2014 Share Posted February 2, 2014 it looks like you got a scsi error on the parity build: Jan 31 13:05:36 CydStorage kernel: ata18.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6 frozen Jan 31 13:05:36 CydStorage kernel: ata18.00: failed command: READ FPDMA QUEUED Jan 31 13:05:36 CydStorage kernel: ata18.00: cmd 60/00:00:d8:96:cd/04:00:17:00:00/40 tag 1 ncq 524288 in Jan 31 13:05:36 CydStorage kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Jan 31 13:05:36 CydStorage kernel: ata18.00: status: { DRDY } Jan 31 13:05:36 CydStorage kernel: ata18: hard resetting link When I have seen that on mine, the next parity check will correct serveral parity errors. Did you try running another parity check after that one? I would think the next run should be close to 0 errors. It seems the error occurred on disk with serial # ending 5640. Quote Link to comment
bkastner Posted February 2, 2014 Share Posted February 2, 2014 it looks like you got a scsi error on the parity build: Jan 31 13:05:36 CydStorage kernel: ata18.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6 frozen Jan 31 13:05:36 CydStorage kernel: ata18.00: failed command: READ FPDMA QUEUED Jan 31 13:05:36 CydStorage kernel: ata18.00: cmd 60/00:00:d8:96:cd/04:00:17:00:00/40 tag 1 ncq 524288 in Jan 31 13:05:36 CydStorage kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Jan 31 13:05:36 CydStorage kernel: ata18.00: status: { DRDY } Jan 31 13:05:36 CydStorage kernel: ata18: hard resetting link When I have seen that on mine, the next parity check will correct serveral parity errors. Did you try running another parity check after that one? I would think the next run should be close to 0 errors. It seems the error occurred on disk with serial # ending 5640. I still have 1140 minutes to go on the original parity check, but I will start another one after. I do have a 2TB disk that ends in that serial #, so maybe this is an indication that I should be replacing that drive sooner rather than later. I just figured if it just calculated parity 2 days ago from these drives that the check should be a no-brainer. I guess that isn't always the case. Thanks for the input. Quote Link to comment
Matapaua Posted February 2, 2014 Share Posted February 2, 2014 Thanks for updated Intel e1000e 2.5.4 driver. Unfortunately have to report am still getting 4% dropped Rx packets on an Intel DZ77BH-55K board with Intel 82579V controller. Quote Link to comment
limetech Posted February 2, 2014 Author Share Posted February 2, 2014 Thanks for updated Intel e1000e 2.5.4 driver. Unfortunately have to report am still getting 4% dropped Rx packets on an Intel DZ77BH-55K board with Intel 82579V controller. If you want to spend a little time 'googling' the error I'd appreciate it: report back if anyone has a solution Quote Link to comment
dlandon Posted February 3, 2014 Share Posted February 3, 2014 Thanks for updated Intel e1000e 2.5.4 driver. Unfortunately have to report am still getting 4% dropped Rx packets on an Intel DZ77BH-55K board with Intel 82579V controller. Possibly a cable or switch problem? Quote Link to comment
dalben Posted February 3, 2014 Share Posted February 3, 2014 Any ETA on 5.06 with the new GUI ? Quote Link to comment
bkastner Posted February 3, 2014 Share Posted February 3, 2014 Is there still an issue with running 5.0.X with more than 4GB of memory? I recently swapped in a new motherboard/cpu that had 16GB of ram on it. Thing seem to be running slower than with my old AMD cpu. If I am doing a parity check watching TV shows from unRAID can be brutal (constant buffering and pausing). If I am also pre-clearing a disk I can't even access shares on UnRAID. As soon as I kill the pre-clear I can access shares again, but everything is slow until I kill the parity check. Also, parity checks used to take 10 hours (3TB parity disk, 10 data disks (2-3TB). I recently installed a 4TB parity disk and when trying to do a first parity check it wanted to take 40+ hours. the new machine is 3x faster at least than my old AMD, and the upgrade of RAM from 4 to 16GB is the only thing I can think of that may be causing my problem. I also moved from 5.0.4 to 5.0.5, but since I haven't seen others reporting these issues I am assuming it's not build specific. Quote Link to comment
ogi Posted February 3, 2014 Share Posted February 3, 2014 Thanks for updated Intel e1000e 2.5.4 driver. Unfortunately have to report am still getting 4% dropped Rx packets on an Intel DZ77BH-55K board with Intel 82579V controller. If you want to spend a little time 'googling' the error I'd appreciate it: report back if anyone has a solution Hey Tom, No solution found, but a google search actually lead me back to the unraid forums, specifically, this thread: http://lime-technology.com/forum/index.php?topic=27136.0 It seems like there was an issue occurring with a 100Mb device being on a network... Also, X9SCM owner here... I installed the new drivers you posted root@Tower:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:25:90:78:82:91 inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:4500 Metric:1 RX packets:10491 errors:0 dropped:6329 overruns:0 frame:0 TX packets:30800 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1242875 (1.1 MiB) TX bytes:32054109 (30.5 MiB) Interrupt:20 Memory:df800000-df820000 Can also confirm that setting the MTU to 4500 drastically reduced the number of dropped RX packets. Quote Link to comment
ogi Posted February 3, 2014 Share Posted February 3, 2014 I came across this article here to help diagnose dropped packets: http://www.novell.com/support/kb/doc.php?id=7007165 root@Tower:~# tcpdump -bash: tcpdump: command not found However since tcpdump isn't included (what's the right vocabulary here?) I can't follow the suggested troubleshooting steps. Ogi Quote Link to comment
PeterB Posted February 4, 2014 Share Posted February 4, 2014 Thanks for updated Intel e1000e 2.5.4 driver. Unfortunately have to report am still getting 4% dropped Rx packets on an Intel DZ77BH-55K board with Intel 82579V controller. Possibly a cable or switch problem? Anything is possible, but I have run identical file transfers with my server booted in Ubuntu desktop - no dropped packets are reported. However, in unRAID, the dropped packets count can be in excess of 50%. I have tried a different switch, and that doesn't stop the dropped packets. If I use a separate switch for the unRAID box, and connect that to my main switch, then the dropped packets count drops to almost zero. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.