From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ronald G Minnich <rminnich@lanl.gov>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Question on mapping 0xfff00000
In-Reply-To: <20010321013034.07203199FB@mail.cse.psu.edu>
Message-ID: <Pine.LNX.4.30.0103231841400.20312-100000@white.acl.lanl.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Date: Fri, 23 Mar 2001 18:43:55 -0700
Topicbox-Message-UUID: 73687b7c-eac9-11e9-9e20-41e7f4b1d025

On Tue, 20 Mar 2001 jmk@plan9.bell-labs.com wrote:

> Looks like an arithmetic overflow problem. The clue is that the return
> should be the ending address of the successfully mapped area. But if you
> add 0xfff00000+0x100000 you get 0x100000000, which is 0 in 32-bits and the
> mapping loop in mmu.c:^mmukmap() is

ok, yes, it is an arithmetic overflow. My fix is to not try to map that
last page, as i will not really need it anyway for what I am doing.

Also, it turns out the return for upamalloc is 0 for fail, and the
STARTING address on success. Just FYI.

thanks for the help, that cleared up the problems I was having. I should
have caught that as many times as I've been bitten by the "last page bug"
in various OSes. My driver is now happy.

ron