Re: BUG(): sched.c: Line 944 - 2.5.35

[Adam J. Richter]

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
[e-mail]     \ /                  Milpitas, California 95035
[phone]         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."