Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755998AbcDDT3V (ORCPT ); Mon, 4 Apr 2016 15:29:21 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:34700 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752968AbcDDT3T (ORCPT ); Mon, 4 Apr 2016 15:29:19 -0400 Subject: Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6) To: Linus Torvalds , Ulf Hansson References: <57008645.4070808@hurleysoftware.com> Cc: linux-mmc , Adrian Hunter , "linux-kernel@vger.kernel.org" , Jaehoon Chung From: Peter Hurley Message-ID: <5702C08C.2050301@hurleysoftware.com> Date: Mon, 4 Apr 2016 12:29:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3132 Lines: 70 On 04/04/2016 11:59 AM, Linus Torvalds wrote: > On Mon, Apr 4, 2016 at 4:29 AM, Ulf Hansson wrote: >> >> The commit that's likely to cause the regression is: >> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards >> simultaneously"). > > Peter, mind testing if you can revert that and get the old behavior > back? It seems to still revert cleanly, although I didn't check if the > revert actually then builds.. Yeah, a straight revert of 520bd7a8b415 resumes normal service: [ 2.710232] mmc0: host does not support reading read-only switch, assuming write-enable [ 2.718437] mmc0: new high speed SDHC card at address e624 [ 2.724801] mmcblk0: mmc0:e624 SU08G 7.40 GiB [ 2.730314] mmcblk0: p1 p2 ... [ 2.808938] mmc1: new high speed MMC card at address 0001 [ 2.816352] mmcblk1: mmc1:0001 MMC04G 3.60 GiB [ 2.822075] mmcblk1boot0: mmc1:0001 MMC04G partition 1 2.00 MiB [ 2.829014] mmcblk1boot1: mmc1:0001 MMC04G partition 2 2.00 MiB [ 2.842600] mmcblk1: p1 p2 Should I send a proper revert? >> This commit further enables asynchronous detection of (e)MMC/SD/SDIO >> cards, by converting from an *ordered* work-queue to a *non-ordered* >> work-queue for card detection. >> >> Although, one should know that there have *never* been any guarantees >> to get a fixed mmcblk id for a card. I expect that's what has been >> assumed here. > > So quite frankly, for the whole "no regressions" issue, "documented > behavior" simply isn't an issue. It doesn't matter one whit or not if > something has been documented: if it has worked and people have > depended on it, it's what we in the industry call "reality". > > And reality trumps documentation. Every time. > > So it sounds like either that just needs to be reverted, or some other > way to get reliable device naming needs to happen. > > So the *simple* model is to just scan the devices minimally serially, > and allocate the names at that point (so the names are reliable > between boots for the same hardware configuration). And then do the > more expensive device setup asynchronously (ie querying device > information, spinning up disks, whatever - things that can take > anything from milliseonds to several seconds, because they are doing > actual IO). So you'd do some very basic (and _often_ fairly quick) > operations serially, but then try to do the expensive parts > concurrently. > > The SCSI layer actually goes a bit further than that: it has a fairly > asynchronous scanning thing, but it does allocate the actual host > device nodes serially, and then it even has an ordered list of > "scanning_hosts" that is used to complete the scanning in-order, so > that the sysfs devices show up in the right order even if things > actually got scanned out-of-order. So scans that finished early will > wait for other scans that are for "earlier" devices, and you end up > with what *looks* ordered to the outside, even if internally it was > all done out-of-order. > > So there are multiple approaches to handling this, while still > allowing fairly asynchronous IO. > > Linus >