Messages in this thread | | | Date | Tue, 10 Aug 2004 10:58:49 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] voluntary-preempt-2.6.8-rc3-O4 |
| |
* Lee Revell <rlrevell@joe-job.com> wrote:
> [<c01062d8>] common_interrupt+0x18/0x20 > [<c013e2ee>] do_anonymous_page+0x7e/0x190 > [<c013e44e>] do_no_page+0x4e/0x310 > [<c013e8d1>] handle_mm_fault+0xc1/0x170 > [<c013d2a0>] get_user_pages+0x130/0x3b0 > [<c013ea28>] make_pages_present+0x68/0x90 > [<c01401d8>] do_mmap_pgoff+0x3f8/0x640 > [<c010b656>] sys_mmap2+0x76/0xb0 > [<c01060b7>] syscall_call+0x7/0xb
another idea: you are running this on a C3, using CONFIG_MCYRIXIII, correct? That is one of the rare configs that triggers X86_USE_3DNOW and MMX ops. If 3dnow is in any way handicapped in that CPU then that could cause trouble. Could you compile for e.g. CONFIG_M586TSC? [that option should be fully compatible with a C3.] - this will exclude the MMX page clearing ops.
what makes me suspicious is this entry in your call-trace:
> [<c013e2ee>] do_anonymous_page+0x7e/0x190
this is the next instruction after:
call c01d1910 <mmx_clear_page>
but it's all a bit weird - the ALSA interrupt should have hit the fast_clear_page() function but it didnt. Maybe it doesnt show up because the call to fast_clear_page() within mmx_clear_page() is tail-optimized and possibly the stack entry is lost. But still ...
Ingo - 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/
| |