linux-kernel - Re: 2.6.35.6 fails to suspend (pxa2xx-mci.0)

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: <20101006235513.GY7159@buzzloop.caiaq.de>
Date:	Thu, 7 Oct 2010 01:55:13 +0200
From:	Daniel Mack <daniel@...aq.de>
To:	Colin Cross <ccross@...roid.com>, "Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	Sven Neumann <s.neumann@...mfeld.com>,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: 2.6.35.6 fails to suspend (pxa2xx-mci.0)

On Mon, Oct 04, 2010 at 09:30:35AM +0200, Sven Neumann wrote:
> we are running an embedded system here based on the PXA300 platform.
> Suspend/resume used to work well so far. However after upgrading the
> kernel from 2.6.34.7 to 2.6.35.6, we get the following error when trying
> to suspend the system:
> 
> # echo "mem" > "/sys/power/state"
> [ 5647.295953] PM: Syncing filesystems ... done.
> [ 5647.318792] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [ 5647.337048] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> [ 5647.356915] Suspending console(s) (use no_console_suspend to debug)
> [ 5647.366651] pm_op(): platform_pm_suspend+0x0/0x5c returns -38
> [ 5647.366671] PM: Device pxa2xx-mci.0 failed to suspend: error -38
> [ 5647.367082] PM: Some devices failed to suspend

We've bisected this effect down to commit 152e1d5920 ("PM: Prevent
waiting forever on asynchronous resume after failing suspend").
Suspending our PXA3xx based system breaks with this patch.

I tried to understand what's going wrong, but I didn't follow the
discussion about this logic, so I would rather like to pass it back to
the originating people.

I can only guess that the problem here is the somewhat tricky handling
around mmc_sdio_suspend(), which returns -ENODEV (-38) in case a
particular function of a card can not be suspended. The SDIO core would
have simply removed the card in this case normally, but the PM core
seems to interfere now, stopping the whole suspend procedure.

Can anyone shed some light on this?

Thanks,
Daniel

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