linux-kernel - Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2

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]

Message-Id: <200910301948.24473.rjw@sisk.pl>
Date:	Fri, 30 Oct 2009 19:48:24 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:	Kernel Testers List <kernel-testers@...r.kernel.org>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	"Jose Marino" <braket@...mail.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m

Hi,

On Monday 26 October 2009, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.31.  Please verify if it still should be listed and let me know
> (either way).

Here's a puzzle for whoever likes hardware detective work.

Suspend to RAM worked just fine on the Jose's box before commit
53024df259e37ad49ee3d1f3721d4cecdd7bc357 (PM / yenta: Fix cardbus
suspend/resume regression, mainline commit
0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c) that made the resume of CardBus
devices actually work.  After this commit, the box hangs during resume 100% of
the time.

We've done quite some debugging and here's the summary of findings:

1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
   resume phase, after resume_device_irqs().

2) Resume works if yenta_set_power() is not called during resume
   (from yenta_set_socket()).

3) It doesn't help to resume all ACPI devices before yenta.

4) It doesn't help to disable yenta events during resume (unconditionally).

5) There are two CardBus bridges in the box and according to the PM_TRACE
   information the _second_ one is the last device we attempt to wake up
   during a failing resume.

Please look into http://bugzilla.kernel.org/show_bug.cgi?id=14334 for details.

OK, any ideas anyone?

Rafael
--
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/