Just did a Google search and concluded that "spinning dots" was as official a name as could be found amongst the top search results.  

 

When Windows 10 asks to restart for an update and you restart and then see TianoCore and the  spinning ( or as autocorrect likes to call it "SP mining") dots going for fifteen minutes, what exactly is happening?

 

Is the external USB dock I have connected to the VM delaying the startup process?  I've turned it off but the dots continue to spin.  The dots don't communicate specific information.  Should I force a VM shutdown so the VM startup process can start clean without any superfluous USB drives attached?  I guess I'll do that because the spinning dots have been going on for 26 minutes.  Long enough for me to struggle through autocorrect while touch typing this post on my iPhone.  (I prefer real keyboards, but my keyboard is attached to the spinning dots OS)

Forced stop and restarted VM and staring at spinning dots for 12 minutes.  Could it be the camera attached via usb that is keeping the spinning dots on so long or do I just have to be patient?

Edited December 18, 20214 yr by oh-tomo

How long has it been since my last post?  Must be 30 minutes.  Still spinning the dots are.  I could try another force stop. 

This time I forced stop, restarted unRAID and started the VM again.  Are the spinning dots masking the windows update progress and it just needs an hour to finish, which my impatience has been denying it?

This time I forced stop, unplugged all usb devices from the usb controller assigned to the VM, then started again, briefly connecting a usb keyboard to hit "enter" when the blue boot up screen asked for a restart selection.  

Does the spinng dots animation indicate that windows is doing something?  Should I just let it spin for two hours?  Or should I force stop it again and adjust the allocated ram setting?   

8 minutes ago, oh-tomo said:

Does the spinng dots animation indicate that windows is doing something?

Yes, but not necessarily productive something.

9 minutes ago, oh-tomo said:

Should I just let it spin for two hours?

When diagnosing bare metal windows in that condition, I'll often let things run for way more than 2 hours, but the times that's helped is fairly small. If it is indeed applying updates it typically will tell you that.

 

Perhaps set up a new VM, and point it at the current vdisk?

I switched the VM setting from Nvidia to VNC and was finally able to login to windows.  Couldn't tell if the update it was working on went through, so I shut down and re-enabled Nvidia and started again.  Spinning dots.  

My current approach is the "watched pot never boils" method.  I have no idea how long those dots spin but the Windows log in screen appears if I check back much much later.

