linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.6.25-rc1 xen pvops regression
@ 2008-02-12 23:54 Jody Belka
  2008-02-13 11:59 ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 46+ messages in thread
From: Jody Belka @ 2008-02-12 23:54 UTC (permalink / raw)
  To: linux-kernel, Ingo Molnar, Thomas Gleixner, Ian Campbell
  Cc: H. Peter Anvin, Eric W. Biederman, Andi Kleen, Mika Penttila,
	Jeremy Fitzhardinge

Hi all,

I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
Unfortunately, I didn't get very far very fast, as the domain just crashed
immediately upon booting, without any direct feedback (I did have messages
on the xen message buffer, which helped). This even with earlyprintk turned on.

After a long, arduous journey, I managed to track this down to the following:

----------
commit	551889a6e2a24a9c06fd453ea03b57b7746ffdc0

x86: construct 32-bit boot time page tables in native format.

Specifically the boot time page tables in a CONFIG_X86_PAE=y enabled
kernel are in PAE format.

early_ioremap is updated to use the standard page table accessors.

Clear any mappings beyond max_low_pfn from the boot page tables in
native_pagetable_setup_start because the initial mappings can extend
beyond the range of physical memory and into the vmalloc area.

Derived from patches by Eric Biederman and H. Peter Anvin.

[ jeremy@goop.org: PAE swapper_pg_dir needs to be page-sized fix ]
----------

However, to make life more interesting, just reverting this isn't quite
enough to get us to the promised land. If we try, we find that although
we do now start booting, we crash again a short way into the process.

In a different manner though. Specifically, in early_ioremap_clear.
Reverting the above commit /except/ for the changes to arch/x86/mm/ioremap.c
gets everything working again.

Well, except that we can't shutdown/reboot properly, but I've sent a patch
for that in another email.


I'm afraid i've no idea what needs to be done to get the change to work
with xen, but i'm willing to try out any patches people come up with.
Please cc me on any replies, as i'm not subscribed, thanks.


J
-- 
Jody Belka
knew (at) pimb (dot) org

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-12 23:54 2.6.25-rc1 xen pvops regression Jody Belka
@ 2008-02-13 11:59 ` Jeremy Fitzhardinge
  2008-02-13 12:13   ` Jody Belka
                     ` (2 more replies)
  0 siblings, 3 replies; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-13 11:59 UTC (permalink / raw)
  To: Jody Belka
  Cc: linux-kernel, Ingo Molnar, Thomas Gleixner, Ian Campbell,
	H. Peter Anvin, Eric W. Biederman, Andi Kleen, Mika Penttila

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

Jody Belka wrote:
> Hi all,
>
> I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
> Unfortunately, I didn't get very far very fast, as the domain just crashed
> immediately upon booting, without any direct feedback (I did have messages
> on the xen message buffer, which helped). This even with earlyprintk turned on.
>
> After a long, arduous journey, I managed to track this down to the following:
>
> ----------
> commit	551889a6e2a24a9c06fd453ea03b57b7746ffdc0
>
> x86: construct 32-bit boot time page tables in native format.
>
> Specifically the boot time page tables in a CONFIG_X86_PAE=y enabled
> kernel are in PAE format.
>
> early_ioremap is updated to use the standard page table accessors.
>
> Clear any mappings beyond max_low_pfn from the boot page tables in
> native_pagetable_setup_start because the initial mappings can extend
> beyond the range of physical memory and into the vmalloc area.
>
> Derived from patches by Eric Biederman and H. Peter Anvin.
>
> [ jeremy@goop.org: PAE swapper_pg_dir needs to be page-sized fix ]
> ----------
>
> However, to make life more interesting, just reverting this isn't quite
> enough to get us to the promised land. If we try, we find that although
> we do now start booting, we crash again a short way into the process.
>
> In a different manner though. Specifically, in early_ioremap_clear.
> Reverting the above commit /except/ for the changes to arch/x86/mm/ioremap.c
> gets everything working again.
>
> Well, except that we can't shutdown/reboot properly, but I've sent a patch
> for that in another email.
>
>
> I'm afraid i've no idea what needs to be done to get the change to work
> with xen, but i'm willing to try out any patches people come up with.
> Please cc me on any replies, as i'm not subscribed, thanks.

Hi,

Although I'm on vacation, I happened to download a recent copy of 
x86.git and found that it crashes early.  Here's a couple of patches to 
apply; I don't know if they apply to current git, but I hope it helps.

    J

[-- Attachment #2: x86-fix-early_ioremap.patch --]
[-- Type: text/x-patch, Size: 981 bytes --]

Subject: x86/early_ioremap: don't assume we're using swapper_pg_dir

At the early stages of boot, before the kernel pagetable has been
fully initialized, a Xen kernel will still be running off the
Xen-provided pagetables rather than swapper_pg_dir[].  Therefore,
readback cr3 to determine the base of the pagetable rather than
assuming swapper_pg_dir[].

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>

---
 arch/x86/mm/ioremap.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

===================================================================
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -265,7 +265,9 @@
 
 static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
 {
-	pgd_t *pgd = &swapper_pg_dir[pgd_index(addr)];
+	/* Don't assume we're using swapper_pg_dir at this point */
+	pgd_t *base = __va(read_cr3());
+	pgd_t *pgd = &base[pgd_index(addr)];
 	pud_t *pud = pud_offset(pgd, addr);
 	pmd_t *pmd = pmd_offset(pud, addr);
 

[-- Attachment #3: xen-unpin-init_pt.patch --]
[-- Type: text/x-patch, Size: 799 bytes --]

Subject: xen: unpin initial Xen pagetable once we're finished with it

Unpin the Xen-provided pagetable once we've finished with it, so it
doesn't cause stray references which cause later swapper_pg_dir
pagetable updates to fail.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>

---
 arch/x86/xen/enlighten.c |    4 ++++
 1 file changed, 4 insertions(+)

===================================================================
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -798,6 +798,10 @@
 	 * added to the table can be prepared properly for Xen.
 	 */
 	xen_write_cr3(__pa(base));
+
+	/* Unpin initial Xen pagetable */
+	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE,
+			  PFN_DOWN(__pa(xen_start_info->pt_base)));
 }
 
 static __init void xen_pagetable_setup_done(pgd_t *base)

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-13 11:59 ` Jeremy Fitzhardinge
@ 2008-02-13 12:13   ` Jody Belka
  2008-02-13 12:23   ` Ingo Molnar
  2008-02-14  2:27   ` Joel Becker
  2 siblings, 0 replies; 46+ messages in thread
From: Jody Belka @ 2008-02-13 12:13 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: linux-kernel, Ingo Molnar, Thomas Gleixner, Ian Campbell,
	H. Peter Anvin, Eric W. Biederman, Andi Kleen, Mika Penttila,
	Ian Campbell


On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
> Hi,
> 
> Although I'm on vacation, I happened to download a recent copy of 
> x86.git and found that it crashes early.  Here's a couple of patches to 
> apply; I don't know if they apply to current git, but I hope it helps.

> Subject: x86/early_ioremap: don't assume we're using swapper_pg_dir
> Subject: xen: unpin initial Xen pagetable once we're finished with it

Applying both of those to current git resulte in booting working again :)
Just leaves the halt/reboot issue that I posted a patch for in another thread.

Tested-by: Jody Belka <knew-linux@pimb.org>


J
-- 
Jody Belka
knew (at) pimb (dot) org

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-13 11:59 ` Jeremy Fitzhardinge
  2008-02-13 12:13   ` Jody Belka
@ 2008-02-13 12:23   ` Ingo Molnar
  2008-02-14  2:27   ` Joel Becker
  2 siblings, 0 replies; 46+ messages in thread
From: Ingo Molnar @ 2008-02-13 12:23 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Jody Belka, linux-kernel, Thomas Gleixner, Ian Campbell,
	H. Peter Anvin, Eric W. Biederman, Andi Kleen, Mika Penttila


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Although I'm on vacation, I happened to download a recent copy of 
> x86.git and found that it crashes early.  Here's a couple of patches 
> to apply; I don't know if they apply to current git, but I hope it 
> helps.

thanks Jeremy, applied.

	Ingo

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-13 11:59 ` Jeremy Fitzhardinge
  2008-02-13 12:13   ` Jody Belka
  2008-02-13 12:23   ` Ingo Molnar
@ 2008-02-14  2:27   ` Joel Becker
  2008-02-14  7:50     ` Jeremy Fitzhardinge
  2 siblings, 1 reply; 46+ messages in thread
From: Joel Becker @ 2008-02-14  2:27 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Ian Campbell, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
>> I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
>> Unfortunately, I didn't get very far very fast, as the domain just crashed
>> immediately upon booting, without any direct feedback (I did have messages
>> on the xen message buffer, which helped). This even with earlyprintk turned on.
>>
>> After a long, arduous journey, I managed to track this down to the following:
>>
>> ----------
>> commit	551889a6e2a24a9c06fd453ea03b57b7746ffdc0

	I'm seeing the same problem, with no messages at all from xen
other than "domain crashed, restart disabled" in xend.log.  I got a
different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
(i386 boot: replace boot_io    remap with enhanced bt_ioremap - enhance
bt_ioremap).  I started from yesterday's
96b5a46e2a72dc1829370c87053e0cd558d58bc0 (WMI: initialize
wmi_blocks.list even if ACPI is disabled) and a known good
9b73e76f3cf63379dcf45fcd4f112f5812418d0a (Merge
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6).

> Although I'm on vacation, I happened to download a recent copy of  
> x86.git and found that it crashes early.  Here's a couple of patches to  
> apply; I don't know if they apply to current git, but I hope it helps.

> Subject: x86/early_ioremap: don't assume we're using swapper_pg_dir
> Subject: xen: unpin initial Xen pagetable once we're finished with it

	After my bisect was done, I re-pulled from Linus and discovered
these patches.  Searching for these emails, they certainly sound like my
problem.  But the kernel does not boot, commit
10270d4838bdc493781f5a1cf2e90e9c34c9142f (acpi: fix
acpi_os_read_pci_configuration() misuse of raw_pci_read()).  Still no
output from Xen - pygrub selects the kernel, and then the domain just
dies back to the dom0 shell.
	Attached are my latest .config and my bisect log.

Joel

-- 

"The real reason GNU ls is 8-bit-clean is so that they can
 start using ISO-8859-1 option characters."
	- Christopher Davis (ckd@loiosh.kei.com)

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 50921 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc1
# Wed Feb 13 17:45:45 2008
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
# CONFIG_GENERIC_LOCKBREAK is not set
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION="-bisectme"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
# CONFIG_MARKERS is not set
CONFIG_OPROFILE=m
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
CONFIG_BLK_DEV_BSG=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_CLASSIC_RCU=y
# CONFIG_PREEMPT_RCU is not set

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
# CONFIG_VMI is not set
CONFIG_PARAVIRT=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_IOMMU_HELPER is not set
CONFIG_NR_CPUS=32
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_RCU_TRACE=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_X86_MSR is not set
CONFIG_X86_CPUID=m
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
# CONFIG_SECCOMP is not set
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x100000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x400000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_BAY=m
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_WMI is not set
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_ACPI_CUSTOM_DSDT_INITRD is not set
CONFIG_ACPI_BLACKLIST_YEAR=1999
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_SBS=m
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_PCIEAER=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_K8_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PD6729=m
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_FAKE=m
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
CONFIG_DEFAULT_BIC=y
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="bic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
# CONFIG_NF_CONNTRACK is not set
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TRACE is not set
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
CONFIG_NETFILTER_XT_MATCH_ESP=m
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AH=m
# CONFIG_IP6_NF_MATCH_MH is not set
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_RAW=m

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
CONFIG_IP_DCCP_ACKVEC=y

#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2=m
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=m
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_CCID3_RTO=100
CONFIG_IP_DCCP_TFRC_LIB=m

#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_NET_DCCPPROBE is not set
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
CONFIG_TIPC=m
# CONFIG_TIPC_ADVANCED is not set
# CONFIG_TIPC_DEBUG is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
# CONFIG_NET_SCH_RR is not set
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_FLOW is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
# CONFIG_NET_ACT_NAT is not set
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y

#
# Wireless
#
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_EXT=y
# CONFIG_MAC80211 is not set
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_CRYPT_TKIP=m
CONFIG_IEEE80211_SOFTMAC=m
CONFIG_IEEE80211_SOFTMAC_DEBUG=y
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_TC1100_WMI is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_INTEL_MENLOW is not set
# CONFIG_ENCLOSURE_SERVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_ATA is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_EMC=m
# CONFIG_DM_MULTIPATH_RDAC is not set
# CONFIG_DM_MULTIPATH_HP is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_MII=m
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_CDCETHER=m
# CONFIG_USB_NET_DM9601 is not set
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
# CONFIG_USB_NET_MCS7830 is not set
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
# CONFIG_USB_KC2190 is not set
CONFIG_USB_NET_ZAURUS=m
# CONFIG_NET_PCMCIA is not set
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=m
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
# CONFIG_PPPOL2TP is not set
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=m

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_APPLETOUCH is not set
CONFIG_MOUSE_VSXXXAA=m
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_JOYDUMP=m
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_FUJITSU is not set
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_MK712=m
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_UCB1400 is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_APANEL is not set
CONFIG_INPUT_WISTRON_BTNS=m
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_N_HDLC=m
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=m
CONFIG_SERIAL_8250_PNP=m
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_XEN=y
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=m

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
CONFIG_CS5535_GPIO=m
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=m
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
# CONFIG_I2C_SIMTEC is not set
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_STUB=m
# CONFIG_I2C_TINY_USB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
# CONFIG_PCF8575 is not set
CONFIG_SENSORS_PCF8591=m
# CONFIG_TPS65010 is not set
CONFIG_SENSORS_MAX6875=m
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=m
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7418 is not set
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
# CONFIG_SENSORS_ADM1029 is not set
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_K8TEMP is not set
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
# CONFIG_SENSORS_I5K_AMB is not set
CONFIG_SENSORS_F71805F=m
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
# CONFIG_SENSORS_FSCHMD is not set
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IBMPEX is not set
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
# CONFIG_SENSORS_LM93 is not set
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_MAX6650 is not set
CONFIG_SENSORS_PC87360=m
# CONFIG_SENSORS_PC87427 is not set
CONFIG_SENSORS_SIS5595=m
# CONFIG_SENSORS_DME1737 is not set
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_THMC50 is not set
CONFIG_SENSORS_VIA686A=m
# CONFIG_SENSORS_VT1211 is not set
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
# CONFIG_SENSORS_W83793 is not set
CONFIG_SENSORS_W83L785TS=m
# CONFIG_SENSORS_W83L786NG is not set
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_HDAPS=m
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
CONFIG_IBMASR=m
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=m
CONFIG_ITCO_WDT=m
# CONFIG_ITCO_VENDOR_SUPPORT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_SBC7240_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
CONFIG_W83627HF_WDT=m
# CONFIG_W83697HF_WDT is not set
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m

#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
CONFIG_SSB=m
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
CONFIG_SSB_PCMCIAHOST_POSSIBLE=y
# CONFIG_SSB_PCMCIAHOST is not set
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_TDA9875=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_CX25840=m
CONFIG_VIDEO_CX2341X=m
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_SAA6588=m
# CONFIG_VIDEO_CPIA is not set
CONFIG_VIDEO_CPIA2=m
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_IVTV is not set
# CONFIG_VIDEO_CAFE_CCIC is not set
CONFIG_V4L_USB_DRIVERS=y
CONFIG_VIDEO_PVRUSB2=m
# CONFIG_VIDEO_PVRUSB2_ONAIR_CREATOR is not set
# CONFIG_VIDEO_PVRUSB2_ONAIR_USB2 is not set
CONFIG_VIDEO_PVRUSB2_SYSFS=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_EM28XX=m
# CONFIG_VIDEO_USBVISION is not set
CONFIG_VIDEO_USBVIDEO=m
CONFIG_USB_VICAM=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_QUICKCAM_MESSENGER=m
CONFIG_USB_ET61X251=m
CONFIG_VIDEO_OVCAMCHIP=m
CONFIG_USB_W9968CF=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m
CONFIG_USB_ZC0301=m
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set
# CONFIG_USB_ZR364XX is not set
# CONFIG_USB_STKWEBCAM is not set
CONFIG_RADIO_ADAPTERS=y
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
CONFIG_USB_DSBR=m
# CONFIG_USB_SI470X is not set
# CONFIG_DVB_CORE is not set
CONFIG_VIDEO_TUNER=m
# CONFIG_VIDEO_TUNER_CUSTOMIZE is not set
CONFIG_TUNER_XC2028=m
CONFIG_TUNER_MT20XX=m
CONFIG_TUNER_TDA8290=m
CONFIG_TUNER_TEA5761=m
CONFIG_TUNER_TEA5767=m
CONFIG_TUNER_SIMPLE=m
CONFIG_TUNER_TDA9887=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR_I2C=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_DAB=y
CONFIG_USB_DABUSB=m

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_ALI=y
CONFIG_AGP_ATI=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=y
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
CONFIG_DRM_MGA=m
# CONFIG_DRM_SIS is not set
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
CONFIG_VGASTATE=m
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=m
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
# CONFIG_FB_EFI is not set
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
# CONFIG_FB_NVIDIA_DEBUG is not set
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA=m
# CONFIG_FB_RIVA_I2C is not set
# CONFIG_FB_RIVA_DEBUG is not set
CONFIG_FB_RIVA_BACKLIGHT=y
CONFIG_FB_I810=m
CONFIG_FB_I810_GTF=y
CONFIG_FB_I810_I2C=y
# CONFIG_FB_LE80578 is not set
CONFIG_FB_INTEL=m
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_INTEL_I2C=y
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
CONFIG_FB_SAVAGE=m
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
CONFIG_FB_KYRO=m
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
CONFIG_FB_CYBLA=m
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_CORGI is not set
# CONFIG_BACKLIGHT_PROGEAR is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_DEBUG=y
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT_POWERBOOK=y
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_THRUSTMASTER_FF=y
# CONFIG_ZEROPLUS_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_HCD_SSB is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_SL811_HCD=m
CONFIG_USB_SL811_CS=m
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
CONFIG_USB_MON=y

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_CLEVO_MAIL is not set

#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
CONFIG_EDAC_E7XXX=m
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82875P=m
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
CONFIG_EDAC_I82860=m
CONFIG_EDAC_R82600=m
# CONFIG_EDAC_I5000 is not set
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m

#
# Conflicting RTC option has been selected, check GEN_RTC and RTC
#

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
# CONFIG_RTC_DRV_DS1374 is not set
CONFIG_RTC_DRV_DS1672=m
# CONFIG_RTC_DRV_MAX6900 is not set
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
# CONFIG_RTC_DRV_M41T80 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1511 is not set
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_DS1742=m
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T59 is not set
CONFIG_RTC_DRV_V3020=m

#
# on-CPU RTC drivers
#

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_NOLOCK=m
CONFIG_GFS2_FS_LOCKING_DLM=m
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_DEBUG_MASKLOG=y
CONFIG_OCFS2_DEBUG_FS=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
# CONFIG_MINIX_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
# CONFIG_SUNRPC_BIND34 is not set
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
# CONFIG_FRAME_POINTER is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
CONFIG_IO_DELAY_0XED=y
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=1
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_BLKCIPHER=m
# CONFIG_CRYPTO_SEQIV is not set
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=m
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
# CONFIG_CRYPTO_TWOFISH_586 is not set
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_LZO is not set
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
# CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set
# CONFIG_CRYPTO_DEV_GEODE is not set
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_VIRTUALIZATION=y
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y

