Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Sep 2007 18:45:52 +0400
From:      Pankov Pavel <pankov_p@mail.ru>
To:        Gary Palmer <gpalmer@freebsd.org>
Cc:        lists@swaggi.com, freebsd-mobile@freebsd.org
Subject:   Re: SD/MMC (ricoh) reader on Thinkpad T61
Message-ID:  <200709161845.54120.pankov_p@mail.ru>
In-Reply-To: <20070916034622.GC927@in-addr.com>
References:  <46EBF2C5.60708@mail.ru> <20070916034622.GC927@in-addr.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 16 September 2007 07:46:22 Gary Palmer wrote:
> On Sat, Sep 15, 2007 at 06:57:09PM +0400, Pankov Pavel wrote:
> [...]
> > Unfortunately, I can't load the resulting module:
> > : pankbook# kldload -v /boot/modules/sdmmc.ko
> > : kldload: can't load /boot/modules/sdmmc.ko: No such file or directory
> >
> > Such file definitely exists:
> > : pankbook# ls -l /boot/modules/sdmmc.ko
> > : -r-xr-xr-x  1 root  wheel  48953 Sep 15 18:41 /boot/modules/sdmmc.ko
> >
> > I think this error is related to non-existent sdmmc.ko.symbols file
> > (every .ko file in my /boot/kernel has corresponding .ko.symbols, but
> > sdmmc doesn't). I'm not familiar with kernel modules, so I don't know
> > how to solve this issue. But I'm ready to test any ideas :)
>
> Check dmesg and/or /var/log/messages.  Quite often "No such file or
> directory" means that the kernel returned ENOENT.  This typically
> happens due to a failure in the in-kernel linker due to a symbol
> not being found in the kernel that the module requires.  dmesg will
> show any kernel linker message and help you debug the issue.

You are absolutely right! Thanks for the pointer! For archives the error was:
: link_elf: symbol bus_space_write_1 undefined

With the following patch (+ the one from my previous mail) I can successfully 
kldload the module:
: --- sdmmc-20070627/dev/sdmmc/sdshc.c	2007-06-25 14:25:52.000000000 +0400
: +++ sdmmc-20070627-fixed/dev/sdmmc/sdshc.c	2007-09-16 15:44:29.000000000 +0400
: @@ -46,6 +46,8 @@
:  #include <dev/pci/pcireg.h>
:  #include <dev/pci/pcivar.h>
:  
: +#include <machine/bus.h>
: +
:  #include "sdbus_if.h"
:  
:  int sdshc_timeout_interval = 0;
: --- sdmmc-20070627/dev/sdmmc/sdshcbus.c	2007-06-19 21:42:28.000000000 +0400
: +++ sdmmc-20070627-fixed/dev/sdmmc/sdshcbus.c	2007-09-16 16:42:39.000000000 : +0400
: @@ -42,6 +42,8 @@
:  #include <sys/malloc.h>
:  #include <sys/ctype.h>
:  
: +#include <machine/bus.h>
: +
:  #include "sdbus_if.h"
:  
:  

It successfully attaches the bus, but inserting the card leads to 
various panics. I tried fixing some panics (it's easier with 
WITNESS-enabled kernel). Here is what I got:
: --- sdmmc-20070627/dev/sdmmc/sdshc.c	2007-06-25 14:25:52.000000000 +0400
: +++ sdmmc-20070627-fixed/dev/sdmmc/sdshc.c	2007-09-16 15:44:29.000000000 +0400
: @@ -453,7 +455,9 @@
:  	    if (children[cnt] != NULL) {
:  		slot = device_get_unit(children[cnt]) + sc->slot_base;
:  		if ((slot_intr_status & (1UL << slot)) != 0) {
: +		    SD_UNLOCK(sc);
:  		    SDBUS_INTR(children[cnt]);
: +		    SD_LOCK(sc);
:  		}
:  	    }
:  	}
: @@ -614,7 +618,7 @@
:  	if ((SDSHC_READ1(sc, RESET) & SDSHC_HSR_RESET_MASK) == 0) {
:  	    return 0;
:  	}
: -	msleep(sc, &sc->mtx, PPAUSE, "sdshc_reset", sdshc_polling_interval);
: +	SD_SLEEP(sc, PPAUSE, "sdshc_reset", sdshc_polling_interval);
:      }
:      /*
:      MSG((sc->dev, "Controller reset failure\n"));
: --- sdmmc-20070627/dev/sdmmc/sdshcbus.c	2007-06-19 21:42:28.000000000 +0400
: +++ sdmmc-20070627-fixed/dev/sdmmc/sdshcbus.c	2007-09-16 16:42:39.000000000 +0400
: @@ -836,8 +838,8 @@
:  		       " but status is not changed; ignored\n"));
:  	} else {
:  	    if (card_state) {
: -		tsleep(sc, PPAUSE, "sdshcbus_event_card_insertion",
: -		       sdshc_wait_after_insertion);
: +		//tsleep(sc, PPAUSE, "sdshcbus_event_card_insertion",
: +		//       sdshc_wait_after_insertion);
:  		if ((card_state = sdshcbus_check_card_inserted(sc))) {
:  		    LOG(0x08, (sc->dev, "Card Insertion detected\n"));
:  		    taskqueue_enqueue_fast(taskqueue_fast, &sc->attach_task);

But after this changes I'm stuck with panics related to the driver trying 
to sleep in interrupt handler (dump aviable). Let me know if you have 
any ideas how to fix it.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709161845.54120.pankov_p>