How long to let TianoCore and the spinning dots do their thing


oh-tomo
Go to solution Solved by oh-tomo,

Recommended Posts

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)

Link to comment
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?

Link to comment
  • 2 months later...
  • 2 weeks 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?

Link to comment

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 by oh-tomo
Link to comment

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 by oh-tomo
Link to comment

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

Link to comment
  • 1 month later...
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

Link to comment
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 by ghost82
Link to comment
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.

 

601231982_Frescovli.png.d1128b6ff9443cc9475a43ccc9c3003d.png.ea335a759149d6eddd67493ec47907a2.png

Edited by ghost82
Link to comment
  • 3 weeks later...

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.  

Link to comment
  • 1 month later...

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?

Link to comment
  • 1 month later...

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 by oh-tomo
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.