On 07/02/18 13:08, Jan Beulich wrote: >>>> On 07.02.18 at 14:01, <igor.druzhi...@citrix.com> wrote: >> So far the issue confirmed: >> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one >> that it was tested on), Intel S2600XX, etc. >> >> Also see: >> https://bugs.xenserver.org/browse/XSO-774 >> >> Well, no-watchdog is what we currently recommend in that case but we >> hoped there is a general solution here from Xen side. You have your >> point that they should fix this on their side because it's their fault >> indeed. But the user experience is also important for us I think. > Of course, hence the suggestion of possible alternative workarounds. > Impacting everyone is, as said, not a desirable approach in a case > like this one. I also continue to dislike the seemingly random division > by 10.
Xen's usability is crap, which is in large part due to attitude like this. It is not ok to expect the end user to know diagnose/debug issues like this, and it is entirely unreasonable to expect the end user to have to manually work around it. This particular issue does want feeding back to Intel so they can try and fix it, but whatever is wrong is present in a large amount of Skylake systems in the field. Xen needs to be able to cope. Finally, as to boot times, your argument is backwards seeing as you care about elapsed boot time. Slowing the frequency will speed everything up, as we aren't executing a large chunk of the BSP boot path with 100hz NMI constantly interrupting. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
