From owner-freebsd-current@freebsd.org Mon Mar 28 15:38:37 2016 Return-Path: Delivered-To: freebsd-current@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 81E09AE0AD9 for ; Mon, 28 Mar 2016 15:38:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58F861DB4 for ; Mon, 28 Mar 2016 15:38:36 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 2c620b4b-f4fb-11e5-b278-7d22021d92d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 28 Mar 2016 15:38:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2SFcY6s002137; Mon, 28 Mar 2016 09:38:34 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1459179514.1091.127.camel@freebsd.org> Subject: Re: SD card adapter doesn't working anymore From: Ian Lepore To: Ruslan Makhmatkhanov , FreeBSD Current Date: Mon, 28 Mar 2016 09:38:34 -0600 In-Reply-To: <56F8FA7C.1030204@FreeBSD.org> References: <56F5A0A9.8030207@FreeBSD.org> <1458947510.1091.91.camel@freebsd.org> <56F5CCDA.2060808@FreeBSD.org> <1458954555.1091.94.camel@freebsd.org> <56F6551D.1010308@FreeBSD.org> <1459132140.1091.122.camel@freebsd.org> <56F8FA7C.1030204@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 15:38:37 -0000 On Mon, 2016-03-28 at 12:33 +0300, Ruslan Makhmatkhanov wrote: > Ian Lepore wrote on 03/28/16 05:29 AM: > > [...] > > > > I updated to r297281 with this quirk applied. Sadly, it doesn't > > > change > > > anything - controllers still not recognized. I also tried to boot > > > this > > > revision with disabled hw.sdhci.enable_msi=0, that I applied > > > earlier. > > > > > > > I finally found some time today to give this stuff a try on my one > > x86 > > system that has an sdhci controller in it. Unfortunately, > > everything > > just works fine. I tried with a GENERIC kernel that has those > > devices > > compiled in, and I tried taking them out and loading sdhci_pci, > > mmc, > > and mmcsd as modules, and everything just worked both ways. > > > > The only thing I can think of now is to turn up the debugging > > levels. > > That's going to generate a lot of spewage, but if you > > paste/upload the > > output somewhere I'll look through it. So try setting: > > > > hw.sdhci.debug=3 > > hw.mmc.debug=3 > > > > in either loader.conf or via sysctl before you kldload the modules. > > If > > the sdhci output is too trashed with interrupt info, maybe lower it > > to > > 2. > > > > -- Ian > > Ian, not much changed with setting this knobs in loader.conf except > of > showing the "REGISTER DUMP" table, that I already sent you in one of > earlier responses. Here is the full dmesg: https://dpaste.de/GeaT/raw > > Also nothing is showing in messages/console upon plugging an SD card. > Maybe I should enable some debug in kernel to make it show anything? > Here is my kern conf: https://dpaste.de/0v9k/raw It's mostly generic, > but with debug bits disabled. > > Mine mmc/sdhci stuff is compiled in and shown in kldstat output: > [rm@smsh-zfs ~]> kldstat -v | grep mmc > 238 sdhci_pci/mmc > 187 mmc/mmcsd > Wow, there's just nothing to work with in that output. I think the increased debuging didn't output anything because nothing is happening, and that's consistant with the value in the Present State register when the driver attaches, which says that no card is inserted. (It says that in several ways... when a card is in, half a dozen of those bits should be non-zero.) It makes me think the controller isn't powered up, or is in some suspend mode or something. But that would be at the pci bus level, not something the driver is in control of. I had a problem like that initially on my FitPc2 x86 board that has sdhci on it, but the problem went away with a bios update. -- Ian