* XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
@ 2010-10-26 17:11 Jens Friedrich
2010-11-11 16:18 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 17+ messages in thread
From: Jens Friedrich @ 2010-10-26 17:11 UTC (permalink / raw)
To: xen-devel
Hi,
i have a VT-d System FSC Celsius W360, which runs perfect with pvops kernel
and XEN 4.0.1 (Debian Squeeze 64Bit), but can’t start Xenlinux 2.6.18.8.
Boot stops at ACPI: PCI Root Bridge [PCI0] (0000:00) also on XEN 4.0.1
64-Bit and XEN 3.4.2 Hypervisor (which was taken from my PROD System and has
a uptime from 150 days actually with PVUSB and PCIpassthrough to different
Domains – rock stable!!). Also, VT-d is working on that system
(PCIpassthrough to Windows 7 HVM), but VGA don’t (Intel IGD and Q35 Express
Chipset). Xenserver V5.5 and 5.6 is also working perfectly…
Here’s my Bootlog, any hint’s or suggestions?
Regards
Jens Friedrich aka Neobiker www.neobiker.de
--SNIPP----
__ __ _ _ ___ _
\ \/ /___ _ __ | || | / _ \ / |
\ // _ \ '_ \ | || |_| | | || |
/ \ __/ | | | |__ _| |_| || |
/_/\_\___|_| |_| |_|(_)___(_)_|
(XEN) Xen version 4.0.1 (root@friedrichnet.de) (gcc version 4.3.2 (Debian
4.3.2-1.1) ) Mon Oct 25 22:17:13 CEST 2010
(XEN) Latest ChangeSet: Wed Aug 25 09:22:42 2010 +0100 21324:b536ebfba183
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 1.98+20100804-4
(XEN) Command line: dom0_mem=384M com1=115200,8n1 console=com1,vga
sync_console sync_to_ring loglvl=all guestloglvl=all
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 3 MBR signatures
(XEN) Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009c800 (usable)
(XEN) 000000000009c800 - 00000000000a0000 (reserved)
(XEN) 00000000000ce000 - 00000000000d0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007d4d0000 (usable)
(XEN) 000000007d4d0000 - 000000007d4d8000 (ACPI data)
(XEN) 000000007d4d8000 - 000000007d4db000 (ACPI NVS)
(XEN) 000000007d4db000 - 0000000080000000 (reserved)
(XEN) 00000000f8000000 - 00000000fc000000 (reserved)
(XEN) 00000000fec00000 - 00000000fec10000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffb00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2004MB (2052528kB)
(XEN) ACPI: RSDP 000F7320, 0014 (r0 PTLTD )
(XEN) ACPI: RSDT 7D4D2AEE, 005C (r1 FSC PC 60000 LTP 0)
(XEN) ACPI: FACP 7D4D78B5, 0074 (r1 FSC 60000 F4240)
(XEN) ACPI: DSDT 7D4D2B4A, 4D6B (r1 FSC D2587/A1 60000 MSFT 3000001)
(XEN) ACPI: FACS 7D4DAFC0, 0040
(XEN) ACPI: TCPA 7D4D7929, 0032 (r1 Phoeni x 60000 TL 0)
(XEN) ACPI: DMAR 7D4D795B, 00F8 (r1 Intel OEMDMAR 60000 LOHR 1)
(XEN) ACPI: SSDT 7D4D7A53, 007A (r1 FSC CST_CPU0 60000 CSF 1)
(XEN) ACPI: SSDT 7D4D7ACD, 007A (r1 FSC CST_CPU1 60000 CSF 1)
(XEN) ACPI: SSDT 7D4D7B47, 00B6 (r1 FSC PST_CPU0 60000 CSF 1)
(XEN) ACPI: SSDT 7D4D7BFD, 00B6 (r1 FSC PST_CPU1 60000 CSF 1)
(XEN) ACPI: SPCR 7D4D7CB3, 0050 (r1 PTLTD $UCRTBL$ 60000 PTL 1)
(XEN) ACPI: SLIC 7D4D7D03, 0176 (r1 FSC PC 60000 LTP 0)
(XEN) ACPI: MCFG 7D4D7E79, 003C (r1 PTLTD MCFG 60000 LTP 0)
(XEN) ACPI: HPET 7D4D7EB5, 0038 (r1 PTLTD HPETTBL 60000 LTP 1)
(XEN) ACPI: APIC 7D4D7EED, 0068 (r1 PTLTD APIC 60000 LTP
0)
(XEN) ACPI: BOOT 7D4D7F55, 0028 (r1 PTLTD $SBFTBL$ 60000 LTP 1)
(XEN) ACPI: ASF! 7D4D7F7D, 0083 (r16 CETP CETP 60000 PTL 1)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000007d4d0000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f7420
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[1004,0], pm1x_evt[1000,0]
(XEN) ACPI: wakeup_vec[7d4dafcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:7 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) Processor #1 7:7 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 3
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2992.566 MHz processor.
(XEN) Initing memory sharing.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) xsave_init: cpu0: cntxt_max_size: 0x240 and states: 00000000:00000003
(XEN) xsave_init: using cntxt_size: 0x240 and states: 00000000:00000003
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d Snoop Control not supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation not supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) xsave_init: cpu1: cntxt_max_size: 0x240 and states: 00000000:00000003
(XEN) Total of 2 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) checking TSC synchronization across 2 CPUs: passed.
(XEN) Platform timer is 14.318MHz HPET
ÿ(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 2 CPUs
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0x200000 -> 0x5ec2ac
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 000000007a800000->000000007b000000 (96256 pages to be
allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff805ec2ac
(XEN) Init. ramdisk: ffffffff805ed000->ffffffff805ed000
(XEN) Phys-Mach map: ffffffff805ed000->ffffffff806ad000
(XEN) Start info: ffffffff806ad000->ffffffff806ad4b4
(XEN) Page tables: ffffffff806ae000->ffffffff806b5000
(XEN) Boot stack: ffffffff806b5000->ffffffff806b6000
(XEN) TOTAL: ffffffff80000000->ffffffff80800000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 2 VCPUs
(XEN) [VT-D]iommu.c:821: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:824: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:799: DMAR:[DMA Write] Request device [00:02.0] fault
addr ffffff000, iommu reg = ffff82c3fff56000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) print_vtd_entries: iommu = ffff83007d073790 bdf = 0:2.0 gmfn = ffffff
(XEN) root_entry = ffff83007d273000
(XEN) root_entry[0] = 633da001
(XEN) context = ffff8300633da000
(XEN) context[10] = 1_63be0001
(XEN) l3 = ffff830063be0000
(XEN) l3_index = 3f
(XEN) l3[3f] = 0
(XEN) l3[3f] not present
(XEN) Scrubbing Free RAM: ...............done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
Xen)
(XEN) Freed 176kB init memory.
[ 0.000000] Bootdata ok (command line is root=/dev/sdb8 ro console=xvc0
console=ttyS0 earlyprintk=xen)
[ 0.000000] Linux version 2.6.18.8-xen (root@xen4) (gcc version 4.3.2
(Debian 4.3.2-1.1) ) #3 SMP Sun Oct 24 19:30:10 CEST 2010
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 0000000018800000 (usable)
kernel direct mapping tables up to 18800000 @ 6b5000-77b000
[ 4.458412] DMI present.
[ 4.465717] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 4.471370] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 4.477160] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 4.483043] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 4.488928] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 4.495164] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI
0-23
[ 4.501997] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[ 4.508486] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 4.515067] Setting APIC routing to xen
[ 4.518871] Using ACPI (MADT) for SMP configuration information
[ 4.527089] Allocating PCI resources starting at 88000000 (gap:
80000000:78000000)
[ 4.534500] Built 1 zonelists. Total pages: 97575
[ 4.539220] Kernel command line: root=/dev/sdb8 ro console=xvc0
console=ttyS0 earlyprintk=xen
[ 4.548075] Initializing CPU#0
[ 4.551053] PID hash table entries: 2048 (order: 11, 16384 bytes)
[ 4.557026] Xen reported: 2992.566 MHz processor.
[ 4.561679] disabling early console
[ 0.000000] Bootdata ok (command line is root=/dev/sdb8 ro console=xvc0
console=ttyS0 earlyprintk=xen)
[ 0.000000] Linux version 2.6.18.8-xen (root@xen4) (gcc version 4.3.2
(Debian 4.3.2-1.1) ) #3 SMP Sun Oct 24 19:30:10 CEST 2010
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 0000000018800000 (usable)
[ 4.458412] DMI present.
[ 4.465717] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 4.471370] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 4.477160] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 4.483043] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 4.488928] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 4.495164] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI
0-23
[ 4.501997] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[ 4.508486] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 4.515067] Setting APIC routing to xen
[ 4.518871] Using ACPI (MADT) for SMP configuration information
[ 4.527089] Allocating PCI resources starting at 88000000 (gap:
80000000:78000000)
[ 4.534500] Built 1 zonelists. Total pages: 97575
[ 4.539220] Kernel command line: root=/dev/sdb8 ro console=xvc0
console=ttyS0 earlyprintk=xen
[ 4.548075] Initializing CPU#0
[ 4.551053] PID hash table entries: 2048 (order: 11, 16384 bytes)
[ 4.557026] Xen reported: 2992.566 MHz processor.
[ 4.561679] disabling early console
[ 4.568227] Console: colour VGA+ 80x25
[ 4.703351] Dentry cache hash table entries: 65536 (order: 7, 524288
bytes)
[ 4.710290] Inode-cache hash table entries: 32768 (order: 6, 262144
bytes)
[ 4.718570] Software IO TLB enabled:
[ 4.718571] Aperture: 2 megabytes
[ 4.718571] Kernel range: ffff88000173e000 - ffff88000193e000
[ 4.718572] Address size: 22 bits
[ 4.734944] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 4.743138] Memory: 378632k/401408k available (2154k kernel code, 14372k
reserved, 969k data, 192k init)
[ 4.820431] Calibrating delay using timer specific routine.. 5987.26
BogoMIPS (lpj=11974527)
[ 4.828691] Security Framework v1.0.0 initialized
[ 4.833348] Capability LSM initialized
[ 4.837073] Mount-cache hash table entries: 256
[ 4.841659] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 4.846239] CPU: L2 cache: 6144K
[ 4.849455] SMP alternatives: switching to UP code
[ 4.854277] ACPI: Core revision 20060707
[ 4.922798] SMP alternatives: switching to SMP code
[ 4.927557] Brought up 2 CPUs
[ 4.927541] Initializing CPU#1
[ 4.927562] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 4.927563] CPU: L2 cache: 6144K
[ 5.014445] migration_cost=9
[ 5.017588] NET: Registered protocol family 16
[ 5.021929] ACPI: bus type pci registered
[ 5.025847] PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 -
3
[ 5.032663] PCI: MCFG area at f8000000 reserved in E820
[ 5.038038] PCI: Using MMCONFIG at f8000000 - f83fffff
[ 5.044971] ACPI: Interpreter enabled
[ 5.048452] ACPI: Using IOAPIC for interrupt routing
[ 5.053692] ACPI: PCI Root Bridge [PCI0] (0000:00)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-10-26 17:11 XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00) Jens Friedrich
@ 2010-11-11 16:18 ` Konrad Rzeszutek Wilk
2010-11-11 17:16 ` Neobiker
0 siblings, 1 reply; 17+ messages in thread
From: Konrad Rzeszutek Wilk @ 2010-11-11 16:18 UTC (permalink / raw)
To: Jens Friedrich; +Cc: xen-devel
On Tue, Oct 26, 2010 at 07:11:37PM +0200, Jens Friedrich wrote:
> Hi,
> i have a VT-d System FSC Celsius W360, which runs perfect with pvops kernel
> and XEN 4.0.1 (Debian Squeeze 64Bit), but can’t start Xenlinux 2.6.18.8.
> Boot stops at ACPI: PCI Root Bridge [PCI0] (0000:00) also on XEN 4.0.1
> 64-Bit and XEN 3.4.2 Hypervisor (which was taken from my PROD System and has
> a uptime from 150 days actually with PVUSB and PCIpassthrough to different
> Domains – rock stable!!). Also, VT-d is working on that system
> (PCIpassthrough to Windows 7 HVM), but VGA don’t (Intel IGD and Q35 Express
> Chipset). Xenserver V5.5 and 5.6 is also working perfectly…
>
> Here’s my Bootlog, any hint’s or suggestions?
Why do you want to use 2.6.18 when the later kernels work?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-11 16:18 ` Konrad Rzeszutek Wilk
@ 2010-11-11 17:16 ` Neobiker
2010-11-12 22:19 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 17+ messages in thread
From: Neobiker @ 2010-11-11 17:16 UTC (permalink / raw)
To: xen-devel
Hi Konrad,
many folks need to use the Xenlinux Kernel due to missing features in pvops
kernel...
For me (neobiker), it's at a minimum pvusb for my VDR System which uses an
usb device for DVB-S :-)
I also use a usb printer on my printer DomU.
Also, i think it is interesting, why the kernel doesn't work at this point,
the xen 4.0.2-rc1-pre version starts nowadays on this host - very strange
behaviour.
So, i look forward completing the pvops kernel with missing features an to
get xen development on an actual kernel version, to get rid of the actual
"feature works" in kernel x, but not in y and the corresponding config chaos
for different xen versions nowadays!
It took me a week to summarize the actual xen wiki to meet the many
dependencies an differences for some articles in a german magazin (c't).
regards
neobiker (Jens Friedrich)
www.neobiker.de
--
View this message in context: http://xen.1045712.n5.nabble.com/XEN-boot-hangs-at-ACPI-PCI-Root-Bridge-PCI0-0000-00-tp3259065p3260687.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-11 17:16 ` Neobiker
@ 2010-11-12 22:19 ` Konrad Rzeszutek Wilk
2010-11-12 23:20 ` Sander Eikelenboom
2010-11-13 10:14 ` Neobiker
0 siblings, 2 replies; 17+ messages in thread
From: Konrad Rzeszutek Wilk @ 2010-11-12 22:19 UTC (permalink / raw)
To: Neobiker; +Cc: xen-devel
On Thu, Nov 11, 2010 at 09:16:35AM -0800, Neobiker wrote:
>
> Hi Konrad,
>
> many folks need to use the Xenlinux Kernel due to missing features in pvops
> kernel...
> For me (neobiker), it's at a minimum pvusb for my VDR System which uses an
> usb device for DVB-S :-)
You could also do PCI passthrough of your USB card to the domain..
> I also use a usb printer on my printer DomU.
>
> Also, i think it is interesting, why the kernel doesn't work at this point,
> the xen 4.0.2-rc1-pre version starts nowadays on this host - very strange
> behaviour.
That might be due to the fact that the drivers (2.6.`8.8) aren't up-to-date
on your new box. You can also find out more details if pass in the Xen hypervisor
command line "sync_console console_to_ring " and in the Linux command line:
"loglevel=8 debug initcall_debug"
That should show you why and exactly where it fails in the bootup. The thing
you are seeing isn't actually the failure, it occurs later on but the output
is buffered and it never reaches Xen hypervisor unless you use those command line
arguments I mentioned.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-12 22:19 ` Konrad Rzeszutek Wilk
@ 2010-11-12 23:20 ` Sander Eikelenboom
2010-11-15 16:47 ` Konrad Rzeszutek Wilk
2010-11-13 10:14 ` Neobiker
1 sibling, 1 reply; 17+ messages in thread
From: Sander Eikelenboom @ 2010-11-12 23:20 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: xen-devel, Neobiker
Friday, November 12, 2010, 11:19:53 PM, you wrote:
> On Thu, Nov 11, 2010 at 09:16:35AM -0800, Neobiker wrote:
>>
>> Hi Konrad,
>>
>> many folks need to use the Xenlinux Kernel due to missing features in pvops
>> kernel...
>> For me (neobiker), it's at a minimum pvusb for my VDR System which uses an
>> usb device for DVB-S :-)
> You could also do PCI passthrough of your USB card to the domain..
I'm doing that, and it works, but there are a few pitfalls:
- With onboard controllers it can sometimes be hard to tell which usb port ends up connected to which usb controller. Some motherboards seem to connect them up rather randomly,so you never know which one to passthrough, but it can differ per motherboard.
- You don't have that problem when you passthrough a dedicated pci / pci-e controller card per domain.
- With xhci (usb3) controllers you will most probably encounter problems, it hasn't matured enough yet (i'm back to usb2 again after trying for quite some time.)
- Found some real cool usb2 controllers with a moschip 9990 chip, these pci-e cards have 4 usb ports, but the bonus is, it has 4 seperate usb controllers.
That means every port has the full 480Mbps bandwidth, instead of having it shared for all port.Without that you can have only one video device per controller card, because that already saturates more than half the bandwidth most of the time.
- All usb2 controllers i have had seems to work fine when passed through even without a hardware iommu.
So apart from these pitfalls it now seems to work like a charm !
Another possibility could be usbip which is in the staging tree of the linux kernel.
--
Sander
>> I also use a usb printer on my printer DomU.
>>
>> Also, i think it is interesting, why the kernel doesn't work at this point,
>> the xen 4.0.2-rc1-pre version starts nowadays on this host - very strange
>> behaviour.
> That might be due to the fact that the drivers (2.6.`8.8) aren't up-to-date
> on your new box. You can also find out more details if pass in the Xen hypervisor
> command line "sync_console console_to_ring " and in the Linux command line:
> "loglevel=8 debug initcall_debug"
> That should show you why and exactly where it fails in the bootup. The thing
> you are seeing isn't actually the failure, it occurs later on but the output
> is buffered and it never reaches Xen hypervisor unless you use those command line
> arguments I mentioned.
--
Best regards,
Sander mailto:linux@eikelenboom.it
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-12 22:19 ` Konrad Rzeszutek Wilk
2010-11-12 23:20 ` Sander Eikelenboom
@ 2010-11-13 10:14 ` Neobiker
2010-11-15 16:49 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 17+ messages in thread
From: Neobiker @ 2010-11-13 10:14 UTC (permalink / raw)
To: xen-devel
Ok, i have been using the hypervisor sync parameters (see output), but didn't
set the kernel debuglevel higher.
I know about the pci passthrough (of course), but my usb ports are all
onboard and i have to connect the usb ports to different domains. So if i
connect the usb controller to vdr domu, i possibly will miss the other usb
ports for other domains... so pvusb works perfectly for my
usb-to-multi-domain scenario.
Are you interested in investigating the failure on the "old" kernel with
another debug log?
I personally think it would be better to concentrate all developper
capacitys in finishing the migration to the new pvops kernels and to
complete all missing features ... ;-)
Btw: Congratlations for the work done untill now !!
Xen may be back to stay as a virtualisation standard if kernel 2.6.38 will
be able to start as dom0 (as 2.6.37 will) and to be able to drive domUs
(missing in upcoming 2.6.37). I think that's really really (!) important for
XEN future. And: XEN 4.0.x must be as rock stable as 3.4.2 as soon as
possible... i personnally don't think about using 4.0.x for production
systems at this point...
regards
neobiker
http://www.neobiker.de/wiki
--
View this message in context: http://xen.1045712.n5.nabble.com/XEN-boot-hangs-at-ACPI-PCI-Root-Bridge-PCI0-0000-00-tp3259065p3263418.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-12 23:20 ` Sander Eikelenboom
@ 2010-11-15 16:47 ` Konrad Rzeszutek Wilk
2010-11-15 16:58 ` Sander Eikelenboom
0 siblings, 1 reply; 17+ messages in thread
From: Konrad Rzeszutek Wilk @ 2010-11-15 16:47 UTC (permalink / raw)
To: Sander Eikelenboom; +Cc: xen-devel, Neobiker
On Sat, Nov 13, 2010 at 12:20:58AM +0100, Sander Eikelenboom wrote:
> Friday, November 12, 2010, 11:19:53 PM, you wrote:
>
> > On Thu, Nov 11, 2010 at 09:16:35AM -0800, Neobiker wrote:
> >>
> >> Hi Konrad,
> >>
> >> many folks need to use the Xenlinux Kernel due to missing features in pvops
> >> kernel...
> >> For me (neobiker), it's at a minimum pvusb for my VDR System which uses an
> >> usb device for DVB-S :-)
>
> > You could also do PCI passthrough of your USB card to the domain..
>
> I'm doing that, and it works, but there are a few pitfalls:
> - With onboard controllers it can sometimes be hard to tell which usb port ends up connected to which usb controller. Some motherboards seem to connect them up rather randomly,so you never know which one to passthrough, but it can differ per motherboard.
Oh I forgot to mention. I've got the USB capture thing and I reproduced the problem you saw
(with page_alloc failing). The issue was that I forgot to enable these two kernel optins:
kernel.shmall = 134217728 kernel.shmmax = 134217728
in the sysctl.conf. Once that was set it worked fine. Haven't put the xHCI controller in box yet
thought.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-13 10:14 ` Neobiker
@ 2010-11-15 16:49 ` Konrad Rzeszutek Wilk
2010-11-16 20:09 ` Neobiker
0 siblings, 1 reply; 17+ messages in thread
From: Konrad Rzeszutek Wilk @ 2010-11-15 16:49 UTC (permalink / raw)
To: Neobiker; +Cc: xen-devel
> I know about the pci passthrough (of course), but my usb ports are all
> onboard and i have to connect the usb ports to different domains. So if i
> connect the usb controller to vdr domu, i possibly will miss the other usb
> ports for other domains... so pvusb works perfectly for my
> usb-to-multi-domain scenario.
Ok.
>
> Are you interested in investigating the failure on the "old" kernel with
> another debug log?
Not really.. which is why I was hinting for you to try the PVOPS and PCI pass-through.
> I personally think it would be better to concentrate all developper
> capacitys in finishing the migration to the new pvops kernels and to
> complete all missing features ... ;-)
>
> Btw: Congratlations for the work done untill now !!
Thank you.
>
> Xen may be back to stay as a virtualisation standard if kernel 2.6.38 will
> be able to start as dom0 (as 2.6.37 will) and to be able to drive domUs
> (missing in upcoming 2.6.37). I think that's really really (!) important for
> XEN future. And: XEN 4.0.x must be as rock stable as 3.4.2 as soon as
> possible... i personnally don't think about using 4.0.x for production
> systems at this point...
Uh, even 4.0.1? What are the issues you are worried about?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-15 16:47 ` Konrad Rzeszutek Wilk
@ 2010-11-15 16:58 ` Sander Eikelenboom
0 siblings, 0 replies; 17+ messages in thread
From: Sander Eikelenboom @ 2010-11-15 16:58 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: xen-devel
Hello Konrad,
Monday, November 15, 2010, 5:47:40 PM, you wrote:
> On Sat, Nov 13, 2010 at 12:20:58AM +0100, Sander Eikelenboom wrote:
>> Friday, November 12, 2010, 11:19:53 PM, you wrote:
>>
>> > On Thu, Nov 11, 2010 at 09:16:35AM -0800, Neobiker wrote:
>> >>
>> >> Hi Konrad,
>> >>
>> >> many folks need to use the Xenlinux Kernel due to missing features in pvops
>> >> kernel...
>> >> For me (neobiker), it's at a minimum pvusb for my VDR System which uses an
>> >> usb device for DVB-S :-)
>>
>> > You could also do PCI passthrough of your USB card to the domain..
>>
>> I'm doing that, and it works, but there are a few pitfalls:
>> - With onboard controllers it can sometimes be hard to tell which usb port ends up connected to which usb controller. Some motherboards seem to connect them up rather randomly,so you never know which one to passthrough, but it can differ per motherboard.
> Oh I forgot to mention. I've got the USB capture thing and I reproduced the problem you saw
> (with page_alloc failing). The issue was that I forgot to enable these two kernel optins:
> kernel.shmall = 134217728 kernel.shmmax = 134217728
> in the sysctl.conf. Once that was set it worked fine. Haven't put the xHCI controller in box yet
> thought.
With just buying some usb2 controllers instead of the usb3 ones, seemed to have "fixed" my problems for the time being. :-)
There were also some more problems with XHCI, so it just hasn't matured enough.
It's only a pity (E/U/O)hci controllers under linux don't support MSI interrupts, Greg KH seems to have reject a patch for that.
But apart from that it works fine ! (with the 2.6.37-rc1 kernel as domU but i don't use NFS) :-)
So apart from some other things i'm quite happy :-)
--
Sander
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-15 16:49 ` Konrad Rzeszutek Wilk
@ 2010-11-16 20:09 ` Neobiker
2010-11-17 16:48 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 17+ messages in thread
From: Neobiker @ 2010-11-16 20:09 UTC (permalink / raw)
To: xen-devel
Konrad Rzeszutek Wilk wrote:
>
>
>> Xen may be back to stay as a virtualisation standard if kernel 2.6.38
>> will
>> be able to start as dom0 (as 2.6.37 will) and to be able to drive domUs
>> (missing in upcoming 2.6.37). I think that's really really (!) important
>> for
>> XEN future. And: XEN 4.0.x must be as rock stable as 3.4.2 as soon as
>> possible... i personnally don't think about using 4.0.x for production
>> systems at this point...
>
> Uh, even 4.0.1? What are the issues you are worried about?
>
>
I'm worried about stability, changes in behaviour, changes in kernel /
parameters, problems with compiling some orig xen kernel, problems running
2.6.18 kernel like above, dependencies like pvops version .32 for > 4.0.1,
.31 for < 4.0.1, bugs in 4.0.0, less bugs in 4.0.1, missing features like
pvusb, windows in vhd didn't like the GPLPV drivers (blue screen), signed
Citrix PV drivers only work with version 5.5, not 5.6, pvops kernel works on
my hardware with debian pvops xen 4.0.1 kernel, but xen pvops kernel
compiled according to wiki fc13 page has errors with agpart loading and so
on..... so i'm waiting for 4.0.3 ;-)
regards from a xen enthusiast using original xen on debian
neobiker
--
View this message in context: http://xen.1045712.n5.nabble.com/XEN-boot-hangs-at-ACPI-PCI-Root-Bridge-PCI0-0000-00-tp3259065p3267936.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-16 20:09 ` Neobiker
@ 2010-11-17 16:48 ` Konrad Rzeszutek Wilk
2010-11-26 19:45 ` Neobiker
0 siblings, 1 reply; 17+ messages in thread
From: Konrad Rzeszutek Wilk @ 2010-11-17 16:48 UTC (permalink / raw)
To: Neobiker; +Cc: xen-devel
On Tue, Nov 16, 2010 at 12:09:56PM -0800, Neobiker wrote:
>
>
> Konrad Rzeszutek Wilk wrote:
> >
> >
> >> Xen may be back to stay as a virtualisation standard if kernel 2.6.38
> >> will
> >> be able to start as dom0 (as 2.6.37 will) and to be able to drive domUs
> >> (missing in upcoming 2.6.37). I think that's really really (!) important
> >> for
> >> XEN future. And: XEN 4.0.x must be as rock stable as 3.4.2 as soon as
> >> possible... i personnally don't think about using 4.0.x for production
> >> systems at this point...
> >
> > Uh, even 4.0.1? What are the issues you are worried about?
> >
> >
> I'm worried about stability, changes in behaviour, changes in kernel /
> parameters, problems with compiling some orig xen kernel, problems running
All of those, except stability, are issues you are going to encounter with
a new kernel...
Can you be more specific about the stability? Have you seen it crash?
> 2.6.18 kernel like above, dependencies like pvops version .32 for > 4.0.1,
> .31 for < 4.0.1, bugs in 4.0.0, less bugs in 4.0.1, missing features like
PVUSB.. well we would love if somebody volunteered to do the driver.
> pvusb, windows in vhd didn't like the GPLPV drivers (blue screen), signed
Uhh, no idea. I am actually using the Novell GPL drivers in Windows 2000
and they seem to work fine.
> Citrix PV drivers only work with version 5.5, not 5.6, pvops kernel works on
> my hardware with debian pvops xen 4.0.1 kernel, but xen pvops kernel
> compiled according to wiki fc13 page has errors with agpart loading and so
> on..... so i'm waiting for 4.0.3 ;-)
Hm, the agpart loading I thought was fixed. When did you observe this behavior?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-17 16:48 ` Konrad Rzeszutek Wilk
@ 2010-11-26 19:45 ` Neobiker
2010-11-26 19:58 ` Neobiker
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Neobiker @ 2010-11-26 19:45 UTC (permalink / raw)
To: xen-devel
Hi,
most kernels (32-bit) except the squeeze 64-bit kernel produce the following
error:
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel Q35 Chipset
agpgart-intel 0000:00:00.0: can't get memory for scratch page
agpgart-intel 0000:00:00.0: agp_backend_initialize() failed
agpgart-intel: probe of 0000:00:00.0 failed with error -12
[drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
Above ist actually seen FC14 / XEN 4.0.1 with latest kernel from MA Young:
2.6.32.26-174.xendom0.fc12.i686.PAE
regards neobiker
--
View this message in context: http://xen.1045712.n5.nabble.com/XEN-boot-hangs-at-ACPI-PCI-Root-Bridge-PCI0-0000-00-tp3259065p3281750.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-26 19:45 ` Neobiker
@ 2010-11-26 19:58 ` Neobiker
2010-11-29 17:07 ` Konrad Rzeszutek Wilk
2011-03-12 18:54 ` agpgart-intel 0000:00:00.0: can't get memory for scratch page dnyaneshgate
2 siblings, 0 replies; 17+ messages in thread
From: Neobiker @ 2010-11-26 19:58 UTC (permalink / raw)
To: xen-devel
Once again, same on Debian Squeeze 64-Bit gives:
root@squeeze:/home/neobiker# dmesg | grep agpgart
[ 0.137360] Linux agpgart interface v0.103
[ 0.137458] agpgart-intel 0000:00:00.0: Intel Q35 Chipset
[ 0.139200] agpgart-intel 0000:00:00.0: detected 6140K stolen memory
[ 0.147234] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000
root@squeeze:/home/neobiker#
root@squeeze:/home/neobiker# uname -r
2.6.32-5-xen-amd64
regards neobiker
--
View this message in context: http://xen.1045712.n5.nabble.com/XEN-boot-hangs-at-ACPI-PCI-Root-Bridge-PCI0-0000-00-tp3259065p3281758.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
2010-11-26 19:45 ` Neobiker
2010-11-26 19:58 ` Neobiker
@ 2010-11-29 17:07 ` Konrad Rzeszutek Wilk
2011-03-12 18:54 ` agpgart-intel 0000:00:00.0: can't get memory for scratch page dnyaneshgate
2 siblings, 0 replies; 17+ messages in thread
From: Konrad Rzeszutek Wilk @ 2010-11-29 17:07 UTC (permalink / raw)
To: Neobiker; +Cc: xen-devel
On Fri, Nov 26, 2010 at 11:45:56AM -0800, Neobiker wrote:
>
> Hi,
> most kernels (32-bit) except the squeeze 64-bit kernel produce the following
> error:
>
> Linux agpgart interface v0.103
> agpgart-intel 0000:00:00.0: Intel Q35 Chipset
> agpgart-intel 0000:00:00.0: can't get memory for scratch page
That looks oddly familiar, but I can't remember where I saw it.
> agpgart-intel 0000:00:00.0: agp_backend_initialize() failed
> agpgart-intel: probe of 0000:00:00.0 failed with error -12
> [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
>
> Above ist actually seen FC14 / XEN 4.0.1 with latest kernel from MA Young:
> 2.6.32.26-174.xendom0.fc12.i686.PAE
You are comparing oranges and bananses here. The MA Young vs Squeeze (unless
you are using the IanC set of kernels) have a different set of patches for the GART controller.
Wht happens if you run a 2.6.32.26-174.xendom0.fc12.x86_64 kernel?
^ permalink raw reply [flat|nested] 17+ messages in thread
* agpgart-intel 0000:00:00.0: can't get memory for scratch page
2010-11-26 19:45 ` Neobiker
2010-11-26 19:58 ` Neobiker
2010-11-29 17:07 ` Konrad Rzeszutek Wilk
@ 2011-03-12 18:54 ` dnyaneshgate
2011-03-14 14:44 ` Konrad Rzeszutek Wilk
2 siblings, 1 reply; 17+ messages in thread
From: dnyaneshgate @ 2011-03-12 18:54 UTC (permalink / raw)
To: xen-devel
Hi,
i have installed same kernel that you had and i also get the same error.
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel 945G Chipset
agpgart-intel 0000:00:00.0: can't get memory for scratch page
agpgart-intel 0000:00:00.0: agp_backend_initialize() failed
agpgart-intel: probe of 0000:00:00.0 failed with error -12
[drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
i am trying to google for it, but didn't find anything.
did you got any solution, if yes please help me .
How do i fix it.
Thanks
--
View this message in context: http://xen.1045712.n5.nabble.com/XEN-boot-hangs-at-ACPI-PCI-Root-Bridge-PCI0-0000-00-tp3259065p3506258.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: agpgart-intel 0000:00:00.0: can't get memory for scratch page
2011-03-12 18:54 ` agpgart-intel 0000:00:00.0: can't get memory for scratch page dnyaneshgate
@ 2011-03-14 14:44 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 17+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-03-14 14:44 UTC (permalink / raw)
To: dnyaneshgate; +Cc: xen-devel
On Sat, Mar 12, 2011 at 10:54:12AM -0800, dnyaneshgate wrote:
> Hi,
> i have installed same kernel that you had and i also get the same error.
>
> Linux agpgart interface v0.103
> agpgart-intel 0000:00:00.0: Intel 945G Chipset
> agpgart-intel 0000:00:00.0: can't get memory for scratch page
> agpgart-intel 0000:00:00.0: agp_backend_initialize() failed
> agpgart-intel: probe of 0000:00:00.0 failed with error -12
> [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
>
> i am trying to google for it, but didn't find anything.
> did you got any solution, if yes please help me .
The fix is in for-2.6.32/bug-fixes which I haven't asked Jeremy yet to pull.
You can pull the changes yourself. You need these two fixes:
xen/setup: Inhibit resource API from using System RAM E820 gaps as PCI mem gaps
(commit 96587057018b3ac0b11bf34b791aaadfc403fc80)
xen/e820: Don't mark balloon memory as E820_UNUSABLE when running as guest
(commit a8462f56975f672ebd5acad179339d8177840e10)
^ permalink raw reply [flat|nested] 17+ messages in thread
* XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00)
@ 2010-10-26 17:50 Neobiker
0 siblings, 0 replies; 17+ messages in thread
From: Neobiker @ 2010-10-26 17:50 UTC (permalink / raw)
To: xen-devel
Hi,
i have a VT-d System (FSC Celsius W360 w C2D), which runs perfect with pvops
kernel and XEN 4.0.1 (Debian Squeeze 64Bit), but can’t start Xenlinux
2.6.18.8.
Booting stops at: "ACPI: PCI Root Bridge [PCI0] (0000:00)" identically on
XEN 4.0.1 64-Bit and XEN 3.4.2 Hypervisor (which was taken from my PROD
System which has a uptime from 150 days actually with PVUSB and
PCIpassthrough to different Domains – rock stable!!). Also, VT-d is working
on that system (PCIpassthrough to Windows 7 HVM), but VGA won’t (Intel IGD
and Q35 Express Chipset). Xenserver V5.5 and 5.6 is also running perfectly…
Here’s my Bootlog, any hint’s or suggestions?
Regards
Jens Friedrich aka Neobiker www.neobiker.de
--SNIPP----
__ __ _ _ ___ _
\ \/ /___ _ __ | || | / _ \ / |
\ // _ \ '_ \ | || |_| | | || |
/ \ __/ | | | |__ _| |_| || |
/_/\_\___|_| |_| |_|(_)___(_)_|
(XEN) Xen version 4.0.1 (root@friedrichnet.de) (gcc version 4.3.2 (Debian
4.3.2-1.1) ) Mon Oct 25 22:17:13 CEST 2010
(XEN) Latest ChangeSet: Wed Aug 25 09:22:42 2010 +0100 21324:b536ebfba183
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 1.98+20100804-4
(XEN) Command line: dom0_mem=384M com1=115200,8n1 console=com1,vga
sync_console sync_to_ring loglvl=all guestloglvl=all
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 3 MBR signatures
(XEN) Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009c800 (usable)
(XEN) 000000000009c800 - 00000000000a0000 (reserved)
(XEN) 00000000000ce000 - 00000000000d0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007d4d0000 (usable)
(XEN) 000000007d4d0000 - 000000007d4d8000 (ACPI data)
(XEN) 000000007d4d8000 - 000000007d4db000 (ACPI NVS)
(XEN) 000000007d4db000 - 0000000080000000 (reserved)
(XEN) 00000000f8000000 - 00000000fc000000 (reserved)
(XEN) 00000000fec00000 - 00000000fec10000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffb00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2004MB (2052528kB)
(XEN) ACPI: RSDP 000F7320, 0014 (r0 PTLTD )
(XEN) ACPI: RSDT 7D4D2AEE, 005C (r1 FSC PC 60000 LTP 0)
(XEN) ACPI: FACP 7D4D78B5, 0074 (r1 FSC 60000 F4240)
(XEN) ACPI: DSDT 7D4D2B4A, 4D6B (r1 FSC D2587/A1 60000 MSFT 3000001)
(XEN) ACPI: FACS 7D4DAFC0, 0040
(XEN) ACPI: TCPA 7D4D7929, 0032 (r1 Phoeni x 60000 TL 0)
(XEN) ACPI: DMAR 7D4D795B, 00F8 (r1 Intel OEMDMAR 60000 LOHR 1)
(XEN) ACPI: SSDT 7D4D7A53, 007A (r1 FSC CST_CPU0 60000 CSF 1)
(XEN) ACPI: SSDT 7D4D7ACD, 007A (r1 FSC CST_CPU1 60000 CSF 1)
(XEN) ACPI: SSDT 7D4D7B47, 00B6 (r1 FSC PST_CPU0 60000 CSF 1)
(XEN) ACPI: SSDT 7D4D7BFD, 00B6 (r1 FSC PST_CPU1 60000 CSF 1)
(XEN) ACPI: SPCR 7D4D7CB3, 0050 (r1 PTLTD $UCRTBL$ 60000 PTL 1)
(XEN) ACPI: SLIC 7D4D7D03, 0176 (r1 FSC PC 60000 LTP 0)
(XEN) ACPI: MCFG 7D4D7E79, 003C (r1 PTLTD MCFG 60000 LTP 0)
(XEN) ACPI: HPET 7D4D7EB5, 0038 (r1 PTLTD HPETTBL 60000 LTP 1)
(XEN) ACPI: APIC 7D4D7EED, 0068 (r1 PTLTD APIC 60000 LTP
0)
(XEN) ACPI: BOOT 7D4D7F55, 0028 (r1 PTLTD $SBFTBL$ 60000 LTP 1)
(XEN) ACPI: ASF! 7D4D7F7D, 0083 (r16 CETP CETP 60000 PTL 1)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000007d4d0000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f7420
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[1004,0], pm1x_evt[1000,0]
(XEN) ACPI: wakeup_vec[7d4dafcc], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:7 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) Processor #1 7:7 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 3
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2992.566 MHz processor.
(XEN) Initing memory sharing.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) xsave_init: cpu0: cntxt_max_size: 0x240 and states: 00000000:00000003
(XEN) xsave_init: using cntxt_size: 0x240 and states: 00000000:00000003
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d Snoop Control not supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation not supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) xsave_init: cpu1: cntxt_max_size: 0x240 and states: 00000000:00000003
(XEN) Total of 2 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) checking TSC synchronization across 2 CPUs: passed.
(XEN) Platform timer is 14.318MHz HPET
ÿ(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 2 CPUs
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0x200000 -> 0x5ec2ac
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 000000007a800000->000000007b000000 (96256 pages to be
allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff805ec2ac
(XEN) Init. ramdisk: ffffffff805ed000->ffffffff805ed000
(XEN) Phys-Mach map: ffffffff805ed000->ffffffff806ad000
(XEN) Start info: ffffffff806ad000->ffffffff806ad4b4
(XEN) Page tables: ffffffff806ae000->ffffffff806b5000
(XEN) Boot stack: ffffffff806b5000->ffffffff806b6000
(XEN) TOTAL: ffffffff80000000->ffffffff80800000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 2 VCPUs
(XEN) [VT-D]iommu.c:821: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:824: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:799: DMAR:[DMA Write] Request device [00:02.0] fault
addr ffffff000, iommu reg = ffff82c3fff56000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) print_vtd_entries: iommu = ffff83007d073790 bdf = 0:2.0 gmfn = ffffff
(XEN) root_entry = ffff83007d273000
(XEN) root_entry[0] = 633da001
(XEN) context = ffff8300633da000
(XEN) context[10] = 1_63be0001
(XEN) l3 = ffff830063be0000
(XEN) l3_index = 3f
(XEN) l3[3f] = 0
(XEN) l3[3f] not present
(XEN) Scrubbing Free RAM: ...............done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
Xen)
(XEN) Freed 176kB init memory.
[ 0.000000] Bootdata ok (command line is root=/dev/sdb8 ro console=xvc0
console=ttyS0 earlyprintk=xen)
[ 0.000000] Linux version 2.6.18.8-xen (root@xen4) (gcc version 4.3.2
(Debian 4.3.2-1.1) ) #3 SMP Sun Oct 24 19:30:10 CEST 2010
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 0000000018800000 (usable)
kernel direct mapping tables up to 18800000 @ 6b5000-77b000
[ 4.458412] DMI present.
[ 4.465717] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 4.471370] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 4.477160] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 4.483043] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 4.488928] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 4.495164] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI
0-23
[ 4.501997] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[ 4.508486] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 4.515067] Setting APIC routing to xen
[ 4.518871] Using ACPI (MADT) for SMP configuration information
[ 4.527089] Allocating PCI resources starting at 88000000 (gap:
80000000:78000000)
[ 4.534500] Built 1 zonelists. Total pages: 97575
[ 4.539220] Kernel command line: root=/dev/sdb8 ro console=xvc0
console=ttyS0 earlyprintk=xen
[ 4.548075] Initializing CPU#0
[ 4.551053] PID hash table entries: 2048 (order: 11, 16384 bytes)
[ 4.557026] Xen reported: 2992.566 MHz processor.
[ 4.561679] disabling early console
[ 0.000000] Bootdata ok (command line is root=/dev/sdb8 ro console=xvc0
console=ttyS0 earlyprintk=xen)
[ 0.000000] Linux version 2.6.18.8-xen (root@xen4) (gcc version 4.3.2
(Debian 4.3.2-1.1) ) #3 SMP Sun Oct 24 19:30:10 CEST 2010
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 0000000018800000 (usable)
[ 4.458412] DMI present.
[ 4.465717] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 4.471370] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 4.477160] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 4.483043] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 4.488928] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 4.495164] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI
0-23
[ 4.501997] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
[ 4.508486] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 4.515067] Setting APIC routing to xen
[ 4.518871] Using ACPI (MADT) for SMP configuration information
[ 4.527089] Allocating PCI resources starting at 88000000 (gap:
80000000:78000000)
[ 4.534500] Built 1 zonelists. Total pages: 97575
[ 4.539220] Kernel command line: root=/dev/sdb8 ro console=xvc0
console=ttyS0 earlyprintk=xen
[ 4.548075] Initializing CPU#0
[ 4.551053] PID hash table entries: 2048 (order: 11, 16384 bytes)
[ 4.557026] Xen reported: 2992.566 MHz processor.
[ 4.561679] disabling early console
[ 4.568227] Console: colour VGA+ 80x25
[ 4.703351] Dentry cache hash table entries: 65536 (order: 7, 524288
bytes)
[ 4.710290] Inode-cache hash table entries: 32768 (order: 6, 262144
bytes)
[ 4.718570] Software IO TLB enabled:
[ 4.718571] Aperture: 2 megabytes
[ 4.718571] Kernel range: ffff88000173e000 - ffff88000193e000
[ 4.718572] Address size: 22 bits
[ 4.734944] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 4.743138] Memory: 378632k/401408k available (2154k kernel code, 14372k
reserved, 969k data, 192k init)
[ 4.820431] Calibrating delay using timer specific routine.. 5987.26
BogoMIPS (lpj=11974527)
[ 4.828691] Security Framework v1.0.0 initialized
[ 4.833348] Capability LSM initialized
[ 4.837073] Mount-cache hash table entries: 256
[ 4.841659] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 4.846239] CPU: L2 cache: 6144K
[ 4.849455] SMP alternatives: switching to UP code
[ 4.854277] ACPI: Core revision 20060707
[ 4.922798] SMP alternatives: switching to SMP code
[ 4.927557] Brought up 2 CPUs
[ 4.927541] Initializing CPU#1
[ 4.927562] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 4.927563] CPU: L2 cache: 6144K
[ 5.014445] migration_cost=9
[ 5.017588] NET: Registered protocol family 16
[ 5.021929] ACPI: bus type pci registered
[ 5.025847] PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 -
3
[ 5.032663] PCI: MCFG area at f8000000 reserved in E820
[ 5.038038] PCI: Using MMCONFIG at f8000000 - f83fffff
[ 5.044971] ACPI: Interpreter enabled
[ 5.048452] ACPI: Using IOAPIC for interrupt routing
[ 5.053692] ACPI: PCI Root Bridge [PCI0] (0000:00)
--
View this message in context: http://xen.1045712.n5.nabble.com/XEN-boot-hangs-at-ACPI-PCI-Root-Bridge-PCI0-0000-00-tp3237518p3237518.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-03-14 14:44 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-26 17:11 XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00) Jens Friedrich
2010-11-11 16:18 ` Konrad Rzeszutek Wilk
2010-11-11 17:16 ` Neobiker
2010-11-12 22:19 ` Konrad Rzeszutek Wilk
2010-11-12 23:20 ` Sander Eikelenboom
2010-11-15 16:47 ` Konrad Rzeszutek Wilk
2010-11-15 16:58 ` Sander Eikelenboom
2010-11-13 10:14 ` Neobiker
2010-11-15 16:49 ` Konrad Rzeszutek Wilk
2010-11-16 20:09 ` Neobiker
2010-11-17 16:48 ` Konrad Rzeszutek Wilk
2010-11-26 19:45 ` Neobiker
2010-11-26 19:58 ` Neobiker
2010-11-29 17:07 ` Konrad Rzeszutek Wilk
2011-03-12 18:54 ` agpgart-intel 0000:00:00.0: can't get memory for scratch page dnyaneshgate
2011-03-14 14:44 ` Konrad Rzeszutek Wilk
2010-10-26 17:50 XEN boot hangs at ACPI: PCI Root Bridge [PCI0] (0000:00) Neobiker
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.