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
> 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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"