On 2007.06.25 08:40:35 -0400, Jeremy Fitzhardinge wrote: > Ingo Molnar wrote: > >* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > >>hm, restoring nmi.c to the v2.6.21 state does not fix the > >>nmi_watchdog=2 hang. I'll do a bisection run. > >> > > > >and after spending an hour on 15 bisection steps: > > > > git-bisect start > > git-bisect good d1be341dba5521506d9e6dccfd66179080705bea > > git-bisect bad a06381fec77bf88ec6c5eb6324457cb04e9ffd69 > > git-bisect bad 794543a236074f49a8af89ef08ef6a753e4777e5 > > git-bisect good 24a77daf3d80bddcece044e6dc3675e427eef3f3 > > git-bisect bad ea62ccd00fd0b6720b033adfc9984f31130ce195 > > git-bisect good 7e20ef030dde0e52dd5a57220ee82fa9facbea4e > > git-bisect bad f19cccf366a07e05703c90038704a3a5ffcb0607 > > git-bisect good 0d08e0d3a97cce22ebf80b54785e00d9b94e1add > > git-bisect bad 856f44ff4af6e57fdc39a8b2bec498c88438bd27 > > git-bisect bad f8822f42019eceed19cc6c0f985a489e17796ed8 > > git-bisect good 1c3d99c11c47c8a1a9ed6a46555dbf6520683c52 > > git-bisect good b239fb2501117bf3aeb4dd6926edd855be92333d > > git-bisect good 98de032b681d8a7532d44dfc66aa5c0c1c755a9d > > git-bisect good 42c24fa22e86365055fc931d833f26165e687c19 > > > >the winner is ... > > > > f8822f42019eceed19cc6c0f985a489e17796ed8 is first bad commit > > commit f8822f42019eceed19cc6c0f985a489e17796ed8 > > Author: Jeremy Fitzhardinge <[EMAIL PROTECTED]> > > Date: Wed May 2 19:27:14 2007 +0200 > > > > [PATCH] i386: PARAVIRT: Consistently wrap paravirt ops callsites to > > make them patchable > > > >... our wonderful paravirt subsystem, honed to eternal perfection by the > >testing-machine x86_64 tree. > > > >reverting -git-curr's paravirt.c, paravirt.h, smp.c and tlbflush.h to > >before the bad commit makes the NMI watchdog work again. Patch against > >-rc6 is below. > > > > Er, wow. I've been running with this stuff for months without a > problem. Do you have CONFIG_PARAVIRT enabled? Do you still get the > hang if you boot with "noreplace-paravirt" to disable the patching?
Are you running on AMD hardware? As Intel performance counters are only 32 bits wide, the wrmsrl bug should be a non-issue at least for the NMI watchdog on Intel hardware. AMD uses 48bit wide performance counters, which are probably less happy ;-) Björn - 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/