[lkml]   [2004]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] voluntary-preempt-2.6.8-rc3-O4

* Lee Revell <> 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 ...

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 14:05    [W:0.288 / U:1.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site