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
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
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.
--
Regards,
Ruslan
T.O.S. Of Reality
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
