Re: [Xen-users] dom0 USB failing with "ehci-pci: probe of 0000:00:1d.0 failed with error -110"

[Robin Lee <robinlee.sysu@xxxxxxxxx>]

On Thu, Feb 18, 2016 at 5:40 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>>> On 18.02.16 at 09:13, <robinlee.sysu@xxxxxxxxx> wrote:
> After a git-bisect test, the commit
> 724b55f48a6c9fca00ddeeca5a130657680caf0b is found the first one that
> introduces this issue.
> And that also suggests that setting 'mwait-idle=false' works around the
> issue. And this is also tested.
> So it may be a bug in 724b55f48a6c9fca00ddeeca5a130657680caf0b?

Provided you have most current microcode updates installed,
and provided you've read through all of the referenced Debian
bug and checked that this isn't - just like there - connected to an
apparently flawed BIOS, I'd suggest narrowing whether instead
of fully disabling the MWAIT idle driver just lowering the maximum
allowed C-state ("max_cstate=<number>"; try 3, 2, and 1 here)
would help.

Also I think this really belongs on xen-devel; you're actually lucky
that I spotted this mail since it ended up in a spam folder.

Jan

> On Wed, Feb 17, 2016 at 8:19 PM, Robin Lee <robinlee.sysu@xxxxxxxxx> wrote:
>
>> Hi all,
>>
>> I recently met the same problem of
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748052
>> Also xen-devel list:
>>
>>
> http://lists.xenproject.org/archives/html/xen-devel/2014-05/threads.html#0208
> 4
>> I copied the subject of this message.
>>
>> I tested previous versions of xen and found the issue was introduced in
>> xen 4.3.0. Any later versions up to 4.6.1 does not fix this issue.
>>
>> Dom0 Linux kernel version is 3.10 from XenServer 6.5SP1.
>>
>> I am new to xen debugging and willing to provide any additional
>> information if needed.
>>
>> Machine infomation:
>>
>> Mother board:
>> Intel Corporation S1200BTL
>>
>> CPU:
>> Intel(R) Xeon(R) CPU E3-1220 V2
>> # lspci
>> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM
>> Controller (rev 09)
>> 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network
>> Connection (rev 05)
>> 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
>> Family USB Enhanced Host Controller #2 (rev 05)
>> 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
>> PCI Express Root Port 1 (rev b5)
>> 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
>> PCI Express Root Port 5 (rev b5)
>> 00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
>> PCI Express Root Port 6 (rev b5)
>> 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
>> Family USB Enhanced Host Controller #1 (rev 05)
>> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
>> 00:1f.0 ISA bridge: Intel Corporation C204 Chipset Family LPC Controller
>> (rev 05)
>> 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset
>> Family SATA AHCI Controller (rev 05)
>> 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus
>> Controller (rev 05)
>> 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
>> Connection
>> 03:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
>> G200e [Pilot] ServerEngines (SEP1) (rev 04)
>> 04:00.0 Fibre Channel: QLogic Corp. ISP2312-based 2Gb Fibre Channel to
>> PCI-X HBA (rev 02)
>>
>>
>> -robin
>>

(copy to xen-devel)
The issue still exists with microcode updated.

And on this machine, nothing 'ACPI Error' like the Debian bug was seen.

And when max_cstate=2 is still bad, max_cstate=1 works.

But max_cstate=1 and mwait-idle=false are different,

which one is preferred to work around this issue?

-robin

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users