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:	Wed, 13 Mar 2013 14:37:17 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Seungwon Jeon <tgih.jun@...sung.com>
CC:	<linux-mmc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	"'Jaehoon Chung'" <jh80.chung@...sung.com>,
	'Chris Ball' <cjb@...top.org>
Subject: Re: [PATCH] mmc: dw_mmc: setpower on MMC_POWER_{UP,OFF}

On 13/03/13 14:20, Seungwon Jeon wrote:
> Hi James,
> 
> On Tuesday, March 12, 2013, James Hogan wrote:
>> Call the setpower platform callback in response to set_ios with
>> ios->power_mode == MMC_POWER_UP or MMC_POWER_OFF, instead of from the
>> card detect work function.
>>
>> This appears to fix a problem I have where a card stuck in a funny state
>> doesn't get properly cleared by the power being turned off, presumably
>> due to lack of power sequencing. This resulted in the following log
>> messages after boot:
>>
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 300000Hz, actual 298922HZ div = 167)
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 200000Hz, actual 199680HZ div = 250)
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 195765Hz, actual 195764HZ div = 255)
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 400000Hz, actual 399360HZ div = 125)
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 300000Hz, actual 298922HZ div = 167)
>>
>> Signed-off-by: James Hogan <james.hogan@...tec.com>
>> Cc: Seungwon Jeon <tgih.jun@...sung.com>
> 
> This patch is reasonable.
> I just want to know though.
> I guess this problem is happened when card is inserted as soon as card is removed.
> If not, could you explain your situation more?

Hi,

It initially started happening after the patch by Yuvaraj CD ("mmc:
dw_mmc: enable controller interrupt before calling mmc_start_host").
Basically after hard resetting the board the card would be in a dodgy
state, and I'd get these elusive errors after boot (see the above patch
thread for details). It was specifically the position of the prink that
it was sensitive to (I have a JTAG console turned on which adds big
latencies to prinks, so it's clearly some kind of race). Unplugging the
card cleared the problem, as did cutting the power to the card for a
sufficient amount of time. While trying to debug the messages I saw
these power callbacks and thought I'd try them as they seem like a much
better place to control the card power, and seem to match other host
drivers too, and it fixed the problem, I presume due to the intentional
delays around those calls. It is of course possible that the race is
just hiding again, but I think the patch is an improvement regardless.

Cheers
James

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