summary refs log tree commit diff stats
path: root/results/classifier/gemma3:12b/hypervisor/864
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/gemma3:12b/hypervisor/86416
-rw-r--r--results/classifier/gemma3:12b/hypervisor/86449011
2 files changed, 27 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/hypervisor/864 b/results/classifier/gemma3:12b/hypervisor/864
new file mode 100644
index 000000000..ca986b2a6
--- /dev/null
+++ b/results/classifier/gemma3:12b/hypervisor/864
@@ -0,0 +1,16 @@
+
+HVF virtual counter diverges from CLOCK_VIRTUAL when the host sleeps
+Description of problem:
+HVF's virtual counter diverges from `CLOCK_VIRTUAL` when the host sleeps and causes the inconsistency between Linux's system counter and everything else.
+
+HVF's virtual counter apparently relies on something similar to `mach_absolute_time`, which stops when the host sleeps and resumes after it wakes up. However, `CLOCK_VIRTUAL` is implemented with `mach_continuous_time`, which continues even while the host sleeps. Linux uses the virtual counter as the source of the system counter and sees inconsistencies between the system counter and the other devices.
+Steps to reproduce:
+1. Launch Fedora.
+2. Compare the time shown at the top of the guest display and one at the top of the host display. The difference should be less than 2 minutes.
+3. Let the host sleep for 3 minutes.
+4. Compare the times again. The difference is now greater than 2 minutes.
+Additional information:
+Here are solutions I've came up with so far. There are trade-offs but any of them should be better than the current situation. I'm happy to implement one if the maintainers have decided which one is the best or figure out a superior alternative.
+- Implement `cpus_get_virtual_clock` of `AccelOpsClass` with `mach_absolute_time`. It would make HVF inconsistent with the other accelerators. Linux also expects the virtual clock is "continuous" and it leaves the divergence from the real time.
+- Request XNU `HOST_NOTIFY_CALENDAR_CHANGE` to update the virtual clock with the continuous time. The interface is undocumented.
+- Use `IORegisterForSystemPower` to update the virtual clock with the continuous time. It is undocumented that the interface handles every cases where `mach_absolute_time` and `mach_continuous_time`, but it actually does if I read XNU's source code correctly.
diff --git a/results/classifier/gemma3:12b/hypervisor/864490 b/results/classifier/gemma3:12b/hypervisor/864490
new file mode 100644
index 000000000..fb497cda4
--- /dev/null
+++ b/results/classifier/gemma3:12b/hypervisor/864490
@@ -0,0 +1,11 @@
+
+Windows 2008 x64 (SBS Server) freezes randomly when using more than 1 CPU core
+
+This issue has been giving headache to us since a long time.
+Difficult to reproduce as it happens randomly.
+We had this issue when we ran Windows 2008 x64 or Windows SBS Server guests in either XEN 3.3 or Proxmox environments.
+When only one CPU core is assigned to the guest, everything is fine. If 2 or more cores are assigned, the guest stops responding after several hours - and in the host machine one of the cores is using 100%. The only thing that helps is resetting the guest.
+
+I am ready to provide logs/crashdumps if needed, because we want to help resolve this issue. I saw some posts on the web of people having the same problems - for some of the workaround was to fix some BIOS settings, but we did not have success with those (e.g. disabling C1E Support and Intel C-State )
+
+Server is running on Intel® Core™ i7-920 Quad-Core, 24 Gig RAM.
\ No newline at end of file