[lkml]   [2002]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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)
if (!pfn_valid(page_to_pfn(page)) || PageReserved(page))


BUG_ON(page-> == 0);

Adam J. Richter __ ______________ 575 Oroville Road \ / 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.036 / U:2.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site