Re: SD card adapter doesn't working anymore

On Sat, 2016-03-26 at 12:23 +0300, Ruslan Makhmatkhanov wrote:
> Ian Lepore wrote on 03/26/16 04:09 AM:
> > On Sat, 2016-03-26 at 02:42 +0300, Ruslan Makhmatkhanov wrote:
> > > Ian Lepore wrote on 03/26/16 02:11 AM:
> > > > On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote:
> > > > > Hello,
> > > > > 
> > > > > I have this in pciconf output:
> > > > > 
> > > > > =============================================================
> > > > > ====
> > > > > ====
> > > > > =
> > > > > none1_at_pci0:36:0:0:	class=0x088000 card=0x167e103c
> > > > > chip=0x2392197b
> > > > > rev=0x30 hdr=0x00
> > > > >        vendor     = 'JMicron Technology Corp.'
> > > > >        device     = 'SD/MMC Host Controller'
> > > > >        class      = base peripheral
> > > > > 
> > > > > none2_at_pci0:36:0:3:	class=0x088000 card=0x167e103c
> > > > > chip=0x2393197b
> > > > > rev=0x30 hdr=0x00
> > > > >        vendor     = 'JMicron Technology Corp.'
> > > > >        device     = 'MS Host Controller'
> > > > >        class      = base peripheral
> > > > > =============================================================
> > > > > ====
> > > > > ====
> > > > > =
> > > > > 
> > > > > And my SD-card controller is not working anymore (it worked
> > > > > on
> > > > > -current
> > > > > on the same laptop year or two ago). Do I need to load some
> > > > > kld
> > > > > to
> > > > > make
> > > > > it working, or support for this controllers was dropped
> > > > > altogether
> > > > > for
> > > > > some reason? I have mostly vanilla GENERIC at r296772, but it
> > > > > actually
> > > > > stopped to work much earlier.
> > > > > 
> > > > > Thanks.
> > > > > 
> > > > 
> > > > Do you have a pciconf entry for class=080501 chip=0x2391197b,
> > > > device
> > > > would probably be "SD Host Controller", and if so, is it 
> > > > none_at_pci o
> > > > r
> > > > sdhci_pci_at_pci ?  If sdhci_pci attached, there would be dmesg
> > > > output
> > > > for
> > > > it, and I'm curious whether any irq-related error showed up
> > > > when it
> > > > attached.
> > > > 
> > > > The only change I can find that might have some effect is a
> > > > switch
> > > > to
> > > > MSI-based interrupts some time ago.  That was MFC'd to 10
> > > > -stable in
> > > > r271051, and that's very close to range cited in that PR.
> > > > 
> > > > It might be worth trying to set hw.sdhci.enable_msi=0 in
> > > > loader.conf
> > > > and see if it makes a difference.
> > > > 
> > > > -- Ian
> > > 
> > > Sorry, but nothing has changed in pciconf/dmesg with this option
> > > at
> > > boot.
> > > 
> > 
> > Hmm, well so much for logic ("what changed around the time reported
> > in
> > that PR?").  Now for intuition...
> > 
> > Maybe this JMicro device id needs the same quirks as the 2381 ID
> > that's
> > already in the driver.  The attached patch would add that.  If this
> > fixes it, that's good, but it doesn't explain why it worked then
> > stopped working at some point.
> > 
> > -- Ian
> 
> 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