From owner-svn-src-head@freebsd.org Mon Jul 10 01:37:31 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3EEFD9A7CE for ; Mon, 10 Jul 2017 01:37:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 881A876F1A for ; Mon, 10 Jul 2017 01:37:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id m68so20582046ith.1 for ; Sun, 09 Jul 2017 18:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=W9jfee5RIxwido0nnM8QqOwQn3Y60jUivIMdUN+VZaI=; b=l+eEgPDyc9OSyjqfO6WK9wr68+UUjwI2MqJDGJKNLh1P+gRWQCYYXh5BzWAjjROThO SUYqWtnyJvGlNsYx0IQ9EoLQNv/ugPhd5ByXNSnMQNbKv2aSf/KSGypkZrzvBKXZHGoz dVwMIsRT9P4jhy5rFZl/asZL/NnEGxGwem1uurepcz5O+nfQBhf86WgJJV4x6RiAW6PK I78Rposfj52H1SX5OYDIs2Ew0ZbMi0EGyw255zQpnTLgcTTn64vw/iA9QeLg5HLe0OFo YKdmORYRrWQOS8+ZKbQNxN7U9sPvkoy8O9Kdbec9toG8cVdeRH53I2xFnYbzP+GUwzqZ LOUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=W9jfee5RIxwido0nnM8QqOwQn3Y60jUivIMdUN+VZaI=; b=NCgO/ygR9BB9Dr2B4J10KOQi4ecgmp+y8YkZHOXRqC9Wze6rLBqhwwWwiYLqmZottw 99J8CrldNmLqw1LfHHvODZvuur3Mhb+RAJiHdzQsylPSaa6tW/9HuI1O4Ole5UEeCTmb 7l3Y2sDYYsZWYjFubTzfNg2Wi/fYmnQ/++NJ4ecnbyev1i4VgOZUtve9dJQhi6uATGUB p0mzOuBePCse5jX3FTtPkx506tMjoAEfEI0AJyMg+eVhGWwvBpwV9OMCsIu5GrafMUQb ZSfDE8E4gnEcnxlv4NkfJRmnSiblrzYL/zeZ6dmWLzuVxIEKxl4unmeLKzO1PW2LbIdZ xbTA== X-Gm-Message-State: AIVw113hmlOsTlf7poJuF3EqprFChIMJ51eLhdAu1ri+B0zSUQYeQox3 rXIrxawxh0C+JmkKHbhVsGxnCq+Odj61 X-Received: by 10.36.90.203 with SMTP id v194mr9443367ita.48.1499650650867; Sun, 09 Jul 2017 18:37:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.212.167 with HTTP; Sun, 9 Jul 2017 18:37:30 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:5d99:2cb7:7594:1100] In-Reply-To: <20170709223747.GC38352@alchemy.franken.de> References: <201707091657.v69GvOar096942@repo.freebsd.org> <20170709184221.GB38352@alchemy.franken.de> <20170709223747.GC38352@alchemy.franken.de> From: Warner Losh Date: Sun, 9 Jul 2017 19:37:30 -0600 X-Google-Sender-Auth: Ycc0VbIvDXL9gSsAWdt8n51jMm4 Message-ID: Subject: Re: svn commit: r320844 - in head: etc/mtree include lib/libcam sys/amd64/conf sys/arm/broadcom/bcm2835 sys/arm/conf sys/arm/ti sys/cam sys/cam/mmc sys/cam/scsi sys/conf sys/dev/mmc sys/dev/sdhci sys/m... To: Marius Strobl Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , src-committers , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 01:37:32 -0000 On Sun, Jul 9, 2017 at 4:37 PM, Marius Strobl wrote: > On Sun, Jul 09, 2017 at 02:49:56PM -0600, Warner Losh wrote: > > On Sun, Jul 9, 2017 at 2:40 PM, Warner Losh wrote: > > > > > > > > > > > On Sun, Jul 9, 2017 at 12:42 PM, Marius Strobl > wrote: > > > > > >> On Sun, Jul 09, 2017 at 04:57:24PM +0000, Warner Losh wrote: > > >> > Author: imp > > >> > Date: Sun Jul 9 16:57:24 2017 > > >> > New Revision: 320844 > > >> > URL: https://svnweb.freebsd.org/changeset/base/320844 > > >> > > > >> > Log: > > >> > An MMC/SD/SDIO stack using CAM > > >> > > > >> > Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's > > >> > flexible queueing will make it easier to write non-storage drivers > > >> > than the legacy stack. SDIO drivers from both the kernel and as > > >> > userland daemons are possible, though much of that functionality > will > > >> > come later. > > >> > > >> At least with a non-MMCCAM kernel, with this revision in place I get > > >> an endless storm of "unexpected" SDHCI_INT_CARD_INT interrupts during > > >> boot. Apparently this is due to the fact that sdhci(4) now enables > > >> these interrupts, but sdhci_generic_intr() neither actually handles > > >> them nor clears them from intmask. > > >> > > > > > > OK. I'll look into it. Since I don't have an SDHCI card in the system I > > > tested it in, I never saw these... > > > > > > > Looking at the code, the problem is obvious. It looks like it came in on > a > > late commit to the mmccam integration branch. I'll revert which should > > solve your problem. > > Thanks, I can confirm that r320850 allows booting again. Compared to > pre-r320844, sdhci(4) now still is incredibly noisy in the non-MMCCAM > path, though. Can we get this removed again or at least put under > sdhci_debug, along with removing the memory overhead for the non-MMCCAM > case and some of the style(9) violations/inconsistencies (re-)introduced, > using something like the attached patch? Sure. The patch failed 100% to apply, so I applied it by hand (there's on > 80 character line that I left that way on purpose because (a) the way you chunked it up was worse than before and (b) most of it should be changed to use other macros so it isn't so ugly and I left the CAM related comments in for easiler grepping). That should get rid of the worst of the re-introduced offenders. That's what happens when work collides... I'll commit in a few, after I fix the module compilation errors... > Looking at my notes and test systems, I did test this > > on a NUC, but it was an older version w/o the patch I just reverted. > Sorry > > for the hassle. r320850 > > Well, I might have given a different impression, but I don't actually > care about NUCs as such; they are just a relatively cheap way of > obtaining various combinations of Intel MMC/SDXC controllers and eMMC > chips and are an acceptable loss should I ever manage to kill an eMMC > chip during development. > Yea, I have one laying around for other reasons as well... Mine don't have eMMC in them, but do have a SD slot... Warner