linux-kernel - Re: 3.16 crashes on resume from Suspend-To-disk, Intel pci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 09 Aug 2014 10:59:13 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Janek Kozicki <janek_listy@...pl>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	linux-kernel@...r.kernel.org, Zhang Rui <rui.zhang@...el.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: 3.16 crashes on resume from Suspend-To-disk, Intel pci_bus problem?

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/