Exact Kernel version: 2.5.40 Hardware Environment: ia32 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. http://marc.theaimsgroup.com/?l=linux-kernel&m=103399745406334&w=2
Original logging author was: "Adam J. Richter" <adam@yggdrasil.com> >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.
From Adam: I tried it in either 2.5.45 or 2.5.46 and it still existed. I have not tried it in 2.5.47, but probably will in a few days (I'm out of town right now).
Martin - should we add HighMem Support as a component? We should reduce the usage of "Other" as much as we can... In any case, I am going to put this bug in the ASSIGNED state since you seem to be the rightful owner...
I've tried turning CONFIG_DEBUG_HIGHMEM on, then loading an initrd. My machine has 4GB physical RAM, so I did mem=1280M: 384MB HIGHMEM available. 896MB LOWMEM available. I haven't been able to reproduce your problem. If you're still seeing this, I'll try to replicate your setup more closely. Otherwise, we should probably just close the bug.
Adam, this bug has been around a while now. Still reproducable at your end?
There's no record that Adam answered to the question whether this problem is still reproducible for him. I'm therefore closing this bug. Please reopen if it's still present in recent 2.6 kernels.
This is an automated email and please do not reply to this email. Dear Submitter, Thank you for submitting the patches to the linux bluetooth mailing list. While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository. ----- Output ----- error: git diff header lacks filename information when removing 1 leading pathname component (line 21) hint: Use 'git am --show-current-patch' to see the failed patch Please resolve the issue and submit the patches again. --- Regards, Linux Bluetooth