Jump to content

[SOLVED] ASrock z97 Bios 2.60 2018/3/13 Update Haswell CPU Microcode to revision 24 and Broadwell CPU Microcode to revision 1D.


Recommended Posts

Good evening, 

I got around to patching my bios to the 2.60 on my Z97 Extreme4/3.1 It is currently my unRaid server for 2 years running.  Essentially, I have a few plugins, dockers, and 2 active vm's.  I have been using a gtx 760 and a gtx 970 for video cards in two separate VM's.  

 

Good news post update system boots gpu roughcast works perfect, everything appears to work fine.

 

Then issue number 1.  None of the 3 network cards I have installed are working.

no ping, no anything.

 

I think ok, lets reboot.

run constant ping on all 3 ip's and the machine gets to Login, and they stop pinging.

 

I disconnect the network cables swap them all for known good.

 

they ping.  OK, life is fine a few days.

 

I run into a reason to shutdown, local power util going down, known thing, alright I'll shutdown.

 

Boot up, and everything stops pinging.  I Think OK, lets swap network cables but this time no ping.

 

So I reboot, go into Safe mode no plugins gui.

 

NO ping.  Everything seems ok, but no network at all.

 

So I reboot to gui.

 

Run fix common problems, and there is a few small things, cached drive permission changes I made, but no network issues found, or anything related.

 

I then think ok, maybe its my network cards (dual rosewill, and onboard asrock,)  I disable the asrock and remove the rosewill.  I add in an old school, (but working,) 100 mbit  Intel 3c905B.

 

Set the static lease to that nic.  

 

same thing.

 

say ok. shut it down swap the nic for original, re-enable the onboard.  No change.

 

think hell with it load bios defaults.

 

Machine boots things ping, but IOMMU is disabled.

 

reboot, re-enable VT-d, and the problem comes back.

 

Here is the kicker, even rolling back to version 2.50 bios. I'm having the same problem.  I know this isn't an unRaid problem, but maybe I'm missing something and someone else has seen this before.

 

issue occurs on 5.6.0 and 5.6.1

 

VM performance is hindered and this doesn't work.

 

So I cold boot, reset bios to default.

 

re-enable VT-D

 

boot

 

Network disappears.

 

Unplug all three network cables.  plug them back in, then ping.

 

The problem.  My power has gone out 30 times int he last week.  The server shuts down when UPS says its low,  when power is restored same issue with the network.  Now one more thing.  I can't always get the bios reset to make network work.

 

I even have a managed switch that I can shut off the ports for network and re-enable.

 

Please note: tonight no matter what I do I can't get the machine to boot with network to get the diagnostics file.  The attached is with iommu off.

 

I can live with this temporarily, but...  Say we have a power outage, I can't expect my wife to go clear the bios, and re-enable. She works at home and we use the VM's as a primary, but I can't exaclty go from my secured, "rat everyone's browsing history out to IT security" from my Raritan KVM at home... every time an issue occurs.

 

I know this isn't an unRaid issue per-say, and ultimately I wouldn't mind a few cores, but i'm going to be 4-5 months before I can snag my next upgrade for my home server.

 

Is there anything anyone may know so I can get IOMMU back.  If anything let this be the warning to either live with the flaw, or lose IOMMU short term on the upgrade for this Mobo specifically.  Maybe this post will stand as a warning to others before they run into the same issue.  I know this was a poor choice of board at the start, but I had it and I'm not swapping for my 6700 at my desk.  My wife's rig is also off limits for the swap as well.

 

Again any help with is is appreciated, not expecting much, its not really an unRaid issue, but more an intel~ asrock z97 issue at this time.

 

grrrr-diagnostics-20180426-1953.zip

Edited by Traverser
Solved!
Link to comment

I forgot to make a new zip file.  

 

I cleaned out my network adapters from the config files.  

 

Boots up with vt-d on.  Everything found and back to usual.

 