USB on Win10 VM became unresponsive (maybe it can't handle having a usb webcam always on?) so I restarted Win10 and eight or so hours later Windows login screen still hadn't appeared so I've forced quit and started the VM from unRAID UI.  I don't see the spinning dots on the TianoCore screen.  Maybe a full unRAID reboot is necessary this time?

Did a full reboot of unraid.   Still no spinning dots on tianocore screen.  Left it for hours and hours.  Disconnected all usb devices.  Noticing cpu core 0 in unraid dashboard is 100% when VM started.  I guess I’ll just leave it for another eight hours and see if it finishes booting.  

Edited March 28, 20224 yr by oh-tomo

Checked again 10 hours later and VM boot still on the same TianoCore screen with no spinning dots.   Adjusted the Logical CPUs setting (i7-9700K) from 0 through 7 selected to just 1 and 2.   Not sure what the best Logical CPU setting is for an i7.  Maybe an i7 is unsuitable for unRAID?   So far not seeing any spinning dots.  Is the lack of spinning dots off the top a dead giveaway that boot will be stuck on that screen for 8 hours or until the end of time?   Is there a wiki checklist with red flags like "no spinning dots = not gonna work, try something else" on it?

 

Also forgot to mention that unRAID dashboard shows CPU 1 at 100%.

Edited March 28, 20224 yr by oh-tomo

I disabled the PCI device "VIA Technologies VL805/806 xHCI USB 3.0 Controller | USB controller (02:00.0)" and was able to boot.  Finally.  CPU 1 and 3 are both at 100%.   Gonna shut down and try to re-enable the PCI USB controller.

No spinning dots on TianoCore screen after re-enabling PCI USB controller.   Would the unRAID Tools/SysDevs page indicate something if this PCI device was having hardware issues?   I don't know how to interpret the spinning dots shyness in the presence of the PCI USB controller.   CPU 1 on the unRAID dashboard is 100%.

Instead of a full reboot of unRAID did a full shutdown, which is probably what the PCI USB controller needed because now I'm seeing the spinning dots again.   Is there a more robust PCI USB controller that won't require a full shutdown to keep running?

VL805/806 chipset can be problematic for passthrough, especially in linux, but some users here had it working in windows vm.

Did you look at the logs in your diagnostics to figure out if it's something happening on the host side or inside the vm?

On 3/29/2022 at 4:56 AM, ghost82 said:

VL805/806 chipset can be problematic for passthrough, especially in linux, but some users here had it working in windows vm.

Did you look at the logs in your diagnostics to figure out if it's something happening on the host side or inside the vm?

 

I have swapped out the Orico ("VIA Technologies VL805/806 xHCI USB 3.0 Controller") for a Rivo USB 3.0 card (appears as "Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)" in System Devices) because the Rivo was better reviewed than the Orico on Amazon.   Win10 VM boot up is just the TianoCore logo without the spinning dots and the log reports:

 

 

2022-05-12T18:22:54.274577Z qemu-system-x86_64: vfio_err_notifier_handler(0000:02:00.0) Unrecoverable error detected. Please collect any data possible and then kill the guest

When I edit the VM settings to disable the uPD720201 controller, Win10 boots fine.  Looking at the system log, I don't see anything referencing pcie issues.

 

<?xml version='1.0' encoding='UTF-8'?>
<domain type='kvm' id='12'>
  <name>Windows 10 VT</name>
  <uuid>b7d3fdd0-bad9-57c6-1819-514f71618295</uuid>
  <metadata>
    <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/>
  </metadata>
  <memory unit='KiB'>17301504</memory>
  <currentMemory unit='KiB'>17301504</currentMemory>
  <memoryBacking>
    <nosharepages/>
  </memoryBacking>
  <vcpu placement='static'>8</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='0'/>
    <vcpupin vcpu='1' cpuset='1'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='3'/>
    <vcpupin vcpu='4' cpuset='4'/>
    <vcpupin vcpu='5' cpuset='5'/>
    <vcpupin vcpu='6' cpuset='6'/>
    <vcpupin vcpu='7' cpuset='7'/>
  </cputune>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
    <nvram>/etc/libvirt/qemu/nvram/b7d3fdd0-bad9-57c6-1819-514f71618295_VARS-pure-efi.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <vendor_id state='on' value='none'/>
    </hyperv>
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' cores='8' threads='1'/>
    <cache mode='passthrough'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='hypervclock' present='yes'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/local/sbin/qemu</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source file='/mnt/disks/SSD_1TB/domains/Windows 10 VT/vdisk1.img' index='3'/>
      <backingStore/>
      <target dev='hdc' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/user/isos/Win10_1809Oct_v2_English_x64.iso' index='2'/>
      <backingStore/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <boot order='2'/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/user/isos/virtio-win-0.1.160-1.iso' index='1'/>
      <backingStore/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <alias name='ide0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <alias name='usb'/>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <alias name='usb'/>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <alias name='usb'/>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <controller type='ide' index='0'>
      <alias name='ide'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <alias name='virtio-serial0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:00:29:81'/>
      <source bridge='br0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/0'/>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
      <alias name='serial0'/>
    </serial>
    <console type='pty' tty='/dev/pts/0'>
      <source path='/dev/pts/0'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-12-Windows 10 VT/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='tablet' bus='usb'>
      <alias name='input0'/>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'>
      <alias name='input1'/>
    </input>
    <input type='keyboard' bus='ps2'>
      <alias name='input2'/>
    </input>
    <graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0' keymap='en-us'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    <sound model='ich9'>
      <alias name='sound0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </sound>
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+0:+100</label>
    <imagelabel>+0:+100</imagelabel>
  </seclabel>
</domain>

 

 

server2018-diagnostics-20220512-1449.zip

12 minutes ago, oh-tomo said:

2022-05-12T18:22:54.274577Z qemu-system-x86_64: vfio_err_notifier_handler(0000:02:00.0) Unrecoverable error detected. Please collect any data possible and then kill the guest

You should try:

pci=noaer

in your kernel arguments, modify the 'append' line of your syslinux configuration, reboot unraid and try.

Edited May 12, 20224 yr by ghost82

40 minutes ago, ghost82 said:

You should try:

pci=noaer

in your kernel arguments, modify the 'append' line of your syslinux configuration, reboot unraid and try.

 

Hey that worked.   Thanks.

 

So I saw this post suggesting the Inateck KT5001 as a suitable card.  I've installed the KT5001 and was able to boot into Win10 VM without the pci=noaer argument.  But it looks like the same VL805 chipset I started with.   Except it has 5 ports instead of 4.

 

11 hours ago, oh-tomo said:

I've installed the KT5001 and was able to boot into Win10 VM without the pci=noaer argument.  But it looks like the same VL805 chipset I started with

In my opinion Inateck is one of the brands that builds quality and cheap usb cards, its fresco chipset is one of the best.

In newer cards to be able to have more usb ports they use also the vli chipset.

Take into account that compatibility/incompatibility is not only based on the chipset, the card needs also a firmware (software) which is stored in an additional chip, and if the firmware is crap it wont work at all or it wont work as expected.

 

Moreover, I don't think they were using the same chipset: the kt5001 has 2 chipsets: the fresco FL1100 and the VL812.

Since you are saying that the "old" Orico card has 4 ports I'm quite sure it has only a single usb controller chipset, with no hub, probably a VL805 usb controller chipset.

 

The vl812 chipset is not a usb controller but a usb hub, so this is attached to the fl1100 controller (and that's why this card is compatible with mac os, because it's based on the fl1100 controller, which works out of the box, and the additional ports are that of a hub provided by the vl812, attached to this controller).

FL1100 can provide 4 usb ports, one of these is used by the vl812, which gives other 4 ports, so you have a total of 7 ports.

 

11 hours ago, oh-tomo said:

Except it has 5 ports

It doesn't have 5 ports, but 7; probably you didn't consider the internal header on the back of the card, which gives other 2 ports.

 

Edited May 14, 20224 yr by ghost82

Well I consider it 5 because I hadn't planned on using the internal two.  Leaving a webcam running for a few days on this new card has left it frozen (all connected usb ports non functioning) again.  Shutting down the VM and starting it again has reached the Tianocore logo without the spinning dots, which suggests that booting the VM won't be possible without shutting down unRAID and restarting.  So I'm in the same situation I was with the previous four port card.  

I restarted Windows and am looking at the spinning dots again.  Spinning is better than not spinning I think we’ve established, right?   It’s been going for over 30 minutes.  Not that I watched the spinning for 30 minutes but it was spinning when I first rebooted 30 minutes ago and now that I’m rechecking it 30 minutes later it is still spinning.  Before I selected restart in Windows I had just run MSI utility v2 and enabled MSI on both HD audio and NVidia graphics and set both to High.  Then when selecting restart I encountered the option to either update and restart or update and power down.  I selected update and restart.  So are the thirty plus minutes of TianoCore spinning dots because :

 

1) Windows is applying an update and needs (30+ minutes of) time to finish?

 

2) my changes using MSI Utility v2 are trapping my VM in a perpetual spinning dot state?

 

3) something else?

 

should I :

 

1) just wait it out?

 

2) force stop the VM and disable NVidia ?

 

3) something else?

"1) Just wait it out" worked.

 

Also audio seems to play better now with MSI enabled.

 

Edited July 10, 20223 yr by oh-tomo

It’s is 11:20am and I see the TianoCore spinning dots.   Around 11 hours ago I restarted Windows 10 to apply updates.  And went to bed.  So I don’t know what’s been going on in the past 11 hours.  I just see the spinning dots now.  Damn. Presumably at some point during the past 11 hour the Windows update finished?  But I don’t know when.  Unless the spinning dots is masking part of the Windows update process?  I’ve unplugged my USB hub from the USB card assigned to this VM if that’s what is keeping the spinning dots occupied.  But the dots still spin six minutes later.  
 

i just want to add that Windows has been nagging me about restarting to apply updates for some weeks.  And these spinning dots remind me why I was so reluctant to restart.   

Edited August 27, 20223 yr by oh-tomo