jonp
-
Posts
6,443 -
Joined
-
Last visited
-
Days Won
24
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by jonp
-
-
Ok, how about general network performance? How is it copying a file from a machine on the network to the Unraid server?
-
The biggest challenge here is trying to figure this out without a copy of your system diagnostics. Can you upload those here from your current flash that is having problems? My guess is there is something in that configuration causing this modprobe issue. To confirm its not anything specific to the flash device itself, you can make a full backup of your flash, then wipe the flash fresh, reinstall Unraid, and boot. If no modprobe issue, then you can most likely rule out the flash device itself as the culprit and restore the backup. Now it comes down to figuring out what on your flash is causing this problem.
Please share your system diagnostics so we can see (from the Tools > Diagnostics page).
-
The syslog to flash method is not valid for capturing log events related to major crashes like you're experiencing. The problem is that the hang can occur before the write to the flash can occur. This is why I am suggesting you connect a monitor / keyboard to the system.
-
Hi there,
Looks like you need to update your forum signature as your hardware has changed from AMD to Intel ;-). That said, I'm not seeing any events in the logs themselves that show a problem. And I'm not sure what this is supposed to mean:
On 1/16/2020 at 9:11 AM, dgomel said:The problem is that once in a while everything stack.
Also hoping that you removed this container while troubleshooting this:
On 1/16/2020 at 9:51 AM, dgomel said:I localized a source of zombies to specific container. The problem started before I implemented the container. So, seems irrelevant.
At this point, I would suggest hooking up a monitor and keyboard to the system and tailing the log (command is tail /var/log/syslog -f). This will begin printing the log out to the screen. Then try to get the system to crash again and capture whatever was printed to the screen (use your phone to take a picture if necessary). This should give us at least some information to point towards a cause.
I'd also check for a BIOS update on your motherboard.
-
1
-
-
That would give us more information...
-
Hi there,
Saw your email into support as well and reviewed your logs. Nothing is glaring at me that is looking out of place. Unfortunately these types of issues can be notoriously difficult to diagnose as they are often hardware-specific. Have you tried reseating the GPU into a different PCI slot? What about a BIOS update? That CPU is awfully old at this point (7+ years). Sometimes these pass through issues come down to just needing a good old fashioned face-lift on the hardware.
-
Thanks for the update! Not sure what would have fixed this from 6.8.1, but either way, glad it's resolved for now!
-
You definitely need to be stubbing any storage, Ethernet, or USB controllers you wish to use in your VM. Otherwise the host OS will load a proper driver and potentially block you from starting the VM.
If with all of those devices stubbed, you're still having a problem, I'm running out of ideas. After starting your VM with the devices assigned, go ahead and recapture diagnostics and upload here. We need to see something in the logs to point to the source of the issue. If nothing is there, it's likely a hardware-specific issue which will be very difficult to remediate.
-
A few things to try:
1) UEFI boot mode. Use OVMF instead of SeaBIOS. See if that makes a difference.
2) Try i440fx (instead of q35).
3) Try setting the CPU to emulated instead of host-passthrough.
If none of those work, let us know and I can try to recreate the issue on our end.
-
I've gone ahead and copied this into our bug reports forum for stable releases. I've listed it under the category of "annoyance" as it doesn't seem to affect functionality, but obviously isn't reporting the correct data. Further commenting on this should be done over there:
-
Hi there,
I saw your email into our support team and wanted to take a moment to reply. After reviewing the thread and diagnostics (as well as the error messages you posted most recently), it's pretty clear to me that this isn't so much a software bug as something being amiss with the hardware/configuration. The fact that you're having so many different issues/error messages is pretty good indication of this. If you were consistently getting the same error or gave us steps that could consistently reproduce an issue, there'd be something for us to investigate on the software side of things.
The first thing I would do is remove the NVMe drive and see if that returns the system to a stable state. If so, power/heat may be an issue and I would try returning the BIOS to defaults (except for disabling C-states as previously suggested) and again, try to recreate the problem.
-
Hi there,
I've passed this along to the devs to take a look. I'm guessing that this is only an appearance issue and that nothing functionally is broken (e.g. you can still assign more than 32GB of RAM to VMs and whatnot). Please confirm.
-
Can you confirm by rolling back to a previous release that these errors / hangs go away?
-
This is very odd behavior indeed. Just to ensure I understand correctly, you are stubbing a USB controller, two NVMe drives, a Wifi controller, and a GPU, and you were passing them all through to a VM just fine. Now if you pass through ANY kind of device to the VM, the VM enters this state:
On 1/2/2020 at 1:29 PM, Krzaku said:the first HT core is pinned at 100% while the others are 0%.
And furthermore this behavior is only exhibited when more than 9 vCPUs are assigned to the VM. So even if you just assign the NVMe SSD for the boot device and no other PCIe devices, the same behavior occurs?
-
Apologies for the delayed reply on this topic. Had to find a system that had enough RAM / CPUs to test this against. Just tested this on one of my test rigs here with an 8700k CPU that has 12 cores and 64GB of total RAM. I have a Windows 10 VM with a NVIDIA GPU for pass through (along with a dedicated USB controller). Normally I only had 8 cores assigned, so I bumped it up to 10 of the 12 cores pinned to the VM and it booted just fine.
I'm assuming when this happens, VM Manager is reporting the VM as started and probably stays in that state until you do a Force Shutdown. If that's true, it's even more difficult to diagnose because I don't see any errors in the logs or anything like that.
The first troubleshooting step I would take would be to stop assigning your GPU and USB device to the VM to see if it boots without PCI device pass through occurring. If that works, try adding the GPU back and see if that works (by itself). If that works, then it might be something with the USB device you're trying to assign to the VM. If it doesn't work, then there may be something odd with that GPU that doesn't like how virtual memory mapping works beyond the 32GB of RAM you previously had installed.
-
It's be a lot easier if you could just show me screenshots of the UI specific to network, CPU, and storage. I totally trust you have it working, I just want to see how the front end is configured and the qemu command line isn't quite good enough for me.It has a guy the same way unRAID has a gui. I did show you a config of a FreeBSD VM running on pve. You can just install PVE somewhere and run a VM and test this yourself. I can take you through the process but I can tell you right now - I ran a FreeBSD VM from the first try, from the first time I used PVE. Just select Q35, everything else is.... well.. self-explanatory.
Sent from my Pixel 3 XL using Tapatalk
-
Does ProxMox have a GUI? If so, can you show me the screen(s) for your configured FreeBSD VM? Can you post those details here?
Sent from my Pixel 3 XL using Tapatalk -
15 minutes ago, ChewbaccaBG said:
I won't argue with you, I just wish to see unRAID being able to handle all the major OSes @ VM, and not just because I need FreeBSD
As for the FreeBSD use, I think most of its use is on bare-metal, not VM.
As do we!! We definitely want folks to be able to run any application they want, and from any OS, but the ability to support that is limited when it comes to utilizing the most optimal virtual interfaces for storage and network (VirtIO). If you can switch from VirtIO to using an emulated controller (requires XML edits today), that should continue to work (also with an emulated CPU instead of host-passthrough). But using emulated interfaces like that will definitely showcase lower performance than if using their VirtIO counterparts. The problem is that in order to use VirtIO, someone has to build and maintain drivers for it on every guest OS that you wish to use it with. Windows has VirtIO drivers even (maintained by folks on the Fedora project). Not sure who is actively maintaining the FreeBSD VirtIO drivers, but I can venture a guess that if this is true:
32 minutes ago, ChewbaccaBG said:FreeBSD use, I think most of its use is on bare-metal, not VM.
Then maybe they don't bother maintaining the drivers at all. Maybe it's a community project that needs some TLC. We as a company certainly can't be responsible for maintaining support within platforms outside of our own. I'm sure you can appreciate that. I would argue as well that while convenient to run as a VM, maybe your work needs to give you some physical servers to run FreeBSD on directly if that's part of your job.
-
Meh, not to start a war of the OSes, but I don't think FreeBSD's major calling card is networking performance. Here's a study from 2019 showing FreeBSD holding its own, but not dominating Linux in any capacity: https://www.phoronix.com/scan.php?page=article&item=windows-linux-10gbe&num=4
And unless I'm mistaken, even Cisco UCS systems that support 40GBe+ connectivity don't even support FreeBSD.
The main benefit for FreeBSD over Linux is it's licensing model. CDDL allows developers to advance the platform without having to contribute any improvements to the code base back to the FreeBSD maintainers (if they don't want to). This is why so many companies make hardware appliances that use FreeBSD for their base OS (they can fine tune their product for maximum performance and then charge a premium for their efforts without allowing someone to just rip off their code that they spent time creating). CDDL also allows for compatibility with Oracle's licensing on ZFS, which is why Oracle has never sued FreeNAS (and frankly I bet that was the deciding factor that led FreeNAS to use FreeBSD in the first place).
Don't let any of this come across as me negating your reasons for needing FreeBSD though. A job's a job and if you need it for your job, well, then you need it. That said, I can't imagine the FreeBSD developers can really afford to let this issue linger. It's not like Linux KVM is a small platform anymore and I have to imagine the vast majority of FreeBSD users are using it in a VM (not bare metal). I could be wrong.
-
1
-
-
Unfortunately I'm not skilled enough to know what I'm looking for and the dev team is deep in the middle of other projects right now. I hate to say it, but I think we're going to be left with waiting for an official fix from FreeBSD. It really doesn't make sense for us to stop all other efforts and focus on a bugfix here when the FreeBSD devs themselves have already noted the issues with the driver in their OS and are working on a fix.
If ProxMox really figured out a work around, then it should work on Unraid as well, but they don't use libvirt which makes recreating what they are doing on Unraid much more difficult. I may be able to make more efforts in trying to get a build working here with some trial and error, but what I can't do is disrupt the devs to focus on analyzing ProxMox git repo to fix an issue that is already being fixed by FreeBSD upstream.
-
Been trying to get FreeBSD working in a VM with various configs/methods, but I'm failing to do so successfully. I'm wondering if Proxmox downgraded their kernel or quirked either it or QEMU to absolve themselves from this. In addition, are you sure on Proxmox the VM is loading via OVMF as opposed to a legacy BIOS? That might be another thing for us to try. In the end, I'm not sure if we're going to be able to do anything in the short term to resolve this.
-
There are a few other things I will try. Most notably a different NIC driver instead of VirtIO.Jon,
As posted earlier, i440fx does not work, it hangs when booting to the installer iso. From all the other reading I've done, I'm under the impression that it should work. I suspect that issue is unrelated, and may be specific to unRAID.
Sent from my Pixel 3 XL using Tapatalk
-
We ran into other problems that last time we updated the kernel. I will do an internal test to see if this even makes a difference but likely we will be waiting for a fix from FreeBSD. In the short term, they believe i440fx works ok. I'll test today to verify.
Sent from my Pixel 3 XL using Tapatalk -
It's good to know that this is seen as a driver but within freebsd though. I think we can safely hold off further efforts on this for now since a fix is forthcoming from freebsd.
Sent from my Pixel 3 XL using Tapatalk
As for the FreeBSD use, I think most of its use is on bare-metal, not VM.
Issues after upgrade to 6.8.0
in General Support
Posted
Let us know if you are 100% stable on 6.7.2.