From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 9 05:50:05 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C915716A419; Sun, 9 Sep 2007 05:50:05 +0000 (UTC) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [IPv6:2001:470:1f01:523::1]) by mx1.freebsd.org (Postfix) with ESMTP id ABEBC13C457; Sun, 9 Sep 2007 05:50:05 +0000 (UTC) (envelope-from peter@wemm.org) Received: from macbook.wemm.org (c-67-188-249-30.hsd1.ca.comcast.net [67.188.249.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter@canning.wemm.org) by canning.wemm.org (Postfix) with ESMTP id 66B9346B62; Sat, 8 Sep 2007 22:50:01 -0700 (PDT) (envelope-from peter@wemm.org) Message-ID: <46E38930.2050409@wemm.org> Date: Sat, 08 Sep 2007 22:48:32 -0700 From: Peter Wemm User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ruslan Ermilov References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905145006.GA50486@team.vega.ru> In-Reply-To: <20070905145006.GA50486@team.vega.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 05:50:05 -0000 Ruslan Ermilov wrote: > On Wed, Sep 05, 2007 at 07:50:49PM +1000, Peter Jeremy wrote: > >> I've been comparing VSZ reported for similar processes on amd64 and >> i386 and found that amd64 processes report as vastly larger than I >> expected: >> >> i386 amd64 >> 1476 3572 getty >> 6272 29184 xclock >> 4784 28020 xdm >> 6420 30000 xterm >> 3828 9444 sendmail >> >> I did some further digging into the procfs map for xterm and found >> that each of the amd64 shared objects has an additional mapping that >> is 255 or 256 pages. Once you remove those mappings, the sizes are >> reasonably similar. A typical set of mappings is: >> >> 0x800f60000 0x800fba000 61 0 0xffffff0027ac2540 r-x 36 18 0x0 COW NC vnode /usr/local/lib/libXaw8.so.8 >> 0x800fba000 0x800fbb000 1 0 0xffffff002765ed20 r-x 1 0 0x2180 COW NC vnode /usr/local/lib/libXaw8.so.8 >> 0x800fbb000 0x8010bb000 18 0 0xffffff0027ac2540 r-x 36 18 0x0 COW NC vnode /usr/local/lib/libXaw8.so.8 [*] >> 0x8010bb000 0x8010cd000 18 0 0xffffff00274d2c40 rw- 1 0 0x2180 COW NC vnode /usr/local/lib/libXaw8.so.8 >> >> 0x28284000 0x282d7000 15 0 0xc360ad68 r-x 9 6 0x0 COW NC vnode /usr/local/lib/libXaw8.so.8 >> 0x282d7000 0x282d8000 0 0 0xc3a4b210 r-x 1 0 0x2180 COW NC vnode /usr/local/lib/libXaw8.so.8 >> 0x282d8000 0x282df000 3 0 0xc3aef39c rwx 1 0 0x2180 COW NC vnode /usr/local/lib/libXaw8.so.8 >> >> Could someone please explain the purpose of the mapping [*] and what >> system resources they occupy. >> >> > These mappings are produced by rtld(1) when it maps shared objects. > I took cat(1) here, and examined its libc.so's mappings on i386 and > amd64. What rtld(1) basically does is mmap's the PT_LOAD segments > (see the Program Header in the "objdump -x /lib/libc.so.*" output). > Since the size of the loadable segment is not necessaily a multiple > of the page size, it zeroes out the rest of the last page of each > loadable segment. If the segment is read-only (like is the case > for the "text" segment), it temporarily write-unprotects the last > page, then zeroes its tail, then makes it read-only again. > > The first mapping you see is created by mapping a "text" segment > of the library. The last mapping is for the "data" segment. > The second mapping is created by toggling the write protection > of the page, and this mapping is 4096 bytes in size. > > The mysterious third mapping on amd64 is due to a gap between the > virtual addresses of the two loadable segments (text and data) on > amd64: > > Program Header: > LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**20 > filesz 0x00000000000d7051 memsz 0x00000000000d7051 flags r-x > LOAD off 0x00000000000d7060 vaddr 0x00000000001d7060 paddr 0x00000000001d7060 align 2**20 > filesz 0x000000000001a010 memsz 0x0000000000032df8 flags rw- > > vend0 = rounddown(vaddr0, pagesize) + roundup(memsz0, pagesize) = 0x0 + 0xd8000 = 0xd8000 > gap = rounddown(vaddr1, pagesize) - vend0 = 0x1d7000 - 0xd8000 = 255 pages > > On i386 there's no gap: > > Program Header: > LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 > filesz 0x000ca5d2 memsz 0x000ca5d2 flags r-x > LOAD off 0x000ca5e0 vaddr 0x000cb5e0 paddr 0x000cb5e0 align 2**12 > filesz 0x000053f0 memsz 0x0001b404 flags rw- > > vend0 = rounddown(vaddr0, pagesize) + roundup(memsz0, pagesize) = 0x0 + 0xcb000 = 0xcb000 > gap = rounddown(vaddr1, pagesize) - vend0 = 0xcb000 - 0xcb000 = 0 pages > > Why amd64 linker does so, I don't know. :-) > > > Cheers, > This is by design, at least from the binutils side of things. There are two bugs. 1) binutils has the wrong max page size. It is currently set at 1MB rather than 2MB. I believe this is fixed in binutils sources that we have not imported yet. This is currently harmless, but is less than useful once we have superpages support committed. 2) There is a bug in sys/kern/imgact_elf.c. It assumes that the PT_LOAD sections are contiguous, which isn't a given. Fixing #1 will give us future benefits. Fixing #2 will reduce the virtual process size by eliminating the unnecessary mappings. I'll take a look and see if I can fix it. If somebody else wants to take a shot, be my guest. We need to fix #2 because running linux binaries is affected. Linux will be using the binutils layout. -Peter From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 9 05:53:27 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F1816A41B for ; Sun, 9 Sep 2007 05:53:27 +0000 (UTC) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [IPv6:2001:470:1f01:523::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8C35C13C467 for ; Sun, 9 Sep 2007 05:53:27 +0000 (UTC) (envelope-from peter@wemm.org) Received: from macbook.wemm.org (c-67-188-249-30.hsd1.ca.comcast.net [67.188.249.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter@canning.wemm.org) by canning.wemm.org (Postfix) with ESMTP id 694FE46B62; Sat, 8 Sep 2007 22:53:27 -0700 (PDT) (envelope-from peter@wemm.org) Message-ID: <46E389FD.4000905@wemm.org> Date: Sat, 08 Sep 2007 22:51:57 -0700 From: Peter Wemm User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kostik Belousov References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905155354.GG53667@deviant.kiev.zoral.com.ua> <20070907002808.GA34246@turion.vk2pj.dyndns.org> <20070907123142.GK53667@deviant.kiev.zoral.com.ua> In-Reply-To: <20070907123142.GK53667@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 05:53:27 -0000 Kostik Belousov wrote: > On Fri, Sep 07, 2007 at 10:28:08AM +1000, Peter Jeremy wrote: > >> On 2007-Sep-05 18:53:54 +0300, Kostik Belousov wrote: >> >>> As you see, virtual address for second loadable section (rw, data+bss) is >>> 0x000000000015b000 (+base). This seems to be due to the alignment that is >>> 0x100000. >>> >>> The ghost mapping you see is due to the rtld algorithm for mapping the elf >>> object, that reserves the address space by doing mmap() for full range >>> where the sections would be located, and then remaps actual segments on the >>> appropriate offsets. See libexec/rtld-elf/map_object.c::map_object(). >>> >> Looking at map_object(), together with a ktrace of cat(1) make it a >> lot clearer what it going on. >> >> >>> The alignment itself seems to come from (or, at least, reflected there) >>> /usr/libdata/ldscripts/elf_x86_64_fbsd.x* files, see ALIGN calculation >>> for rw sections. >>> >> These ldscript files are themselves generated based on constants in >> /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh - which >> incorrectly states that the amd64 max page size is 1MB (this is >> corrected in the FSF CVS repo between binutils 2.17 and 2.18). >> >> The intent appears to be to align sections on PDE boundaries. I'm >> not sure what purpose this might serve but it definitely doesn't >> work because: >> 1) The PDE boundary is 2MB, not 1MB as currently configured >> 2) ld-elf.so.1 makes no attempt to support anything other than page alignment >> >> As a result, the only effect of this configuration is to vastly bloat >> the VSZ of processes - whilst these pages will never be accessed, >> there will still be some associated KVM bloat to support the increased >> VSZ and number of vm_map_entry's associated with processes. I don't >> know enough about the VM system to quantify this. >> > It seems to be negligible. > > >> Can anyone suggest a technical reason[1] for not applying the following >> patch to remove the 1MB "max page size": >> Index: /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh >> =================================================================== >> RCS file: /usr/ncvs/src/contrib/binutils/ld/emulparams/elf_x86_64.sh,v >> retrieving revision 1.1.1.6 >> diff -u -r1.1.1.6 elf_x86_64.sh >> --- /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 16 Jun 2004 05:45:40 -0000 1.1.1.6 >> +++ /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 7 Sep 2007 00:20:31 -0000 >> @@ -2,7 +2,7 @@ >> ELFSIZE=64 >> OUTPUT_FORMAT="elf64-x86-64" >> TEXT_START_ADDR=0x400000 >> -MAXPAGESIZE=0x100000 >> +MAXPAGESIZE=0x1000 >> COMMONPAGESIZE=0x1000 >> NONPAGED_TEXT_START_ADDR=0x400000 >> ARCH="i386:x86-64" >> >> [1] being on a vendor branch is not a technical reason >> > If working, patch seems to be good. Maybe, we shall look whether the linux > distribution did something with this. And, I think that the question shall > be actually asking to binutils developers. > No. It's our bug. This layout is by design, in order to make best use of large pages. The correct change here is to change from 0x100000 to 0x200000 like binutils itself has done. Then we can fix the rtld or imgact_elf bugs that bogusly map this extra space. -Peter From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 9 05:54:36 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C23D16A417; Sun, 9 Sep 2007 05:54:36 +0000 (UTC) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [IPv6:2001:470:1f01:523::1]) by mx1.freebsd.org (Postfix) with ESMTP id 10BC313C4B4; Sun, 9 Sep 2007 05:54:36 +0000 (UTC) (envelope-from peter@wemm.org) Received: from macbook.wemm.org (c-67-188-249-30.hsd1.ca.comcast.net [67.188.249.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter@canning.wemm.org) by canning.wemm.org (Postfix) with ESMTP id F034846B62; Sat, 8 Sep 2007 22:54:35 -0700 (PDT) (envelope-from peter@wemm.org) Message-ID: <46E38A42.8050400@wemm.org> Date: Sat, 08 Sep 2007 22:53:06 -0700 From: Peter Wemm User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ruslan Ermilov References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905145006.GA50486@team.vega.ru> <46E38930.2050409@wemm.org> In-Reply-To: <46E38930.2050409@wemm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 05:54:36 -0000 Peter Wemm wrote: > > 2) There is a bug in sys/kern/imgact_elf.c. It assumes that the > PT_LOAD sections are contiguous, which isn't a given. I think I may have outsmarted myself here. This should be coming from rtld, not the kernel. In any case, it is still our bug. -Peter From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 9 09:20:04 2007 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C9516A468 for ; Sun, 9 Sep 2007 09:20:04 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (mx1.vega.ru [87.242.77.163]) by mx1.freebsd.org (Postfix) with ESMTP id 899A713C474 for ; Sun, 9 Sep 2007 09:20:03 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=53970 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IUIxU-000FnX-OS; Sun, 09 Sep 2007 09:20:00 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.1/8.14.1) with ESMTP id l899Jeid072695; Sun, 9 Sep 2007 13:19:40 +0400 (MSD) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.1/8.14.1/Submit) id l899Jev6072694; Sun, 9 Sep 2007 13:19:40 +0400 (MSD) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Sun, 9 Sep 2007 13:19:39 +0400 From: Ruslan Ermilov To: Peter Wemm Message-ID: <20070909091939.GA72634@team.vega.ru> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905145006.GA50486@team.vega.ru> <46E38930.2050409@wemm.org> <46E38A42.8050400@wemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E38A42.8050400@wemm.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 09:20:04 -0000 On Sat, Sep 08, 2007 at 10:53:06PM -0700, Peter Wemm wrote: > Peter Wemm wrote: >> >> 2) There is a bug in sys/kern/imgact_elf.c. It assumes that the PT_LOAD >> sections are contiguous, which isn't a given. > > I think I may have outsmarted myself here. This should be coming from > rtld, not the kernel. In any case, it is still our bug. > This has to do with binutils (the section's alignment). On i386 it's 2^12 (4KB): : Program Header: : LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 : filesz 0x000ca5d2 memsz 0x000ca5d2 flags r-x : LOAD off 0x000ca5e0 vaddr 0x000cb5e0 paddr 0x000cb5e0 align 2**12 : filesz 0x000053f0 memsz 0x0001b404 flags rw- But on amd64 it's 2^20 (1MB): : Program Header: : LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**20 : filesz 0x00000000000d7051 memsz 0x00000000000d7051 flags r-x : LOAD off 0x00000000000d7060 vaddr 0x00000000001d7060 paddr 0x00000000001d7060 align 2**20 : filesz 0x000000000001a010 memsz 0x0000000000032df8 flags rw- 1MB gives either 255 or 256 pages when aligned. What I don't understand is why rtld mmaps the total sum of virtual sizes (memsz) from the library, which often is greater than the size of the file, but I didn't yet look close enough in the sources. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 9 09:41:13 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE21616A421 for ; Sun, 9 Sep 2007 09:41:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA2013C478 for ; Sun, 9 Sep 2007 09:41:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IUJHr-000H2T-5V; Sun, 09 Sep 2007 12:41:11 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l899f209045920; Sun, 9 Sep 2007 12:41:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l899f1s2045919; Sun, 9 Sep 2007 12:41:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 Sep 2007 12:41:01 +0300 From: Kostik Belousov To: Peter Wemm Message-ID: <20070909094101.GW53667@deviant.kiev.zoral.com.ua> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905145006.GA50486@team.vega.ru> <46E38930.2050409@wemm.org> <46E38A42.8050400@wemm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PjLo8P/CG6vpADRe" Content-Disposition: inline In-Reply-To: <46E38A42.8050400@wemm.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 669e5d776fa0e81a52da9f410dfff76f X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1448 [September 7 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 09:41:13 -0000 --PjLo8P/CG6vpADRe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 08, 2007 at 10:53:06PM -0700, Peter Wemm wrote: > Peter Wemm wrote: > > > >2) There is a bug in sys/kern/imgact_elf.c. It assumes that the=20 > >PT_LOAD sections are contiguous, which isn't a given. >=20 > I think I may have outsmarted myself here. This should be coming from=20 > rtld, not the kernel. In any case, it is still our bug. The extra mapping is mostly harmless. It only increases the VSZ. Moreover, I think that it prevents kernel from selecting gaps for mapping some chunks between segments of the elf object. This might cause funny effects, and even break gdb more. What seems to be a real bug is the fact that first mapping (for whole region, inside which the actual segments are remmapped later) is not aligned according to the elf object segments requirement. As consequence, our rtld ignores alignment specification in the elf segments that are greater that page size. It seems we were lucky that gcc and most other compilers does not generate code that depends on bigger alignment. --PjLo8P/CG6vpADRe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG47+sC3+MBN1Mb4gRAjgNAJ0TwgdcK0wp3/5oo8FOY3zBLHkP2wCg89nr v+4mD3uaNMwR+eqmT8qPDbU= =XwEF -----END PGP SIGNATURE----- --PjLo8P/CG6vpADRe-- From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 10 10:18:54 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A636616A417 for ; Mon, 10 Sep 2007 10:18:54 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id E5F2A13C428 for ; Mon, 10 Sep 2007 10:18:53 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l8AAIpCh001885; Mon, 10 Sep 2007 20:18:51 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l8AAIoVu001884; Mon, 10 Sep 2007 20:18:50 +1000 (EST) (envelope-from peter) Date: Mon, 10 Sep 2007 20:18:50 +1000 From: Peter Jeremy To: Peter Wemm Message-ID: <20070910101850.GA1146@turion.vk2pj.dyndns.org> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905145006.GA50486@team.vega.ru> <46E38930.2050409@wemm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <46E38930.2050409@wemm.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 10:18:54 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Sep-08 22:48:32 -0700, Peter Wemm wrote: >1) binutils has the wrong max page size. It is currently set at 1MB rathe= r=20 >than 2MB. I believe this is fixed in binutils sources that we have not=20 >imported yet. This is currently harmless, but is less than useful once we= =20 >have superpages support committed. I can see the usefulness of superpages for large objects (like the kernel and database buffer caches) but do they actually have much benefit for normal executables and shared libraries? Looking through my set of .so's, I only have 6 that have text segments larger than 2MiB (though a 7th is close to 2MiB), the largest (libwx_gtk2) is only 5MiB. None of the data or bss segments are larger than 2MiB and (the largest is 1.8MiB). I notice that the i386 ld scripts don't bother with superpage alignments. >2) There is a bug in sys/kern/imgact_elf.c. It assumes that the PT_LOAD= =20 >sections are contiguous, which isn't a given. I've had a quick look through all my process maps and I don't see any obvious issues with imgact_elf.c - it looks to be only ld-elf.so.1. >process size by eliminating the unnecessary mappings. I'll take a look an= d=20 >see if I can fix it. If somebody else wants to take a shot, be my guest. The biggest difficulty I see is that currently ld-elf.so just mmap()s the various bits of the requested .so - any alignment is totally up to mmap(2). There is no way to request anything other than page alignment. I can see potential uses for a "MAP_ALIGN" flag to mmap(2) which would treat "addr" as an minimum alignment but no other Unices appear to support this. The only other option I can see would be for ld-elf.so to second-guess the way mmap(2) works and use a mixture of MAP_FIXED and mmap()/munmap() to achieve the required alignment. --=20 Peter Jeremy --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG5RoK/opHv/APuIcRAhgMAJ9acX+/6QTnyOXwwUCBwzEVL9YuTACgwWU9 4ZsqBGDWMv9V/fb/g29RVaE= =REOR -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 10 10:43:16 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3003716A46E for ; Mon, 10 Sep 2007 10:43:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9A81D13C4B7 for ; Mon, 10 Sep 2007 10:43:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IUgjS-000PRH-4o for freebsd-amd64@freebsd.org; Mon, 10 Sep 2007 13:43:14 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8AAh5Ge022191; Mon, 10 Sep 2007 13:43:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8AAh5a7022189; Mon, 10 Sep 2007 13:43:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Sep 2007 13:43:05 +0300 From: Kostik Belousov To: Peter Jeremy Message-ID: <20070910104305.GA53667@deviant.kiev.zoral.com.ua> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905145006.GA50486@team.vega.ru> <46E38930.2050409@wemm.org> <20070910101850.GA1146@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CtqPPqYpYc7tL2y7" Content-Disposition: inline In-Reply-To: <20070910101850.GA1146@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 49b91432ac2f6f50aab85e53d3752740 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1448 [September 7 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 10:43:16 -0000 --CtqPPqYpYc7tL2y7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 10, 2007 at 08:18:50PM +1000, Peter Jeremy wrote: > On 2007-Sep-08 22:48:32 -0700, Peter Wemm wrote: > >1) binutils has the wrong max page size. It is currently set at 1MB rat= her=20 > >than 2MB. I believe this is fixed in binutils sources that we have not= =20 > >imported yet. This is currently harmless, but is less than useful once = we=20 > >have superpages support committed. >=20 > I can see the usefulness of superpages for large objects (like the > kernel and database buffer caches) but do they actually have much > benefit for normal executables and shared libraries? Looking through > my set of .so's, I only have 6 that have text segments larger than > 2MiB (though a 7th is close to 2MiB), the largest (libwx_gtk2) is only > 5MiB. None of the data or bss segments are larger than 2MiB and (the > largest is 1.8MiB). >=20 > I notice that the i386 ld scripts don't bother with superpage alignments. >=20 > >2) There is a bug in sys/kern/imgact_elf.c. It assumes that the PT_LOAD= =20 > >sections are contiguous, which isn't a given. >=20 > I've had a quick look through all my process maps and I don't see any > obvious issues with imgact_elf.c - it looks to be only ld-elf.so.1. >=20 > >process size by eliminating the unnecessary mappings. I'll take a look = and=20 > >see if I can fix it. If somebody else wants to take a shot, be my guest. >=20 > The biggest difficulty I see is that currently ld-elf.so just mmap()s > the various bits of the requested .so - any alignment is totally up to > mmap(2). There is no way to request anything other than page alignment. >=20 > I can see potential uses for a "MAP_ALIGN" flag to mmap(2) which would > treat "addr" as an minimum alignment but no other Unices appear to > support this. The only other option I can see would be for ld-elf.so > to second-guess the way mmap(2) works and use a mixture of MAP_FIXED > and mmap()/munmap() to achieve the required alignment. Or rtld may map the huge region (twice of alignment) to reserve space that is guaranteed to contain the address with needed alignment, and then do use the mixture of MAP_FIXED mmaps and munmap() to stitch the needed memory map. --CtqPPqYpYc7tL2y7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5R+4C3+MBN1Mb4gRAnrWAJ9rbV1o6zHpzUmNdVl7L0NKRTdhMACfSaIB 6Ul5e2BLQkACu4/ryJqRMDY= =PIJa -----END PGP SIGNATURE----- --CtqPPqYpYc7tL2y7-- From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 10 12:05:14 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C593A16A417 for ; Mon, 10 Sep 2007 12:05:14 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp804.mail.ird.yahoo.com (smtp804.mail.ird.yahoo.com [217.146.188.64]) by mx1.freebsd.org (Postfix) with SMTP id 01C2E13C45E for ; Mon, 10 Sep 2007 12:05:13 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 72851 invoked from network); 10 Sep 2007 11:38:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=Uu19ftjLUcaxwM+qCFwHRLkhba8ZVIU2y3ygpLMharG0bzBcpkcvYCCRwtufg9yd4eEDxmoumoBLBZ9AFNLKOyP9uuvE6XQLMLlHwjJFShbApFih1hNxdPYcaSENfBY9fDeeBXL7CEhTzTfZ5/DdQq9r9Y2W+KOta/G59ndzfG0= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (thomas.sparrevohn@btinternet.com@86.133.55.166 with login) by smtp804.mail.ird.yahoo.com with SMTP; 10 Sep 2007 11:38:33 -0000 X-YMail-OSG: zeqPtFkVM1l7K4piU8KCuvJbFWSORYgI_RhF5Rra9QnNBtxwWmLLNcE6Ik8VOuvop98DUW8UNA-- From: Thomas Sparrevohn To: freebsd-amd64@freebsd.org Date: Mon, 10 Sep 2007 12:38:32 +0100 User-Agent: KMail/1.9.7 References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070910101850.GA1146@turion.vk2pj.dyndns.org> <20070910104305.GA53667@deviant.kiev.zoral.com.ua> In-Reply-To: <20070910104305.GA53667@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709101238.32403.Thomas.Sparrevohn@btinternet.com> Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 12:05:14 -0000 On Monday 10 September 2007 11:43:05 Kostik Belousov wrote: > > > > I can see the usefulness of superpages for large objects (like the > > kernel and database buffer caches) but do they actually have much > > benefit for normal executables and shared libraries? Looking through > > my set of .so's, I only have 6 that have text segments larger than > > 2MiB (though a 7th is close to 2MiB), the largest (libwx_gtk2) is only > > 5MiB. None of the data or bss segments are larger than 2MiB and (the > > largest is 1.8MiB). > > Well - one idea could be to create combined library maps e.g. Tag multiple libraries against a static location map - One could tag the executeable with a unique identifier in order to overcome update issues - However I am not sure that it would give benefits as I believe that there are a limited number of superpage PTE's (I believe, not sure however) Ideally all - or maybe not all - libraries text part could be mapped into a fixed region that could be shared using superpages and global pages From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 11 13:32:52 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76A1716A418 for ; Tue, 11 Sep 2007 13:32:52 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [194.126.106.100]) by mx1.freebsd.org (Postfix) with ESMTP id 451D013C457 for ; Tue, 11 Sep 2007 13:32:49 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from localhost (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 092DBBAF0 for ; Tue, 11 Sep 2007 16:08:14 +0300 (EEST) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by localhost (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQk4-ajzERyz for ; Tue, 11 Sep 2007 16:08:12 +0300 (EEST) Received: from raad.tartu.ee (lv.raad.tartu.ee [194.126.106.110]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 47A62B817 for ; Tue, 11 Sep 2007 16:08:11 +0300 (EEST) Received: from INFO/SpoolDir by raad.tartu.ee (Mercury 1.48); 11 Sep 07 16:08:12 +0300 Received: from SpoolDir by INFO (Mercury 1.48); 11 Sep 07 16:07:59 +0300 Received: from [172.26.1.3] (172.26.1.3) by raad.tartu.ee (Mercury 1.48) with ESMTP; 11 Sep 07 16:07:58 +0300 Message-ID: <46E69330.9070401@raad.tartu.ee> Date: Tue, 11 Sep 2007 16:08:00 +0300 From: Toomas Aas User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 2nd generation Opteron? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 13:32:52 -0000 Hello! I just wanted to ask whether anyone has had chance to try FreeBSD/amd64 on the 2nd generation Opteron machine? I'm thinking about getting new hardware for our web server where the OS should be FreeBSD 6.2, preferrably amd64. Hardware notes mention only the 1st generation Opteron and Xeon Nocona, but list archives seem to indicate that Xeon 5000 based systems also work. So what about the Opteron? -- Toomas Aas From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 11 15:43:03 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AFBF16A418 for ; Tue, 11 Sep 2007 15:43:03 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (thingy.kcilink.com [74.92.149.59]) by mx1.freebsd.org (Postfix) with ESMTP id 5510413C442 for ; Tue, 11 Sep 2007 15:43:01 +0000 (UTC) (envelope-from vivek@khera.org) Received: from [192.168.7.121] (host-121.int.kcilink.com [192.168.7.121]) by yertle.kcilink.com (Postfix) with ESMTP id 71A46C943A for ; Tue, 11 Sep 2007 11:26:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46E69330.9070401@raad.tartu.ee> References: <46E69330.9070401@raad.tartu.ee> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A0ADB25-45BD-462E-9BE9-21E507988D06@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Tue, 11 Sep 2007 11:26:57 -0400 To: FreeBSD AMD64 X-Mailer: Apple Mail (2.752.3) Subject: Re: 2nd generation Opteron? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 15:43:03 -0000 On Sep 11, 2007, at 9:08 AM, Toomas Aas wrote: > Hello! > > I just wanted to ask whether anyone has had chance to try FreeBSD/ > amd64 on the 2nd generation Opteron machine? I'm thinking about > getting new hardware for our web server where the OS should be > FreeBSD 6.2, preferrably amd64. Hardware notes mention only the 1st > generation Opteron and Xeon Nocona, but list archives seem to > indicate that Xeon 5000 based systems also work. So what about the > Opteron? Is this second generation? CPU: Dual-Core AMD Opteron(tm) Processor 2216 (2393.65-MHz K8-class CPU) If so, it works just fine. This is from a Sun Fire X4100 M2 dual dual-core server. From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 11 16:17:11 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E3216A417 for ; Tue, 11 Sep 2007 16:17:11 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (thingy.kcilink.com [74.92.149.59]) by mx1.freebsd.org (Postfix) with ESMTP id D017C13C467 for ; Tue, 11 Sep 2007 16:17:11 +0000 (UTC) (envelope-from vivek@khera.org) Received: from [192.168.7.121] (host-121.int.kcilink.com [192.168.7.121]) by yertle.kcilink.com (Postfix) with ESMTP id E7929C943A; Tue, 11 Sep 2007 12:17:10 -0400 (EDT) In-Reply-To: <20070911190819.pa866a29gkw08gsw@webmail.raad.tartu.ee> References: <46E69330.9070401@raad.tartu.ee> <3A0ADB25-45BD-462E-9BE9-21E507988D06@khera.org> <20070911190819.pa866a29gkw08gsw@webmail.raad.tartu.ee> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Tue, 11 Sep 2007 12:17:09 -0400 To: Toomas Aas X-Mailer: Apple Mail (2.752.3) Cc: freebsd-amd64@freebsd.org Subject: Re: 2nd generation Opteron? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 16:17:12 -0000 On Sep 11, 2007, at 12:08 PM, Toomas Aas wrote: >> >> If so, it works just fine. This is from a Sun Fire X4100 M2 dual >> dual-core server. > > I hope it's fast :) > it is so fast, it almost does the work before i ask it to. :-) the one with 20GB RAM is especially fast. From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 6 18:30:02 2007 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 663C516A419 for ; Thu, 6 Sep 2007 18:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D19F13C46E for ; Thu, 6 Sep 2007 18:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l86IU2Yr082233 for ; Thu, 6 Sep 2007 18:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l86IU1LI082230; Thu, 6 Sep 2007 18:30:01 GMT (envelope-from gnats) Resent-Date: Thu, 6 Sep 2007 18:30:01 GMT Resent-Message-Id: <200709061830.l86IU1LI082230@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Joshua Isom Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CF0116A418 for ; Thu, 6 Sep 2007 18:23:14 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF3E13C45B for ; Thu, 6 Sep 2007 18:23:14 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l86INEfN043753 for ; Thu, 6 Sep 2007 18:23:14 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.1/8.14.1/Submit) id l86INEsk043752; Thu, 6 Sep 2007 18:23:14 GMT (envelope-from nobody) Message-Id: <200709061823.l86INEsk043752@www.freebsd.org> Date: Thu, 6 Sep 2007 18:23:14 GMT From: Joshua Isom To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Fri, 14 Sep 2007 10:57:46 +0000 Cc: Subject: amd64/116159: Panic while debugging on CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 18:30:02 -0000 >Number: 116159 >Category: amd64 >Synopsis: Panic while debugging on CURRENT >Confidential: no >Severity: critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 06 18:30:01 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Joshua Isom >Release: CURRENT kernel, STABLE userland >Organization: >Environment: FreeBSD freebsd 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Sep 5 06:32:03 CDT 2007 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 >Description: When I use a 6-STABLE userland with a 7-CURRENT kernel(for support for my dvd drive), I can predictably cause a panic in the kernel while debugging a program, and all as a non root user. Looking at the coredump seems to provide no information but once it paniced I was able to get this information. kdb_enter() at kdb_enter+0x31 panic() at panic+0x173 postsig() at postsig+0x155 thread_export_context() at thread_export_context+0x1c7 thread_userret() at thread_userret+0x481 userret() at userret+0xfb trap() at trap+0x22d calltrap() at calltrap+0x8 trap 0xc, rip=0xdc0038, rsp=0x7fffffffe730, rbp=0x7fffffffee760 The way I cause this is to debug a program that segfaults, and type in "next" or a similar command into gdb. When I tried upgrading to a full CURRENT system, debugging anything seemed to be broken(one command would become zombied and I couldn't figure out which). I don't have any problems with debugging with a 6-STABLE system. >How-To-Repeat: $ gdb foo > run program went boom > next kernel goes boom >Fix: Unknown, but everything works in 6-STABLE. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 10 03:00:12 2007 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AB1C16A421 for ; Mon, 10 Sep 2007 03:00:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 60F3D13C442 for ; Mon, 10 Sep 2007 03:00:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8A30Csp086734 for ; Mon, 10 Sep 2007 03:00:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8A30CxH086732; Mon, 10 Sep 2007 03:00:12 GMT (envelope-from gnats) Date: Mon, 10 Sep 2007 03:00:12 GMT Message-Id: <200709100300.l8A30CxH086732@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Joshua Isom X-Mailman-Approved-At: Fri, 14 Sep 2007 10:57:46 +0000 Cc: Subject: Re: amd64/116159: Panic while debugging on CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joshua Isom List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 03:00:12 -0000 The following reply was made to PR amd64/116159; it has been noted by GNATS. From: Joshua Isom To: bug-followup@FreeBSD.org, jrisom@gmail.com Cc: Subject: Re: amd64/116159: Panic while debugging on CURRENT Date: Sun, 9 Sep 2007 21:25:22 -0500 I disabled the debugging lines in the GENERIC and rebuilt, and I didn't have problems debugging. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options KDB # Enable kernel debugger support. #options DDB # Support DDB. #options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed I don't know which caused the issue but it seems as though the debugging support caused the kernel crash. From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 10 11:07:56 2007 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F21916A4CD for ; Mon, 10 Sep 2007 11:07:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3561013C494 for ; Mon, 10 Sep 2007 11:07:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8AB7uaB017171 for ; Mon, 10 Sep 2007 11:07:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8AB7sRF017167 for freebsd-amd64@FreeBSD.org; Mon, 10 Sep 2007 11:07:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Sep 2007 11:07:54 GMT Message-Id: <200709101107.l8AB7sRF017167@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org X-Mailman-Approved-At: Fri, 14 Sep 2007 10:57:46 +0000 Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 11:07:56 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/89202 amd64 [ufs] [panic] Kernel crash when accessing filesystem w o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number 2 problems total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up o amd64/74747 amd64 System panic on shutdown when process will not die o amd64/76136 amd64 system halts before reboot o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/80691 amd64 amd64 kernel hangs on load o amd64/82425 amd64 [fxp] fxp0: device timeout, fxp interface dies on 5.4/ o amd64/85451 amd64 [hang] 6.0-BETA3 lockups on AMD64 (PREEMPTION only) o amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 o amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock called (by ata o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/88790 amd64 kernel panic on first boot (after the FreeBSD installa o amd64/89501 amd64 System crashes on install using ftp on local subnet o amd64/89503 amd64 Cant Boot Installation Disk o amd64/89546 amd64 [geom] GEOM error o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/91492 amd64 BTX halted o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff o amd64/92889 amd64 [libc] xdr double buffer overflow o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/94677 amd64 panic in amd64 install at non-root user creation o amd64/94989 amd64 BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) and 5. f amd64/95414 amd64 kernel crashes during install o amd64/95888 amd64 kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP DL140G o amd64/97075 amd64 Panic, Trap 12 o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/102122 amd64 6.1-RELEASE amd64 Install Media panics on boot. s amd64/104311 amd64 ports/wine should be installable on amd64 o amd64/105514 amd64 FreeBSD/amd64 - Fails to boot on HP Pavilion dv8000 La o amd64/105531 amd64 [sata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - doe o amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on o amd64/106604 amd64 saslauthd crashes with signal 6 on FreeBSD 6.2-PREREL o amd64/106918 amd64 [re] Asus P5B with internal RealTek PCIe Ethernet gets o amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work f amd64/109584 amd64 zdump doesn't work o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/111955 amd64 [install] Install CD boot panic due to missing BIOS sm o amd64/111992 amd64 BTX failed - HP Laptop dv2315nr s gnu/112215 amd64 [patch] gcc(1): "gcc -m32" attempts to link against 64 o amd64/112677 amd64 [aac] Adaptec 4805SAS causes 6.2 (AMD64) to panic (amd f amd64/112828 amd64 Complete data loss after upgrade 6.1 -> 6.2 (Amd64) o amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/115784 amd64 Compiling with -m32 breaks on FreeBSD/amd64 s amd64/115815 amd64 [sata] [request] Gigabyte GA-M61P-S3 Motherboard unsup o amd64/116159 amd64 Panic while debugging on CURRENT 50 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/74608 amd64 [mpt] [hang] mpt hangs 5 minutes when booting o amd64/74811 amd64 [nfs] df, nfs mount, negative Avail -> 32/64-bit confu s amd64/85273 amd64 FreeBSD (NetBSD or OpenBSD) not install on laptop Comp o amd64/88730 amd64 kernel panics during booting from the installation CD o amd64/91195 amd64 FreeBSD 6.0(amd64) and Asus A8R-MVP a amd64/93002 amd64 amd64 (6.0) coredumps at unpredictable times a amd64/93090 amd64 [nve] NIC on GA-K8NF-9 motherboard is recognized, but o amd64/97489 amd64 [ata] nForce 410 ATA controller dma time out (ASUS K8N o amd64/100326 amd64 [fdc] /dev/fd0 not created after installation FreeBSD o amd64/100838 amd64 [powerd] FreeBSD 6.0/6.1 kernel panics when booting wi f amd64/101132 amd64 [smp] Incorrect cpu idle and usage statistics in top a o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/103259 amd64 [ar] Cannot use ataraid on nvidia nForce4+amd64 o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p o amd64/107858 amd64 ASRock Conroe-945G-DVI motherboard: non-working sound f amd64/108345 amd64 6.2-* GENERIC will not boot Intel PD EMT64 w/ ACPI o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot o amd64/111096 amd64 motherboard ASRock AM2NF6G-VSTA not supported f amd64/113111 amd64 Potentially wrong instructions will be produced for EM o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/115581 amd64 [patch] -mfancy-math-387 has no effect 21 problems total. From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 13 05:00:03 2007 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0324616A419 for ; Thu, 13 Sep 2007 05:00:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D3FD513C46B for ; Thu, 13 Sep 2007 05:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8D502sI058969 for ; Thu, 13 Sep 2007 05:00:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8D502tb058968; Thu, 13 Sep 2007 05:00:02 GMT (envelope-from gnats) Resent-Date: Thu, 13 Sep 2007 05:00:02 GMT Resent-Message-Id: <200709130500.l8D502tb058968@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Slava Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 926A416A41A for ; Thu, 13 Sep 2007 04:50:14 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 9656E13C459 for ; Thu, 13 Sep 2007 04:50:14 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l8D4oD3d008683 for ; Thu, 13 Sep 2007 04:50:13 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.1/8.14.1/Submit) id l8D4oD4U008682; Thu, 13 Sep 2007 04:50:13 GMT (envelope-from nobody) Message-Id: <200709130450.l8D4oD4U008682@www.freebsd.org> Date: Thu, 13 Sep 2007 04:50:13 GMT From: Slava To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Fri, 14 Sep 2007 10:57:46 +0000 Cc: Subject: amd64/116322: At start fsck on current, the system panics X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 05:00:03 -0000 >Number: 116322 >Category: amd64 >Synopsis: At start fsck on current, the system panics >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 13 05:00:02 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Slava >Release: FreeBSD Current >Organization: >Environment: FreeBSD file1.local 7.0-CURRENT FreeBSD 7.0-CURRENT #5: Wed Sep 12 11:30:31 KRAST 2007 slava@file1.local:/usr/obj/usr/src/sys/FILE1-AMD64-7 amd64 >Description: At start fsck on current, the system panics: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3c8 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff801a4e59 stack pointer = 0x10:0xffffffffb3574ba0 frame pointer = 0x10:0x4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) trap number = 12 panic: page fault coredump while to catch it has not turned out. >How-To-Repeat: To start fsck on a disk after emergency switching-off. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 13 05:40:01 2007 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4FAD16A421 for ; Thu, 13 Sep 2007 05:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C819113C458 for ; Thu, 13 Sep 2007 05:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8D5e1oe062022 for ; Thu, 13 Sep 2007 05:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8D5e153062021; Thu, 13 Sep 2007 05:40:01 GMT (envelope-from gnats) Resent-Date: Thu, 13 Sep 2007 05:40:01 GMT Resent-Message-Id: <200709130540.l8D5e153062021@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Slava Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D289F16A417 for ; Thu, 13 Sep 2007 05:39:36 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id CBEF813C45D for ; Thu, 13 Sep 2007 05:39:36 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l8D5daUJ016559 for ; Thu, 13 Sep 2007 05:39:36 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.1/8.14.1/Submit) id l8D5daCp016558; Thu, 13 Sep 2007 05:39:36 GMT (envelope-from nobody) Message-Id: <200709130539.l8D5daCp016558@www.freebsd.org> Date: Thu, 13 Sep 2007 05:39:36 GMT From: Slava To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Fri, 14 Sep 2007 10:57:46 +0000 Cc: Subject: amd64/116325: twed the controller with DEVICE_POLLING, is not loaded a server. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 05:40:01 -0000 >Number: 116325 >Category: amd64 >Synopsis: twed the controller with DEVICE_POLLING, is not loaded a server. >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 13 05:40:01 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Slava >Release: FreeBSD Current >Organization: >Environment: FreeBSD file1.local 7.0-CURRENT FreeBSD 7.0-CURRENT #5: Wed Sep 12 11:30:31 KRAST 2007 slava@file1.local:/usr/obj/usr/src/sys/FILE1-AMD64-7 amd64 >Description: There is a file server with the controller 3ware 7506-12. Loading with kernel GENERIC without problems. It is necessary to add only options options DEVICE_POLLING options HZ=1000 and loading stops on: Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default ad0: 238475MB at ata0-master UDMA100 ad4: 715404MB at ata2-master SATA150 ad6: 715404MB at ata3-master SATA150 twed0: on twe0 twed0: 1907793MB (3907160064 sectors) MB - INTEL S3000AHX. 4 Gb the RAM. >How-To-Repeat: >Fix: Patch attached with submission follows: boot witch GENERIC kernel file1# dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #5: Wed Sep 12 11:30:31 KRAST 2007 slava@file1.local:/usr/obj/usr/src/sys/FILE1-AMD64-7 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2802.72-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf47 Stepping = 7 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4282937344 (4084 MB) avail memory = 4129521664 (3938 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 5 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 30-53 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x3000-0x300f mem 0xe8800000-0xe880000f,0xe8000000-0xe87fffff irq 35 at device 2.0 on pci2 twe0: [GIANT-LOCKED] twe0: [ITHREAD] twe0: 12 ports, Firmware FE7X 1.05.00.063, BIOS BE7X 1.08.00.048 pcib3: at device 28.4 on pci0 pci3: on pcib3 pcib4: at device 28.5 on pci0 pci4: on pcib4 em0: port 0x2000-0x201f mem 0xe8a80000-0xe8a9ffff,0xe8a00000-0xe8a7ffff irq 17 at device 0.0 on pci4 em0: Ethernet address: 00:15:17:23:b2:c2 em0: [FILTER] pci4: at device 0.3 (no driver attached) pci4: at device 0.4 (no driver attached) uhci0: port 0x4080-0x409f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x4060-0x407f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x4040-0x405f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x4020-0x403f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xe8b00400-0xe8b007ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: waiting for BIOS to give up control usb4: timed out waiting for BIOS usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 vgapci0: port 0x1000-0x10ff mem 0xe0000000-0xe7ffffff,0xe8940000-0xe894ffff irq 18 at device 4.0 on pci5 em1: port 0x1100-0x113f mem 0xe8920000-0xe893ffff,0xe8900000-0xe891ffff irq 17 at device 5.0 on pci5 em1: Ethernet address: 00:15:17:23:b2:c3 em1: [FILTER] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x40b0-0x40bf irq 18 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x40c8-0x40cf,0x40e4-0x40e7,0x40c0-0x40c7,0x40e0-0x40e3,0x40a0-0x40af mem 0xe8b00000-0xe8b003ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] orm0: at iomem 0xc0000-0xc8fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub2 kbd2 at ukbd0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default ad0: 238475MB at ata0-master UDMA100 ad4: 715404MB at ata2-master SATA150 ad6: 715404MB at ata3-master SATA150 twed0: on twe0 twed0: 1907793MB (3907160064 sectors) <-- witch polling stops here SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a em0: link state changed to UP #pciconf -vl|less hostb0@pci0:0:0: class=0x060000 card=0x348d8086 chip=0x27788086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'E7230/3000/3010 Processor to I/O Controller' class = bridge subclass = HOST-PCI pcib1@pci0:28:0: class=0x060400 card=0x27d08086 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:28:4: class=0x060400 card=0x27e08086 chip=0x27e08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801GR/GH/GHM (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:28:5: class=0x060400 card=0x27e28086 chip=0x27e28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801GR/GH/GHM (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:29:0: class=0x0c0300 card=0x348d8086 chip=0x27c88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0x348d8086 chip=0x27c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0x348d8086 chip=0x27ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:29:3: class=0x0c0300 card=0x348d8086 chip=0x27cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:29:7: class=0x0c0320 card=0x348d8086 chip=0x27cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib5@pci0:30:0: class=0x060401 card=0x348d8086 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/DBL/EB/ER/FB/GB/HB (ICH2/3/4/4/5/5/6/7/8), 63xxESB Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:31:0: class=0x060100 card=0x348d8086 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR (ICH7 Family) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0x348d8086 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1@pci0:31:2: class=0x01018f card=0x348d8086 chip=0x27c08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller' class = mass storage subclass = ATA none0@pci0:31:3: class=0x0c0500 card=0x348d8086 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus pcib2@pci1:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6702PXH PCI Express-to-PCI Express Bridge' class = bridge subclass = PCI-PCI twe0@pci2:2:0: class=0x010400 card=0x100113c1 chip=0x100113c1 rev=0x01 hdr=0x00 vendor = '3ware Inc.' device = '7000/8000 series ATA-133 Storage Controller' class = mass storage subclass = RAID em0@pci4:0:0: class=0x020000 card=0x348d8086 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PM' class = network subclass = ethernet none1@pci4:0:3: class=0x070002 card=0x00008086 chip=0x108f8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Active Management Technology - SOL' class = simple comms subclass = UART none2@pci4:0:4: class=0x0c0701 card=0x00008086 chip=0x108e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Active Management Technology - KCS' class = serial bus vgapci0@pci5:4:0: class=0x030000 card=0x348d8086 chip=0x515e1002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc.' device = 'Radeon ES1000 Radeon ES1000' class = display subclass = VGA em1@pci5:5:0: class=0x020000 card=0x348d8086 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet file1# vmstat -i interrupt total rate irq14: ata0 33303 6 irq17: em1 1090040 205 irq18: uhci2 713 0 irq19: uhci1+ 444774 83 irq23: uhci0 ehci0 1 0 irq35: twe0 319034 60 cpu0: timer 10622737 1998 irq256: em0 16057387 3020 cpu1: timer 10620606 1997 Total 39188595 7371 >Release-Note: >Audit-Trail: >Unformatted: