All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: linux-2.5.40 64GB highmem BUG()
@ 2002-12-21  9:43 Adam J. Richter
  2002-12-21  9:48 ` William Lee Irwin III
  0 siblings, 1 reply; 6+ messages in thread
From: Adam J. Richter @ 2002-12-21  9:43 UTC (permalink / raw)
  To: wli; +Cc: linux-kernel

>> 	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
adam@yggdrasil.com     \ /                  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."

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: linux-2.5.40 64GB highmem BUG()
@ 2002-10-08  1:12 Adam J. Richter
  0 siblings, 0 replies; 6+ messages in thread
From: Adam J. Richter @ 2002-10-08  1:12 UTC (permalink / raw)
  To: tmolina; +Cc: linux-kernel

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
adam@yggdrasil.com     \ /                  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."

^ permalink raw reply	[flat|nested] 6+ messages in thread
* linux-2.5.40 64GB highmem BUG()
@ 2002-10-07 13:27 Adam J. Richter
  2002-10-08  0:48 ` Thomas Molina
  2002-12-19 23:36 ` William Lee Irwin III
  0 siblings, 2 replies; 6+ messages in thread
From: Adam J. Richter @ 2002-10-07 13:27 UTC (permalink / raw)
  To: linux-kernel

	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
adam@yggdrasil.com     \ /                  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."

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-12-21  9:41 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-21  9:43 linux-2.5.40 64GB highmem BUG() Adam J. Richter
2002-12-21  9:48 ` William Lee Irwin III
  -- strict thread matches above, loose matches on Subject: below --
2002-10-08  1:12 Adam J. Richter
2002-10-07 13:27 Adam J. Richter
2002-10-08  0:48 ` Thomas Molina
2002-12-19 23:36 ` William Lee Irwin III

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.