search for: last_map_addr

Displaying 9 results from an estimated 9 matches for "last_map_addr".

2013 Jun 17
1
Kernel panic in pin_pagetable_pfn
...00000] Xen: 0000000008cc2000 - 0000000009bc5000 (reserved) [ 0.000000] Xen: 0000000009bc5000 - 00000001e0000000 (usable) [ 0.000000] last_pfn = 0x1e0000 max_arch_pfn = 0x3ffffffff [ 0.000000] last_pfn = 0x100000 max_arch_pfn = 0x3ffffffff [ 0.000000] init_memory_mapping [ 0.000000] last_map_addr: 100000000 end: 100000000 [ 0.000000] init_memory_mapping [ 0.000000] last_map_addr: 1e0000000 end: 1e0000000 [ 0.000000] RAMDISK: 009b9000 - 08cc2000 [ 0.000000] DMI not present or invalid. [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at 0000000000000000-0000...
2008 Nov 29
24
pv_ops dom0 testing
I am trying to get a pv_ops dom0 working for testing, but I am running into an elf_init error: (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_init: not an ELF binary Full output attached. >From what I have read on the mailing lists, it seems that it is usually a problem with either grub or a corrupt dom0 kernel. Attached is my kernel config (2.6.28-rc6-tip). I followed the instructions on:
2009 Mar 04
1
pv_ops kernel 2.6.29-rc6 boot failure
...000fed00400 (reserved) Xen: 00000000fed20000 - 00000000feda0000 (reserved) Xen: 00000000fee00000 - 00000000fef00000 (reserved) Xen: 00000000ffb00000 - 0000000100000000 (reserved) DMI 2.5 present. last_pfn = 0xcfdff max_arch_pfn = 0x100000000 init_memory_mapping: 0000000000000000-00000000cfdff000 last_map_addr: cfdff000 end: cfdff000 ACPI: RSDP 000FEC00, 0024 (r2 DELL ) ACPI: XSDT 000FC5B3, 008C (r1 DELL B9K 15 ASL 61) ACPI: FACP 000FC6E3, 00F4 (r3 DELL B9K 15 ASL 61) ACPI Warning (tbfadt-0568): 32/64X length mismatch in Gpe0Block: 128/64 [20081204] FADT: X_PM1a_E...
2009 Aug 01
7
dom0 unable to launch domU
Hi, I have a problem with a dom0 which is unable to launch my domU : all my dom0 are Debian Lenny amd64 with Debian kernel 2.6.26-2-xen-amd64 and xen-hypervisor-3.2-1-amd64. Then all domU (PV) are Debian Lenny amd64 too, with vanilla kernel 2.6.29.6. So, this new dom0 can''t launch any domU which are working on an other dom0. Software is same on both dom0, and hardware is near the
2009 Jan 10
51
Xen with dom0 pvops on ultra-recent "git tip" kernel on x86_64
...0000000006306000 (usable) Xen: 0000000007ff0000 - 0000000008000000 (ACPI data) Xen: 00000000fffbd000 - 0000000100000000 (reserved) console [xenboot0] enabled PAT support disabled. DMI 2.4 present. last_pfn = 0x6306 max_arch_pfn = 0x100000000 init_memory_mapping: 0000000000000000-0000000006306000 last_map_addr: 6306000 end: 6306000 ACPI: RSDP 000FBC80, 0014 (r0 QEMU ) ACPI: RSDT 07FF0000, 002C (r1 QEMU QEMURSDT 1 QEMU 1) ACPI: FACP 07FF002C, 0074 (r1 QEMU QEMUFACP 1 QEMU 1) ACPI: DSDT 07FF0100, 24A4 (r1 BXPC BXDSDT 1 INTL 20061109) ACPI: FACS 07FF00C0, 0040 ACP...
2009 Feb 27
8
Kernel build failure
Did a ''git pull'' a few minutes ago and tried to rebuild my kernel and was given this error: make CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm -> include/asm-x86 CALL scripts/checksyscalls.sh CHK include/linux/compile.h CC drivers/acpi/acpica/hwsleep.o drivers/acpi/acpica/hwsleep.c: In function
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all