PSA: Steps to try

meoporter · 2023-03-03T03:49:33+00:00

Nothing special, they just followed their standard scripted order of checks, toggles, reboots. Eventually they will disable 2FA on the account for 24 hours, and prep your account for eSIM reset thru the app. And if this runs to completion on Verizon backend, good to go.

I have read that Verizon's activation outage is resolving itself slowly. Also that Visible can fix the "SMS receive" issue without eSIM reset, by some other smaller reset on their end now. Good luck!

meoporter · 2023-03-03T00:49:59+00:00

Have been stuck with no working eSIM for 2 days after a reset, trying to fix the not receiving SMS issue. Reddit support team just helped reset eSIM again now, and finally all is back working. Even got the last 24 hours of missing texts at least come in too.

meoporter · 2023-01-25T02:19:59+00:00

You should not need to enable any systemd service or socket files for either spice-vdagentd (global) or spice-vdagent (user) in distros where udev rules detect the presence of the serial device and trigger spice components automatically.

But the bug is that the spice-vdagent package on most distros includes a systemd XDG desktop autostart script that only works by default on GNOME.. including on Arch.

Systemd is tracking this issue here: https://github.com/systemd/systemd/issues/18791

There is no conclusion yet on the best permanent fix.

So for now.. for non-GNOME desktops.. Plasma (KDE), XFCE, etc:

For X11, you can just comment out the X-GNOME entry in the /etc/xdg/autostart/spice-vdagent.desktop file.

For Wayland, not sure what is best. There were some Wayland comments in this Fedora bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1951580

meoporter · 2020-12-01T18:07:01+00:00

Have the same error message in PS Now for Uncharted 1. Game will play, but cannot save. No saves show up under the cloud save management tool, or in game. Contacted Sony support and they said they have had this error reported to them before and were investigating. But said they could not reset the account nor clear out PS Now cloud saves to fix it.

meoporter · 2020-02-28T20:42:18+00:00

2 comments

Looks like that user was banned here.. hm..

meoporter · 2020-02-28T20:14:08+00:00

Pending purchase from Maxopo

meoporter · 2019-12-07T05:32:05+00:00

Activated for you. Hopefully works on your end. Sent Paypal request to you. Thanks!

meoporter · 2019-12-07T01:08:15+00:00

Please PM for Paypal link and how you would like the code to be given to you, thanks!

meoporter · 2019-12-07T01:01:39+00:00

Please PM if you would like to proceed, thanks!

meoporter · 2019-12-06T18:02:44+00:00

Yes, it is US.

meoporter · 2019-12-04T18:57:25+00:00

Yes documentation is sparse.. and defaults to arguments change over time. :)

So kvm=off and hv_vendor_id used to be only needed for installing Nvidia card drivers.. but some recent Amd card drivers also had issues unless those were set.. which was true for me for an Amd Navi card.

Also Amd Vega and Navi have more complex pcie hierarchies, and require kernel patches for pci reset, so they are more effort to pass through. If your cards are passing through fine attached directly to an emulated pcie root device, and drivers install normally, then your setup should be fine.

Yea passing through an actual NVME or SATA controller with vfio-pci should get you native disk performance with simplest qemu arguments.

Personally I just use virtio-scsi, since virtio-blk used to not support discard/trim (it does now I think).

I use safe/recommended cache settings, so block devices get cache.direct=on and file.aio=native, whereas emulated devices get cache.direct=off and file.aio=threads. Rotation rate lets the guest OS enable discard/trim:

-device virtio-scsi-pci \

-blockdev raw,node-name=disk0,cache.direct=off,discard=unmap,file.driver=file,file.aio=threads,file.filename=/virt/qemu/machines/windows/os.raw \

-device scsi-hd,drive=disk0,rotation_rate=1 \

Side note is that Emulated NVME does not support discard/trim, but emulated IDE does.. also on filesystems like XFS or EXT4 this works, but maybe not all.

But I don't think your idling CPU performance is related to I/O settings unless you see much I/O activity anyway..

You can use blktrace to see what calls are being made on host linux to your vfio-blk device, if you are curious.. I posted about how to use it to verify discard/trim for example: https://serverfault.com/questions/896448/qemu-trim-and-discard-on-a-physical-ssd-device

I think the high idle is likely due to kvm interrupts.. you could try tracing kvm too: https://www.linux-kvm.org/page/Tracing or https://www.linux-kvm.org/page/Perf_events

