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:	Mon, 1 Nov 2010 11:02:00 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Arnd Hannemann <arnd@...dnet.de>
Cc:	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: regression: b43-sdio: probe of mmc0:0001:1 failed with error -16

On Mon, Nov 1, 2010 at 10:05 AM, Arnd Hannemann <arnd@...dnet.de> wrote:
> No, actually mmc_sdio_init_card() is called _before_ sdio_bus_probe

Yes, it is called once at boot while the card is mmc_rescan()ed.

But that's not interesting, because the card is then powered down, and
will only be powered on again when it is probed with a driver.

> Also mmd_sdio_resume is not called at all.

Sorry, I meant mmc_sdio_restore_host.

You should see something like this:

sdio_bus_probe - >
    ... (runtime PM function calls) ... ->
           mmc_power_restore_host ->
                 mmc_sdio_power_restore ->
                        mmc_sdio_init_card -> ...

We have 1 report where the latter mmc_sdio_init_card fails at this
point, and I'm interested to know whether it fails for you, too (and
if yes, where). If it is not even called, I'd appreciate if you can
check out where does this flow break in your case.

> No mmc_send_relative_addr() does _not_ return -110, actually it
> is not called at all.

OK.

> I inserted a WARN_ON() in sdio_bus_probe, and here is the backtrace I get:

The interesting part is actually what happens after sdio_bus_probe(),
not before it.

Is mmc_power_restore_host being called ? mmc_sdio_power_restore ?
mmc_sdio_init_card ? etc...

I'm also attaching a patch that requires hosts to explicitly indicate
whether they support powering off/on their cards after boot (which
would prevent SDIO core from powering off you card after boot since
your host doesn't indicate that capability).

Can you please see if the problem goes away with it ?

Thanks,
Ohad.

View attachment "0001-mmc-add-MMC_CAP_RUNTIME_PM.patch" of type "text/x-patch" (5656 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