From owner-svn-src-all@freebsd.org Mon Jul 10 01:37:31 2017 Return-Path: Delivered-To: svn-src-all@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 E4BF2D9A7CF for ; Mon, 10 Jul 2017 01:37:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 9B4D076F1B for ; Mon, 10 Jul 2017 01:37:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id m68so20582044ith.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=pCwjmLzk2dAGFrPBaJUze3khvyyvREljpN8nAW/DDTt5NadKB8nzEpytJ/YBFc08fb 3cjTnv2uhqbQYbEcHQUDMZvnNEtjSxRO19orMnhD7wzvCeikcH2zBoVXvpSDgmAgB0PF ObQ3u9dKBljnnx15v+Fp38ewTHuOTQCan7So5M7L5iWiJSNnsBXWq29n9ergU2MLBB6g QEBfQtaC+MrWq72goCBVie779ote664+RkmsA9BO8WnMnHUyAf+PdyXclP5Mxl+jUCqV hzWoDDyYWAXJ6Lm6LDPWRBD0A/kakXzG1FIk1/ONEeBesBkAToJxI6eH/ICY/cyZpsRY K6Kw== X-Gm-Message-State: AIVw111yH8aTQHupbFuegA7TrlppL+T73U8qeiLaKgRNOg3rk0aP7pzq vmol4Xy8jfMqyoWx9PijoFLbx4VpqyVu 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-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" 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