Ian Lepore wrote on 03/28/16 06:38 PM:
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
anything - controllers still not recognized. I also tried to boot
revision with disabled hw.sdhci.enable_msi=0, that I applied

I finally found some time today to give this stuff a try on my one
system that has an sdhci controller in it.  Unfortunately,
just works fine.  I tried with a GENERIC kernel that has those
compiled in, and I tried taking them out and loading sdhci_pci,
and mmcsd as modules, and everything just worked both ways.

The only thing I can think of now is to turn up the debugging
   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:


in either loader.conf or via sysctl before you kldload the modules.
the sdhci output is too trashed with interrupt info, maybe lower it

-- 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.

-- Ian

Ok, I'll try to do something about that. Just want to tell, that some time ago, after this controller stopped to work in -current, I had dual boot system with windows. And when I was needed to burn some SD, I just booted to windows and successfully write SD.

I have a latest firmware for my laptop installed, so the only thing I can try is to boot some old FreeBSD versions to see if it will work with them, because this firmware can't be downgraded as far I know.


T.O.S. Of Reality
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to