Tilman Schmidt wrote:
Still, X came up fine, I could log in (Gnome feeling subjectively
a bit sluggish), call up a web page from the Internet in Firefox,
and start perusing the logs, when the whole system froze: neither
mouse nor keyboard would react anymore, and only the Wind^Wreset
button would put me back in control. After rebooting into the
previous, non-mm kernel I found this in the syslog:
Feb 20 17:22:40 xenon kernel: [ 48.180297] BUG: using smp_processor_id() in
preemptible [00000000] code: ntpdate/3562
Feb 20 17:22:40 xenon kernel: [ 48.180297] caller is
__nf_conntrack_find+0x9b/0xeb [nf_conntrack]
Feb 20 17:22:40 xenon kernel: [ 48.180297] Pid: 3562, comm: ntpdate Not
tainted 2.6.25-rc2-mm1-testing #1
Feb 20 17:22:40 xenon kernel: [ 48.180297] [<c02015b9>]
debug_smp_processor_id+0x99/0xb0
Feb 20 17:22:40 xenon kernel: [ 48.180297] [<fac643a7>]
__nf_conntrack_find+0x9b/0xeb [nf_conntrack]
I guess the cause for this is a combination of preemtible
RCU and conntrack using RCU since 2.6.25-rc. Using
NF_CT_STAT_INC_ATOMIC should fix it, but I'd prefer
to have a fix that doesn't increase overhead when regular
RCU is used.
I'll see if I can find a better way to fix this tommorrow.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
