From owner-freebsd-stable Sun Sep 2 21:29: 5 2001 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9885637B401 for ; Sun, 2 Sep 2001 21:29:00 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f834SxX13277; Sun, 2 Sep 2001 22:28:59 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f834Sxh23190; Sun, 2 Sep 2001 22:28:59 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109030428.f834Sxh23190@harmony.village.org> To: non@ever.sanda.gr.jp Subject: Re: PC Card memory window Cc: stable@FreeBSD.ORG In-reply-to: Your message of "Sun, 02 Sep 2001 17:38:37 +0900." <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> Date: Sun, 02 Sep 2001 22:28:59 -0600 From: Warner Losh Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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