[-- Attachment #3: bisect.log --]
[-- Type: text/plain, Size: 2540 bytes --]

git-bisect start
# bad: [96b5a46e2a72dc1829370c87053e0cd558d58bc0] WMI: initialize wmi_blocks.list even if ACPI is disabled
git-bisect bad 96b5a46e2a72dc1829370c87053e0cd558d58bc0
# good: [9b73e76f3cf63379dcf45fcd4f112f5812418d0a] Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git-bisect good 9b73e76f3cf63379dcf45fcd4f112f5812418d0a
# good: [cda13dd164f91df79ba797ab84848352b03de115] [POWERPC] 83xx: Clean up / convert mpc83xx board DTS files to v1 format.
git-bisect good cda13dd164f91df79ba797ab84848352b03de115
# bad: [02ff1324930675599694bb1285afc4341f98a7a1] [ALSA] ak4xxx - Check value ranges in ctl callbacks
git-bisect bad 02ff1324930675599694bb1285afc4341f98a7a1
# good: [91b4f954759653272504c55b715b757207ed1700] [VLAN]: Move protocol determination to seperate function
git-bisect good 91b4f954759653272504c55b715b757207ed1700
# good: [60b3b9af35aad66345e395be911e46fb8443f0c5] x86: x86 user_regset cleanup
git-bisect good 60b3b9af35aad66345e395be911e46fb8443f0c5
# bad: [10f22dde556d1ed41d55355d1fb8ad495f9810c8] x86: arch/x86/mm/init_64.c printk fixes
git-bisect bad 10f22dde556d1ed41d55355d1fb8ad495f9810c8
# good: [27cc2a812eb504f4aadff5baa862da715fb0f886] x86: use shorter addresses in i386 segfault printks
git-bisect good 27cc2a812eb504f4aadff5baa862da715fb0f886
# good: [fa2d8369a1e0e5dd0fdaaba9d40ca5187f4cd20b] x86: c_p_a(), add simple self test at boot
git-bisect good fa2d8369a1e0e5dd0fdaaba9d40ca5187f4cd20b
# bad: [30551bb3ce9257a2352b3cb4e45010d415cc0ad5] x86: add PG_LEVEL enum
git-bisect bad 30551bb3ce9257a2352b3cb4e45010d415cc0ad5
# bad: [a2172e2586f6662af996e47f417bb718c37cf8d2] x86: fix some bugs about EFI runtime code mapping
git-bisect bad a2172e2586f6662af996e47f417bb718c37cf8d2
# bad: [d701fda8601fe267fbd3648f108f0e751305101b] x86: fix early_ioremap()/btmap
git-bisect bad d701fda8601fe267fbd3648f108f0e751305101b
# bad: [beacfaac3f23b30814aafee37a055257c7062ef3] x86 32-bit boot: rename bt_ioremap() to early_ioremap()
git-bisect bad beacfaac3f23b30814aafee37a055257c7062ef3
# good: [fbd3bfd87f91e6a454f3f61f67ee745f0cb59aa4] x86: use __PAGE_KERNEL_EXEC in ioremap_64.c
git-bisect good fbd3bfd87f91e6a454f3f61f67ee745f0cb59aa4
# bad: [0947b2f31ca1ea1211d3cde2dbd8fcec579ef395] i386 boot: replace boot_ioremap with enhanced bt_ioremap - enhance bt_ioremap
git-bisect bad 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
# good: [4138cc3418f5eaa7524ff8e927102863f1ba0ea5] x86: set strong uncacheable where UC is really desired
git-bisect good 4138cc3418f5eaa7524ff8e927102863f1ba0ea5

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-14  2:27   ` Joel Becker
@ 2008-02-14  7:50     ` Jeremy Fitzhardinge
  2008-02-15 20:23       ` Joel Becker
  0 siblings, 1 reply; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-14  7:50 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Ian Campbell, H. Peter Anvin, Eric W. Biederman,
	Andi Kleen, Mika Penttila

Joel Becker wrote:
> On Wed, Feb 13, 2008 at 10:59:33PM +1100, Jeremy Fitzhardinge wrote:
>   
>>> I thought I'd try out 2.6.25-rc1 as a xen 32-bit pae domU the other day.
>>> Unfortunately, I didn't get very far very fast, as the domain just crashed
>>> immediately upon booting, without any direct feedback (I did have messages
>>> on the xen message buffer, which helped). This even with earlyprintk turned on.
>>>
>>> After a long, arduous journey, I managed to track this down to the following:
>>>
>>> ----------
>>> commit	551889a6e2a24a9c06fd453ea03b57b7746ffdc0
>>>       
>
> 	I'm seeing the same problem, with no messages at all from xen
> other than "domain crashed, restart disabled" in xend.log.  I got a
> different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
> (i386 boot: replace boot_io    remap with enhanced bt_ioremap - enhance
> bt_ioremap).  I started from yesterday's
> 96b5a46e2a72dc1829370c87053e0cd558d58bc0 (WMI: initialize
> wmi_blocks.list even if ACPI is disabled) and a known good
> 9b73e76f3cf63379dcf45fcd4f112f5812418d0a (Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6).
>
>   
>> Although I'm on vacation, I happened to download a recent copy of  
>> x86.git and found that it crashes early.  Here's a couple of patches to  
>> apply; I don't know if they apply to current git, but I hope it helps.
>>     
>
>   
>> Subject: x86/early_ioremap: don't assume we're using swapper_pg_dir
>> Subject: xen: unpin initial Xen pagetable once we're finished with it
>>     
>
> 	After my bisect was done, I re-pulled from Linus and discovered
> these patches.  Searching for these emails, they certainly sound like my
> problem.  But the kernel does not boot, commit
> 10270d4838bdc493781f5a1cf2e90e9c34c9142f (acpi: fix
> acpi_os_read_pci_configuration() misuse of raw_pci_read()).  Still no
> output from Xen - pygrub selects the kernel, and then the domain just
> dies back to the dom0 shell.
> 	Attached are my latest .config and my bisect log.
>   

Is the domain ending up in the crashed state?  Do you get a register 
dump with xm dmesg?  That would be very useful in determining what went 
wrong.  You may need to compile Xen with debug=y in Config.mk.

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-14  7:50     ` Jeremy Fitzhardinge
@ 2008-02-15 20:23       ` Joel Becker
  2008-02-16  2:44         ` Jeremy Fitzhardinge
  2008-02-17 18:49         ` Ian Campbell
  0 siblings, 2 replies; 46+ messages in thread
From: Joel Becker @ 2008-02-15 20:23 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Ian Campbell, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila

On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
>> 	I'm seeing the same problem, with no messages at all from xen
>> other than "domain crashed, restart disabled" in xend.log.  I got a
>> different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
>> (i386 boot: replace boot_io    remap with enhanced bt_ioremap - enhance
>> bt_ioremap).  I started from yesterday's
>> 96b5a46e2a72dc1829370c87053e0cd558d58bc0 (WMI: initialize
>> wmi_blocks.list even if ACPI is disabled) and a known good
>> 9b73e76f3cf63379dcf45fcd4f112f5812418d0a (Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6).
>
> Is the domain ending up in the crashed state?  Do you get a register  
> dump with xm dmesg?  That would be very useful in determining what went  
> wrong.  You may need to compile Xen with debug=y in Config.mk.

	I didn't know xm dmesg existed :-)  Regarding debug=y, I'm using
a prepackaged dom0 set.  Here's what I find in xm dmesg:

Joel

(XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 00000000e0000000) for mfn 3a2f0f (pfn f0)
(XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 00000003a2f0f063 for dom109
(XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 00000000e0000000) for mfn 3a2f0f (pfn f0)
(XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 00000003a2f0f063 for dom109
(XEN) mm.c:3331:d109 ptwr_emulate: could not get_page_from_l1e()
(XEN) Unhandled page fault in domain 109 on VCPU 0 (ec=0003)
(XEN) Pagetable walk from 00000000c01687f0:
(XEN)  L4[0x000] = 00000003a2933027 00000000000006cc
(XEN)  L3[0x003] = 000000039afea027 0000000000000005
(XEN)  L2[0x000] = 000000039bfb7067 0000000000001048 
(XEN)  L1[0x168] = 00000003a2e97061 0000000000000168
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 109 (vcpu#0) crashed on cpu#2:
(XEN) ----[ Xen-3.1.3-rc3  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    e019:[<00000000c04040bd>]
(XEN) RFLAGS: 0000000000000282   CONTEXT: guest
(XEN) rax: 00000000c01687f0   rbx: 00000000f52fe000   rcx: 00000000a2f0f063
(XEN) rdx: 0000000000000003   rsi: 0000000000000000   rdi: 00000000a2f0f063
(XEN) rbp: 0000000000000003   rsp: 00000000c06daefc   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) cr3: 000000039afe2000   cr2: 00000000c01687f0
(XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
(XEN) Guest stack trace from esp=c06daefc:
(XEN)   00000003 c04040bd 0001e019 00010082 c01687f0 f52fe000 80000000 a2f0f063
(XEN)   000f0000 c01687f0 c0417ab6 a2f0f063 00000003 000000f0 f52fe000 00000010
(XEN)   000004ff 000f0000 000004ff c06eee29 00000063 80000000 000f0000 c06dafc8
(XEN)   c06ca400 0069a000 00000000 c06f9d82 00000000 f57fd000 f57fd000 f57fd000
(XEN)   c0005d60 c06dafc8 c06ca400 0069a000 00000000 c06e70d4 c06d7680 c1043000
(XEN)   007c9000 00000000 0069a000 c1043000 c06dafe4 00000000 00000000 c06e05fd
(XEN)   c0602000 c06529f8 dfbffdff c0701940 c1043000 c06dafe4 00000000 00000000
(XEN)   c06e5f54 00000000 178bc1f1 00000001 03020800 00020f12 f5800000 00000000
(XEN)   c1043000 c06e05c3 c06e05cb c06e05d3 c040288f c040299a c0403270 c06e6141
(XEN)   c0403652 c0403709 c0403831 c0403a56 c0403a6d c0403a86 c0403b67 c04042c9
(XEN)   c0404492 c04045da c040467a c06e622f c06e6238 c04052c5 c04052f7 c0405325
(XEN)   c0405410 c06e6272 c06e62ee c06e6341 c05f23f3 c05f25d0 c04060eb c04063ed
(XEN)   c04064cf c040652b c0406719 c0406877 c0406fcc c0407046 c0407120 c04075cb
(XEN)   c04075e9 c040762b c040765f c040772c c0407755 c0407804 c0408c32 c0408cd3
(XEN)   c05fa9ad c05faa20 c05faabe c05fad01 c06e6843 c06e6853 c0409b23 c0409c6d
(XEN)   c06e6921 c06e692a c040a4f1 c040b5a2 c040b5b0 c040b627 c040b635 c06e7ff4
(XEN)   c06e8007 c040b8bf c040b8ee c06e8340 c06e8349 c040bcb0 c040bd26 c040c9a4
(XEN)   c040cca2 c040ccaa c040cd11 c040cd47 c040cd50 c040d026 c040d02e c040d278
(XEN)   c040d280 c040d297 c040d29f c040d2c4 c040ddad c040de24 c040de33 c040de67
(XEN)   c040dea1 c040deaa c040deb3 c05f2a94 c05f2bfb c05f2c4a c05f2c65 c05f2ddc

-- 

Life's Little Instruction Book #24

	"Drink champagne for no reason at all."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-15 20:23       ` Joel Becker
@ 2008-02-16  2:44         ` Jeremy Fitzhardinge
  2008-02-16  8:54           ` Joel Becker
  2008-02-17 18:49         ` Ian Campbell
  1 sibling, 1 reply; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-16  2:44 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Ian Campbell, H. Peter Anvin, Eric W. Biederman,
	Andi Kleen, Mika Penttila

Joel Becker wrote:
> On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
>   
>>> 	I'm seeing the same problem, with no messages at all from xen
>>> other than "domain crashed, restart disabled" in xend.log.  I got a
>>> different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
>>> (i386 boot: replace boot_io    remap with enhanced bt_ioremap - enhance
>>> bt_ioremap).  I started from yesterday's
>>> 96b5a46e2a72dc1829370c87053e0cd558d58bc0 (WMI: initialize
>>> wmi_blocks.list even if ACPI is disabled) and a known good
>>> 9b73e76f3cf63379dcf45fcd4f112f5812418d0a (Merge
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6).
>>>       
>> Is the domain ending up in the crashed state?  Do you get a register  
>> dump with xm dmesg?  That would be very useful in determining what went  
>> wrong.  You may need to compile Xen with debug=y in Config.mk.
>>     
>
> 	I didn't know xm dmesg existed :-)  Regarding debug=y, I'm using
> a prepackaged dom0 set.  Here's what I find in xm dmesg:
>
> Joel
>
> (XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 00000000e0000000) for mfn 3a2f0f (pfn f0)
> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 00000003a2f0f063 for dom109
> (XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 00000000e0000000) for mfn 3a2f0f (pfn f0)
> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 00000003a2f0f063 for dom109
> (XEN) mm.c:3331:d109 ptwr_emulate: could not get_page_from_l1e()
>   

Hm, I have a suspicion about what this might be.  I'll haven't tried 
reproducing it yet though.

> (XEN) Unhandled page fault in domain 109 on VCPU 0 (ec=0003)
> (XEN) Pagetable walk from 00000000c01687f0:
> (XEN)  L4[0x000] = 00000003a2933027 00000000000006cc
> (XEN)  L3[0x003] = 000000039afea027 0000000000000005
> (XEN)  L2[0x000] = 000000039bfb7067 0000000000001048 
> (XEN)  L1[0x168] = 00000003a2e97061 0000000000000168
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 109 (vcpu#0) crashed on cpu#2:
> (XEN) ----[ Xen-3.1.3-rc3  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    2
> (XEN) RIP:    e019:[<00000000c04040bd>]
>   

What does this EIP correspond to in your kernel?  Also:

c01687f0 c0417ab6 c040288f c040299a c0403270

(as guesses of potential callers to try and work out a stack trace).

Thanks,
	J



^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-16  2:44         ` Jeremy Fitzhardinge
@ 2008-02-16  8:54           ` Joel Becker
  2008-02-16 11:46             ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 46+ messages in thread
From: Joel Becker @ 2008-02-16  8:54 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Ian Campbell, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila

On Sat, Feb 16, 2008 at 01:44:26PM +1100, Jeremy Fitzhardinge wrote:
> Joel Becker wrote:
>
>> (XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 
>> 00000000e0000000) for mfn 3a2f0f (pfn f0)
>> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 
>> 00000003a2f0f063 for dom109
>> (XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 
>> 00000000e0000000) for mfn 3a2f0f (pfn f0)
>> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 
>> 00000003a2f0f063 for dom109
>> (XEN) mm.c:3331:d109 ptwr_emulate: could not get_page_from_l1e()
>>   
>
> Hm, I have a suspicion about what this might be.  I'll haven't tried 
> reproducing it yet though.
>
>> (XEN) Unhandled page fault in domain 109 on VCPU 0 (ec=0003)
>> (XEN) Pagetable walk from 00000000c01687f0:
>> (XEN)  L4[0x000] = 00000003a2933027 00000000000006cc
>> (XEN)  L3[0x003] = 000000039afea027 0000000000000005
>> (XEN)  L2[0x000] = 000000039bfb7067 0000000000001048 (XEN)  L1[0x168] = 
>> 00000003a2e97061 0000000000000168
>> (XEN) domain_crash_sync called from entry.S
>> (XEN) Domain 109 (vcpu#0) crashed on cpu#2:
>> (XEN) ----[ Xen-3.1.3-rc3  x86_64  debug=n  Not tainted ]----
>> (XEN) CPU:    2
>> (XEN) RIP:    e019:[<00000000c04040bd>]
>>   
>
> What does this EIP correspond to in your kernel?  Also:
>
> c01687f0 c0417ab6 c040288f c040299a c0403270
>
> (as guesses of potential callers to try and work out a stack trace).

	ksymoops is no help at all, but I got these from objdump of
vmlinux:

c04040bd xen_set_pte
c0417ab6 set_pte_present
c040288f set_bit
c040299a __raw_spin_unlock
c0403270 __set_64bit

Joel

-- 

Dort wo man Bücher verbrennt, verbrennt man am Ende auch Mensch.
(Wherever they burn books, they will also end up burning people.)
	- Heinrich Heine

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-16  8:54           ` Joel Becker
@ 2008-02-16 11:46             ` Jeremy Fitzhardinge
  2008-02-17  6:29               ` Joel Becker
  2008-02-17  6:39               ` Joel Becker
  0 siblings, 2 replies; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-16 11:46 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Ian Campbell, H. Peter Anvin, Eric W. Biederman,
	Andi Kleen, Mika Penttila

Joel Becker wrote:
> On Sat, Feb 16, 2008 at 01:44:26PM +1100, Jeremy Fitzhardinge wrote:
>   
>> Joel Becker wrote:
>>
>>     
>>> (XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 
>>> 00000000e0000000) for mfn 3a2f0f (pfn f0)
>>> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 
>>> 00000003a2f0f063 for dom109
>>> (XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 
>>> 00000000e0000000) for mfn 3a2f0f (pfn f0)
>>> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 
>>> 00000003a2f0f063 for dom109
>>> (XEN) mm.c:3331:d109 ptwr_emulate: could not get_page_from_l1e()
>>>   
>>>       
>> Hm, I have a suspicion about what this might be.  I'll haven't tried 
>> reproducing it yet though.
>>
>>     
>>> (XEN) Unhandled page fault in domain 109 on VCPU 0 (ec=0003)
>>> (XEN) Pagetable walk from 00000000c01687f0:
>>> (XEN)  L4[0x000] = 00000003a2933027 00000000000006cc
>>> (XEN)  L3[0x003] = 000000039afea027 0000000000000005
>>> (XEN)  L2[0x000] = 000000039bfb7067 0000000000001048 (XEN)  L1[0x168] = 
>>> 00000003a2e97061 0000000000000168
>>> (XEN) domain_crash_sync called from entry.S
>>> (XEN) Domain 109 (vcpu#0) crashed on cpu#2:
>>> (XEN) ----[ Xen-3.1.3-rc3  x86_64  debug=n  Not tainted ]----
>>> (XEN) CPU:    2
>>> (XEN) RIP:    e019:[<00000000c04040bd>]
>>>   
>>>       
>> What does this EIP correspond to in your kernel?  Also:
>>
>> c01687f0 c0417ab6 c040288f c040299a c0403270
>>
>> (as guesses of potential callers to try and work out a stack trace).
>>     
>
> 	ksymoops is no help at all, but I got these from objdump of
> vmlinux:
>
> c04040bd xen_set_pte
> c0417ab6 set_pte_present
> c040288f set_bit
> c040299a __raw_spin_unlock
> c0403270 __set_64bit

(My usual technique is use "gdb vmlinux" and "x/i 0x...." to do the 
lookup.) 

Unfortunately that doesn't narrow down what the kernel was actually 
trying to do at the time.  Clearly a set_pte; looks like someone is 
trying to create a writable mapping of an existing pte page.

Does "console=hvc0 earlyprintk=xen" on the kernel command line give any 
clue about how far it gets before crashing?

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-16 11:46             ` Jeremy Fitzhardinge
@ 2008-02-17  6:29               ` Joel Becker
  2008-02-17 12:09                 ` Jeremy Fitzhardinge
  2008-02-17  6:39               ` Joel Becker
  1 sibling, 1 reply; 46+ messages in thread
From: Joel Becker @ 2008-02-17  6:29 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Ian Campbell, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila

On Sat, Feb 16, 2008 at 10:46:23PM +1100, Jeremy Fitzhardinge wrote:
> Joel Becker wrote:
>> 	ksymoops is no help at all, but I got these from objdump of
>> vmlinux:
>>
>> c04040bd xen_set_pte
>> c0417ab6 set_pte_present
>> c040288f set_bit
>> c040299a __raw_spin_unlock
>> c0403270 __set_64bit
>
> (My usual technique is use "gdb vmlinux" and "x/i 0x...." to do the  
> lookup.) 

	Thanks for the tip!

> Unfortunately that doesn't narrow down what the kernel was actually  
> trying to do at the time.  Clearly a set_pte; looks like someone is  
> trying to create a writable mapping of an existing pte page.
>
> Does "console=hvc0 earlyprintk=xen" on the kernel command line give any  
> clue about how far it gets before crashing?

	Console is already hvc0, but earlyprintk gets us:

--8<-----------------------------------------------------------------
Reserving virtual address space above 0xf57fe000
Linux version 2.6.25-rc2-bisectme (jlbec@ca-build23.us.oracle.com) (gcc
version 4.1.2 20070626 (Red Hat 4.1.2-14)) #21 SMP Fri Feb 15 16:28:35
PST 2008
ACPI in unprivileged domain disabled
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 0000000078000000 (usable)
console [xenboot0] enabled
1192MB HIGHMEM available.
727MB LOWMEM available.
Started domain ca-test58
                        Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
NX (Execute Disable) protection: active
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   186366
  HighMem    186366 ->   491520
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   491520
-->8-----------------------------------------------------------------

That's it.

Joel

-- 

"The nearest approach to immortality on Earth is a government
 bureau."
	- James F. Byrnes

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-16 11:46             ` Jeremy Fitzhardinge
  2008-02-17  6:29               ` Joel Becker
@ 2008-02-17  6:39               ` Joel Becker
  1 sibling, 0 replies; 46+ messages in thread
From: Joel Becker @ 2008-02-17  6:39 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Ian Campbell, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila

On Sat, Feb 16, 2008 at 10:46:23PM +1100, Jeremy Fitzhardinge wrote:
>>> What does this EIP correspond to in your kernel?  Also:
>>>
>>> c01687f0 c0417ab6 c040288f c040299a c0403270
>>>
>>> (as guesses of potential callers to try and work out a stack trace).
>>>     
>>
> (My usual technique is use "gdb vmlinux" and "x/i 0x...." to do the  
> lookup.) 

	Ok, my objdump didn't do a good job.  With gdb I get:

0xc04040bd <xen_set_pte_at+185>:	mov    %edi,(%eax)
0xc01687f0:	Cannot access memory at address 0xc01687f0
0xc0417ab6 <__set_fixmap+326>:	pop    %ecx
0xc040288f <xen_alloc_ptpage+41>:	lock btsl $0x8,(%eax)
0xc040299a <xen_load_idt+74>:	lock incb 0xc0766148
0xc0403270 <xen_set_pte_atomic+26>:	lock cmpxchg8b (%edi)

Joel

-- 

Life's Little Instruction Book #139

	"Never deprive someone of hope; it might be all they have."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-17  6:29               ` Joel Becker
@ 2008-02-17 12:09                 ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-17 12:09 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Ian Campbell, H. Peter Anvin, Eric W. Biederman,
	Andi Kleen, Mika Penttila

Joel Becker wrote:
>   
>> Unfortunately that doesn't narrow down what the kernel was actually  
>> trying to do at the time.  Clearly a set_pte; looks like someone is  
>> trying to create a writable mapping of an existing pte page.
>>
>> Does "console=hvc0 earlyprintk=xen" on the kernel command line give any  
>> clue about how far it gets before crashing?
>>     
>
>   

I built a kernel using your .config here, but I can't reproduce the 
problem.  It makes it all the way to trying to start init (failed at 
that point because I didn't create an initrd with the xvd module to 
mount /).

> 	Console is already hvc0, but earlyprintk gets us:
>
> --8<-----------------------------------------------------------------
> Reserving virtual address space above 0xf57fe000
> Linux version 2.6.25-rc2-bisectme (jlbec@ca-build23.us.oracle.com) (gcc
> version 4.1.2 20070626 (Red Hat 4.1.2-14)) #21 SMP Fri Feb 15 16:28:35
> PST 2008
> ACPI in unprivileged domain disabled
> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 0000000078000000 (usable)
> console [xenboot0] enabled
> 1192MB HIGHMEM available.
> 727MB LOWMEM available.
> Started domain ca-test58
>                         Scan SMP from c0000000 for 1024 bytes.
> Scan SMP from c009fc00 for 1024 bytes.
> Scan SMP from c00f0000 for 65536 bytes.
> NX (Execute Disable) protection: active
> Zone PFN ranges:
>   DMA             0 ->     4096
>   Normal       4096 ->   186366
>   HighMem    186366 ->   491520
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
>     0:        0 ->   491520
> -->8-----------------------------------------------------------------
>
> That's it.
>   

I get:

Entering add_active_range(0, 0, 16384) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    16384
  HighMem     16384 ->    16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    16384
On node 0 totalpages: 16384
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 96 pages used for memmap
  Normal zone: 12192 pages, LIFO batch:1
  HighMem zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
...


What happens if you give the domain less memory?

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-15 20:23       ` Joel Becker
  2008-02-16  2:44         ` Jeremy Fitzhardinge
@ 2008-02-17 18:49         ` Ian Campbell
  2008-02-18 10:40           ` Joel Becker
  1 sibling, 1 reply; 46+ messages in thread
From: Ian Campbell @ 2008-02-17 18:49 UTC (permalink / raw)
  To: Joel Becker
  Cc: Jeremy Fitzhardinge, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila

[-- Attachment #1: Type: text/plain, Size: 3138 bytes --]


On Fri, 2008-02-15 at 12:23 -0800, Joel Becker wrote:
> On Thu, Feb 14, 2008 at 06:50:52PM +1100, Jeremy Fitzhardinge wrote:
> >> 	I'm seeing the same problem, with no messages at all from xen
> >> other than "domain crashed, restart disabled" in xend.log.  I got a
> >> different commit in my bisect, 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
> >> (i386 boot: replace boot_io    remap with enhanced bt_ioremap - enhance
> >> bt_ioremap).  I started from yesterday's
> >> 96b5a46e2a72dc1829370c87053e0cd558d58bc0 (WMI: initialize
> >> wmi_blocks.list even if ACPI is disabled) and a known good
> >> 9b73e76f3cf63379dcf45fcd4f112f5812418d0a (Merge
> >> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6).
> >
> > Is the domain ending up in the crashed state?  Do you get a register  
> > dump with xm dmesg?  That would be very useful in determining what went  
> > wrong.  You may need to compile Xen with debug=y in Config.mk.
> 
> 	I didn't know xm dmesg existed :-)  Regarding debug=y, I'm using
> a prepackaged dom0 set.  Here's what I find in xm dmesg:
> 
> Joel
> 
> (XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 00000000e0000000) for mfn 3a2f0f (pfn f0)
> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 00000003a2f0f063 for dom109
> (XEN) mm.c:1825:d109 Bad type (saw 0000000028000001 != exp 00000000e0000000) for mfn 3a2f0f (pfn f0)
> (XEN) mm.c:649:d109 Error getting mfn 3a2f0f (pfn f0) from L1 entry 00000003a2f0f063 for dom109
> (XEN) mm.c:3331:d109 ptwr_emulate: could not get_page_from_l1e()

I've been seeing similar attempts to map 0xf0 but so far I was the only
one (although that made no sense to me). Does the patch below help at
all? The problem seems to be that the kernel is trying to map pages at
0xf0000 but these are not reserved in the guest E820 map so they could
contain a page table page etc.

A useful tip for getting a backtrace out of a crashed Xen guest is to
set "on_crash=preserve" in your domain config. Then once the crash has
happened you can use "/usr/lib/xen/bin/xenctx -s System.map <domid>"
where System.map is the guest kernel System.map.

Ian.

--- 

x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.

Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 9008ed5..79525f5 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -7,6 +7,7 @@
 #include <linux/bootmem.h>
 #include <linux/slab.h>
 #include <asm/dmi.h>
+#include <asm/e820.h>
 
 static char dmi_empty_string[] = "        ";
 
@@ -336,6 +337,10 @@ void __init dmi_scan_machine(void)
 		}
 	}
 	else {
+
+		if (!e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RESERVED))
+			goto out;
+
 		/*
 		 * no iounmap() for that ioremap(); it would be a no-op, but
 		 * it's so early in setup that sucker gets confused into doing

-- 
Ian Campbell

The profession of book writing makes horse racing seem like a solid,
stable business.
		-- John Steinbeck
	[Horse racing *is* a stable business ...]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply related	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-17 18:49         ` Ian Campbell
@ 2008-02-18 10:40           ` Joel Becker
  2008-02-19 21:50             ` Ian Campbell
  2008-02-19 21:59             ` Ian Campbell
  0 siblings, 2 replies; 46+ messages in thread
From: Joel Becker @ 2008-02-18 10:40 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Jeremy Fitzhardinge, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila

On Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:
> I've been seeing similar attempts to map 0xf0 but so far I was the only
> one (although that made no sense to me). Does the patch below help at
> all? The problem seems to be that the kernel is trying to map pages at
> 0xf0000 but these are not reserved in the guest E820 map so they could
> contain a page table page etc.
> 
> A useful tip for getting a backtrace out of a crashed Xen guest is to
> set "on_crash=preserve" in your domain config. Then once the crash has
> happened you can use "/usr/lib/xen/bin/xenctx -s System.map <domid>"
> where System.map is the guest kernel System.map.

	That didn't work for me - it gave me "can't trace dom0" for
whatever reason.  But...

> x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> 
> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 9008ed5..79525f5 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -7,6 +7,7 @@
>  #include <linux/bootmem.h>
>  #include <linux/slab.h>
>  #include <asm/dmi.h>
> +#include <asm/e820.h>
>  
>  static char dmi_empty_string[] = "        ";
>  
> @@ -336,6 +337,10 @@ void __init dmi_scan_machine(void)
>  		}
>  	}
>  	else {
> +
> +		if (!e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RESERVED))
> +			goto out;
> +
>  		/*
>  		 * no iounmap() for that ioremap(); it would be a no-op, but
>  		 * it's so early in setup that sucker gets confused into doing

	This fixed it.  I'm now booting successfully.  Thank you!  If
you have any furthur patches you'd like to test, I'd be happy to do so.

Joel

-- 

"And yet I find,
 And yet I find repeating in my head.
 If I can't be my own, 
 I'd feel better dead."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-18 10:40           ` Joel Becker
@ 2008-02-19 21:50             ` Ian Campbell
  2008-02-19 21:59             ` Ian Campbell
  1 sibling, 0 replies; 46+ messages in thread
From: Ian Campbell @ 2008-02-19 21:50 UTC (permalink / raw)
  To: Joel Becker
  Cc: Jeremy Fitzhardinge, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila


On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> On Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:
> > I've been seeing similar attempts to map 0xf0 but so far I was the only
> > one (although that made no sense to me). Does the patch below help at
> > all? The problem seems to be that the kernel is trying to map pages at
> > 0xf0000 but these are not reserved in the guest E820 map so they could
> > contain a page table page etc.
> > 
> > A useful tip for getting a backtrace out of a crashed Xen guest is to
> > set "on_crash=preserve" in your domain config. Then once the crash has
> > happened you can use "/usr/lib/xen/bin/xenctx -s System.map <domid>"
> > where System.map is the guest kernel System.map.
> 
> 	That didn't work for me - it gave me "can't trace dom0" for
> whatever reason.  But...

Strange. You gave it the domid of the guest not dom0 I assume. Might be
an older buggy version but it works ok in newer versions:

        # /usr/lib/xen/bin/xenctx -s /boot/System.map-2.6.18.8-x86_32p-xenU 2
        eip: c01013a7 hypercall_page+0x3a7 flags: 00001246 i z p
        esp: c0361f64
        eax: 00000000   ebx: deadbeef   ecx: deadbeef   edx: 00000001
        esi: 00000000   edi: 00000000   ebp: c0361f84
         cs: 00000061    ds: 0000007b    fs: 00000000    gs: 00000000
        
        Stack:
         c01089eb 02d8e984 5cec4d7d 0001f3ea 00000000 000008f1 ffffffff 00000000
         c0361f8c c010436c c0361fa8 c0103263 c03880c0 c03880a0 000008f1 c038a464
         c184f3c4 c0361fbc c0102415 c0102060 00000000 00000a00 c0361ff8 c036687f
         c02ed19c c038e120 c031f000 00000022 c03662a0 c184d000 000023c4 00000000
        
        Code:
        cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 1d 00 00 00 cd 82 <c3> cc cc cc cc cc cc cc cc cc cc 
        
        Call Trace:
          [<c01013a7>] hypercall_page+0x3a7  <--
          [<c01089eb>] raw_safe_halt+0x9b 
          [<c010436c>] xen_idle+0x2c 
          [<c0103263>] cpu_idle+0x83 
          [<c0102415>] rest_init+0x35 
          [<c0102060>] _stext+0x60 
          [<c036687f>] start_kernel+0x36f 
          [<c03662a0>] parse_early_param+0x70 
        
Ian.

-- 
Ian Campbell

94% of the women in America are beautiful and the rest hang out around
here.


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-18 10:40           ` Joel Becker
  2008-02-19 21:50             ` Ian Campbell
@ 2008-02-19 21:59             ` Ian Campbell
  2008-02-20  7:43               ` H. Peter Anvin
  1 sibling, 1 reply; 46+ messages in thread
From: Ian Campbell @ 2008-02-19 21:59 UTC (permalink / raw)
  To: Joel Becker
  Cc: Jeremy Fitzhardinge, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, H. Peter Anvin, Eric W. Biederman, Andi Kleen,
	Mika Penttila


On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> On Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:

> > x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.

> 	This fixed it.  I'm now booting successfully.  Thank you!

Excellent. Jeremy, are you happy for this to go in?

>From 23e4ec12b95064320f83fca1cc1ad5c7b2eb3386 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ijc@hellion.org.uk>
Date: Tue, 19 Feb 2008 21:57:45 +0000
Subject: [PATCH] x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.

Under Xen the memory at 0xf0000 is regular RAM and so can potentially contain a
page table and hence cannot be mapped. The e820 map given to guest reflects
this.

Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
---
 drivers/firmware/dmi_scan.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 653265a..7d29403 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -7,6 +7,7 @@
 #include <linux/bootmem.h>
 #include <linux/slab.h>
 #include <asm/dmi.h>
+#include <asm/e820.h>
 
 static char dmi_empty_string[] = "        ";
 
@@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
 		}
 	}
 	else {
+		if (!e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RESERVED))
+			goto out;
+
 		/*
 		 * no iounmap() for that ioremap(); it would be a no-op, but
 		 * it's so early in setup that sucker gets confused into doing
-- 
1.5.4.2

-- 
Ian Campbell

After the game the king and the pawn go in the same box.
		-- Italian proverb


^ permalink raw reply related	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-19 21:59             ` Ian Campbell
@ 2008-02-20  7:43               ` H. Peter Anvin
  2008-02-20  8:51                 ` Ian Campbell
  0 siblings, 1 reply; 46+ messages in thread
From: H. Peter Anvin @ 2008-02-20  7:43 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Joel Becker, Jeremy Fitzhardinge, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila

Ian Campbell wrote:
> On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
>> On Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:
> 
>>> x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> 
>> 	This fixed it.  I'm now booting successfully.  Thank you!
> 
> Excellent. Jeremy, are you happy for this to go in?
> 

NAK!

It's pretty standard for 0xf0000...0x100000 to be marked RESERVED in 
E820 on real hardware (including the system I'm typing on right now.) 
It is so marked to indicate that hardware cannot be mapped into that 
space.  However, you can't rely on this fact -- heck, you can't rely on 
E820 even existing on a real machine.  I have specimens of real-life 
machines that go both ways.

This patch WILL break real hardware.

What's particularly damning is that it's titled "x86/xen: Do not scan 
for DMI unless the DMI region is reserved by e820." whereas in fact it 
changes (breaks) generic code.

	-hpa

>>From 23e4ec12b95064320f83fca1cc1ad5c7b2eb3386 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ijc@hellion.org.uk>
> Date: Tue, 19 Feb 2008 21:57:45 +0000
> Subject: [PATCH] x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> 
> Under Xen the memory at 0xf0000 is regular RAM and so can potentially contain a
> page table and hence cannot be mapped. The e820 map given to guest reflects
> this.
> 
> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
> ---
>  drivers/firmware/dmi_scan.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 653265a..7d29403 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -7,6 +7,7 @@
>  #include <linux/bootmem.h>
>  #include <linux/slab.h>
>  #include <asm/dmi.h>
> +#include <asm/e820.h>
>  
>  static char dmi_empty_string[] = "        ";
>  
> @@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
>  		}
>  	}
>  	else {
> +		if (!e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RESERVED))
> +			goto out;
> +
>  		/*
>  		 * no iounmap() for that ioremap(); it would be a no-op, but
>  		 * it's so early in setup that sucker gets confused into doing

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-20  7:43               ` H. Peter Anvin
@ 2008-02-20  8:51                 ` Ian Campbell
  2008-02-20 21:42                   ` Joel Becker
  2008-02-20 21:58                   ` Jeremy Fitzhardinge
  0 siblings, 2 replies; 46+ messages in thread
From: Ian Campbell @ 2008-02-20  8:51 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Joel Becker, Jeremy Fitzhardinge, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila


On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> > On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> >> On Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:
> > 
> >>> x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> > 
> >> 	This fixed it.  I'm now booting successfully.  Thank you!
> > 
> > Excellent. Jeremy, are you happy for this to go in?
> > 
> 
> NAK!
> 
> It's pretty standard for 0xf0000...0x100000 to be marked RESERVED in 
> E820 on real hardware (including the system I'm typing on right now.) 
> It is so marked to indicate that hardware cannot be mapped into that 
> space.  However, you can't rely on this fact -- heck, you can't rely on 
> E820 even existing on a real machine.  I have specimens of real-life 
> machines that go both ways.
> 
> This patch WILL break real hardware.
> 
> What's particularly damning is that it's titled "x86/xen: Do not scan 
> for DMI unless the DMI region is reserved by e820." whereas in fact it 
> changes (breaks) generic code.

Sorry, I was trying to indicate that it was a generic change which was
motivated by Xen support, but you're right it did look like I was saying
it was a Xen only change.

As far as the actual change goes I was assuming that any machine that
has DMI/SMBIOS would easily be new enough to have an E820 which could be
expected to reserve this region. Looks like I was mistaken about how
long E820 had been around and/or how reliably it is used to reserve the
tables.

Anyway, will have to think of another solution.

Ian.

-- 
Ian Campbell

Just because the message may never be received does not mean it is
not worth sending.


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-20  8:51                 ` Ian Campbell
@ 2008-02-20 21:42                   ` Joel Becker
  2008-02-20 22:30                     ` Ian Campbell
  2008-02-20 21:58                   ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 46+ messages in thread
From: Joel Becker @ 2008-02-20 21:42 UTC (permalink / raw)
  To: Ian Campbell
  Cc: H. Peter Anvin, Jeremy Fitzhardinge, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila

On Wed, Feb 20, 2008 at 08:51:50AM +0000, Ian Campbell wrote:
> 
> On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
> > NAK!
> 
> As far as the actual change goes I was assuming that any machine that
> has DMI/SMBIOS would easily be new enough to have an E820 which could be
> expected to reserve this region. Looks like I was mistaken about how
> long E820 had been around and/or how reliably it is used to reserve the
> tables.
> 
> Anyway, will have to think of another solution.

	What changed to make this not work in the first place?  New dmi
code?

Joel

-- 

"The real reason GNU ls is 8-bit-clean is so that they can
 start using ISO-8859-1 option characters."
	- Christopher Davis (ckd@loiosh.kei.com)

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-20  8:51                 ` Ian Campbell
  2008-02-20 21:42                   ` Joel Becker
@ 2008-02-20 21:58                   ` Jeremy Fitzhardinge
  2008-02-20 22:29                     ` Ian Campbell
  1 sibling, 1 reply; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-20 21:58 UTC (permalink / raw)
  To: Ian Campbell
  Cc: H. Peter Anvin, Joel Becker, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila

Ian Campbell wrote:
> On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
>   
>> Ian Campbell wrote:
>>     
>>> On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
>>>       
>>>> On Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:
>>>>         
>>>>> x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
>>>>>           
>>>> 	This fixed it.  I'm now booting successfully.  Thank you!
>>>>         
>>> Excellent. Jeremy, are you happy for this to go in?
>>>       

I had no problem with it, but Peter's objection seems substantial enough.

> As far as the actual change goes I was assuming that any machine that
> has DMI/SMBIOS would easily be new enough to have an E820 which could be
> expected to reserve this region. Looks like I was mistaken about how
> long E820 had been around and/or how reliably it is used to reserve the
> tables.
>
> Anyway, will have to think of another solution.
>   

Well, the way we've handled this kind of thing elsewhere is to just 
reserve that pseudophys address space in earlish Xen init code and fill 
it with not-DMI things (zero, I guess).  It's a bit of a waste of 
memory, but maybe we can recover it once DMI has given up and gone 
away.  This also makes it easy to insert faked-up DMI info if that turns 
out to be useful.


    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-20 21:58                   ` Jeremy Fitzhardinge
@ 2008-02-20 22:29                     ` Ian Campbell
  2008-02-21 21:16                       ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 46+ messages in thread
From: Ian Campbell @ 2008-02-20 22:29 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: H. Peter Anvin, Joel Becker, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila


On Wed, 2008-02-20 at 13:58 -0800, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > On Tue, 2008-02-19 at 23:43 -0800, H. Peter Anvin wrote:
> >   
> >> Ian Campbell wrote:
> >>     
> >>> On Mon, 2008-02-18 at 02:40 -0800, Joel Becker wrote:
> >>>       
> >>>> On Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:
> >>>>         
> >>>>> x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> >>>>>           
> >>>> 	This fixed it.  I'm now booting successfully.  Thank you!
> >>>>         
> >>> Excellent. Jeremy, are you happy for this to go in?
> >>>       
> 
> I had no problem with it, but Peter's objection seems substantial enough.

Definitely.

> > As far as the actual change goes I was assuming that any machine that
> > has DMI/SMBIOS would easily be new enough to have an E820 which could be
> > expected to reserve this region. Looks like I was mistaken about how
> > long E820 had been around and/or how reliably it is used to reserve the
> > tables.
> >
> > Anyway, will have to think of another solution.
> >   
> 
> Well, the way we've handled this kind of thing elsewhere is to just 
> reserve that pseudophys address space in earlish Xen init code and fill 
> it with not-DMI things (zero, I guess).  It's a bit of a waste of 
> memory, but maybe we can recover it once DMI has given up and gone 
> away.  This also makes it easy to insert faked-up DMI info if that turns 
> out to be useful.

I'll see if I can track down where the page is getting used and have a
go at getting in there first. It must be pretty early to be allocated
already when dmi_scan_machine gets called.

It's possible that the domain builder might have already allocated a PT
at this address. I haven't checked but I think currently the domain
builder always puts PT pages after the kernel so hopefully it's only a
theoretical problem.

Another option I was thinking of was a command line option to disable
DMI, which (maybe) isn't terribly useful in itself but it introduces an
associated variable to frob with. That's similar to how the TSC was
handled in the past (well, the opposite since TSC was forced on).

Ian.
-- 
Ian Campbell

Universe, n.:
	The problem.


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-20 21:42                   ` Joel Becker
@ 2008-02-20 22:30                     ` Ian Campbell
  0 siblings, 0 replies; 46+ messages in thread
From: Ian Campbell @ 2008-02-20 22:30 UTC (permalink / raw)
  To: Joel Becker
  Cc: H. Peter Anvin, Jeremy Fitzhardinge, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila


On Wed, 2008-02-20 at 13:42 -0800, Joel Becker wrote:
> 	What changed to make this not work in the first place?  New dmi
> code?

I don't think so -- this code is present even in the 2.6.18-xen.hg tree
(where it's gated with is_initial_domain() which isn't suitable for the
upstream tree).

I don't really know why it should start happening now. It may be that
some of the recentish changes to e.g. early_ioremap or early pagetable
setup etc. have tweaked the layout of the early pagetables around so
this problem bites us more readily. Or it may just be a combination of
kernel image size, RAM size and perhaps a dose of bad luck.

Ian.
-- 
Ian Campbell

... at least I thought I was dancing, 'til somebody stepped on my hand.
		-- J. B. White


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-20 22:29                     ` Ian Campbell
@ 2008-02-21 21:16                       ` Jeremy Fitzhardinge
  2008-02-21 21:21                         ` H. Peter Anvin
  0 siblings, 1 reply; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-21 21:16 UTC (permalink / raw)
  To: Ian Campbell
  Cc: H. Peter Anvin, Joel Becker, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila

Ian Campbell wrote:
> I'll see if I can track down where the page is getting used and have a
> go at getting in there first. It must be pretty early to be allocated
> already when dmi_scan_machine gets called.
>
> It's possible that the domain builder might have already allocated a PT
> at this address. I haven't checked but I think currently the domain
> builder always puts PT pages after the kernel so hopefully it's only a
> theoretical problem.
>   

Yes, it does.  And presumably the early pagetable builder is guaranteed 
to avoid special memory like the DMI space.  But the bug definitely 
seems to be a result of the DMI code trying to make a RW mapping of a 
pagetable page, so something is amiss there.

Ooh, sleazy hack idea: make DMI always map RO, so even if it does get a 
pagetable it causes no complaint...  A bit awkward, since there doesn't 
seem to be an RO form of early_ioremap.

> Another option I was thinking of was a command line option to disable
> DMI, which (maybe) isn't terribly useful in itself but it introduces an
> associated variable to frob with. That's similar to how the TSC was
> handled in the past (well, the opposite since TSC was forced on).
>   

Yep, that would work too.

Still curious about why a pagetable page is ending up in that range 
though.  Seems like it shouldn't be possible, since we shouldn't be 
allowed to allocate from those pages, at least until the DMI probe has 
happened...  Unless the early allocator is only excluded from e820 
reserved pages, which would cause a problem on systems which don't 
reserve the DMI space...  HPA?

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 21:16                       ` Jeremy Fitzhardinge
@ 2008-02-21 21:21                         ` H. Peter Anvin
  2008-02-21 21:37                           ` Jeremy Fitzhardinge
  2008-02-21 22:04                           ` Eric W. Biederman
  0 siblings, 2 replies; 46+ messages in thread
From: H. Peter Anvin @ 2008-02-21 21:21 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Ian Campbell, Joel Becker, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Eric W. Biederman, Andi Kleen, Mika Penttila

Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
>> I'll see if I can track down where the page is getting used and have a
>> go at getting in there first. It must be pretty early to be allocated
>> already when dmi_scan_machine gets called.
>>
>> It's possible that the domain builder might have already allocated a PT
>> at this address. I haven't checked but I think currently the domain
>> builder always puts PT pages after the kernel so hopefully it's only a
>> theoretical problem.
>>   
> 
> Yes, it does.  And presumably the early pagetable builder is guaranteed 
> to avoid special memory like the DMI space.  But the bug definitely 
> seems to be a result of the DMI code trying to make a RW mapping of a 
> pagetable page, so something is amiss there.
> 
> Ooh, sleazy hack idea: make DMI always map RO, so even if it does get a 
> pagetable it causes no complaint...  A bit awkward, since there doesn't 
> seem to be an RO form of early_ioremap.
> 
>> Another option I was thinking of was a command line option to disable
>> DMI, which (maybe) isn't terribly useful in itself but it introduces an
>> associated variable to frob with. That's similar to how the TSC was
>> handled in the past (well, the opposite since TSC was forced on).
>>   
> 
> Yep, that would work too.
> 
> Still curious about why a pagetable page is ending up in that range 
> though.  Seems like it shouldn't be possible, since we shouldn't be 
> allowed to allocate from those pages, at least until the DMI probe has 
> happened...  Unless the early allocator is only excluded from e820 
> reserved pages, which would cause a problem on systems which don't 
> reserve the DMI space...  HPA?
> 

I thought the problem was a Xen-provided pagetable from before Linux 
started?

	-hpa

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 21:21                         ` H. Peter Anvin
@ 2008-02-21 21:37                           ` Jeremy Fitzhardinge
  2008-02-21 21:44                             ` H. Peter Anvin
  2008-02-21 22:12                             ` Ian Campbell
  2008-02-21 22:04                           ` Eric W. Biederman
  1 sibling, 2 replies; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-21 21:37 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Ian Campbell, Joel Becker, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Eric W. Biederman, Andi Kleen, Mika Penttila

H. Peter Anvin wrote:
>> Still curious about why a pagetable page is ending up in that range 
>> though.  Seems like it shouldn't be possible, since we shouldn't be 
>> allowed to allocate from those pages, at least until the DMI probe 
>> has happened...  Unless the early allocator is only excluded from 
>> e820 reserved pages, which would cause a problem on systems which 
>> don't reserve the DMI space...  HPA?
>>
>
> I thought the problem was a Xen-provided pagetable from before Linux 
> started? 

Hm, I don't think so.  The domain-builder pagetable is put after the 
kernel, so it shouldn't be under 1M.

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 21:37                           ` Jeremy Fitzhardinge
@ 2008-02-21 21:44                             ` H. Peter Anvin
  2008-02-21 22:12                             ` Ian Campbell
  1 sibling, 0 replies; 46+ messages in thread
From: H. Peter Anvin @ 2008-02-21 21:44 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Ian Campbell, Joel Becker, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Eric W. Biederman, Andi Kleen, Mika Penttila

Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>>> Still curious about why a pagetable page is ending up in that range 
>>> though.  Seems like it shouldn't be possible, since we shouldn't be 
>>> allowed to allocate from those pages, at least until the DMI probe 
>>> has happened...  Unless the early allocator is only excluded from 
>>> e820 reserved pages, which would cause a problem on systems which 
>>> don't reserve the DMI space...  HPA?
>>>
>>
>> I thought the problem was a Xen-provided pagetable from before Linux 
>> started? 
> 
> Hm, I don't think so.  The domain-builder pagetable is put after the 
> kernel, so it shouldn't be under 1M.
> 

That's weird, then.  If we put a page table at 0xf0000, it would crash 
hard on real hardware (there is ROM there); as I mentioned, I do have 
hardware which both reserves and doesn't reserve this region.

	-hpa

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 21:21                         ` H. Peter Anvin
  2008-02-21 21:37                           ` Jeremy Fitzhardinge
@ 2008-02-21 22:04                           ` Eric W. Biederman
  2008-02-21 23:14                             ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 46+ messages in thread
From: Eric W. Biederman @ 2008-02-21 22:04 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Jeremy Fitzhardinge, Ian Campbell, Joel Becker, Jody Belka,
	linux-kernel, Ingo Molnar, Thomas Gleixner, Andi Kleen,
	Mika Penttila

"H. Peter Anvin" <hpa@zytor.com> writes:

> Jeremy Fitzhardinge wrote:
>> Ian Campbell wrote:
>>> I'll see if I can track down where the page is getting used and have a
>>> go at getting in there first. It must be pretty early to be allocated
>>> already when dmi_scan_machine gets called.
>>>
>>> It's possible that the domain builder might have already allocated a PT
>>> at this address. I haven't checked but I think currently the domain
>>> builder always puts PT pages after the kernel so hopefully it's only a
>>> theoretical problem.
>>>
>>
>> Yes, it does.  And presumably the early pagetable builder is guaranteed to
>> avoid special memory like the DMI space.  But the bug definitely seems to be a
>> result of the DMI code trying to make a RW mapping of a pagetable page, so
>> something is amiss there.
>>
>> Ooh, sleazy hack idea: make DMI always map RO, so even if it does get a
>> pagetable it causes no complaint...  A bit awkward, since there doesn't seem
>> to be an RO form of early_ioremap.
>>
>>> Another option I was thinking of was a command line option to disable
>>> DMI, which (maybe) isn't terribly useful in itself but it introduces an
>>> associated variable to frob with. That's similar to how the TSC was
>>> handled in the past (well, the opposite since TSC was forced on).
>>>
>>
>> Yep, that would work too.
>>
>> Still curious about why a pagetable page is ending up in that range though.
>> Seems like it shouldn't be possible, since we shouldn't be allowed to allocate
>> from those pages, at least until the DMI probe has happened...  Unless the
>> early allocator is only excluded from e820 reserved pages, which would cause a
>> problem on systems which don't reserve the DMI space...  HPA?
>>
>
> I thought the problem was a Xen-provided pagetable from before Linux started?

The immediate symptom was that we have a page table at the address we
are doing the DMI probe.  Xen does not allow pages tables to be mapped
read-write so early_ioremap get into trouble.

We have a mystery:
- Why did the Xen domain builder or the linux kernel use 0xf0000 - 0x10000
  for a page table.

  It should be possible to instrument the early linux page allocation
  and see what page pages linux is using to see who is doing weird
  things.

We have possible solutions.
- Add a read-only flag to early_ioremap for use by our table scans.
- Don't do a DMI scan in the case of Xen.
- Fix the Xen domain builder.

My inclination is that we disable the fruitless DMI scan in the case
Xen, or we get the Xen domain builder fixed.

If Xen is going to increasingly look like a normal X86 BIOS we should
let the DMI scan run and be put the burden on Xen to keep things
looking like a normal x86 machine.  If Xen is not going to look more
like a normal x86 machine we can say oh, that is nice, it's Xen so
don't bother doing things that will cause problems.

In this case can we confirm that the domain builder is using those
early 64k as pages for a page table, and then educate it that not
allowing OS access to those pages is a little silly.

All of that said.  For DMI tables other early tables we should not
be writing to them anyway so learning to use read-only maps may be
the right solution.  If the reason Xen was complaining was that
we were accessing an area that was not page tables but instead
should only be mapped read-only I would have a lot of sympathy
with that.  As mapping areas that are architecturally ROMs read-write
is silly.

So guys can you please finish the root cause and really see why there
is a page table page at in 64K ROM BIOS area?

Eric

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 21:37                           ` Jeremy Fitzhardinge
  2008-02-21 21:44                             ` H. Peter Anvin
@ 2008-02-21 22:12                             ` Ian Campbell
  2008-02-21 22:23                               ` H. Peter Anvin
  2008-02-21 22:58                               ` Joel Becker
  1 sibling, 2 replies; 46+ messages in thread
From: Ian Campbell @ 2008-02-21 22:12 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: H. Peter Anvin, Joel Becker, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila


On Thu, 2008-02-21 at 13:37 -0800, Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
> >> Still curious about why a pagetable page is ending up in that range 
> >> though.  Seems like it shouldn't be possible, since we shouldn't be 
> >> allowed to allocate from those pages, at least until the DMI probe 
> >> has happened...  Unless the early allocator is only excluded from 
> >> e820 reserved pages, which would cause a problem on systems which 
> >> don't reserve the DMI space...  HPA?
> >>
> >
> > I thought the problem was a Xen-provided pagetable from before Linux 
> > started? 
> 
> Hm, I don't think so.  The domain-builder pagetable is put after the 
> kernel, so it shouldn't be under 1M.

I can confirm that it is Linux which is allocating it. The call path:
        # xm create -c debian-x86_32p-1
        Using config file "/etc/xen/debian-x86_32p-1".
        Started domain debian-1
        xen_alloc_pt_init PFN f0
        Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #68
         [<c02ecb6b>] xen_alloc_pt_init+0x4b/0x60
         [<c02f5e2b>] one_page_table_init+0x8b/0xf0
         [<c02f63df>] paging_init+0x3bf/0x520
         [<c02ee444>] setup_arch+0x2a4/0x410
         [<c02e9a64>] start_kernel+0x64/0x380
         [<c02efd7f>] cpu_detect+0x6f/0xf0
         [<c02ed1a1>] xen_start_kernel+0x2f1/0x310
         =======================
        Entering add_active_range(0, 0, 262144) 0 entries of 256 used
        Zone PFN ranges:
          DMA             0 ->     4096

Ian.
> 
>     J
> 
-- 
Ian Campbell

Why do they call a fast a fast, when it goes so slow?


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 22:12                             ` Ian Campbell
@ 2008-02-21 22:23                               ` H. Peter Anvin
  2008-02-21 22:49                                 ` Jeremy Fitzhardinge
  2008-02-21 22:58                               ` Joel Becker
  1 sibling, 1 reply; 46+ messages in thread
From: H. Peter Anvin @ 2008-02-21 22:23 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Jeremy Fitzhardinge, Joel Becker, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila

Ian Campbell wrote:
> On Thu, 2008-02-21 at 13:37 -0800, Jeremy Fitzhardinge wrote:
>> H. Peter Anvin wrote:
>>>> Still curious about why a pagetable page is ending up in that range 
>>>> though.  Seems like it shouldn't be possible, since we shouldn't be 
>>>> allowed to allocate from those pages, at least until the DMI probe 
>>>> has happened...  Unless the early allocator is only excluded from 
>>>> e820 reserved pages, which would cause a problem on systems which 
>>>> don't reserve the DMI space...  HPA?
>>>>
>>> I thought the problem was a Xen-provided pagetable from before Linux 
>>> started? 
>> Hm, I don't think so.  The domain-builder pagetable is put after the 
>> kernel, so it shouldn't be under 1M.
> 
> I can confirm that it is Linux which is allocating it. The call path:
>         # xm create -c debian-x86_32p-1
>         Using config file "/etc/xen/debian-x86_32p-1".
>         Started domain debian-1
>         xen_alloc_pt_init PFN f0
>         Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #68
>          [<c02ecb6b>] xen_alloc_pt_init+0x4b/0x60
>          [<c02f5e2b>] one_page_table_init+0x8b/0xf0
>          [<c02f63df>] paging_init+0x3bf/0x520
>          [<c02ee444>] setup_arch+0x2a4/0x410
>          [<c02e9a64>] start_kernel+0x64/0x380
>          [<c02efd7f>] cpu_detect+0x6f/0xf0
>          [<c02ed1a1>] xen_start_kernel+0x2f1/0x310
>          =======================
>         Entering add_active_range(0, 0, 262144) 0 entries of 256 used
>         Zone PFN ranges:
>           DMA             0 ->     4096
> 

What is the e820 information you feed the kernel?  We should only ever 
allocate page tables out of available RAM, not any other type of memory 
(reserved or not).

	-hpa

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 22:23                               ` H. Peter Anvin
@ 2008-02-21 22:49                                 ` Jeremy Fitzhardinge
  2008-02-21 22:58                                   ` H. Peter Anvin
  0 siblings, 1 reply; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-21 22:49 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Ian Campbell, Joel Becker, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Eric W. Biederman, Andi Kleen, Mika Penttila

H. Peter Anvin wrote:
> Ian Campbell wrote:
>> On Thu, 2008-02-21 at 13:37 -0800, Jeremy Fitzhardinge wrote:
>>> H. Peter Anvin wrote:
>>>>> Still curious about why a pagetable page is ending up in that 
>>>>> range though.  Seems like it shouldn't be possible, since we 
>>>>> shouldn't be allowed to allocate from those pages, at least until 
>>>>> the DMI probe has happened...  Unless the early allocator is only 
>>>>> excluded from e820 reserved pages, which would cause a problem on 
>>>>> systems which don't reserve the DMI space...  HPA?
>>>>>
>>>> I thought the problem was a Xen-provided pagetable from before 
>>>> Linux started? 
>>> Hm, I don't think so.  The domain-builder pagetable is put after the 
>>> kernel, so it shouldn't be under 1M.
>>
>> I can confirm that it is Linux which is allocating it. The call path:
>>         # xm create -c debian-x86_32p-1
>>         Using config file "/etc/xen/debian-x86_32p-1".
>>         Started domain debian-1
>>         xen_alloc_pt_init PFN f0
>>         Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #68
>>          [<c02ecb6b>] xen_alloc_pt_init+0x4b/0x60
>>          [<c02f5e2b>] one_page_table_init+0x8b/0xf0
>>          [<c02f63df>] paging_init+0x3bf/0x520
>>          [<c02ee444>] setup_arch+0x2a4/0x410
>>          [<c02e9a64>] start_kernel+0x64/0x380
>>          [<c02efd7f>] cpu_detect+0x6f/0xf0
>>          [<c02ed1a1>] xen_start_kernel+0x2f1/0x310
>>          =======================
>>         Entering add_active_range(0, 0, 262144) 0 entries of 256 used
>>         Zone PFN ranges:
>>           DMA             0 ->     4096
>>
>
> What is the e820 information you feed the kernel?  We should only ever 
> allocate page tables out of available RAM, not any other type of 
> memory (reserved or not). 

The kernel gets a flat memory map; all memory is just plain RAM.  The 
problem is that we're allocating a normal page and turning it into a 
pagetable - so far so good.  Then the DMI code is randomly mapping that 
same page RW so it can scan it for DMI signatures, which Xen is preventing.

There are two immediate fixes:

   1. Only scan for DMI if the memory is reserved (rejected, because HPA
      says some machines don't reserve the DMI space).  Alternatively,
      don't bother scanning if booting under Xen.
   2. Make DMI map the memory RO so that Xen doesn't complain (which is
      sensible because DMI is ROM anyway).

But as far as I can tell, this shouldn't be happening anyway, and could 
happen on real hardware which doesn't reserve the DMI space.  It 
probably doesn't because initial pagetables on real hardware use large 
pages, and therefore allocate less memory for pagetable memory and 
therefore doesn't end up hitting the 0xf0000 region.  But that area 
should be excluded from the allocation pool.

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 22:12                             ` Ian Campbell
  2008-02-21 22:23                               ` H. Peter Anvin
@ 2008-02-21 22:58                               ` Joel Becker
  1 sibling, 0 replies; 46+ messages in thread
From: Joel Becker @ 2008-02-21 22:58 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Jeremy Fitzhardinge, H. Peter Anvin, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila

On Thu, Feb 21, 2008 at 10:12:36PM +0000, Ian Campbell wrote:
> 
> On Thu, 2008-02-21 at 13:37 -0800, Jeremy Fitzhardinge wrote:
> > H. Peter Anvin wrote:
> > >> Still curious about why a pagetable page is ending up in that range 
> > >> though.  Seems like it shouldn't be possible, since we shouldn't be 
> > >> allowed to allocate from those pages, at least until the DMI probe 
> > >> has happened...  Unless the early allocator is only excluded from 
> > >> e820 reserved pages, which would cause a problem on systems which 
> > >> don't reserve the DMI space...  HPA?
> > >>
> > >
> > > I thought the problem was a Xen-provided pagetable from before Linux 
> > > started? 
> > 
> > Hm, I don't think so.  The domain-builder pagetable is put after the 
> > kernel, so it shouldn't be under 1M.
> 
> I can confirm that it is Linux which is allocating it. The call path:

	Also, I have older kernels (2.6.24-rc era) that run Just Fine.
I haven't changed my dom0 at all.

Joel

-- 

"There is no more evil thing on earth than race prejudice, none at 
 all.  I write deliberately -- it is the worst single thing in life 
 now.  It justifies and holds together more baseness, cruelty and
 abomination than any other sort of error in the world." 
        - H. G. Wells

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 22:49                                 ` Jeremy Fitzhardinge
@ 2008-02-21 22:58                                   ` H. Peter Anvin
  2008-02-22  7:25                                     ` Ian Campbell
  0 siblings, 1 reply; 46+ messages in thread
From: H. Peter Anvin @ 2008-02-21 22:58 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Ian Campbell, Joel Becker, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Eric W. Biederman, Andi Kleen, Mika Penttila

Jeremy Fitzhardinge wrote:
>>
>> What is the e820 information you feed the kernel?  We should only ever 
>> allocate page tables out of available RAM, not any other type of 
>> memory (reserved or not). 
> 
> The kernel gets a flat memory map; all memory is just plain RAM.  The 
> problem is that we're allocating a normal page and turning it into a 
> pagetable - so far so good.  Then the DMI code is randomly mapping that 
> same page RW so it can scan it for DMI signatures, which Xen is preventing.
> 
> There are two immediate fixes:
> 
>   1. Only scan for DMI if the memory is reserved (rejected, because HPA
>      says some machines don't reserve the DMI space).  Alternatively,
>      don't bother scanning if booting under Xen.
>   2. Make DMI map the memory RO so that Xen doesn't complain (which is
>      sensible because DMI is ROM anyway).
> 
> But as far as I can tell, this shouldn't be happening anyway, and could 
> happen on real hardware which doesn't reserve the DMI space.  It 
> probably doesn't because initial pagetables on real hardware use large 
> pages, and therefore allocate less memory for pagetable memory and 
> therefore doesn't end up hitting the 0xf0000 region.  But that area 
> should be excluded from the allocation pool.
> 

Which it is on real hardware, because although it's not *reserved* (type 
2), it is certainly not made available as *normal memory* (type 1).  If 
Xen maps this as type 1 then I definitely see the problem.

We can exclude type 1 memory from DMI scan, certainly.

However, Xen may want to consider why provide memory below the 1 MB 
point at all, and certainly whether it's wise to provide RAM in the 
640-1024 KB legacy region -- although you could argue that "it *should* 
work", odds are pretty good you'll have nasty surprises on a regular basis.

	-hpa


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 22:04                           ` Eric W. Biederman
@ 2008-02-21 23:14                             ` Jeremy Fitzhardinge
  2008-02-21 23:26                               ` H. Peter Anvin
  0 siblings, 1 reply; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-21 23:14 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: H. Peter Anvin, Ian Campbell, Joel Becker, Jody Belka,
	linux-kernel, Ingo Molnar, Thomas Gleixner, Andi Kleen,
	Mika Penttila

Eric W. Biederman wrote:
>> I thought the problem was a Xen-provided pagetable from before Linux started?
>>     
>
> The immediate symptom was that we have a page table at the address we
> are doing the DMI probe.  Xen does not allow pages tables to be mapped
> read-write so early_ioremap get into trouble.
>   

Correct.

> We have a mystery:
> - Why did the Xen domain builder or the linux kernel use 0xf0000 - 0x10000
>   for a page table.
>   

It didn't.  Ian confirmed the allocation comes from the kernel's 
pagetable setup.  The domain builder always puts pagetables after the 
kernel, so over 1M.

>   It should be possible to instrument the early linux page allocation
>   and see what page pages linux is using to see who is doing weird
>   things.
>   

Linux.  Which suggests a latent bug.

> We have possible solutions.
> - Add a read-only flag to early_ioremap for use by our table scans.
> - Don't do a DMI scan in the case of Xen.
> - Fix the Xen domain builder.
>   

1 or 2.  3 is not a problem.

> All of that said.  For DMI tables other early tables we should not
> be writing to them anyway so learning to use read-only maps may be
> the right solution.  If the reason Xen was complaining was that
> we were accessing an area that was not page tables but instead
> should only be mapped read-only I would have a lot of sympathy
> with that.  As mapping areas that are architecturally ROMs read-write
> is silly.
>   

For PV guests, Xen itself isn't really interested in any of the platform 
bios/hardware (not even acknowledging its existence, let alone emulate 
anything).  Definitely no magic memory ranges or scanning for 
signatures.  The in-kernel Xen support has made some concessions to that 
sort of stuff, by making sure various memory ranges are valid to be 
scanned, even if they don't contain anything meaningful.  We could do 
something like that for DMI if that turns out to be the best answer.

> So guys can you please finish the root cause and really see why there
> is a page table page at in 64K ROM BIOS area?
>   

It seems to me that those pages are being handed out as heap pages by 
the early allocator.  In the Xen case this is OK because there's nothing 
magic about them.  But if real hardware doesn't reserve these pages in 
the E820 map, then they could end up being used as regular memory by 
mistake, which is an issue.

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 23:14                             ` Jeremy Fitzhardinge
@ 2008-02-21 23:26                               ` H. Peter Anvin
  2008-02-21 23:46                                 ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 46+ messages in thread
From: H. Peter Anvin @ 2008-02-21 23:26 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Eric W. Biederman, Ian Campbell, Joel Becker, Jody Belka,
	linux-kernel, Ingo Molnar, Thomas Gleixner, Andi Kleen,
	Mika Penttila

Jeremy Fitzhardinge wrote:
> 
> It seems to me that those pages are being handed out as heap pages by 
> the early allocator.  In the Xen case this is OK because there's nothing 
> magic about them.  But if real hardware doesn't reserve these pages in 
> the E820 map, then they could end up being used as regular memory by 
> mistake, which is an issue.
> 

No, they couldn't.

On real hardware they'll be memory types 0 or 2, depending on whether or 
not they're marked reserved.

Available RAM is type 1.

	-hpa

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 23:26                               ` H. Peter Anvin
@ 2008-02-21 23:46                                 ` Jeremy Fitzhardinge
  2008-02-21 23:57                                   ` H. Peter Anvin
  0 siblings, 1 reply; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-21 23:46 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Eric W. Biederman, Ian Campbell, Joel Becker, Jody Belka,
	linux-kernel, Ingo Molnar, Thomas Gleixner, Andi Kleen,
	Mika Penttila

H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>>
>> It seems to me that those pages are being handed out as heap pages by 
>> the early allocator.  In the Xen case this is OK because there's 
>> nothing magic about them.  But if real hardware doesn't reserve these 
>> pages in the E820 map, then they could end up being used as regular 
>> memory by mistake, which is an issue.
>>
>
> No, they couldn't.
>
> On real hardware they'll be memory types 0 or 2, depending on whether 
> or not they're marked reserved.
>
> Available RAM is type 1. 

OK.  Well, perhaps Ian's patch could be amended to test to see if the 
e820 map marks the ISA ROM region as normal RAM, and skip it if so?

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 23:46                                 ` Jeremy Fitzhardinge
@ 2008-02-21 23:57                                   ` H. Peter Anvin
  0 siblings, 0 replies; 46+ messages in thread
From: H. Peter Anvin @ 2008-02-21 23:57 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Eric W. Biederman, Ian Campbell, Joel Becker, Jody Belka,
	linux-kernel, Ingo Molnar, Thomas Gleixner, Andi Kleen,
	Mika Penttila

Jeremy Fitzhardinge wrote:
>>
>> Available RAM is type 1. 
> 
> OK.  Well, perhaps Ian's patch could be amended to test to see if the 
> e820 map marks the ISA ROM region as normal RAM, and skip it if so?
> 

That would work, at least for this particular case.  I expect you'll
have a neverending list of similar issues.

	-hpa

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-21 22:58                                   ` H. Peter Anvin
@ 2008-02-22  7:25                                     ` Ian Campbell
  2008-02-22  9:28                                       ` Alan Cox
  2008-02-26 17:06                                       ` Mark McLoughlin
  0 siblings, 2 replies; 46+ messages in thread
From: Ian Campbell @ 2008-02-22  7:25 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Jeremy Fitzhardinge, Joel Becker, Jody Belka, linux-kernel,
	Ingo Molnar, Thomas Gleixner, Eric W. Biederman, Andi Kleen,
	Mika Penttila


On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote:
> 
> Which it is on real hardware, because although it's not *reserved*
> (type 2), it is certainly not made available as *normal memory* (type
> 1).  If Xen maps this as type 1 then I definitely see the problem.
> 
> We can exclude type 1 memory from DMI scan, certainly.

I'd been meaning to ask this. So the machines you have which don't
describe 0xf0000 as reserved also don't describe it as RAM? (I guess
it's either a hole in the table or one of the other e820 types).

So it sounds like it would be acceptable to simply invert the test in my
original patch as below? (actually reverting to my original-original
patch which I never sent out because checking for reserved sounded more
correct at the time, which was dumb of me because I was well aware of
the other possible types, I must have been having one of those days).

Ian.

>From 13bdb4ee9d80b83a81c3dbefa52464e511d1b4df Mon Sep 17 00:00:00 2001
From: Ian Campbell <ijc@hellion.org.uk>
Date: Fri, 22 Feb 2008 07:17:14 +0000
Subject: [PATCH] x86: Do not scan for DMI if the DMI region is marked as RAM by e820.

Under Xen the memory at 0xf0000 is regular RAM and so can potentially contain a
page table and hence cannot be mapped. The e820 map given to guest reflects
this.

Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
---
 drivers/firmware/dmi_scan.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 653265a..f8fde74 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -7,6 +7,7 @@
 #include <linux/bootmem.h>
 #include <linux/slab.h>
 #include <asm/dmi.h>
+#include <asm/e820.h>
 
 static char dmi_empty_string[] = "        ";
 
@@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
 		}
 	}
 	else {
+		if (e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RAM))
+			goto out;
+
 		/*
 		 * no iounmap() for that ioremap(); it would be a no-op, but
 		 * it's so early in setup that sucker gets confused into doing
-- 
1.5.4.2



-- 
Ian Campbell

Stupidity, like virtue, is its own reward.


^ permalink raw reply related	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-22  7:25                                     ` Ian Campbell
@ 2008-02-22  9:28                                       ` Alan Cox
  2008-02-22  9:55                                         ` Andi Kleen
  2008-02-26 17:06                                       ` Mark McLoughlin
  1 sibling, 1 reply; 46+ messages in thread
From: Alan Cox @ 2008-02-22  9:28 UTC (permalink / raw)
  To: Ian Campbell
  Cc: H. Peter Anvin, Jeremy Fitzhardinge, Joel Becker, Jody Belka,
	linux-kernel, Ingo Molnar, Thomas Gleixner, Eric W. Biederman,
	Andi Kleen, Mika Penttila

> I'd been meaning to ask this. So the machines you have which don't
> describe 0xf0000 as reserved also don't describe it as RAM? (I guess
> it's either a hole in the table or one of the other e820 types).

Making 0xf0000 bus addresses RAM is probably a bad idea anyway. Most OS's
treat the E820 map with paranoia because we do see real PCs which
variously claim that the BIOS ROM space is RAM, ACPI, Reserved or just
forget to mention it. At least for a non PV guest it should be mapped as
R/O.

Likewise you get E820 maps with zero size entries, repeated entries ...


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-22  9:28                                       ` Alan Cox
@ 2008-02-22  9:55                                         ` Andi Kleen
  2008-02-22 10:00                                           ` Alan Cox
  0 siblings, 1 reply; 46+ messages in thread
From: Andi Kleen @ 2008-02-22  9:55 UTC (permalink / raw)
  To: Alan Cox
  Cc: Ian Campbell, H. Peter Anvin, Jeremy Fitzhardinge, Joel Becker,
	Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Eric W. Biederman, Mika Penttila

Alan Cox wrote:
>> I'd been meaning to ask this. So the machines you have which don't
>> describe 0xf0000 as reserved also don't describe it as RAM? (I guess
>> it's either a hole in the table or one of the other e820 types).
> 
> Making 0xf0000 bus addresses RAM is probably a bad idea anyway. Most OS's
> treat the E820 map with paranoia because we do see real PCs which
> variously claim that the BIOS ROM space is RAM, ACPI, Reserved or just
> forget to mention it. 

Actually I switched 64bit over to trust e820 completely and not
reserve 640k-1MB explicitly some time ago
and AFAIK there hasn't been any reports that it causes problems.

So presumably trusting e802 is ok on modern systems (2003+)

-Andi

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-22  9:55                                         ` Andi Kleen
@ 2008-02-22 10:00                                           ` Alan Cox
  2008-02-22 10:15                                             ` Andi Kleen
  0 siblings, 1 reply; 46+ messages in thread
From: Alan Cox @ 2008-02-22 10:00 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Ian Campbell, H. Peter Anvin, Jeremy Fitzhardinge, Joel Becker,
	Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Eric W. Biederman, Mika Penttila

> Actually I switched 64bit over to trust e820 completely and not
> reserve 640k-1MB explicitly some time ago
> and AFAIK there hasn't been any reports that it causes problems.
> 
> So presumably trusting e802 is ok on modern systems (2003+)

Apparently so - at least 64bit capable ones. We do still sort the entries
to remove zero length records and other suprises.

Alan

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-22 10:00                                           ` Alan Cox
@ 2008-02-22 10:15                                             ` Andi Kleen
  2008-02-22 16:27                                               ` H. Peter Anvin
  2008-02-22 19:25                                               ` Pavel Machek
  0 siblings, 2 replies; 46+ messages in thread
From: Andi Kleen @ 2008-02-22 10:15 UTC (permalink / raw)
  To: Alan Cox
  Cc: Ian Campbell, H. Peter Anvin, Jeremy Fitzhardinge, Joel Becker,
	Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Eric W. Biederman, Mika Penttila

Alan Cox wrote:
>> Actually I switched 64bit over to trust e820 completely and not
>> reserve 640k-1MB explicitly some time ago
>> and AFAIK there hasn't been any reports that it causes problems.
>>
>> So presumably trusting e802 is ok on modern systems (2003+)
> 
> Apparently so - at least 64bit capable ones. 

They should all use the same BIOS code bases, except perhaps
some embedded weirdnesses.

We do still sort the entries
> to remove zero length records and other suprises.

That code could be actually dropped. And the sorting too.
It's all not needed I think.

AFAIK none of the e820 access code cares about any of
that.

64bit only has it because I copied it originally and never
bothered to remove it.

-Andi


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-22 10:15                                             ` Andi Kleen
@ 2008-02-22 16:27                                               ` H. Peter Anvin
  2008-02-22 19:25                                               ` Pavel Machek
  1 sibling, 0 replies; 46+ messages in thread
From: H. Peter Anvin @ 2008-02-22 16:27 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Alan Cox, Ian Campbell, Jeremy Fitzhardinge, Joel Becker,
	Jody Belka, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Eric W. Biederman, Mika Penttila

Andi Kleen wrote:
> Alan Cox wrote:
>>> Actually I switched 64bit over to trust e820 completely and not
>>> reserve 640k-1MB explicitly some time ago
>>> and AFAIK there hasn't been any reports that it causes problems.
>>>
>>> So presumably trusting e802 is ok on modern systems (2003+)
>> Apparently so - at least 64bit capable ones. 
> 
> They should all use the same BIOS code bases, except perhaps
> some embedded weirdnesses.

Well, that, plus you still have to deal with a lot older stuff.

> We do still sort the entries
>> to remove zero length records and other suprises.
> 
> That code could be actually dropped. And the sorting too.
> It's all not needed I think.

When I dealt with this for another project, I found that the e820 data 
format is suboptimal.  It's better to treat it as a sorted list of 
(address, type) tuples (where type can be zero); the data from e820 can 
be fed into such a data structure and it cleans it up nicely.

	-hpa

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-22 10:15                                             ` Andi Kleen
  2008-02-22 16:27                                               ` H. Peter Anvin
@ 2008-02-22 19:25                                               ` Pavel Machek
  1 sibling, 0 replies; 46+ messages in thread
From: Pavel Machek @ 2008-02-22 19:25 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Alan Cox, Ian Campbell, H. Peter Anvin, Jeremy Fitzhardinge,
	Joel Becker, Jody Belka, linux-kernel, Ingo Molnar,
	Thomas Gleixner, Eric W. Biederman, Mika Penttila

On Fri 2008-02-22 11:15:59, Andi Kleen wrote:
> Alan Cox wrote:
> >> Actually I switched 64bit over to trust e820 completely and not
> >> reserve 640k-1MB explicitly some time ago
> >> and AFAIK there hasn't been any reports that it causes problems.
> >>
> >> So presumably trusting e802 is ok on modern systems (2003+)
> > 
> > Apparently so - at least 64bit capable ones. 
> 
> They should all use the same BIOS code bases, except perhaps

At least kohjinsha subnotebook has very 'interesting' bios. Very new,
but geode -> not 64bit.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-22  7:25                                     ` Ian Campbell
  2008-02-22  9:28                                       ` Alan Cox
@ 2008-02-26 17:06                                       ` Mark McLoughlin
  2008-02-26 20:05                                         ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 46+ messages in thread
From: Mark McLoughlin @ 2008-02-26 17:06 UTC (permalink / raw)
  To: Ian Campbell
  Cc: H. Peter Anvin, Jeremy Fitzhardinge, Joel Becker, Jody Belka,
	linux-kernel, Ingo Molnar, Thomas Gleixner, Eric W. Biederman,
	Andi Kleen, Mika Penttila

On Fri, 2008-02-22 at 07:25 +0000, Ian Campbell wrote:
> On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote:
> > 
> > Which it is on real hardware, because although it's not *reserved*
> > (type 2), it is certainly not made available as *normal memory* (type
> > 1).  If Xen maps this as type 1 then I definitely see the problem.
> > 
> > We can exclude type 1 memory from DMI scan, certainly.
> 
> I'd been meaning to ask this. So the machines you have which don't
> describe 0xf0000 as reserved also don't describe it as RAM? (I guess
> it's either a hole in the table or one of the other e820 types).
> Ian.

...

> >From 13bdb4ee9d80b83a81c3dbefa52464e511d1b4df Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ijc@hellion.org.uk>
> Date: Fri, 22 Feb 2008 07:17:14 +0000
> Subject: [PATCH] x86: Do not scan for DMI if the DMI region is marked as RAM by e820.
> 
> Under Xen the memory at 0xf0000 is regular RAM and so can potentially contain a
> page table and hence cannot be mapped. The e820 map given to guest reflects
> this.
> 
> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>

...

> @@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
>  		}
>  	}
>  	else {
> +		if (e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RAM))
> +			goto out;

	One issue with using the e820 map for this is that a Xen Dom0 will also
have this region marked as RAM in the e820 map, but will set up a fixmap
for it, allowing dmi_scan_machine() to map the region.

Cheers,
Mark.


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: 2.6.25-rc1 xen pvops regression
  2008-02-26 17:06                                       ` Mark McLoughlin
@ 2008-02-26 20:05                                         ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 46+ messages in thread
From: Jeremy Fitzhardinge @ 2008-02-26 20:05 UTC (permalink / raw)
  To: Mark McLoughlin
  Cc: Ian Campbell, H. Peter Anvin, Joel Becker, Jody Belka,
	linux-kernel, Ingo Molnar, Thomas Gleixner, Eric W. Biederman,
	Andi Kleen, Mika Penttila

Mark McLoughlin wrote:
>> @@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
>>  		}
>>  	}
>>  	else {
>> +		if (e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RAM))
>> +			goto out;
>>     
>
> 	One issue with using the e820 map for this is that a Xen Dom0 will also
> have this region marked as RAM in the e820 map, but will set up a fixmap
> for it, allowing dmi_scan_machine() to map the region.
>   

Would it be easier to just fake up a mapping so that window points to 
the real dmi area, and mark E820 accordingly?

    J

^ permalink raw reply	[flat|nested] 46+ messages in thread

end of thread, other threads:[~2008-02-26 20:09 UTC | newest]

Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-12 23:54 2.6.25-rc1 xen pvops regression Jody Belka
2008-02-13 11:59 ` Jeremy Fitzhardinge
2008-02-13 12:13   ` Jody Belka
2008-02-13 12:23   ` Ingo Molnar
2008-02-14  2:27   ` Joel Becker
2008-02-14  7:50     ` Jeremy Fitzhardinge
2008-02-15 20:23       ` Joel Becker
2008-02-16  2:44         ` Jeremy Fitzhardinge
2008-02-16  8:54           ` Joel Becker
2008-02-16 11:46             ` Jeremy Fitzhardinge
2008-02-17  6:29               ` Joel Becker
2008-02-17 12:09                 ` Jeremy Fitzhardinge
2008-02-17  6:39               ` Joel Becker
2008-02-17 18:49         ` Ian Campbell
2008-02-18 10:40           ` Joel Becker
2008-02-19 21:50             ` Ian Campbell
2008-02-19 21:59             ` Ian Campbell
2008-02-20  7:43               ` H. Peter Anvin
2008-02-20  8:51                 ` Ian Campbell
2008-02-20 21:42                   ` Joel Becker
2008-02-20 22:30                     ` Ian Campbell
2008-02-20 21:58                   ` Jeremy Fitzhardinge
2008-02-20 22:29                     ` Ian Campbell
2008-02-21 21:16                       ` Jeremy Fitzhardinge
2008-02-21 21:21                         ` H. Peter Anvin
2008-02-21 21:37                           ` Jeremy Fitzhardinge
2008-02-21 21:44                             ` H. Peter Anvin
2008-02-21 22:12                             ` Ian Campbell
2008-02-21 22:23                               ` H. Peter Anvin
2008-02-21 22:49                                 ` Jeremy Fitzhardinge
2008-02-21 22:58                                   ` H. Peter Anvin
2008-02-22  7:25                                     ` Ian Campbell
2008-02-22  9:28                                       ` Alan Cox
2008-02-22  9:55                                         ` Andi Kleen
2008-02-22 10:00                                           ` Alan Cox
2008-02-22 10:15                                             ` Andi Kleen
2008-02-22 16:27                                               ` H. Peter Anvin
2008-02-22 19:25                                               ` Pavel Machek
2008-02-26 17:06                                       ` Mark McLoughlin
2008-02-26 20:05                                         ` Jeremy Fitzhardinge
2008-02-21 22:58                               ` Joel Becker
2008-02-21 22:04                           ` Eric W. Biederman
2008-02-21 23:14                             ` Jeremy Fitzhardinge
2008-02-21 23:26                               ` H. Peter Anvin
2008-02-21 23:46                                 ` Jeremy Fitzhardinge
2008-02-21 23:57                                   ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).