Messages in this thread |  | | From | "Adam J. Richter" <> | Date | Mon, 16 Sep 2002 09:36:15 -0700 | Subject | Re: BUG(): sched.c: Line 944 - 2.5.35 |
| |
Shawn Starr wrote:
>Kernel 2.5.35: > >code resides in main schedule() function: > >if (unlikely(in_atomic())) > BUG();
That line prevously checked in_interrupt (in 2.5.34) instead of in_atomic. If you have CONFIG_PREEMPT defined, the definition of in_atomic in linux-2.5.35/include/asm-i386/hardirq.h is:
# define in_atomic() (preempt_count() != kernel_locked())
When I see this problem at boot, preempt_count() returns 0x4000000 (PREEMPT_ACTIVE) and kernel_locked() returns 0.
I don't understand the semantics of PREEMPT_ACTIVE to know whether to
(1) change the test back to using in_interrupt instead of in_atomic, or (2) change the definition of in_atomic(), or (3) look for a bug somewhere else.
However, I know experimentally that changing the test back to using in_interrupt() results in a possibly unrelated BUG() at line 279 of rmap.c:
void page_remove_rmap(struct page * page, pte_t * ptep) { pte_addr_t pte_paddr = ptep_to_paddr(ptep); struct pte_chain *pc;
if (!page || !ptep) BUG(); if (!pfn_valid(page_to_pfn(page)) || PageReserved(page)) return;
pte_chain_lock(page);
BUG_ON(page->pte.direct == 0);
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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |