From owner-svn-src-head@FreeBSD.ORG Thu Mar 26 22:09:24 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28F92106566C; Thu, 26 Mar 2009 22:09:24 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id D76448FC19; Thu, 26 Mar 2009 22:09:23 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 26 Mar 2009 15:10:15 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.3/8.14.1) with ESMTP id n2QM9Nhl078656; Thu, 26 Mar 2009 15:09:23 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.3/8.14.3/Submit) id n2QM9NdZ078655; Thu, 26 Mar 2009 15:09:23 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200903262209.n2QM9NdZ078655@ambrisko.com> In-Reply-To: <200903261758.28547.jhb@freebsd.org> To: John Baldwin Date: Thu, 26 Mar 2009 15:09:23 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Doug Ambrisko , src-committers@freebsd.org, Doug Ambrisko , Roman Divacky , svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r190445 - in head/sys: amd64/linux32 compat/linprocfs compat/linux conf dev/ipmi modules/ipmi modules/linprocfs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:09:24 -0000 John Baldwin writes: | On Thursday 26 March 2009 5:29:42 pm Doug Ambrisko wrote: [snip] | > Maybe you have another suggestion to fix this. The problem showed up | > when doing a mmap of 0xcf79c000 into 0xffffffffcf79c000 also a mmap | > of 0xf0000 ended up the same way. This caused it to fail. Note this | > is only on amd64 with a Linux. It didn't happen with a FreeBSD i386 | > version on amd64. Here is a sample test program: | | I'm sure this can be easily fixed in the Linux mmap() handlers instead. Do | you know if your Linux binary is using mmap2() or the old mmap()? I think it uses linux_mmap then bouncing it to linux_mmap_common. linux_mmap_common had it right but when it mmap picked it up then it was wrong in my intrumentation. I'll flip the l_off_t type back and then instrument it more to find out when things are going bad. I missed the other usage of l_off_t so I agree this is a bad change. However, I wonder if the other usage of l_off_t actually works right or there is a bug with that as well? I should be able to get something put together pretty quick and send it for review. Thanks, Doug A.