On Nov 28, 2014, at 00:50, Jan Beulich wrote:
On 28.11.14 at 09:24, wrote:
>>> And with 6 errata
>>> documented it's not all that unlikely that there's a 7th one with
>>> MONITOR/MWAIT behavior. The commit you bisected to (and
>>> which you had verified to be the culprit by just forcing
>>
On 11/27/2014 01:27 AM, Jan Beulich wrote:
This was precisely the reason why I told you that the numbering
differs (and is confusing and has nothing to do with actual C state
numbers): What max_cstate refers to in the mwait-idle driver is
what above is listed as type[Cx], i.e. the state at index
On 11/25/2014 03:00 AM, Jan Beulich wrote:
Okay, so it's not really the mwait-idle driver causing the regression,
but it is C-state related. Hence we're now down to seeing whether all
or just the deeper C states are affected, i.e. I now need to ask you
to play with "max_cstate=". For that you'll
On 11/25/2014 12:16 AM, Jan Beulich wrote:
(XEN) 'c' pressed -> printing ACPI Cx structures
(XEN) ==cpu0==
(XEN) active state:C0
(XEN) max_cstate:C7
(XEN) states:
(XEN) C1:type[C1] latency[001] usage[5664] method[ FFH]
duration[4042540627]
(XEN) C2:type[C3] l
On 24.11.14 at 10:08, wrote:
On Nov 24, 2014, at 00:45, Jan Beulich wrote:
On 23.11.14 at 02:28, wrote:
As promised, below is the apic-verbosity=debug log, with 'i'. Thanks!
I'm sorry, I misspelled the option, it's really "apic_verbosity=debug".
The 'i' output at least already confirms that
On Nov 24, 2014, at 00:45, Jan Beulich wrote:
On 23.11.14 at 02:28, wrote:
>> With mwait-idle=0:
>>
>> (XEN) 'c' pressed -> printing ACPI Cx structures
>> (XEN) ==cpu0==
>> (XEN) active state: C0
>> (XEN) max_cstate: C7
>> (XEN) states:
>> (XEN) C1: type[C1]
On 11/21/2014 0:42, Jan Beulich wrote:
On 20.11.14 at 21:07, wrote:
Running with mwait-idle=0 solves (hides?) the problem. Next step is to
fiddle with the C states?
For that I'd first of all like to know how much use of C states the
system still makes with that option in place. For that I'd ne
Hi Jan,
Thanks for all your help so far! Here's my latest update.
On 11/17/2014 23:54, Jan Beulich wrote:
Plus, without said adjustment, first just disable the
MWAIT CPU idle driver ("mwait-idle=0") and then, if that didn't make
a difference, use of C states altogether ("cpuidle=0"). If any of
On 11/17/2014 23:54, Jan Beulich wrote:
On 17.11.14 at 20:21, wrote:
Okay, I did a bisection and was not able to correlate the above error
message with the problem I'm seeing. Not saying it's not related, but I
had plenty of successful test runs in the presence of that error.
Took me about a w
Hi Jan,
On 11/11/2014 0:05, Jan Beulich wrote:
And these
[ 199.775209] pcieport :00:03.0: AER: Multiple Corrected error
received: id=0018
[ 199.775238] pcieport :00:03.0: PCIe Bus Error:
severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID)
[ 199.7
Hi,
I'm trying to do some bisection to find the cause of my VGA passthrough
issues, but gcc 4.9 is throwing too many warnings, all of which are
interpreted as errors, which kills the build. So I'm trying to compile
with 4.8. Unfortunately, ./configure chokes because it says it can't
find Pyth
On 11/10/2014 0:51, Jan Beulich wrote:
On 10.11.14 at 09:03, wrote:
Sorry for the delay, took some debugging on another computer to get
serial logging working. Due to its size, I've posted the entire log of a
crashed session here: http://pastebin.com/AiPHUZRH In this case I used a
3.0 gig memor
On 11/04/2014 02:15 AM, Jan Beulich wrote:
In fact this would not just be nice, but is strictly needed, and (as
with any pass-through related problems) additionally requires
running with "iommu=debug" alongside the usual need of setting
the log levels to the maximum.
Hi all,
Sorry for the del
13 matches
Mail list logo
