Jump to content

zoggy

Members
  • Content Count

    562
  • Joined

  • Last visited

Community Reputation

15 Good

About zoggy

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. any chance we can get dhcpcd updated?
  2. just to note, upgraded from 6.7.0->6.7.1-rc1->6.7.1-rc2 without problems. 6.7.0 cosmetic bug still shown every 20 hours:
  3. ok, here we go: https://openbenchmarking.org/result/1906037-HV-190603PTS41,1906033-HV-190603PTS92
  4. whew okay, I have an intel i3-3220 CPU and wanted to see how much performance I can get back with disabling the mitigations as noted. I upgraded to 6.7.1rc1 and spun up the Phoronix Test Suite in a docker vm and focus on the cpu test -- https://openbenchmarking.org/suite/pts/cpu The array was running but no activity was ongoing, and no other dockers were active. Test suite cycle took about 3 hours in a run, each test ran 3 times and deviations is noted. Ran first set as is with the mitigations in place then rebooted with syslinux cfg modification to disable the mitigation (still get some due to microcode used) and re-ran same tests to compare. results: https://openbenchmarking.org/result/1906037-HV-190603PTS41,1906033-HV-190603PTS92 can see that 2-14% increase on various things. The ctx-clock micro-benchmark for looking at the context switching overhead shows the big impact since Spectre/Meltdown Which is why you can see is the most drastic reported as it targets that specific area.. 87% difference! hope this helps for those curious
  5. anyone else seeing this in 6.7.0 every 5 hours: I do dhcp with static assignments from my router. nothing has changed there recently (uptime on router was 85 days), rebooted this yesterday thinking it may have been the source but checked today and still seeing the messages. Looking back at my logs, looks like it started on the 6.7.0-rc8. as my logs from 6.7.0-rc7 and older does not have any of the entries. network is integrated into mobo, its a realtek: looks to be cosmetic as nothing shows any impact by it. looking at the unraid 6.7.0 release I see: dhcpcd: version 7.2.0 guessing this is the root cause. just fyi, latest is 7.2.2
  6. the logical place is to go look at the security forum section about this issue which had nothing hence why I posted there and noted.
  7. @limetech sorry for the cross post, but I came here looking to see if the CVE was already addressed.
  8. offical site: https://zombieloadattack.com/ “ZombieLoad,” as it’s called, is a side-channel attack targeting Intel chips, allowing hackers to effectively exploit design flaws rather than injecting malicious code. Intel said ZombieLoad is made up of four bugs, which the researchers reported to the chip maker just a month ago. Almost every computer with an Intel chips dating back to 2011 are affected by the vulnerabilities. AMD and ARM chips are not said to be vulnerable like earlier side-channel attacks. additional info: https://techcrunch.com/2019/05/14/zombieload-flaw-intel-processors/ and patches: https://techcrunch.com/2019/05/14/intel-chip-flaws-patches-released/
  9. I can confirm you will get a marvell warning from the plugin (although a bit vague): I get it because I have a Supermicro's SAS2LP-MV8 controller (based on the Marvell 9480 host controller). "Marvell" never shows up in my syslog anywhere. As others have noted, some Marvell controllers are fine (never been a problem and still is fine on 6.7.0) but it is more of piece of mind to us another brand for reliability.
  10. what is different from 6.7.0 final and 6.7.0-rc8?
  11. just curious if this RC is going to be final.. as 6.7.0rc started in jan
  12. you can just ssh to your unraid box and do "ifconfig eth0" for the info. also the unraid gui dashboard says the info as well but just more tedious as you have to change the drop down from general info > counters > errors to see everything.
  13. from your test, looks like you did tcp testing and see the problem. so now you could try udp and see if it also has an issue. but regardless now you should packet capture and see what happens at the dips. you can use wireshark and do an io graph to make it easy to align and search. example: side question, what mtu are you using and have you checked your nic stats to make sure you dont have runts/giants and/or errors?
  14. you should load up iperf3 / ethr and test internally from within your own network. eliminate as many networking elements and unknown variables you can. may find out your isp just has bad peering.. or your firewall rules are the cause.. etc
  15. updated from previous rc. so far no fireworks