I'm far from a Linux pro.  I'm sure I have some fallout left from this, but I was able to reboot 3 times successfully with no issue again.

 

I may still ask for help on the cleanup, but the VM performance is superior to  what it was; Plex is even working much better.

 

I know this is not a problem Lime Tech created; but would anyone have a script to flush out the network card(s) already.  Been searching a bit, only have so many minutes on my break.

Link to comment

 

2 hours ago, Traverser said:

I don't completely understand this config file.  I'm reading a ton of forum searches, but I'm drawing a blank. I can understand ASDI Edit in AD for a 15,000 user facility...  but this is kinda tough shift for me.

 

Which config file are you asking about? I'm not sure what any of this has to do with Active Directory. In fact I don't understand you last sentence at all.

Link to comment

I am accustomed to spending the majority of my day working in the background of Active directory.  For some reason the config file in the diagnostics confuses me, and  I'm not sure how to modify this to "make it work properly" and don't want to re-install the whole setup.

Link to comment

At the moment a ton of errors pertaining to network cards I have eliminated, that made a problem I induced with a firmware update go away, (which it did, well mostly: )

 

I found this in another thread.  Instead of deleting them, I moved them to a different directory:

 

 

 

"Try after shutting down, deleting from the flash drive the 2 network files in /config (network.cfg and network-rules.cfg), then reboot (or delete the rules file and edit network.cfg)."

After doign so, my VM's now made a virbro and I can access them via splash desktop or teamviewer style apps, but I cannot access them directly from my internal network.  I could make a vlan and link it up, but I'd rather they stay local.

Is it safe to delete the virbro, and will the machine create a bro or no chance?
 

Link to comment

I do appreciate the help its pretty awesome what they do, I just don't want to leave a vulnerability out there.

 

Ultimately get rid of the hardware causing this post all of this:

 

Apr 28 14:35:42 GRRRR kernel: virbr0: port 1(virbr0-nic) entered blocking state
Apr 28 14:35:42 GRRRR kernel: virbr0: port 1(virbr0-nic) entered disabled state
Apr 28 14:35:42 GRRRR kernel: device virbr0-nic entered promiscuous mode
Apr 28 14:35:42 GRRRR dhcpcd[1744]: virbr0: new hardware address: 26:66:c2:9b:11:3f
Apr 28 14:35:42 GRRRR dhcpcd[1744]: virbr0: new hardware address: 52:54:00:d6:78:3e
Apr 28 14:35:43 GRRRR avahi-daemon[15246]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
Apr 28 14:35:43 GRRRR avahi-daemon[15246]: New relevant interface virbr0.IPv4 for mDNS.
Apr 28 14:35:43 GRRRR avahi-daemon[15246]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
Apr 28 14:35:43 GRRRR kernel: virbr0: port 1(virbr0-nic) entered blocking state
Apr 28 14:35:43 GRRRR kernel: virbr0: port 1(virbr0-nic) entered listening state
Apr 28 14:35:43 GRRRR dnsmasq[16331]: started, version 2.79 cachesize 150
Apr 28 14:35:43 GRRRR dnsmasq[16331]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify
Apr 28 14:35:43 GRRRR dnsmasq-dhcp[16331]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h
Apr 28 14:35:43 GRRRR dnsmasq-dhcp[16331]: DHCP, sockets bound exclusively to interface virbr0
Apr 28 14:35:43 GRRRR dnsmasq[16331]: no servers found in /etc/resolv.conf, will retry
Apr 28 14:35:43 GRRRR dnsmasq[16331]: read /etc/hosts - 2 addresses

Link to comment

Your network settings are back to the defaults which means that virtual machines will be using vibr0 (VIrtual BRidge 0) and thus be in an internal host only network that is NAT'd out to your LAN

 

You need to change the setting to use br0 instead, which is tied to your NIC interface and thus become visible to your LAN

image.thumb.png.dff9bd406aac14b1e948e7402a277207.png

I'm using br1 as my NIC interfaces are not bonded together.

  • Like 1
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...