limetech Posted October 30, 2018 Author Share Posted October 30, 2018 13 minutes ago, jlruss9777 said: Any thoughts or ideas on why the problem with 6.6.3? No clue without diagnostics.zip Link to comment
bastl Posted October 30, 2018 Share Posted October 30, 2018 1 hour ago, jlruss9777 said: "internal error: Did not find USB device 093a:2510" You passthrough a USB Device to your VM which isn't connected anymore. I bet it's a mouse. Link to comment
s.Oliver Posted October 31, 2018 Share Posted October 31, 2018 19 hours ago, jlruss9777 said: Upgraded from 6.6.1 to 6.6.3. All but my VM was fine with the update. The single VM wouldn't start and gave the following execution error: "internal error: Did not find USB device 093a:2510" At the same time the VM Log would read: "2018-10-30 17:51:06.614+0000: shutting down, reason=failed" And the Sytem log would indicate: "Oct 30 13:51:06 LargeServer kernel: vfio-pci 0000:03:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none Oct 30 13:51:06 LargeServer kernel: vfio-pci 0000:03:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none" I have reverted to 6.6.1 and all is working again. Any thoughts or ideas on why the problem with 6.6.3? mostly sure, that an previous available & passed through usb-device, with identifier 093a:2510, isn't known/available to the qemu-process at launch time of your VM. you can look them up via "Tools > System Devices". when triggered it shows you a live view of all known devices – you simply can use your browsers search/find command to look for your device "093a:2510" if you think it has to be here (because you didn't change anything else). or, you do this on an older build of unRAID (you already reverted back i read), do the identification there (so you're sure the device with this adress is available) – make a screenshot of it – then upgrade again and re-identify this device. if it's there, note the adress of it, go to the VM tab, edit your VM and be sure to to passthrough the right device at the bottom. the other logged lines "...vfio-pci 0000:03:00.0..." do only indicate, that a pci-device (most probably your GFX card) was allocated to the VM at start time. Link to comment
Gico Posted October 31, 2018 Share Posted October 31, 2018 20 hours ago, limetech said: No clue without diagnostics.zip And how can I get use full information in my case? On 10/27/2018 at 7:07 PM, Gico said: The GUI is partially unresponsive. Had this yesterday and rebooted. Happened again now. I can get Main tab but without the array actions. Can't get dashboard & dockers tab. Tools --> diagnostics, and I'm on "Please wait" for 15 minutes now. Array shares are available. Dockers are not. Uninstalled nerdpack and rebooted. Update: It happened again. Syslog shows nothing meaningful. Any ideas? I can SSH but can't download diagnostics. Update 2: Downgraded to 6.6.2 Link to comment
jlruss9777 Posted October 31, 2018 Share Posted October 31, 2018 18 hours ago, bastl said: You passthrough a USB Device to your VM which isn't connected anymore. I bet it's a mouse. 52 minutes ago, s.Oliver said: mostly sure, that an previous available & passed through usb-device, with identifier 093a:2510, isn't known/available to the qemu-process at launch time of your VM. you can look them up via "Tools > System Devices". when triggered it shows you a live view of all known devices – you simply can use your browsers search/find command to look for your device "093a:2510" if you think it has to be here (because you didn't change anything else). or, you do this on an older build of unRAID (you already reverted back i read), do the identification there (so you're sure the device with this adress is available) – make a screenshot of it – then upgrade again and re-identify this device. if it's there, note the adress of it, go to the VM tab, edit your VM and be sure to to passthrough the right device at the bottom. the other logged lines "...vfio-pci 0000:03:00.0..." do only indicate, that a pci-device (most probably your GFX card) was allocated to the VM at start time. Thank you both for your insight. Turns out it was in fact a mouse! (my wife took it to use on her laptop). Crazy that something like that would stop the VM from starting all together. I reinstalled 6.6.3 with all peripherals attached this time and everything, VM included, so far works with no discernible hiccups. The rig is used as a data server, Plex media server, with the VM acting as a Steam game "server" to my other desktops. I guess i will see if removing the usb mouse and keyboard will affect any of the remote play abilities b/c i don't want to leave them hooked up all the time or have to find them every restart. Again guys, thank you very much. System: M/B: ASUSTeK COMPUTER INC. - Z9PA-D8 Series CPU: Intel® Xeon® CPU E5-2650 0 @ 2.00GHz (Dual) Memory: 64 GB Multi-bit ECC (max. installable capacity 256 GB) Network: bond0: transmit load balancing, mtu 1500 eth0: 1000 Mb/s, full duplex, mtu 1500 eth1: 1000 Mb/s, full duplex, mtu 1500 Cache Pool: x2 Samsung_SSD_860_EVO_500GB_S3Z1NB0K195539Z - 500 GB Storage: 12TB WD Red Drives 6 TB Parity Link to comment
wgstarks Posted October 31, 2018 Share Posted October 31, 2018 45 minutes ago, Gico said: And how can I get use full information in my case? Have you tried running diagnostics via ssh? Should write the diagnostics file to root/logs. You can also try Fix Common Problems plugin in troubleshooting mode. Link to comment
Harro Posted November 1, 2018 Share Posted November 1, 2018 Has anyone noticed that schedule for parity checks is being ignored and seems to run on the first of the month regardless of what scheduler is set at? I have had this since 6.6.2 and has happened again on 6.6.3. Not really a problem but with exchanging drives throughout the month and running drive rebuilding twice this month , I really didn't want a parity check until the 1st of the year, which is what the scheduler is set at. Link to comment
bonienl Posted November 1, 2018 Share Posted November 1, 2018 There is a bug report about this. It will be fixed in the next release. Link to comment
Harro Posted November 1, 2018 Share Posted November 1, 2018 2 minutes ago, bonienl said: There is a bug report about this. It will be fixed in the next release. 1 minute ago, Frank1940 said: You should probably post this issue here: https://forums.unraid.net/bug-reports/stable-releases/ Thank you it looks like it will be handled next release . Might hold off adding new drives until then, just for the sake of not putting any more stress on server until necessary. Link to comment
steve1977 Posted November 2, 2018 Share Posted November 2, 2018 Upgraded and rebooted. Unfortunatly, GUI does no longer show up. My Unraid machine runs headless, so I basically have no chance of trouble-shooting. Unraid also does not show as connected to the router. Any idea what it could be driving this issue? Link to comment
Squid Posted November 2, 2018 Share Posted November 2, 2018 16 minutes ago, steve1977 said: Any idea what it could be driving this issue? Not without at least a monitor connected to the machine. Without that at a minimum, it can't even be determined if unRaid is booting at all. Link to comment
steve1977 Posted November 2, 2018 Share Posted November 2, 2018 Sorry, got it fixed. Stupid mistakes on my end. All is working. Thanks for the development and support. Link to comment
Zer0Nin3r Posted November 3, 2018 Share Posted November 3, 2018 On 10/30/2018 at 1:18 PM, bastl said: You passthrough a USB Device to your VM which isn't connected anymore. I bet it's a mouse. On 10/31/2018 at 8:01 AM, jlruss9777 said: Thank you both for your insight. Turns out it was in fact a mouse! My understanding from trial & error is that you have to unmount/deselect your USB devices from the template before disconnecting them from the host/server/computer. Otherwise, when you go to start up the VM the next time around you will receive the error that you received. My question is, Is this a bug or standard operating procedure? Link to comment
bastl Posted November 4, 2018 Share Posted November 4, 2018 10 hours ago, Zer0Nin3r said: Is this a bug or standard operating procedure? I guess it's by design. If a user accidentally removes a passed through device he should get an error message of some sort. If he don't see it and the VM starts up fine and the device isn't usable as usual he might be more confused. A improvement would be to put the name from the device in the error message so it's easier to identify. Link to comment
bonienl Posted November 4, 2018 Share Posted November 4, 2018 10 hours ago, Zer0Nin3r said: you have to unmount/deselect your USB devices from the template before disconnecting them from the host/server/computer Yes this is the intended procedure, the user must explicitely tell to add or remove a device. This allows Unraid to give a warning when something goes missing before starting the VM. 8 minutes ago, bastl said: A improvement would be to put the name from the device in the error message Not sure if this is possible, but it is a good suggestion. Need to investigate. Link to comment
dlandon Posted November 4, 2018 Share Posted November 4, 2018 12 hours ago, Zer0Nin3r said: My question is, Is this a bug or standard operating procedure? Another way to handle this is to install the "Libvirt Hotplug USB" plugin and manage the USB device for the VM once it is started. Link to comment
cyberspectre Posted November 4, 2018 Share Posted November 4, 2018 Just want to report that my Ryzen machine has been up for a week now since the update, with no issues. In fact, VM performance has drastically improved. Before, I was getting stuttering when playing videos in any Windows browser but Edge. Now that I've updated, that no longer happens. 😀 Link to comment
Cessquill Posted November 5, 2018 Share Posted November 5, 2018 Just to chime in to reinforce some of the points some people are having... Parity check speeds - My monthly parity check (8TB array), which usually takes between 19-23 hours, took just under 1 day and 16 hours. Not much has changed since the last check - I've replaced a 1TB drive with an 8, and re-provisioned the 1TB as an Unassigned Device with a "Downloads" share. In theory this takes load off my main array. Drives Don't Spin Down - My drives don't seem to spin down. If anything I notice all but the parity drive spun up when there's not much activity. My diagnostics for this were posted previously. I have the Nerd Pack installed, but have only installed Python for the Speedtest plugin. Also have folder cache plugin and am manually starting it on reboot. Happy to resupply diagnostics when I'm back at the machine, but wanted to say that some issues in this thread are perhaps not fringe cases. Link to comment
JorgeB Posted November 5, 2018 Share Posted November 5, 2018 58 minutes ago, Cessquill said: Parity check speeds - My monthly parity check (8TB array), which usually takes between 19-23 hours, took just under 1 day and 16 hours. Check the syslog for call traces during the parity check, there are some users affected by that on the latest releases, that can be fixed by lowering md_sync_thresh, if it's not that I would be surprised if it's directly linked to the new release, since except for some users with very low end CPUs I don't remember seeing anyone complain, and it looks like you have an E3 v3 Xeon, I have a similar one, and it certainly didn't make any difference for me: Link to comment
Cessquill Posted November 5, 2018 Share Posted November 5, 2018 3 minutes ago, johnnie.black said: Check the syslog for call traces during the parity check, there are some users affected by that on the latest releases, that can be fixed by lowering md_sync_thresh, if it's not that I would be surprised if it's directly linked to the new release, since except for some users with very low end CPUs I don't remember seeing anyone complain, and it looks like you have an E3 v3 Xeon, I have a similar one, and it certainly didn't make any difference for me: Will do, thanks. Yes, I've got an E3 v3 on this. Link to comment
zoggy Posted November 5, 2018 Share Posted November 5, 2018 wish the parity history page listed the unraid version that check was running. Link to comment
JorgeB Posted November 5, 2018 Share Posted November 5, 2018 3 minutes ago, zoggy said: wish the parity history page listed the unraid version that check was running. Yeah, me too, also that it showed if it was a check, rebuild, clear, etc Link to comment
Cessquill Posted November 5, 2018 Share Posted November 5, 2018 3 hours ago, johnnie.black said: Check the syslog for call traces during the parity check, there are some users affected by that on the latest releases, that can be fixed by lowering md_sync_thresh, if it's not that I would be surprised if it's directly linked to the new release, since except for some users with very low end CPUs I don't remember seeing anyone complain, and it looks like you have an E3 v3 Xeon, I have a similar one, and it certainly didn't make any difference for me: Have rebooted since parity check, but current syslog has a call trace at 3.40 this morning, closely followed by an out of memory error. Looks like I've got some investigating to do... Link to comment
zoggy Posted November 5, 2018 Share Posted November 5, 2018 13 minutes ago, Cessquill said: Have rebooted since parity check, but current syslog has a call trace at 3.40 this morning, closely followed by an out of memory error. Looks like I've got some investigating to do... you use cache_dirs plugin? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.