February 23, 20179 yr I don't see eth1 coming and going in sympathy. You don't have bonding enabled so you can't just swap ports. You also don't seem to have bridging enabled, which probably explains your docker problem. Try turning on bonding (mode 1) and bridging and see if that helps.
February 23, 20179 yr Author I was just using a single port, but the mobo has dual ethernet. Is there an advantage to using bonding if they are going to the same Switch? Never mind - I did some reading. I'll get another ethernet cable and use it goign forward. In any case, I've done as asked, but Docker still isn't playing ball. FCPsyslog_tail.txt Edited February 23, 20179 yr by emmcee
February 23, 20179 yr I thought you meant you were swapping between the two NICs. Perhaps you meant you were swapping cables. Bonding (mode 1) gives redundancy and makes it easy when you have multiple NICs - just plug into any one and it works. The bridge is like a virtual internal switch that lets dockers look out through the physical connection. I can't tell anything from that tail, I'm afraid. Need the diagnostics. Is that after a reboot following the network reconfiguration?
February 23, 20179 yr Author Sorry - I swapped a cable from one port to another. Both ports seem to be working in Bonded mode now. Diagnostics attached. Thanks for taking the time to help me. tower-diagnostics-20170223-1531.zip
February 23, 20179 yr The docker log is still complaining about network problems but it's encouraging to see Quote time="2017-02-23T15:03:08.045148766Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. but this still indicates an error Quote time="2017-02-23T15:03:08.143687680Z" level=fatal msg="Error starting daemon: Error initializing network controller: Error creating default \"bridge\" network: cannot create network docker0 (2d14423c7816ecec50f174460daa5f1a54fbb4392fe06df0ee8524e26a350c3d): conflicts with network 2c6d8cffa9ff6de49c2d5863d7df3a8c4b7c17441cae3d17a2fb0c181b13b088 (docker0): networks have same bridge name" I'm not a docker expert. Maybe it's time to re-create your docker.img file. It's quite painless and worth a try. Instructions are here.
February 23, 20179 yr Author I already recreated the Docker image but no luck. Feeling brave and/or stupid I updated to 6.3.2 again. GUI was fast and Docker was running, but within 30 seconds of the GUI coming up there was a Kernel Panic again. It's was up for 20 minutes since that running FCP troubleshooting and a parity check. I powered down and removed the flash drive. When I put it into my Windwos box it said the drive has errors. I'm goign to repair and try 6.3.2 again. Failing that I'll go back to 6.2.4 and remove all plugins and see what happens. With 6.2.4 not throwing any Kernel Panics all day, can we put the PSU issue to bed? It seems to be an issue with 6.3.2. Edit: latest diagnostics... FCPsyslog_tail.txt tower-diagnostics-20170223-1704.zip Edited February 23, 20179 yr by emmcee
February 23, 20179 yr I don't think it's safe to use 6.3.2. You're still getting this: Quote Feb 23 17:02:26 Tower kernel: x86: Booting SMP configuration: Feb 23 17:02:26 Tower kernel: .... node #0, CPUs: #1 #2 Feb 23 17:02:26 Tower kernel: mce: [Hardware Error]: Machine check events logged Feb 23 17:02:26 Tower kernel: #3 #4 #5 #6 #7<6>x86: Booted up 1 node, 8 CPUs The docker log isn't showing network problems any more. I don't have anything to add to the subject of the power supply. You might want to look into this: Quote Feb 23 17:02:54 Tower kernel: e1000e: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx Feb 23 17:02:54 Tower kernel: e1000e 0000:00:19.0 eth1: 10/100 speed: disabling TSO Bad cable or switch port.
February 23, 20179 yr Author Yep - dodgy cable is going into the bin. Not sure why there are no Docker errors as Docker still wasn't running. What I've learned so far... A virgin 6.3.2 or 6.3.1 causes the panics. I'm picking up a PSU later to rule that out once and for all. It looks like Docker is causing the slowdown on my 6.2.4. When it's disabled the GUI is back to normal snapiness. So the plan is to go back to a virgin 6.2.4 and start from scratch (if I can remember all my paths...)
February 23, 20179 yr Author Still no joy. Opening a thread on the Docker Engine forum. Edited February 23, 20179 yr by emmcee
February 24, 20179 yr Author OK, I ran a full Parity check last night (~1000 errors). This morning I stripped back my config folder to the bare minimum this morning and I got Docker to run. No slowdown. Great. Now I'm trying to rebuild plex with my previous appdata and folder structure from memory. Not fun, but it looks like I'm out of the woods! If I get a chance over the weekend I'll test 6.3 with the new PSU and report back. Thanks for all your help. Edited February 24, 20179 yr by emmcee
February 24, 20179 yr Community Expert 2 hours ago, emmcee said: OK, I ran a full Parity check last night (~1000 errors) You should run another to make sure parity is valid now. Exactly zero is the only acceptable result.
February 24, 20179 yr Author 9 minutes ago, trurl said: You should run another to make sure parity is valid now. Exactly zero is the only acceptable result. Thanks. I'll do that tonight.
February 24, 20179 yr Author OK, we can finally rule out the PSU issue. I just ran it on my desk with a 250W PSU and there was a Kernel Panic even before I got to load the GUI.
February 24, 20179 yr Community Expert 10 minutes ago, emmcee said: OK, we can finally rule out the PSU issue. I just ran it on my desk with a 250W PSU and there was a Kernel Panic even before I got to load the GUI. What is the exact model of that power supply?
February 24, 20179 yr Author My original is a Mini-Box picoPSU-160-XT The test supply is a LITEON PS-5251-6LF (HP part no: 353011-001). The label says it's good for 200W on +12 and +5 rails combined
February 24, 20179 yr 59 minutes ago, emmcee said: My original is a Mini-Box picoPSU-160-XT The test supply is a LITEON PS-5251-6LF (HP part no: 353011-001). The label says it's good for 200W on +12 and +5 rails combined Quite honestly, whether or not the PSU winds up being the culprit, you're still playing with fire. And wattage on an actual ATX supply is immaterial. The important thing is amperage on the rails. 1.79A spinup * 5 drives = ~9 amps. The supply in theory when new ( and the style of the supply indicates that its probably 10+ years old) could supply 17A on the 12v line to both the drives and to the motherboard. My opinion (take it or leave it) is that there is no more important component of any server than the powersupply, as it forms the basis for the entire system. And since power supplies do age and are able to supply less power over time, spec'ing one out that is an exact match is poor planning. But, as I stated the PSU may or may not be the root cause of your issues. Just popping my 2cents worth in here (as I hate it when people quote combined wattage on a ps when its the amps that are important )
February 24, 20179 yr Author I do understand where you're coming from squid - I only mentioned the wattage as it was on the PSU's label. I would disagree that it's speced as an exact match. Looking at the PicoPSU spec here it's rated for 15A peak on the 12V rail (and it can supply that for up to a minute). Thats more than 50% overhead assuming it hits 9A on the 12V rail. Looking at the real world draw using the power meter it's briefly hitting 80W for the whole system during the FCP test or if I click the "Spin Up" button. That's 50% of the nominal rating and 40% of the peak rating. I also think that 8 months of uptime on 6.2 without so much as a single parity error points to the system being happy. If I get time ove the weekend I may put 6.3 back on and disconnect the drives completley to see if I still get the error. I have an 800W supply in my main PC, but I'm not sure I have the inclinaiton to open that up again. In any case, the next plan is to swap out 2x 3TB for 8TB Reds so I may drop the 2TB drive at the same time, bringing me down to 4 spinning drives. Edited February 24, 20179 yr by emmcee
February 24, 20179 yr Author 10 hours ago, trurl said: You should run another to make sure parity is valid now. Exactly zero is the only acceptable result. Parity check is complete. Exactly zero is the current result. I've ordered a PWM fan to bring down the drive temps during Parity check. I have Plex up and running now. Being able to watch Adventure Time is the only thing that matters to some people in this house. Edited February 25, 20179 yr by emmcee
February 25, 20179 yr Author Update. I'm willing to concede that my PSU may be cutting it a bit fine. I pulled the EVGA Supernova 750 W PSU from my gaming rig. It's good for 62A on the 12V rail. I booted 6.3.2 and no mce errors in the log. I did more research into the PicoPSU, it seems it just passes 12V straight from the external AC-DC brick. The brick being 120W, obviously can only do 10A which is a lot closer to the specs on the WD Red datasheet (although still within measured power consumption of 80W). Anyway, I'm going to order a 150W brick, and in time will reduce my drive count to 4. I've also ordered a PCW case fan to bring my drive temps down and I'll reconfigure the drive layout in the case so there is a gap in the middle. However... I still get a kernel panic on 6.3.2 within a minute of booting. The second time it didn't even get to the login prompt (see attached) . This is taking my brand new 6.2.4 build with 2 Dockers, and a handful of plugins and running an Update from the Plugins tab. 6.2.4 runs like a champ - I've completed 2 Parity Checks and spent the evening watching Plex while it was doing a check. Is it reasonable now to assume there is a bug in 6.3.2? Edited February 25, 20179 yr by emmcee
March 1, 20179 yr Author Parts arrived today so I've done a power/cooling upgrade. I invested in 2 new Ethernet cables so channel bonding is working properly. The case Fan is now an Akasa 14cm PCW. I've split the HDDs into groups of 3 and 2 so there is a large gap for airflow. I've installed AutoFan plugin and it's currently an hour into a parity check and temps are a full 10deg lower than previously. And it seems like it will turn the fan off completely when not in use, which is pretty cool. Most importantly I've upgraded the power brick for the PicoPSU to 192W, which should allow for 13A on the 12V rail. I'll attempt an upgrade to 6.3.2 again later in the week to see if it's fixed the mce error. I just wanted to say to say a big thanks to all for the help on this thread. Fingers crossed I can get to the bottom of the Kernel Panic issue.
April 6, 20179 yr Author I just wanted to follow up this thread (I hate when people don't post solutions). I got to the bottom of this today. Apparently the latest firmware for the Gigabyte H97N-WIFI motherboard have support for Broadwell but it's buggy. They released a beta (Ver. F9b) that has a fix, although no release notes. I just installed 6.3.2 and no MCE errors in the logs and it's been up a couple of hours without issue. Problem solved.
Archived
This topic is now archived and is closed to further replies.