Bug 8801
Summary: | 2.6.21.5: kernel BUG at arch/i386/mm/highmem.c:38! - HP Proliant 110 | ||
---|---|---|---|
Product: | Memory Management | Reporter: | Szabolcs Toth (totya) |
Component: | Page Allocator | Assignee: | Andrew Morton (akpm) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | high | CC: | acpi-bugzilla |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.21.5 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
The bug and the booting procedure
Cpu info IOMEM Kernel configuration lspci info Software information |
Description
Szabolcs Toth
2007-07-24 01:54:27 UTC
Created attachment 12112 [details]
The bug and the booting procedure
The attachment show the bug and the bootping procedure
I use this kernel on machine which have really two CPU or two CPU core, but there I didn't see that kind of problem. I have seen this problem only on machine which worked with Hyperthread only. Created attachment 12113 [details]
Cpu info
Created attachment 12114 [details]
IOMEM
Created attachment 12115 [details]
Kernel configuration
Created attachment 12116 [details]
lspci info
Created attachment 12117 [details]
Software information
> Most recent kernel where this bug did not occur: 2.6.21.5 but your dmesg shows the failure in 2.6.21.5 What release does _not_have the issue? did 2.6.20.stable work, does 2.6.22? > Kernel command line: ... acpi=ht This doesn't appear to be a bug in ACPI, as "acpi=ht" effectively disables ACPI. And I'm curious why you are running with ACPI disabled, is there a reason? Sort of unusual to see these disabled on a modern machine: # CONFIG_ACPI_BUTTON is not set # CONFIG_ACPI_PROCESSOR is not set > I have seen this problem only on machine which worked with Hyperthread only. Does this problem go away when you disable HT in the BIOS, or when you boot with "maxcpus=1"? > kernel BUG at arch/i386/mm/highmem.c:38! This doesn't looks like an ACPI/interrupt issue, but rather a memory management issue.... /* * kmap_atomic/kunmap_atomic is significantly faster than kmap/kunmap because * no global lock is needed and because the kmap code must perform a global TLB * invalidation when the kmap pool wraps. * * However when holding an atomic kmap is is not legal to sleep, so atomic * kmaps are appropriate for short, tight code paths only. */ void *kmap_atomic(struct page *page, enum km_type type) { enum fixed_addresses idx; unsigned long vaddr; /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */ pagefault_disable(); idx = type + KM_TYPE_NR*smp_processor_id(); 38: BUG_ON(!pte_none(*(kmap_pte-idx))); |