On Fri, 2010-04-30 at 19:06 +0200, Andi Kleen wrote: > The mission information is which CONFIG_* option changes the behaviour. > (or maybe it's in the bugzilla, i just skimmed it very quickly) > > presumably it's either hibernation or memory hotadd that introduces > the problem. > > My patch just allowed to have both together. > > Once it's determined which one it is one could do a second bisect > with that option always on (and the other off)? Or maybe it's not a > regression. Thx Andi. I now get the obvious: the way I built the kernels (using standard Debian configs as template, having both CONFIG_MEMORY_HOTPLUG and CONIG_HIBERNATION enabled), without your commit, CONFIG_MEMORY_HOTPLUG was implicitly turned off. Bummer. Enabling CONFIG_MEMORY_HOTPLUG actually enables the bug. I explicitly confirmed this on top of 2.6.33.2: config-2.6.33.2.git19f00f0-config-2.6.33-2-amd64.nohiber:CONFIG_MEMORY_HOTPLUG=y =>"bad" config-2.6.33.2.git19f00f0-config-2.6.33-2-amd64.nohotplug:# CONFIG_MEMORY_HOTPLUG is not set =>"good" So any code enabled by CONFIG_MEMORY_HOTPLUG is the winner, presumable somewhere in the mmc code (?). I am not sure how to proceed, now. To bisect I would need to guess/find a "good" kernel first, if there is one. Maybe some hints how to best debug the code in question would be more helpful... Thx, Stephan -- Stephan Sürken <absurd at olurdix.de> -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
