On Sun, May 17, 2009 at 12:07:27PM -0300, Glauber Costa wrote: > On Sun, May 17, 2009 at 05:32:35PM +0300, Gleb Natapov wrote: > > On Sun, May 17, 2009 at 11:31:07AM -0300, Glauber Costa wrote: > > > On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: > > > > On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: > > > > > This patch sets bits 1 in disabled processor's _STA. > > > > > According to the ACPI spec, this bit means: > > > > > "Set if the device is enabled and decoding its resources." > > > > > > > > > > Without it, Windows 2008 device manager shows the processors > > > > > as malfunctioning hardware. > > > > > > > > > If you uncheck "show hidden devices" option in View menu of the > > > > device manager you should see only enabled CPUs (bit 2 of _STA). > > > > This patch breaks resume from hibernate on windows 2008/vista. > > > > > > The last change on that piece of code was made by you under the comment: > > > > > > 1) Disabled processor's _STA method should return 0 (this fixes Vista's > > > BSOD on resuming after hibernate problem) > > > > > > However, you did not changed it to 0, but to 9 instead. What did you meant? > > > > > I wrote commit message before changing it to 9 :( I don't remember why I > > changed it to 9, but I think it was because of Linux CPU hot-plug. > > > > > It appears that windows won't accept bit 0 without bit 1 being set. > > > > > > However, it works fine in my use case if _STA returns 0 or 8. The only real > > > problem is, as I said, setting bit 0 but not bit 1. Does any among 0 or 8 > > > works for your hibernate use case? > > Can you check Linux cpu hot-plug please. > Yeah, unfortunately neither work for linux cpu hotplug. Anything without bit 0 set > won't work. So valid values appear to be 0x1, 0x3, 0x9, 0xB. Theoretically we can provide different values for different OSes, but this is just a guess work since there is no any documentation how CPU hot-plug should work on x86. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
