Although 2.5.40 has been out for a while, I think I ought
to post this bug as I haven't seen any other mention of it.
When I boot an 2.5.40 x86 kernel built with CONFIG_HIGHMEM64G,
and with a 920kB initial ramdisk (2.2MB uncompressed), I get a kernel
BUG() at highmem.c line 480, preceded by a message saying "scheduling
with KM_TYPE 15 held!" The machine on which I experienced this
problem has 1.25GB of RAM. The problem occurs with and without
CONFIG_PREEMPT. All kernels that tried were SMP kernels running on a
uniprocessor.
The problem does not occur if I build 2.5.40 with
CONFIG_HIGHMEM4G or CONFIG_NOHIGMEM. So, it's probably not causing
problems for many people, but I thought I should report it anyhow.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Mon, 7 Oct 2002, Adam J. Richter wrote:
> Although 2.5.40 has been out for a while, I think I ought
> to post this bug as I haven't seen any other mention of it.
>
> When I boot an 2.5.40 x86 kernel built with CONFIG_HIGHMEM64G,
> and with a 920kB initial ramdisk (2.2MB uncompressed), I get a kernel
> BUG() at highmem.c line 480, preceded by a message saying "scheduling
> with KM_TYPE 15 held!" The machine on which I experienced this
> problem has 1.25GB of RAM. The problem occurs with and without
> CONFIG_PREEMPT. All kernels that tried were SMP kernels running on a
> uniprocessor.
>
> The problem does not occur if I build 2.5.40 with
> CONFIG_HIGHMEM4G or CONFIG_NOHIGMEM. So, it's probably not causing
> problems for many people, but I thought I should report it anyhow.
Does the accompanying trace output say BUG(), or is there a might_sleep()
in the trace output? In other words, is it a scheduling while holding a
lock kind of thing?
On 2002-10-08 0:48:32, Thomas Molina wrote:
>On Mon, 7 Oct 2002, Adam J. Richter wrote:
>
>> Although 2.5.40 has been out for a while, I think I ought
>> to post this bug as I haven't seen any other mention of it.
>>
>> When I boot an 2.5.40 x86 kernel built with CONFIG_HIGHMEM64G,
>> and with a 920kB initial ramdisk (2.2MB uncompressed), I get a kernel
>> BUG() at highmem.c line 480, preceded by a message saying "scheduling
>> with KM_TYPE 15 held!" The machine on which I experienced this
>> problem has 1.25GB of RAM. The problem occurs with and without
>> CONFIG_PREEMPT. All kernels that tried were SMP kernels running on a
>> uniprocessor.
>>
>> The problem does not occur if I build 2.5.40 with
>> CONFIG_HIGHMEM4G or CONFIG_NOHIGMEM. So, it's probably not causing
>> problems for many people, but I thought I should report it anyhow.
>
>Does the accompanying trace output say BUG(), or is there a might_sleep()
>in the trace output? In other words, is it a scheduling while holding a
>lock kind of thing?
It is the BUG() statement in check_highmem_ptes in mm/highmem.c:
#if CONFIG_DEBUG_HIGHMEM
void check_highmem_ptes(void)
{
int idx, type;
preempt_disable();
for (type = 0; type < KM_TYPE_NR; type++) {
idx = type + KM_TYPE_NR*smp_processor_id();
if (!pte_none(*(kmap_pte-idx))) {
printk("scheduling with KM_TYPE %d held!\n", type);
BUG();
}
}
preempt_enable();
}
#endif
I'm updating to 2.5.41 and will post a trace if the problem
still occurs.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Mon, Oct 07, 2002 at 06:27:19AM -0700, Adam J. Richter wrote:
> Although 2.5.40 has been out for a while, I think I ought
> to post this bug as I haven't seen any other mention of it.
> When I boot an 2.5.40 x86 kernel built with CONFIG_HIGHMEM64G,
> and with a 920kB initial ramdisk (2.2MB uncompressed), I get a kernel
> BUG() at highmem.c line 480, preceded by a message saying "scheduling
> with KM_TYPE 15 held!" The machine on which I experienced this
> problem has 1.25GB of RAM. The problem occurs with and without
> CONFIG_PREEMPT. All kernels that tried were SMP kernels running on a
> uniprocessor.
This is not reproducible here with 2.5.52-mm2. Is the initrd required
to trigger this?
Thanks,
Bill
At some point in the past, I wrote:
>> This is not reproducible here with 2.5.52-mm2. Is the initrd required
>> to trigger this?
On Sat, Dec 21, 2002 at 01:43:20AM -0800, Adam J. Richter wrote:
> Yes, the initrd seems to be required. It happens when
> the initrd attempts to mount /proc (it runs a shell script that
> starts by setting PATH, mounting /dev, and mounting /proc).
> I've verified that under 2.5.52 the problem occurs with
> CONFIG_HIGHME64G and not with CONFIG_HIGHMEM4G. Actually, now the
> problem is a BUG() at slab.c:1451, which is also memory corruption,
> and I suspect just an evolution of the same problem from 2.5.40.
> Anyhow, in case it helps you, I've put the vmlinux and initrd
> that produce this problem in
> ftp://ftp.yggdrasil.com/private/adam/for-wli/. Note that the ramdisk
> has kernel modules that don't match the kernel but that's not the
> issue, as I configured that kernel to have a different version name.
> Thanks for your attention to this problem.
I'll take it for a spin sometime in the next 6-12 hours.
Bill
>> Although 2.5.40 has been out for a while, I think I ought
>> to post this bug as I haven't seen any other mention of it.
>> When I boot an 2.5.40 x86 kernel built with CONFIG_HIGHMEM64G,
>> and with a 920kB initial ramdisk (2.2MB uncompressed), I get a kernel
>> BUG() at highmem.c line 480, preceded by a message saying "scheduling
>> with KM_TYPE 15 held!" The machine on which I experienced this
>> problem has 1.25GB of RAM. The problem occurs with and without
>> CONFIG_PREEMPT. All kernels that tried were SMP kernels running on a
>> uniprocessor.
>This is not reproducible here with 2.5.52-mm2. Is the initrd required
>to trigger this?
Yes, the initrd seems to be required. It happens when
the initrd attempts to mount /proc (it runs a shell script that
starts by setting PATH, mounting /dev, and mounting /proc).
I've verified that under 2.5.52 the problem occurs with
CONFIG_HIGHME64G and not with CONFIG_HIGHMEM4G. Actually, now the
problem is a BUG() at slab.c:1451, which is also memory corruption,
and I suspect just an evolution of the same problem from 2.5.40.
Anyhow, in case it helps you, I've put the vmlinux and initrd
that produce this problem in
ftp://ftp.yggdrasil.com/private/adam/for-wli/. Note that the ramdisk
has kernel modules that don't match the kernel but that's not the
issue, as I configured that kernel to have a different version name.
Thanks for your attention to this problem.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."