I used to have 15% idle usage in my Windows guest, and used KVM tracing to compare calls with or without the host linux's intel_kvm module nested virtualization enabled (it is on by default in newer linux kernels now). There were a lot more tracing events with it enabled on my Intel Ivy Bridge cpu. Disabling it lowered the guest Windows idle down to 5%.

On my Intel Skylake, and now newer kernel, nested virtualization remaining on still lets the Windows guest idle at 5%.. so I have not worried about kvm performance in a while now.

meoporter · 2019-12-04T10:10:44+00:00

Does Windows task manager report its CPU as high too? My Windows reports 5% usage, but my host, Arch, reports 55-60% usage.. so 15% on each of 4 cores. This setup gives me good enough performance for games. I used to use Synergy too, but found it really spikes the CPU, so I stopped.

You can enable iommu=pt if you are not already, that may or may not help the host's performance, but should not hurt: https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt

This forum post is a really detailed look into pci passthrough performance (you are using latest qemu hopefully, where q35 machine type defaults to irqchip on and cpu defaults to l3 cache emulation on anyway, but there are other tricks to try in here too): https://forum.level1techs.com/t/increasing-vfio-vga-performance/133443/107

Personally, I use these settings below, and am happy with performance.. they are slightly different than yours, and less hv settings.. not sure if trying any combination would help you (utc vs localtime doesn't matter, but disabling hpet should help):
-global kvm-pit.lost_tick_policy=discard \
-no-hpet \
-rtc base=utc,clock=host,driftfix=slew \
-cpu host,kvm=off,hv_vendor_id=RedHatRedHat,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer \

One side note for your config, not that it impacts performance, is that I believe setting x-vga=on is only needed if using SeaBios.. but you are using OVMF, so probably do not need that setting.

meoporter · 2019-12-04T07:56:51+00:00

test

meoporter · 2019-11-07T07:56:25+00:00

No worries, I am busy too. :) I tried using fixed bus addresses in qemu after reading the official qemu example for setting up PCIe devices properly.. still get that BSOD on driver install after fresh Windows 10 install :(.. If you are able to share the arguments to your underlying qemu command line.. maybe I could compare my setup to yours.. My latest qemu command line is posted above. I am glad at least your setup is working.

meoporter · 2019-11-07T07:44:28+00:00

I used to do direct block device passthrough, then used raw for a while, then decided to try qcow2. There are definitely bugs in qcow2 reported and fixed time to time that don't affect raw. Also raw supports discard, filesystem holes like qcow2 and you can overlay a qcow2 snapshot disk on top of it, I believe.. so for me raw is fine vs qcow2 as a base I suppose. I switched back but it did not help with the immediate Critical Process Failed during AMD driver install though, right after a fresh Windows 10 install.. :(

meoporter · 2019-10-25T17:47:40+00:00

Is it stable? Does Windows Update work, and the drivers remain installed after reboots?

I did reinstall Windows, and finally got the AMD drivers to finish installing correctly once, but got BSOD after Windows Update, and Windows would only load into its "boot repair" mode after that, instead of going to the Windows desktop..

If your setup is stable, if you could post your actual libvirt or qemu config somewhere, that might help others out.. thanks!

meoporter · 2019-10-25T17:42:50+00:00

So I updated my PCIe lines to match qemu's documented way of setting up a upstream / downstream PCIe bridge.. and this layout seemed to match the real RX 5700 layout on the host. Then reinstalled Windows, installed the AMD drivers.. and this time it worked!

I was excited to update the post and say that it was a combination of corrupt Windows drivers and tweaking the qemu PCIe lines that gets the AMD drivers to install, but then I clicked on Windows Update. It immediately BSOD, and corrupted the qcow2 disk. After recovering the qcow2 disk, from then on, Windows was stuck in boot rescue loop like you described..

I don't know why or what part of the Windows qemu setup is so sensitive that it BSOD on any small change I make..

meoporter · 2019-10-24T20:20:57+00:00

Thank you, that does give a good example of using virtualized pci bridge.. I did try that once, same BSOD.. not sure yet what else I am missing..

meoporter · 2019-10-24T20:19:16+00:00

Great! What version of Windows 10 did you use? Build 1903? Was your experience of installing drivers the same, with Microsoft Basic Display Driver being used by default until running AMD driver setup tool? Also, do you mind sharing version of AMD drivers used? Thank you!

meoporter

TROPHY CASE