Christoph Lameter <[email protected]> wrote:
>
> We have some strange race conditions as a result of the timer
> scalability fixes.
>
> ptype_all is set to 0x10:0x10 on faster systems (Xeon 3.6Ghz).
> Slower systems do fine(Xeon 3.0Ghz) and do not corrupt ptype_all.
>
> Its not clear to me how ptype_all could relate to timer operations
I'd do `nm -n vmlinux', see which data structures the linker placed nearby
to ptype_all and then go looking for overruns against them.
ptype_base is an array, but I cannot see any race around ptype_base. So
look to see if ptype_base is corrupted as well, keep walking back through
memory, see where the scribble starts.
> but
> if I apply these timer patches I get ptype_all corruption.
>
> timers-fixes-improvements.patch
> timers-fixes-improvements-smp_processor_id-fix.patch
> timers-fixes-improvements-fix.patch
> timer-deadlock-fix
> (It does not matter if the last three are applied)
2.6.12-rc3-mm3 has different patches:
timers-fixes-improvements.patch
timers-fixes-improvements-smp_processor_id-fix.patch
timers-fixes-improvements-fix.patch
timers-fix-__mod_timer-vs-__run_timers-deadlock.patch
timers-fix-__mod_timer-vs-__run_timers-deadlock-tidy.patch
timers-comments-update.patch
kernel-timerc-remove-a-goto-construct.patch
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
