13 minutes ago, jlruss9777 said:

Any thoughts or ideas on why the problem with 6.6.3?

No clue without diagnostics.zip

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.

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.

 

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

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

 

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.

 

 

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.

There is a bug report about this. It will be fixed in the next release.

Deleted

Edited November 1, 20187 yr by Frank1940

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.

 

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?

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.

Sorry, got it fixed. Stupid mistakes on my end. All is working. Thanks for the development and support.

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?

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. 

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.

 

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.

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. 😀

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.

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:

 

 

 

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.

wish the parity history page listed the unraid version that check was running.

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

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...

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?