From owner-freebsd-amd64@FreeBSD.ORG Sun May 8 05:41:48 2011 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A90106564A; Sun, 8 May 2011 05:41:47 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5AF8FC08; Sun, 8 May 2011 05:41:47 +0000 (UTC) Received: by iwn33 with SMTP id 33so5081681iwn.13 for ; Sat, 07 May 2011 22:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F06yVEXVgp6TZzW4RsOw7ukHx3tGWhPopRk8exrDHj8=; b=bDpJFhKv29vD0ZkQjI5ngQfzzdqLGJNAUzVyN+y6GFoBKbHQQ1mMko8mVGdHfLgrVm t01/ISCOqjbHWItqHqvAvqvtPUIvsK6APWz6DCe1m7JRQppK6o18NCUsNLB/CbhgYqNt pYNotzjdQT5OmOUTeru8ehk+00JV9ugGR9P90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hhqinhWVUr7szfpKHgfChg8LdHbYH4DPlyTJDgJO3vg27S7Fm7c9iKCw2nElgANOAj U+ZndvryLA97myHUbghIi7c9D6qmtBi4CecGTjeyMsbiqCjybBQffMj2RAobcckem0Gc I9Hb7KKnqgTjjFtwhzHO298VhYdKclzQvJPPI= MIME-Version: 1.0 Received: by 10.43.44.6 with SMTP id ue6mr4563918icb.69.1304831635777; Sat, 07 May 2011 22:13:55 -0700 (PDT) Received: by 10.42.167.5 with HTTP; Sat, 7 May 2011 22:13:55 -0700 (PDT) In-Reply-To: <20110507101105.GA32422@freebsd.org> References: <201105070452.p474qvuw097711@freebsd-current.sentex.ca> <20110507101105.GA32422@freebsd.org> Date: Sun, 8 May 2011 01:13:55 -0400 Message-ID: From: Arnaud Lacombe To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 08 May 2011 11:08:54 +0000 Cc: amd64@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 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, 08 May 2011 05:41:48 -0000 Hi, On Sat, May 7, 2011 at 6:11 AM, Alexander Best wrote: >> [...] >> ld -b binary -d -warn-common -r -d -o wpifw.fwo wpi.fw >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 = =A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-s= ign -fformat-extensions =A0-Wmissing-include-dirs -nostdinc =A0-I. -I/src/s= ys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include = opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -DGPROF -falign-functions=3D16 = -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=3Dkernel -m= no-red-zone =A0-mfpmath=3D387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-s= se3 =A0-msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-= protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.c >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 = =A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-s= ign -fformat-extensions =A0-Wmissing-include-dirs -nostdinc =A0-I. -I/src/s= ys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include = opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -DGPROF -falign-functions=3D16 = -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=3Dkernel -m= no-red-zone =A0-mfpmath=3D387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-s= se3 =A0-msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-= protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.c >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 = =A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-s= ign -fformat-extensions =A0-Wmissing-include-dirs -nostdinc =A0-I. -I/src/s= ys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include = opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -DGPROF -falign-functions=3D16 = -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=3Dkernel -m= no-red-zone =A0-mfpmath=3D387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-s= se3 =A0-msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-= protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c > > could somebody explain, why only on amd64 the default COPTFLAGS are -O2 > -frename-registers (even with DEBUG set)? judging from gcc(1) expecially > -frename-registers makes debugging very hard. > -> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/kern.pre.mk#rev1.45 A. From owner-freebsd-amd64@FreeBSD.ORG Mon May 9 06:30:18 2011 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 221BA106566B for ; Mon, 9 May 2011 06:30:18 +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 DB3ED8FC19 for ; Mon, 9 May 2011 06:30:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p496UHeQ083618 for ; Mon, 9 May 2011 06:30:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p496UH8e083614; Mon, 9 May 2011 06:30:17 GMT (envelope-from gnats) Resent-Date: Mon, 9 May 2011 06:30:17 GMT Resent-Message-Id: <201105090630.p496UH8e083614@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, Igor Polovykh Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27FF1106564A for ; Mon, 9 May 2011 06:25:16 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 19FE88FC14 for ; Mon, 9 May 2011 06:25:16 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p496PFcq064094 for ; Mon, 9 May 2011 06:25:15 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p496PFpO064093; Mon, 9 May 2011 06:25:15 GMT (envelope-from nobody) Message-Id: <201105090625.p496PFpO064093@red.freebsd.org> Date: Mon, 9 May 2011 06:25:15 GMT From: Igor Polovykh To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Mon, 09 May 2011 10:58:28 +0000 Cc: Subject: amd64/156898: usb keyboard does not work while boot (ps2 keyboard works perfect) 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, 09 May 2011 06:30:18 -0000 >Number: 156898 >Category: amd64 >Synopsis: usb keyboard does not work while boot (ps2 keyboard works perfect) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 09 06:30:16 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Igor Polovykh >Release: 8.2 >Organization: BVG Studio >Environment: [ip@?????.org /]$ uname -a FreeBSD bvgm.org 8.2-STABLE FreeBSD 8.2-STABLE #15: Thu Apr 28 01:40:03 MSD 2011 root@:/usr/src/sys/amd64/compile/BVGM amd64 >Description: when /etc/fstab file is corrupt and we can not boot normally. We get this error and cannot use usb keyboard to make something. Root mount waiting for: usbus1 Trying to mount root from ufs:/dev/ad4s1a ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. Loader variables: vfs.root.mountfrom=ufs:/dev/ad4s1a vfs.root.mountfrom.options=rw mount> >How-To-Repeat: 1. attach usb keyboard to PC. 2. make corrupt file /etc/fstab to stop normal mounting from root partition (example change filesystem type from UFS to UFS2) 3. When you try to boot you won't be able to use usb keyboard to point right partition to mount (ps2 keyboard works ok). You'll see the message like noted in Full Description section. >Fix: I think the code that support usb keyboard have to load first. I guess there is some workaround but i am not so smart in FreeBSD boot loader to find it. Perhaps this is a right behavior of boot loader ( by designed :), i do not know. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon May 9 11:07:01 2011 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 6B9781065675 for ; Mon, 9 May 2011 11:07:01 +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 502568FC08 for ; Mon, 9 May 2011 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p49B71Fw070555 for ; Mon, 9 May 2011 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p49B70k7070553 for freebsd-amd64@FreeBSD.org; Mon, 9 May 2011 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 May 2011 11:07:00 GMT Message-Id: <201105091107.p49B70k7070553@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 Cc: Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org 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, 09 May 2011 11:07:01 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/156898 amd64 usb keyboard does not work while boot (ps2 keyboard wo o amd64/156719 amd64 ab: apr_socket_recv: Connection reset by peer (54) o amd64/156464 amd64 fpsetprec does not work o amd64/156106 amd64 [boot] boot0 fails to start o amd64/156074 amd64 [hang] Removing CD-Rom from Lenovo T61p hangs system o amd64/156014 amd64 [hang] FreeBSD 8.2-RELEASE amd64 freeze and crash o amd64/155249 amd64 [build] 8.1 buildworld failure o amd64/155135 amd64 [boot] Does Not Boot On a Very Standard Hardware o amd64/154957 amd64 [boot] Install boot CD won't boot up - keeps rebooting o amd64/154629 amd64 [panic] Fatal trap 9: general protection fault while i o amd64/153935 amd64 [hang] system hangs while trying to do 'shutdown -h no o amd64/153831 amd64 [boot] CD bootloader won't on Tyan s2912G2nr o amd64/153496 amd64 [hyper-v] [install] Install on Hyper-V leaves corrupt o amd64/153372 amd64 [panic] kernel panic o amd64/153175 amd64 [amd64] Kernel Panic on only FreeBSD 8 amd64 o amd64/152874 amd64 [install] 8.1 install fails where 7.3 works due to lac o amd64/152430 amd64 [boot] HP ProLiant Microserver n36l cannot boot into i o amd64/151385 amd64 [boot] Installation hangs on MacBook o amd64/150170 amd64 [patch] [amd64] [headers] SIG_ATOMIC_MIN/SIG_ATOMIC_MA o amd64/145991 amd64 [NOTES] [patch] Add a requires line to /sys/amd64/conf o amd64/144405 amd64 [build] [patch] include /usr/obj/lib32 in cleanworld t s amd64/143173 amd64 [ata] Promise FastTrack TX4 + SATA DVD, installer can' f amd64/141413 amd64 [hang] Tyan 2881 m3289 SMDC freeze o amd64/141060 amd64 [install] Can't install 8.0-RELEASE on the server wher o amd64/140715 amd64 [boot] Dell M600 Blade fails to boot 7.2+ 64 bit o amd64/139998 amd64 [panic][net] 7.2 amd64 panic in rtrequest1_fib o amd64/139924 amd64 [boot] cd or dvd not load o amd64/138029 amd64 [panic][bpf] periodically kernel panic and reboot o amd64/137942 amd64 [pci] 8.0-BETA2 having problems with Asus M2N-SLI-delu o amd64/135265 amd64 [mpt] Boot from install cd hangs on HP DL160 G5 with L o amd64/135040 amd64 [ata] FreeBSD/amd64 does not (always) detect disk on S o amd64/133977 amd64 [panic] [ffs] "panic: ffs_blkfree: freeing free block" o amd64/133701 amd64 Recompiling the kernel with k8temp or smbios break GEO o amd64/132574 amd64 [boot] [hang] Freeze on bootstrap loader (CD) using AT o amd64/131456 amd64 [acpi] [ata] ACPI & ATA problems s amd64/131209 amd64 [panic] [bce] 7.1-STABLE amd64 crash - m0 NULL o amd64/130368 amd64 [hang] Switching from xorg to console locks up compute o amd64/129889 amd64 [boot] [hang] The booting process stops at the line mo o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [em] amd64 motherboard: Intel DG965WH motherboard comp o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/127640 amd64 [amd64] gcc(1) will not build shared libraries with -f o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 51 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon May 9 16:31:49 2011 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 5661E106566C for ; Mon, 9 May 2011 16:31:49 +0000 (UTC) (envelope-from lists@wcubed.net) Received: from mail.datausa.com (mail.datausa.com [216.150.220.220]) by mx1.freebsd.org (Postfix) with SMTP id 18FDF8FC0A for ; Mon, 9 May 2011 16:31:49 +0000 (UTC) Received: (qmail 7776 invoked by uid 89); 9 May 2011 10:31:48 -0600 Received: from c-174-51-28-95.hsd1.co.comcast.net (HELO ?10.0.1.1?) (brad@wcubed.net@174.51.28.95) by mail.datausa.com with SMTP; 9 May 2011 10:31:48 -0600 Message-ID: <4DC816F4.1030406@wcubed.net> Date: Mon, 09 May 2011 10:31:48 -0600 From: Brad Waite User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Understanding i386 PAE 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, 09 May 2011 16:31:49 -0000 Hi all, I've got some questions about i386 PAE. I was pointed towards this list, but if another is more appropriate, just let me know. I also know that i386 PAE is the ugly, red-headed step-child of FreeBSD. Kindly keep the standard "why don't you use amd64" statements to a minimum. My aim is to gain an accurate understanding of how things work with my antiquated and lowly 32-bit hardware. Based on my research, hardware w/PAE support can address up to 64G of memory via a 36-bit addressing scheme. However, since an i386 process can only address 32 bits, each process gets at most 4G of that 64G. In my case, my Intel SE7501BR2, dual 2GHz Xeon server supports 8G max and I want to use 6G, maximizing the kernel memory. I understand that KVA_PAGES determines the amount of memory reserved for the kernel, and therefore userland processes. But where does the kernel fit into that 32-bit/4G limit? My original understanding was that the kernel was a process, just like userland ones, and could address 4G and therefore I could split my 6G into 4G for the kernel and 2G for userland (KVA_PAGES = 2048). I've been informed that PAE doesn't actually work that way. Instead, the kernel-reserved memory is per-process and setting KVA_PAGES to 2048 means the kernel takes up all of the 4G of a process' addressable memory, which obviously won't work. Is the latter actually the case or is my original understanding correct? Or is it somewhere in between? Thanks! From owner-freebsd-amd64@FreeBSD.ORG Mon May 9 17:38:26 2011 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 B3DC2106564A for ; Mon, 9 May 2011 17:38:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5A18FC12 for ; Mon, 9 May 2011 17:38:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2A45446B06; Mon, 9 May 2011 13:38:26 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B6D3C8A01B; Mon, 9 May 2011 13:38:25 -0400 (EDT) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Mon, 9 May 2011 13:27:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DC816F4.1030406@wcubed.net> In-Reply-To: <4DC816F4.1030406@wcubed.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105091327.36809.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 09 May 2011 13:38:25 -0400 (EDT) Cc: Subject: Re: Understanding i386 PAE 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, 09 May 2011 17:38:26 -0000 On Monday, May 09, 2011 12:31:48 pm Brad Waite wrote: > Hi all, I've got some questions about i386 PAE. I was pointed towards > this list, but if another is more appropriate, just let me know. > > I also know that i386 PAE is the ugly, red-headed step-child of FreeBSD. > Kindly keep the standard "why don't you use amd64" statements to a > minimum. My aim is to gain an accurate understanding of how things work > with my antiquated and lowly 32-bit hardware. > > Based on my research, hardware w/PAE support can address up to 64G of > memory via a 36-bit addressing scheme. However, since an i386 process > can only address 32 bits, each process gets at most 4G of that 64G. In > my case, my Intel SE7501BR2, dual 2GHz Xeon server supports 8G max and I > want to use 6G, maximizing the kernel memory. > > I understand that KVA_PAGES determines the amount of memory reserved for > the kernel, and therefore userland processes. But where does the kernel > fit into that 32-bit/4G limit? > > My original understanding was that the kernel was a process, just like > userland ones, and could address 4G and therefore I could split my 6G > into 4G for the kernel and 2G for userland (KVA_PAGES = 2048). > > I've been informed that PAE doesn't actually work that way. Instead, the > kernel-reserved memory is per-process and setting KVA_PAGES to 2048 > means the kernel takes up all of the 4G of a process' addressable > memory, which obviously won't work. > > Is the latter actually the case or is my original understanding correct? > Or is it somewhere in between? FreeBSD uses a shared address space on x86 (both i386 and amd64) where the kernel is mapped into every process' address space at a fixed address. This makes it cheaper and easier to copy data between a user process and the kernel since you don't have to temporarily map user pages into the kernel's address space, etc. It is possible to use separate address spaces for the kernel and userland (other OS's have done this) so that you could have 4G for the kernel and 4G for userland. However, this would require a good bit of work in the kernel (e.g. copyin/copyout would have to start mapping user pages at temporary addresses in the kernel). As you have noted, PAE does not increas your virtual address space, merely your phyiscal address space by changing PTEs to use 64-bit physical addresses instead of 32-bit physical addresses. However, each process can only address up to 4G of RAM at a time. -- John Baldwin From owner-freebsd-amd64@FreeBSD.ORG Mon May 9 18:25:52 2011 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 DB5751065674 for ; Mon, 9 May 2011 18:25:52 +0000 (UTC) (envelope-from lists@wcubed.net) Received: from mail.datausa.com (mail.datausa.com [216.150.220.220]) by mx1.freebsd.org (Postfix) with SMTP id B6D278FC0C for ; Mon, 9 May 2011 18:25:52 +0000 (UTC) Received: (qmail 40478 invoked by uid 89); 9 May 2011 12:25:51 -0600 Received: from c-174-51-28-95.hsd1.co.comcast.net (HELO ?10.0.1.1?) (brad@wcubed.net@174.51.28.95) by mail.datausa.com with SMTP; 9 May 2011 12:25:51 -0600 Message-ID: <4DC831AE.1070103@wcubed.net> Date: Mon, 09 May 2011 12:25:50 -0600 From: Brad Waite User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: John Baldwin References: <4DC816F4.1030406@wcubed.net> <201105091327.36809.jhb@freebsd.org> In-Reply-To: <201105091327.36809.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: Understanding i386 PAE 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, 09 May 2011 18:25:52 -0000 On 5/9/2011 11:27 AM, John Baldwin wrote: Thanks for the clarification, John. > FreeBSD uses a shared address space on x86 (both i386 and amd64) where > the kernel is mapped into every process' address space at a fixed address. > This makes it cheaper and easier to copy data between a user process and the > kernel since you don't have to temporarily map user pages into the kernel's > address space, etc. That's disappointing for my use, but it make sense. > It is possible to use separate address spaces for the kernel and userland > (other OS's have done this) so that you could have 4G for the kernel and 4G > for userland. However, this would require a good bit of work in the kernel > (e.g. copyin/copyout would have to start mapping user pages at temporary > addresses in the kernel). Would be handy to be able to use memory this way, but if I were responsible for making it happen, I'm sure that we'd be on amd128 before it was finished. ;) > As you have noted, PAE does not increase your virtual address space, merely > your physical address space by changing PTEs to use 64-bit physical addresses > instead of 32-bit physical addresses. However, each process can only address > up to 4G of RAM at a time. So given the shared address space, the amount of memory the kernel can use doesn't benefit much from PAE. I can see how typical installs with lots/big userland processes and the standard 1G KVA would benefit, though. Since I'm trying to eke as much memory as I can for ZFS, I don't gain much. I suppose I could allocate 3.75G for the kernel, assuming that none of my userland processes need more than .25G (or that if they do, swapping to disk is okay). Would that be pushing it? I've come across a few things about hardware addresses eating up 256M - 512M of RAM - is that still the case with PAE? If that is pushing it, what's the max KVA you'd recommend. From owner-freebsd-amd64@FreeBSD.ORG Mon May 9 19:06:21 2011 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 B0268106566C; Mon, 9 May 2011 19:06:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 32DAB8FC16; Mon, 9 May 2011 19:06:20 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p49J6EiU083388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 22:06:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p49J6ECo076888; Mon, 9 May 2011 22:06:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p49J6EZq076887; Mon, 9 May 2011 22:06:14 +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, 9 May 2011 22:06:14 +0300 From: Kostik Belousov To: Brad Waite Message-ID: <20110509190614.GJ48734@deviant.kiev.zoral.com.ua> References: <4DC816F4.1030406@wcubed.net> <201105091327.36809.jhb@freebsd.org> <4DC831AE.1070103@wcubed.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Z/W+H++SBmO57jII" Content-Disposition: inline In-Reply-To: <4DC831AE.1070103@wcubed.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-amd64@freebsd.org Subject: Re: Understanding i386 PAE 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, 09 May 2011 19:06:21 -0000 --Z/W+H++SBmO57jII Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2011 at 12:25:50PM -0600, Brad Waite wrote: > On 5/9/2011 11:27 AM, John Baldwin wrote: >=20 > Thanks for the clarification, John. >=20 > > FreeBSD uses a shared address space on x86 (both i386 and amd64) where > > the kernel is mapped into every process' address space at a fixed addre= ss. =20 > > This makes it cheaper and easier to copy data between a user process an= d the=20 > > kernel since you don't have to temporarily map user pages into the kern= el's=20 > > address space, etc. >=20 > That's disappointing for my use, but it make sense. >=20 > > It is possible to use separate address spaces for the kernel and userla= nd=20 > > (other OS's have done this) so that you could have 4G for the kernel an= d 4G=20 > > for userland. However, this would require a good bit of work in the ke= rnel=20 > > (e.g. copyin/copyout would have to start mapping user pages at temporar= y=20 > > addresses in the kernel). >=20 > Would be handy to be able to use memory this way, but if I were > responsible for making it happen, I'm sure that we'd be on amd128 before > it was finished. ;) Jeff had patches that implemented this. Redhat did patched their kernel for some time, but finally decided not to do anymore. It is much more trouble then the gain on x86. >=20 > > As you have noted, PAE does not increase your virtual address space, me= rely=20 > > your physical address space by changing PTEs to use 64-bit physical add= resses=20 > > instead of 32-bit physical addresses. However, each process can only a= ddress=20 > > up to 4G of RAM at a time. >=20 > So given the shared address space, the amount of memory the kernel can > use doesn't benefit much from PAE. I can see how typical installs with > lots/big userland processes and the standard 1G KVA would benefit, > though. Since I'm trying to eke as much memory as I can for ZFS, I don't > gain much. >=20 > I suppose I could allocate 3.75G for the kernel, assuming that none of > my userland processes need more than .25G (or that if they do, swapping > to disk is okay). I am sure it will not even start init(8). Note that 250Mb is the _virtual address space_, and not the physical memory available to=20 the process. Well, init(8) is static, so it might start, but I am sure that e.g. sh(1) will not. Also, even if you allocate ~3GB for kernel KVA, the amount of space available for ZFS cache will be less then this, probably much less. Due to other kernel users for VA, and due to fragmentation. >=20 > Would that be pushing it? I've come across a few things about hardware > addresses eating up 256M - 512M of RAM - is that still the case with > PAE? If that is pushing it, what's the max KVA you'd recommend. First, you should indeed understand the difference between physical memory pages (which PAE allows to have large pool of) and virtual address space. After that, you would see clearly that what you are trying to do is mostly a waste. Esp. due to ZFS architecture of having directly addressed pages in the cache. UFS with page cache/buffers would use as much pages as provided for caching. --Z/W+H++SBmO57jII Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3IOyYACgkQC3+MBN1Mb4gVTgCfb5TUcubh2SuyVbzVVvu3pzwx qrkAn1s/Ltq9jqE04C/deV7vrWC0QvM1 =9Nq0 -----END PGP SIGNATURE----- --Z/W+H++SBmO57jII-- From owner-freebsd-amd64@FreeBSD.ORG Tue May 10 19:19:43 2011 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 2C7F21065670; Tue, 10 May 2011 19:19:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 036E48FC15; Tue, 10 May 2011 19:19:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4AJJgO5070125; Tue, 10 May 2011 19:19:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4AJJgZr070121; Tue, 10 May 2011 19:19:42 GMT (envelope-from linimon) Date: Tue, 10 May 2011 19:19:42 GMT Message-Id: <201105101919.p4AJJgZr070121@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-usb@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: usb/156898: [keyboard] usb keyboard does not work while boot (ps2 keyboard works perfect) 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, 10 May 2011 19:19:43 -0000 Old Synopsis: usb keyboard does not work while boot (ps2 keyboard works perfect) New Synopsis: [keyboard] usb keyboard does not work while boot (ps2 keyboard works perfect) Responsible-Changed-From-To: freebsd-amd64->freebsd-usb Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 10 19:19:26 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=156898 From owner-freebsd-amd64@FreeBSD.ORG Thu May 12 03:00:13 2011 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D64A106564A; Thu, 12 May 2011 03:00:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 227B48FC13; Thu, 12 May 2011 03:00:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p4C30AA2005763; Wed, 11 May 2011 23:00:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p4C30AiA005754; Thu, 12 May 2011 03:00:10 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 May 2011 03:00:10 GMT Message-Id: <201105120300.p4C30AiA005754@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 03:00:13 -0000 TB --- 2011-05-12 00:20:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-12 00:20:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-05-12 00:20:01 - cleaning the object tree TB --- 2011-05-12 00:20:26 - cvsupping the source tree TB --- 2011-05-12 00:20:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-05-12 00:26:02 - building world TB --- 2011-05-12 00:26:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-12 00:26:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-12 00:26:02 - TARGET=amd64 TB --- 2011-05-12 00:26:02 - TARGET_ARCH=amd64 TB --- 2011-05-12 00:26:02 - TZ=UTC TB --- 2011-05-12 00:26:02 - __MAKE_CONF=/dev/null TB --- 2011-05-12 00:26:02 - cd /src TB --- 2011-05-12 00:26:02 - /usr/bin/make -B buildworld >>> World build started on Thu May 12 00:26:02 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu May 12 02:50:42 UTC 2011 TB --- 2011-05-12 02:50:42 - generating LINT kernel config TB --- 2011-05-12 02:50:42 - cd /src/sys/amd64/conf TB --- 2011-05-12 02:50:42 - /usr/bin/make -B LINT TB --- 2011-05-12 02:50:42 - building LINT kernel TB --- 2011-05-12 02:50:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-12 02:50:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-12 02:50:42 - TARGET=amd64 TB --- 2011-05-12 02:50:42 - TARGET_ARCH=amd64 TB --- 2011-05-12 02:50:42 - TZ=UTC TB --- 2011-05-12 02:50:42 - __MAKE_CONF=/dev/null TB --- 2011-05-12 02:50:42 - cd /src TB --- 2011-05-12 02:50:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu May 12 02:50:42 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/sound/pci/solo.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/sound/pci/spicds.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/sound/pci/t4dwave.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/sound/pci/via8233.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/sound/pci/via82c686.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/sound/pci/vibes.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/sound/pci/hda/hdac.c /src/sys/dev/sound/pci/hda/hdac.c:499: error: 'HDA_INTEL_PPT' undeclared here (not in a function) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-12 03:00:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-12 03:00:10 - ERROR: failed to build lint kernel TB --- 2011-05-12 03:00:10 - 7291.52 user 1345.65 system 9609.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Fri May 13 04:09:46 2011 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 2708C1065678; Fri, 13 May 2011 04:09:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F1C558FC13; Fri, 13 May 2011 04:09:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4D49jH5069433; Fri, 13 May 2011 04:09:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4D49jgJ069429; Fri, 13 May 2011 04:09:45 GMT (envelope-from linimon) Date: Fri, 13 May 2011 04:09:45 GMT Message-Id: <201105130409.p4D49jgJ069429@freefall.freebsd.org> To: freebsd@it-psycho.de, linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: ports/156719: ab: apr_socket_recv: Connection reset by peer (54) 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: Fri, 13 May 2011 04:09:46 -0000 Synopsis: ab: apr_socket_recv: Connection reset by peer (54) State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Fri May 13 04:09:20 UTC 2011 State-Changed-Why: To which apache port does this PR apply? Responsible-Changed-From-To: freebsd-amd64->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 13 04:09:20 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=156719