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_at_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 RealityReceived on Mon Mar 28 2016 - 13:48:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC