* dom0 kernel - irq nobody cared ... the continuing saga ..
@ 2015-02-09 15:03 Sander Eikelenboom
2015-02-09 15:18 ` David Vrabel
0 siblings, 1 reply; 23+ messages in thread
From: Sander Eikelenboom @ 2015-02-09 15:03 UTC (permalink / raw)
To: Jan Beulich, David Vrabel, Konrad Rzeszutek Wilk; +Cc: xen-devel@lists.xen.org
Hi Jan / David / Konrad,
I was just testing a 3.19 kernel on my intel machine and again
ran into the sporadically appearing "irq nobody cared" on the dom0 kernel.
This occurs now for quite some kernel versions (running xen-unstable now,
but it also appeared in the past with builds that are now xen-4.5).
[ 1905.880200] irq 18: nobody cared (try booting with the "irqpoll" option)
[ 1905.914838] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-creanuc-20150209-doflr+ #1
[ 1905.935473] Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
[ 1905.956149] 0000000000000000 ffff8800596ae88c ffffffff81897311 ffff8800596ae800
[ 1905.976929] ffffffff81081554 ffff8800596ae800 0000000000000000 0000000000000000
[ 1905.997906] ffffffff81081961 0000000000000000 0000000000000000 0000000000000012
[ 1906.018751] Call Trace:
[ 1906.039416] <IRQ> [<ffffffff81897311>] ? dump_stack+0x40/0x50
[ 1906.060678] [<ffffffff81081554>] ? __report_bad_irq+0x1e/0xbb
[ 1906.081953] [<ffffffff81081961>] ? note_interrupt+0x1a9/0x234
[ 1906.102733] [<ffffffff8107fac7>] ? handle_irq_event_percpu+0xd7/0xf1
[ 1906.122995] [<ffffffff8107fb18>] ? handle_irq_event+0x37/0x57
[ 1906.143275] [<ffffffff8108224a>] ? handle_fasteoi_irq+0x74/0xcb
[ 1906.163455] [<ffffffff8107f4b2>] ? generic_handle_irq+0x15/0x20
[ 1906.182889] [<ffffffff813a6b0b>] ? evtchn_fifo_handle_events+0x138/0x16f
[ 1906.202356] [<ffffffff813a48c9>] ? __xen_evtchn_do_upcall+0x39/0x69
[ 1906.222156] [<ffffffff813a5c41>] ? xen_evtchn_do_upcall+0x27/0x36
[ 1906.241987] [<ffffffff818a015e>] ? xen_do_hypervisor_callback+0x1e/0x30
[ 1906.261917] <EOI> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
[ 1906.282116] [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
[ 1906.302364] [<ffffffff81007138>] ? xen_safe_halt+0xc/0x13
[ 1906.322525] [<ffffffff81013ae1>] ? default_idle+0x5/0x8
[ 1906.342592] [<ffffffff81078b8a>] ? cpu_startup_entry+0x114/0x25e
[ 1906.362771] [<ffffffff81efee9d>] ? start_kernel+0x422/0x42d
[ 1906.383029] [<ffffffff81efe880>] ? set_init_arg+0x50/0x50
[ 1906.402921] [<ffffffff81f019a0>] ? xen_start_kernel+0x4d3/0x4db
[ 1906.422483] handlers:
[ 1906.441717] [<ffffffff8155cd42>] ata_bmdma_interrupt
[ 1906.461174] Disabling IRQ #18
Is there any thing i could do / dump when this occurs or patch the kernel
to auto dump something to hopefully find out where this sporadic issue
comes from ?
Because previous attempts didn't seem to deliver any useful data, but i can't
trigger it, so probably i have to partly rely on hooking it up to the code
that leads to the "irq nobody cared" message, but probably on far less then
200000 iterations for it to contain something sensible.
The funky part is that this time it's the ata device with on ssd attached,
however i can still read and write normally (so it doesn't seem to need the irq ?)
/proc/interrupts shows the high count:
CPU0 CPU1 CPU2 CPU3
8: 0 0 0 0 xen-pirq-ioapic-edge rtc0
9: 1 0 0 0 xen-pirq-ioapic-level acpi
16: 29 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb3
18: 200000 0 0 0 xen-pirq-ioapic-level ata_generic
23: 23145 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb4
24: 111697 0 0 0 xen-percpu-virq timer0
25: 0 0 0 0 xen-percpu-ipi spinlock0
26: 12989 0 0 0 xen-percpu-ipi resched0
27: 1123 0 0 0 xen-percpu-ipi callfunc0
28: 0 0 0 0 xen-percpu-virq debug0
29: 330 0 0 0 xen-percpu-ipi callfuncsingle0
30: 1 0 0 0 xen-percpu-ipi irqwork0
31: 0 25012 0 0 xen-percpu-virq timer1
32: 0 1 0 0 xen-percpu-ipi spinlock1
33: 0 20107 0 0 xen-percpu-ipi resched1
34: 0 2232 0 0 xen-percpu-ipi callfunc1
35: 0 0 0 0 xen-percpu-virq debug1
36: 0 426 0 0 xen-percpu-ipi callfuncsingle1
37: 0 0 0 0 xen-percpu-ipi irqwork1
38: 0 0 82595 0 xen-percpu-virq timer2
39: 0 0 0 0 xen-percpu-ipi spinlock2
40: 0 0 83192 0 xen-percpu-ipi resched2
41: 0 0 1295 0 xen-percpu-ipi callfunc2
42: 0 0 0 0 xen-percpu-virq debug2
43: 0 0 372 0 xen-percpu-ipi callfuncsingle2
44: 0 0 0 0 xen-percpu-ipi irqwork2
45: 0 0 0 38677 xen-percpu-virq timer3
46: 0 0 0 0 xen-percpu-ipi spinlock3
47: 0 0 0 62021 xen-percpu-ipi resched3
48: 0 0 0 2130 xen-percpu-ipi callfunc3
49: 0 0 0 0 xen-percpu-virq debug3
50: 0 0 0 469 xen-percpu-ipi callfuncsingle3
51: 0 0 0 0 xen-percpu-ipi irqwork3
52: 2422 0 0 0 xen-dyn-event xenbus
53: 0 0 0 0 xen-percpu-virq xen-pcpu
55: 23 0 0 0 xen-pirq-msi mei_me
56: 26273 0 0 0 xen-pirq-msi 0000:00:1f.2
57: 143 0 0 0 xen-pirq-msi xhci_hcd
58: 1222 0 0 0 xen-dyn-event evtchn:xenstored
59: 0 0 0 0 xen-dyn-event evtchn:xenstored
60: 413 0 0 0 xen-dyn-event evtchn:xenstored
61: 1 0 0 0 xen-dyn-event evtchn:xenconsoled
62: 1345095 0 0 0 xen-dyn-event evtchn:qemu-system-i38
63: 46 0 0 0 xen-dyn-event evtchn:qemu-system-i38
64: 495 0 0 0 xen-dyn-event evtchn:xenstored
65: 16 0 0 0 xen-dyn-event evtchn:xenconsoled
66: 426359 0 0 0 xen-dyn-event evtchn:qemu-system-i38
67: 25116 0 0 0 xen-dyn-event evtchn:qemu-system-i38
68: 9085 0 0 0 xen-dyn-event evtchn:qemu-system-i38
69: 67 0 0 0 xen-dyn-event evtchn:qemu-system-i38
70: 11671 0 0 0 xen-dyn-event blkif-backend
71: 1657 0 0 0 xen-dyn-event blkif-backend
72: 19392 0 0 0 xen-dyn-event vif2.0-q0-tx
73: 1 0 0 0 xen-dyn-event vif2.0-q0-rx
74: 503 0 0 0 xen-dyn-event blkif-backend
75: 14565 0 0 0 xen-dyn-event vif1.0-q0-tx
76: 1 0 0 0 xen-dyn-event vif1.0-q0-rx
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 0 0 0 0 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 0 0 0 0 Performance monitoring interrupts
IWI: 1 0 0 0 IRQ work interrupts
RTR: 0 0 0 0 APIC ICR read retries
RES: 12989 20107 83193 62022 Rescheduling interrupts
CAL: 1453 2658 1667 2599 Function call interrupts
TLB: 0 0 0 0 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 9 9 9 9 Machine check polls
HYP: 2196482 47720 167263 103207 Hypervisor callback interrupts
ERR: 0
MIS: 0
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-09 15:03 dom0 kernel - irq nobody cared ... the continuing saga Sander Eikelenboom @ 2015-02-09 15:18 ` David Vrabel 2015-02-09 15:39 ` Sander Eikelenboom 2015-02-09 16:36 ` Jan Beulich 0 siblings, 2 replies; 23+ messages in thread From: David Vrabel @ 2015-02-09 15:18 UTC (permalink / raw) To: Sander Eikelenboom, Jan Beulich, David Vrabel, Konrad Rzeszutek Wilk Cc: xen-devel@lists.xen.org On 09/02/15 15:03, Sander Eikelenboom wrote: > Hi Jan / David / Konrad, > > I was just testing a 3.19 kernel on my intel machine and again > ran into the sporadically appearing "irq nobody cared" on the dom0 kernel. > This occurs now for quite some kernel versions (running xen-unstable now, > but it also appeared in the past with builds that are now xen-4.5). I wouldn't suspect anything Xen related here. IRQ #18 is a shared line-level interrupt so other driver/device that was/is sharing than line is misbehaving. I'd recommend seeing if your BIOS has a option to put the disk controllers into AHCI mode which would allow them to use MSIs (I think). David ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-09 15:18 ` David Vrabel @ 2015-02-09 15:39 ` Sander Eikelenboom 2015-02-09 16:36 ` Jan Beulich 1 sibling, 0 replies; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-09 15:39 UTC (permalink / raw) To: David Vrabel; +Cc: xen-devel@lists.xen.org, Jan Beulich Monday, February 9, 2015, 4:18:15 PM, you wrote: > On 09/02/15 15:03, Sander Eikelenboom wrote: >> Hi Jan / David / Konrad, >> >> I was just testing a 3.19 kernel on my intel machine and again >> ran into the sporadically appearing "irq nobody cared" on the dom0 kernel. >> This occurs now for quite some kernel versions (running xen-unstable now, >> but it also appeared in the past with builds that are now xen-4.5). > I wouldn't suspect anything Xen related here. IRQ #18 is a shared > line-level interrupt so other driver/device that was/is sharing than > line is misbehaving. > I'd recommend seeing if your BIOS has a option to put the disk > controllers into AHCI mode which would allow them to use MSIs (I think). > David There seems to be an bios update so that's worth a shot. -- Sander ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-09 15:18 ` David Vrabel 2015-02-09 15:39 ` Sander Eikelenboom @ 2015-02-09 16:36 ` Jan Beulich 2015-02-09 17:13 ` Sander Eikelenboom 1 sibling, 1 reply; 23+ messages in thread From: Jan Beulich @ 2015-02-09 16:36 UTC (permalink / raw) To: David Vrabel, Sander Eikelenboom; +Cc: xen-devel@lists.xen.org >>> On 09.02.15 at 16:18, <david.vrabel@citrix.com> wrote: > On 09/02/15 15:03, Sander Eikelenboom wrote: >> Hi Jan / David / Konrad, >> >> I was just testing a 3.19 kernel on my intel machine and again >> ran into the sporadically appearing "irq nobody cared" on the dom0 kernel. >> This occurs now for quite some kernel versions (running xen-unstable now, >> but it also appeared in the past with builds that are now xen-4.5). > > I wouldn't suspect anything Xen related here. IRQ #18 is a shared > line-level interrupt so other driver/device that was/is sharing than > line is misbehaving. > > I'd recommend seeing if your BIOS has a option to put the disk > controllers into AHCI mode which would allow them to use MSIs (I think). But iirc previous instances weren't always pointing at a disk controller, and hence dealing with that as a special case won't make the underlying problem go away. Sander, this looking different from previous reports of yours - is this different (or differently configured) hardware now? In which case knowing what other devices sit on that same IRQ would (again) be necessary, including which of them you pass to guests. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-09 16:36 ` Jan Beulich @ 2015-02-09 17:13 ` Sander Eikelenboom 2015-02-10 8:48 ` Jan Beulich 0 siblings, 1 reply; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-09 17:13 UTC (permalink / raw) To: Jan Beulich; +Cc: David Vrabel, xen-devel@lists.xen.org Monday, February 9, 2015, 5:36:28 PM, you wrote: >>>> On 09.02.15 at 16:18, <david.vrabel@citrix.com> wrote: >> On 09/02/15 15:03, Sander Eikelenboom wrote: >>> Hi Jan / David / Konrad, >>> >>> I was just testing a 3.19 kernel on my intel machine and again >>> ran into the sporadically appearing "irq nobody cared" on the dom0 kernel. >>> This occurs now for quite some kernel versions (running xen-unstable now, >>> but it also appeared in the past with builds that are now xen-4.5). >> >> I wouldn't suspect anything Xen related here. IRQ #18 is a shared >> line-level interrupt so other driver/device that was/is sharing than >> line is misbehaving. >> >> I'd recommend seeing if your BIOS has a option to put the disk >> controllers into AHCI mode which would allow them to use MSIs (I think). > But iirc previous instances weren't always pointing at a disk > controller, and hence dealing with that as a special case won't > make the underlying problem go away. > Sander, this looking different from previous reports of yours - > is this different (or differently configured) hardware now? In > which case knowing what other devices sit on that same IRQ > would (again) be necessary, including which of them you pass to > guests. > Jan S-ata controller is already in AHCI mode and using MSI, it actually was the IDE controller that was on irq 18. Yes the device that tries to handle the interrupt seems to change .. however that device is always not actively used. This time it was an unused IDE controller with driver loaded in dom0 and a mini-pcie wifi card passed through to a guest. But i did a bios update like David suggested and now the IDE controller is gone (which is chipset only since it lacks a physical connector anyway). Now it is sharing the IRQ with the SMbus: 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) Subsystem: Intel Corporation Device 204f Flags: medium devsel, IRQ 18 Memory at f7d35000 (64-bit, non-prefetchable) [size=256] I/O ports at f040 [size=32] 02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Lenovo Device 30a1 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at f7c00000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [170] Power Budgeting <?> Kernel driver in use: pciback Why it seems so keen on interrupt sharing eludes me completely. Also wondering why it doesn't enable MSI on the WIFI NIC, but perhaps the driver doesn't support it .. will have to look at that later and see what it does when booting baremetal. -- Sander ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-09 17:13 ` Sander Eikelenboom @ 2015-02-10 8:48 ` Jan Beulich 2015-02-10 9:19 ` Sander Eikelenboom 0 siblings, 1 reply; 23+ messages in thread From: Jan Beulich @ 2015-02-10 8:48 UTC (permalink / raw) To: Sander Eikelenboom, Konrad RzeszutekWilk Cc: David Vrabel, xen-devel@lists.xen.org >>> On 09.02.15 at 18:13, <linux@eikelenboom.it> wrote: > Yes the device that tries to handle the interrupt seems to change .. > however that device is always not actively used. > This time it was an unused IDE controller with driver loaded in dom0 > and a mini-pcie wifi card passed through to a guest. > > But i did a bios update like David suggested and now the IDE controller > is gone (which is chipset only since it lacks a physical connector anyway). > > Now it is sharing the IRQ with the SMbus: > > 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus > Controller (rev 04) > Subsystem: Intel Corporation Device 204f > Flags: medium devsel, IRQ 18 > Memory at f7d35000 (64-bit, non-prefetchable) [size=256] > I/O ports at f040 [size=32] > > 02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless > Network Adapter (PCI-Express) (rev 01) > Subsystem: Lenovo Device 30a1 > Flags: bus master, fast devsel, latency 0, IRQ 18 > Memory at f7c00000 (64-bit, non-prefetchable) [size=64K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- > Capabilities: [60] Express Legacy Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Virtual Channel > Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 > Capabilities: [170] Power Budgeting <?> > Kernel driver in use: pciback > > Why it seems so keen on interrupt sharing eludes me completely. Coming back to the /proc/interrupts output you posted earlier: /proc/interrupts shows the high count: CPU0 CPU1 CPU2 CPU3 8: 0 0 0 0 xen-pirq-ioapic-edge rtc0 9: 1 0 0 0 xen-pirq-ioapic-level acpi 16: 29 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb3 18: 200000 0 0 0 xen-pirq-ioapic-level ata_generic I would have thought that xen-pciback would install an interrupt handler here too when a device using IRQ 18 gets handed to a guest. May there be something broken in xen_pcibk_control_isr()? > Also wondering why it doesn't enable MSI on the WIFI NIC, but perhaps the > driver > doesn't support it .. will have to look at that later and see what it does > when > booting baremetal. Did you check whether the respective driver is capable of using MSI? Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 8:48 ` Jan Beulich @ 2015-02-10 9:19 ` Sander Eikelenboom 2015-02-10 9:35 ` Jan Beulich 0 siblings, 1 reply; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-10 9:19 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel@lists.xen.org, David Vrabel Tuesday, February 10, 2015, 9:48:09 AM, you wrote: >>>> On 09.02.15 at 18:13, <linux@eikelenboom.it> wrote: >> Yes the device that tries to handle the interrupt seems to change .. >> however that device is always not actively used. >> This time it was an unused IDE controller with driver loaded in dom0 >> and a mini-pcie wifi card passed through to a guest. >> >> But i did a bios update like David suggested and now the IDE controller >> is gone (which is chipset only since it lacks a physical connector anyway). >> >> Now it is sharing the IRQ with the SMbus: >> >> 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus >> Controller (rev 04) >> Subsystem: Intel Corporation Device 204f >> Flags: medium devsel, IRQ 18 >> Memory at f7d35000 (64-bit, non-prefetchable) [size=256] >> I/O ports at f040 [size=32] >> >> 02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless >> Network Adapter (PCI-Express) (rev 01) >> Subsystem: Lenovo Device 30a1 >> Flags: bus master, fast devsel, latency 0, IRQ 18 >> Memory at f7c00000 (64-bit, non-prefetchable) [size=64K] >> Capabilities: [40] Power Management version 3 >> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- >> Capabilities: [60] Express Legacy Endpoint, MSI 00 >> Capabilities: [100] Advanced Error Reporting >> Capabilities: [140] Virtual Channel >> Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 >> Capabilities: [170] Power Budgeting <?> >> Kernel driver in use: pciback >> >> Why it seems so keen on interrupt sharing eludes me completely. > Coming back to the /proc/interrupts output you posted earlier: > /proc/interrupts shows the high count: > CPU0 CPU1 CPU2 CPU3 > 8: 0 0 0 0 xen-pirq-ioapic-edge rtc0 > 9: 1 0 0 0 xen-pirq-ioapic-level acpi > 16: 29 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb3 > 18: 200000 0 0 0 xen-pirq-ioapic-level ata_generic > I would have thought that xen-pciback would install an interrupt > handler here too when a device using IRQ 18 gets handed to a > guest. May there be something broken in xen_pcibk_control_isr()? It seems to only do that for PV guests, not for HVM. Don't know how it wil go now after the bios update, lspci lists the SMBUS is also using irq 18 now, but it doesn't register a driver (according to lspci -k) and it doesn't appear in dom0's /proc/interrupts. How are things supposed to work with a machine with: - a shared irq - iommu + interrupt remapping enabled - HVM guests Would dom0 always see the legacy irq or is Xen or the iommu routing it directly to the guest ? And what would i suppose to see when using Xen's debug key 'i', should there be an entry routing it to both guests ? In dom0 i see: 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) Subsystem: Intel Corporation Device 204f Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin C routed to IRQ 18 Region 0: Memory at f7d35000 (64-bit, non-prefetchable) [size=256] Region 4: I/O ports at f040 [size=32] 02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Lenovo Device 30a1 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 But Xen says: (XEN) [2015-02-10 09:10:27.040] IRQ: 0 affinity:1 vec:f0 type=IO-APIC-edge status=00000000 timer_interrupt() (XEN) [2015-02-10 09:10:27.040] IRQ: 1 affinity:1 vec:38 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 3 affinity:1 vec:40 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 4 affinity:1 vec:48 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 5 affinity:1 vec:50 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 6 affinity:1 vec:58 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 7 affinity:1 vec:60 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 8 affinity:1 vec:68 type=IO-APIC-edge status=00000030 in-flight=0 domain-list=0: 8(---), (XEN) [2015-02-10 09:10:27.040] IRQ: 9 affinity:1 vec:70 type=IO-APIC-level status=00000030 in-flight=0 domain-list=0: 9(---), (XEN) [2015-02-10 09:10:27.040] IRQ: 10 affinity:1 vec:78 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 11 affinity:1 vec:88 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 12 affinity:1 vec:90 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 13 affinity:f vec:98 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 14 affinity:1 vec:a0 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 15 affinity:1 vec:a8 type=IO-APIC-edge status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 16 affinity:1 vec:b0 type=IO-APIC-level status=00000030 in-flight=0 domain-list=0: 16(---), (XEN) [2015-02-10 09:10:27.040] IRQ: 18 affinity:1 vec:c0 type=IO-APIC-level status=00000010 in-flight=0 domain-list=3: 18(---), (XEN) [2015-02-10 09:10:27.040] IRQ: 19 affinity:f vec:d0 type=IO-APIC-level status=00000002 mapped, unbound (XEN) [2015-02-10 09:10:27.040] IRQ: 20 affinity:2 vec:c8 type=IO-APIC-level status=00000010 in-flight=0 domain-list=3: 20(-M-), (XEN) [2015-02-10 09:10:27.040] IRQ: 23 affinity:8 vec:b8 type=IO-APIC-level status=00000010 in-flight=0 domain-list=0: 23(---), (XEN) [2015-02-10 09:10:27.040] IRQ: 24 affinity:f vec:28 type=DMA_MSI status=00000000 iommu_page_fault() (XEN) [2015-02-10 09:10:27.040] IRQ: 25 affinity:f vec:30 type=DMA_MSI status=00000000 iommu_page_fault() (XEN) [2015-02-10 09:10:27.040] IRQ: 26 affinity:1 vec:d8 type=PCI-MSI status=00000030 in-flight=0 domain-list=0:599(---), (XEN) [2015-02-10 09:10:27.040] IRQ: 27 affinity:2 vec:21 type=PCI-MSI status=00000030 in-flight=0 domain-list=0:598(---), (XEN) [2015-02-10 09:10:27.040] IRQ: 28 affinity:1 vec:29 type=PCI-MSI status=00000030 in-flight=0 domain-list=0:597(---), (XEN) [2015-02-10 09:10:27.040] IRQ: 29 affinity:1 vec:59 type=PCI-MSI status=00000010 in-flight=0 domain-list=3: 54(---), So since domain-list only has domain 3 listed for irq 18, I would interpret that as that Xen (/ the iommu if it's involved) should never let irq 18 arrive at dom0, but my interpretations regarding irq's at how that works have been proven to be quite flaky :-) At the moment i have annotated the dom0 kernel with (in the hope it does trigger again some day): @@ -215,6 +216,13 @@ __report_bad_irq(unsigned int irq, struct irq_desc *desc, action = desc->action; while (action) { printk(KERN_ERR "[<%p>] %pf", action->handler, action->handler); + + if(action->name){ + printk(KERN_ERR "?!?!?!? action->name: %s shared:%d dev_id:%d\n", action->name, (action->flags & IRQF_SHARED) ? 1 : 0, action->dev_id ? 1 : 0); + } else { + printk(KERN_ERR "?!?!?!? action->name: No name shared:%d dev_id:%d\n", (action->flags & IRQF_SHARED) ? 1 : 0, action->dev_id ? 1 : 0); + } + if (action->thread_fn) printk(KERN_CONT " threaded [<%p>] %pf", action->thread_fn, action->thread_fn); It seems the dev_id cookie seems to be device specific, so probably a bit harder to print .. if you know some better way to figure out where the irq storm is coming from or headed to .. i'm all ears (or eyes) .. -- Sander >> Also wondering why it doesn't enable MSI on the WIFI NIC, but perhaps the >> driver >> doesn't support it .. will have to look at that later and see what it does >> when >> booting baremetal. > Did you check whether the respective driver is capable of using > MSI? > Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 9:19 ` Sander Eikelenboom @ 2015-02-10 9:35 ` Jan Beulich 2015-02-10 10:03 ` Sander Eikelenboom 2015-02-10 13:07 ` Sander Eikelenboom 0 siblings, 2 replies; 23+ messages in thread From: Jan Beulich @ 2015-02-10 9:35 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: David Vrabel, xen-devel@lists.xen.org >>> On 10.02.15 at 10:19, <linux@eikelenboom.it> wrote: >> Coming back to the /proc/interrupts output you posted earlier: > >> /proc/interrupts shows the high count: > >> CPU0 CPU1 CPU2 CPU3 >> 8: 0 0 0 0 xen-pirq-ioapic-edge rtc0 >> 9: 1 0 0 0 xen-pirq-ioapic-level acpi >> 16: 29 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb3 >> 18: 200000 0 0 0 xen-pirq-ioapic-level ata_generic > >> I would have thought that xen-pciback would install an interrupt >> handler here too when a device using IRQ 18 gets handed to a >> guest. May there be something broken in xen_pcibk_control_isr()? > > It seems to only do that for PV guests, not for HVM. Interesting; no idea why that would be. > Don't know how it wil go now after the bios update, > lspci lists the SMBUS is also using irq 18 now, but it doesn't register > a driver (according to lspci -k) and it doesn't appear in dom0's > /proc/interrupts. With that I don't think you're going to have problems, as the IRQ then is masked. > How are things supposed to work with a machine with: > - a shared irq > - iommu + interrupt remapping enabled > - HVM guests Konrad? > Would dom0 always see the legacy irq or is Xen or the iommu routing it > directly to > the guest ? A shared IRQ can't be routed directly, as all involved domains need to see it. > And what would i suppose to see when using Xen's debug key 'i', should there > be an entry routing it to both guests ? Yes, if both have a driver using it. >. if you know some better way to figure out where the irq storm is > coming from or headed to .. i'm all ears (or eyes) .. I suppose that's because there's no handler installed by pciback, yet IRQs generated by the passed through device also arrive in Dom0, and the driver for the device left in Dom0 doesn't claim the interrupts. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 9:35 ` Jan Beulich @ 2015-02-10 10:03 ` Sander Eikelenboom 2015-02-10 10:36 ` Jan Beulich 2015-02-10 13:07 ` Sander Eikelenboom 1 sibling, 1 reply; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-10 10:03 UTC (permalink / raw) To: Jan Beulich; +Cc: David Vrabel, xen-devel@lists.xen.org Tuesday, February 10, 2015, 10:35:36 AM, you wrote: >>>> On 10.02.15 at 10:19, <linux@eikelenboom.it> wrote: >>> Coming back to the /proc/interrupts output you posted earlier: >> >>> /proc/interrupts shows the high count: >> >>> CPU0 CPU1 CPU2 CPU3 >>> 8: 0 0 0 0 xen-pirq-ioapic-edge rtc0 >>> 9: 1 0 0 0 xen-pirq-ioapic-level acpi >>> 16: 29 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb3 >>> 18: 200000 0 0 0 xen-pirq-ioapic-level ata_generic >> >>> I would have thought that xen-pciback would install an interrupt >>> handler here too when a device using IRQ 18 gets handed to a >>> guest. May there be something broken in xen_pcibk_control_isr()? >> >> It seems to only do that for PV guests, not for HVM. > Interesting; no idea why that would be. >> Don't know how it wil go now after the bios update, >> lspci lists the SMBUS is also using irq 18 now, but it doesn't register >> a driver (according to lspci -k) and it doesn't appear in dom0's >> /proc/interrupts. > With that I don't think you're going to have problems, as the IRQ > then is masked. Is there an easy way to verify that it's indeed masked ? >> How are things supposed to work with a machine with: >> - a shared irq >> - iommu + interrupt remapping enabled >> - HVM guests > Konrad? >> Would dom0 always see the legacy irq or is Xen or the iommu routing it >> directly to >> the guest ? > A shared IRQ can't be routed directly, as all involved domains need > to see it. >> And what would i suppose to see when using Xen's debug key 'i', should there >> be an entry routing it to both guests ? > Yes, if both have a driver using it. Yes, so when no driver enables it, xen won't list it either, then my thinking was correct at that point. >>. if you know some better way to figure out where the irq storm is >> coming from or headed to .. i'm all ears (or eyes) .. > I suppose that's because there's no handler installed by pciback, yet > IRQs generated by the passed through device also arrive in Dom0, > and the driver for the device left in Dom0 doesn't claim the interrupts. Yes so just for my idea of what happened (and i have googled): the irq arrived at dom0 .. it went through the registered handlers: [ 1906.422483] handlers: [ 1906.441717] [<ffffffff8155cd42>] ata_bmdma_interrupt In this case .. there is only one .. the handler verifies if it should actually handle this irq by the dev_id cookie, in this case it doesn't .. there are no handlers .. so after 200000 of those linux says hey we have an interrupt that nobody cared about. So there is a chance it's an irq that was actually destined to the device that was passed through, but that didn't handle it ? If that's the case .. why .. wasn't it handled in time .. or was it shutdown .. or ... I can't remember if this even happens on shutdown of the guest (and i think i should if it was). However is there a small chance on a race on guest shutdown, when the guest doesn't disable the device properly it self on shutdown ? (i ask that because HVM guests don't cleanup properly on shutdown, due to the xenstore entry still being "initialized" instead of "connected", so on cleanup the guest kernel reports "initialized != connected" and doesn't cleanup. (and the xenstore entry being not set to connected is due to libxl not properly setting the states). -- Sander > Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 10:03 ` Sander Eikelenboom @ 2015-02-10 10:36 ` Jan Beulich 2015-02-10 10:47 ` Sander Eikelenboom 0 siblings, 1 reply; 23+ messages in thread From: Jan Beulich @ 2015-02-10 10:36 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: David Vrabel, xen-devel@lists.xen.org >>> On 10.02.15 at 11:03, <linux@eikelenboom.it> wrote: > Tuesday, February 10, 2015, 10:35:36 AM, you wrote: >> I suppose that's because there's no handler installed by pciback, yet >> IRQs generated by the passed through device also arrive in Dom0, >> and the driver for the device left in Dom0 doesn't claim the interrupts. > > Yes so just for my idea of what happened (and i have googled): > the irq arrived at dom0 .. it went through the registered handlers: > [ 1906.422483] handlers: > [ 1906.441717] [<ffffffff8155cd42>] ata_bmdma_interrupt > > In this case .. there is only one .. the handler verifies if it should > actually handle this irq by the dev_id cookie, in this case it doesn't > .. there are no handlers .. so after 200000 of those linux says hey we > have an interrupt that nobody cared about. > > So there is a chance it's an irq that was actually destined to the device > that was passed through, but that didn't handle it ? > If that's the case .. why .. wasn't it handled in time .. or was it shutdown > .. > or ... No - such a shared IRQ gets sent to both domains. There's no notion of one domain claiming it and the other then not seeing it, as any instance of the interrupt may mean more than one of the devices signaled it - remember that shared interrupts are always level triggered, i.e. there is no way of telling how many devices request servicing. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 10:36 ` Jan Beulich @ 2015-02-10 10:47 ` Sander Eikelenboom 2015-02-10 10:57 ` Jan Beulich 2015-02-10 10:59 ` Andrew Cooper 0 siblings, 2 replies; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-10 10:47 UTC (permalink / raw) To: Jan Beulich; +Cc: David Vrabel, xen-devel@lists.xen.org Tuesday, February 10, 2015, 11:36:48 AM, you wrote: >>>> On 10.02.15 at 11:03, <linux@eikelenboom.it> wrote: >> Tuesday, February 10, 2015, 10:35:36 AM, you wrote: >>> I suppose that's because there's no handler installed by pciback, yet >>> IRQs generated by the passed through device also arrive in Dom0, >>> and the driver for the device left in Dom0 doesn't claim the interrupts. >> >> Yes so just for my idea of what happened (and i have googled): >> the irq arrived at dom0 .. it went through the registered handlers: >> [ 1906.422483] handlers: >> [ 1906.441717] [<ffffffff8155cd42>] ata_bmdma_interrupt >> >> In this case .. there is only one .. the handler verifies if it should >> actually handle this irq by the dev_id cookie, in this case it doesn't >> .. there are no handlers .. so after 200000 of those linux says hey we >> have an interrupt that nobody cared about. >> >> So there is a chance it's an irq that was actually destined to the device >> that was passed through, but that didn't handle it ? >> If that's the case .. why .. wasn't it handled in time .. or was it shutdown >> .. >> or ... > No - such a shared IRQ gets sent to both domains. There's no notion > of one domain claiming it and the other then not seeing it, as any > instance of the interrupt may mean more than one of the devices > signaled it - remember that shared interrupts are always level > triggered, i.e. there is no way of telling how many devices request > servicing. Ok .. just thinking out loud .. But how would that work then ? If the interrupt gets always sent to both domains and there is no handler for it in dom0 Wouldn't that then *always* cause a "irq nobody cared" .. unless it's masked ? And if so .. wouldn't that imply that since i sometimes (but not always) get the "irq nobody cared", that it is unmasked at some point in time ? And if so .. is there a way to detect that it's get unmasked ? -- Sander > Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 10:47 ` Sander Eikelenboom @ 2015-02-10 10:57 ` Jan Beulich 2015-02-10 10:59 ` Andrew Cooper 1 sibling, 0 replies; 23+ messages in thread From: Jan Beulich @ 2015-02-10 10:57 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: David Vrabel, xen-devel@lists.xen.org >>> On 10.02.15 at 11:47, <linux@eikelenboom.it> wrote: > Tuesday, February 10, 2015, 11:36:48 AM, you wrote: >> No - such a shared IRQ gets sent to both domains. There's no notion >> of one domain claiming it and the other then not seeing it, as any >> instance of the interrupt may mean more than one of the devices >> signaled it - remember that shared interrupts are always level >> triggered, i.e. there is no way of telling how many devices request >> servicing. > > Ok .. just thinking out loud .. > > But how would that work then ? > If the interrupt gets always sent to both domains > and > there is no handler for it in dom0 > > Wouldn't that then *always* cause a "irq nobody cared" .. > unless it's masked ? That's what the handler pciback installs is needed for. > And if so .. wouldn't that imply that since i sometimes (but not always) > get the "irq nobody cared", that it is unmasked at some point in time ? No, seeing this depends on both the other driver (some claim they handled IRQs even if their device didn't need service) and the rate at which "false" IRQs get sent. > And if so .. is there a way to detect that it's get unmasked ? IRQs without handlers are masked; when a handler gets installed they get unmasked. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 10:47 ` Sander Eikelenboom 2015-02-10 10:57 ` Jan Beulich @ 2015-02-10 10:59 ` Andrew Cooper 2015-02-10 11:21 ` Jan Beulich 1 sibling, 1 reply; 23+ messages in thread From: Andrew Cooper @ 2015-02-10 10:59 UTC (permalink / raw) To: Sander Eikelenboom, Jan Beulich; +Cc: David Vrabel, xen-devel@lists.xen.org On 10/02/15 10:47, Sander Eikelenboom wrote: > Tuesday, February 10, 2015, 11:36:48 AM, you wrote: > >>>>> On 10.02.15 at 11:03, <linux@eikelenboom.it> wrote: >>> Tuesday, February 10, 2015, 10:35:36 AM, you wrote: >>>> I suppose that's because there's no handler installed by pciback, yet >>>> IRQs generated by the passed through device also arrive in Dom0, >>>> and the driver for the device left in Dom0 doesn't claim the interrupts. >>> Yes so just for my idea of what happened (and i have googled): >>> the irq arrived at dom0 .. it went through the registered handlers: >>> [ 1906.422483] handlers: >>> [ 1906.441717] [<ffffffff8155cd42>] ata_bmdma_interrupt >>> >>> In this case .. there is only one .. the handler verifies if it should >>> actually handle this irq by the dev_id cookie, in this case it doesn't >>> .. there are no handlers .. so after 200000 of those linux says hey we >>> have an interrupt that nobody cared about. >>> >>> So there is a chance it's an irq that was actually destined to the device >>> that was passed through, but that didn't handle it ? >>> If that's the case .. why .. wasn't it handled in time .. or was it shutdown >>> .. >>> or ... >> No - such a shared IRQ gets sent to both domains. There's no notion >> of one domain claiming it and the other then not seeing it, as any >> instance of the interrupt may mean more than one of the devices >> signaled it - remember that shared interrupts are always level >> triggered, i.e. there is no way of telling how many devices request >> servicing. > Ok .. just thinking out loud .. > > But how would that work then ? > If the interrupt gets always sent to both domains > and > there is no handler for it in dom0 > > Wouldn't that then *always* cause a "irq nobody cared" .. > unless it's masked ? > > And if so .. wouldn't that imply that since i sometimes (but not always) > get the "irq nobody cared", that it is unmasked at some point in time ? > > And if so .. is there a way to detect that it's get unmasked ? Xen should only deliver the interrupt to domains which have a device on the appropriate line. In this case there are two devices using the line, one with no driver and one passed through. In the case of passthrough, the device is actually in a hybrid state in both dom0 and domU (with both having actual access), which means line level interrupts will be delivered to both domains. I presume the irq handler pciback registers will not claim the line level interrupts, as it cant know for certain whether the interrupt was for the passed-through device. This in turn will (presumably) cause the dom0 kernel to declare that nobody cared. ~Andrew ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 10:59 ` Andrew Cooper @ 2015-02-10 11:21 ` Jan Beulich 0 siblings, 0 replies; 23+ messages in thread From: Jan Beulich @ 2015-02-10 11:21 UTC (permalink / raw) To: Andrew Cooper; +Cc: Sander Eikelenboom, David Vrabel, xen-devel@lists.xen.org >>> On 10.02.15 at 11:59, <andrew.cooper3@citrix.com> wrote: > I presume the irq handler pciback registers will not claim the line > level interrupts, as it cant know for certain whether the interrupt was > for the passed-through device. This in turn will (presumably) cause the > dom0 kernel to declare that nobody cared. The sole purpose of that handler is to claim the IRQ, so that the kernel won't consider it unclaimed even if no other device claims it. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 9:35 ` Jan Beulich 2015-02-10 10:03 ` Sander Eikelenboom @ 2015-02-10 13:07 ` Sander Eikelenboom 2015-02-10 13:26 ` Jan Beulich 2015-02-10 15:13 ` Konrad Rzeszutek Wilk 1 sibling, 2 replies; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-10 13:07 UTC (permalink / raw) To: Jan Beulich; +Cc: David Vrabel, xen-devel@lists.xen.org Tuesday, February 10, 2015, 10:35:36 AM, you wrote: >>>> On 10.02.15 at 10:19, <linux@eikelenboom.it> wrote: >>> Coming back to the /proc/interrupts output you posted earlier: >> >>> /proc/interrupts shows the high count: >> >>> CPU0 CPU1 CPU2 CPU3 >>> 8: 0 0 0 0 xen-pirq-ioapic-edge rtc0 >>> 9: 1 0 0 0 xen-pirq-ioapic-level acpi >>> 16: 29 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb3 >>> 18: 200000 0 0 0 xen-pirq-ioapic-level ata_generic >> >>> I would have thought that xen-pciback would install an interrupt >>> handler here too when a device using IRQ 18 gets handed to a >>> guest. May there be something broken in xen_pcibk_control_isr()? >> >> It seems to only do that for PV guests, not for HVM. > Interesting; no idea why that would be. Hi Jan, Coming back to this part .. with some additional debugging on HVM guest start i get: [ 84.362097] pciback 0000:02:00.0: resetting (FLR, D3, bus) the device [ 84.422884] pciback 0000:02:00.0: xen_pcibk_reset_device: me here [ 84.452639] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 85.636725] pciback 0000:00:19.0: resetting (FLR, D3, ) the device [ 85.774845] pciback 0000:00:19.0: xen_pcibk_reset_device: me here [ 85.810857] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 85.865075] xen_pciback: vpci: 0000:02:00.0: assign to virtual slot 0 [ 85.886926] pciback 0000:02:00.0: registering for 1 [ 85.907936] xen_pciback: vpci: 0000:00:19.0: assign to virtual slot 1 [ 85.929490] pciback 0000:00:19.0: registering for 1 So it bails out on: /* Asked to disable, but ISR isn't runnig */ if (!enable && !dev_data->isr_on){ dev_warn(&dev->dev, "%s: return !enable && !dev_data->isr_on enable:%d dev_data->isr_on:%d\n", __func__, enable, dev_data->isr_on ? 1 : 0); return; } -- Sander >> Don't know how it wil go now after the bios update, >> lspci lists the SMBUS is also using irq 18 now, but it doesn't register >> a driver (according to lspci -k) and it doesn't appear in dom0's >> /proc/interrupts. > With that I don't think you're going to have problems, as the IRQ > then is masked. >> How are things supposed to work with a machine with: >> - a shared irq >> - iommu + interrupt remapping enabled >> - HVM guests > Konrad? >> Would dom0 always see the legacy irq or is Xen or the iommu routing it >> directly to >> the guest ? > A shared IRQ can't be routed directly, as all involved domains need > to see it. >> And what would i suppose to see when using Xen's debug key 'i', should there >> be an entry routing it to both guests ? > Yes, if both have a driver using it. >>. if you know some better way to figure out where the irq storm is >> coming from or headed to .. i'm all ears (or eyes) .. > I suppose that's because there's no handler installed by pciback, yet > IRQs generated by the passed through device also arrive in Dom0, > and the driver for the device left in Dom0 doesn't claim the interrupts. > Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 13:07 ` Sander Eikelenboom @ 2015-02-10 13:26 ` Jan Beulich 2015-02-10 15:35 ` Sander Eikelenboom 2015-02-10 15:13 ` Konrad Rzeszutek Wilk 1 sibling, 1 reply; 23+ messages in thread From: Jan Beulich @ 2015-02-10 13:26 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: David Vrabel, xen-devel@lists.xen.org >>> On 10.02.15 at 14:07, <linux@eikelenboom.it> wrote: > Tuesday, February 10, 2015, 10:35:36 AM, you wrote: >>>>> On 10.02.15 at 10:19, <linux@eikelenboom.it> wrote: >>>> I would have thought that xen-pciback would install an interrupt >>>> handler here too when a device using IRQ 18 gets handed to a >>>> guest. May there be something broken in xen_pcibk_control_isr()? >>> >>> It seems to only do that for PV guests, not for HVM. > >> Interesting; no idea why that would be. > > Coming back to this part .. with some additional debugging on HVM guest > start i > get: > [ 84.362097] pciback 0000:02:00.0: resetting (FLR, D3, bus) the device > [ 84.422884] pciback 0000:02:00.0: xen_pcibk_reset_device: me here > [ 84.452639] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && > !dev_data->isr_on enable:0 dev_data->isr_on:0 > [ 85.636725] pciback 0000:00:19.0: resetting (FLR, D3, ) the device > [ 85.774845] pciback 0000:00:19.0: xen_pcibk_reset_device: me here > [ 85.810857] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && > !dev_data->isr_on enable:0 dev_data->isr_on:0 > [ 85.865075] xen_pciback: vpci: 0000:02:00.0: assign to virtual slot 0 > [ 85.886926] pciback 0000:02:00.0: registering for 1 > [ 85.907936] xen_pciback: vpci: 0000:00:19.0: assign to virtual slot 1 > [ 85.929490] pciback 0000:00:19.0: registering for 1 > > So it bails out on: > /* Asked to disable, but ISR isn't runnig */ > if (!enable && !dev_data->isr_on){ > dev_warn(&dev->dev, "%s: return !enable && !dev_data->isr_on > enable:%d dev_data->isr_on:%d\n", __func__, enable, dev_data->isr_on ? 1 : 0); > return; > } I don't really know how this code is supposed to work (we don't use it in our kernels), but it seems the more interesting question is what happens when xen_pcibk_do_op() calls this function. I also note there is a sysfs interface to control some aspects of this, but I can't see how that would work when it only sets ->isr_on but doesn't install the IRQ handler if it isn't already installed. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 13:26 ` Jan Beulich @ 2015-02-10 15:35 ` Sander Eikelenboom 2015-02-10 15:46 ` Konrad Rzeszutek Wilk 2015-02-10 16:22 ` Jan Beulich 0 siblings, 2 replies; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-10 15:35 UTC (permalink / raw) To: Jan Beulich; +Cc: David Vrabel, xen-devel@lists.xen.org [-- Attachment #1: Type: text/plain, Size: 7346 bytes --] Tuesday, February 10, 2015, 2:26:43 PM, you wrote: >>>> On 10.02.15 at 14:07, <linux@eikelenboom.it> wrote: >> Tuesday, February 10, 2015, 10:35:36 AM, you wrote: >>>>>> On 10.02.15 at 10:19, <linux@eikelenboom.it> wrote: >>>>> I would have thought that xen-pciback would install an interrupt >>>>> handler here too when a device using IRQ 18 gets handed to a >>>>> guest. May there be something broken in xen_pcibk_control_isr()? >>>> >>>> It seems to only do that for PV guests, not for HVM. >> >>> Interesting; no idea why that would be. >> >> Coming back to this part .. with some additional debugging on HVM guest >> start i >> get: >> [ 84.362097] pciback 0000:02:00.0: resetting (FLR, D3, bus) the device >> [ 84.422884] pciback 0000:02:00.0: xen_pcibk_reset_device: me here >> [ 84.452639] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && >> !dev_data->isr_on enable:0 dev_data->isr_on:0 >> [ 85.636725] pciback 0000:00:19.0: resetting (FLR, D3, ) the device >> [ 85.774845] pciback 0000:00:19.0: xen_pcibk_reset_device: me here >> [ 85.810857] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && >> !dev_data->isr_on enable:0 dev_data->isr_on:0 >> [ 85.865075] xen_pciback: vpci: 0000:02:00.0: assign to virtual slot 0 >> [ 85.886926] pciback 0000:02:00.0: registering for 1 >> [ 85.907936] xen_pciback: vpci: 0000:00:19.0: assign to virtual slot 1 >> [ 85.929490] pciback 0000:00:19.0: registering for 1 >> >> So it bails out on: >> /* Asked to disable, but ISR isn't runnig */ >> if (!enable && !dev_data->isr_on){ >> dev_warn(&dev->dev, "%s: return !enable && !dev_data->isr_on >> enable:%d dev_data->isr_on:%d\n", __func__, enable, dev_data->isr_on ? 1 : 0); >> return; >> } > I don't really know how this code is supposed to work (we don't use > it in our kernels), but it seems the more interesting question is what > happens when xen_pcibk_do_op() calls this function. I also note there > is a sysfs interface to control some aspects of this, but I can't see how > that would work when it only sets ->isr_on but doesn't install the IRQ > handler if it isn't already installed. > Jan Suse is still forward porting and not considering upstream/pvops ? Hmmm it seems xen_pcibk_do_op() is never called .. Turned up the pciback debug, and annotated xen_pcibk_do_op() it self with more warnings, it should print something when invoked. complete dmesg attached. Here the debug output from pciback: seizing: [ 9.113134] xen_pciback: wants to seize 0000:02:00.0 [ 9.113137] xen_pciback: wants to seize 0000:00:19.0 [ 9.113146] pciback 0000:00:00.0: probing... [ 9.113154] pciback 0000:00:02.0: probing... [ 9.113160] pciback 0000:00:14.0: probing... [ 9.113165] pciback 0000:00:16.0: probing... [ 9.113171] pciback 0000:00:16.3: probing... [ 9.113176] pciback 0000:00:19.0: probing... [ 9.113178] pciback 0000:00:19.0: seizing device [ 9.113182] pciback 0000:00:19.0: pcistub_device_alloc [ 9.113184] pciback 0000:00:19.0: deferring initialization [ 9.113189] pciback 0000:00:1a.0: probing... [ 9.113194] pciback 0000:00:1b.0: probing... [ 9.113200] pciback 0000:00:1c.0: probing... [ 9.113205] pciback 0000:00:1c.2: probing... [ 9.113210] pciback 0000:00:1d.0: probing... [ 9.113216] pciback 0000:00:1f.0: probing... [ 9.113221] pciback 0000:00:1f.2: probing... [ 9.113226] pciback 0000:00:1f.3: probing... [ 9.113232] pciback 0000:02:00.0: probing... [ 9.113234] pciback 0000:02:00.0: seizing device [ 9.113237] pciback 0000:02:00.0: pcistub_device_alloc [ 9.113239] pciback 0000:02:00.0: deferring initialization initialization while dom0 is still booting: [ 14.371824] pciback 0000:02:00.0: initializing... [ 14.371829] pciback 0000:02:00.0: initializing config [ 14.371879] pciback 0000:02:00.0: enabling device [ 14.371944] xen: registering gsi 18 triggering 0 polarity 1 [ 14.371949] Already setup the GSI :18 [ 14.372457] pciback 0000:02:00.0: save state of device [ 14.372582] pciback 0000:02:00.0: resetting (FLR, D3, etc) the device [ 14.403788] pciback 0000:02:00.0: reset device [ 14.403794] pciback 0000:02:00.0: xen_pcibk_reset_device: me heres [ 14.404638] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 14.406186] pciback 0000:00:19.0: initializing... [ 14.406189] pciback 0000:00:19.0: initializing config [ 14.406225] pciback 0000:00:19.0: enabling device [ 14.406320] xen: registering gsi 20 triggering 0 polarity 1 [ 14.406340] xen: --> pirq=20 -> irq=20 (gsi=20) [ 14.406372] pciback 0000:00:19.0: save state of device [ 14.406435] pciback 0000:00:19.0: resetting (FLR, D3, etc) the device [ 14.507741] pciback 0000:00:19.0: reset device [ 14.507747] pciback 0000:00:19.0: xen_pcibk_reset_device: me heres [ 14.538842] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 14.571345] xen_pciback: backend is vpci guest start: [ 117.061148] pciback 0000:02:00.0: resetting (FLR, D3, bus) the device [ 117.092324] pciback 0000:02:00.0: OK [ 117.123935] pciback 0000:02:00.0: xen_pcibk_reset_device: me heres [ 117.153042] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 118.336807] pciback 0000:00:19.0: resetting (FLR, D3, ) the device [ 118.371580] pci 0000:00:00.0: not owned by us! [ 118.475884] pciback 0000:00:19.0: xen_pcibk_reset_device: me heres [ 118.497516] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 118.581239] xen-pciback pci-1-0: allocated pdev @ 0xffff88000007e9c0 [ 118.582466] xen-pciback pci-1-0: getting be setup [ 118.582683] xen-pciback pci-1-0: exporting dom 0 bus 2 slot 0 func 0 [ 118.582688] xen_pciback: vpci: 0000:02:00.0: assign to virtual slot 0 [ 118.613355] pciback 0000:02:00.0: registering for 1 [ 118.635176] xen-pciback pci-1-0: exporting dom 0 bus 0 slot 19 func 0 [ 118.635180] xen_pciback: vpci: 0000:00:19.0: assign to virtual slot 1 [ 118.657663] pciback 0000:00:19.0: registering for 1 [ 118.682808] xen-pciback pci-1-0: Publishing pci roots [ 118.682907] xen-pciback pci-1-0: writing root 0 at 0000:00 [ 118.686896] xen-pciback pci-1-0: fe state changed 1 So this one is up to Konrad i guess ... I haven't checked the call chain of xen_pcibk_do_op .. but that could be a side effect of libxl not imitating pci-front good enough (since HVM guests don't use the pci-front driver, but instead rely on libxl and Qemu to play those parts. One of the issues i already mentioned that devices never get to the state connected, for HVM guests. The backend state stays 3 (XenbusStateInitialised) and the frontend state stays 1 (XenbusStateInitialising). Until now i thought is was benign and only causing issues on shutdown: - not cleaning up of the device in the guest itself. which causes invoking the fallbacks of which a few were fixed just before the 4.5.0 release. - issues when only removing one assigned device of multiple assigned to a guest. since the passed through devices in principle are working OK. -- Sander [-- Attachment #2: dmesg.txt --] [-- Type: text/plain, Size: 55921 bytes --] [ 0.000000] PAT configuration [0-7]: WB WT UC- UC WC WP UC UC [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.19.0-creanuc-20150209-doflr-spurious-pcidb6+ (root@creanuc) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Tue Feb 10 15:52:48 CET 2015 [ 0.000000] Command line: root=/dev/mapper/creanuc-creanuc_dom0 ro mem=1536M video=HDMI-A-1:1024x768D nomodeset xen-pciback.hide=(02:00.0)(00:19.0) [ 0.000000] Released 0 page(s) [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable [ 0.000000] Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved [ 0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable [ 0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved [ 0.000000] Xen: [mem 0x0000000020200000-0x0000000040003fff] usable [ 0.000000] Xen: [mem 0x0000000040004000-0x0000000040004fff] reserved [ 0.000000] Xen: [mem 0x0000000040005000-0x0000000060263fff] usable [ 0.000000] Xen: [mem 0x0000000060264000-0x00000000db861fff] unusable [ 0.000000] Xen: [mem 0x00000000db862000-0x00000000dbce0fff] reserved [ 0.000000] Xen: [mem 0x00000000dbce1000-0x00000000dbcf0fff] ACPI data [ 0.000000] Xen: [mem 0x00000000dbcf1000-0x00000000dbe0efff] ACPI NVS [ 0.000000] Xen: [mem 0x00000000dbe0f000-0x00000000dc207fff] reserved [ 0.000000] Xen: [mem 0x00000000dc208000-0x00000000dc208fff] unusable [ 0.000000] Xen: [mem 0x00000000dc209000-0x00000000dc24bfff] ACPI NVS [ 0.000000] Xen: [mem 0x00000000dc24c000-0x00000000dcffffff] unusable [ 0.000000] Xen: [mem 0x00000000dd000000-0x00000000df9fffff] reserved [ 0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] Xen: [mem 0x00000000fed90000-0x00000000fed91fff] reserved [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved [ 0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] Xen: [mem 0x0000000100000000-0x000000021e5fffff] unusable [ 0.000000] e820: remove [mem 0x60000000-0xfffffffffffffffe] usable [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] e820: user-defined physical RAM map: [ 0.000000] user: [mem 0x0000000000000000-0x000000000009cfff] usable [ 0.000000] user: [mem 0x000000000009d800-0x00000000000fffff] reserved [ 0.000000] user: [mem 0x0000000000100000-0x000000001fffffff] usable [ 0.000000] user: [mem 0x0000000020000000-0x00000000201fffff] reserved [ 0.000000] user: [mem 0x0000000020200000-0x0000000040003fff] usable [ 0.000000] user: [mem 0x0000000040004000-0x0000000040004fff] reserved [ 0.000000] user: [mem 0x0000000040005000-0x000000005fffffff] usable [ 0.000000] user: [mem 0x0000000060264000-0x00000000db861fff] unusable [ 0.000000] user: [mem 0x00000000db862000-0x00000000dbce0fff] reserved [ 0.000000] user: [mem 0x00000000dbce1000-0x00000000dbcf0fff] ACPI data [ 0.000000] user: [mem 0x00000000dbcf1000-0x00000000dbe0efff] ACPI NVS [ 0.000000] user: [mem 0x00000000dbe0f000-0x00000000dc207fff] reserved [ 0.000000] user: [mem 0x00000000dc208000-0x00000000dc208fff] unusable [ 0.000000] user: [mem 0x00000000dc209000-0x00000000dc24bfff] ACPI NVS [ 0.000000] user: [mem 0x00000000dc24c000-0x00000000dcffffff] unusable [ 0.000000] user: [mem 0x00000000dd000000-0x00000000df9fffff] reserved [ 0.000000] user: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] user: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] user: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] user: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] user: [mem 0x00000000fed90000-0x00000000fed91fff] reserved [ 0.000000] user: [mem 0x00000000fee00000-0x00000000feefffff] reserved [ 0.000000] user: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] user: [mem 0x0000000100000000-0x000000021e5fffff] unusable [ 0.000000] SMBIOS 2.7 present. [ 0.000000] DMI: /D53427RKE, BIOS RKPPT10H.86A.0038.2014.1223.1928 12/23/2014 [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable [ 0.000000] AGP: No AGP bridge found [ 0.000000] e820: last_pfn = 0x60000 max_arch_pfn = 0x400000000 [ 0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576 [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] [ 0.000000] [mem 0x00000000-0x000fffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x5fe00000-0x5fffffff] [ 0.000000] [mem 0x5fe00000-0x5fffffff] page 4k [ 0.000000] BRK [0x02092000, 0x02092fff] PGTABLE [ 0.000000] BRK [0x02093000, 0x02093fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0x40000000-0x40003fff] [ 0.000000] [mem 0x40000000-0x40003fff] page 4k [ 0.000000] BRK [0x02094000, 0x02094fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0x40005000-0x5fdfffff] [ 0.000000] [mem 0x40005000-0x5fdfffff] page 4k [ 0.000000] BRK [0x02095000, 0x02095fff] PGTABLE [ 0.000000] BRK [0x02096000, 0x02096fff] PGTABLE [ 0.000000] BRK [0x02097000, 0x02097fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff] [ 0.000000] [mem 0x20200000-0x3fffffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff] [ 0.000000] [mem 0x00100000-0x1fffffff] page 4k [ 0.000000] RAMDISK: [mem 0x04000000-0x04fc5fff] [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x00000000000F04A0 000024 (v02 Intel ) [ 0.000000] ACPI: XSDT 0x00000000DBCE5080 000084 (v01 Intel D53427RK 00000026 AMI 00010013) [ 0.000000] ACPI: FACP 0x00000000DBCEEDC0 00010C (v05 Intel D53427RK 00000026 AMI 00010013) [ 0.000000] ACPI: DSDT 0x00000000DBCE5198 009C22 (v02 Intel D53427RK 00000026 INTL 20051117) [ 0.000000] ACPI: FACS 0x00000000DBE0EF80 000040 [ 0.000000] ACPI: APIC 0x00000000DBCEEED0 000072 (v03 Intel D53427RK 00000026 AMI 00010013) [ 0.000000] ACPI: FPDT 0x00000000DBCEEF48 000044 (v01 Intel D53427RK 00000026 AMI 00010013) [ 0.000000] ACPI: FIDT 0x00000000DBCEEF90 00009C (v01 Intel D53427RK 00000026 AMI 00010013) [ 0.000000] ACPI: TCPA 0x00000000DBCEF030 000032 (v02 APTIO4 NAPAASF 00000026 MSFT 01000013) [ 0.000000] ACPI: MCFG 0x00000000DBCEF068 00003C (v01 Intel D53427RK 00000026 MSFT 00000097) [ 0.000000] ACPI: HPET 0x00000000DBCEF0A8 000038 (v01 Intel D53427RK 00000026 AMI. 00000005) [ 0.000000] ACPI: SSDT 0x00000000DBCEF0E0 000315 (v01 SataRe SataTabl 00000026 INTL 20091112) [ 0.000000] ACPI: SSDT 0x00000000DBCEF3F8 0009AA (v01 PmRef Cpu0Ist 00000026 INTL 20051117) [ 0.000000] ACPI: SSDT 0x00000000DBCEFDA8 000B22 (v01 PmRef CpuPm 00000026 INTL 20051117) [ 0.000000] ACPI: XMAR 0x00000000DBCF08D0 0000B8 (v01 INTEL SNB 00000026 INTL 00000001) [ 0.000000] ACPI: ASF! 0x00000000DBCF0988 0000A5 (v32 INTEL HCG 00000026 TFSM 000F4240) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0x5fffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x0009cfff] [ 0.000000] node 0: [mem 0x00100000-0x1fffffff] [ 0.000000] node 0: [mem 0x20200000-0x40003fff] [ 0.000000] node 0: [mem 0x40005000-0x5fffffff] [ 0.000000] Initmem setup node 0 [mem 0x00001000-0x5fffffff] [ 0.000000] On node 0 totalpages: 392603 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 21 pages reserved [ 0.000000] DMA zone: 3996 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 6080 pages used for memmap [ 0.000000] DMA32 zone: 388607 pages, LIFO batch:31 [ 0.000000] p2m virtual area at ffffc90000000000, size is 400000 [ 0.000000] Remapped 612 page(s) [ 0.000000] Reserving Intel graphics stolen memory at 0xdda00000-0xdf9fffff [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs [ 0.000000] e820: [mem 0xdfa00000-0xf7ffffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.6.0-unstable (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:16 nr_cpumask_bits:16 nr_cpu_ids:4 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 29 pages/cpu @ffff88005f600000 s79232 r8192 d31360 u524288 [ 0.000000] pcpu-alloc: s79232 r8192 d31360 u524288 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 0 1 2 3 [ 0.000000] xen: PV spinlocks enabled [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 386438 [ 0.000000] Kernel command line: root=/dev/mapper/creanuc-creanuc_dom0 ro mem=1536M video=HDMI-A-1:1024x768D nomodeset xen-pciback.hide=(02:00.0)(00:19.0) [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 using standard form [ 0.000000] software IO TLB [mem 0x59a00000-0x5da00000] (64MB) mapped at [ffff880059a00000-ffff88005d9fffff] [ 0.000000] Memory: 1436748K/1570412K available (8827K kernel code, 917K rwdata, 3156K rodata, 1016K init, 640K bss, 133664K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS:4352 nr_irqs:456 16 [ 0.000000] xen:events: Using FIFO-based ABI [ 0.000000] xen: --> pirq=1 -> irq=1 (gsi=1) [ 0.000000] xen: --> pirq=2 -> irq=2 (gsi=2) [ 0.000000] xen: --> pirq=3 -> irq=3 (gsi=3) [ 0.000000] xen: --> pirq=4 -> irq=4 (gsi=4) [ 0.000000] xen: --> pirq=5 -> irq=5 (gsi=5) [ 0.000000] xen: --> pirq=6 -> irq=6 (gsi=6) [ 0.000000] xen: --> pirq=7 -> irq=7 (gsi=7) [ 0.000000] xen: --> pirq=8 -> irq=8 (gsi=8) [ 0.000000] xen: --> pirq=9 -> irq=9 (gsi=9) [ 0.000000] xen: --> pirq=10 -> irq=10 (gsi=10) [ 0.000000] xen: --> pirq=11 -> irq=11 (gsi=11) [ 0.000000] xen: --> pirq=12 -> irq=12 (gsi=12) [ 0.000000] xen: --> pirq=13 -> irq=13 (gsi=13) [ 0.000000] xen: --> pirq=14 -> irq=14 (gsi=14) [ 0.000000] xen: --> pirq=15 -> irq=15 (gsi=15) [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] tsc: Detected 2294.832 MHz processor [ 8.758869] Calibrating delay loop (skipped), value calculated using timer frequency.. 4589.66 BogoMIPS (lpj=9179328) [ 8.758876] pid_max: default: 32768 minimum: 301 [ 8.758887] ACPI: Core revision 20141107 [ 8.791772] ACPI: All ACPI Tables successfully acquired [ 8.792445] Security Framework initialized [ 8.792468] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) [ 8.792473] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes) [ 8.792796] Initializing cgroup subsys devices [ 8.792802] Initializing cgroup subsys freezer [ 8.792807] Initializing cgroup subsys net_cls [ 8.792813] Initializing cgroup subsys blkio [ 8.792817] Initializing cgroup subsys perf_event [ 8.792904] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 8.792904] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [ 8.792913] CPU: Physical Processor ID: 0 [ 8.792915] CPU: Processor Core ID: 0 [ 8.793441] mce: CPU supports 2 MCE banks [ 8.793464] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [ 8.793464] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [ 8.793673] Freeing SMP alternatives memory: 48K (ffffffff81fe5000 - ffffffff81ff1000) [ 8.795890] cpu 0 spinlock event irq 25 [ 8.795938] Performance Events: unsupported p6 CPU model 58 no PMU driver, software events only. [ 8.796189] NMI watchdog: disabled (cpu0): hardware events not enabled [ 8.796269] installing Xen timer for CPU 1 [ 8.796281] cpu 1 spinlock event irq 32 [ 8.797257] installing Xen timer for CPU 2 [ 8.797269] cpu 2 spinlock event irq 39 [ 8.798163] installing Xen timer for CPU 3 [ 8.798173] cpu 3 spinlock event irq 46 [ 8.798988] x86: Booted up 1 node, 4 CPUs [ 8.799294] devtmpfs: initialized [ 8.800177] xor: automatically using best checksumming function: [ 8.838982] avx : 12103.000 MB/sec [ 8.839183] NET: Registered protocol family 16 [ 8.839200] xen:grant_table: Grant tables using version 1 layout [ 8.839214] Grant table initialized [ 8.839870] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it [ 8.839876] ACPI: bus type PCI registered [ 8.839880] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 8.840006] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 8.840013] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820 [ 8.850950] PCI: Using configuration type 1 for base access [ 8.931211] raid6: sse2x1 4577 MB/s [ 8.999337] raid6: sse2x2 5715 MB/s [ 9.067424] raid6: sse2x4 6496 MB/s [ 9.067428] raid6: using algorithm sse2x4 (6496 MB/s) [ 9.067431] raid6: using ssse3x2 recovery algorithm [ 9.067491] ACPI: Added _OSI(Module Device) [ 9.067496] ACPI: Added _OSI(Processor Device) [ 9.067505] ACPI: Added _OSI(3.0 _SCP Extensions) [ 9.067508] ACPI: Added _OSI(Processor Aggregator Device) [ 9.069465] xen: registering gsi 9 triggering 0 polarity 0 [ 9.071581] ACPI: Executed 1 blocks of module-level executable AML code [ 9.076303] ACPI: Dynamic OEM Table Load: [ 9.076315] ACPI: SSDT 0xFFFF8800596F0000 00083B (v01 PmRef Cpu0Cst 00003001 INTL 20051117) [ 9.077198] ACPI: Dynamic OEM Table Load: [ 9.077206] ACPI: SSDT 0xFFFF8800596ECC00 000303 (v01 PmRef ApIst 00003000 INTL 20051117) [ 9.077888] ACPI: Dynamic OEM Table Load: [ 9.077896] ACPI: SSDT 0xFFFF8800596A5800 000119 (v01 PmRef ApCst 00003000 INTL 20051117) [ 9.079167] ACPI: Interpreter enabled [ 9.079177] ACPI: (supports S0 S5) [ 9.079181] ACPI: Using IOAPIC for interrupt routing [ 9.079222] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 9.087310] ACPI: Power Resource [FN00] (off) [ 9.087419] ACPI: Power Resource [FN01] (off) [ 9.087539] ACPI: Power Resource [FN02] (off) [ 9.087641] ACPI: Power Resource [FN03] (off) [ 9.087742] ACPI: Power Resource [FN04] (off) [ 9.088669] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e]) [ 9.088680] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 9.089083] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug PME] [ 9.089337] acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability] [ 9.090410] PCI host bridge to bus 0000:00 [ 9.090416] pci_bus 0000:00: root bus resource [bus 00-3e] [ 9.090420] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] [ 9.090425] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] [ 9.090429] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] [ 9.090433] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff] [ 9.090438] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff] [ 9.090442] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff] [ 9.090446] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff] [ 9.090450] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff] [ 9.090454] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff] [ 9.090459] pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfeafffff] [ 9.090482] pci 0000:00:00.0: [8086:0154] type 00 class 0x060000 [ 9.090724] pci 0000:00:02.0: [8086:0166] type 00 class 0x030000 [ 9.090770] pci 0000:00:02.0: reg 0x10: [mem 0xf7800000-0xf7bfffff 64bit] [ 9.090795] pci 0000:00:02.0: reg 0x18: [mem 0xe0000000-0xefffffff 64bit pref] [ 9.090811] pci 0000:00:02.0: reg 0x20: [io 0xf000-0xf03f] [ 9.091088] pci 0000:00:14.0: [8086:1e31] type 00 class 0x0c0330 [ 9.091142] pci 0000:00:14.0: reg 0x10: [mem 0xf7d20000-0xf7d2ffff 64bit] [ 9.091324] pci 0000:00:14.0: PME# supported from D3hot D3cold [ 9.091390] pci 0000:00:14.0: System wakeup disabled by ACPI [ 9.091492] pci 0000:00:16.0: [8086:1e3a] type 00 class 0x078000 [ 9.091548] pci 0000:00:16.0: reg 0x10: [mem 0xf7d3c000-0xf7d3c00f 64bit] [ 9.091735] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold [ 9.091881] pci 0000:00:16.3: [8086:1e3d] type 00 class 0x070002 [ 9.091933] pci 0000:00:16.3: reg 0x10: [io 0xf0e0-0xf0e7] [ 9.091955] pci 0000:00:16.3: reg 0x14: [mem 0xf7d3a000-0xf7d3afff] [ 9.092288] pci 0000:00:19.0: [8086:1502] type 00 class 0x020000 [ 9.092335] pci 0000:00:19.0: reg 0x10: [mem 0xf7d00000-0xf7d1ffff] [ 9.092355] pci 0000:00:19.0: reg 0x14: [mem 0xf7d39000-0xf7d39fff] [ 9.092375] pci 0000:00:19.0: reg 0x18: [io 0xf080-0xf09f] [ 9.092547] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold [ 9.092617] pci 0000:00:19.0: System wakeup disabled by ACPI [ 9.092705] pci 0000:00:1a.0: [8086:1e2d] type 00 class 0x0c0320 [ 9.092754] pci 0000:00:1a.0: reg 0x10: [mem 0xf7d38000-0xf7d383ff] [ 9.092977] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold [ 9.093072] pci 0000:00:1a.0: System wakeup disabled by ACPI [ 9.093164] pci 0000:00:1b.0: [8086:1e20] type 00 class 0x040300 [ 9.093205] pci 0000:00:1b.0: reg 0x10: [mem 0xf7d30000-0xf7d33fff 64bit] [ 9.093398] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 9.093471] pci 0000:00:1b.0: System wakeup disabled by ACPI [ 9.093550] pci 0000:00:1c.0: [8086:1e10] type 01 class 0x060400 [ 9.093757] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 9.093816] pci 0000:00:1c.0: Enabling MPC IRBNCE [ 9.093823] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled [ 9.093871] pci 0000:00:1c.0: System wakeup disabled by ACPI [ 9.093955] pci 0000:00:1c.2: [8086:1e14] type 01 class 0x060400 [ 9.094162] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold [ 9.094215] pci 0000:00:1c.2: Enabling MPC IRBNCE [ 9.094222] pci 0000:00:1c.2: Intel PCH root port ACS workaround enabled [ 9.094270] pci 0000:00:1c.2: System wakeup disabled by ACPI [ 9.094371] pci 0000:00:1d.0: [8086:1e26] type 00 class 0x0c0320 [ 9.094420] pci 0000:00:1d.0: reg 0x10: [mem 0xf7d37000-0xf7d373ff] [ 9.094643] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold [ 9.094735] pci 0000:00:1d.0: System wakeup disabled by ACPI [ 9.094818] pci 0000:00:1f.0: [8086:1e56] type 00 class 0x060100 [ 9.095185] pci 0000:00:1f.2: [8086:1e03] type 00 class 0x010601 [ 9.095235] pci 0000:00:1f.2: reg 0x10: [io 0xf0d0-0xf0d7] [ 9.095255] pci 0000:00:1f.2: reg 0x14: [io 0xf0c0-0xf0c3] [ 9.095275] pci 0000:00:1f.2: reg 0x18: [io 0xf0b0-0xf0b7] [ 9.095295] pci 0000:00:1f.2: reg 0x1c: [io 0xf0a0-0xf0a3] [ 9.095315] pci 0000:00:1f.2: reg 0x20: [io 0xf060-0xf07f] [ 9.095335] pci 0000:00:1f.2: reg 0x24: [mem 0xf7d36000-0xf7d367ff] [ 9.095466] pci 0000:00:1f.2: PME# supported from D3hot [ 9.095617] pci 0000:00:1f.3: [8086:1e22] type 00 class 0x0c0500 [ 9.095656] pci 0000:00:1f.3: reg 0x10: [mem 0xf7d35000-0xf7d350ff 64bit] [ 9.095711] pci 0000:00:1f.3: reg 0x20: [io 0xf040-0xf05f] [ 9.096007] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 9.096200] pci 0000:02:00.0: [168c:002b] type 00 class 0x028000 [ 9.096255] pci 0000:02:00.0: reg 0x10: [mem 0xf7c00000-0xf7c0ffff 64bit] [ 9.096542] pci 0000:02:00.0: supports D1 [ 9.096545] pci 0000:02:00.0: PME# supported from D0 D1 D3hot [ 9.096606] pci 0000:02:00.0: System wakeup disabled by ACPI [ 9.103584] pci 0000:00:1c.2: PCI bridge to [bus 02] [ 9.103604] pci 0000:00:1c.2: bridge window [mem 0xf7c00000-0xf7cfffff] [ 9.103656] pci_bus 0000:00: on NUMA node 0 [ 9.103659] acpi PNP0A08:00: Disabling ASPM (FADT indicates it is unsupported) [ 9.104048] xen: registering gsi 13 triggering 1 polarity 0 [ 9.104273] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15) [ 9.104360] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. [ 9.104444] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 *4 5 6 10 11 12 14 15) [ 9.104526] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15) [ 9.104607] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 10 11 12 14 15) [ 9.104688] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. [ 9.104775] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 10 11 12 14 15) [ 9.104858] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15) [ 9.105184] ACPI: Enabled 6 GPEs in block 00 to 3F [ 9.105245] xen:balloon: Initialising balloon driver [ 9.105481] xen_balloon: Initialising balloon driver [ 9.105677] vgaarb: setting as boot device: PCI:0000:00:02.0 [ 9.105685] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 9.105691] vgaarb: loaded [ 9.105694] vgaarb: bridge control possible 0000:00:02.0 [ 9.105795] SCSI subsystem initialized [ 9.105812] libata version 3.00 loaded. [ 9.105847] ACPI: bus type USB registered [ 9.105876] usbcore: registered new interface driver usbfs [ 9.105890] usbcore: registered new interface driver hub [ 9.105929] usbcore: registered new device driver usb [ 9.105976] pps_core: LinuxPPS API ver. 1 registered [ 9.105980] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 9.105988] PTP clock support registered [ 9.106040] wmi: Mapper loaded [ 9.106086] Advanced Linux Sound Architecture Driver Initialized. [ 9.106091] PCI: Using ACPI for IRQ routing [ 9.110886] PCI: pci_cache_line_size set to 64 bytes [ 9.110981] e820: reserve RAM buffer [mem 0x0009d000-0x0009ffff] [ 9.110984] e820: reserve RAM buffer [mem 0x40004000-0x43ffffff] [ 9.111515] Switched to clocksource xen [ 9.111648] FS-Cache: Loaded [ 9.111775] CacheFiles: Loaded [ 9.111832] pnp: PnP ACPI init [ 9.111977] system 00:00: [io 0x0680-0x069f] has been reserved [ 9.111983] system 00:00: [io 0x1000-0x100f] has been reserved [ 9.111988] system 00:00: [io 0xffff] has been reserved [ 9.111992] system 00:00: [io 0xffff] has been reserved [ 9.111997] system 00:00: [io 0x0400-0x0453] could not be reserved [ 9.112001] system 00:00: [io 0x0458-0x047f] has been reserved [ 9.112007] system 00:00: [io 0x0500-0x057f] has been reserved [ 9.112014] system 00:00: [io 0x164e-0x164f] has been reserved [ 9.112022] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) [ 9.112045] xen: registering gsi 8 triggering 1 polarity 0 [ 9.112089] pnp 00:01: Plug and Play ACPI device, IDs PNP0b00 (active) [ 9.112157] system 00:02: [io 0x0454-0x0457] has been reserved [ 9.112164] system 00:02: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active) [ 9.112375] system 00:03: [io 0x0a00-0x0a1f] has been reserved [ 9.112380] system 00:03: [io 0x0a30-0x0a3f] has been reserved [ 9.112385] system 00:03: [io 0x0a20-0x0a2f] has been reserved [ 9.112389] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active) [ 9.112483] system 00:04: [io 0x04d0-0x04d1] has been reserved [ 9.112489] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active) [ 9.112532] pnp 00:05: Plug and Play ACPI device, IDs PNP0c31 (active) [ 9.112834] system 00:06: [mem 0xfed1c000-0xfed1ffff] has been reserved [ 9.112840] system 00:06: [mem 0xfed10000-0xfed17fff] has been reserved [ 9.112844] system 00:06: [mem 0xfed18000-0xfed18fff] has been reserved [ 9.112848] system 00:06: [mem 0xfed19000-0xfed19fff] has been reserved [ 9.112853] system 00:06: [mem 0xf8000000-0xfbffffff] has been reserved [ 9.112858] system 00:06: [mem 0xfed20000-0xfed3ffff] has been reserved [ 9.112862] system 00:06: [mem 0xfed90000-0xfed93fff] could not be reserved [ 9.112867] system 00:06: [mem 0xfed45000-0xfed8ffff] has been reserved [ 9.112871] system 00:06: [mem 0xff000000-0xffffffff] has been reserved [ 9.112876] system 00:06: [mem 0xfee00000-0xfeefffff] has been reserved [ 9.112880] system 00:06: [mem 0xdfa00000-0xdfa00fff] has been reserved [ 9.112885] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active) [ 9.113089] system 00:07: [mem 0x20000000-0x201fffff] has been reserved [ 9.113095] system 00:07: [mem 0x40004000-0x40004fff] has been reserved [ 9.113099] system 00:07: Plug and Play ACPI device, IDs PNP0c01 (active) [ 9.113123] pnp: PnP ACPI: found 8 devices [ 9.113134] xen_pciback: wants to seize 0000:02:00.0 [ 9.113137] xen_pciback: wants to seize 0000:00:19.0 [ 9.113146] pciback 0000:00:00.0: probing... [ 9.113154] pciback 0000:00:02.0: probing... [ 9.113160] pciback 0000:00:14.0: probing... [ 9.113165] pciback 0000:00:16.0: probing... [ 9.113171] pciback 0000:00:16.3: probing... [ 9.113176] pciback 0000:00:19.0: probing... [ 9.113178] pciback 0000:00:19.0: seizing device [ 9.113182] pciback 0000:00:19.0: pcistub_device_alloc [ 9.113184] pciback 0000:00:19.0: deferring initialization [ 9.113189] pciback 0000:00:1a.0: probing... [ 9.113194] pciback 0000:00:1b.0: probing... [ 9.113200] pciback 0000:00:1c.0: probing... [ 9.113205] pciback 0000:00:1c.2: probing... [ 9.113210] pciback 0000:00:1d.0: probing... [ 9.113216] pciback 0000:00:1f.0: probing... [ 9.113221] pciback 0000:00:1f.2: probing... [ 9.113226] pciback 0000:00:1f.3: probing... [ 9.113232] pciback 0000:02:00.0: probing... [ 9.113234] pciback 0000:02:00.0: seizing device [ 9.113237] pciback 0000:02:00.0: pcistub_device_alloc [ 9.113239] pciback 0000:02:00.0: deferring initialization [ 9.124179] PM-Timer failed consistency check (0xffffff) - aborting. [ 9.124231] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 9.124259] pci 0000:00:1c.2: PCI bridge to [bus 02] [ 9.124272] pci 0000:00:1c.2: bridge window [mem 0xf7c00000-0xf7cfffff] [ 9.124293] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 9.124296] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 9.124298] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 9.124301] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000d3fff] [ 9.124303] pci_bus 0000:00: resource 8 [mem 0x000d4000-0x000d7fff] [ 9.124306] pci_bus 0000:00: resource 9 [mem 0x000d8000-0x000dbfff] [ 9.124308] pci_bus 0000:00: resource 10 [mem 0x000dc000-0x000dffff] [ 9.124311] pci_bus 0000:00: resource 11 [mem 0x000e0000-0x000e3fff] [ 9.124313] pci_bus 0000:00: resource 12 [mem 0x000e4000-0x000e7fff] [ 9.124316] pci_bus 0000:00: resource 13 [mem 0xdfa00000-0xfeafffff] [ 9.124319] pci_bus 0000:02: resource 1 [mem 0xf7c00000-0xf7cfffff] [ 9.124352] NET: Registered protocol family 2 [ 9.124571] TCP established hash table entries: 16384 (order: 5, 131072 bytes) [ 9.124604] TCP bind hash table entries: 16384 (order: 6, 262144 bytes) [ 9.124643] TCP: Hash tables configured (established 16384 bind 16384) [ 9.124665] TCP: reno registered [ 9.124671] UDP hash table entries: 1024 (order: 3, 32768 bytes) [ 9.124680] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) [ 9.124730] NET: Registered protocol family 1 [ 9.124755] pci 0000:00:02.0: Video device with shadowed ROM [ 9.124874] xen: registering gsi 16 triggering 0 polarity 1 [ 9.124889] xen: --> pirq=16 -> irq=16 (gsi=16) [ 9.125195] xen: registering gsi 16 triggering 0 polarity 1 [ 9.125198] Already setup the GSI :16 [ 9.143766] xen: registering gsi 23 triggering 0 polarity 1 [ 9.143779] xen: --> pirq=23 -> irq=23 (gsi=23) [ 9.163824] PCI: CLS mismatch (64 != 32), using 64 bytes [ 9.163895] Trying to unpack rootfs image as initramfs... [ 9.178219] Freeing initrd memory: 16152K (ffff880004000000 - ffff880004fc6000) [ 9.178789] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 9.190175] sha1_ssse3: Using AVX optimized SHA-1 implementation [ 9.190506] futex hash table entries: 1024 (order: 4, 65536 bytes) [ 9.190546] audit: initializing netlink subsys (disabled) [ 9.190570] audit: type=2000 audit(1423580623.200:1): initialized [ 9.190804] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 9.192706] VFS: Disk quotas dquot_6.5.2 [ 9.192754] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 9.193178] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 9.193307] ntfs: driver 2.1.31 [Flags: R/W]. [ 9.193440] fuse init (API version 7.23) [ 9.200293] alg: No test for stdrng (krng) [ 9.206606] NET: Registered protocol family 38 [ 9.206634] bounce: pool size: 64 pages [ 9.206682] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) [ 9.206774] io scheduler noop registered [ 9.206781] io scheduler deadline registered [ 9.206829] io scheduler cfq registered (default) [ 9.207027] xen: registering gsi 16 triggering 0 polarity 1 [ 9.207032] Already setup the GSI :16 [ 9.207231] xen: registering gsi 18 triggering 0 polarity 1 [ 9.207245] xen: --> pirq=18 -> irq=18 (gsi=18) [ 9.207397] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 9.207421] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 9.207427] cpcihp_zt5550: ZT5550 CompactPCI Hot Plug Driver version: 0.2 [ 9.207450] cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1 [ 9.207454] cpcihp_generic: not configured, disabling. [ 9.207472] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 9.208913] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed [ 9.208956] vmlfb: initializing [ 14.207685] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) [ 14.207696] uvesafb: vbe_init() failed with -22 [ 14.207709] uvesafb: probe of uvesafb.0 failed with error -22 [ 14.207754] vesafb: mode is 1024x768x32, linelength=4096, pages=0 [ 14.207758] vesafb: scrolling: redraw [ 14.207762] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 14.208858] vesafb: framebuffer at 0xe0000000, mapped to 0xffffc90004500000, using 6144k, total 32704k [ 14.280805] Console: switching to colour frame buffer device 128x48 [ 14.353311] fb0: VESA VGA frame buffer device [ 14.353956] vga16fb: initializing [ 14.353959] vga16fb: mapped to 0xffff8800000a0000 [ 14.354595] checking generic (e0000000 1ff0000) vs hw (a0000 10000) [ 14.354756] fb1: VGA16 VGA frame buffer device [ 14.355375] intel_idle: MWAIT substates: 0x21120 [ 14.355377] intel_idle: v0.4 model 0x3A [ 14.355379] intel_idle: lapic_timer_reliable_states 0xffffffff [ 14.355434] intel_idle: intel_idle yielding to none [ 14.355451] ipmi message handler version 39.2 [ 14.356062] ipmi device interface [ 14.356531] IPMI System Interface driver. [ 14.357120] ipmi_si: Unable to find any System Interface(s) [ 14.357874] IPMI Watchdog: driver initialized [ 14.358467] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot. [ 14.360538] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 [ 14.361672] ACPI: Power Button [PWRB] [ 14.362218] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 14.363219] ACPI: Power Button [PWRF] [ 14.364423] Monitor-Mwait will be used to enter C-1 state [ 14.364531] Monitor-Mwait will be used to enter C-2 state [ 14.365426] Warning: Processor Platform Limit not supported. [ 14.366192] thermal LNXTHERM:00: registered as thermal_zone0 [ 14.366963] ACPI: Thermal Zone [TZ00] (28 C) [ 14.367902] thermal LNXTHERM:01: registered as thermal_zone1 [ 14.368670] ACPI: Thermal Zone [TZ01] (30 C) [ 14.369272] Error: Driver 'processor_aggregator' is already registered, aborting... [ 14.370789] xen:xen_evtchn: Event-channel device installed [ 14.371824] pciback 0000:02:00.0: initializing... [ 14.371829] pciback 0000:02:00.0: initializing config [ 14.371879] pciback 0000:02:00.0: enabling device [ 14.371944] xen: registering gsi 18 triggering 0 polarity 1 [ 14.371949] Already setup the GSI :18 [ 14.372457] pciback 0000:02:00.0: save state of device [ 14.372582] pciback 0000:02:00.0: resetting (FLR, D3, etc) the device [ 14.403788] pciback 0000:02:00.0: reset device [ 14.403794] pciback 0000:02:00.0: xen_pcibk_reset_device: me heres [ 14.404638] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 14.406186] pciback 0000:00:19.0: initializing... [ 14.406189] pciback 0000:00:19.0: initializing config [ 14.406225] pciback 0000:00:19.0: enabling device [ 14.406320] xen: registering gsi 20 triggering 0 polarity 1 [ 14.406340] xen: --> pirq=20 -> irq=20 (gsi=20) [ 14.406372] pciback 0000:00:19.0: save state of device [ 14.406435] pciback 0000:00:19.0: resetting (FLR, D3, etc) the device [ 14.507741] pciback 0000:00:19.0: reset device [ 14.507747] pciback 0000:00:19.0: xen_pcibk_reset_device: me heres [ 14.538842] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 14.571345] xen_pciback: backend is vpci [ 14.603959] xen_acpi_processor: Uploading Xen processor PM info [ 14.638237] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 14.660041] xen: registering gsi 19 triggering 0 polarity 1 [ 14.660052] xen: --> pirq=19 -> irq=19 (gsi=19) [ 14.680635] 0000:00:16.3: ttyS0 at I/O 0xf0e0 (irq = 19, base_baud = 115200) is a 16550A [ 14.702044] hpet_acpi_add: no address or irqs in _CRS [ 14.723497] Non-volatile memory driver v1.3 [ 14.744718] Linux agpgart interface v0.103 [ 14.765625] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [ 14.787219] tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78) [ 14.855814] [drm] Initialized drm 1.1.0 20060810 [ 14.893780] drm/i810 does not support SMP [ 14.918281] brd: module loaded [ 14.941320] loop: module loaded [ 14.962178] nbd: registered device at major 43 [ 14.985542] drbd: initialized. Version: 8.4.5 (api:1/proto:86-101) [ 15.007162] drbd: built-in [ 15.027335] drbd: registered as block device major 147 [ 15.047771] xen: registering gsi 16 triggering 0 polarity 1 [ 15.047775] Already setup the GSI :16 [ 15.073235] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042f conflicts with OpRegion 0x0000000000000400-0x000000000000047f (\PMIO) (20141107/utaddress-258) [ 15.115810] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 15.137924] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054f conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20141107/utaddress-258) [ 15.182774] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 15.205922] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053f conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20141107/utaddress-258) [ 15.253570] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 15.278381] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052f conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20141107/utaddress-258) [ 15.329572] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 15.356150] lpc_ich: Resource conflict(s) found affecting gpio_ich [ 15.382733] Loading iSCSI transport class v2.0-870. [ 15.409348] hv_vmbus: registering driver hv_storvsc [ 15.435428] ahci 0000:00:1f.2: version 3.0 [ 15.435495] xen: registering gsi 19 triggering 0 polarity 1 [ 15.435497] Already setup the GSI :19 [ 15.461249] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x1 impl SATA mode [ 15.487286] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst [ 15.513959] scsi host0: ahci [ 15.540331] scsi host1: ahci [ 15.579602] scsi host2: ahci [ 15.618969] scsi host3: ahci [ 15.658168] scsi host4: ahci [ 15.683032] scsi host5: ahci [ 15.706980] ata1: SATA max UDMA/133 abar m2048@0xf7d36000 port 0xf7d36100 irq 56 [ 15.731152] ata2: DUMMY [ 15.754921] ata3: DUMMY [ 15.778191] ata4: DUMMY [ 15.800907] ata5: DUMMY [ 15.823140] ata6: DUMMY [ 15.844645] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) [ 15.867959] eql: Equalizer2002: Simon Janes (simon@ncm.com) and David S. Miller (davem@redhat.com) [ 15.900365] libphy: Fixed MDIO Bus: probed [ 15.923920] tun: Universal TUN/TAP device driver, 1.6 [ 15.947217] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> [ 15.970844] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI [ 15.992983] e100: Copyright(c) 1999-2006 Intel Corporation [ 16.014990] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI [ 16.036993] e1000: Copyright (c) 1999-2006 Intel Corporation. [ 16.058945] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k [ 16.080951] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. [ 16.103047] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.15-k [ 16.125500] igb: Copyright (c) 2007-2014 Intel Corporation. [ 16.148014] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.2-k [ 16.167545] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 16.168092] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 16.168094] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 16.168095] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 16.168381] ata1.00: supports DRM functions and may not be fully accessible [ 16.171226] ata1.00: disabling queued TRIM support [ 16.171227] ata1.00: ATA-9: Crucial_CT120M500SSD3, MU05, max UDMA/133 [ 16.171228] ata1.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 16.174932] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 16.174934] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 16.174935] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 16.175223] ata1.00: supports DRM functions and may not be fully accessible [ 16.178038] ata1.00: disabling queued TRIM support [ 16.181240] ata1.00: configured for UDMA/133 [ 16.181371] scsi 0:0:0:0: Direct-Access ATA Crucial_CT120M50 MU05 PQ: 0 ANSI: 5 [ 16.181569] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 16.181582] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) [ 16.181583] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 16.181667] sd 0:0:0:0: [sda] Write Protect is off [ 16.181669] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 16.181718] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 16.182154] sda: sda1 [ 16.182509] sd 0:0:0:0: [sda] Attached SCSI disk [ 16.566170] igbvf: Copyright (c) 2009 - 2012 Intel Corporation. [ 16.585010] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 4.0.1-k [ 16.613693] ixgbe: Copyright (c) 1999-2014 Intel Corporation. [ 16.631926] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.12.1-k [ 16.650577] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation. [ 16.669511] ixgb: Intel(R) PRO/10GbE Network Driver - version 1.0.135-k2-NAPI [ 16.688894] ixgb: Copyright (c) 1999-2008 Intel Corporation. [ 16.708551] xen_netfront: Initialising Xen virtual ethernet driver [ 16.728648] usbcore: registered new interface driver asix [ 16.749029] usbcore: registered new interface driver ax88179_178a [ 16.769397] xen: registering gsi 16 triggering 0 polarity 1 [ 16.769401] Already setup the GSI :16 [ 16.789239] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 16.809708] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 [ 16.830793] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported [ 16.830910] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 16.852010] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 16.873421] usb usb1: Product: xHCI Host Controller [ 16.894670] usb usb1: Manufacturer: Linux 3.19.0-creanuc-20150209-doflr-spurious-pcidb6+ xhci-hcd [ 16.916200] usb usb1: SerialNumber: 0000:00:14.0 [ 16.937563] hub 1-0:1.0: USB hub found [ 16.958546] hub 1-0:1.0: 4 ports detected [ 16.979705] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 17.000776] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 [ 17.021719] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 [ 17.042599] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 17.063379] usb usb2: Product: xHCI Host Controller [ 17.084050] usb usb2: Manufacturer: Linux 3.19.0-creanuc-20150209-doflr-spurious-pcidb6+ xhci-hcd [ 17.105308] usb usb2: SerialNumber: 0000:00:14.0 [ 17.126615] hub 2-0:1.0: USB hub found [ 17.156665] hub 2-0:1.0: 4 ports detected [ 17.177372] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 17.197866] ehci-pci: EHCI PCI platform driver [ 17.218122] xen: registering gsi 16 triggering 0 polarity 1 [ 17.218125] Already setup the GSI :16 [ 17.238322] ehci-pci 0000:00:1a.0: EHCI Host Controller [ 17.258417] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 3 [ 17.278541] ehci-pci 0000:00:1a.0: debug port 2 [ 17.302271] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported [ 17.302309] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf7d38000 [ 17.403735] usb 1-3: new full-speed USB device number 2 using xhci_hcd [ 17.415612] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 [ 17.415748] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 17.415753] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 17.415757] usb usb3: Product: EHCI Host Controller [ 17.415760] usb usb3: Manufacturer: Linux 3.19.0-creanuc-20150209-doflr-spurious-pcidb6+ ehci_hcd [ 17.415763] usb usb3: SerialNumber: 0000:00:1a.0 [ 17.416217] hub 3-0:1.0: USB hub found [ 17.416234] hub 3-0:1.0: 3 ports detected [ 17.416835] xen: registering gsi 23 triggering 0 polarity 1 [ 17.416843] Already setup the GSI :23 [ 17.416939] ehci-pci 0000:00:1d.0: EHCI Host Controller [ 17.417167] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 4 [ 17.417213] ehci-pci 0000:00:1d.0: debug port 2 [ 17.421223] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported [ 17.421266] ehci-pci 0000:00:1d.0: irq 23, io mem 0xf7d37000 [ 17.427537] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 [ 17.427581] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002 [ 17.427582] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 17.427583] usb usb4: Product: EHCI Host Controller [ 17.427584] usb usb4: Manufacturer: Linux 3.19.0-creanuc-20150209-doflr-spurious-pcidb6+ ehci_hcd [ 17.427585] usb usb4: SerialNumber: 0000:00:1d.0 [ 17.427719] hub 4-0:1.0: USB hub found [ 17.427724] hub 4-0:1.0: 3 ports detected [ 17.427847] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 17.427853] ohci-pci: OHCI PCI platform driver [ 17.427867] ohci-platform: OHCI generic platform driver [ 17.427879] uhci_hcd: USB Universal Host Controller Interface driver [ 17.427919] usbcore: registered new interface driver usb-storage [ 17.427949] i8042: PNP: No PS/2 controller found. Probing ports directly. [ 18.469560] i8042: No controller found [ 18.487084] hv_vmbus: registering driver hyperv_keyboard [ 18.513828] mousedev: PS/2 mouse device common for all mice [ 18.532001] rtc_cmos 00:01: RTC can wake from S4 [ 18.550088] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0 [ 18.588840] rtc_cmos 00:01: alarms up to one month, y3k, 242 bytes nvram [ 18.606766] i2c /dev entries driver [ 18.624505] xen: registering gsi 18 triggering 0 polarity 1 [ 18.624508] Already setup the GSI :18 [ 18.642018] ACPI Warning: SystemIO range 0x000000000000f040-0x000000000000f05f conflicts with OpRegion 0x000000000000f040-0x000000000000f04f (\_SB_.PCI0.SBUS.SMBI) [ 18.652791] usb 1-3: New USB device found, idVendor=0d8c, idProduct=013c [ 18.652793] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 18.652794] usb 1-3: Product: USB PnP Sound Device [ 18.652796] usb 1-3: Manufacturer: C-Media Electronics Inc. [ 18.695548] usb 4-1: new high-speed USB device number 2 using ehci-pci [ 18.695563] usb 3-1: new high-speed USB device number 2 using ehci-pci [ 18.773585] (20141107/utaddress-258) [ 18.810329] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 18.829874] pps_ldisc: PPS line discipline registered [ 18.843975] usb 4-1: New USB device found, idVendor=8087, idProduct=0024 [ 18.843976] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 18.844014] usb 3-1: New USB device found, idVendor=8087, idProduct=0024 [ 18.844015] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 18.844211] hub 4-1:1.0: USB hub found [ 18.844234] hub 3-1:1.0: USB hub found [ 18.844314] hub 4-1:1.0: 8 ports detected [ 18.844318] hub 3-1:1.0: 6 ports detected [ 19.003098] w83627ehf: Found NCT6776F chip at 0xa30 [ 19.021697] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 [ 19.040197] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 19.058790] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) [ 19.077716] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 19.096512] iTCO_vendor_support: vendor-support=0 [ 19.115411] xen_wdt: Xen WatchDog Timer Driver v0.01 [ 19.115714] usb 4-1.5: new high-speed USB device number 3 using ehci-pci [ 19.153681] xen_wdt: cannot register miscdev on minor=130 (-16) [ 19.172905] wdt: probe of wdt failed with error -16 [ 19.192189] softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0) [ 19.212081] device-mapper: uevent: version 1.0.3 [ 19.224587] usb 4-1.5: New USB device found, idVendor=0b95, idProduct=772b [ 19.224588] usb 4-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 19.224590] usb 4-1.5: Product: AX88772C [ 19.224591] usb 4-1.5: Manufacturer: ASIX Elec. Corp. [ 19.224592] usb 4-1.5: SerialNumber: 000001 [ 19.332261] device-mapper: ioctl: 4.29.0-ioctl (2014-10-28) initialised: dm-devel@redhat.com [ 19.353238] device-mapper: multipath: version 1.7.0 loaded [ 19.378145] device-mapper: multipath round-robin: version 1.0.0 loaded [ 19.398333] leds_ss4200: no LED devices found [ 19.418244] hidraw: raw HID events driver (C) Jiri Kosina [ 19.439583] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.3/0003:0D8C:013C.0001/input/input2 [ 19.536401] hid-generic 0003:0D8C:013C.0001: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-0000:00:14.0-3/input3 [ 19.582742] usbcore: registered new interface driver usbhid [ 19.604713] usbhid: USB HID core driver [ 19.626657] hv_utils: Registering HyperV Utility Driver [ 19.648274] hv_vmbus: registering driver hv_util [ 19.676174] usbcore: registered new interface driver snd-usb-audio [ 19.697050] usbcore: registered new interface driver snd-ua101 [ 19.717373] usbcore: registered new interface driver snd-usb-usx2y [ 19.737529] usbcore: registered new interface driver snd-usb-us122l [ 19.757362] usbcore: registered new interface driver snd-usb-caiaq [ 19.777234] usbcore: registered new interface driver snd-usb-6fire [ 19.796719] usbcore: registered new interface driver snd-usb-hiface [ 19.816085] GACT probability on [ 19.834848] Mirror/redirect action on [ 19.853150] Simple TC action Loaded [ 19.871262] netem: version 1.3 [ 19.889071] u32 classifier [ 19.906693] Performance counters on [ 19.924301] input device check on [ 19.941692] Actions configured [ 19.959238] Netfilter messages via NETLINK v0.30. [ 19.977014] nfnl_acct: registering with nfnetlink. [ 19.995114] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 20.013440] ctnetlink v0.93: registering with nfnetlink. [ 20.031834] xt_time: kernel timezone is -0000 [ 20.049921] ip_set: protocol 6 [ 20.067711] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP) [ 20.085672] IPVS: Connection hash table configured (size=4096, memory=64Kbytes) [ 20.103826] IPVS: Creating netns size=1984 id=0 [ 20.121891] IPVS: ipvs loaded. [ 20.139625] IPVS: [rr] scheduler registered. [ 20.157218] IPVS: [wrr] scheduler registered. [ 20.174698] IPVS: [lc] scheduler registered. [ 20.191621] IPVS: [wlc] scheduler registered. [ 20.208045] IPVS: [lblc] scheduler registered. [ 20.224240] IPVS: [lblcr] scheduler registered. [ 20.240380] IPVS: [dh] scheduler registered. [ 20.256295] IPVS: [sh] scheduler registered. [ 20.272038] IPVS: [sed] scheduler registered. [ 20.287825] IPVS: [nq] scheduler registered. [ 20.303319] ip_tables: (C) 2000-2006 Netfilter Core Team [ 20.318707] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully [ 20.334257] arp_tables: (C) 2002 David S. Miller [ 20.349671] TCP: cubic registered [ 20.364895] Initializing XFRM netlink socket [ 20.379731] NET: Registered protocol family 10 [ 20.394216] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 20.408059] NET: Registered protocol family 17 [ 20.421341] NET: Registered protocol family 15 [ 20.434240] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. [ 20.461745] Ebtables v2.0 registered [ 20.475683] NET: Registered protocol family 33 [ 20.489457] Key type rxrpc registered [ 20.503445] asix 4-1.5:1.0 eth0: register 'asix' at usb-0000:00:1d.0-1.5, ASIX AX88772B USB 2.0 Ethernet, 00:0e:c6:f7:a4:2a [ 20.518624] Key type rxrpc_s registered [ 20.534009] 8021q: 802.1Q VLAN Support v1.8 [ 20.563627] Key type dns_resolver registered [ 20.579388] openvswitch: Open vSwitch switching datapath [ 20.595474] mpls_gso: MPLS GSO support [ 20.611921] registered taskstats version 1 [ 20.628834] Btrfs loaded [ 20.667025] console [netcon0] enabled [ 20.683211] netconsole: network logging started [ 20.699507] rtc_cmos 00:01: setting system clock to 2015-02-10 15:03:54 UTC (1423580634) [ 20.716436] ALSA device list: [ 20.733166] #0: C-Media Electronics Inc. USB PnP Sound Device at usb-0000:00:14.0-3, full speed [ 20.751193] Freeing unused kernel memory: 1016K (ffffffff81ee7000 - ffffffff81fe5000) [ 20.769102] Write protecting the kernel read-only data: 14336k [ 20.790867] Freeing unused kernel memory: 1404K (ffff8800018a1000 - ffff880001a00000) [ 20.809545] Freeing unused kernel memory: 940K (ffff880001d15000 - ffff880001e00000) [ 20.928664] udevd[178]: starting version 175 [ 21.210257] random: lvm urandom read with 76 bits of entropy available [ 21.503560] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) [ 22.320379] udevd[477]: starting version 175 [ 22.913155] random: nonblocking pool is initialized [ 23.014085] asix 4-1.5:1.0 eth-rescue: renamed from eth0 [ 24.105076] EXT4-fs (dm-0): re-mounted. Opts: (null) [ 24.295094] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro [ 25.715926] Adding 1949692k swap on /dev/mapper/creanuc-creanuc_swap. Priority:-1 extents:1 across:1949692k SS [ 26.144985] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro [ 27.739668] IPv6: ADDRCONF(NETDEV_UP): eth-rescue: link is not ready [ 27.792652] asix 4-1.5:1.0 eth-rescue: link down [ 29.457637] IPv6: ADDRCONF(NETDEV_CHANGE): eth-rescue: link becomes ready [ 29.481629] asix 4-1.5:1.0 eth-rescue: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 34.820913] device xen_ovs_bridge entered promiscuous mode [ 116.576695] device vif1.0-emu entered promiscuous mode [ 116.621078] device vif1.0 entered promiscuous mode [ 116.658291] IPv6: ADDRCONF(NETDEV_UP): vif1.0: link is not ready [ 117.061148] pciback 0000:02:00.0: resetting (FLR, D3, bus) the device [ 117.092324] pciback 0000:02:00.0: OK [ 117.123935] pciback 0000:02:00.0: xen_pcibk_reset_device: me heres [ 117.153042] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 118.336807] pciback 0000:00:19.0: resetting (FLR, D3, ) the device [ 118.371580] pci 0000:00:00.0: not owned by us! [ 118.475884] pciback 0000:00:19.0: xen_pcibk_reset_device: me heres [ 118.497516] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 [ 118.581239] xen-pciback pci-1-0: allocated pdev @ 0xffff88000007e9c0 [ 118.582466] xen-pciback pci-1-0: getting be setup [ 118.582683] xen-pciback pci-1-0: exporting dom 0 bus 2 slot 0 func 0 [ 118.582688] xen_pciback: vpci: 0000:02:00.0: assign to virtual slot 0 [ 118.613355] pciback 0000:02:00.0: registering for 1 [ 118.635176] xen-pciback pci-1-0: exporting dom 0 bus 0 slot 19 func 0 [ 118.635180] xen_pciback: vpci: 0000:00:19.0: assign to virtual slot 1 [ 118.657663] pciback 0000:00:19.0: registering for 1 [ 118.682808] xen-pciback pci-1-0: Publishing pci roots [ 118.682907] xen-pciback pci-1-0: writing root 0 at 0000:00 [ 118.686896] xen-pciback pci-1-0: fe state changed 1 [ 146.310213] xen-blkback:ring-ref 8, event-channel 19, protocol 1 (x86_64-abi) persistent grants [ 146.844857] vif vif-1-0 vif1.0: Guest Rx ready [ 146.866554] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 15:35 ` Sander Eikelenboom @ 2015-02-10 15:46 ` Konrad Rzeszutek Wilk 2015-02-10 16:22 ` Jan Beulich 1 sibling, 0 replies; 23+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-02-10 15:46 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: David Vrabel, Jan Beulich, xen-devel@lists.xen.org On Tue, Feb 10, 2015 at 04:35:47PM +0100, Sander Eikelenboom wrote: > > Tuesday, February 10, 2015, 2:26:43 PM, you wrote: > > >>>> On 10.02.15 at 14:07, <linux@eikelenboom.it> wrote: > >> Tuesday, February 10, 2015, 10:35:36 AM, you wrote: > >>>>>> On 10.02.15 at 10:19, <linux@eikelenboom.it> wrote: > >>>>> I would have thought that xen-pciback would install an interrupt > >>>>> handler here too when a device using IRQ 18 gets handed to a > >>>>> guest. May there be something broken in xen_pcibk_control_isr()? > >>>> > >>>> It seems to only do that for PV guests, not for HVM. > >> > >>> Interesting; no idea why that would be. > >> > >> Coming back to this part .. with some additional debugging on HVM guest > >> start i > >> get: > >> [ 84.362097] pciback 0000:02:00.0: resetting (FLR, D3, bus) the device > >> [ 84.422884] pciback 0000:02:00.0: xen_pcibk_reset_device: me here > >> [ 84.452639] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && > >> !dev_data->isr_on enable:0 dev_data->isr_on:0 > >> [ 85.636725] pciback 0000:00:19.0: resetting (FLR, D3, ) the device > >> [ 85.774845] pciback 0000:00:19.0: xen_pcibk_reset_device: me here > >> [ 85.810857] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && > >> !dev_data->isr_on enable:0 dev_data->isr_on:0 > >> [ 85.865075] xen_pciback: vpci: 0000:02:00.0: assign to virtual slot 0 > >> [ 85.886926] pciback 0000:02:00.0: registering for 1 > >> [ 85.907936] xen_pciback: vpci: 0000:00:19.0: assign to virtual slot 1 > >> [ 85.929490] pciback 0000:00:19.0: registering for 1 > >> > >> So it bails out on: > >> /* Asked to disable, but ISR isn't runnig */ > >> if (!enable && !dev_data->isr_on){ > >> dev_warn(&dev->dev, "%s: return !enable && !dev_data->isr_on > >> enable:%d dev_data->isr_on:%d\n", __func__, enable, dev_data->isr_on ? 1 : 0); > >> return; > >> } > > > I don't really know how this code is supposed to work (we don't use > > it in our kernels), but it seems the more interesting question is what > > happens when xen_pcibk_do_op() calls this function. I also note there > > is a sysfs interface to control some aspects of this, but I can't see how > > that would work when it only sets ->isr_on but doesn't install the IRQ > > handler if it isn't already installed. > > > Jan > > Suse is still forward porting and not considering upstream/pvops ? > > Hmmm it seems xen_pcibk_do_op() is never called .. > > Turned up the pciback debug, and annotated xen_pcibk_do_op() it self with > more warnings, it should print something when invoked. > complete dmesg attached. > > Here the debug output from pciback: > > seizing: > [ 9.113134] xen_pciback: wants to seize 0000:02:00.0 > [ 9.113137] xen_pciback: wants to seize 0000:00:19.0 > [ 9.113146] pciback 0000:00:00.0: probing... > [ 9.113154] pciback 0000:00:02.0: probing... > [ 9.113160] pciback 0000:00:14.0: probing... > [ 9.113165] pciback 0000:00:16.0: probing... > [ 9.113171] pciback 0000:00:16.3: probing... > [ 9.113176] pciback 0000:00:19.0: probing... > [ 9.113178] pciback 0000:00:19.0: seizing device > [ 9.113182] pciback 0000:00:19.0: pcistub_device_alloc > [ 9.113184] pciback 0000:00:19.0: deferring initialization > [ 9.113189] pciback 0000:00:1a.0: probing... > [ 9.113194] pciback 0000:00:1b.0: probing... > [ 9.113200] pciback 0000:00:1c.0: probing... > [ 9.113205] pciback 0000:00:1c.2: probing... > [ 9.113210] pciback 0000:00:1d.0: probing... > [ 9.113216] pciback 0000:00:1f.0: probing... > [ 9.113221] pciback 0000:00:1f.2: probing... > [ 9.113226] pciback 0000:00:1f.3: probing... > [ 9.113232] pciback 0000:02:00.0: probing... > [ 9.113234] pciback 0000:02:00.0: seizing device > [ 9.113237] pciback 0000:02:00.0: pcistub_device_alloc > [ 9.113239] pciback 0000:02:00.0: deferring initialization > > initialization while dom0 is still booting: > [ 14.371824] pciback 0000:02:00.0: initializing... > [ 14.371829] pciback 0000:02:00.0: initializing config > [ 14.371879] pciback 0000:02:00.0: enabling device > [ 14.371944] xen: registering gsi 18 triggering 0 polarity 1 > [ 14.371949] Already setup the GSI :18 > [ 14.372457] pciback 0000:02:00.0: save state of device > [ 14.372582] pciback 0000:02:00.0: resetting (FLR, D3, etc) the device > [ 14.403788] pciback 0000:02:00.0: reset device > [ 14.403794] pciback 0000:02:00.0: xen_pcibk_reset_device: me heres > [ 14.404638] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 > [ 14.406186] pciback 0000:00:19.0: initializing... > [ 14.406189] pciback 0000:00:19.0: initializing config > [ 14.406225] pciback 0000:00:19.0: enabling device > [ 14.406320] xen: registering gsi 20 triggering 0 polarity 1 > [ 14.406340] xen: --> pirq=20 -> irq=20 (gsi=20) > [ 14.406372] pciback 0000:00:19.0: save state of device > [ 14.406435] pciback 0000:00:19.0: resetting (FLR, D3, etc) the device > [ 14.507741] pciback 0000:00:19.0: reset device > [ 14.507747] pciback 0000:00:19.0: xen_pcibk_reset_device: me heres > [ 14.538842] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 > [ 14.571345] xen_pciback: backend is vpci > > guest start: > [ 117.061148] pciback 0000:02:00.0: resetting (FLR, D3, bus) the device > [ 117.092324] pciback 0000:02:00.0: OK > [ 117.123935] pciback 0000:02:00.0: xen_pcibk_reset_device: me heres > [ 117.153042] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 > [ 118.336807] pciback 0000:00:19.0: resetting (FLR, D3, ) the device > [ 118.371580] pci 0000:00:00.0: not owned by us! > [ 118.475884] pciback 0000:00:19.0: xen_pcibk_reset_device: me heres > [ 118.497516] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 > [ 118.581239] xen-pciback pci-1-0: allocated pdev @ 0xffff88000007e9c0 > [ 118.582466] xen-pciback pci-1-0: getting be setup > [ 118.582683] xen-pciback pci-1-0: exporting dom 0 bus 2 slot 0 func 0 > [ 118.582688] xen_pciback: vpci: 0000:02:00.0: assign to virtual slot 0 > [ 118.613355] pciback 0000:02:00.0: registering for 1 > [ 118.635176] xen-pciback pci-1-0: exporting dom 0 bus 0 slot 19 func 0 > [ 118.635180] xen_pciback: vpci: 0000:00:19.0: assign to virtual slot 1 > [ 118.657663] pciback 0000:00:19.0: registering for 1 > [ 118.682808] xen-pciback pci-1-0: Publishing pci roots > [ 118.682907] xen-pciback pci-1-0: writing root 0 at 0000:00 > [ 118.686896] xen-pciback pci-1-0: fe state changed 1 > > > > So this one is up to Konrad i guess ... > > I haven't checked the call chain of xen_pcibk_do_op .. but that could be a > side effect of libxl not imitating pci-front good enough (since HVM guests > don't use the pci-front driver, but instead rely on libxl and Qemu to play > those parts. Yup. It (the call to setup the ISR) is driven by the PV pci protocol which of course HVM guests don't use. But setting this ISR up needn't be tied in with the PV PCI protocol. Thank you for narrowing this down! ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 15:35 ` Sander Eikelenboom 2015-02-10 15:46 ` Konrad Rzeszutek Wilk @ 2015-02-10 16:22 ` Jan Beulich 2015-02-10 17:30 ` Sander Eikelenboom 1 sibling, 1 reply; 23+ messages in thread From: Jan Beulich @ 2015-02-10 16:22 UTC (permalink / raw) To: linux; +Cc: david.vrabel, xen-devel >>> Sander Eikelenboom <linux@eikelenboom.it> 02/10/15 5:01 PM >>> >Tuesday, February 10, 2015, 2:26:43 PM, you wrote: >>>> On 10.02.15 at 14:07, <linux@eikelenboom.it> wrote: >> I don't really know how this code is supposed to work (we don't use >> it in our kernels), but it seems the more interesting question is what >> happens when xen_pcibk_do_op() calls this function. I also note there >> is a sysfs interface to control some aspects of this, but I can't see how >> that would work when it only sets ->isr_on but doesn't install the IRQ >> handler if it isn't already installed. >Suse is still forward porting and not considering upstream/pvops ? We're preparing to switch, but we aren't there yet. >So this one is up to Konrad i guess ... Indeed. >I haven't checked the call chain of xen_pcibk_do_op .. but that could be a >side effect of libxl not imitating pci-front good enough (since HVM guests >don't use the pci-front driver, but instead rely on libxl and Qemu to play >those parts. I thought the frontend functionality was entirely in qemu. Does this behave identical between qemu-trad and qemu-upstream? >One of the issues i already mentioned that devices never get to the state >connected, for HVM guests. The backend state stays 3 (XenbusStateInitialised) >and the frontend state stays 1 (XenbusStateInitialising). That sounds wrong too - not sure from where this state are driven for pcifront (see above). Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 16:22 ` Jan Beulich @ 2015-02-10 17:30 ` Sander Eikelenboom 2015-02-10 17:47 ` Jan Beulich 0 siblings, 1 reply; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-10 17:30 UTC (permalink / raw) To: Jan Beulich; +Cc: david.vrabel, xen-devel Tuesday, February 10, 2015, 5:22:16 PM, you wrote: >>>> Sander Eikelenboom <linux@eikelenboom.it> 02/10/15 5:01 PM >>> >>Tuesday, February 10, 2015, 2:26:43 PM, you wrote: >>>>> On 10.02.15 at 14:07, <linux@eikelenboom.it> wrote: >>> I don't really know how this code is supposed to work (we don't use >>> it in our kernels), but it seems the more interesting question is what >>> happens when xen_pcibk_do_op() calls this function. I also note there >>> is a sysfs interface to control some aspects of this, but I can't see how >>> that would work when it only sets ->isr_on but doesn't install the IRQ >>> handler if it isn't already installed. >>Suse is still forward porting and not considering upstream/pvops ? > We're preparing to switch, but we aren't there yet. >>So this one is up to Konrad i guess ... > Indeed. >>I haven't checked the call chain of xen_pcibk_do_op .. but that could be a >>side effect of libxl not imitating pci-front good enough (since HVM guests >>don't use the pci-front driver, but instead rely on libxl and Qemu to play >>those parts. > I thought the frontend functionality was entirely in qemu. Does this behave > identical between qemu-trad and qemu-upstream? AFIAK yes, just tested and also with qemu-trad the xenstore front end pci entry stays state "1" .. and therefor pciback doesn't get further then state "3". qemu doesn't do xenbus itself (at least not for pci) libxl isn't notified by qemu that the device is setup (nor has the functionality in place to actually change the xenstore entry for this case) So nothing happens. >>One of the issues i already mentioned that devices never get to the state >>connected, for HVM guests. The backend state stays 3 (XenbusStateInitialised) >>and the frontend state stays 1 (XenbusStateInitialising). > That sounds wrong too - not sure from where this state are driven for > pcifront (see above). For pv-guests, pci-back and pci-front mostly do there own dance driven by those xenbustate changes. Libxl for PV guests even waits for the xenbusstate to become "4" aka connected in libxl_pci.c. For HVM guests it's really up to libxl at the moment, but it lacks in multiple fashions. (probably it worked with xend but these things didn't get ported properly to libxl yet, probably because from a glance everything seems to work fine). But when you try to mimic it by hand after the guest has started (just write to the xenstore entry with xenstore-write and up it from state "1" to state "2" or state "3", with: xenstore-write /local/domain/1/device/pci/0/state 2 or xenstore-write /local/domain/1/device/pci/0/state 3 You will notice xenpciback responds, but it tries to read some pci-front config directly, but that fails since there is no pcifront connection. [ 926.050193] xen-pciback pci-1-0: fe state changed 3 [ 926.050964] xen-pciback pci-1-0: Reading frontend config [ 926.051189] xen-pciback pci-1-0: 2 Error reading configuration from frontend So that should probably be skipped. with: xenstore-write /local/domain/1/device/pci/0/state 4 we get: [ 1053.062003] xen-pciback pci-1-0: fe state changed 4 Now the "root" pciback entry state is also changed to 4 .. however the individual device entries underneath are still state 3. Apart from that most of the xenstore-watches in the code seem to be on that root entry and not on the individual devices, which is probably going to lead to problems when only removing one of the passed through devices from a given guest (when the rest would be working properly). So it's a multi-headed beast .. and i don't know if the way it's put together and if the limited available states (and the limitation of xenstore-watches) are actually enough to make this work properly. The only spec about which side is supposed to do what when (and what when it fails) ... seems to be the xen-pciback and pci-front code. Not to mention backward compatibility (it's broken but it does work) So it is far above my limited c-skills (i'm able to read to a certain extent but not write) and lack of knowledge about the libxl-ishms with respect to timeouts callbacks and all that kind of stuff. -- Sander > Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 17:30 ` Sander Eikelenboom @ 2015-02-10 17:47 ` Jan Beulich 2015-02-10 18:26 ` Sander Eikelenboom 0 siblings, 1 reply; 23+ messages in thread From: Jan Beulich @ 2015-02-10 17:47 UTC (permalink / raw) To: linux Cc: wei.liu2, stefano.stabellini, Ian.Jackson, xen-devel, Ian.Campbell, david.vrabel >>> Sander Eikelenboom <linux@eikelenboom.it> 02/10/15 6:30 PM >>> >Tuesday, February 10, 2015, 5:22:16 PM, you wrote: >>>>> Sander Eikelenboom <linux@eikelenboom.it> 02/10/15 5:01 PM >>> >>>I haven't checked the call chain of xen_pcibk_do_op .. but that could be a >>>side effect of libxl not imitating pci-front good enough (since HVM guests >>>don't use the pci-front driver, but instead rely on libxl and Qemu to play >>>those parts. > >> I thought the frontend functionality was entirely in qemu. Does this behave >> identical between qemu-trad and qemu-upstream? > >AFIAK yes, just tested and also with qemu-trad the xenstore front end pci entry >stays state "1" .. and therefor pciback doesn't get further then state "3". > >qemu doesn't do xenbus itself (at least not for pci) >libxl isn't notified by qemu that the device is setup (nor has the functionality >in place to actually change the xenstore entry for this case) > >So nothing happens. > >>>One of the issues i already mentioned that devices never get to the state >>>connected, for HVM guests. The backend state stays 3 (XenbusStateInitialised) >>>and the frontend state stays 1 (XenbusStateInitialising). > >> That sounds wrong too - not sure from where this state are driven for >> pcifront (see above). > >For pv-guests, pci-back and pci-front mostly do there own dance driven by those >xenbustate changes. Libxl for PV guests even waits for the xenbusstate to become >"4" aka connected in libxl_pci.c. > >For HVM guests it's really up to libxl at the moment, but it lacks in multiple >fashions. (probably it worked with xend but these things didn't get ported >properly to libxl yet, probably because from a glance everything seems to work >fine). So let's ask the tool stack and qemu maintainers (now Cc-ed) about how this is supposed to work, and how much of that is known to actually be implemented. Jan >But when you try to mimic it by hand after the guest has started >(just write to the xenstore entry with xenstore-write and up it from state "1" >to state "2" or state "3", with: > >xenstore-write /local/domain/1/device/pci/0/state 2 >or >xenstore-write /local/domain/1/device/pci/0/state 3 > >You will notice xenpciback responds, but it tries to read some pci-front config >directly, but that fails since there is no pcifront connection. >[ 926.050193] xen-pciback pci-1-0: fe state changed 3 >[ 926.050964] xen-pciback pci-1-0: Reading frontend config >[ 926.051189] xen-pciback pci-1-0: 2 Error reading configuration from frontend > >So that should probably be skipped. > >with: >xenstore-write /local/domain/1/device/pci/0/state 4 > >we get: >[ 1053.062003] xen-pciback pci-1-0: fe state changed 4 > >Now the "root" pciback entry state is also changed to 4 .. >however the individual device entries underneath are still state 3. > >Apart from that most of the xenstore-watches in the code seem to be on that root >entry and not on the individual devices, which is probably going to lead to >problems when only removing one of the passed through devices from a given guest >(when the rest would be working properly). > >So it's a multi-headed beast .. and i don't know if the way it's put together >and if the limited available states (and the limitation of xenstore-watches) >are actually enough to make this work properly. >The only spec about which side is supposed to do what when (and what >when it fails) ... seems to be the xen-pciback and pci-front code. > >Not to mention backward compatibility (it's broken but it does work) > >So it is far above my limited c-skills (i'm able to read to a certain extent but not write) >and lack of knowledge about the libxl-ishms with respect to timeouts callbacks >and all that kind of stuff. > >-- >Sander ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 17:47 ` Jan Beulich @ 2015-02-10 18:26 ` Sander Eikelenboom 0 siblings, 0 replies; 23+ messages in thread From: Sander Eikelenboom @ 2015-02-10 18:26 UTC (permalink / raw) To: Jan Beulich Cc: wei.liu2, stefano.stabellini, Ian.Jackson, xen-devel, Ian.Campbell, david.vrabel Tuesday, February 10, 2015, 6:47:46 PM, you wrote: >>>> Sander Eikelenboom <linux@eikelenboom.it> 02/10/15 6:30 PM >>> >>Tuesday, February 10, 2015, 5:22:16 PM, you wrote: >>>>>> Sander Eikelenboom <linux@eikelenboom.it> 02/10/15 5:01 PM >>> >>>>I haven't checked the call chain of xen_pcibk_do_op .. but that could be a >>>>side effect of libxl not imitating pci-front good enough (since HVM guests >>>>don't use the pci-front driver, but instead rely on libxl and Qemu to play >>>>those parts. >> >>> I thought the frontend functionality was entirely in qemu. Does this behave >>> identical between qemu-trad and qemu-upstream? >> >>AFIAK yes, just tested and also with qemu-trad the xenstore front end pci entry >>stays state "1" .. and therefor pciback doesn't get further then state "3". >> >>qemu doesn't do xenbus itself (at least not for pci) >>libxl isn't notified by qemu that the device is setup (nor has the functionality >>in place to actually change the xenstore entry for this case) >> >>So nothing happens. >> >>>>One of the issues i already mentioned that devices never get to the state >>>>connected, for HVM guests. The backend state stays 3 (XenbusStateInitialised) >>>>and the frontend state stays 1 (XenbusStateInitialising). >> >>> That sounds wrong too - not sure from where this state are driven for >>> pcifront (see above). >> >>For pv-guests, pci-back and pci-front mostly do there own dance driven by those >>xenbustate changes. Libxl for PV guests even waits for the xenbusstate to become >>"4" aka connected in libxl_pci.c. >> >>For HVM guests it's really up to libxl at the moment, but it lacks in multiple >>fashions. (probably it worked with xend but these things didn't get ported >>properly to libxl yet, probably because from a glance everything seems to work >>fine). > So let's ask the tool stack and qemu maintainers (now Cc-ed) about how this is > supposed to work, and how much of that is known to actually be implemented. > Jan Hmm just had a look at /tools/python/xen/xend/server/pciif.py and that also in "reconfigureDevice(self, _, config" just seems to set the guest/pcifront xenstore entry to state "1". No special casing between PV and HVM, so i suppose that that should have lead to the same result, on PV guest it will do the "states-dance" between pciback and front, but on HVM guests it doesn't. -- Sander >>But when you try to mimic it by hand after the guest has started >>(just write to the xenstore entry with xenstore-write and up it from state "1" >>to state "2" or state "3", with: >> >>xenstore-write /local/domain/1/device/pci/0/state 2 >>or >>xenstore-write /local/domain/1/device/pci/0/state 3 >> >>You will notice xenpciback responds, but it tries to read some pci-front config >>directly, but that fails since there is no pcifront connection. >>[ 926.050193] xen-pciback pci-1-0: fe state changed 3 >>[ 926.050964] xen-pciback pci-1-0: Reading frontend config >>[ 926.051189] xen-pciback pci-1-0: 2 Error reading configuration from frontend >> >>So that should probably be skipped. >> >>with: >>xenstore-write /local/domain/1/device/pci/0/state 4 >> >>we get: >>[ 1053.062003] xen-pciback pci-1-0: fe state changed 4 >> >>Now the "root" pciback entry state is also changed to 4 .. >>however the individual device entries underneath are still state 3. >> >>Apart from that most of the xenstore-watches in the code seem to be on that root >>entry and not on the individual devices, which is probably going to lead to >>problems when only removing one of the passed through devices from a given guest >>(when the rest would be working properly). >> >>So it's a multi-headed beast .. and i don't know if the way it's put together >>and if the limited available states (and the limitation of xenstore-watches) >>are actually enough to make this work properly. >>The only spec about which side is supposed to do what when (and what >>when it fails) ... seems to be the xen-pciback and pci-front code. >> >>Not to mention backward compatibility (it's broken but it does work) >> >>So it is far above my limited c-skills (i'm able to read to a certain extent but not write) >>and lack of knowledge about the libxl-ishms with respect to timeouts callbacks >>and all that kind of stuff. >> >>-- >>Sander ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 kernel - irq nobody cared ... the continuing saga .. 2015-02-10 13:07 ` Sander Eikelenboom 2015-02-10 13:26 ` Jan Beulich @ 2015-02-10 15:13 ` Konrad Rzeszutek Wilk 1 sibling, 0 replies; 23+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-02-10 15:13 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: David Vrabel, Jan Beulich, xen-devel@lists.xen.org On Tue, Feb 10, 2015 at 02:07:05PM +0100, Sander Eikelenboom wrote: > > Tuesday, February 10, 2015, 10:35:36 AM, you wrote: > > >>>> On 10.02.15 at 10:19, <linux@eikelenboom.it> wrote: > >>> Coming back to the /proc/interrupts output you posted earlier: > >> > >>> /proc/interrupts shows the high count: > >> > >>> CPU0 CPU1 CPU2 CPU3 > >>> 8: 0 0 0 0 xen-pirq-ioapic-edge rtc0 > >>> 9: 1 0 0 0 xen-pirq-ioapic-level acpi > >>> 16: 29 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb3 > >>> 18: 200000 0 0 0 xen-pirq-ioapic-level ata_generic > >> > >>> I would have thought that xen-pciback would install an interrupt > >>> handler here too when a device using IRQ 18 gets handed to a > >>> guest. May there be something broken in xen_pcibk_control_isr()? > >> > >> It seems to only do that for PV guests, not for HVM. > > > Interesting; no idea why that would be. > > Hi Jan, > > Coming back to this part .. with some additional debugging on HVM guest start i > get: > [ 84.362097] pciback 0000:02:00.0: resetting (FLR, D3, bus) the device > [ 84.422884] pciback 0000:02:00.0: xen_pcibk_reset_device: me here > [ 84.452639] pciback 0000:02:00.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 > [ 85.636725] pciback 0000:00:19.0: resetting (FLR, D3, ) the device > [ 85.774845] pciback 0000:00:19.0: xen_pcibk_reset_device: me here > [ 85.810857] pciback 0000:00:19.0: xen_pcibk_control_isr: return !enable && !dev_data->isr_on enable:0 dev_data->isr_on:0 > [ 85.865075] xen_pciback: vpci: 0000:02:00.0: assign to virtual slot 0 > [ 85.886926] pciback 0000:02:00.0: registering for 1 > [ 85.907936] xen_pciback: vpci: 0000:00:19.0: assign to virtual slot 1 > [ 85.929490] pciback 0000:00:19.0: registering for 1 > > So it bails out on: /me nods. That is with the 'reset' set, so no installing of the ISR. Let me cook up a patch that will always install the ISR. > /* Asked to disable, but ISR isn't runnig */ > if (!enable && !dev_data->isr_on){ > dev_warn(&dev->dev, "%s: return !enable && !dev_data->isr_on enable:%d dev_data->isr_on:%d\n", __func__, enable, dev_data->isr_on ? 1 : 0); > return; > } > > -- > Sander > > >> Don't know how it wil go now after the bios update, > >> lspci lists the SMBUS is also using irq 18 now, but it doesn't register > >> a driver (according to lspci -k) and it doesn't appear in dom0's > >> /proc/interrupts. > > > With that I don't think you're going to have problems, as the IRQ > > then is masked. > > >> How are things supposed to work with a machine with: > >> - a shared irq > >> - iommu + interrupt remapping enabled > >> - HVM guests > > > Konrad? > > >> Would dom0 always see the legacy irq or is Xen or the iommu routing it > >> directly to > >> the guest ? > > > A shared IRQ can't be routed directly, as all involved domains need > > to see it. > > >> And what would i suppose to see when using Xen's debug key 'i', should there > >> be an entry routing it to both guests ? > > > Yes, if both have a driver using it. > > >>. if you know some better way to figure out where the irq storm is > >> coming from or headed to .. i'm all ears (or eyes) .. > > > I suppose that's because there's no handler installed by pciback, yet > > IRQs generated by the passed through device also arrive in Dom0, > > and the driver for the device left in Dom0 doesn't claim the interrupts. > > > Jan > > > ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2015-02-10 18:26 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-02-09 15:03 dom0 kernel - irq nobody cared ... the continuing saga Sander Eikelenboom 2015-02-09 15:18 ` David Vrabel 2015-02-09 15:39 ` Sander Eikelenboom 2015-02-09 16:36 ` Jan Beulich 2015-02-09 17:13 ` Sander Eikelenboom 2015-02-10 8:48 ` Jan Beulich 2015-02-10 9:19 ` Sander Eikelenboom 2015-02-10 9:35 ` Jan Beulich 2015-02-10 10:03 ` Sander Eikelenboom 2015-02-10 10:36 ` Jan Beulich 2015-02-10 10:47 ` Sander Eikelenboom 2015-02-10 10:57 ` Jan Beulich 2015-02-10 10:59 ` Andrew Cooper 2015-02-10 11:21 ` Jan Beulich 2015-02-10 13:07 ` Sander Eikelenboom 2015-02-10 13:26 ` Jan Beulich 2015-02-10 15:35 ` Sander Eikelenboom 2015-02-10 15:46 ` Konrad Rzeszutek Wilk 2015-02-10 16:22 ` Jan Beulich 2015-02-10 17:30 ` Sander Eikelenboom 2015-02-10 17:47 ` Jan Beulich 2015-02-10 18:26 ` Sander Eikelenboom 2015-02-10 15:13 ` Konrad Rzeszutek Wilk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.