At Fri, 8 Aug 2014 18:25:59 +0200, Janek Kozicki wrote: > > Full reply, along with CONFIG_PM_TRACE_RTC=y results is below. (snip) > > Now I tried to identify the problem. There are two magic numbers > recorded in realtime clock: > > pci 0000:ff:0d.1: hash matches > pci_bus 0000:ff: hash matches > > The 0000:ff: is strange, like no particular piece of hardware driver is > wrong, but whole bus? > > The 0000:ff:0d.1 from lspci is a following thing: > > ff:0d.1 System peripheral [0880]: Intel Corporation Ivytown Unicast Registers > [8086:0ee3] (rev 04) > Subsystem: Super Micro Computer Inc Device [15d9:0628] > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > <TAbort- <MAbort- >SERR- <PERR- INTx- > > > So that's the best I could do so far. Currently I am waiting for more > instructions from you on how to proceed. > > PS: I am pretty sure that my hardware is not broken.
So, the PM hang problem still exists although the kernel WARNING is gone after the patch, right? Then the kernel WARNING was a red herring. It should be fixed, but it wasn't the real cause of the hang. I'll apply the patch to sound git tree in anyway, as it look like a right fix for kernel WARNING. Takashi -- 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/
