Hi, I am trying to understand your test case. Were you actually measure uncore_imc events at the time you suspended?
I tried on my IvyBridge Lenovo and it works fine with 3.14-rc4+ (tip.git). I used: echo -n disk >/sys/power/state On Tue, Feb 25, 2014 at 4:48 PM, H. Peter Anvin <h...@zytor.com> wrote: > On 02/24/2014 12:19 PM, Borislav Petkov wrote: >> Btw, >> >> I don't know whether the following observation is related or not, but it >> so happens that after resume from suspend-to-disk, I see the booting up >> of the resume kernel on the console but when it is time for the original >> kernel to take over and switch to graphics, the screen remains black but >> the machine is responsive over the network. >> >> And this doesn't happen on every resume but only sporadically. >> >> And yep, -rc3 was fine. >> >> On Mon, Feb 24, 2014 at 05:24:00PM +0100, Borislav Petkov wrote: >>> This started happening this morning after booting -rc4+tip, let's >>> add *everybody* to CC :-) >>> >>> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and >>> other goodies on the stack. >>> > > snb_uncore_imc_init_box() is introduced new in tip:perf/core, and is a > relatively recent commit (b9e1ab6d4c0582cad97699285a6b3cf992251b00), so > I suspect that that wasn't in whatever -rc3 mix you were testing. > > I am wondering if backing/disabling out that support (perhaps by > removing the relevant PCI ID) fixes the problem? > > -hpa > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
