Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 02 Sep 2001 22:28:59 -0600
From:      Warner Losh <imp@harmony.village.org>
To:        non@ever.sanda.gr.jp
Cc:        stable@FreeBSD.ORG
Subject:   Re: PC Card memory window 
Message-ID:  <200109030428.f834Sxh23190@harmony.village.org>
In-Reply-To: Your message of "Sun, 02 Sep 2001 17:38:37 %2B0900." <20010902173837I.non@ever.sanda.gr.jp> 
References:  <20010902173837I.non@ever.sanda.gr.jp>  <200108241855.f7OIt8W96250@harmony.village.org> <20010825090731N.non@ever.sanda.gr.jp> <20010902165357Q.non@ever.sanda.gr.jp> 

next in thread | previous in thread | raw e-mail | index | archive | help
A recent commit that changed a 1 to an actual size, plus your
debugging output made me think.  I started to look at the code and
have an idea about what might be happening.

In message <20010902173837I.non@ever.sanda.gr.jp> non@ever.sanda.gr.jp writes:
: Below is from /var/log/messages,
: It seems that pccardd is reading and assignning iomem correctly but
: kernel is ignoring it.

Try the following patch:

Index: nsp_pccard.c
===================================================================
RCS file: /home/imp/FreeBSD/CVS/src/sys/dev/nsp/nsp_pccard.c,v
retrieving revision 1.8
diff -u -r1.8 nsp_pccard.c
--- nsp_pccard.c	2001/07/14 00:38:51	1.8
+++ nsp_pccard.c	2001/09/03 03:53:26
@@ -175,7 +175,7 @@
 
 	sc->mem_rid = 0;
 	sc->mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY, &sc->mem_rid,
-					 0, ~0, msize, RF_ACTIVE);
+					 0, ~0, 1, RF_ACTIVE);
 	if (sc->mem_res == NULL) {
 		nsp_release_resource(dev);
 		return(ENOMEM);

Because there is the following code in pccard_nbk.c's
pccard_alloc_resource:
static u_long mem_start = IOM_BEGIN;
static u_long mem_end = IOM_END;
...
	if (start == 0 && end == ~0 && type == SYS_RES_MEMORY && count != 1) {
		start = mem_start;
		end = mem_end;
	}
...

So, when you pass it a size, it will allocate memory from the range of 
0xa0000 to 0xfffff.  Looks like your laptop has its first available
memory at 0xc8800.  The sysctl pccard.mem_start and pccard.mem_end
will adjust these values.

There's at least one bug here.  That is that the memory requested size 
isn't aligned to the size of the memory requested.  That's relatively
easy to fix.

For pccard, the size '1' means use the default, as assigned by
pccardd.  The exact size means just allocate it.  One could argue this 
too is a bug...  I think that it is.  1 should mean "Ask the bus" and
a non-1 value should mean "make sure that it is at least this big"
(well, those two are the same thing, if you think about it).

The trouble here comes in with some drivers.  They need to allocate
memory that isn't listed in the CIS.  The ones that I'm aware of need
to map card attribute memory for some reason.  The xe driver has a
crude CIS parser in it to find out what the make/model of the card
is.  The ray driver does unholy things that I never can recall.  Other 
drivers may do things too, but I can't recall at the moment.

So if we were to change this behavior, we'd need to change the xe and
ray drivers.  If not, then we need to change the nsp and ncv drivers.
Since the changes for the nsp and ncv drivers are smaller and easier
to verify, I think the right answer might be to change nsp and ncv for
4.4-RELEASE and do a more complete fix after the release.

The reason that you are seeing different behavior between 4.3 and 4.4
is we changed the range and made it a sysctl.  The range in 4.3 and
earlier was 0xd0000 to 0xdffff.  Since you reported getting 0xd0000 in 
4.3, I think that's what we're seeing.

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




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