From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 04:24:48 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F78616A41F for ; Sun, 22 May 2005 04:24:48 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 095FA43D1F for ; Sun, 22 May 2005 04:24:45 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 33BC04DC5F; Sun, 22 May 2005 04:24:56 +0000 (GMT) Received: from [10.0.0.8] (adsl-143-85.swiftdsl.com.au [218.214.143.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 469DB4DC4F; Sun, 22 May 2005 04:24:55 +0000 (GMT) Message-ID: <4290098B.6020405@roq.com> Date: Sun, 22 May 2005 14:24:43 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.8) Gecko/20050518 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Toll, Eric" References: <9BC86C67C3AF7646B9C5382020457A9456E91B@VIP10-WIN2K> In-Reply-To: <9BC86C67C3AF7646B9C5382020457A9456E91B@VIP10-WIN2K> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP cc: freebsd-amd64@freebsd.org Subject: Re: FreeBSD AMD64 Ubench 0.3 results X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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, 22 May 2005 04:24:48 -0000 Here are mine first here is my Amd 64 Laptop.. ASUS A4K 3400+ 512meg ram *FreeBSD 5.4-STABLE FreeBSD 5.4-STABLE #1: Wed May 18 18:06:23 EST 2005 michael@mikeslaptop:/usr/obj/usr/src/sys/GENERIC amd64 Ubench CPU: 119460 Ubench MEM: 108405 -------------------- Ubench AVG: 113932 * Here is a Dell 1850 Dual CPU with 4 Gigs of ram, thats in idle CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.23-MHz 686-class CPU) FreeBSD 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #0: Sun May 22 12:23:00 EST 2005 root@dagobah:/usr/obj/usr/src/sys/SMP i386 Ubench CPU: 170748 Ubench MEM: 172775 -------------------- Ubench AVG: 171761 Toll, Eric wrote: >I realize this is a bit off topic, but I am trying to see if I have the AMD64 >5.4 Kernel and my Hardware setup properly. The first time I ran it, my system >crashed hard. After I adjusted a few BIOS entries I got the results below >reliably time after time. FWIW Ubench seems to be a good torture test for a new >box setup. > >I have Dual Opteron 242's, and 1 Gb of Kingston ECC Registered DDR400 Ram >(non-interleaved mode) Would anyone be kind enough to post their scores and >basic hardware config? The scores on the Ubench site seem a bit stale. > >I used the ubench in /usr/ports with no special compile flags e.g. 'make >install' >I think the low RAM score is due to the fact I have only 1Gb. > > >My scores were/are: > >Ubench CPU: 178450 >Ubench MEM: 156069 >-------------------- >Ubench AVG: 167259 > > > >Regards, >Eric > >_______________________________________________ >freebsd-amd64@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 >To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 04:33:05 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4E0D16A41F for ; Sun, 22 May 2005 04:33:04 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 329F043D54 for ; Sun, 22 May 2005 04:33:03 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id 7869078C75 for ; Sun, 22 May 2005 00:33:03 -0400 (EDT) Received: from pandora.afflictions.org ([127.0.0.1]) by localhost (pandora.afflictions.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41058-05 for ; Sun, 22 May 2005 00:32:55 -0400 (EDT) Received: from dementia.afflictions.org (dementia.afflictions.org [172.19.206.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pandora.afflictions.org (Postfix) with ESMTP id 05ABB78C72 for ; Sun, 22 May 2005 00:32:54 -0400 (EDT) Received: by dementia.afflictions.org (Postfix, from userid 1001) id 2E0E333C7B; Sun, 22 May 2005 00:32:52 -0400 (EDT) Date: Sun, 22 May 2005 00:32:52 -0400 From: Damian Gerow To: freebsd-amd64@freebsd.org Message-ID: <20050522043251.GA87263@afflictions.org> Mail-Followup-To: freebsd-amd64@freebsd.org References: <20050521022130.GW52914@afflictions.org> <20050521064120.GA51907@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050521064120.GA51907@xor.obsecurity.org> X-GPG-Fingerprint: B3D7 D901 A53A 1A99 BFD6 E6DF 9F3B 742B C288 9CC9 User-Agent: Mutt/1.5.9i X-Virus-Scanned: amavisd-new at pandora.afflictions.org Subject: Re: mplayer, amd64, and CPU flags X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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, 22 May 2005 04:33:05 -0000 Thus spake Kris Kennaway (kris@obsecurity.org) [21/05/05 02:42]: : > This is with automagic CPU detection compiled in, but when I take it out, I : > still get the same thing. : : Look at what the port does..it looks like it only enables runtime : detection support on i386. Talk to the maintainer. The wording in the Makefile describing WITHOUT_RUNTIME_CPUDETECTION -- which I traditionally define when building mplayer -- infers that by defining it, all possible CPU flags are assumed set, and it is up to the builder to "explicitly disable" them. In other words, without using runtime detection, it's still borked. I'll take that up with the maintainer as well. Though it looks like the problem is well on its way to being solved. FWIW, by manually enabling the various flags, I see DVD decryption jump up at least five frames per second, from anywhere between seven and ten to at least fifteen. That's a 50% speed increase. From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 11:36:27 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 675BC16A41C for ; Sun, 22 May 2005 11:36:27 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (hood.oook.cz [212.27.205.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D8F443D48 for ; Sun, 22 May 2005 11:36:26 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (localhost.oook.cz [127.0.0.1]) by hood.oook.cz (8.13.3/8.13.3) with ESMTP id j4MBZAXp084330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 May 2005 13:35:10 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by hood.oook.cz (8.13.3/8.13.3/Submit) id j4MBZ5id084311; Sun, 22 May 2005 13:35:05 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: hood.oook.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: Damian Gerow In-Reply-To: <20050522043251.GA87263@afflictions.org> References: <20050521022130.GW52914@afflictions.org> <20050521064120.GA51907@xor.obsecurity.org> <20050522043251.GA87263@afflictions.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3tdm74bcYMH8vIJ/DOVx" Date: Sun, 22 May 2005 13:35:05 +0200 Message-Id: <1116761705.23538.7.camel@hood.oook.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Cc: freebsd-amd64@FreeBSD.org Subject: Re: mplayer, amd64, and CPU flags X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 11:36:27 -0000 --=-3tdm74bcYMH8vIJ/DOVx Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Damian Gerow p=ED=B9e v ne 22. 05. 2005 v 00:32 -0400: > Thus spake Kris Kennaway (kris@obsecurity.org) [21/05/05 02:42]: > : > This is with automagic CPU detection compiled in, but when I take it = out, I > : > still get the same thing. > :=20 > : Look at what the port does..it looks like it only enables runtime > : detection support on i386. Talk to the maintainer. >=20 > The wording in the Makefile describing WITHOUT_RUNTIME_CPUDETECTION -- wh= ich > I traditionally define when building mplayer -- infers that by defining i= t, > all possible CPU flags are assumed set, and it is up to the builder to > "explicitly disable" them. In other words, without using runtime detecti= on, > it's still borked. >=20 > I'll take that up with the maintainer as well. Though it looks like the > problem is well on its way to being solved. >=20 > FWIW, by manually enabling the various flags, I see DVD decryption jump u= p > at least five frames per second, from anywhere between seven and ten to a= t > least fifteen. That's a 50% speed increase. I haven't noticed any speedup on DVD playback from these flags. What helped me immensely was moving to xorg-server-snap, which can do DMA'ed xv feeding on radeon driver. That cut down CPU usage inside xorg from 30% to 5% on DVD playback with mplayer ... --=20 Pav Lucistnik Stupidity got us into this mess -- why can't it get us out? --=-3tdm74bcYMH8vIJ/DOVx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCkG5pntdYP8FOsoIRAobIAJ46J8ovs6b0xdcNz06rziRHNfRrBwCgnsad jkuTeen92scc93nEyD89wZY= =ks1w -----END PGP SIGNATURE----- --=-3tdm74bcYMH8vIJ/DOVx-- From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 19:22:00 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 028CD16A41C for ; Sun, 22 May 2005 19:22:00 +0000 (GMT) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 679AD43D1D for ; Sun, 22 May 2005 19:21:59 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP id j4MJLuGu016829 (8.13.2/1.4); Sun, 22 May 2005 21:21:56 +0200 (MET DST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP id j4MJLuFM027896 (8.13.2/2.02); Sun, 22 May 2005 21:21:56 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 22 May 2005 21:21:56 +0200 (MEST) From: Michiel Boland To: Pav Lucistnik In-Reply-To: <1116697452.79313.31.camel@hood.oook.cz> Message-ID: References: <20050521022130.GW52914@afflictions.org> <20050521105451.V92958@fw.reifenberger.com> <200505211237.00974.loox@e-shell.net> <1116697452.79313.31.camel@hood.oook.cz> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-1116789664=:27863" Content-ID: Cc: riggs@rrr.de, freebsd-amd64@freebsd.org Subject: Re: mplayer, amd64, and CPU flags [patch] 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, 22 May 2005 19:22:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1804928587-1116789664=:27863 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Rather than hack the port Makefile, I think it is better to fix cpuinfo.c. I placed the attached patch-TOOLS-cpuinfo.c in ports/multimedia/mplayer/files and then recompiled mplayer. It now detects the cpu properly. I am CC-ing this to the port maintainer; hopefully this can be merged into the real source somehow. $ mplayer MPlayer 1.0pre7-3.4.2 (C) 2000-2005 MPlayer Team CPU: Advanced Micro Devices (Family: 8, Stepping: 0) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 ---559023410-1804928587-1116789664=:27863 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=patch-TOOLS-cpuinfo.c Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=patch-TOOLS-cpuinfo.c LS0tIFRPT0xTL2NwdWluZm8uYy5vcmlnCU1vbiBPY3QgMTEgMjE6MjY6MTMg MjAwNA0KKysrIFRPT0xTL2NwdWluZm8uYwlTdW4gTWF5IDIyIDIwOjU3OjEx IDIwMDUNCkBAIC00MCwxMyArNDAsOSBAQA0KIGNwdWlkKGludCBmdW5jKSB7 DQogCWNwdWlkX3JlZ3NfdCByZWdzOw0KICNkZWZpbmUJQ1BVSUQJIi5ieXRl IDB4MGYsIDB4YTI7ICINCi0JYXNtKCJwdXNoICUlZWJ4OyAiDQotCSAgICAi bW92bCAlNCwlJWVheDsgIiBDUFVJRA0KLQkgICAgIm1vdmwgJSVlYXgsJTA7 IG1vdmwgJSVlYngsJTE7IG1vdmwgJSVlY3gsJTI7IG1vdmwgJSVlZHgsJTM7 ICINCi0JICAgICJwb3AgJSVlYngiDQotCQk6ICI9bSIgKHJlZ3MuZWF4KSwg Ij1tIiAocmVncy5lYngpLCAiPW0iIChyZWdzLmVjeCksICI9bSIgKHJlZ3Mu ZWR4KQ0KLQkJOiAiZyIgKGZ1bmMpDQotCQk6ICIlZWF4IiwgIiVlY3giLCAi JWVkeCIpOw0KKwlhc20oQ1BVSUQNCisJCTogIj1hIiAocmVncy5lYXgpLCAi PWIiIChyZWdzLmVieCksICI9YyIgKHJlZ3MuZWN4KSwgIj1kIiAocmVncy5l ZHgpDQorCQk6ICIwIiAoZnVuYykpOw0KIAlyZXR1cm4gcmVnczsNCiB9DQog DQo= ---559023410-1804928587-1116789664=:27863-- From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 19:25:22 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26EFD16A41C for ; Sun, 22 May 2005 19:25:22 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from anya.eboundary.com (anya.eboundary.com [69.90.127.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id C628543D1F for ; Sun, 22 May 2005 19:25:21 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from epicofti by anya.eboundary.com with local (Exim 4.51 (FreeBSD)) id 1DZw80-000I17-Kd; Sun, 22 May 2005 15:28:48 -0400 Received: from 127.0.0.1 ([127.0.0.1]) (SquirrelMail authenticated user freebsd@epicoftimewasted.com) by www.epicoftimewasted.com with HTTP; Sun, 22 May 2005 15:28:48 -0400 (EDT) Message-ID: <1503.127.0.0.1.1116790128.squirrel@www.epicoftimewasted.com> In-Reply-To: <428F7928.60406@samsco.org> References: <4905.127.0.0.1.1116698556.squirrel@www.epicoftimewasted.com> <428F7928.60406@samsco.org> Date: Sun, 22 May 2005 15:28:48 -0400 (EDT) From: "Ryan R." To: "Scott Long" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - anya.eboundary.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [1018 1019] / [26 6] X-AntiAbuse: Sender Address Domain - epicoftimewasted.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-amd64@freebsd.org Subject: Re: 5.4-RELEASE Athlon64 E3/E4 core support 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, 22 May 2005 19:25:22 -0000 > Ryan R. wrote: > >> First off, some info about my setup: >> >> Motherboard: DFI Lanparty SLI-DR, nForce4, socket 939 >> CPU: Athlon64 3700+ "San Diego" core, revision E4, socket 939, 1mb L2 >> cache >> Memory: 2x 512mb OCZ Value VX >> I've run prime95 in Windows for just over 84 hours, with zero errors. >> I've run memtest86+ for about 12 hours, with zero errors. >> >> Now, the problem is that I recently upgraded to this system from a >> socket >> 754 "Clawhammer" (C0 revision) setup, which worked perfectly in >> 5.3-RELEASE/amd64. Before I upgraded the hardware, I didn't think to >> rebuild the kernel/world with a clean make.conf and kernel config. When >> I >> booted the new machine, I got a kernel panic (fatal trap 9) on boot, >> between the detection of my drives and mounting root. I tried a few >> things to get it working, but to no avail. I then decided it has to be >> my >> old world/kernel, so I did a binary upgrade to 5.4-RELEASE/amd64. >> >> After doing the binary upgrade, the system would boot again (at first, >> anyways). Once the system had booted, I figured I should rebuild my >> ports. While I was watching the build, the kernel paniced again (I >> forgot >> the exact message, and I didn't copy it down). I once again tried a few >> things to get it to work, but since I had spent so much time trying to >> get >> it to work before the binary upgrade, I figured it'd be easier to just >> wipe the drive and start over fresh, that way I have a known good system >> to start with if any problems pop up. >> >> So, I wiped the drive, and installed 5.4-RELEASE/amd64 on it. Install >> went fine, system booted, but then the panics came back. It usually >> happened while building some ports, but it happened in a different spot >> each time, so it's not like one specific port was causing me problems. >> It >> also didn't happen only under load. >> >> Now, I have the problem narrowed down to one of two things: >> 1) The hardware is bad. This lead me to run the memtest/prime95 tests, >> but they revealed no problems. This leads me to option 2. >> 2) The amd64 build of FreeBSD. >> >> So, I once again wipe the drive, but this time I install >> 5.4-RELEASE/i386. >> It installs fine, and boots fine. One thing I notice during boot, is >> that SSE3 isn't detected by the kernel as a CPU feature anymore (amd64 >> build did detect it). I begin building all my ports, and I was able to >> get my system up and running without even a hint of trouble. >> >> >> So, I'm curious to know if there are any problems with the amd64 release >> with these E3/E4 revision CPUs, maybe relating to the SSE3 instructions? >> Is there anything I can try to narrow down what exactly is causing my >> hardware to panic? I know I should build a kernel with debugging >> support >> (I tried it before installing the i386 release, but got a kernel >> panic... >> go figure), but I probably wouldn't be able to see the problem in a >> trace >> if I tripped over it. >> >> Any help would be appreciated. Thanks. > > It's pretty hard to make an nForce chipset work under FreeBSD 5.x. The > biggest problem seems to be with how the legacy system clocks are > implemented, which FreeBSD 5.x and prior relies on. FreeBSD 6-CURRENT > uses a completely different method that is compatible with the nForce, > so I'd recommend trying that instead. I use it on my desktop nForce4 > machine without any problems (except for the buggy nve ethernet driver). > > Scott > Ok, I've installed 6-CURRENT, and so far things seem to be working, except for my SATA ports. On boot, I get a couple ata2 and ata3 CONNECT/DISCONNECT notices, and then this panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x50 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff80276652 stack pointer = 0x10:0xffffffffa556cac0 frame pointer = 0x10:0xffffffffa556cb10 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 = 8 (thread taskq) [thread pid 8 tid 100031 ] Stopped at device_attach+0x22: cmpq $0,0x50(%r13) db> trace Tracing pid 8 tid 100031 td 0xffffff003db6d4c0 device_attach() at device_attach+0x22 bus_generic_attach() at bus_generic_attach+0x18 ata_identify() at ata_identify+0xe6 ata_sata_phy_event() at ata_sata_phy_event+0xa2 taskqueue_run() at taskqueue_run+0x97 taskqueue_thread_loop() at taskqueue_thread_loop+0x2c fork_exit() at fork_exit+0xbb fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa556cd00, rbp = 0 --- Disabling my SATA ports allows the system to boot. For reference, I have two SATA drives, both are Maxtor 6B300S0/BANC1980, and they're both on the nvidia SATA ports. Moving the drives to the Silicon Image ports still gives me the CONNECT/DISCONNECT messages, but not the panic. I'm not using a GENERIC kernel any more (removed unused SCSI/RAID/network devices), I don't know if that poses any debugging problems. If it makes a difference, I'll rebuild the GENERIC kernel and get a dump from that. It's not much of an issue for me, since the drives are used for storage in Windows only, but still something to mention none the less. Sorry for the second e-mail btw Scott, forgot to CC the mailing list the first time. Ryan From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 20:27:01 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3819916A41C for ; Sun, 22 May 2005 20:27:01 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0243443D49 for ; Sun, 22 May 2005 20:26:58 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D527572DD4; Sun, 22 May 2005 13:26:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CFF7C72DCB; Sun, 22 May 2005 13:26:58 -0700 (PDT) Date: Sun, 22 May 2005 13:26:58 -0700 (PDT) From: Doug White To: Sean McNeil In-Reply-To: Message-ID: <20050522123938.I27009@carver.gumbysoft.com> References: <1116566651.1588.17.camel@server.mcneil.com> <20050520135046.T8229@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: amd64@freebsd.org Subject: Re: help with GPF on 5.4-STABLE 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, 22 May 2005 20:27:01 -0000 Answer is inline, but a ways down. On Fri, 20 May 2005, Sean McNeil wrote: > Doug, > > Thanks for helping me look into this. > > On May 20, 2005, at 1:59 PM, Doug White wrote: > > > Lets prune this down: > > > > On Thu, 19 May 2005, Sean McNeil wrote: > > > > > >> I'm not sure what information to provide from my crash dump. I > >> tried to > >> burn a CD with my > >> > >> 'TOSHIBA ' 'CD/DVDW SD-R5372' 'TU31' Removable CD-ROM > >> > >> via. nautilus CD burner and I get a kernel panic: > >> > >> May 19 19:41:23 server kernel: Fatal trap 9: general protection > >> fault while in kernel mode > >> May 19 19:41:23 server kernel: instruction pointer = > >> 0x8:0xffffffff801f4d99May 19 19:41:23 server kernel: stack > >> pointer = 0x10:0xffffffffb1d7ab80 > >> May 19 19:41:23 server kernel: frame pointer = > >> 0x10:0xffffff0000c3b000 > >> May 19 19:41:23 server kernel: code segment = base > >> 0x0, limit 0xfffff, type 0x1b > >> May 19 19:41:23 server kernel: = DPL 0, pres 1, long 1, def32 0, > >> gran 1 > >> May 19 19:41:23 server kernel: processor eflags = interrupt > >> enabled, resume, IOPL = 0 > >> May 19 19:41:23 server kernel: current process = 5 > >> (thread taskq) > >> May 19 19:41:23 server kernel: trap number = 9 > >> May 19 19:41:23 server kernel: panic: general protection fault > >> > >> What can I do to get the proper info to the developers? using kgdb, I > >> checked the threads (pids) and stack. > >> > > There appears to be a missing return on the lines above. I think it > caused you to read the SP for the IP. > > > kern.timeout.c line 530 is > > > > 530 mtx_unlock_spin(&callout_lock); > > I don't think this is the problem. I think it is happening inside an > interrupt handler while the thread was at this point. > > > I'm not sure what in there would generate a GPF. Load up a debugging > > version of the kernel that generated this error into gdb (add > > "makeoptions > > DEBUG=-g" to your kernel config & rebuild if you don't have one, > > and you > > don't need to load in the crashdump), and enter > > > > disass 0xffffffffb1d7ab80 > > Looking at 0xffffffff801f4d99 (as that is the IP and above is the > SP), I see: > > (gdb) l *0xffffffff801f4d99 > 0xffffffff801f4d99 is in ata_completed (/usr/src/sys/dev/ata/ata- > queue.c:401). > 396 > 397 ATA_DEBUG_RQ(request, "completed callback/wakeup"); > 398 > 399 /* get results back to the initiator */ > 400 if (request->callback) > 401 (request->callback)(request); > 402 else > 403 sema_post(&request->done); > 404 > 405 ata_start(ch); > > 0xffffffff801f4d87 : mov 0x58(%rbx),%rax > 0xffffffff801f4d8b : test %rax,%rax > 0xffffffff801f4d8e : data16 > 0xffffffff801f4d8f : nop > 0xffffffff801f4d90 : je 0xffffffff801f4eb5 > > 0xffffffff801f4d96 : mov %rbx,%rdi > 0xffffffff801f4d99 : callq *%eax > > There is an eax register in 64-bit mode? When I do an info reg in > kgdb I don't see one. %r?x are the 64 bit versions of %e?x which are the 32 bit versions of %?x :) I think this is a peculiarity of long vs. normal mode and that the CALL instruction prefix is the same for 32 and 64 bit quantities. Its entirely possible gdb is just decoding the instruction wrong, assuming its 32 bit and not 64. Can you print the value of callback in the request there? I wonder if the pointer is somehow mangled. > > It'll disassemble whatever function it is in. Search the addresses > > on the > > left for the matching line and paste it and a handful to both sides > > into > > your reply. That will help us narrow things down by seeing what > > instruction faulted and searching for conditions that cause that > > fault. > > It would appear that the atapicam layer is somehow setting (or not > clearing) the request callback field of a structure. Or, perhaps, > there is a reference to the request structure that is happening after > the atapicam layer thinks that it is finished and free'd the memory. > > Does that sound reasonable? > > Looking at the frame structure, it looks like rax == eax: > > (kgdb) p/x frame > $2 = {tf_rdi = 0xffffff007abafe18, tf_rsi = 0x1, tf_rdx = 0x50, > tf_rcx = 0x20, > tf_r8 = 0xffffff007b7518b8, tf_r9 = 0xffffff007b75c2c0, > tf_rax = 0x50070802106a0, tf_rbx = 0xffffff007abafe18, > tf_rbp = 0xffffff0000c3b000, tf_r10 = 0xffffffff806c8c38, tf_r11 = > 0x0, > tf_r12 = 0x4, tf_r13 = 0x1, tf_r14 = 0xffffff0000b54608, tf_r15 = > 0x1, > tf_trapno = 0x9, tf_addr = 0x0, tf_flags = 0xffffffff8032355a, > tf_err = 0x0, > tf_rip = 0xffffffff801f4d99, tf_cs = 0x8, tf_rflags = 0x10206, > tf_rsp = 0xffffffffb1d7ab90, tf_ss = 0x10} > > which would make some sense. As tf_rax looks bogus. > > What else can I do? > > Thanks, > Sean > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 20:55:21 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E52016A41C for ; Sun, 22 May 2005 20:55:21 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45B5C43D1F for ; Sun, 22 May 2005 20:55:21 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id D7EF9F1A95; Sun, 22 May 2005 13:55:20 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62447-07; Sun, 22 May 2005 13:55:19 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 7D49DF18D4; Sun, 22 May 2005 13:55:19 -0700 (PDT) From: Sean McNeil To: Doug White In-Reply-To: <20050522123938.I27009@carver.gumbysoft.com> References: <1116566651.1588.17.camel@server.mcneil.com> <20050520135046.T8229@carver.gumbysoft.com> <20050522123938.I27009@carver.gumbysoft.com> Content-Type: text/plain Date: Sun, 22 May 2005 13:55:19 -0700 Message-Id: <1116795319.92384.5.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Cc: amd64@freebsd.org Subject: Re: help with GPF on 5.4-STABLE 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, 22 May 2005 20:55:21 -0000 On Sun, 2005-05-22 at 13:26 -0700, Doug White wrote: > Answer is inline, but a ways down. > > On Fri, 20 May 2005, Sean McNeil wrote: > > > Doug, > > > > Thanks for helping me look into this. > > > > On May 20, 2005, at 1:59 PM, Doug White wrote: > > > > > Lets prune this down: > > > > > > On Thu, 19 May 2005, Sean McNeil wrote: > > > > > > > > >> I'm not sure what information to provide from my crash dump. I > > >> tried to > > >> burn a CD with my > > >> > > >> 'TOSHIBA ' 'CD/DVDW SD-R5372' 'TU31' Removable CD-ROM > > >> > > >> via. nautilus CD burner and I get a kernel panic: > > >> > > >> May 19 19:41:23 server kernel: Fatal trap 9: general protection > > >> fault while in kernel mode > > >> May 19 19:41:23 server kernel: instruction pointer = > > >> 0x8:0xffffffff801f4d99May 19 19:41:23 server kernel: stack > > >> pointer = 0x10:0xffffffffb1d7ab80 > > >> May 19 19:41:23 server kernel: frame pointer = > > >> 0x10:0xffffff0000c3b000 > > >> May 19 19:41:23 server kernel: code segment = base > > >> 0x0, limit 0xfffff, type 0x1b > > >> May 19 19:41:23 server kernel: = DPL 0, pres 1, long 1, def32 0, > > >> gran 1 > > >> May 19 19:41:23 server kernel: processor eflags = interrupt > > >> enabled, resume, IOPL = 0 > > >> May 19 19:41:23 server kernel: current process = 5 > > >> (thread taskq) > > >> May 19 19:41:23 server kernel: trap number = 9 > > >> May 19 19:41:23 server kernel: panic: general protection fault > > >> > > >> What can I do to get the proper info to the developers? using kgdb, I > > >> checked the threads (pids) and stack. > > >> > > > > There appears to be a missing return on the lines above. I think it > > caused you to read the SP for the IP. > > > > > kern.timeout.c line 530 is > > > > > > 530 mtx_unlock_spin(&callout_lock); > > > > I don't think this is the problem. I think it is happening inside an > > interrupt handler while the thread was at this point. > > > > > I'm not sure what in there would generate a GPF. Load up a debugging > > > version of the kernel that generated this error into gdb (add > > > "makeoptions > > > DEBUG=-g" to your kernel config & rebuild if you don't have one, > > > and you > > > don't need to load in the crashdump), and enter > > > > > > disass 0xffffffffb1d7ab80 > > > > Looking at 0xffffffff801f4d99 (as that is the IP and above is the > > SP), I see: > > > > (gdb) l *0xffffffff801f4d99 > > 0xffffffff801f4d99 is in ata_completed (/usr/src/sys/dev/ata/ata- > > queue.c:401). > > 396 > > 397 ATA_DEBUG_RQ(request, "completed callback/wakeup"); > > 398 > > 399 /* get results back to the initiator */ > > 400 if (request->callback) > > 401 (request->callback)(request); > > 402 else > > 403 sema_post(&request->done); > > 404 > > 405 ata_start(ch); > > > > 0xffffffff801f4d87 : mov 0x58(%rbx),%rax > > 0xffffffff801f4d8b : test %rax,%rax > > 0xffffffff801f4d8e : data16 > > 0xffffffff801f4d8f : nop > > 0xffffffff801f4d90 : je 0xffffffff801f4eb5 > > > > 0xffffffff801f4d96 : mov %rbx,%rdi > > 0xffffffff801f4d99 : callq *%eax > > > > There is an eax register in 64-bit mode? When I do an info reg in > > kgdb I don't see one. > > %r?x are the 64 bit versions of %e?x which are the 32 bit versions of %?x > :) > > I think this is a peculiarity of long vs. normal mode and that the CALL > instruction prefix is the same for 32 and 64 bit quantities. Its entirely > possible gdb is just decoding the instruction wrong, assuming its 32 bit > and not 64. > > Can you print the value of callback in the request there? I wonder if the > pointer is somehow mangled. It appears to be exactly what is in the rax register (the callback value): (kgdb) p *(struct ata_request *)0xffffff007abafe18 $1 = {device = 0xffffff0000c3b1b8, driver = 0xffffff00628d6780, u = {ata = { command = 3 '\003', feature = 0 '\0', count = 0, lba = 0}, atapi = { ccb = "\003\000\000\000\022\000\000\000\000\000\000\000\000\000\000", sense_data = {error_code = 0 '\0', valid = 0 '\0', segment = 0 '\0', sense_key = 0 '\0', reserved2_4 = 0 '\0', ili = 0 '\0', eom = 0 '\0', filemark = 0 '\0', cmd_info = 0, sense_length = 0 '\0', cmd_specific_info = 0, asc = 0 '\0', ascq = 0 '\0', replaceable_unit_code = 0 '\0', sk_specific = 0 '\0', sksv = 0 '\0', sk_specific1 = 0 '\0', sk_specific2 = 0 '\0'}, sense_key = 80 'P', sense_cmd = 85 'U'}}, status = 80 'P', error = 0 '\0', dmastat = 0 '\0', bytecount = 18, transfersize = 18, donecount = 78, data = 0xffffff007abafe38 "", flags = 1650, callback = 0x50070802106a0, done = {sema_mtx = {mtx_object = {lo_class = 0xa000000, lo_name = 0xc0080000026
, lo_type = 0x0, lo_flags = 0, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 0, mtx_recurse = 0}, sema_cv = {cv_description = 0x0, cv_waiters = 0}, sema_waiters = 0, sema_value = 0}, retries = 2, timeout = 5, callout = {c_links = {sle = { sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xffffffff99bc0570}}, c_time = 538867, c_arg = 0xffffff007abafe18, c_func = 0xffffffff801f5bf0 , c_flags = 8}, result = 5, task = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ---Type to continue, or q to quit--- ta_func = 0xffffffff801f4d20 , ta_context = 0xffffff007abafe18}, bio = 0x0, sequence = {tqe_next = 0x0, tqe_prev = 0x0}, chain = {tqe_next = 0x0, tqe_prev = 0xffffff0000c3b2c8}} The device is: (kgdb) p *((struct ata_request *)0xffffff007abafe18)->device $3 = {channel = 0xffffff0000c3b000, unit = 16, name = 0xffffff007b0057e0 "acd1", param = 0xffffff000114c400, softc = 0xffffff00010c7800, attach = 0xffffffff8020a530 , detach = 0xffffffff8020a000 , config = 0, start = 0xffffffff8020b6e0 , flags = 4, cmd = 0, mode = 12, setmode = 0xffffffff80204430 } Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Sun May 22 23:06:03 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B348516A41C for ; Sun, 22 May 2005 23:06:03 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E1D143D53 for ; Sun, 22 May 2005 23:06:03 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id DF1DBF1A48; Sun, 22 May 2005 16:06:02 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00663-01; Sun, 22 May 2005 16:06:01 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 87832F1A30; Sun, 22 May 2005 16:06:01 -0700 (PDT) From: Sean McNeil To: Doug White In-Reply-To: <20050522123938.I27009@carver.gumbysoft.com> References: <1116566651.1588.17.camel@server.mcneil.com> <20050520135046.T8229@carver.gumbysoft.com> <20050522123938.I27009@carver.gumbysoft.com> Content-Type: text/plain Date: Sun, 22 May 2005 16:06:01 -0700 Message-Id: <1116803161.1148.8.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Cc: amd64@freebsd.org Subject: Re: help with GPF on 5.4-STABLE - found fix 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, 22 May 2005 23:06:03 -0000 Hi Doug, I want to extend my appreciation for your questions as they steered me in the right direction and helped me resolve the issue with atapicam. I am puzzled as why I am the first to experience this problem. It would appear to be an issue that others should have run into before me. There is a problem in sys/dev/ata/ata-queue.c with ata_completed(). In the case where there is an ATAPI error, a new request is issued. It is a sense request. The problem is, there is a value in donecount from the previous request that isn't zero'd out. The following patch fixes my crash and makes burning CDs work again. --- sys/dev/ata/ata-queue.c.orig Sun May 22 15:28:03 2005 +++ sys/dev/ata/ata-queue.c Sun May 22 15:28:27 2005 @@ -340,6 +340,7 @@ request->data = (caddr_t)&request->u.atapi.sense_data; request->bytecount = sizeof(struct atapi_sense); request->transfersize = sizeof(struct atapi_sense); + request->donecount = 0; request->timeout = 5; request->flags &= (ATA_R_ATAPI | ATA_R_QUIET); request->flags |= (ATA_R_READ | ATA_R_IMMEDIATE | ATA_R_REQUEUE); Now, how do I get this incorporated into -STABLE? Do I need to submit a bug report? Is this simple enough that a team member can simply review and commit? Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 02:18:03 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93AD816A41C for ; Mon, 23 May 2005 02:18:03 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E1B443D54 for ; Mon, 23 May 2005 02:18:03 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4N2I1WV062827; Sun, 22 May 2005 19:18:01 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4N2HtYL062822; Sun, 22 May 2005 19:17:55 -0700 (PDT) (envelope-from obrien) Date: Sun, 22 May 2005 19:17:55 -0700 From: "David O'Brien" To: Mike Jakubik Message-ID: <20050523021755.GC62693@dragon.NUXI.org> References: <428B6FC1.3000907@fsn.hu> <1116437340.69035.0.camel@hood.oook.cz> <20050518180521.GB9719@odin.ac.hmc.edu> <20050519010828.GA64608@dragon.NUXI.org> <428CC309.5040306@fsn.hu> <20050520165526.GE6982@dragon.NUXI.org> <1246.172.16.0.199.1116617274.squirrel@172.16.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1246.172.16.0.199.1116617274.squirrel@172.16.0.1> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: FreeBSD on dual core Opterons - stupid buildworld test X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 02:18:03 -0000 On Fri, May 20, 2005 at 03:27:54PM -0400, Mike Jakubik wrote: > On Fri, May 20, 2005 12:55 pm, David O'Brien said: > > > > For 6.0-RELEASE (which branches June 1, 2005), I'm going to just have the > > kernel ignore that dual-core Opteron sets the HTT feature flag. > > And what about RELENG_5? I'll MFC it if thats what users would like. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 05:22:17 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E55216A41C; Mon, 23 May 2005 05:22:17 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D28043D1D; Mon, 23 May 2005 05:22:16 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4N5MD4j065582; Sun, 22 May 2005 22:22:13 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4N5MB2P065581; Sun, 22 May 2005 22:22:11 -0700 (PDT) (envelope-from obrien) Date: Sun, 22 May 2005 22:22:11 -0700 From: "David O'Brien" To: Jung-uk Kim Message-ID: <20050523052211.GA65514@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Jung-uk Kim , freebsd-arch@freebsd.org, rwatson@freebsd.org, freebsd-amd64@freebsd.org References: <200505191431.08189.jkim@niksun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505191431.08189.jkim@niksun.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: rwatson@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: AMD64 NUMA-awareness? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 05:22:17 -0000 On Thu, May 19, 2005 at 02:31:08PM -0400, Jung-uk Kim wrote: > I am not sure about the meaning of 'true NUMA capable machines' but > AMD64 is ccNUMA unless I am completely mistaken, and FreeBSD/amd64 is > well-supported. Even multicore processors are available now ..snip.. I am working on extracting the CPU & memory topology on AMD Opteron machines. For Athlon64 X2 (dual-core) there is nothing for FreeBSD to do differently than today. Once I have the ability to nicely express the topology on an Opteron system, there are two heavy hitters that have said they will consume the bits and work on optimizing FreeBSD for Opteron systems. For Intel dual-core HTT systems, there aren't any NUMA characteristics I'm aware of. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 08:30:51 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B60416A41C; Mon, 23 May 2005 08:30:51 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2261E43D58; Mon, 23 May 2005 08:30:49 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 562484B707; Mon, 23 May 2005 10:30:48 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00796-03-3; Mon, 23 May 2005 10:30:47 +0200 (CEST) Received: from palle.girgensohn.se (1-2-8-5a.asp.sth.bostream.se [82.182.157.66]) by melon.pingpong.net (Postfix) with ESMTP id C2FBA4B705; Mon, 23 May 2005 10:30:47 +0200 (CEST) Date: Mon, 23 May 2005 10:30:47 +0200 From: Palle Girgensohn To: stable@freebsd.org, amd64@freebsd.org Message-ID: <1266D69ABEC58B97FBFE536F@palle.girgensohn.se> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========580DD7932ECF1A4D3976==========" X-Virus-Scanned: by amavisd-new at pingpong.net Cc: Subject: savecore: first and last dump headers disagree 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, 23 May 2005 08:30:51 -0000 --==========580DD7932ECF1A4D3976========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! We have an amd64 system that still experiences crashes after installing 5.4, mostly during high loads. (It's been unstable all the time, really; see previous posts.) I've added dumpdev="/dev/amrd0s2b", and some time ago I did get coredumps, but with latest versions of the kernel, savecore does not give me a dump, instead it says: savecore: first and last dump headers disagree on /dev/amrd0s2b savecore: unsaved dumps found but not saved What can I do to fix this? I guess I need a core dump to proceed in finding the problem? Also, the machine does not reboot after a panic, that's an even bigger problem, really, it needs console hands-on to revive every time. Last time it crashed (last week, before updating to 5.4-RELEASE, that system was a few weeks older on the RELENG_5_4 branch), it seems to have get stuck on dumping the core, can this be the problem: ------- Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address = 0x00 ... trap number = 12 panic: page fault cpuid = 0 boot() called on cpu#0 Uptime: 1d23h50m36s Dumping 2047 MB 16 32 -------- The cursor sits at the position after "32". Seems to me it fails to dump the core, can this be it? On previous crashes, before dumpdev was set, it would hang before that The machine is Dell 2850 w/ Perc raid, Dual CPUs, SMP with hyperthreading OFF in BIOS. Enclosing the KERNEL config, almost a GENERIC kernel. I can provide more info if required. So, in short, three question, really. - How can I get rid of the crashes? (heh) - How can I get the system to do unattended reboot when crashed? - How do I get a coredump? Any help appreciated. /Palle Diffing GENERIC vs KERNEL: --- GENERIC Tue Apr 12 15:57:01 2005 +++ KERNEL Fri Apr 29 22:27:41 2005 @@ -20,7 +20,9 @@ machine amd64 cpu HAMMER -ident GENERIC +ident KERNEL + +makeoptions DEBUG=-g # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. @@ -45,7 +47,7 @@ options COMPAT_43 # Needed by COMPAT_LINUX32 options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 -options COMPAT_LINUX32 # Compatible with i386 linux binaries +#options COMPAT_LINUX32 # Compatible with i386 linux binaries options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory @@ -64,10 +66,10 @@ # Enabling NO_MIXED_MODE gives a performance improvement on some motherboards # but does not work with some boards (mostly nVidia chipset based). -#options NO_MIXED_MODE # Don't penalize working chipsets +options NO_MIXED_MODE # Don't penalize working chipsets # Linux 32-bit ABI support -options LINPROCFS # Cannot be a module yet. +#options LINPROCFS # Cannot be a module yet. # Bus support. Do not remove isa, even if you have no isa slots device acpi @@ -260,3 +262,19 @@ device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) + +# SMP +options SMP + +# SysV stuff +# This provides support for System V shared memory. +# +options SYSVSHM +options SYSVSEM +options SYSVMSG +options SHMMAXPGS=65536 +options SEMMNI=40 +options SEMMNS=240 +options SEMUME=40 +options SEMMNU=120 --==========580DD7932ECF1A4D3976========== Content-Type: text/plain; charset=iso-8859-1; name=KERNEL Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=KERNEL; size=10048 # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # = http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-confi= g.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.421.2.11.2.1 2005/04/09 17:28:37 = kensmith Exp $ machine amd64 cpu HAMMER ident KERNEL makeoptions DEBUG=3D-g # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Needed by COMPAT_LINUX32 options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 #options COMPAT_LINUX32 # Compatible with i386 linux binaries=20 options SCSI_DELAY=3D15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. # Workarounds for some known-to-be-broken chipsets (nVidia nForce3-Pro150) device atpic # 8259A compatability # Enabling NO_MIXED_MODE gives a performance improvement on some = motherboards # but does not work with some boards (mostly nVidia chipset based). options NO_MIXED_MODE # Don't penalize working chipsets # Linux 32-bit ABI support #options LINPROCFS # Cannot be a module yet. # Bus support. Do not remove isa, even if you have no isa slots device acpi device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these = NICs! device miibus # MII bus support device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device nge # NatSemi DP83820 gigabit Ethernet device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' # XXX kvtop brokenness, pointer/int warnings #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards # XXX kvtop brokenness, pointer/int warnings #device lnc # NE2100, NE32-VL Lance Ethernet cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires mii device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) # SMP options SMP # SysV stuff # This provides support for System V shared memory. # options SYSVSHM options SYSVSEM options SYSVMSG options SHMMAXPGS=3D65536 options SEMMNI=3D40 options SEMMNS=3D240 options SEMUME=3D40 options SEMMNU=3D120 --==========580DD7932ECF1A4D3976========== Content-Type: text/plain; charset=iso-8859-1; name="dmesg.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.txt"; size=5939 Copyright (c) 1992-2005 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 5.4-RELEASE #6: Wed May 18 15:56:44 CEST 2005 girgen@melon.pingpong.net:/usr/obj/usr/src/sys/MELON Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.02-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 = Features=3D0xbfebfbff Features2=3D0x641d,MON,DS_CPL,CNTX-ID,CX16,> AMD Features=3D0x20000800 real memory =3D 2147221504 (2047 MB) avail memory =3D 2061484032 (1965 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 7 ioapic1: Changing APIC ID to 8 ioapic1: WARNING: intbase 32 !=3D expected base 24 ioapic2: Changing APIC ID to 9 ioapic2: WARNING: intbase 64 !=3D expected base 56 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem = 0xdfdc0000-0xdfdfffff,0xd80f0000-0xd80fffff irq 46 at device 14.0 on pci2 amr0: Firmware 513O, BIOS H418, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port = 0xecc0-0xecff mem 0xdfae0000-0xdfafffff irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:11:43:37:a4:9e em0: Speed:N/A Duplex:N/A pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port = 0xdcc0-0xdcff mem 0xdf8e0000-0xdf8fffff irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:11:43:37:a4:9f em1: Speed:N/A Duplex:N/A pcib8: at device 6.0 on pci0 pci8: on pcib8 uhci0: port 0xbce0-0xbcff irq = 16 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbcc0-0xbcdf irq = 19 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbca0-0xbcbf irq = 18 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib9: at device 30.0 on pci0 pci9: on pcib9 pci9: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port = 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on = acpi0 sio0: type 16550A orm0: at iomem = 0xec000-0xeffff,0xce800-0xcf7ff,0xcb000-0xcbfff,0xc0000-0xcafff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> 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 uhub3: Dell product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub3: 2 ports with 2 removable, self powered Timecounters tick every 1.000 msec acd0: CDROM at ata0-master PIO4 amrd0: on amr0 amrd0: 139760MB (286228480 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device=20 ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/amrd0s2a WARNING: / was not properly dismounted WARNING: /misc was not properly dismounted /misc: mount pending error: blocks 22544 files 3 WARNING: /usr was not properly dismounted WARNING: /usr/local was not properly dismounted /usr/local: mount pending error: blocks 348 files 1 WARNING: /var was not properly dismounted /var: mount pending error: blocks 2040 files 130 WARNING: /var/spool/imap was not properly dismounted em1: Link is up 100 Mbps Half Duplex em0: Link is up 1000 Mbps Full Duplex Interrupt storm detected on "irq18: uhci2"; throttling interrupt source Interrupt storm detected on "irq16: uhci0"; throttling interrupt source --==========580DD7932ECF1A4D3976==========-- From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 08:37:09 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 797C516A41C for ; Mon, 23 May 2005 08:37:09 +0000 (GMT) (envelope-from uedc@rz.uni-karlsruhe.de) Received: from smtp1.rz.uni-karlsruhe.de (smtp1.rz.uni-karlsruhe.de [129.13.185.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16D4243D1F for ; Mon, 23 May 2005 08:37:08 +0000 (GMT) (envelope-from uedc@rz.uni-karlsruhe.de) Received: from rzstud2.stud.uni-karlsruhe.de (exim@rzstud2.stud.uni-karlsruhe.de [193.196.41.38]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.43 #1) id 1Da8Qs-0001Fr-Ey; Mon, 23 May 2005 10:37:06 +0200 Received: from uedc by rzstud2.stud.uni-karlsruhe.de with local (Exim 3.36 #1) id 1Da8Qs-0006mf-00; Mon, 23 May 2005 10:37:06 +0200 Date: Mon, 23 May 2005 10:37:06 +0200 From: "Thomas E. Zander" To: Michiel Boland Message-ID: <20050523083706.GD16701@rz.uni-karlsruhe.de> References: <20050521022130.GW52914@afflictions.org> <20050521105451.V92958@fw.reifenberger.com> <200505211237.00974.loox@e-shell.net> <1116697452.79313.31.camel@hood.oook.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: Thomas Zander Cc: riggs@rrr.de, freebsd-amd64@freebsd.org Subject: Re: mplayer, amd64, and CPU flags [patch] 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, 23 May 2005 08:37:09 -0000 Hi, On Sun, May 22, 2005 at 09:21:56PM +0200, Michiel Boland wrote: > Rather than hack the port Makefile, I think it is better to fix cpuinfo.c. Yes, I agree. The patch looks completely reasonable to me and returns results as expected on my box. I think that's the way we should go. Regards, Riggs -- - "[...] I talked to the computer at great length and -- explained my view of the Universe to it" said Marvin. --- And what happened?" pressed Ford. ---- "It committed suicide." said Marvin. From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 08:54:40 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C192016A41C for ; Mon, 23 May 2005 08:54:40 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from e0-a11.b1.lan.prg.vol.cz (e0-a11.b1.lan.prg.vol.cz [195.122.204.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BE9C43D1D for ; Mon, 23 May 2005 08:54:39 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from pav.hide.vol.cz (localhost [127.0.0.1]) by e0-a11.b1.lan.prg.vol.cz (8.13.1/8.13.1) with ESMTP id j4N8sZ5w069070; Mon, 23 May 2005 10:54:35 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by pav.hide.vol.cz (8.13.1/8.13.1/Submit) id j4N8sPen068353; Mon, 23 May 2005 10:54:25 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: pav.hide.vol.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: "Thomas E. Zander" In-Reply-To: <20050523083706.GD16701@rz.uni-karlsruhe.de> References: <20050521022130.GW52914@afflictions.org> <20050521105451.V92958@fw.reifenberger.com> <200505211237.00974.loox@e-shell.net> <1116697452.79313.31.camel@hood.oook.cz> <20050523083706.GD16701@rz.uni-karlsruhe.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Eg5vhYmIZ2E7Absr/wv3" Date: Mon, 23 May 2005 10:54:23 +0200 Message-Id: <1116838463.36019.18.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Cc: freebsd-amd64@FreeBSD.org Subject: Re: mplayer, amd64, and CPU flags [patch] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 08:54:40 -0000 --=-Eg5vhYmIZ2E7Absr/wv3 Content-Type: text/plain; charset=ISO8859-2 Content-Transfer-Encoding: quoted-printable Thomas E. Zander p=ED=B9e v po 23. 05. 2005 v 10:37 +0200: > Hi, >=20 > On Sun, May 22, 2005 at 09:21:56PM +0200, Michiel Boland wrote: >=20 > > Rather than hack the port Makefile, I think it is better to fix cpuinfo= .c.=20 >=20 > Yes, I agree. > The patch looks completely reasonable to me and returns results as > expected on my box. > I think that's the way we should go. Ok, patch checked into CVS. --=20 Pav Lucistnik Some programmers are able to write FORTRAN in any language. --=-Eg5vhYmIZ2E7Absr/wv3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCkZo/ntdYP8FOsoIRAixNAJ9m6N2bEWKkzz0Ap6kHq2n/bQHeRgCeNaFA NZg9b/8cmWRnSoRo1Fg8ufM= =VAEX -----END PGP SIGNATURE----- --=-Eg5vhYmIZ2E7Absr/wv3-- From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 10:18:05 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 567BB16A41C; Mon, 23 May 2005 10:18:05 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id E111B43D1D; Mon, 23 May 2005 10:18:04 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 4DA8B4B626; Mon, 23 May 2005 12:18:03 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18448-01-11; Mon, 23 May 2005 12:18:03 +0200 (CEST) Received: from palle.girgensohn.se (1-2-8-5a.asp.sth.bostream.se [82.182.157.66]) by melon.pingpong.net (Postfix) with ESMTP id E85D04B624; Mon, 23 May 2005 12:18:02 +0200 (CEST) Date: Mon, 23 May 2005 12:18:02 +0200 From: Palle Girgensohn To: Palle Girgensohn , stable@freebsd.org, amd64@freebsd.org Message-ID: <6950A47790357A4F74A4572E@palle.girgensohn.se> In-Reply-To: <1266D69ABEC58B97FBFE536F@palle.girgensohn.se> References: <1266D69ABEC58B97FBFE536F@palle.girgensohn.se> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new at pingpong.net Cc: Subject: system does not reboot after panic (Was: savecore: first and last dump headers disagree) 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, 23 May 2005 10:18:05 -0000 --On m=E5ndag, maj 23, 2005 10.30.47 +0200 Palle Girgensohn=20 wrote: > Hi! > > We have an amd64 system that still experiences crashes after installing > 5.4, mostly during high loads. (It's been unstable all the time, really; > see previous posts.) > > I've added dumpdev=3D"/dev/amrd0s2b", and some time ago I did get > coredumps, but with latest versions of the kernel, savecore does not give > me a dump, instead it says: > > savecore: first and last dump headers disagree on /dev/amrd0s2b > savecore: unsaved dumps found but not saved > > What can I do to fix this? I guess I need a core dump to proceed in > finding the problem? Peter Holm tipped me of using savecore -f. Hopefully this will give me a=20 core next time. This one was already destroyed by swapping. :( > Also, the machine does not reboot after a panic, that's an even bigger > problem, really, it needs console hands-on to revive every time. This is really *the* main issue. It won't reboot automatically, it just=20 sits there waiting for keyboard action... :( there is no debugger in the=20 kernel, would adding kbd and kbd_unattende help? I doubt it? Anything else=20 that can be done? /Palle > Last time it crashed (last week, before updating to 5.4-RELEASE, that > system was a few weeks older on the RELENG_5_4 branch), it seems to have > get stuck on dumping the core, can this be the problem: > > ------- > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0: apic id =3D 00 > fault virtual address =3D 0x00 > ... > trap number =3D 12 > panic: page fault > cpuid =3D 0 > boot() called on cpu#0 > Uptime: 1d23h50m36s > Dumping 2047 MB > 16 32 > -------- > The cursor sits at the position after "32". > > Seems to me it fails to dump the core, can this be it? On previous > crashes, before dumpdev was set, it would hang before that > > The machine is Dell 2850 w/ Perc raid, Dual CPUs, SMP with hyperthreading > OFF in BIOS. Enclosing the KERNEL config, almost a GENERIC kernel. I can > provide more info if required. > > So, in short, three question, really. > > - How can I get rid of the crashes? (heh) > - How can I get the system to do unattended reboot when crashed? > - How do I get a coredump? > Any help appreciated. > > /Palle > > > Diffing GENERIC vs KERNEL: > > --- GENERIC Tue Apr 12 15:57:01 2005 > +++ KERNEL Fri Apr 29 22:27:41 2005 > @@ -20,7 +20,9 @@ > > machine amd64 > cpu HAMMER > -ident GENERIC > +ident KERNEL > + > +makeoptions DEBUG=3D-g > > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for > devices. > @@ -45,7 +47,7 @@ > options COMPAT_43 # Needed by COMPAT_LINUX32 > options COMPAT_IA32 # Compatible with i386 binaries > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > -options COMPAT_LINUX32 # Compatible with i386 linux > binaries > +#options COMPAT_LINUX32 # Compatible with i386 linux > binaries > options SCSI_DELAY=3D15000 # Delay (in ms) before probing > SCSI > options KTRACE # ktrace(1) support > options SYSVSHM # SYSV-style shared memory > @@ -64,10 +66,10 @@ > > # Enabling NO_MIXED_MODE gives a performance improvement on some > motherboards > # but does not work with some boards (mostly nVidia chipset based). > -#options NO_MIXED_MODE # Don't penalize working chipsets > +options NO_MIXED_MODE # Don't penalize working chipsets > > # Linux 32-bit ABI support > -options LINPROCFS # Cannot be a module yet. > +#options LINPROCFS # Cannot be a module yet. > > # Bus support. Do not remove isa, even if you have no isa slots > device acpi > @@ -260,3 +262,19 @@ > device firewire # FireWire bus code > device sbp # SCSI over FireWire (Requires scbus and > da) > device fwe # Ethernet over FireWire (non-standard!) > + > +# SMP > +options SMP > + > +# SysV stuff > +# This provides support for System V shared memory. > +# > +options SYSVSHM > +options SYSVSEM > +options SYSVMSG > +options SHMMAXPGS=3D65536 > +options SEMMNI=3D40 > +options SEMMNS=3D240 > +options SEMUME=3D40 > +options SEMMNU=3D120 From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 11:01:46 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAD3D16A41C for ; Mon, 23 May 2005 11:01:46 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87F9043D4C for ; Mon, 23 May 2005 11:01:46 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4NB1krR003997 for ; Mon, 23 May 2005 11:01:46 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4NB1j1H003991 for freebsd-amd64@freebsd.org; Mon, 23 May 2005 11:01:45 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 23 May 2005 11:01:45 GMT Message-Id: <200505231101.j4NB1j1H003991@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org 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, 23 May 2005 11:01:47 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/27] amd64/73211 amd64 FAST_IPSEC broken on amd64 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/07/28] amd64/69704 amd64 ext2/ext3 unstable in amd64 o [2004/07/28] amd64/69707 amd64 IPC32 dont work OK in amd64 FreeBSD o [2004/09/07] amd64/71471 amd64 Can not install 5.3beta3/amd64 on IBM eSe o [2004/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see o [2004/10/30] amd64/73322 amd64 unarchiving /etc to msdos fs locks up amd o [2004/11/01] amd64/73369 amd64 on-board firewire unreliable with Asus K8 o [2004/11/07] amd64/73650 amd64 5.3-release panics on boot o [2004/11/10] amd64/73775 amd64 Kernel panic (trap 12) when booting with o [2004/11/16] amd64/74014 amd64 5.3-RELEASE-AMD64 freezes on boot during o [2004/12/05] amd64/74747 amd64 System panic on shutdown when process wil o [2004/12/18] amd64/75209 amd64 5.3-Release panics on attempted boot from o [2004/12/23] amd64/75417 amd64 ACPI: SATA Hard-disk o [2005/01/12] amd64/76136 amd64 system halts before reboot o [2005/01/17] amd64/76336 amd64 racoon/setkey -D cases instant "Fatal Tra o [2005/02/02] amd64/77011 amd64 consisten 5.3-p5 make crash on installwor o [2005/02/04] amd64/77101 amd64 Please include ULi M1689 LAN, SATA, and A o [2005/02/17] amd64/77629 amd64 aMule hardlocks AMD64 system o [2005/02/23] amd64/77949 amd64 Pb boot FreeBSD 64 o [2005/03/04] amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/p o [2005/03/07] amd64/78558 amd64 installation o [2005/03/14] amd64/78848 amd64 sis driver on FreeBSD 5.x does not work o o [2005/04/12] amd64/79813 amd64 Will not install/run on amd64 nForce 4 pl o [2005/04/19] amd64/80114 amd64 kldload snd_ich causes interrupt storm wh o [2005/05/06] amd64/80691 amd64 amd64 kernel hangs on load a [2005/05/10] amd64/80839 amd64 RELEASE 5.4 / libc: make buildworld fails o [2005/05/14] amd64/81037 amd64 SATA problem o [2005/05/19] amd64/81272 amd64 JDK 1.5 port doesn't build. o [2005/05/19] amd64/81279 amd64 /usr/games/random returns every line o [2005/05/20] amd64/81325 amd64 KLD if_ath.ko: depends on ath_hal - not a 30 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/01/11] amd64/61209 amd64 ppc0: cannot reserve I/O port range o [2004/02/21] amd64/63188 amd64 ti(4) broken on amd64 o [2004/07/28] amd64/69705 amd64 IPC problem (msq_queues) o [2004/07/28] amd64/69709 amd64 ACPI enabled then floppy don't work (5.2. o [2004/08/15] amd64/70500 amd64 bge driver for 3Com 3C996B on amd64 preve o [2004/12/02] amd64/74608 amd64 mpt hangs 5 minutes when booting o [2004/12/07] amd64/74811 amd64 df, nfs mount, negative Avail -> 32/64-bi o [2004/12/13] ports/75015 amd64 cvsup on amd64 with runsocks (socks5) cor o [2004/12/25] amd64/75488 amd64 ntfs_iconv not working on amd64 o [2005/02/13] amd64/77470 amd64 Using of cyrillic filenames conversion le o [2005/03/17] amd64/78954 amd64 kerberos 5 failed to build o [2005/05/11] amd64/80885 amd64 OpenGL hardware accel dont work on FreeBS o [2005/05/16] amd64/81089 amd64 FreeBSD 5.4 released version can not use 13 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 14:23:24 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E572616A41C; Mon, 23 May 2005 14:23:24 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9817F43D1F; Mon, 23 May 2005 14:23:24 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j4NENNVR033483; Mon, 23 May 2005 09:23:23 -0500 (CDT) (envelope-from dan) Date: Mon, 23 May 2005 09:23:23 -0500 From: Dan Nelson To: Palle Girgensohn Message-ID: <20050523142323.GB16069@dan.emsphone.com> References: <1266D69ABEC58B97FBFE536F@palle.girgensohn.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1266D69ABEC58B97FBFE536F@palle.girgensohn.se> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: amd64@freebsd.org, stable@freebsd.org Subject: Re: savecore: first and last dump headers disagree 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, 23 May 2005 14:23:25 -0000 In the last episode (May 23), Palle Girgensohn said: > We have an amd64 system that still experiences crashes after > installing 5.4, mostly during high loads. (It's been unstable all the > time, really; see previous posts.) > > I've added dumpdev="/dev/amrd0s2b", and some time ago I did get coredumps, > but with latest versions of the kernel, savecore does not give me a dump, > instead it says: > > savecore: first and last dump headers disagree on /dev/amrd0s2b > savecore: unsaved dumps found but not saved "savecore -vv" should print enough of both headers to let you see what's different. > Fatal trap 12: page fault while in kernel mode > cpuid = 0: apic id = 00 > fault virtual address = 0x00 > ... > trap number = 12 > panic: page fault > cpuid = 0 > boot() called on cpu#0 > Uptime: 1d23h50m36s > Dumping 2047 MB > 16 32 > -------- > The cursor sits at the position after "32". That's probably why your headers disagree :) If you put "options KDB_TRACE" in your kernel config file, it will print a small stack trace before trying to dump, which might be enough to track down the cause of the panic even without a dump. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 14:50:08 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2764F16A41C; Mon, 23 May 2005 14:50:08 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7EED43D1F; Mon, 23 May 2005 14:50:07 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j4NEqJoG007820; Mon, 23 May 2005 10:52:20 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: obrien@freebsd.org Date: Mon, 23 May 2005 10:49:55 -0400 User-Agent: KMail/1.6.2 References: <200505191431.08189.jkim@niksun.com> <20050523052211.GA65514@dragon.NUXI.org> In-Reply-To: <20050523052211.GA65514@dragon.NUXI.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200505231049.55883.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.83/889/Sun May 22 06:18:49 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: rwatson@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: AMD64 NUMA-awareness? 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, 23 May 2005 14:50:08 -0000 On Monday 23 May 2005 01:22 am, David O'Brien wrote: > On Thu, May 19, 2005 at 02:31:08PM -0400, Jung-uk Kim wrote: > > I am not sure about the meaning of 'true NUMA capable machines' > > but AMD64 is ccNUMA unless I am completely mistaken, and > > FreeBSD/amd64 is well-supported. Even multicore processors are > > available now > > ..snip.. > > I am working on extracting the CPU & memory topology on AMD Opteron > machines. For Athlon64 X2 (dual-core) there is nothing for FreeBSD > to do differently than today. Great. I am assuming you're working on ACPI SRAT/SLIT parsing, correct? > Once I have the ability to nicely express the topology on an > Opteron system, there are two heavy hitters that have said they > will consume the bits and work on optimizing FreeBSD for Opteron > systems. If you need any help, let me know. > For Intel dual-core HTT systems, there aren't any NUMA > characteristics I'm aware of. I believe you are correct. Jung-uk Kim > -- > -- David  (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 14:57:38 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 842B316A41C; Mon, 23 May 2005 14:57:38 +0000 (GMT) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39B7A43D4C; Mon, 23 May 2005 14:57:37 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) by smtp-gw-cl-c.dmv.com (8.12.10/8.12.10) with ESMTP id j4NEvaEo094080; Mon, 23 May 2005 10:57:36 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Mon, 23 May 2005 10:58:13 -0400 Message-Id: <1116860293.10083.43.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Cc: freebsd-amd64@freebsd.org Subject: Manipulating disk cache (buf) settings 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, 23 May 2005 14:57:38 -0000 We are running a PostgreSQL server (8.0.3) on a dual opteron system with 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show values of 215MB and 225771520 (which equals 215MB) respectively. My understanding from having searched the archives is that this is the value that is used by the system/kernel in determining how much disk data to cache. If that is in fact the case, then my question would be how to best increase the amount of memory the system can use for disk caching. Ideally I would like to have upwards of 1G for this type of caching/buffering. I suspect it would not be as easy as simply adjusting vfs.hibufspace upwards but would instead involving add either a loader.conf or kernel option of some "master" setting that affects hibufspace, bufspace, and related tunables. Or would this involve editing one of the system files? Sven From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 14:59:22 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C6F716A41C for ; Mon, 23 May 2005 14:59:22 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3251143D48 for ; Mon, 23 May 2005 14:59:19 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 0817FB883 for ; Mon, 23 May 2005 10:59:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <4290098B.6020405@roq.com> References: <9BC86C67C3AF7646B9C5382020457A9456E91B@VIP10-WIN2K> <4290098B.6020405@roq.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76A19EF2-7AE3-4EE8-9329-0344D0F49EF3@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Mon, 23 May 2005 10:59:16 -0400 To: freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.730) Subject: Re: FreeBSD AMD64 Ubench 0.3 results 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, 23 May 2005 14:59:22 -0000 On May 22, 2005, at 12:24 AM, Michael VInce wrote: > Here is a Dell 1850 Dual CPU with 4 Gigs of ram, thats in idle > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.23-MHz 686-class CPU) > > FreeBSD 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #0: Sun May 22 > 12:23:00 EST 2005 root@dagobah:/usr/obj/usr/src/sys/SMP i386 > > Ubench CPU: 170748 > Ubench MEM: 172775 > -------------------- > Ubench AVG: 171761 > Here's a pair of dual opteron 246's 2.0GHz w/4GB RAM each which are supposed to be identical, except they're built a couple of months apart. d03 is a well-loaded postgres server, and d01 is a live replica of it and runs reporting. d03 also runs disk intensive ops about 30% faster. FreeBSD 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #1: Wed May 18 12:29:27 EDT 2005 vivek@d01:/var/usr.obj/n/lorax1/usr5/src/sys/D03 amd64 Ubench CPU: 212991 Ubench MEM: 181483 -------------------- Ubench AVG: 197237 FreeBSD 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #0: Mon May 16 16:53:06 EDT 2005 vivek@d03:/var/usr.obj/n/lorax1/usr5/src/sys/D03 amd64 Ubench CPU: 215080 Ubench MEM: 187326 -------------------- Ubench AVG: 201203 The numbers from my Dell Xeon-EMT64 server at the office are so low, it ain't worth posting... Vivek Khera, Ph.D. +1-301-869-4449 x806 From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 15:47:57 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 133CC16A4DC; Mon, 23 May 2005 15:47:57 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF39843D49; Mon, 23 May 2005 15:47:56 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 4A975B87A; Mon, 23 May 2005 11:47:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <1116860293.10083.43.camel@lanshark.dmv.com> References: <1116860293.10083.43.camel@lanshark.dmv.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Mon, 23 May 2005 11:47:55 -0400 To: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.730) Cc: Subject: Re: Manipulating disk cache (buf) settings 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, 23 May 2005 15:47:57 -0000 On May 23, 2005, at 10:58 AM, Sven Willenberger wrote: > We are running a PostgreSQL server (8.0.3) on a dual opteron system > with > 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show > values of 215MB and 225771520 (which equals 215MB) respectively. My > understanding from having searched the archives is that this is the > value that is used by the system/kernel in determining how much disk > data to cache. > This is correct, from what I understand. If you take the vfs.hibufspace and divide by the page size for postgres (normally 8192) you get the proper value for the postgres tunable effective_cache_size. However, the value you see is also the max FreeBSD will use without hacking up the kernel sources. I asked about this a while back and got a response on what to hack, but I hate keeping local patches to the core system which often tend to be forgotten on upgrades... But I would also love to see the max cache get bigger, especially with multi-gig servers becoming more common and affordable. This will kill us on benchmark comparisons for large databases for sure. Vivek Khera, Ph.D. +1-301-869-4449 x806 From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 16:26:34 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D619B16A41C; Mon, 23 May 2005 16:26:34 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CA0C43D4C; Mon, 23 May 2005 16:26:33 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j4NGSfff011371; Mon, 23 May 2005 12:28:42 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: John Baldwin Date: Mon, 23 May 2005 12:26:18 -0400 User-Agent: KMail/1.6.2 References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <200503211411.58425.jkim@niksun.com> <200503211440.21752.jhb@FreeBSD.org> In-Reply-To: <200503211440.21752.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_qQgkC9ldWlyB+M7" Message-Id: <200505231226.18856.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.83/889/Sun May 22 06:18:49 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: "Matthew N. Dodd" , David O'Brien , freebsd-amd64@FreeBSD.org Subject: [PATCH] SMBIOS scan for loader (Was: Re: R3000Z Laptop Status) 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, 23 May 2005 16:26:35 -0000 --Boundary-00=_qQgkC9ldWlyB+M7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 21 March 2005 02:40 pm, John Baldwin wrote: > On Monday 21 March 2005 02:11 pm, Jung-uk Kim wrote: > > On Monday 21 March 2005 01:28 pm, Scott Long wrote: > > > Astrodog wrote: > > > >>>>>>>I was wondering if the R3000Z fixes have been committed > > > >>>>>>> to the RELENG_5 branch, I don't see anything on the > > > >>>>>>> lists about it. Should I expect 5.4 to work with the > > > >>>>>>> R3000 line? > > > >>>>>> > > > >>>>>>Yes. hint.atkbd.0.flags="0x9" is all you need now. Try > > > >>>>>> the latest snapshot and let us know. > > > >>>>>> > > > >>>>>>Thanks, > > > >>>>>> > > > >>>>>>Jung-uk Kim > > > >>>>> > > > >>>>>Is there any way that these systems can be detected at > > > >>>>> runtime and have the work-arounds be automatically > > > >>>>> activated? > > > >>>> > > > >>>>I believe DMI-based quirk table is the only way but we > > > >>>> don't want to do that, right? > > > >>>> > > > >>>>Jung-uk Kim > > > >>>> > > > >>>>>Scott > > > >>> > > > >>>Well, it's gross, but it's not impossible to do. Is there a > > > >>>technical reason why we wouldn't want this? > > > >> > > > >>The only technical reason that I can think of is some systems > > > >> (e. g., IBM e345 and e346 Opteron servers) have DMI > > > >> structures in ACPI NVS area, which is not accessible from > > > >> early stage. If you want to do something like that, you > > > >> will have to add gross hack in pmap.c to temporarily map it, > > > >> I think. > > > >> > > > >>>Are there any alternatives, like detecting a signature in > > > >>> ACPI, either a text string or a certain bit of ASL > > > >>> bytecode? > > > >> > > > >>We already have the quirk for this broken BIOS. However, > > > >> keyboard probing happens way earlier to use this quirk. :-( > > > >> > > > >>Jung-uk Kim > > > >> > > > >>>Scott > > > > > > > > Something that came up originally, when this issue was first > > > > noticed, was trying to figure out what, if any platforms, > > > > would have problems if this was made to apply to all AMD64 > > > > machines, and use the flag to drive an opt-out. In as far as > > > > I'm aware, no AMD64-based machines are effected if you just > > > > "break" the keyboard test functionality, though I'm not > > > > certain this is a path worth looking at, since its still a > > > > bit ugly. > > > > > > My number 1 concern is that 5.4-RELEASE 'Just Works' when you > > > load it onto a machine. Undocumented and under-documented > > > work-arounds are very hard to manage and don't help users that > > > aren't intimately familiar with the problem. This is a place > > > where ("Alert! Don the asbestos skivvies now!") adding an > > > option to ("I'm warning you! Prepare for flamage!") beastie.4th > > > might be a good idea. > > > > One possibility is adding DMI scan code in loader and passing > > BIOS ID strings to kernel because loader can easily call BIOS > > function calls. This won't require ugly hack in kernel space. > > I like this approach better. We already provide hints to ACPI via > the loader. I had some time last week and wrote the patch. This patch exports the following environment variables to loader: hint.smbios.0.enabled "YES" when SMBIOS is detected hint.smbios.0.bios.vendor BIOS vendor hint.smbios.0.bios.version BIOS version hint.smbios.0.bios.reldate BIOS release date hint.smbios.0.system.maker System manufacturer hint.smbios.0.system.product System product name hint.smbios.0.system.version System version number hint.smbios.0.planar.maker Base board manufacturer hint.smbios.0.planar.product Base board product name hint.smbios.0.planar.version Base board version number hint.smbios.0.chassis.maker Enclosure manufacturer hint.smbios.0.chassis.version Enclosure version If you think the information is excessive, you can comment them out. You can change the variable names if you don't like them. ;-) Cheers, Jung-uk Kim * Postscript: Matthew, http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/bios/smbios.c has the wrong SMBIOS EPS structure. According to 'System Management BIOS Reference Specification, v2.4 Final (http://www.dmtf.org/standards/published_documents/DSP0134.pdf)' page 13-14, correct structure is something like this: /* * SMBIOS Entry Point Structure */ struct smbios_eps { u_int8_t Anchor[4]; /* '_SM_' */ u_int8_t Checksum; u_int8_t Length; u_int8_t SMBIOS_Major; u_int8_t SMBIOS_Minor; u_int16_t Max_Size; u_int8_t Revision; u_int8_t Formatted_Area[5]; u_int8_t Intermediate_Anchor[5]; /* '_DMI_' */ u_int8_t Intermediate_Checksum; u_int16_t Structure_Table_Length; u_int32_t Structure_Table_Address; u_int16_t Structure_Count; u_int8_t SMBIOS_BCD_Revision; } __packed; Just FYI... --Boundary-00=_qQgkC9ldWlyB+M7 Content-Type: text/x-diff; charset="iso-8859-1"; name="smbios.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="smbios.diff" Index: src/sys/boot/i386/libi386/Makefile =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/libi386/Makefile,v retrieving revision 1.37 diff -u -r1.37 Makefile --- src/sys/boot/i386/libi386/Makefile 24 Oct 2004 15:32:49 -0000 1.37 +++ src/sys/boot/i386/libi386/Makefile 23 May 2005 15:39:03 -0000 @@ -8,7 +8,7 @@ comconsole.c devicename.c elf32_freebsd.c \ elf64_freebsd.c gatea20.c \ i386_copy.c i386_module.c nullconsole.c pxe.c pxetramp.s \ - time.c vidconsole.c amd64_tramp.S + smbios.c time.c vidconsole.c amd64_tramp.S BOOT_COMCONSOLE_PORT?= 0x3f8 CFLAGS+= -DCOMPORT=${BOOT_COMCONSOLE_PORT} Index: src/sys/boot/i386/libi386/libi386.h =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/libi386/libi386.h,v retrieving revision 1.19 diff -u -r1.19 libi386.h --- src/sys/boot/i386/libi386/libi386.h 22 Oct 2004 14:56:23 -0000 1.19 +++ src/sys/boot/i386/libi386/libi386.h 23 May 2005 15:39:03 -0000 @@ -99,6 +99,8 @@ void biosacpi_detect(); +void smbios_detect(); + void gateA20(void); int i386_autoload(void); --- src/sys/boot/i386/libi386/smbios.c Mon May 23 11:38:29 2005 +++ src/sys/boot/i386/libi386/smbios.c Fri May 20 21:50:45 2005 @@ -0,0 +1,176 @@ +/*- + * Copyright (c) 2005 Jung-uk Kim + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include + +#include "btxv86.h" + +/* + * Detect SMBIOS and export information about the SMBIOS into the + * environment. + * + * System Management BIOS Reference Specification, v2.4 Final + * http://www.dmtf.org/standards/published_documents/DSP0134.pdf + */ + +/* + * Spec. 2.1.1 SMBIOS Structure Table Entry Point + * + * 'The SMBIOS Entry Point structure, described below, can be located by + * application software by searching for the anchor-string on paragraph + * (16-byte) boundaries within the physical memory address range + * 000F0000h to 000FFFFFh.' + */ +#define SMBIOS_START 0xf0000 +#define SMBIOS_LENGTH 0x10000 +#define SMBIOS_STEP 0x10 +#define SMBIOS_SIG "_SM_" +#define SMBIOS_DMI_SIG "_DMI_" + +static u_int8_t *smbios_parse_table(const u_int8_t *dmi); +static void smbios_setenv(const char *env, const u_int8_t *dmi, + const int offset); +static u_int8_t smbios_checksum(const u_int8_t *addr, const u_int8_t len); +static u_int8_t *smbios_sigsearch(const caddr_t addr, const u_int32_t len); + +void +smbios_detect(void) +{ + u_int8_t *smbios, *dmi, *addr; + u_int16_t i, length, count; + u_int32_t paddr; + + /* locate and validate the SMBIOS */ + smbios = smbios_sigsearch(PTOV(SMBIOS_START), SMBIOS_LENGTH); + if (smbios == 0) + return; + + /* export values from the SMBIOS */ + setenv("hint.smbios.0.enabled", "YES", 1); + + length = *(u_int16_t *)(smbios + 0x16); /* Structure Table Length */ + paddr = *(u_int32_t *)(smbios + 0x18); /* Structure Table Address */ + count = *(u_int16_t *)(smbios + 0x1c); /* No of SMBIOS Structures */ + + for (dmi = addr = PTOV(paddr), i = 0; + dmi - addr < length && i < count; i++) + dmi = smbios_parse_table(dmi); +} + +static u_int8_t * +smbios_parse_table(const u_int8_t *dmi) +{ + u_int8_t *dp; + + switch(dmi[0]) { + case 0: /* Type 0: BIOS */ + smbios_setenv("hint.smbios.0.bios.vendor", dmi, 0x04); + smbios_setenv("hint.smbios.0.bios.version", dmi, 0x05); + smbios_setenv("hint.smbios.0.bios.reldate", dmi, 0x08); + break; + + case 1: /* Type 1: System */ + smbios_setenv("hint.smbios.0.system.maker", dmi, 0x04); + smbios_setenv("hint.smbios.0.system.product", dmi, 0x05); + smbios_setenv("hint.smbios.0.system.version", dmi, 0x06); + break; + + case 2: /* Type 2: Base Board (or Module) */ + smbios_setenv("hint.smbios.0.planar.maker", dmi, 0x04); + smbios_setenv("hint.smbios.0.planar.product", dmi, 0x05); + smbios_setenv("hint.smbios.0.planar.version", dmi, 0x06); + break; + + case 3: /* Type 3: System Enclosure or Chassis */ + smbios_setenv("hint.smbios.0.chassis.maker", dmi, 0x04); + smbios_setenv("hint.smbios.0.chassis.version", dmi, 0x06); + break; + + default: /* skip other types */ + break; + } + + /* find structure terminator */ + dp = (u_int8_t *)(dmi + dmi[1]); + while (dp[0] != 0 || dp[1] != 0) + dp++; + + return(dp + 2); +} + +static void +smbios_setenv(const char *str, const u_int8_t *dmi, const int offset) +{ + char *cp; + int i; + + /* skip undefined string */ + if (dmi[offset] == 0) + return; + + for (cp = (char *)(dmi + dmi[1]), i = 0; i < dmi[offset] - 1; i++) + cp += strlen(cp) + 1; + setenv(str, cp, 1); +} + +static u_int8_t +smbios_checksum(const u_int8_t *addr, const u_int8_t len) +{ + u_int8_t sum; + int i; + + for (sum = 0, i = 0; i < len; i++) + sum += addr[i]; + + return(sum); +} + +static u_int8_t * +smbios_sigsearch(const caddr_t addr, const u_int32_t len) +{ + caddr_t cp; + + /* search on 16-byte boundaries */ + for (cp = addr; cp - addr < len; cp += SMBIOS_STEP) { + /* compare signature, validate checksum */ + if (!strncmp(cp, SMBIOS_SIG, 4)) { + if (smbios_checksum(cp, *(cp + 0x05))) + continue; + if (strncmp(cp + 0x10, SMBIOS_DMI_SIG, 5)) + continue; + if (smbios_checksum(cp + 0x10, 0x0f)) + continue; + + return(cp); + } + } + + return(0); +} Index: src/sys/boot/i386/loader/main.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/loader/main.c,v retrieving revision 1.30 diff -u -r1.30 main.c --- src/sys/boot/i386/loader/main.c 22 Oct 2004 14:57:28 -0000 1.30 +++ src/sys/boot/i386/loader/main.c 23 May 2005 15:39:04 -0000 @@ -140,6 +140,9 @@ /* detect ACPI for future reference */ biosacpi_detect(); + /* detect SMBIOS for future reference */ + smbios_detect(); + printf("\n"); printf("%s, Revision %s\n", bootprog_name, bootprog_rev); printf("(%s, %s)\n", bootprog_maker, bootprog_date); --Boundary-00=_qQgkC9ldWlyB+M7-- From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 17:44:18 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7282D16A41C for ; Mon, 23 May 2005 17:44:18 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 139C743D53 for ; Mon, 23 May 2005 17:44:18 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 11248 invoked from network); 23 May 2005 17:44:17 -0000 Received: by simscan 1.1.0 ppid: 11233, pid: 11242, t: 0.1225s scanners: clamav: 0.84/m:31/d:888 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail24.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 May 2005 17:44:17 -0000 Received: from hydrogen.funkthat.com (knwluz@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.12.10/8.11.6) with ESMTP id j4NHiG2g076790; Mon, 23 May 2005 10:44:16 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j4NHiGQZ076789; Mon, 23 May 2005 10:44:16 -0700 (PDT) Date: Mon, 23 May 2005 10:44:15 -0700 From: John-Mark Gurney To: Sven Willenberger Message-ID: <20050523174415.GI959@funkthat.com> Mail-Followup-To: Sven Willenberger , freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org References: <1116860293.10083.43.camel@lanshark.dmv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116860293.10083.43.camel@lanshark.dmv.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Manipulating disk cache (buf) settings X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 17:44:18 -0000 Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400: > We are running a PostgreSQL server (8.0.3) on a dual opteron system with > 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show > values of 215MB and 225771520 (which equals 215MB) respectively. My > understanding from having searched the archives is that this is the > value that is used by the system/kernel in determining how much disk > data to cache. This is incorrect... FreeBSD merged the vm and buf systems a while back, so all of memory is used as a disk cache.. The buf cache is still used for filesystem meta data (and for pending writes of files, but those buf's reference the original page, not local storage)... Just as an experiment, on a quiet system do: dd if=/dev/zero of=somefile bs=1m count=2048 and then read it back in: dd if=somefile of=/dev/null bs=1m and watch systat or iostat and see if any of the file is read... You'll probably see that none of it is... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 18:01:40 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A00316A41C; Mon, 23 May 2005 18:01:40 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D6843D54; Mon, 23 May 2005 18:01:39 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id 44D6878C8E; Mon, 23 May 2005 14:01:41 -0400 (EDT) Received: from 172.19.206.153 ([172.19.206.153]) by mail.afflictions.org (Horde) with HTTP for ; Mon, 23 May 2005 14:01:40 -0400 Message-ID: <20050523140140.heswsw004gg0ggos@mail.afflictions.org> Date: Mon, 23 May 2005 14:01:40 -0400 From: Damian Gerow To: pav@FreeBSD.org References: <20050521022130.GW52914@afflictions.org> <20050521064120.GA51907@xor.obsecurity.org> <20050522043251.GA87263@afflictions.org> <1116761705.23538.7.camel@hood.oook.cz> In-Reply-To: <1116761705.23538.7.camel@hood.oook.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-ALPHA X-Originating-IP: 172.19.206.153 X-Abuse-Address: abuse@afflictions.org Cc: Damian Gerow , freebsd-amd64@FreeBSD.org Subject: Re: mplayer, amd64, and CPU flags 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, 23 May 2005 18:01:40 -0000 Thus spake Pav Lucistnik : >> FWIW, by manually enabling the various flags, I see DVD decryption jump up >> at least five frames per second, from anywhere between seven and ten to at >> least fifteen. That's a 50% speed increase. > > I haven't noticed any speedup on DVD playback from these flags. Note that I said 'decryption' and not 'playback'. Frankly, I don't want my playback to speed up at all: I like watching my movies at normal speed. ;) From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 18:49:29 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E6B116A41C; Mon, 23 May 2005 18:49:29 +0000 (GMT) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD38643D48; Mon, 23 May 2005 18:49:28 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id j4NInRWa022821; Mon, 23 May 2005 14:49:27 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: John-Mark Gurney In-Reply-To: <20050523174415.GI959@funkthat.com> References: <1116860293.10083.43.camel@lanshark.dmv.com> <20050523174415.GI959@funkthat.com> Content-Type: text/plain Date: Mon, 23 May 2005 14:50:04 -0400 Message-Id: <1116874204.10077.61.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Manipulating disk cache (buf) settings 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, 23 May 2005 18:49:29 -0000 On Mon, 2005-05-23 at 10:44 -0700, John-Mark Gurney wrote: > Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400: > > We are running a PostgreSQL server (8.0.3) on a dual opteron system with > > 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show > > values of 215MB and 225771520 (which equals 215MB) respectively. My > > understanding from having searched the archives is that this is the > > value that is used by the system/kernel in determining how much disk > > data to cache. > > This is incorrect... FreeBSD merged the vm and buf systems a while back, > so all of memory is used as a disk cache.. The buf cache is still used > for filesystem meta data (and for pending writes of files, but those buf's > reference the original page, not local storage)... > > Just as an experiment, on a quiet system do: > dd if=/dev/zero of=somefile bs=1m count=2048 > and then read it back in: > dd if=somefile of=/dev/null bs=1m > and watch systat or iostat and see if any of the file is read... You'll > probably see that none of it is... > Yes, confirmed as stated, this is great news then. In essence the PostgreSQL planner can be told that the effective cache size is *much* larger than that calculated by using vfs.hibufspace; should result in some [hopefully] marked performance boosts. btw: > dd if=/dev/zero of=zerofile bs=1m count=2048 2048+0 records in 2048+0 records out 2147483648 bytes transferred in 43.381462 secs (49502335 bytes/sec) > dd if=zerofile of=/dev/null bs=1m 2048+0 records in 2048+0 records out 2147483648 bytes transferred in 5.304807 secs (404818435 bytes/sec) and that was on a 3GB RAM system so the caching scheme works great. Sven From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 19:52:12 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3851416A41C for ; Mon, 23 May 2005 19:52:12 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (hood.oook.cz [212.27.205.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A6C343D1F for ; Mon, 23 May 2005 19:52:09 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (localhost.oook.cz [127.0.0.1]) by hood.oook.cz (8.13.3/8.13.3) with ESMTP id j4NJq1Df003903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2005 21:52:01 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by hood.oook.cz (8.13.3/8.13.3/Submit) id j4NJq0p1003902; Mon, 23 May 2005 21:52:00 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: hood.oook.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: Damian Gerow In-Reply-To: <20050523140140.heswsw004gg0ggos@mail.afflictions.org> References: <20050521022130.GW52914@afflictions.org> <20050521064120.GA51907@xor.obsecurity.org> <20050522043251.GA87263@afflictions.org> <1116761705.23538.7.camel@hood.oook.cz> <20050523140140.heswsw004gg0ggos@mail.afflictions.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fdMHskcXMIOSqQxWGQ5w" Date: Mon, 23 May 2005 21:52:00 +0200 Message-Id: <1116877920.2708.10.camel@hood.oook.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Cc: freebsd-amd64@FreeBSD.org Subject: Re: mplayer, amd64, and CPU flags X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 19:52:12 -0000 --=-fdMHskcXMIOSqQxWGQ5w Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Damian Gerow p=ED=B9e v po 23. 05. 2005 v 14:01 -0400: > Thus spake Pav Lucistnik : > >> FWIW, by manually enabling the various flags, I see DVD decryption jum= p up > >> at least five frames per second, from anywhere between seven and ten t= o at > >> least fifteen. That's a 50% speed increase. > > > > I haven't noticed any speedup on DVD playback from these flags. >=20 > Note that I said 'decryption' and not 'playback'. Frankly, I don't want = my > playback to speed up at all: I like watching my movies at normal speed. Whatever. I switched to xine, which is - much nicer to DVD unit, it only flashes activity from time to time, just like PowerDVD on Windows do, mplayer was reading all the time - can do menus really well - have actually usable GUI, which, if nothing, allows you to switch audio/subtitle stream or deinterlacing on the fly Mplayer sucks, folks, really hard. I still love him. ;) BTW Damian, I'm getting bounces when I mail you directly, something about timeouts, you may want to re-check your mail setup. --=20 Pav Lucistnik An arrow (+0,+0) {@f0} finds a mark. It dies. --=-fdMHskcXMIOSqQxWGQ5w Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCkjRgntdYP8FOsoIRAjO/AJ0QDO2hofFdoil9CDQl942cf60E3QCgiHaf YZgFL/fhTqENMw4ii037fgk= =uIcV -----END PGP SIGNATURE----- --=-fdMHskcXMIOSqQxWGQ5w-- From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 21:17:18 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A06E16A41C; Mon, 23 May 2005 21:17:18 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64DF043D1D; Mon, 23 May 2005 21:17:18 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 4F6ECB879; Mon, 23 May 2005 17:17:17 -0400 (EDT) In-Reply-To: <20050523174415.GI959@funkthat.com> References: <1116860293.10083.43.camel@lanshark.dmv.com> <20050523174415.GI959@funkthat.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F46458B-2524-42AB-8B3D-0F54F485241B@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Mon, 23 May 2005 17:17:16 -0400 To: freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.730) Cc: freebsd-stable@freebsd.org Subject: Re: Manipulating disk cache (buf) settings 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, 23 May 2005 21:17:18 -0000 On May 23, 2005, at 1:44 PM, John-Mark Gurney wrote: > This is incorrect... FreeBSD merged the vm and buf systems a while > back, > so all of memory is used as a disk cache.. The buf cache is still > used > for filesystem meta data (and for pending writes of files, but > those buf's > reference the original page, not local storage)... > Cool... So what would you recommend telling an application like Postgres what the cache size is? All of RAM? That seems unlikely given much of the ram is used for other things. Is there no upper bound in how much RAM will be used for the cache? Vivek Khera, Ph.D. +1-301-869-4449 x806 From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 23:30:03 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E919516A41C for ; Mon, 23 May 2005 23:30:03 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48B3A43D53 for ; Mon, 23 May 2005 23:30:03 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 23690 invoked from network); 23 May 2005 23:30:03 -0000 Received: by simscan 1.1.0 ppid: 23670, pid: 23684, t: 0.1334s scanners: clamav: 0.84/m:31/d:888 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail24.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 May 2005 23:30:02 -0000 Received: from hydrogen.funkthat.com (yrozoh@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.12.10/8.11.6) with ESMTP id j4NNU22g086135; Mon, 23 May 2005 16:30:02 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j4NNTngu086116; Mon, 23 May 2005 16:29:49 -0700 (PDT) Date: Mon, 23 May 2005 16:29:49 -0700 From: John-Mark Gurney To: Vivek Khera Message-ID: <20050523232948.GJ959@funkthat.com> Mail-Followup-To: Vivek Khera , freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org References: <1116860293.10083.43.camel@lanshark.dmv.com> <20050523174415.GI959@funkthat.com> <1F46458B-2524-42AB-8B3D-0F54F485241B@khera.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F46458B-2524-42AB-8B3D-0F54F485241B@khera.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Manipulating disk cache (buf) settings X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 23:30:04 -0000 Vivek Khera wrote this message on Mon, May 23, 2005 at 17:17 -0400: > On May 23, 2005, at 1:44 PM, John-Mark Gurney wrote: > > >This is incorrect... FreeBSD merged the vm and buf systems a while > >back, > >so all of memory is used as a disk cache.. The buf cache is still > >used > >for filesystem meta data (and for pending writes of files, but > >those buf's > >reference the original page, not local storage)... > > > > Cool... So what would you recommend telling an application like > Postgres what the cache size is? All of RAM? That seems unlikely > given much of the ram is used for other things. Is there no upper > bound in how much RAM will be used for the cache? I'm not familar host Postgres uses the cache number to change it's behavior, but I would say choose a responable amount of memory that you expect to regularly have available on the system... If you are only using it for db, and a few other small processes, 512meg less than ram is probably reasonable... The other way is to try a few different values and see how it impacts performance.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 01:15:09 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C93FA16A41C; Tue, 24 May 2005 01:15:09 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 692DA43D1D; Tue, 24 May 2005 01:15:09 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id E339778C95; Mon, 23 May 2005 21:15:11 -0400 (EDT) Received: from pandora.afflictions.org ([127.0.0.1]) by localhost (pandora.afflictions.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49239-08; Mon, 23 May 2005 21:15:08 -0400 (EDT) Received: from dementia.afflictions.org (dementia.afflictions.org [172.19.206.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pandora.afflictions.org (Postfix) with ESMTP id 75FB478C89; Mon, 23 May 2005 21:15:07 -0400 (EDT) Received: by dementia.afflictions.org (Postfix, from userid 1001) id DE65533C30; Mon, 23 May 2005 21:15:01 -0400 (EDT) Date: Mon, 23 May 2005 21:15:01 -0400 From: Damian Gerow To: Pav Lucistnik Message-ID: <20050524011501.GA28277@afflictions.org> Mail-Followup-To: Pav Lucistnik , freebsd-amd64@FreeBSD.org References: <20050521022130.GW52914@afflictions.org> <20050521064120.GA51907@xor.obsecurity.org> <20050522043251.GA87263@afflictions.org> <1116761705.23538.7.camel@hood.oook.cz> <20050523140140.heswsw004gg0ggos@mail.afflictions.org> <1116877920.2708.10.camel@hood.oook.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116877920.2708.10.camel@hood.oook.cz> X-GPG-Fingerprint: B3D7 D901 A53A 1A99 BFD6 E6DF 9F3B 742B C288 9CC9 User-Agent: Mutt/1.5.9i X-Virus-Scanned: amavisd-new at pandora.afflictions.org Cc: freebsd-amd64@FreeBSD.org Subject: Re: mplayer, amd64, and CPU flags 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, 24 May 2005 01:15:09 -0000 Thus spake Pav Lucistnik (pav@FreeBSD.org) [23/05/05 15:52]: : BTW Damian, I'm getting bounces when I mail you directly, something : about timeouts, you may want to re-check your mail setup. That would be because my mail server's currently on the move. From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 01:18:25 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE12416A41C; Tue, 24 May 2005 01:18:24 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C2A343D1D; Tue, 24 May 2005 01:18:24 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4O1IDrI029594; Tue, 24 May 2005 11:18:13 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4O1IBqB011672; Tue, 24 May 2005 11:18:12 +1000 Date: Tue, 24 May 2005 11:18:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John-Mark Gurney In-Reply-To: <20050523174415.GI959@funkthat.com> Message-ID: <20050524104940.O68917@delplex.bde.org> References: <1116860293.10083.43.camel@lanshark.dmv.com> <20050523174415.GI959@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Manipulating disk cache (buf) settings 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, 24 May 2005 01:18:25 -0000 On Mon, 23 May 2005, John-Mark Gurney wrote: > Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400: >> We are running a PostgreSQL server (8.0.3) on a dual opteron system with >> 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show >> values of 215MB and 225771520 (which equals 215MB) respectively. My >> understanding from having searched the archives is that this is the >> value that is used by the system/kernel in determining how much disk >> data to cache. > > This is incorrect... FreeBSD merged the vm and buf systems a while back, > so all of memory is used as a disk cache.. Indeed. Statistics utilities still haven't caught up with dyson's changes in 1994 or 1995, so their display of statistics related to disk caching is very misleading. systat -v and top display vfs.bufspace but not vfs.hibufspace. Both of these are uninitersting. vfs.bufspace gives the amount of virtual memory that is currently allocated to the buffer cache. vfs.hibufspace gives the maximum for this amount. Virtual memory for buffers is almost never released, so on active systems vfs.bufspace is close to the maximum. The maximum is just a compile-time constand (BKVASIZE) times a boot-time constant (nbuf). There is no way to tell from userland exactly how much of memory is used for the vm part of the disk cache. "inact" in systat -v gives a maximum. Watch heavy file system for a while and you may see "inact" increase as vm is used for disk data. It decreases mainly when a file system is unmounted. Otherwise, it tends to stay near its maximum, with pages for not recently used disk data being reused for something else (newer disk data or processes). > The buf cache is still used > for filesystem meta data (and for pending writes of files, but those buf's > reference the original page, not local storage)... This is mostly incorrect. The buffer cache is now little more than a window on vm. Metadata is backed by vm except for low quality file systems. Directories are backed by vm unless vfs.vmiodirenable is 0 (not the default). > Just as an experiment, on a quiet system do: > dd if=/dev/zero of=somefile bs=1m count=2048 > and then read it back in: > dd if=somefile of=/dev/null bs=1m > and watch systat or iostat and see if any of the file is read... You'll > probably see that none of it is... Also, with systat -v: - start with "inact" small and watch it grow as the file is cached - remove the file and watch "inact" drop. I haven't tried this lately. The system has some defence against using up all of the free and inactive pages for a single file to the exclusion of other disk data, so you might not get 2GB cached even if you have 4GB memory. > If that is in fact the case, then my question would be how to best > increase the amount of memory the system can use for disk caching. Just add RAM and don't run bloatware :-). Bruce From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 09:33:55 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A150916A41C for ; Tue, 24 May 2005 09:33:55 +0000 (GMT) (envelope-from groot@kde.org) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FEFA43D48 for ; Tue, 24 May 2005 09:33:54 +0000 (GMT) (envelope-from groot@kde.org) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost.englishbreakfastnetwork.org) by pandora.cs.kun.nl (8.12.10/5.2) with ESMTP id j4O9Xokk003477 for ; Tue, 24 May 2005 11:33:50 +0200 (MEST) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Tue, 24 May 2005 11:33:50 +0200 User-Agent: KMail/1.8.50 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505241133.50199.groot@kde.org> X-Scanned-By: MIMEDefang 2.48 on 131.174.33.4 Subject: (ATI chipsets|mATX boards) and 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: Tue, 24 May 2005 09:33:55 -0000 In the interest of covering more of the bases wrt. consumer chipsets for the hardware compat page, has anyone ever used FreeBSD-amd64 with either of the following boards (and if so, how successful was it)? - MSI RX480M2. This is an ATI chipset, ATI Radeon XPRESS 200P, which I've never seen mentioned on the list before. It might be an interesting kind of board, with PCI-E for video but no useless PCI-E x1 slots. - Gigabyte GA-K8VM800M. This is VIA's K8M800 chipset - it _looks_ ilke a K8T800 with an integrated video, that's all. A mATX board, this might be interesting for low-endish desktop machines. -- These are your friends - Adem GPG: FEA2 A3FE Adriaan de Groot From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 14:14:48 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66F6016A41F; Tue, 24 May 2005 14:14:48 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33F5E43D58; Tue, 24 May 2005 14:14:48 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id C5A08B878; Tue, 24 May 2005 10:14:47 -0400 (EDT) In-Reply-To: <20050523232948.GJ959@funkthat.com> References: <1116860293.10083.43.camel@lanshark.dmv.com> <20050523174415.GI959@funkthat.com> <1F46458B-2524-42AB-8B3D-0F54F485241B@khera.org> <20050523232948.GJ959@funkthat.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Tue, 24 May 2005 10:14:47 -0400 To: freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.730) Cc: freebsd-stable@freebsd.org Subject: Re: Manipulating disk cache (buf) settings 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, 24 May 2005 14:14:48 -0000 On May 23, 2005, at 7:29 PM, John-Mark Gurney wrote: > Vivek Khera wrote this message on Mon, May 23, 2005 at 17:17 -0400: >> >> Cool... So what would you recommend telling an application like >> Postgres what the cache size is? All of RAM? That seems unlikely >> given much of the ram is used for other things. Is there no upper >> bound in how much RAM will be used for the cache? >> > > I'm not familar host Postgres uses the cache number to change it's > behavior, but I would say choose a responable amount of memory that > you expect to regularly have available on the system... If you are > only using it for db, and a few other small processes, 512meg less > than ram is probably reasonable... Thanks. Since PG also uses a bunch of RAM for internal ops like sorting and such, I suspect telling it that 50% of RAM is available for cache will be good. Testing theory now... :-) Vivek Khera, Ph.D. +1-301-869-4449 x806 From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 15:14:50 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DDA816A41C for ; Tue, 24 May 2005 15:14:50 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9804C43D48 for ; Tue, 24 May 2005 15:14:49 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd21.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1Dab7E-0004d4-00; Tue, 24 May 2005 17:14:44 +0200 Received: from fw.reifenberger.com (EIJ1TYZTweCUeoE89ySGHW0uI7VvbadM1wt+hrWqOyHHkYd9ap8cri@[84.152.77.151]) by fwd21.sul.t-online.de with esmtp id 1Dab71-1WTwsC0; Tue, 24 May 2005 17:14:31 +0200 Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.3/8.13.3/Submit) with ESMTP id j4OFEEL9009688 for ; Tue, 24 May 2005 17:14:14 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 24 May 2005 17:14:14 +0200 (CEST) From: Michael Reifenberger To: amd64@freebsd.org Message-ID: <20050524165452.A9190@fw.reifenberger.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: EIJ1TYZTweCUeoE89ySGHW0uI7VvbadM1wt+hrWqOyHHkYd9ap8cri@t-dialin.net X-TOI-MSGID: ed52ed7b-a8b3-449b-b1b9-1fa491ac1898 Cc: Subject: producing/using i386 libs/apps under 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: Tue, 24 May 2005 15:14:50 -0000 Hi, there seems to be at last two instances of the same problem when using freebsd/amd64: (openoffice-1.1.4): After compiling all base libs for i386 (into /usr/lib32) and fetching the missing i386 libs from an i386 machine (into /usr/lib32) starting openoffice.org-1.1.4 leads to: /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libXmu.so.6: unsupported file layout ( It seems to be the wrong linker which uses the wrong lib... ) (/sys/boot/ficl/): make testmain fails with: cc -O -pipe -fno-strict-aliasing -ffreestanding -mpreferred-stack-boundary=2 -DTESTMAIN -D_TESTMAIN -m32 -I. -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/i386 -I/usr/src/sys/boot/ficl/../common -c /usr/src/sys/boot/ficl/testmain.c cc -O -pipe -fno-strict-aliasing -ffreestanding -mpreferred-stack-boundary=2 -DTESTMAIN -D_TESTMAIN -m32 -I. -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/i386 -I/usr/src/sys/boot/ficl/../common -o testmain dict.o ficl.o fileaccess.o float.o loader.o math64.o prefix.o search.o stack.o tools.o vm.o words.o sysdep.o softcore.o testmain.o /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc *** Error code 1 (Here it seems that the linker is not aware of the -m32 option) Is someone working in this area? Or are there workarounds available? Thanks! Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 15:16:39 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D726216A41C for ; Tue, 24 May 2005 15:16:39 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A41D43D49 for ; Tue, 24 May 2005 15:16:39 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd23.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Dab93-00027w-05; Tue, 24 May 2005 17:16:37 +0200 Received: from fw.reifenberger.com (bHsovEZbZeY0mlxS3vNs+YX-xKxJUl2UmddI3CZt0IPQOUccxQzlwl@[84.152.77.151]) by fwd23.sul.t-online.de with esmtp id 1Dab91-1V69c80; Tue, 24 May 2005 17:16:35 +0200 Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.3/8.13.3/Submit) with ESMTP id j4OFGG7i009697 for ; Tue, 24 May 2005 17:16:19 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 24 May 2005 17:16:16 +0200 (CEST) From: Michael Reifenberger To: amd64@freebsd.org Message-ID: <20050524171448.A9190@fw.reifenberger.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: bHsovEZbZeY0mlxS3vNs+YX-xKxJUl2UmddI3CZt0IPQOUccxQzlwl@t-dialin.net X-TOI-MSGID: 58723cb2-8b4b-405b-be79-7e0d9b4e171d Cc: Subject: debugging amd64 kernel via firewire from i386? 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, 24 May 2005 15:16:40 -0000 Hi, does the above work? Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 15:24:02 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 914A416A41C for ; Tue, 24 May 2005 15:24:02 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B5E43D1D for ; Tue, 24 May 2005 15:24:02 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4OFO1mn031596; Tue, 24 May 2005 08:24:01 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4OFO14q031595; Tue, 24 May 2005 08:24:01 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 May 2005 08:24:01 -0700 From: "David O'Brien" To: Michael Reifenberger Message-ID: <20050524152401.GA31564@dragon.NUXI.org> References: <20050524165452.A9190@fw.reifenberger.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524165452.A9190@fw.reifenberger.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: producing/using i386 libs/apps under amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 15:24:02 -0000 On Tue, May 24, 2005 at 05:14:14PM +0200, Michael Reifenberger wrote: > (/sys/boot/ficl/): > make testmain fails with: > cc -O -pipe -fno-strict-aliasing -ffreestanding > -mpreferred-stack-boundary=2 -DTESTMAIN -D_TESTMAIN -m32 -I. > -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/i386 > -I/usr/src/sys/boot/ficl/../common -c /usr/src/sys/boot/ficl/testmain.c > cc -O -pipe -fno-strict-aliasing -ffreestanding > -mpreferred-stack-boundary=2 -DTESTMAIN -D_TESTMAIN -m32 -I. > -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/i386 > -I/usr/src/sys/boot/ficl/../common -o testmain dict.o ficl.o fileaccess.o > float.o loader.o math64.o prefix.o search.o stack.o tools.o vm.o words.o > sysdep.o softcore.o testmain.o > /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for > -lgcc /usr/bin/ld: cannot find -lgcc > *** Error code 1 > > (Here it seems that the linker is not aware of the -m32 option) We do not yet support building 32-bit binaries under FreeBSD/amd64. We support running them. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 15:29:46 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0522716A41C for ; Tue, 24 May 2005 15:29:46 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90CC143D53 for ; Tue, 24 May 2005 15:29:45 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4OFTiDG031690; Tue, 24 May 2005 08:29:44 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4OFTioP031689; Tue, 24 May 2005 08:29:44 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 May 2005 08:29:44 -0700 From: "David O'Brien" To: Adriaan de Groot Message-ID: <20050524152944.GB31564@dragon.NUXI.org> References: <200505241133.50199.groot@kde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505241133.50199.groot@kde.org> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: (ATI chipsets|mATX boards) and amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 15:29:46 -0000 On Tue, May 24, 2005 at 11:33:50AM +0200, Adriaan de Groot wrote: > In the interest of covering more of the bases wrt. consumer chipsets for the > hardware compat page, has anyone ever used FreeBSD-amd64 with either of the > following boards (and if so, how successful was it)? > > - MSI RX480M2. This is an ATI chipset, ATI Radeon XPRESS 200P, which I've > never seen mentioned on the list before. It might be an interesting kind of > board, with PCI-E for video but no useless PCI-E x1 slots. I'll let you know ASAP. I was building one of these and an Asus K8N-DL this past weekend (but didn't have time to finish the MSI RX480M2). One thing I don't like about the MSI RX480M2 is that it doesn't have a serial port on the back connector. :~-( It does have a parallel port... which I'm surprised wasn't "lost" before loosing the serial port. There is a serial port header on the motherboard, but the needed cable isn't included with the motherboard, and the header is in a place that typical header cables aren't long enough. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 15:33:00 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5053916A41C for ; Tue, 24 May 2005 15:33:00 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D16843D4C for ; Tue, 24 May 2005 15:32:58 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4OFWp9I031810; Tue, 24 May 2005 08:32:51 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4OFWpbO031801; Tue, 24 May 2005 08:32:51 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 May 2005 08:32:50 -0700 From: "David O'Brien" To: "Ryan R." Message-ID: <20050524153250.GC31564@dragon.NUXI.org> References: <4905.127.0.0.1.1116698556.squirrel@www.epicoftimewasted.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4905.127.0.0.1.1116698556.squirrel@www.epicoftimewasted.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: 5.4-RELEASE Athlon64 E3/E4 core support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 15:33:00 -0000 On Sat, May 21, 2005 at 02:02:36PM -0400, Ryan R. wrote: > So, I once again wipe the drive, but this time I install 5.4-RELEASE/i386. > It installs fine, and boots fine. One thing I notice during boot, is > that SSE3 isn't detected by the kernel as a CPU feature anymore (amd64 > build did detect it). This has been corrected in 6-CURRENT. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 15:49:13 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DDE316A41C for ; Tue, 24 May 2005 15:49:13 +0000 (GMT) (envelope-from ingrid@cityscope.net) Received: from ns1.cityscope.net (cityscope.net [66.151.76.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9D3C43D1F for ; Tue, 24 May 2005 15:49:10 +0000 (GMT) (envelope-from ingrid@cityscope.net) Received: from ingrid (user-0ceie2f.cable.mindspring.com [24.233.56.79]) by ns1.cityscope.net (8.12.1/8.12.1) with ESMTP id j4OFnBCb013490 for ; Tue, 24 May 2005 10:49:11 -0500 (CDT) Message-Id: <200505241549.j4OFnBCb013490@ns1.cityscope.net> From: "Ingrid Kast Fuller" To: Date: Tue, 24 May 2005 10:49:04 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcVgeBzJCVF8gCWzQCmjqfWEHd+C7Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Gigabyte GA-K8VM800M 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, 24 May 2005 15:49:13 -0000 Has anyone used the following motherboard or know if there are any problems with it and FreeBSD? On this website, I only see the following motherboard: http://www.freebsd.org/platforms/amd64/motherboards.html GA-K8VT800 VIA K8T800 / Socket 754 Fully functional Adriaan de Groot ( dmesg) 5.3-RELEASE, 5.4-STABLE NIC is Realtek. Sound untested, but should work. Ingrid Kast Fuller CityScope Net 713-477-6161 http://www.cityscope.net Are you making a return on your website investment? If not, call CityScope, we can help you change that! From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 15:59:26 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABB7616A420 for ; Tue, 24 May 2005 15:59:26 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D51B843D54 for ; Tue, 24 May 2005 15:59:25 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4OFxOmN032651; Tue, 24 May 2005 08:59:24 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4OFxOAX032650; Tue, 24 May 2005 08:59:24 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 May 2005 08:59:24 -0700 From: "David O'Brien" To: Neil Short Message-ID: <20050524155924.GE31564@dragon.NUXI.org> References: <20050520033116.62902.qmail@web30704.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520033116.62902.qmail@web30704.mail.mud.yahoo.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: device cpufreq X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 15:59:26 -0000 On Thu, May 19, 2005 at 08:31:16PM -0700, Neil Short wrote: > I updated to 6.0-CURRENT to test out the powernow > drivers on my machine. It's a laptop and the processor > is AMD Athlon-xpm. .. > carmen# dmesg > ... > CPU: AMD Athlon(tm) XP Processor 3000+ (1595.89-MHz > 686-class CPU) > Origin = "AuthenticAMD" Id = 0xf48 Stepping = 8 I'm surprised by this output - you have a K8 core CPU (754-pin rev. C0). Your BIOS should say something other than "Athlon(tm) XP". What laptop do you have? > Features=0x78bfbff OV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> > AMD Features=0xc0500000 > ... > cpu0 on motherboard > powernow0: on cpu0 This is correct. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 16:13:32 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9722216A41C for ; Tue, 24 May 2005 16:13:32 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4302E43D48 for ; Tue, 24 May 2005 16:13:32 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd30.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1Dac1D-0000y6-01; Tue, 24 May 2005 18:12:35 +0200 Received: from fw.reifenberger.com (bKigaOZB8eNj6077Cbg25bQWjx9o6J1VZ-nmwkdehrvFOmF8jS4swN@[84.152.77.151]) by fwd30.sul.t-online.de with esmtp id 1Dac10-0iOqbw0; Tue, 24 May 2005 18:12:22 +0200 Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.3/8.13.3/Submit) with ESMTP id j4OGC5bc009966 for ; Tue, 24 May 2005 18:12:05 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 24 May 2005 18:12:05 +0200 (CEST) From: Michael Reifenberger To: freebsd-amd64@freebsd.org In-Reply-To: <20050524152401.GA31564@dragon.NUXI.org> Message-ID: <20050524181051.F9190@fw.reifenberger.com> References: <20050524165452.A9190@fw.reifenberger.com> <20050524152401.GA31564@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: bKigaOZB8eNj6077Cbg25bQWjx9o6J1VZ-nmwkdehrvFOmF8jS4swN@t-dialin.net X-TOI-MSGID: 58d33703-b97a-434e-8445-e2591f6e53e6 Subject: Re: producing/using i386 libs/apps under 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: Tue, 24 May 2005 16:13:32 -0000 On Tue, 24 May 2005, David O'Brien wrote: ... >> (Here it seems that the linker is not aware of the -m32 option) > > We do not yet support building 32-bit binaries under FreeBSD/amd64. > We support running them. > Thats whats my impression. But the first example with openoffice showed that there is something wrong too. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 16:32:30 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0E3016A41C for ; Tue, 24 May 2005 16:32:30 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC61943D55 for ; Tue, 24 May 2005 16:32:30 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1DacKT-0007iS-00; Tue, 24 May 2005 18:32:29 +0200 Date: Tue, 24 May 2005 18:32:29 +0200 To: freebsd-amd64@freebsd.org Message-ID: <20050524163229.GE21800@poupinou.org> References: <20050520033116.62902.qmail@web30704.mail.mud.yahoo.com> <20050524155924.GE31564@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524155924.GE31564@dragon.NUXI.org> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot Cc: Subject: Re: device cpufreq 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, 24 May 2005 16:32:31 -0000 On Tue, May 24, 2005 at 08:59:24AM -0700, David O'Brien wrote: > On Thu, May 19, 2005 at 08:31:16PM -0700, Neil Short wrote: > > I updated to 6.0-CURRENT to test out the powernow > > drivers on my machine. It's a laptop and the processor > > is AMD Athlon-xpm. > .. > > carmen# dmesg > > ... > > CPU: AMD Athlon(tm) XP Processor 3000+ (1595.89-MHz > > 686-class CPU) > > Origin = "AuthenticAMD" Id = 0xf48 Stepping = 8 > > I'm surprised by this output - you have a K8 core CPU (754-pin rev. C0). > Your BIOS should say something other than "Athlon(tm) XP". What laptop > do you have? Some amd64 with long mode disabled are called 'sempron' due to some QA failing tests. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 17:33:22 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5657016A41C for ; Tue, 24 May 2005 17:33:22 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E57643D48 for ; Tue, 24 May 2005 17:33:22 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4OHXKib034744; Tue, 24 May 2005 10:33:21 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4OHXJZW034743; Tue, 24 May 2005 10:33:19 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 May 2005 10:33:19 -0700 From: "David O'Brien" To: Bruno Ducrot Message-ID: <20050524173319.GA34689@dragon.NUXI.org> References: <20050520033116.62902.qmail@web30704.mail.mud.yahoo.com> <20050524155924.GE31564@dragon.NUXI.org> <20050524163229.GE21800@poupinou.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524163229.GE21800@poupinou.org> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: device cpufreq X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 17:33:22 -0000 On Tue, May 24, 2005 at 06:32:29PM +0200, Bruno Ducrot wrote: > On Tue, May 24, 2005 at 08:59:24AM -0700, David O'Brien wrote: > > On Thu, May 19, 2005 at 08:31:16PM -0700, Neil Short wrote: > > > I updated to 6.0-CURRENT to test out the powernow > > > drivers on my machine. It's a laptop and the processor > > > is AMD Athlon-xpm. > > .. > > > carmen# dmesg > > > ... > > > CPU: AMD Athlon(tm) XP Processor 3000+ (1595.89-MHz > > > 686-class CPU) > > > Origin = "AuthenticAMD" Id = 0xf48 Stepping = 8 > > > > I'm surprised by this output - you have a K8 core CPU (754-pin rev. C0). > > Your BIOS should say something other than "Athlon(tm) XP". What laptop > > do you have? > > Some amd64 with long mode disabled are called 'sempron' due to some QA > failing tests. Uh, no. AMD wishes to sell a 32-bit "value" CPU. They are called the Sempron brand. It makes most sense from a manufacturing POV to make these from a K8 derived core than to continue to produce K7 derivatives. A Sempron is not an Athlon64 that failed QA tests. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 17:53:24 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F47A16A41C for ; Tue, 24 May 2005 17:53:24 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EE9843D1F for ; Tue, 24 May 2005 17:53:24 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4OHrMCo035291; Tue, 24 May 2005 10:53:22 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4OHrFdQ035284; Tue, 24 May 2005 10:53:15 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 May 2005 10:53:15 -0700 From: "David O'Brien" To: =?unknown-8bit?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= Message-ID: <20050524175315.GA35171@dragon.NUXI.org> References: <42842F46.9040608@samsco.org> <4284FD37.2070009@jonny.eng.br> <20050519054630.GC68698@dragon.NUXI.org> <428CC670.50002@jonny.eng.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428CC670.50002@jonny.eng.br> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: Actual benefits of amd64 over i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 17:53:24 -0000 On Thu, May 19, 2005 at 02:01:36PM -0300, Joo Carlos Mendes Lus wrote: > David O'Brien wrote: > > On Fri, May 13, 2005 at 04:17:11PM -0300, Joo Carlos Mendes Lus wrote: > > > >> What about a 64 bit kernel, and mixed mode (32bit and 64bit) > >>userland? Solaris does this, and it sounds efficient, from the comments > >>I've seen in this list. > > > > > > When Sparc went from 32-bits to 64-bits the calling ABI was not changed. > > Nor were the number of registers increased. So it is w/o a doubt that a > > 32-bit Sparc binary runs faster than a 64-bit one (abit 64-bit math and > > large memory). This is not true of AMD64 - the number of registers was > > doubled and the calling ABI changed and optimized. > > Would these benefits outcome the losses caused by bigger binaries? > Isn't it possible to use 64 bit registers in a 32 bit segment? Just > like i386 segments, where one could define the default register size... .. > > What is the difference of "i386 emulation" and "native 32 bit executables > > in amd64 arch"?? > > IMHO, the 32bit binaries prepared to run in amd64 32bit segments are > not the same as 32 binaries prepared to run in i386 mode. These "32bit > amd64 executables" would take advantage of the extra registers and 64 > bit extensions when possible. It is not possible to access the extra registers in 32-bit mode. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 19:32:21 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43A1316A41C for ; Tue, 24 May 2005 19:32:21 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8F2343D48 for ; Tue, 24 May 2005 19:32:20 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1Daf8V-0007sN-00; Tue, 24 May 2005 21:32:19 +0200 Date: Tue, 24 May 2005 21:32:19 +0200 To: freebsd-amd64@freebsd.org Message-ID: <20050524193219.GG21800@poupinou.org> References: <20050520033116.62902.qmail@web30704.mail.mud.yahoo.com> <20050524155924.GE31564@dragon.NUXI.org> <20050524163229.GE21800@poupinou.org> <20050524173319.GA34689@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524173319.GA34689@dragon.NUXI.org> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot Subject: Re: device cpufreq 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, 24 May 2005 19:32:21 -0000 On Tue, May 24, 2005 at 10:33:19AM -0700, David O'Brien wrote: > Uh, no. > > AMD wishes to sell a 32-bit "value" CPU. They are called the Sempron > brand. It makes most sense from a manufacturing POV to make these from a > K8 derived core than to continue to produce K7 derivatives. A Sempron is > not an Athlon64 that failed QA tests. I don't say that. I said only some (early) Sempron are such amd64 with 64 bit turned off. Maybe I misread and badly interpreted this page: http://www.theinquirer.net/?article=14578 last year. (When I reread it, indeed it do not mention failing things). -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 20:33:36 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30CB116A41C; Tue, 24 May 2005 20:33:35 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 136E943D49; Tue, 24 May 2005 20:33:30 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j4OKZmEW049569; Tue, 24 May 2005 16:35:49 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: FreeBSD-gnats-submit@freebsd.org Date: Tue, 24 May 2005 16:33:25 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200505241633.25228.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.83/889/Sun May 22 06:18:49 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org Subject: [PATCH] SMBIOS scan for loader 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, 24 May 2005 20:33:36 -0000 >Submitter-Id: current-users >Originator: Jung-uk Kim >Organization: NIKSUN, Inc. >Confidential: no >Synopsis: [PATCH] SMBIOS scan for loader >Severity: non-critical >Priority: low >Category: kern >Class: change-request >Release: FreeBSD 6.0-CURRENT amd64 >Environment: System: FreeBSD xxx.xxx.xxx.xxx 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Tue May 24 15:00:27 EDT 2005 jkim@xxx.xxx.xxx.xxx:/usr/src/sys/amd64/compile/BEASTIE amd64 >Description: This patch scans static SMBIOS structures and exports the following environment variables to loader: hint.smbios.0.enabled "YES" when SMBIOS is detected hint.smbios.0.bios.vendor BIOS vendor hint.smbios.0.bios.version BIOS version hint.smbios.0.bios.reldate BIOS release date hint.smbios.0.system.maker System manufacturer hint.smbios.0.system.product System product name hint.smbios.0.system.version System version number hint.smbios.0.planar.maker Base board manufacturer hint.smbios.0.planar.product Base board product name hint.smbios.0.planar.version Base board version number hint.smbios.0.chassis.maker Enclosure manufacturer hint.smbios.0.chassis.version Enclosure version These strings can be used to detect hardware quirks and to set appropriate flags. For example, Compaq R3000 series and some HP laptops require hint.atkbd.0.flags="0x9" to boot. See amd64/67745 for more detail. detail. >How-To-Repeat: >Fix: Modified files: sys/boot/i386/libi386 Makefile sys/boot/i386/libi386 libi386.h sys/boot/i386/loader main.c Added file: sys/boot/i386/libi386 smbios.c Index: sys/boot/i386/libi386/Makefile =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/libi386/Makefile,v retrieving revision 1.37 diff -u -r1.37 Makefile --- sys/boot/i386/libi386/Makefile 24 Oct 2004 15:32:49 -0000 1.37 +++ sys/boot/i386/libi386/Makefile 23 May 2005 15:39:03 -0000 @@ -8,7 +8,7 @@ comconsole.c devicename.c elf32_freebsd.c \ elf64_freebsd.c gatea20.c \ i386_copy.c i386_module.c nullconsole.c pxe.c pxetramp.s \ - time.c vidconsole.c amd64_tramp.S + smbios.c time.c vidconsole.c amd64_tramp.S BOOT_COMCONSOLE_PORT?= 0x3f8 CFLAGS+= -DCOMPORT=${BOOT_COMCONSOLE_PORT} Index: sys/boot/i386/libi386/libi386.h =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/libi386/libi386.h,v retrieving revision 1.19 diff -u -r1.19 libi386.h --- sys/boot/i386/libi386/libi386.h 22 Oct 2004 14:56:23 -0000 1.19 +++ sys/boot/i386/libi386/libi386.h 23 May 2005 15:39:03 -0000 @@ -99,6 +99,8 @@ void biosacpi_detect(); +void smbios_detect(); + void gateA20(void); int i386_autoload(void); --- sys/boot/i386/libi386/smbios.c Mon May 23 11:38:29 2005 +++ sys/boot/i386/libi386/smbios.c Fri May 20 21:50:45 2005 @@ -0,0 +1,176 @@ +/*- + * Copyright (c) 2005 Jung-uk Kim + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include + +#include "btxv86.h" + +/* + * Detect SMBIOS and export information about the SMBIOS into the + * environment. + * + * System Management BIOS Reference Specification, v2.4 Final + * http://www.dmtf.org/standards/published_documents/DSP0134.pdf + */ + +/* + * Spec. 2.1.1 SMBIOS Structure Table Entry Point + * + * 'The SMBIOS Entry Point structure, described below, can be located by + * application software by searching for the anchor-string on paragraph + * (16-byte) boundaries within the physical memory address range + * 000F0000h to 000FFFFFh.' + */ +#define SMBIOS_START 0xf0000 +#define SMBIOS_LENGTH 0x10000 +#define SMBIOS_STEP 0x10 +#define SMBIOS_SIG "_SM_" +#define SMBIOS_DMI_SIG "_DMI_" + +static u_int8_t *smbios_parse_table(const u_int8_t *dmi); +static void smbios_setenv(const char *env, const u_int8_t *dmi, + const int offset); +static u_int8_t smbios_checksum(const u_int8_t *addr, const u_int8_t len); +static u_int8_t *smbios_sigsearch(const caddr_t addr, const u_int32_t len); + +void +smbios_detect(void) +{ + u_int8_t *smbios, *dmi, *addr; + u_int16_t i, length, count; + u_int32_t paddr; + + /* locate and validate the SMBIOS */ + smbios = smbios_sigsearch(PTOV(SMBIOS_START), SMBIOS_LENGTH); + if (smbios == 0) + return; + + /* export values from the SMBIOS */ + setenv("hint.smbios.0.enabled", "YES", 1); + + length = *(u_int16_t *)(smbios + 0x16); /* Structure Table Length */ + paddr = *(u_int32_t *)(smbios + 0x18); /* Structure Table Address */ + count = *(u_int16_t *)(smbios + 0x1c); /* No of SMBIOS Structures */ + + for (dmi = addr = PTOV(paddr), i = 0; + dmi - addr < length && i < count; i++) + dmi = smbios_parse_table(dmi); +} + +static u_int8_t * +smbios_parse_table(const u_int8_t *dmi) +{ + u_int8_t *dp; + + switch(dmi[0]) { + case 0: /* Type 0: BIOS */ + smbios_setenv("hint.smbios.0.bios.vendor", dmi, 0x04); + smbios_setenv("hint.smbios.0.bios.version", dmi, 0x05); + smbios_setenv("hint.smbios.0.bios.reldate", dmi, 0x08); + break; + + case 1: /* Type 1: System */ + smbios_setenv("hint.smbios.0.system.maker", dmi, 0x04); + smbios_setenv("hint.smbios.0.system.product", dmi, 0x05); + smbios_setenv("hint.smbios.0.system.version", dmi, 0x06); + break; + + case 2: /* Type 2: Base Board (or Module) */ + smbios_setenv("hint.smbios.0.planar.maker", dmi, 0x04); + smbios_setenv("hint.smbios.0.planar.product", dmi, 0x05); + smbios_setenv("hint.smbios.0.planar.version", dmi, 0x06); + break; + + case 3: /* Type 3: System Enclosure or Chassis */ + smbios_setenv("hint.smbios.0.chassis.maker", dmi, 0x04); + smbios_setenv("hint.smbios.0.chassis.version", dmi, 0x06); + break; + + default: /* skip other types */ + break; + } + + /* find structure terminator */ + dp = (u_int8_t *)(dmi + dmi[1]); + while (dp[0] != 0 || dp[1] != 0) + dp++; + + return(dp + 2); +} + +static void +smbios_setenv(const char *str, const u_int8_t *dmi, const int offset) +{ + char *cp; + int i; + + /* skip undefined string */ + if (dmi[offset] == 0) + return; + + for (cp = (char *)(dmi + dmi[1]), i = 0; i < dmi[offset] - 1; i++) + cp += strlen(cp) + 1; + setenv(str, cp, 1); +} + +static u_int8_t +smbios_checksum(const u_int8_t *addr, const u_int8_t len) +{ + u_int8_t sum; + int i; + + for (sum = 0, i = 0; i < len; i++) + sum += addr[i]; + + return(sum); +} + +static u_int8_t * +smbios_sigsearch(const caddr_t addr, const u_int32_t len) +{ + caddr_t cp; + + /* search on 16-byte boundaries */ + for (cp = addr; cp - addr < len; cp += SMBIOS_STEP) { + /* compare signature, validate checksum */ + if (!strncmp(cp, SMBIOS_SIG, 4)) { + if (smbios_checksum(cp, *(cp + 0x05))) + continue; + if (strncmp(cp + 0x10, SMBIOS_DMI_SIG, 5)) + continue; + if (smbios_checksum(cp + 0x10, 0x0f)) + continue; + + return(cp); + } + } + + return(0); +} Index: sys/boot/i386/loader/main.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/loader/main.c,v retrieving revision 1.30 diff -u -r1.30 main.c --- sys/boot/i386/loader/main.c 22 Oct 2004 14:57:28 -0000 1.30 +++ sys/boot/i386/loader/main.c 23 May 2005 15:39:04 -0000 @@ -140,6 +140,9 @@ /* detect ACPI for future reference */ biosacpi_detect(); + /* detect SMBIOS for future reference */ + smbios_detect(); + printf("\n"); printf("%s, Revision %s\n", bootprog_name, bootprog_rev); printf("(%s, %s)\n", bootprog_maker, bootprog_date); From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 23:18:21 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 676F916A41C; Tue, 24 May 2005 23:18:21 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFC5343D1F; Tue, 24 May 2005 23:18:20 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id B877B4AD07; Wed, 25 May 2005 01:18:18 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00753-03-2; Wed, 25 May 2005 01:18:18 +0200 (CEST) Received: from [192.168.1.187] (rambutan.pingpong.net [192.168.1.187]) by melon.pingpong.net (Postfix) with ESMTP id 611AC4ACFE; Wed, 25 May 2005 01:18:18 +0200 (CEST) Date: Wed, 25 May 2005 01:18:18 +0200 From: Palle Girgensohn To: Jung-uk Kim , freebsd-amd64@freebsd.org Message-ID: <84E3A284FDA86CFEB0595B02@rambutan.pingpong.net> In-Reply-To: <200505191335.32434.jkim@niksun.com> References: <200505191642.j4JGghLq096694@www.freebsd.org> <200505191335.32434.jkim@niksun.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at pingpong.net Cc: Tony Sweeney , freebsd-gnats-submit@freebsd.org Subject: Re: amd64/81272: JDK 1.5 port doesn't build. 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, 24 May 2005 23:18:21 -0000 Also make sure you run only a single CPU when building (i.e. turn off SMP in kernel config if you have it), and use a system that is as quiet as possible. /Palle --On torsdag, maj 19, 2005 13.35.32 -0400 Jung-uk Kim wrote: > This issue has been known for a while. Workaround is here: > > http://docs.freebsd.org/cgi/mid.cgi?422A3051.40703 > > Jung-uk Kim > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Tue May 24 23:20:05 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4283416A41C for ; Tue, 24 May 2005 23:20:05 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D2AA43D48 for ; Tue, 24 May 2005 23:20:05 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4ONK4bp036994 for ; Tue, 24 May 2005 23:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4ONK4qn036993; Tue, 24 May 2005 23:20:04 GMT (envelope-from gnats) Date: Tue, 24 May 2005 23:20:04 GMT Message-Id: <200505242320.j4ONK4qn036993@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Palle Girgensohn Cc: Subject: Re: amd64/81272: JDK 1.5 port doesn't build. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Palle Girgensohn List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 23:20:05 -0000 The following reply was made to PR amd64/81272; it has been noted by GNATS. From: Palle Girgensohn To: Jung-uk Kim , freebsd-amd64@freebsd.org Cc: Tony Sweeney , freebsd-gnats-submit@freebsd.org Subject: Re: amd64/81272: JDK 1.5 port doesn't build. Date: Wed, 25 May 2005 01:18:18 +0200 Also make sure you run only a single CPU when building (i.e. turn off SMP in kernel config if you have it), and use a system that is as quiet as possible. /Palle --On torsdag, maj 19, 2005 13.35.32 -0400 Jung-uk Kim wrote: > This issue has been known for a while. Workaround is here: > > http://docs.freebsd.org/cgi/mid.cgi?422A3051.40703 > > Jung-uk Kim > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 00:25:42 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C829D16A41C for ; Wed, 25 May 2005 00:25:42 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6054A43D49 for ; Wed, 25 May 2005 00:25:42 +0000 (GMT) (envelope-from girgen@FreeBSD.org) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 9658A4ACB9; Wed, 25 May 2005 02:25:41 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 98727-01-8; Wed, 25 May 2005 02:25:41 +0200 (CEST) Received: from [192.168.1.187] (rambutan.pingpong.net [192.168.1.187]) by melon.pingpong.net (Postfix) with ESMTP id 4FB964ACB5; Wed, 25 May 2005 02:25:41 +0200 (CEST) Date: Wed, 25 May 2005 02:25:38 +0200 From: Palle Girgensohn To: kwsn@earthlink.net, freebsd-amd64@freebsd.org Message-ID: <24CD85AD72E7F49E3A9AC091@rambutan.pingpong.net> In-Reply-To: <1115965490.59966.18.camel@jonnyv.kwsn.lan> References: <1115839640.59966.12.camel@jonnyv.kwsn.lan> <1115965490.59966.18.camel@jonnyv.kwsn.lan> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at pingpong.net Cc: toby.murray@gmail.com Subject: Re: Panic while running jdk15 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: Wed, 25 May 2005 00:25:43 -0000 --On torsdag, maj 12, 2005 23.24.50 -0700 Jon Kuster wrote: > On Wed, 2005-05-11 at 12:27 -0700, Jon Kuster wrote: >> After we managed to get jdk15 built and then shipped our box to the >> colo, it has started panicing. We haven't been able to reliably >> reproduce this yet, but it always happens when our java program is doing >> it's thing. >> >> kernel trap 12 with interrupts disabled >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id=00 >> fault virtual address = 0x1c0 >> fault code = supervisor write, page not present >> instruction pointer = 0x8 :0xffffffff80382348 >> stack pointer = 0x10 :0xffffffff7935aa0 >> frame pointer = 0x10 :0xffffffff7935ae0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 6503 (sh) >> >> I haven't been able to get a dump yet, or even a trace in ddb - our >> remote management card apparently emulates a usb keyboard which doesn't >> seem to work when the box is paniced. >> >> nm -n /boot/kernel/kernel |grep ffffffff803823 >> ffffffff80382330 T cpu_throw >> ffffffff80382380 T cpu_switch > > We've switched off Hyperthreading (we're running em64T xeons), and that > seems to have worked around the problem. It's a little too early to say > for sure, but we were seeing panics twice a day, and we haven't had a > panic in about a day and a half. Hi! This looks very similar to our problem. Dell 2850 (i.e. em64T xeon, two CPUs). Turning off HTT made it live longer (long enough for med to believe it actually solved the problem), but after a week or so it crashed twice a day again. We're *not* running java, though. Apache 1.3, php4, postgres8.0.3, amavis (i.e. perl), postfix. apache, postgres and php are very loaded, the machine has a load >= .8 most of the time (mostly due to sloppy code, but anyway). 5.4-release made it better, for a few days, but then it started crashing again. Today, I've built a non-SMP kernel, so we're effectively running a single CPU. It has not crashed so far (but it is slow). Always Fatal trap 12: page fault while in kernel mode It also hangs and does not reboot by itself. it seems so hard it never manages to save a core dump, and has to be restarted by hitting the big button. Contacted Dell support, as I'm beginning to suspect the hardware. After BIOS upgrade today, recommended by Dell, The machine hung at userland startup, when starting the various daemons. Five times in a row, at least. Then it decided to actually come up, and stayed up for eight hours. then down again. sic... If it works fine with one CPU, is it likely to be hardware problem or software? Jon, you report is a few weeks old, what happened? Does it live happily w/o HTT? /Palle From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 01:32:13 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B383816A41C; Wed, 25 May 2005 01:32:13 +0000 (GMT) (envelope-from kwsn@earthlink.net) Received: from pop-sarus.atl.sa.earthlink.net (pop-sarus.atl.sa.earthlink.net [207.69.195.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CCD443D49; Wed, 25 May 2005 01:32:13 +0000 (GMT) (envelope-from kwsn@earthlink.net) Received: from dialup-4.240.105.121.dial1.phoenix1.level3.net ([4.240.105.121] helo=jonnyv.kwsn.lan) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1Dakkl-0001Ej-00; Tue, 24 May 2005 21:32:12 -0400 From: Jon Kuster To: Palle Girgensohn In-Reply-To: <24CD85AD72E7F49E3A9AC091@rambutan.pingpong.net> References: <1115839640.59966.12.camel@jonnyv.kwsn.lan> <1115965490.59966.18.camel@jonnyv.kwsn.lan> <24CD85AD72E7F49E3A9AC091@rambutan.pingpong.net> Content-Type: text/plain Date: Tue, 24 May 2005 18:32:09 -0700 Message-Id: <1116984729.4388.14.camel@jonnyv.kwsn.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: toby.murray@gmail.com, freebsd-amd64@freebsd.org Subject: Re: Panic while running jdk15 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kwsn@earthlink.net List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 01:32:14 -0000 On Wed, 2005-05-25 at 02:25 +0200, Palle Girgensohn wrote: > --On torsdag, maj 12, 2005 23.24.50 -0700 Jon Kuster > wrote: > > > On Wed, 2005-05-11 at 12:27 -0700, Jon Kuster wrote: > >> After we managed to get jdk15 built and then shipped our box to the > >> colo, it has started panicing. We haven't been able to reliably > >> reproduce this yet, but it always happens when our java program is doing > >> it's thing. > >> > >> kernel trap 12 with interrupts disabled > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 0; apic id=00 > >> fault virtual address = 0x1c0 > >> fault code = supervisor write, page not present > >> instruction pointer = 0x8 :0xffffffff80382348 > >> stack pointer = 0x10 :0xffffffff7935aa0 > >> frame pointer = 0x10 :0xffffffff7935ae0 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags = resume, IOPL = 0 > >> current process = 6503 (sh) > >> > >> I haven't been able to get a dump yet, or even a trace in ddb - our > >> remote management card apparently emulates a usb keyboard which doesn't > >> seem to work when the box is paniced. > >> > >> nm -n /boot/kernel/kernel |grep ffffffff803823 > >> ffffffff80382330 T cpu_throw > >> ffffffff80382380 T cpu_switch > > > > We've switched off Hyperthreading (we're running em64T xeons), and that > > seems to have worked around the problem. It's a little too early to say > > for sure, but we were seeing panics twice a day, and we haven't had a > > panic in about a day and a half. > > Hi! > > This looks very similar to our problem. Dell 2850 (i.e. em64T xeon, two > CPUs). Turning off HTT made it live longer (long enough for med to believe > it actually solved the problem), but after a week or so it crashed twice a > day again. We're *not* running java, though. Apache 1.3, php4, > postgres8.0.3, amavis (i.e. perl), postfix. apache, postgres and php are > very loaded, the machine has a load >= .8 most of the time (mostly due to > sloppy code, but anyway). > > 5.4-release made it better, for a few days, but then it started crashing > again. Today, I've built a non-SMP kernel, so we're effectively running a > single CPU. It has not crashed so far (but it is slow). > > Always Fatal trap 12: page fault while in kernel mode > > It also hangs and does not reboot by itself. it seems so hard it never > manages to save a core dump, and has to be restarted by hitting the big > button. > > Contacted Dell support, as I'm beginning to suspect the hardware. After > BIOS upgrade today, recommended by Dell, The machine hung at userland > startup, when starting the various daemons. Five times in a row, at least. > Then it decided to actually come up, and stayed up for eight hours. then > down again. sic... > > If it works fine with one CPU, is it likely to be hardware problem or > software? > > Jon, you report is a few weeks old, what happened? Does it live happily w/o > HTT? We're running a Dell PE1850, which I think is exactly the same as a 2850, except in a smaller case. It's been up ever since we turned off HTT. It hasn't been in full production due to some network issues so it's idle most of the time (and probably will be even when it is in production), but it's survived running our java program repeatedly while a -j8 buildworld was going on. It also survived an incident where we ran it out of swap. I don't want to say turning off HTT solved the problem, but it has eliminated the panics for us. -Jon From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 09:47:45 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FD3016A41C for ; Wed, 25 May 2005 09:47:45 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2934F43D1F for ; Wed, 25 May 2005 09:47:45 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so136436nzp for ; Wed, 25 May 2005 02:47:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kvFgum1lvkNHBnm0weBKIgnczzuEVHNQJVbhhEaQA4EV0O/9ekwnO1HwxgOHWEdS6YOcFB19Acr2VGmiSUOuBzIMtIs0FDUjecp+oFRnKxtMsUXY1oIDpJ/0+DsZFi6oECXTGU5oxKBZo+ULdn73gmvK/d7LYFj/y/LurG4fYPY= Received: by 10.36.2.16 with SMTP id 16mr63049nzb; Wed, 25 May 2005 02:47:44 -0700 (PDT) Received: by 10.36.72.13 with HTTP; Wed, 25 May 2005 02:47:44 -0700 (PDT) Message-ID: <28edec3c0505250247428b6db2@mail.gmail.com> Date: Wed, 25 May 2005 17:47:44 +0800 From: "Mars G. Miro" To: freebsd-amd64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: bind 9.3.1 thread issues on FreeBSD 5.3R/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Mars G. Miro" List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 09:47:45 -0000 Yo list! I think I'm seeing a problem about bind9.3.1 on FreeBSD 5.3R/AMD64. This is addressed by setting WITHOUT_BIND9_THREADS=3Dtrue when compiling the port. This also doesn't happen on FreeBSD 5.4R/AMD64. The problem manifests when shutting down the named daemon where it just would not die gracefully (you have to kill -9 it). Here are the necessary steps to reproduce it: 1) install FreeBSD5.3R/AMD64 2) install bind9.3.1 from ports (set WITH_PORT_REPLACES_BASE_BIND9) 3) configure a simple resolver (# cd /var/named/etc/namedb && sh make-localhost) 4) start named server ( # /etc/rc.d/named start or # named -u bind -t /var/named ) 5) test some dns queries ( dig, nslookup etc) 6) kill named server ( # /etc/rc.d/named stop or # killall named ),=20 [ this is where it happens ... ] if logging is configured, you'd see something like: 5-May-2005 08:44:32.348 database: debug 1: done free_rbtdb(0.0.127.IN-ADDR.= ARPA) 25-May-2005 08:44:32.348 general: debug 3: zone_shutdown: zone authors.bind/CH: shutting down 25-May-2005 08:44:32.348 general: debug 3: zone_shutdown: zone version.bind/CH: shutting down 25-May-2005 08:44:32.349 client: debug 3: client @0x739400: shutdown 25-May-2005 08:44:32.349 client: debug 3: client @0x739400: free 25-May-2005 08:44:32.349 client: debug 3: client @0x739c00: shutdown 25-May-2005 08:44:32.349 client: debug 3: client @0x739c00: accept failed: operation canceled 25-May-2005 08:44:32.349 client: debug 3: client @0x739c00: free 25-May-2005 08:44:32.349 general: debug 3: clientmgr @0x6feb80: clientmgr_destroy 25-May-2005 08:44:32.349 resolver: debug 3: res 0x73ae00: detach 25-May-2005 08:44:32.349 resolver: debug 3: res 0x73ae00: destroy 25-May-2005 08:44:32.349 general: debug 3: dns_requestmgr_detach: 0x7e1000: eref 0 iref 0 25-May-2005 08:44:32.349 general: debug 3: mgr_destroy 25-May-2005 08:44:32.349 database: debug 1: calling free_rbtdb(.) 25-May-2005 08:44:32.349 database: debug 1: done free_rbtdb(.) 25-May-2005 08:44:32.349 database: debug 1: calling free_rbtdb(.) 25-May-2005 08:44:32.349 database: debug 1: done free_rbtdb(.) 25-May-2005 08:44:32.351 resolver: debug 3: res 0x7e1500: detach 25-May-2005 08:44:32.351 resolver: debug 3: res 0x7e1500: destroy 25-May-2005 08:44:32.351 general: debug 3: dns_requestmgr_detach: 0x7f4700: eref 0 iref 0 25-May-2005 08:44:32.351 general: debug 3: mgr_destroy 25-May-2005 08:44:32.351 database: debug 1: calling free_rbtdb(.) 25-May-2005 08:44:32.351 database: debug 1: done free_rbtdb(.) but then the process is still there: root 31645 0.0 0.1 3580 844 ?? SsJ 4:45AM 0:00.02 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -ss bind 39312 0.0 0.5 9752 5432 ?? IsJ 8:44AM 0:00.02 /usr/sbin/named -u bind -t /var/named The only way to kill it is kill -9 the pid. Somebody also had some similar issues like this (slapd): http://www.monkey.org/freebsd/archive/freebsd-amd64/200404/msg00076.html w/c is FreeBSD 5.2.X on AMD64. And, as I've said, this doesn't manifest on FreeBSD5.4R/AMD64 nor 5.3/5.4 i386 and the work-around is to compile the port WITHOUT_BIND9_THREADS=3Dtrue, So is anyone else also experiencing this problem? Thanks. cheers mars From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 10:29:51 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72B8716A41C for ; Wed, 25 May 2005 10:29:51 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from amd64.molecon.ru (amd64.molecon.ru [213.219.245.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E55F43D4C for ; Wed, 25 May 2005 10:29:50 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from [194.154.84.47] (helo=[10.20.5.22]) by amd64.molecon.ru with esmtp (Exim 4.51 (FreeBSD)) id 1DadmF-0000OZ-Do for freebsd-amd64@freebsd.org; Tue, 24 May 2005 22:05:15 +0400 Date: Tue, 24 May 2005 22:05:08 +0400 From: Oleg Rusanov X-Mailer: The Bat! (v3.0) Professional Organization: Molecon X-Priority: 3 (Normal) Message-ID: <1567974056.20050524220508@molecon.ru> To: freebsd-amd64 MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit X-PopBeforeSMTPSenders: info@molecon.ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - amd64.molecon.ru X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - molecon.ru X-Source: X-Source-Args: X-Source-Dir: Subject: DMA X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Rusanov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 10:29:51 -0000 Çäðàâñòâóéòå, freebsd-amd64. Anybody can help me to solve this erors please: o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see ???? -- Ñ óâàæåíèåì, Oleg mailto:freebsd-amd64@molecon.ru From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 13:37:15 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DBFA16A41C for ; Wed, 25 May 2005 13:37:15 +0000 (GMT) (envelope-from Laurent.Protois@ensea.fr) Received: from picsou.ensea.fr (picsou.ensea.fr [193.51.45.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB19843D54 for ; Wed, 25 May 2005 13:37:13 +0000 (GMT) (envelope-from Laurent.Protois@ensea.fr) Received: from attila.ensea.fr (attila.ensea.fr [193.51.47.175]) by picsou.ensea.fr (8.12.11/8.12.11j) with ESMTP id j4PDb0X5003136 for ; Wed, 25 May 2005 15:37:01 +0200 (CEST) From: Laurent Protois To: freebsd-amd64@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15 Organization: Ensea Date: Wed, 25 May 2005 15:39:23 +0200 Message-Id: <1117028363.20922.5.camel@attila.ensea.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4-3mdk Content-Transfer-Encoding: 8bit X-Miltered: at picsou with ID 42947F7C.000 by Joe's j-chkmail (V-1.7.1 - http://j-chkmail.ensmp.fr)! X-MailScanner-Information: Contacter le CRI pour plus d'informations X-MailScanner@picsou.ensea.fr: Ce message parait sain Cc: Subject: FreeBSD 5.4 AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Laurent.Protois@ensea.fr List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 13:37:15 -0000 Hi, I try to install a freebsd(amd64) 5.4 on a shuttle with a sn85g4 motherboard (socket 754) (FN85 : Nvidia nforce 3 150 shipset) and my sata disk is not recognized ;-( Does anybody have an idea to do it ? thanks -- ___________________________________________________________________ Laurent Protois (Ingénieur Systemes & Reseaux) Centre de Ressources Informatiques (CRI) de l'ENSEA Ecole Nationale Supérieure de l'Electronique et de ses Applications 6, avenue du Ponceau - 95014 Cergy Pontoise Cedex tel: 01 30 73 66 26 fax: 01 30 73 66 67 email: protois@ensea.fr web: http://www.ensea.fr ___________________________________________________________________ From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 13:44:12 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFBAA16A41C for ; Wed, 25 May 2005 13:44:12 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.FreeBSD.org (Postfix) with SMTP id 350AE43D49 for ; Wed, 25 May 2005 13:44:11 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 25 May 2005 13:44:11 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Wed, 25 May 2005 09:44:12 -0400 (EDT) Message-ID: <3545.172.16.0.199.1117028652.squirrel@172.16.0.1> In-Reply-To: <20050524153250.GC31564@dragon.NUXI.org> References: <4905.127.0.0.1.1116698556.squirrel@www.epicoftimewasted.com> <20050524153250.GC31564@dragon.NUXI.org> Date: Wed, 25 May 2005 09:44:12 -0400 (EDT) From: "Mike Jakubik" To: freebsd-amd64@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-amd64@freebsd.org Subject: Re: 5.4-RELEASE Athlon64 E3/E4 core support 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: Wed, 25 May 2005 13:44:12 -0000 On Tue, May 24, 2005 11:32 am, David O'Brien said: > On Sat, May 21, 2005 at 02:02:36PM -0400, Ryan R. wrote: > >> So, I once again wipe the drive, but this time I install >> 5.4-RELEASE/i386. >> It installs fine, and boots fine. One thing I notice during boot, is >> that SSE3 isn't detected by the kernel as a CPU feature anymore (amd64 >> build did detect it). > > This has been corrected in 6-CURRENT. A little off the topic, but what about new arch flags for make.conf? This CPU, as well as the new Venice core Athlons supports SSE3. I'm not even sure if this is useful or if our GCC supports it, just thought id mention it. From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 13:44:12 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D503716A41F for ; Wed, 25 May 2005 13:44:12 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.FreeBSD.org (Postfix) with SMTP id 3526543D4C for ; Wed, 25 May 2005 13:44:11 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 25 May 2005 13:44:11 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Wed, 25 May 2005 09:44:12 -0400 (EDT) Message-ID: <3545.172.16.0.199.1117028652.squirrel@172.16.0.1> In-Reply-To: <20050524153250.GC31564@dragon.NUXI.org> References: <4905.127.0.0.1.1116698556.squirrel@www.epicoftimewasted.com> <20050524153250.GC31564@dragon.NUXI.org> Date: Wed, 25 May 2005 09:44:12 -0400 (EDT) From: "Mike Jakubik" To: freebsd-amd64@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-amd64@freebsd.org Subject: Re: 5.4-RELEASE Athlon64 E3/E4 core support 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: Wed, 25 May 2005 13:44:13 -0000 On Tue, May 24, 2005 11:32 am, David O'Brien said: > On Sat, May 21, 2005 at 02:02:36PM -0400, Ryan R. wrote: > >> So, I once again wipe the drive, but this time I install >> 5.4-RELEASE/i386. >> It installs fine, and boots fine. One thing I notice during boot, is >> that SSE3 isn't detected by the kernel as a CPU feature anymore (amd64 >> build did detect it). > > This has been corrected in 6-CURRENT. A little off the topic, but what about new arch flags for make.conf? This CPU, as well as the new Venice core Athlons supports SSE3. I'm not even sure if this is useful or if our GCC supports it, just thought id mention it. From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 13:44:37 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E73F16A41C for ; Wed, 25 May 2005 13:44:37 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from amd64.molecon.ru (amd64.molecon.ru [213.219.245.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8A9343D1F for ; Wed, 25 May 2005 13:44:36 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from [194.154.84.54] (helo=[10.20.5.22]) by amd64.molecon.ru with esmtp (Exim 4.51 (FreeBSD)) id 1DawBV-0002UI-Tu for freebsd-amd64@freebsd.org; Wed, 25 May 2005 17:44:34 +0400 Date: Wed, 25 May 2005 17:44:21 +0400 From: Oleg Rusanov X-Mailer: The Bat! (v3.0) Professional Organization: Molecon X-Priority: 3 (Normal) Message-ID: <487002021.20050525174421@molecon.ru> To: freebsd-amd64 In-Reply-To: <1567974056.20050524220508@molecon.ru> References: <1567974056.20050524220508@molecon.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: domain_site_design_promotion_server_hosting_collocation_voip_admin_rusanov_oleg_4330049_msk@molecon.ru, freebsd-amd64@molecon.ru, freebsd-opennet@molecon.ru, info@molecon.ru, inform@molecon.ru, molecon, mysql@molecon.ru, oleg@molecon.ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - amd64.molecon.ru X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - molecon.ru X-Source: X-Source-Args: X-Source-Dir: Subject: DMA X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Rusanov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 13:44:37 -0000 Hi, freebsd-amd64. Anybody can help me to solve this erors please: o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see ???? -- Regards, Oleg mailto:freebsd-amd64@molecon.ru From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 14:12:47 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCD8E16A41C for ; Wed, 25 May 2005 14:12:47 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from amd64.molecon.ru (amd64.molecon.ru [213.219.245.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B24943D49 for ; Wed, 25 May 2005 14:12:46 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from [194.154.84.54] (helo=[10.20.5.22]) by amd64.molecon.ru with esmtp (Exim 4.51 (FreeBSD)) id 1Dawck-0002q7-Mh for freebsd-amd64@freebsd.org; Wed, 25 May 2005 18:12:43 +0400 Date: Wed, 25 May 2005 18:12:29 +0400 From: Oleg Rusanov X-Mailer: The Bat! (v3.0) Professional Organization: Molecon X-Priority: 3 (Normal) Message-ID: <1265275482.20050525181229@molecon.ru> To: freebsd-amd64 In-Reply-To: <1604723504.20050511162549@molecon.ru> References: <1604723504.20050511162549@molecon.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: domain_site_design_promotion_server_hosting_collocation_voip_admin_rusanov_oleg_4330049_msk@molecon.ru, freebsd-amd64@molecon.ru, freebsd-opennet@molecon.ru, info@molecon.ru, inform@molecon.ru, molecon, mysql@molecon.ru, oleg@molecon.ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - amd64.molecon.ru X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - molecon.ru X-Source: X-Source-Args: X-Source-Dir: Subject: FAILURE - READ_DMA timed out and FAILURE - WRITE_DMA timed out X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Rusanov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 14:12:47 -0000 HEllo, freebsd-amd64. Sory for my english. Copy 500 Mb from Maxtor 7Y250M0/YAR51HW0 to WDC WD740GD-00FLA0/21.08U21 server go DOWN after 50% done! WDC WD740GD-00FLA0/21.08U21 is system HDD and i whant to use second HDD for backups. May 11 16:11:41 amd64 kernel: ad6: TIMEOUT - READ_DMA retrying (2 retries left) LBA=135076159 May 11 16:11:42 amd64 kernel: ad6: WARNING - removed from configuration May 11 16:11:42 amd64 kernel: ata3-master: FAILURE - READ_DMA timed out Or i have this errors and server also go down: Apr 11 14:53:18 amd64 kernel: ad6: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=38914943 Apr 11 14:53:19 amd64 kernel: ad6: WARNING - removed from configuration Apr 11 14:53:19 amd64 kernel: ata3-master: FAILURE - WRITE_DMA timed out I tryed to disable DMA and ICPI in /boot/defaults/loader.conf: amd64# cat /boot/defaults/loader.conf hw.ata.ata_dma="0" hw.ata.atapi_dma="0" hint.acpi.0.disabled="1" and this NO helped to me. -------------------------My configuation:---------------------------------- Tyan2882g3nr, Opteron 244, 2gb memory May 11 16:14:11 amd64 kernel: ad4: 70911MB [144073/16/63] at ata2-master SATA150 May 11 16:14:11 amd64 kernel: ad6: 239372MB [486344/16/63] at ata3-master SATA150 amd64# uname -a FreeBSD amd64.molecon.ru 5.4-STABLE FreeBSD 5.4-STABLE #0: Wed May 11 11:41:55 MSD 2005 amd64# atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 Serial ATA v1.0 Slave: no device present ATA channel 3: Master: ad6 Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present amd64# amd64# sysctl hw.ata hw.ata.atapi_dma: 0 hw.ata.wc: 1 hw.ata.ata_dma: 1 amd64# amd64# sysctl -a | grep -i dma ATA DMA 6 2K 2K 6 256 hw.ata.atapi_dma: 0 hw.ata.ata_dma: 1 hw.busdma.total_bpages: 32 hw.busdma.zone0.total_bpages: 32 hw.busdma.zone0.free_bpages: 32 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 2 hw.busdma.zone0.boundary: 65536 dev.atapci.1.%desc: AMD 8111 UDMA133 controller dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.SBRG.DMAD dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 amd64# cat /var/log/messages May 11 16:11:41 amd64 kernel: ad6: TIMEOUT - READ_DMA retrying (2 retries left) LBA=135076159 May 11 16:11:42 amd64 kernel: ad6: WARNING - removed from configuration May 11 16:11:42 amd64 kernel: ata3-master: FAILURE - READ_DMA timed out May 11 16:14:11 amd64 syslogd: kernel boot file is /boot/kernel/kernel May 11 16:14:11 amd64 kernel: Copyright (c) 1992-2005 The FreeBSD Project. May 11 16:14:11 amd64 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 May 11 16:14:11 amd64 kernel: The Regents of the University of California. All rights reserved. May 11 16:14:11 amd64 kernel: FreeBSD 5.4-STABLE #0: Wed May 11 11:41:55 MSD 2005 May 11 16:14:11 amd64 kernel: lavandas@amd64.molecon.ru:/usr/obj/usr/src/sys/L64 May 11 16:14:11 amd64 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 May 11 16:14:11 amd64 kernel: CPU: AMD Opteron(tm) Processor 244 (1792.23-MHz K8-class CPU) May 11 16:14:11 amd64 kernel: Origin = "AuthenticAMD" Id = 0xf58 Stepping = 8 May 11 16:14:11 amd64 kernel: Features=0x78bfbff May 11 16:14:11 amd64 kernel: AMD Features=0xe0500800 May 11 16:14:11 amd64 kernel: real memory = 1073676288 (1023 MB) May 11 16:14:11 amd64 kernel: avail memory = 1028308992 (980 MB) May 11 16:14:11 amd64 kernel: ACPI APIC Table: May 11 16:14:11 amd64 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs May 11 16:14:11 amd64 kernel: cpu0 (BSP): APIC ID: 0 May 11 16:14:11 amd64 kernel: cpu1 (AP): APIC ID: 1 May 11 16:14:11 amd64 kernel: MADT: Forcing active-low polarity and level trigger for SCI May 11 16:14:11 amd64 kernel: ioapic0 irqs 0-23 on motherboard May 11 16:14:11 amd64 kernel: ioapic1 irqs 24-27 on motherboard May 11 16:14:11 amd64 kernel: ioapic2 irqs 28-31 on motherboard May 11 16:14:11 amd64 kernel: acpi0: on motherboard May 11 16:14:11 amd64 kernel: acpi0: Power Button (fixed) May 11 16:14:11 amd64 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 May 11 16:14:11 amd64 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 May 11 16:14:11 amd64 kernel: cpu0: on acpi0 May 11 16:14:11 amd64 kernel: acpi_throttle0: on cpu0 May 11 16:14:11 amd64 kernel: cpu1: on acpi0 May 11 16:14:11 amd64 kernel: pcib0: port 0xcf8-0xcff on acpi0 May 11 16:14:11 amd64 kernel: pci0: on pcib0 May 11 16:14:11 amd64 kernel: pcib1: at device 6.0 on pci0 May 11 16:14:11 amd64 kernel: pci3: on pcib1 May 11 16:14:11 amd64 kernel: pci3: at device 0.0 (no driver attached) May 11 16:14:11 amd64 kernel: pci3: at device 0.1 (no driver attached) May 11 16:14:11 amd64 kernel: atapci0: port 0xa800-0xa80f,0xac00-0xac03,0xb000-0xb007,0xb400-0xb403,0xbc00-0xbc07 mem 0xfeafec00-0xfeafefff irq 19 at device 5.0 on pci3 May 11 16:14:11 amd64 kernel: ata2: channel #0 on atapci0 May 11 16:14:11 amd64 kernel: ata3: channel #1 on atapci0 May 11 16:14:11 amd64 kernel: ata4: channel #2 on atapci0 May 11 16:14:11 amd64 kernel: ata5: channel #3 on atapci0 May 11 16:14:11 amd64 kernel: pci3: at device 6.0 (no driver attached) May 11 16:14:11 amd64 kernel: pci3: at device 8.0 (no driver attached) May 11 16:14:11 amd64 kernel: isab0: at device 7.0 on pci0 May 11 16:14:11 amd64 kernel: isa0: on isab0 May 11 16:14:11 amd64 kernel: atapci1: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 May 11 16:14:11 amd64 kernel: ata0: channel #0 on atapci1 May 11 16:14:11 amd64 kernel: ata1: channel #1 on atapci1 May 11 16:14:11 amd64 kernel: pci0: at device 7.2 (no driver attached) May 11 16:14:11 amd64 kernel: pci0: at device 7.3 (no driver attached) May 11 16:14:11 amd64 kernel: pcib2: at device 10.0 on pci0 May 11 16:14:11 amd64 kernel: pci2: on pcib2 May 11 16:14:11 amd64 kernel: bge0: mem 0xfc8b0000-0xfc8bffff,0xfc8c0000-0xfc8cffff irq 24 at device 9.0 on pci2 May 11 16:14:11 amd64 kernel: miibus0: on bge0 May 11 16:14:11 amd64 kernel: brgphy0: on miibus0 May 11 16:14:11 amd64 kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto May 11 16:14:11 amd64 kernel: bge0: Ethernet address: 00:e0:81:29:28:60 May 11 16:14:11 amd64 kernel: bge1: mem 0xfc8e0000-0xfc8effff,0xfc8f0000-0xfc8fffff irq 25 at device 9.1 on pci2 May 11 16:14:11 amd64 kernel: miibus1: on bge1 May 11 16:14:11 amd64 kernel: brgphy1: on miibus1 May 11 16:14:11 amd64 kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto May 11 16:14:11 amd64 kernel: bge1: Ethernet address: 00:e0:81:29:28:61 May 11 16:14:11 amd64 kernel: pci0: at device 10.1 (no driver attached) May 11 16:14:11 amd64 kernel: pcib3: at device 11.0 on pci0 May 11 16:14:11 amd64 kernel: pci1: on pcib3 May 11 16:14:11 amd64 kernel: pci0: at device 11.1 (no driver attached) May 11 16:14:11 amd64 kernel: acpi_button0: on acpi0 May 11 16:14:11 amd64 kernel: orm0: at iomem 0xc8000-0xcc7ff,0xc0000-0xc7fff on isa0 May 11 16:14:11 amd64 kernel: atkbdc0: at port 0x64,0x60 on isa0 May 11 16:14:11 amd64 kernel: sc0: at flags 0x100 on isa0 May 11 16:14:11 amd64 kernel: sc0: VGA <16 virtual consoles, flags=0x300> May 11 16:14:11 amd64 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 May 11 16:14:11 amd64 kernel: Timecounters tick every 1.000 msec May 11 16:14:11 amd64 kernel: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging limited to 100 packets/entry by default May 11 16:14:11 amd64 kernel: ad4: 70911MB [144073/16/63] at ata2-master SATA150 May 11 16:14:11 amd64 kernel: ad6: 239372MB [486344/16/63] at ata3-master SATA150 May 11 16:14:11 amd64 kernel: SMP: AP CPU #1 Launched! May 11 16:14:11 amd64 kernel: Mounting root from ufs:/dev/ad4s1a May 11 16:14:11 amd64 kernel: WARNING: / was not properly dismounted May 11 16:14:11 amd64 kernel: WARNING: /tmp was not properly dismounted May 11 16:14:11 amd64 kernel: WARNING: /usr was not properly dismounted May 11 16:14:11 amd64 kernel: WARNING: /var was not properly dismounted amd64# -- Regards, Oleg mailto:freebsd-amd64@molecon.ru From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 14:19:03 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8375E16A41C for ; Wed, 25 May 2005 14:19:03 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2607843D54 for ; Wed, 25 May 2005 14:19:02 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4PEJ2vS054160; Wed, 25 May 2005 07:19:02 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4PEJ263054159; Wed, 25 May 2005 07:19:02 -0700 (PDT) (envelope-from obrien) Date: Wed, 25 May 2005 07:19:02 -0700 From: "David O'Brien" To: Mike Jakubik Message-ID: <20050525141902.GC35171@dragon.NUXI.org> References: <4905.127.0.0.1.1116698556.squirrel@www.epicoftimewasted.com> <20050524153250.GC31564@dragon.NUXI.org> <3545.172.16.0.199.1117028652.squirrel@172.16.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3545.172.16.0.199.1117028652.squirrel@172.16.0.1> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: 5.4-RELEASE Athlon64 E3/E4 core support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 14:19:03 -0000 On Wed, May 25, 2005 at 09:44:12AM -0400, Mike Jakubik wrote: > On Tue, May 24, 2005 11:32 am, David O'Brien said: > > On Sat, May 21, 2005 at 02:02:36PM -0400, Ryan R. wrote: > > > >> So, I once again wipe the drive, but this time I install > >> 5.4-RELEASE/i386. > >> It installs fine, and boots fine. One thing I notice during boot, is > >> that SSE3 isn't detected by the kernel as a CPU feature anymore (amd64 > >> build did detect it). > > > > This has been corrected in 6-CURRENT. > > A little off the topic, but what about new arch flags for make.conf? This > CPU, as well as the new Venice core Athlons supports SSE3. I'm not even > sure if this is useful or if our GCC supports it, just thought id mention > it. I'm most likely going to add an "opteron-e" CPUTYPE. I've been pushing for GCC to grow a "k8-e" support. But no traction yet. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 14:34:09 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5254916A41C for ; Wed, 25 May 2005 14:34:09 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA40E43D1D for ; Wed, 25 May 2005 14:34:08 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DawxS-0000rk-P4; Wed, 25 May 2005 17:34:06 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Laurent.Protois@ensea.fr In-Reply-To: Message from Laurent Protois of "Wed, 25 May 2005 15:39:23 +0200." <1117028363.20922.5.camel@attila.ensea.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2005 17:34:06 +0300 From: Danny Braniss Message-ID: Cc: freebsd-amd64@FreeBSD.org Subject: Re: FreeBSD 5.4 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: Wed, 25 May 2005 14:34:09 -0000 > Hi, > = > I try to install a freebsd(amd64) 5.4 on a shuttle > with a sn85g4 motherboard (socket 754) > (FN85 : Nvidia nforce 3 150 shipset) = > and my sata disk is not recognized ;-( > = > Does anybody have an idea to do it ? i have the same box/mb, are you sure the bios sees it ok? danny From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 15:16:59 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 849AB16A41F; Wed, 25 May 2005 15:16:59 +0000 (GMT) (envelope-from imura@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 469D943D4C; Wed, 25 May 2005 15:16:59 +0000 (GMT) (envelope-from imura@FreeBSD.org) Received: from freefall.freebsd.org (imura@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4PFGx4B005131; Wed, 25 May 2005 15:16:59 GMT (envelope-from imura@freefall.freebsd.org) Received: (from imura@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4PFGweM005127; Wed, 25 May 2005 15:16:58 GMT (envelope-from imura) Date: Wed, 25 May 2005 15:16:58 GMT From: "R. Imura" Message-Id: <200505251516.j4PFGweM005127@freefall.freebsd.org> To: liettneff@bk.ru, imura@FreeBSD.org, freebsd-amd64@FreeBSD.org, imura@FreeBSD.org Cc: Subject: Re: amd64/75488: ntfs_iconv not working on 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: Wed, 25 May 2005 15:16:59 -0000 Synopsis: ntfs_iconv not working on amd64 State-Changed-From-To: open->patched State-Changed-By: imura State-Changed-When: Wed May 25 15:00:26 GMT 2005 State-Changed-Why: This bug should have been fixed in -current: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/libkern/iconv_xlat16.c#rev1.3 I also prepared compiled kernel module for 5.4-RELEASE: http://people.freebsd.org/~imura/75488/ Thanks! Responsible-Changed-From-To: freebsd-amd64->imura Responsible-Changed-By: imura Responsible-Changed-When: Wed May 25 15:00:26 GMT 2005 Responsible-Changed-Why: I would like to pick this up. http://www.freebsd.org/cgi/query-pr.cgi?pr=75488 From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 15:27:55 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B20016A41C for ; Wed, 25 May 2005 15:27:55 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42F2343D4C for ; Wed, 25 May 2005 15:27:55 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4PFRsx2055700; Wed, 25 May 2005 08:27:54 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4PFRkEM055699; Wed, 25 May 2005 08:27:46 -0700 (PDT) (envelope-from obrien) Date: Wed, 25 May 2005 08:27:46 -0700 From: "David O'Brien" To: Martin Nilsson Message-ID: <20050525152745.GE35171@dragon.NUXI.org> References: <428C85A6.6010004@gneto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428C85A6.6010004@gneto.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: Opteron problens with 16GB memory X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 15:27:55 -0000 On Thu, May 19, 2005 at 02:25:10PM +0200, Martin Nilsson wrote: > Are there any known problems with Opterons and more than 12GB memory? > I'm running 5.4-STABLE on a Tyan K8WE, the box is stable with 12GB > but I get internal compiler errors when building world with 16GB. Do you have "hardware memory hole" or "software memory hole" support turned on in the BIOS? -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 15:58:36 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16BD916A41C for ; Wed, 25 May 2005 15:58:36 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id D55EB43D1F for ; Wed, 25 May 2005 15:58:35 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 549E7F1A9D; Wed, 25 May 2005 08:58:35 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35223-02; Wed, 25 May 2005 08:58:34 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 33FC6F199F; Wed, 25 May 2005 08:58:34 -0700 (PDT) From: Sean McNeil To: "Mars G. Miro" In-Reply-To: <28edec3c0505250247428b6db2@mail.gmail.com> References: <28edec3c0505250247428b6db2@mail.gmail.com> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Wed, 25 May 2005 08:58:33 -0700 Message-Id: <1117036713.35298.1.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Cc: freebsd-amd64@freebsd.org Subject: Re: bind 9.3.1 thread issues on FreeBSD 5.3R/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 15:58:36 -0000 On Wed, 2005-05-25 at 17:47 +0800, Mars G. Miro wrote: > Yo list! > > I think I'm seeing a problem about bind9.3.1 on FreeBSD 5.3R/AMD64. > This is addressed by setting WITHOUT_BIND9_THREADS=true when compiling > the port. This also doesn't happen on FreeBSD 5.4R/AMD64. > > The problem manifests when shutting down the named daemon where it > just would not die gracefully (you have to kill -9 it). > > Here are the necessary steps to reproduce it: > 1) install FreeBSD5.3R/AMD64 > 2) install bind9.3.1 from ports (set WITH_PORT_REPLACES_BASE_BIND9) > 3) configure a simple resolver (# cd /var/named/etc/namedb && sh > make-localhost) > 4) start named server ( # /etc/rc.d/named start or # named -u bind -t > /var/named ) > 5) test some dns queries ( dig, nslookup etc) > 6) kill named server ( # /etc/rc.d/named stop or # killall named ), > [ this is where it happens ... ] There is a problem with threads on exit that was fixed in 5.4. Update to -STABLE to get lots of stability issues as well as this problem resolved. Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 17:17:23 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88BAF16A41C for ; Wed, 25 May 2005 17:17:23 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B4C543D1F for ; Wed, 25 May 2005 17:17:23 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([66.130.198.54]) by VL-MO-MR007.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IH2006JI2OYBH@VL-MO-MR007.ip.videotron.ca> for freebsd-amd64@freebsd.org; Wed, 25 May 2005 13:17:22 -0400 (EDT) Date: Wed, 25 May 2005 13:17:15 -0400 From: Nicolas Blais To: freebsd-amd64@freebsd.org Message-id: <200505251317.22128.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=nextPart5841627.xz1AnS1pYk Content-transfer-encoding: 7bit User-Agent: KMail/1.8 Subject: amd64 optimized gcc? 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: Wed, 25 May 2005 17:17:23 -0000 --nextPart5841627.xz1AnS1pYk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I am developping a software that follows a random()-dependant algorithm whi= ch=20 is extremely cpu intensif.=20 I decided to run on different platforms to see how it performed based on cp= u=20 and os (in a way of benchmarking) and I'm surprised by the numbers: Reference times for benchmark (5e+07 run of the algorithm): (FreeBSD/i386) Venice (S939, 512K L2 cache) Athlon64 3000 overclocked @ 26= 55=20 Mhz : 78.3072 s (638511 r/s) Note: Cool 'n' Quiet! Disabled in BIOS. Note: 1 G RAM (FreeBSD/amd64) Venice (S939, 512K L2 cache) Athlon64 3000 overclocked @ 2= 655=20 Mhz : 71.2521 s (701732 r/s) Note: Cool 'n' Quiet! Disabled in BIOS. Note: 1 G RAM (Knoppix/i386) Clawhammer (S747, 1MB L2 cache) Athlon64 3200 @ 2000 Mhz := =20 133.858 s (373325 r/s) Note: Compaq R3240CA Laptop, Cool 'n' Quiet! forced by BIOS. Note: 512 M RAM (FreeBSD/amd64) Clawhammer (S747, 1MB L2 cache) Athlon64 3200 @ 2000 Mhz := =20 47.2754 s (1057630 r/s) Note: Compaq R3240CA Laptop, Cool 'n' Quiet! forced by BIOS. sysctl hw.acpi.cpu.px_control=3D-1 Note: 512 M RAM (FreeBSD/i386) Pentium II @ 233 Mhz : 538.136 s (92913.3 r/s) Note: 192 M RAM Not surprising is the Pentium II :). What is surprising is that amd64 Free= BSD=20 seems to execute code faster than i386 FreeBSD, so I'm wondering if gcc=20 (amd64) really optimizes code for the cpu. If it is, I would probably move = my=20 httpd server to amd64... Also, maybe less surprising is that Knoppix sucks running the algorithm for= =20 some reason and that L2 cache really is a big factor (my Laptop outperforms= =20 my heavily overclocked box). Any comments? =2D-=20 =46reeBSD 6.0-CURRENT #2: Sun May 22 11:29:47 EDT 2005 =20 nicblais@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://66.130.198.54:8081/security/nb_root.asc --nextPart5841627.xz1AnS1pYk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBClLMiz38ton5LGeIRAvw7AJ97aSVuTJn3Pxw7ahROhgy6Z98lCgCeNkLs VcmPoCAV3tXf3MLnQZp2ylY= =Pjk4 -----END PGP SIGNATURE----- --nextPart5841627.xz1AnS1pYk-- From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 17:46:43 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44B4416A41C; Wed, 25 May 2005 17:46:43 +0000 (GMT) (envelope-from martin@gneto.com) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4925443D49; Wed, 25 May 2005 17:46:41 +0000 (GMT) (envelope-from martin@gneto.com) Received: from as6-1-5.kr.m.bonet.se ([83.227.181.30] [83.227.181.30]) by mxfep01.bredband.com with ESMTP id <20050525174640.GILO26796.mxfep01.bredband.com@as6-1-5.kr.m.bonet.se>; Wed, 25 May 2005 19:46:40 +0200 Received: from [192.168.10.11] (euklides.gneto.com [192.168.10.11]) by as6-1-5.kr.m.bonet.se (Postfix) with ESMTP id D7A3E67843; Wed, 25 May 2005 19:46:39 +0200 (CEST) Message-ID: <4294B9FF.8010705@gneto.com> Date: Wed, 25 May 2005 19:46:39 +0200 From: Martin Nilsson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <428C85A6.6010004@gneto.com> <20050525152745.GE35171@dragon.NUXI.org> In-Reply-To: <20050525152745.GE35171@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Opteron problens with 16GB memory 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: Wed, 25 May 2005 17:46:43 -0000 David O'Brien wrote: > On Thu, May 19, 2005 at 02:25:10PM +0200, Martin Nilsson wrote: > >>Are there any known problems with Opterons and more than 12GB memory? >>I'm running 5.4-STABLE on a Tyan K8WE, the box is stable with 12GB >>but I get internal compiler errors when building world with 16GB. > > > Do you have "hardware memory hole" or "software memory hole" support > turned on in the BIOS? I don't remember which I had, the box is now at the customer running RedHat Enterprise Linux so I can't test it more with FreeBSD. Which setting for "hardware memory hole" is recommended? /Martin From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 17:51:08 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCF0416A41C for ; Wed, 25 May 2005 17:51:08 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from viefep12-int.chello.at (viefep12-int.chello.at [213.46.255.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7F6043D49 for ; Wed, 25 May 2005 17:51:07 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from [80.98.207.149] by viefep12-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050525175105.UYIM2846.viefep12-int.chello.at@[80.98.207.149]>; Wed, 25 May 2005 19:51:05 +0200 Message-ID: <4294BB08.3090703@t-hosting.hu> Date: Wed, 25 May 2005 19:51:04 +0200 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Blais References: <200505251317.22128.nb_root@videotron.ca> In-Reply-To: <200505251317.22128.nb_root@videotron.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 optimized gcc? 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: Wed, 25 May 2005 17:51:08 -0000 Hello, As for the optimization, I'm very interested how fast can be an actual optimized system. The stock release doesn't optimizes too much, afaik it uses -O. I have been experimenting for a while with building the whole system with my custom cflags, and yesterday I succeeded. I managed to build the whole system with CFLAGS=-s -Os -march=athlon64 COPTFLAGS=-s -Os -march=athlon64 I might have used -O2 instead of -Os but not -O3 which made a compilation error. The -s is for srtipping the binaries and libs, because this is intended to be used on a production system, where we use stable software releases, thus we don't need debug symbols And I ripped out the softwares I don't need with macros. (named, sendmail, games, ...) Unfortunately I don't have a machine for testing purposes but I would ty it. If I provide You such a disc would You try it in the same way? I'm not sure it is a working a disc, but it should be. I haven't read that anybody made such discs. Cheers, Gábor Kövesdán Nicolas Blais wrote: >I am developping a software that follows a random()-dependant algorithm which >is extremely cpu intensif. >I decided to run on different platforms to see how it performed based on cpu >and os (in a way of benchmarking) and I'm surprised by the numbers: > >Reference times for benchmark (5e+07 run of the algorithm): > >(FreeBSD/i386) Venice (S939, 512K L2 cache) Athlon64 3000 overclocked @ 2655 >Mhz : 78.3072 s (638511 r/s) > Note: Cool 'n' Quiet! Disabled in BIOS. > Note: 1 G RAM > >(FreeBSD/amd64) Venice (S939, 512K L2 cache) Athlon64 3000 overclocked @ 2655 >Mhz : 71.2521 s (701732 r/s) > Note: Cool 'n' Quiet! Disabled in BIOS. > Note: 1 G RAM > >(Knoppix/i386) Clawhammer (S747, 1MB L2 cache) Athlon64 3200 @ 2000 Mhz : >133.858 s (373325 r/s) > Note: Compaq R3240CA Laptop, Cool 'n' Quiet! forced by BIOS. > Note: 512 M RAM > >(FreeBSD/amd64) Clawhammer (S747, 1MB L2 cache) Athlon64 3200 @ 2000 Mhz : >47.2754 s (1057630 r/s) > Note: Compaq R3240CA Laptop, Cool 'n' Quiet! forced by BIOS. > sysctl hw.acpi.cpu.px_control=-1 > Note: 512 M RAM > >(FreeBSD/i386) Pentium II @ 233 Mhz : 538.136 s (92913.3 r/s) > Note: 192 M RAM > >Not surprising is the Pentium II :). What is surprising is that amd64 FreeBSD >seems to execute code faster than i386 FreeBSD, so I'm wondering if gcc >(amd64) really optimizes code for the cpu. If it is, I would probably move my >httpd server to amd64... > >Also, maybe less surprising is that Knoppix sucks running the algorithm for >some reason and that L2 cache really is a big factor (my Laptop outperforms >my heavily overclocked box). > >Any comments? > > From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 17:55:57 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BCD316A41C for ; Wed, 25 May 2005 17:55:57 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from sarajevo.pacific.net.sg (sarajevo.pacific.net.sg [203.120.90.134]) by mx1.FreeBSD.org (Postfix) with SMTP id 43A0843D1D for ; Wed, 25 May 2005 17:55:55 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 29445 invoked from network); 25 May 2005 17:55:51 -0000 Received: from unknown (HELO maxwell2.pacific.net.sg) (203.120.90.192) by sarajevo with SMTP; 25 May 2005 17:55:51 -0000 Received: from [192.168.0.107] ([210.24.246.101]) by maxwell2.pacific.net.sg with ESMTP id <20050525175551.CDDF1130.maxwell2.pacific.net.sg@[192.168.0.107]>; Thu, 26 May 2005 01:55:51 +0800 Message-ID: <4294BC21.8060004@pacific.net.sg> Date: Thu, 26 May 2005 01:55:45 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050514) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Blais References: <200505251317.22128.nb_root@videotron.ca> In-Reply-To: <200505251317.22128.nb_root@videotron.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 optimized gcc? 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: Wed, 25 May 2005 17:55:57 -0000 Hi, Nicolas Blais wrote: > Reference times for benchmark (5e+07 run of the algorithm): > > (FreeBSD/i386) Venice (S939, 512K L2 cache) Athlon64 3000 overclocked @ 2655 > Mhz : 78.3072 s (638511 r/s) > Note: Cool 'n' Quiet! Disabled in BIOS. > Note: 1 G RAM > > (FreeBSD/amd64) Venice (S939, 512K L2 cache) Athlon64 3000 overclocked @ 2655 > Mhz : 71.2521 s (701732 r/s) > Note: Cool 'n' Quiet! Disabled in BIOS. > Note: 1 G RAM > The compiler has more registers when compiling for the AMD64 mode. > Not surprising is the Pentium II :). What is surprising is that amd64 FreeBSD > seems to execute code faster than i386 FreeBSD, so I'm wondering if gcc > (amd64) really optimizes code for the cpu. If it is, I would probably move my > httpd server to amd64... > HTTPD does not gain from the registers but from memory. Erich From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 17:58:58 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7D6A16A41C for ; Wed, 25 May 2005 17:58:58 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56F7843D1D for ; Wed, 25 May 2005 17:58:58 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4PHwvAG059159; Wed, 25 May 2005 10:58:57 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4PHwuR7059158; Wed, 25 May 2005 10:58:56 -0700 (PDT) (envelope-from obrien) Date: Wed, 25 May 2005 10:58:56 -0700 From: "David O'Brien" To: Martin Nilsson Message-ID: <20050525175856.GA59126@dragon.NUXI.org> References: <428C85A6.6010004@gneto.com> <20050525152745.GE35171@dragon.NUXI.org> <4294B9FF.8010705@gneto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4294B9FF.8010705@gneto.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: Opteron problens with 16GB memory X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 17:58:58 -0000 On Wed, May 25, 2005 at 07:46:39PM +0200, Martin Nilsson wrote: > David O'Brien wrote: > Which setting for "hardware memory hole" is recommended? For now, both memory hole support should be turned off. Especially for dual-core CPU's. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 18:51:34 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91BA116A41C for ; Wed, 25 May 2005 18:51:34 +0000 (GMT) (envelope-from dmarshall@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84F9D43D53 for ; Wed, 25 May 2005 18:51:33 +0000 (GMT) (envelope-from dmarshall@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so86927rne for ; Wed, 25 May 2005 11:51:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fEhnBhVGLxaheOLjduLDqLQ0M4wCP94oVC5RiNIl0VeiZP7fF+hwIt6WjtGwrD1UvtVYBv+BCxgk0BMvjiNtZ+sCVN8VaJRyrRvPcw8igyD+adJUXd03gj/+mE8K62rYZ9ZCdE+VqTloQkIFAEbn/ISJXhEWgK9HrJkFw5K93ss= Received: by 10.38.101.64 with SMTP id y64mr249599rnb; Wed, 25 May 2005 11:51:32 -0700 (PDT) Received: by 10.38.181.35 with HTTP; Wed, 25 May 2005 11:51:31 -0700 (PDT) Message-ID: <53f158630505251151567e8063@mail.gmail.com> Date: Wed, 25 May 2005 11:51:32 -0700 From: David Marshall To: freebsd-amd64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: AE_NO_ACPI_TABLES: Is BIOS Update the First Step? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Marshall List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 18:51:34 -0000 Hi, My boss just put a new server in our colo. It has a Tyan Thunder K8SR motherboard with 2 Opterons. When I boot an SMP kernel, dmesg.boot includes the following: CPU: AMD Opteron(tm) Processor 246 (1991.88-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0xf58 Stepping =3D 8 Features=3D0x78bfbff AMD Features=3D0xe0500800 real memory =3D 2147483648 (2048 MB) avail memory =3D 2061676544 (1966 MB) ACPI-0159: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TA= BLES ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI= _TABL ES ACPI: table load failed: AE_NO_ACPI_TABLES My searches have indicated that the most prevalent causes of this are ACPI not being enabled or an out-of-date BIOS. The motherboard manual indicates that ACPI is enabled by default, so should our next step be just to update the BIOS and hope for the best? Is there a clever way to determine our BIOS version without physically accessing the server? TIA! From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 20:40:15 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 888C416A41C for ; Wed, 25 May 2005 20:40:15 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A8BC43D1F for ; Wed, 25 May 2005 20:40:14 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 18FC14AF2F; Wed, 25 May 2005 22:40:13 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15636-01-8; Wed, 25 May 2005 22:40:12 +0200 (CEST) Received: from [82.182.157.67] (1-2-8-5b.asp.sth.bostream.se [82.182.157.67]) by melon.pingpong.net (Postfix) with ESMTP id 9C8684AF2E; Wed, 25 May 2005 22:40:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> Content-Transfer-Encoding: 7bit From: Palle Girgensohn Date: Wed, 25 May 2005 22:40:12 +0200 To: amd64@freebsd.org X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at pingpong.net Cc: Jon Kuster Subject: Dual Xeon EM64T crashes reliably w/ 5.x 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: Wed, 25 May 2005 20:40:15 -0000 Hi! When running our Dell 2850, dual xeon CPUs, in SMP mode with 5.4 (same w/ 5.3-stable), it will relibaly crash at least a couple of times per day. When crashin, the kernel panics (Fatal trap 12: page fault while in kernel mode) and the system will not reboot, neither will it save a core dump. I need to manually hit the big button to reboot. This machine is very loaded, mostly due to some rather sloppy php scripts, that can be well optimized. Average load >1 most of the time, I'd say. Still, it's not a reason to panic, IMHO :) I've built a uni-processor kernel, and now the machine is quite stable, but that's not a solution, of course. I'm cc:ing Jon Kuster, since he describes exactly the same problem, with identical hardware. His machine is not as loaded, so in his case moving from four CPUs (two "real" + HTT) to two real (shutting down HTT) was enough to stop the crashes. For me, I must run UP. So, I don't get any core dumps, the machine does not reboot automatically, and customers are really unhappy. I'm clueless and need help. What do I do? Don't say "linux"... :( /Palle From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 21:05:47 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D48B16A41C for ; Wed, 25 May 2005 21:05:47 +0000 (GMT) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AC6643D1D for ; Wed, 25 May 2005 21:05:46 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id j4PL5jWa019520 for ; Wed, 25 May 2005 17:05:45 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: freebsd-amd64@freebsd.org Content-Type: text/plain Date: Wed, 25 May 2005 17:06:23 -0400 Message-Id: <1117055183.13183.57.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 Subject: BKVASIZE for large block-size filesystems 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: Wed, 25 May 2005 21:05:47 -0000 [originally posted to freebsd-stable, realized that some amd64-specific info may be needed here too] FreeBSD5.4-Stable amd64 on a dual-opteron system with LSI-Megaraid 400G+ partion. The filesystem was created with: newfs -b 65536 -f 8192 -e 15835 /dev/amrd2s1d This is the data filesystem for a PostgreSQL database; as the default page size (files) is 8k, the above newfs scheme has 8k fragments which should fit nicely with the PostgreSQL page size. Now by default param.h defines BKVASIZE as 16384 (which has been pointed out in other posts as being *not* twice the default blocksize of 16k). I have modified it to be set at 32768 but still see a high and increasing value of vfs.bufdefragcnt which makes sense given the blocksize of the major filesystem in use. My question is are there any caveats about increasing BKVASIZE to 65536? The system has 8G of RAM and I understand that nbufs decreases with increasing BKVASIZE; how can I either determine if the resulting nbufs will be sufficient or calculate what is needed based on RAM and system usage? Also, will increasing BKVASIZE require a complete make buildworld or, if not, how can I remake the portions of system affected by BKVASIZE? Sven From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 22:09:28 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2322E16A41C for ; Wed, 25 May 2005 22:09:28 +0000 (GMT) (envelope-from kometen@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC4CA43D49 for ; Wed, 25 May 2005 22:09:27 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so161265rng for ; Wed, 25 May 2005 15:09:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WtzR1EBcriXGR2mpeqUpyRyw51c+6QjThWvYaV3n1a8zdS+EI2aBsz6CvyXeI16Tx3cl5J9CPBpQLofCpG28yP6nW+xmSTNOWloPR3sYAvstMpVt58nhmaaaBkvzaoRWzV6FRTB5QJ6HspMwIKoDBtj5KwkGKNKslfInPCRgaP0= Received: by 10.38.74.75 with SMTP id w75mr1319931rna; Wed, 25 May 2005 15:09:26 -0700 (PDT) Received: by 10.38.149.57 with HTTP; Wed, 25 May 2005 15:09:26 -0700 (PDT) Message-ID: Date: Thu, 26 May 2005 00:09:26 +0200 From: Claus Guttesen To: Palle Girgensohn In-Reply-To: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Claus Guttesen List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 22:09:28 -0000 > with identical hardware. His machine is not as loaded, so in his case > moving from four CPUs (two "real" + HTT) to two real (shutting down > HTT) was enough to stop the crashes. For me, I must run UP. What compile-options do you have in /etc/make.conf? Doing php I guess it's a web-server, what other apps are running on the server? Is the server located in a location with adequate cooling? May not apply any longer, but during the 5.1-days Scott Long advised me to add the following lines to /boot/loader.conf: echo vm.kmem_size=3D"450000000" >> /boot/loader.conf echo kern.maxvnodes=3D"200000" >> /boot/loader.conf That prevented my webservers from rebooting without any apparent reason. Too many temp-files was the cause. Try purging temp-files more often if the above lines do help. Claus From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 22:17:24 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C73FF16A41C for ; Wed, 25 May 2005 22:17:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F9D743D1F for ; Wed, 25 May 2005 22:17:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F3E8C5144D; Wed, 25 May 2005 15:18:11 -0700 (PDT) Date: Wed, 25 May 2005 15:18:11 -0700 From: Kris Kennaway To: K?vesd?n G?bor Message-ID: <20050525221811.GA49299@xor.obsecurity.org> References: <200505251317.22128.nb_root@videotron.ca> <4294BB08.3090703@t-hosting.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <4294BB08.3090703@t-hosting.hu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 optimized gcc? 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: Wed, 25 May 2005 22:17:24 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 25, 2005 at 07:51:04PM +0200, K?vesd?n G?bor wrote: > Hello, >=20 > As for the optimization, I'm very interested how fast can be an actual=20 > optimized system. The stock release doesn't optimizes too much, afaik it= =20 > uses -O. I have been experimenting for a while with building the whole=20 > system with my custom cflags, and yesterday I succeeded. I managed to=20 > build the whole system with >=20 > CFLAGS=3D-s -Os -march=3Dathlon64 > COPTFLAGS=3D-s -Os -march=3Dathlon64 >=20 > I might have used -O2 instead of -Os but not -O3 which made a=20 > compilation error. This might make you feel good, but unless you're running a CPU-bound workload you're unlikely to be able to measure any difference. > The -s is for srtipping the binaries and libs, because this is intended= =20 > to be used on a production system, where we use stable software=20 > releases, thus we don't need debug symbols Binaries are already stripped as they're installed. Kris --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFClPmjWry0BWjoQKURArCgAJ0bBDRwQV8I83GcI5fjYGvlUykrhACdHRCR LZrCpQAkxamgj19S0K96wWc= =T6i9 -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-amd64@FreeBSD.ORG Wed May 25 23:53:48 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEDC916A41C for ; Wed, 25 May 2005 23:53:48 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48D7443D49 for ; Wed, 25 May 2005 23:53:47 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 238254AF56; Thu, 26 May 2005 01:53:46 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 44432-02-7; Thu, 26 May 2005 01:53:45 +0200 (CEST) Received: from [82.182.157.67] (1-2-8-5b.asp.sth.bostream.se [82.182.157.67]) by melon.pingpong.net (Postfix) with ESMTP id 7F80D4AF54; Thu, 26 May 2005 01:53:45 +0200 (CEST) In-Reply-To: References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Palle Girgensohn Date: Thu, 26 May 2005 01:53:45 +0200 To: Claus Guttesen X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at pingpong.net Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Wed, 25 May 2005 23:53:48 -0000 2005-05-26 kl. 00.09 skrev Claus Guttesen: >> with identical hardware. His machine is not as loaded, so in his case >> moving from four CPUs (two "real" + HTT) to two real (shutting down >> HTT) was enough to stop the crashes. For me, I must run UP. > > What compile-options do you have in /etc/make.conf? Doing php I guess > it's a web-server, what other apps are running on the server? Is the > server located in a location with adequate cooling? cooling, yes. You can see my previous posts for more info, but in short, we run php apache-1.3, postgresql-8.0.3, perl-5.8.6 (amavisd), postfix, named, clamd. httpd is very busy. CPUTYPE?=nocona CFLAGS= -O -pipe COPTFLAGS= -O -pipe Kernel is generic except some small details, see http://lists.freebsd.org/pipermail/freebsd-amd64/2005-May/004949.html > May not apply any longer, but during the 5.1-days Scott Long advised > me to add the following lines to /boot/loader.conf: > > echo vm.kmem_size="450000000" >> /boot/loader.conf # sysctl vm.kmem_size vm.kmem_size: 419430400 > echo kern.maxvnodes="200000" >> /boot/loader.conf # sysctl kern.maxvnodes kern.maxvnodes: 100000 Both are lower, but I don't believe this would crash a 5.4 system? Much has happened since 5.1. > > That prevented my webservers from rebooting without any apparent > reason. Too many temp-files was the cause. Try purging temp-files more > often if the above lines do help. I don't have many temp files, doubt it is the problem. It can be an out-of-memory situation, possibly... I realize now it is swapping, 25% of swap used. Must get more memory, I guess... can the machine crash that hard when out of memory??? Problem is, I hardly dare to try anything right now. I'm running single-CPU, it works fine. If it starts crashing again soon, I'll start loosing customers. Would abandoning amd64 and installing a i386 system help? Probably yes? I'd rather not, that's a substantial amount time to reinstall everything... :( /Palle From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 00:13:47 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99A8716A41C for ; Thu, 26 May 2005 00:13:47 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5148943D54 for ; Thu, 26 May 2005 00:13:45 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id A5C8E4CFF4; Thu, 26 May 2005 00:14:04 +0000 (GMT) Received: from [192.168.46.52] (ppp166-27.static.internode.on.net [150.101.166.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id A9A934CEC5; Thu, 26 May 2005 00:14:03 +0000 (GMT) Message-ID: <429514AF.5000306@roq.com> Date: Thu, 26 May 2005 10:13:35 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.8) Gecko/20050524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Blais References: <200505251317.22128.nb_root@videotron.ca> In-Reply-To: <200505251317.22128.nb_root@videotron.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 optimized gcc? 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, 26 May 2005 00:13:47 -0000 Interesting. I have been playing with GCC optimizations my self latterly and have been wondering how much it helps, haven't done any benchmarks though. I some times wonder if the GCC people are doing good working with optimization flags. I recently lost my hard drive on my ASUS A4K (AMD64) laptop, so bought a new 16meg cache 80gig Toshiba hard drive for it, while I wait for warranty to come through on my old one. I did a buildworld under 'CPUTYPE=athlon64' in make.conf and 'CFLAGS= -O2 -pipe -funroll-loops' for the the kernel. I also used both to build all my ports including xorg and KDE. All this combined has made my laptop feel a lot faster. After I load up openoffice2 (via Linux emu) once I can fully reopen a xls file in about 1.5 seconds, I believe the HD cache must be playing a bit part in that. Mike Nicolas Blais wrote: >I am developping a software that follows a random()-dependant algorithm which >is extremely cpu intensif. >I decided to run on different platforms to see how it performed based on cpu >and os (in a way of benchmarking) and I'm surprised by the numbers: > >Reference times for benchmark (5e+07 run of the algorithm): > >(FreeBSD/i386) Venice (S939, 512K L2 cache) Athlon64 3000 overclocked @ 2655 >Mhz : 78.3072 s (638511 r/s) > Note: Cool 'n' Quiet! Disabled in BIOS. > Note: 1 G RAM > >(FreeBSD/amd64) Venice (S939, 512K L2 cache) Athlon64 3000 overclocked @ 2655 >Mhz : 71.2521 s (701732 r/s) > Note: Cool 'n' Quiet! Disabled in BIOS. > Note: 1 G RAM > >(Knoppix/i386) Clawhammer (S747, 1MB L2 cache) Athlon64 3200 @ 2000 Mhz : >133.858 s (373325 r/s) > Note: Compaq R3240CA Laptop, Cool 'n' Quiet! forced by BIOS. > Note: 512 M RAM > >(FreeBSD/amd64) Clawhammer (S747, 1MB L2 cache) Athlon64 3200 @ 2000 Mhz : >47.2754 s (1057630 r/s) > Note: Compaq R3240CA Laptop, Cool 'n' Quiet! forced by BIOS. > sysctl hw.acpi.cpu.px_control=-1 > Note: 512 M RAM > >(FreeBSD/i386) Pentium II @ 233 Mhz : 538.136 s (92913.3 r/s) > Note: 192 M RAM > >Not surprising is the Pentium II :). What is surprising is that amd64 FreeBSD >seems to execute code faster than i386 FreeBSD, so I'm wondering if gcc >(amd64) really optimizes code for the cpu. If it is, I would probably move my >httpd server to amd64... > >Also, maybe less surprising is that Knoppix sucks running the algorithm for >some reason and that L2 cache really is a big factor (my Laptop outperforms >my heavily overclocked box). > >Any comments? > > From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 00:28:33 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB91216A41C for ; Thu, 26 May 2005 00:28:33 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 513B243D49 for ; Thu, 26 May 2005 00:28:33 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so494061wra for ; Wed, 25 May 2005 17:28:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=T5I5CVHK9zABV/++sRRnQ1OBzJLZ/uAXAgfRNYFMdwnXpf79T6qkG4tKLmTl1NMp7pj/cri8p63VIRcBgELAyefMmwxTKdy3FEAstyTPuWJ4LpmsiDXuzVyCIrpRBkvmSZm5x9oQclaxFH1E8OlrqT0p3IPlyWAt6b6B4rlqzNQ= Received: by 10.54.117.4 with SMTP id p4mr653147wrc; Wed, 25 May 2005 17:28:32 -0700 (PDT) Received: by 10.54.40.66 with HTTP; Wed, 25 May 2005 17:28:32 -0700 (PDT) Message-ID: <2fd864e0505251728271d2403@mail.gmail.com> Date: Wed, 25 May 2005 17:28:32 -0700 From: Astrodog To: Palle Girgensohn In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Astrodog List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 00:28:33 -0000 Considering the HTT security announcement, I'm not sure HTT should be enabled on any production boxes. That being said, you may want to investigate the usability of ULE in your situation, assuming it shipped with 5.4 (Which I'm not sure of). In some specific instances, I've seen switching to ULE solve problems of this nature, although it may simply bring up whole new ones. --- Harrison Grundy From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 00:38:58 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C29A16A41C for ; Thu, 26 May 2005 00:38:58 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CBFB43D48 for ; Thu, 26 May 2005 00:38:57 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4Q0ckkG015259; Thu, 26 May 2005 10:38:46 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4Q0cgMC012996; Thu, 26 May 2005 10:38:44 +1000 Date: Thu, 26 May 2005 10:38:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Sven Willenberger In-Reply-To: <1117055183.13183.57.camel@lanshark.dmv.com> Message-ID: <20050526090743.S75084@delplex.bde.org> References: <1117055183.13183.57.camel@lanshark.dmv.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@FreeBSD.org Subject: Re: BKVASIZE for large block-size filesystems 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, 26 May 2005 00:38:58 -0000 On Wed, 25 May 2005, Sven Willenberger wrote: > [originally posted to freebsd-stable, realized that some amd64-specific > info may be needed here too] It's not very amd64-specific due to bugs. BKVASIZE and algorithms that use it are tuned for i386's. This gives mistuning for arches that have more kernel virtual address space. > FreeBSD5.4-Stable amd64 on a dual-opteron system with LSI-Megaraid 400G+ > partion. The filesystem was created with: newfs -b 65536 -f 8192 -e > 15835 /dev/amrd2s1d > > This is the data filesystem for a PostgreSQL database; as the default > page size (files) is 8k, the above newfs scheme has 8k fragments which > should fit nicely with the PostgreSQL page size. Now by default param.h Fragments don't work very well. It might be better to fit files to the block size. If all files had size 8K, then -b 8192 -f 8192 would work best (slightly better than -b 8192 -f 1024, that slightly better than the current defaults, and all much better than -b 65536 -f 8192). > defines BKVASIZE as 16384 (which has been pointed out in other posts as > being *not* twice the default blocksize of 16k). I have modified it to > be set at 32768 but still see a high and increasing value of > vfs.bufdefragcnt which makes sense given the blocksize of the major > filesystem in use. Yes, a block size larger than BKVASIZE will cause lots of fragmentation. I'm not sure if this is still a large pessimization. > My question is are there any caveats about increasing BKVASIZE to 65536? > The system has 8G of RAM and I understand that nbufs decreases with > increasing BKVASIZE; The decrease in nbufs is a bug. It defeats half of the point of increasing BKVASIZE: if most buffers have size 64K, then increasing BKVASIZE from 16K to 64K gives approximately nbuf/4 buffers all of size 64K instead of nbuf buffers, with nbuf/4 of them of size 64K and 3*nbuf/4 of them unusable. Thus it avoids some resource wastage at a cost of possibly not using enough resources for effective caching. However, little is lost if most buffers have size 64K. Then the reduced nbuf consumes all of the kva resources that we are willing to allocate. The problem is when file systems are mixed and ones with a block size of 64K are not used much or at all. The worst case is when all blocks have size 512, which can happen for msdosfs. Then up to (BKVASIZE - 512) / BKVASIZE of the kva resource is wasted (> 99% for BKVASIZE = 65536 but only 97% for BKVASIZE = 16384). To fix the bug, change BKVASIZE in kern_vfs_bio_buffer_alloc() to 16384 and consider adjusting the machbcache tunable (see below). > how can I either determine if the resulting nbufs > will be sufficient or calculate what is needed based on RAM and system > usage? nbuf is not directly visible except using a debugger, but vfs.maxbufspace gives it indirectly -- divide the latter by BKVASIZE to get nbuf. A few thousand for it is plenty. I used to use BKVASIZE = 65536, and fixed the bug as above, and also doubled nbuf in kern_vfs_bio_buffer_alloc(), and also configured VM_BCACHE_SIZE_MAX to 512M so that the elevated nbuf was actually used, but the need for significantly increasing the default nbuf (at least with BKVASIZE = 16384) went away many years ago when memory sizes started exceeding 256M or so. My doubling of nbuf broke a few years later when memory sizes started exceeding 1GB. i386's just don't have enough virtual address space to use a really large nbuf, so when there is enough physical memory the default nbuf is as large as possible. I was only tuning BKVASIZE and VM_BCACHE_SIZE_MAX to benchmark file systems with large block sizes, but the performance with large block sizes was poor even with this tuning so I lost interest in it. Now I just use the defaults and the bug fix reduces to a spelling change. nbuf defeaults to about 7000 on my machines with 1GB of memory. This is plenty. With BKVASIZE = 64K and without the fix, it would be 1/4 as much, which seems a little low. nbuf is also limited by kernel virtual memory. amd's have more (I'm not sure how much), and they should have so much more that the bcache part is effectively infinity, but it is or was actually only twice as much as on i386's (default VM_BCACHE_SIZE_MAX = 200MB on i386's and 400MB on amd64's). Even i386's can spare more provided the memory is not needed for other things, e.g., networking. The default of 400MB on amd64's combined with BKVASIZE gives a limit on nbuf of 400MB/64K = 6400 which is plently, so you shouldn't need to change the bcache tunable. > Also, will increasing BKVASIZE require a complete make buildworld or, if > not, how can I remake the portions of system affected by BKVASIZE? It's not a properly supported option, so the way to change it is to edit it in the sys/param.h source file. After changing it there, the everything will be rebuilt as necessary by makeworld and/or rebuilding kernels. Unfortunately, almost everything will be rebuilt because too many things depend on sys/param.h. When testing changes to BKVASIZE, I used to cheat by preserving the timestamp of sys/param.h and manually recompiling only the necessary things. Very little depends on BKVASIZE. IIRC, there used to be 2 object files per kernel, but now there is only 1 (vfs_bio.o). Bruce From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 00:39:55 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1D2216A41C for ; Thu, 26 May 2005 00:39:55 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DBE843D4C for ; Thu, 26 May 2005 00:39:55 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 596634AD42; Thu, 26 May 2005 02:39:54 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 48082-03-4; Thu, 26 May 2005 02:39:54 +0200 (CEST) Received: from [82.182.157.67] (1-2-8-5b.asp.sth.bostream.se [82.182.157.67]) by melon.pingpong.net (Postfix) with ESMTP id 0C4E84AC72; Thu, 26 May 2005 02:39:54 +0200 (CEST) In-Reply-To: <2fd864e0505251728271d2403@mail.gmail.com> References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Palle Girgensohn Date: Thu, 26 May 2005 02:39:53 +0200 To: Astrodog X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at pingpong.net Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Thu, 26 May 2005 00:39:55 -0000 2005-05-26 kl. 02.28 skrev Astrodog: > Considering the HTT security announcement, I'm not sure HTT should be > enabled on any production boxes. That being said, you may want to > investigate the usability of ULE in your situation, assuming it > shipped with 5.4 (Which I'm not sure of). In some specific instances, > I've seen switching to ULE solve problems of this nature, although it > may simply bring up whole new ones. > I don't think it exists in 5.4, but I may be wrong? /Palle From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 00:44:28 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1910D16A41C for ; Thu, 26 May 2005 00:44:28 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7CEE43D1F for ; Thu, 26 May 2005 00:44:27 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id C1B434AD3B; Thu, 26 May 2005 02:44:26 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 48795-03-2; Thu, 26 May 2005 02:44:26 +0200 (CEST) Received: from [82.182.157.67] (1-2-8-5b.asp.sth.bostream.se [82.182.157.67]) by melon.pingpong.net (Postfix) with ESMTP id 4D64B4AC72; Thu, 26 May 2005 02:44:26 +0200 (CEST) In-Reply-To: <2fd864e0505251728271d2403@mail.gmail.com> References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Palle Girgensohn Date: Thu, 26 May 2005 02:44:26 +0200 To: Astrodog X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at pingpong.net Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Thu, 26 May 2005 00:44:28 -0000 2005-05-26 kl. 02.28 skrev Astrodog: > Considering the HTT security announcement, I'm not sure HTT should be > enabled on any production boxes. HTT is off (byt setting in BIOS). It helped for a couple of days, but now it crashes with "simple" dual SMP as well. Turning SMP off in kernel config makes the machine stable, so this is an SMP problem, AFAIKT. Can anyone conclude if this is a harware problem? There must be tons of Dell 2850's out there, aren't any running FreeBSD 5.4/amd64? Are they stable? /Palle From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 00:47:22 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0F4516A41C for ; Thu, 26 May 2005 00:47:22 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71D6E43D1D for ; Thu, 26 May 2005 00:47:22 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so498767wra for ; Wed, 25 May 2005 17:47:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=id0ZxKcw3bJPQf6qUjWe8ZOEoVF3Kr/QiJ2Q5ZuPnDfnNrUJ1GSXOB3/D5c36CVXNnrfEiURtGTHqaq2WIJVtb/QiHtRDCZQuExYC6WKzoBe7RhPwETexa9jLJwBpY4ef2spArzCOnlLLJxOMjF6p3kYJZ0jSsdCvxROninwyAw= Received: by 10.54.145.14 with SMTP id s14mr662625wrd; Wed, 25 May 2005 17:47:21 -0700 (PDT) Received: by 10.54.40.66 with HTTP; Wed, 25 May 2005 17:47:21 -0700 (PDT) Message-ID: <2fd864e05052517474b44921@mail.gmail.com> Date: Wed, 25 May 2005 17:47:21 -0700 From: Astrodog To: Palle Girgensohn In-Reply-To: <2fd864e050525174534f2a809@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> <2fd864e050525174534f2a809@mail.gmail.com> Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Astrodog List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 00:47:23 -0000 On 5/25/05, Astrodog wrote: > On 5/25/05, Palle Girgensohn wrote: > > > > 2005-05-26 kl. 02.28 skrev Astrodog: > > > > > Considering the HTT security announcement, I'm not sure HTT should be > > > enabled on any production boxes. That being said, you may want to > > > investigate the usability of ULE in your situation, assuming it > > > shipped with 5.4 (Which I'm not sure of). In some specific instances, > > > I've seen switching to ULE solve problems of this nature, although it > > > may simply bring up whole new ones. > > > > > > > I don't think it exists in 5.4, but I may be wrong? > > > > /Palle > > > > >=20 > I just checked CVS, its atleast part of RELENG_5, I don't have a 5.4-R > machine to check on. >=20 If its there, it'll be in src/sys/kern/sched_ule.c From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 00:52:37 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FEF016A41C for ; Thu, 26 May 2005 00:52:37 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D2CA43D48 for ; Thu, 26 May 2005 00:52:36 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so499941wra for ; Wed, 25 May 2005 17:52:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t/uuetx1pcqvM1i2ndEmfA1q3xnEX+1/XajomaqtflTJzvDTAeRsHP6/dYuh2h/1+d3NG4wpbdnAf9td9S67OTX8mhxwoQxvUe1dmbnte1hJ1gr3AokHur7a6ZFVE8tn0vts6JB//0qxAjtpM0H7I+zHNosTBatiey03B8bCS2s= Received: by 10.54.140.3 with SMTP id n3mr667900wrd; Wed, 25 May 2005 17:45:56 -0700 (PDT) Received: by 10.54.40.66 with HTTP; Wed, 25 May 2005 17:45:56 -0700 (PDT) Message-ID: <2fd864e050525174534f2a809@mail.gmail.com> Date: Wed, 25 May 2005 17:45:56 -0700 From: Astrodog To: Palle Girgensohn In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Astrodog List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 00:52:37 -0000 On 5/25/05, Palle Girgensohn wrote: >=20 > 2005-05-26 kl. 02.28 skrev Astrodog: >=20 > > Considering the HTT security announcement, I'm not sure HTT should be > > enabled on any production boxes. That being said, you may want to > > investigate the usability of ULE in your situation, assuming it > > shipped with 5.4 (Which I'm not sure of). In some specific instances, > > I've seen switching to ULE solve problems of this nature, although it > > may simply bring up whole new ones. > > >=20 > I don't think it exists in 5.4, but I may be wrong? >=20 > /Palle >=20 >=20 I just checked CVS, its atleast part of RELENG_5, I don't have a 5.4-R machine to check on. From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 01:39:52 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D970F16A41C for ; Thu, 26 May 2005 01:39:52 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 623C143D1D for ; Thu, 26 May 2005 01:39:52 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp101.rog.mail.re2.yahoo.com with SMTP; 26 May 2005 01:39:51 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Wed, 25 May 2005 21:39:51 -0400 (EDT) Message-ID: <1472.172.16.0.199.1117071591.squirrel@172.16.0.1> In-Reply-To: References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> Date: Wed, 25 May 2005 21:39:51 -0400 (EDT) From: "Mike Jakubik" To: "Palle Girgensohn" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Thu, 26 May 2005 01:39:53 -0000 On Wed, May 25, 2005 8:44 pm, Palle Girgensohn said: > > > HTT is off (byt setting in BIOS). It helped for a couple of days, but > now it crashes with "simple" dual SMP as well. Turning SMP off in kernel > config makes the machine stable, so this is an SMP problem, AFAIKT. > > > Can anyone conclude if this is a harware problem? There must be tons of > Dell 2850's out there, aren't any running FreeBSD 5.4/amd64? Are they > stable? You would have to enable debugging, and let us know the result. Please look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html for more info. Also, a dmesg of your system would be useful too. From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 02:37:18 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EDA616A41C for ; Thu, 26 May 2005 02:37:18 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61C8743D48 for ; Thu, 26 May 2005 02:37:18 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.1.4] (pcp04418836pcs.nrockv01.md.comcast.net [69.140.110.248]) by yertle.kcilink.com (Postfix) with ESMTP id 702ABB85A for ; Wed, 25 May 2005 22:37:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Wed, 25 May 2005 22:37:15 -0400 To: amd64@freebsd.org X-Mailer: Apple Mail (2.730) Cc: Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Thu, 26 May 2005 02:37:18 -0000 On May 25, 2005, at 8:44 PM, Palle Girgensohn wrote: > Can anyone conclude if this is a harware problem? There must be > tons of Dell 2850's out there, aren't any running FreeBSD 5.4/ > amd64? Are they stable? > > what ethernet is on the motherboard? i had a pair of dual opterons that would regularly lockup under bge but when i put in some intel- based em driver cards, the boxes became completely stable, even before the recent opteron-lockup fix that went into 5.4. From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 03:12:47 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CD1516A41F for ; Thu, 26 May 2005 03:12:47 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AA6143D49 for ; Thu, 26 May 2005 03:12:46 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so865725nzp for ; Wed, 25 May 2005 20:12:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SCz8eYXcjSwesD3RumbndFD9Ly7aFZpjXZMZrtpHS6JTrO9RS5KOf+2qoE2rcKJanjoNz3EQcrQv+dE55N+lw8rgGQUOnp1dwLvIFGzu7LkBLyUwrdLc048y9LKyYsMRas9j69E9/fCv4onrBJ/Nv7EcfrBnK75/M/ePfnjq1cw= Received: by 10.36.157.18 with SMTP id f18mr434655nze; Wed, 25 May 2005 20:12:45 -0700 (PDT) Received: by 10.36.72.13 with HTTP; Wed, 25 May 2005 20:12:45 -0700 (PDT) Message-ID: <28edec3c05052520121e03ec8f@mail.gmail.com> Date: Thu, 26 May 2005 11:12:45 +0800 From: "Mars G. Miro" To: sean@mcneil.com, freebsd-amd64@freebsd.org In-Reply-To: <1117036713.35298.1.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <28edec3c0505250247428b6db2@mail.gmail.com> <1117036713.35298.1.camel@server.mcneil.com> Cc: Subject: Re: bind 9.3.1 thread issues on FreeBSD 5.3R/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Mars G. Miro" List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 03:12:47 -0000 On 5/25/05, Sean McNeil wrote: > On Wed, 2005-05-25 at 17:47 +0800, Mars G. Miro wrote: > > Yo list! > >=20 > > I think I'm seeing a problem about bind9.3.1 on FreeBSD 5.3R/AMD64. > > This is addressed by setting WITHOUT_BIND9_THREADS=3Dtrue when compilin= g > > the port. This also doesn't happen on FreeBSD 5.4R/AMD64. > >=20 > > The problem manifests when shutting down the named daemon where it > > just would not die gracefully (you have to kill -9 it). > >=20 > > Here are the necessary steps to reproduce it: > > 1) install FreeBSD5.3R/AMD64 > > 2) install bind9.3.1 from ports (set WITH_PORT_REPLACES_BASE_BIND9) > > 3) configure a simple resolver (# cd /var/named/etc/namedb && sh > > make-localhost) > > 4) start named server ( # /etc/rc.d/named start or # named -u bind -t > > /var/named ) > > 5) test some dns queries ( dig, nslookup etc) > > 6) kill named server ( # /etc/rc.d/named stop or # killall named ),=20 > > [ this is where it happens ... ] >=20 > There is a problem with threads on exit that was fixed in 5.4. Update > to -STABLE to get lots of stability issues as well as this problem > resolved. >=20 Yeah, as I've stated it doesn't happen 5.4R, the interesting bit though is that it only happens on AMD64. Also the problem can be reproduced in a jail, in fact it was in a jail that I first found out about it. Thanks, > Cheers, > Sean >=20 >=20 >=20 cheers mars From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 06:31:16 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC67016A420 for ; Thu, 26 May 2005 06:31:16 +0000 (GMT) (envelope-from kometen@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id C527D43D1F for ; Thu, 26 May 2005 06:31:15 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so202220rng for ; Wed, 25 May 2005 23:31:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ugm9N9kxpg7NmCx6YRr97mhxfnNdx5mVBm5r6PkqxNSP4P3aCFxSUq+IPPzMlFR1xhWRaS2bCgNq3IGdtxnGWuq9yWRvaXUr9g9SIGvMpnqFv2prQymLuoxpfqBaICaxN7FDIlNC2o6/c1QaGM95em/7T9wXri1Ox/E5VLVKXLg= Received: by 10.38.161.27 with SMTP id j27mr1822390rne; Wed, 25 May 2005 23:31:15 -0700 (PDT) Received: by 10.38.149.57 with HTTP; Wed, 25 May 2005 23:31:15 -0700 (PDT) Message-ID: Date: Thu, 26 May 2005 08:31:15 +0200 From: Claus Guttesen To: Palle Girgensohn In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Claus Guttesen List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 06:31:17 -0000 > Can anyone conclude if this is a harware problem? There must be tons of > Dell 2850's out there, aren't any running FreeBSD 5.4/amd64? Are they > stable? I have one in production running rt3 (using mysql as backend), the server is lightly loaded, but I'll be moving more services like samba over on the box the next few weeks. It's lightly loaded most of the times, but have been very stable apart from that. Then I have two test-servers I'll be phasing in as nfs-servers. During some tests it's been running stable. All running the amd64-port. Claus From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 07:10:45 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D29916A41C for ; Thu, 26 May 2005 07:10:45 +0000 (GMT) (envelope-from kometen@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C55EB43D1F for ; Thu, 26 May 2005 07:10:44 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so205334rng for ; Thu, 26 May 2005 00:10:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pVpVpC8dITjplrDaGN+7MzxCisOa8orH00NYNgcIiZwy8WVd7VD5wq3Fr709nVlzKl85n6x782S/VvKp8Evq/p2CBTpmdi+pbVoLble+ILP2TSe3WHfeYweTcBh/HR1MXto5P8+t6X9T5cREqwfkDqULx9bTNZ+R/4wyl5lh4ZM= Received: by 10.38.12.13 with SMTP id 13mr1816038rnl; Thu, 26 May 2005 00:10:44 -0700 (PDT) Received: by 10.38.149.57 with HTTP; Thu, 26 May 2005 00:10:44 -0700 (PDT) Message-ID: Date: Thu, 26 May 2005 09:10:44 +0200 From: Claus Guttesen To: Palle Girgensohn In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Claus Guttesen List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 07:10:45 -0000 > cooling, yes. You can see my previous posts for more info, but in > short, we run php apache-1.3, postgresql-8.0.3, perl-5.8.6 (amavisd), > postfix, named, clamd. httpd is very busy. >=20 > CPUTYPE?=3Dnocona > CFLAGS=3D -O -pipe > COPTFLAGS=3D -O -pipe I have CPUTYPE=3Dnocona, CFLAGS=3D -O2 -pipe -funroll-loops and COPTFLAGS= =3D -O2 -pipe -funroll-loops, but that should not make any difference. > Kernel is generic except some small details, see > http://lists.freebsd.org/pipermail/freebsd-amd64/2005-May/004949.html > I don't have many temp files, doubt it is the problem. It can be an > out-of-memory situation, possibly... I realize now it is swapping, 25% > of swap used. Must get more memory, I guess... can the machine crash > that hard when out of memory??? I saw the dmesg and noticed this at the bottom: Interrupt storm detected on "irq18: uhci2"; throttling interrupt source Interrupt storm detected on "irq16: uhci0"; throttling interrupt source This indicates USB, if so try adding usbd_enable=3D"NO" to /etc/rc.conf. Try limiting the amount of clients able to connect to your webserver, so you can serve those which do get access well. I have the following in my /usr/local/etc/apache/httpd.conf (I'm using apache): KeepAlive Off MaxClients 50 MaxClients is (avail. RAM / size of each process) minus some housekeeping. Your server should not swap. Since KeepAlive is off it can serve more clients than 50. > Would abandoning amd64 and installing a i386 system help? Probably yes? > I'd rather not, that's a substantial amount time to reinstall > everything... :( Don't know, but amd64 appears faster than i386 (when you can go with dual of course). Claus From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 08:22:26 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1AE016A425 for ; Thu, 26 May 2005 08:22:26 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3846043D6A for ; Thu, 26 May 2005 08:22:23 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 2E6254ACE0; Thu, 26 May 2005 10:22:22 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 92081-01; Thu, 26 May 2005 10:22:21 +0200 (CEST) Received: from [82.182.157.67] (1-2-8-5b.asp.sth.bostream.se [82.182.157.67]) by melon.pingpong.net (Postfix) with ESMTP id B3B2C4ACDC; Thu, 26 May 2005 10:22:20 +0200 (CEST) In-Reply-To: <1472.172.16.0.199.1117071591.squirrel@172.16.0.1> References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> <1472.172.16.0.199.1117071591.squirrel@172.16.0.1> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <252b9604b5fd2d0c671818d1f7f4dd76@pingpong.net> Content-Transfer-Encoding: 7bit From: Palle Girgensohn Date: Thu, 26 May 2005 10:22:19 +0200 To: "Mike Jakubik" X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at pingpong.net Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Thu, 26 May 2005 08:22:27 -0000 2005-05-26 kl. 03.39 skrev Mike Jakubik: > On Wed, May 25, 2005 8:44 pm, Palle Girgensohn said: >> > >> >> HTT is off (byt setting in BIOS). It helped for a couple of days, but >> now it crashes with "simple" dual SMP as well. Turning SMP off in >> kernel >> config makes the machine stable, so this is an SMP problem, AFAIKT. >> >> >> Can anyone conclude if this is a harware problem? There must be tons >> of >> Dell 2850's out there, aren't any running FreeBSD 5.4/amd64? Are they >> stable? > > You would have to enable debugging, and let us know the result. Please > look at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ > kerneldebug.html > for more info. Also, a dmesg of your system would be useful too. Debugging is on, but the crash/panic does not write a core, it never happens, the system is too hung for that... it does no automatic reboot, and is completely unresponsive, I have to hit the big button to restart it. :( KDB KDB_UNATTENDED KDB_TRACE Not even the KDB_TRACE reveals anything... /Palle From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 08:35:07 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19B4E16A41C for ; Thu, 26 May 2005 08:35:07 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from salvador.pacific.net.sg (salvador.pacific.net.sg [203.120.90.219]) by mx1.FreeBSD.org (Postfix) with SMTP id 2626F43D1D for ; Thu, 26 May 2005 08:35:05 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 8036 invoked from network); 26 May 2005 08:34:48 -0000 Received: from unknown (HELO maxwell2.pacific.net.sg) (203.120.90.192) by salvador with SMTP; 26 May 2005 08:34:47 -0000 Received: from [192.168.0.107] ([210.24.246.101]) by maxwell2.pacific.net.sg with ESMTP id <20050526083437.FJBU1130.maxwell2.pacific.net.sg@[192.168.0.107]>; Thu, 26 May 2005 16:34:37 +0800 Message-ID: <42958A0E.2020205@pacific.net.sg> Date: Thu, 26 May 2005 16:34:22 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050514) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Palle Girgensohn References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> <1472.172.16.0.199.1117071591.squirrel@172.16.0.1> <252b9604b5fd2d0c671818d1f7f4dd76@pingpong.net> In-Reply-To: <252b9604b5fd2d0c671818d1f7f4dd76@pingpong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Thu, 26 May 2005 08:35:07 -0000 Hi, did this machine ever run with two CPUs with any operating system? Erich Palle Girgensohn wrote: > > 2005-05-26 kl. 03.39 skrev Mike Jakubik: > >> On Wed, May 25, 2005 8:44 pm, Palle Girgensohn said: >> >>> >> >>> >>> HTT is off (byt setting in BIOS). It helped for a couple of days, but >>> now it crashes with "simple" dual SMP as well. Turning SMP off in >>> kernel >>> config makes the machine stable, so this is an SMP problem, AFAIKT. >>> >>> >>> Can anyone conclude if this is a harware problem? There must be tons of >>> Dell 2850's out there, aren't any running FreeBSD 5.4/amd64? Are they >>> stable? >> >> >> You would have to enable debugging, and let us know the result. Please >> look at >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ >> kerneldebug.html >> for more info. Also, a dmesg of your system would be useful too. > > > Debugging is on, but the crash/panic does not write a core, it never > happens, the system is too hung for that... it does no automatic > reboot, and is completely unresponsive, I have to hit the big button to > restart it. :( > > KDB > KDB_UNATTENDED > KDB_TRACE > > Not even the KDB_TRACE reveals anything... > > /Palle > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 08:53:47 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 052B916A41F for ; Thu, 26 May 2005 08:53:47 +0000 (GMT) (envelope-from kometen@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8098143D66 for ; Thu, 26 May 2005 08:53:41 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so214021rng for ; Thu, 26 May 2005 01:53:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IYHsxN5E2waTWekbn7TnbMt609eEDr9zQYTw2NKcRLd/qtm6tfPwgP5PaWHmxdtRIyKR54JC4i4DIKJt45RnOc7ILzEf8UbBup9PoUJvfYtPETtNZkYk3KsHwgJfkr8sUj0mdX3AL62pdCHjpl0wKpwtzONVzC2vVESorTbuC2Y= Received: by 10.38.5.73 with SMTP id 73mr1843778rne; Thu, 26 May 2005 01:53:40 -0700 (PDT) Received: by 10.38.149.57 with HTTP; Thu, 26 May 2005 01:53:40 -0700 (PDT) Message-ID: Date: Thu, 26 May 2005 10:53:40 +0200 From: Claus Guttesen To: Erich Dollansky In-Reply-To: <42958A0E.2020205@pacific.net.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <2fd864e0505251728271d2403@mail.gmail.com> <1472.172.16.0.199.1117071591.squirrel@172.16.0.1> <252b9604b5fd2d0c671818d1f7f4dd76@pingpong.net> <42958A0E.2020205@pacific.net.sg> Cc: amd64@freebsd.org, Palle Girgensohn Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Claus Guttesen List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 08:53:47 -0000 > Hi, > did this machine ever run with two CPUs with any operating system? Don't top-post please! Yes, on FreeBSD at least. I have two smaller 1850's running as webservers sometimes heavily loaded, no panics. Claus From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 09:04:37 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EC3216A41C for ; Thu, 26 May 2005 09:04:37 +0000 (GMT) (envelope-from archwndas@yahoo.com) Received: from web61114.mail.yahoo.com (web61114.mail.yahoo.com [209.73.179.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 1F29D43D5E for ; Thu, 26 May 2005 09:04:34 +0000 (GMT) (envelope-from archwndas@yahoo.com) Received: (qmail 93315 invoked by uid 60001); 26 May 2005 09:04:34 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=LdHSgyqc8vHe0gihbgg4kaWQIFAxKcRD743H2/X9zp1I8XLgDAkUOgHfsRF7YnKWMmLEHk6Ci/I+ovvRpIBvivXf7YIXQ7XlM1a2I7TZavWlNOzF4D1UBNbze9wP/a3VnMTVi2MzH/nUd4so5D0oA6ur3hri1JYr65s+vyfpFvM= ; Message-ID: <20050526090434.93313.qmail@web61114.mail.yahoo.com> Received: from [195.130.113.228] by web61114.mail.yahoo.com via HTTP; Thu, 26 May 2005 02:04:34 PDT Date: Thu, 26 May 2005 02:04:34 -0700 (PDT) From: Simeon Nifos To: freebsd-amd64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: FreeBSD 5.4 Release AMD64 (installation CD) boot fails 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, 26 May 2005 09:04:37 -0000 Dear list, Booting from the AMD64 installation CD of 5.4 Release, hoping to install it I was suprised to see that it stack after Beastie-menu! It didn't want to boot no matter if I tried "Boot with ACPI Disabled". Any ideas how to fix this problem? I had the same problem on an Opteron QUAD with a TYAN S4882. Regards! Simeon! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 13:02:25 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0EB916A420 for ; Thu, 26 May 2005 13:02:24 +0000 (GMT) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8780D43D1D for ; Thu, 26 May 2005 13:02:24 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id j4QD2LWa038966; Thu, 26 May 2005 09:02:22 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: Bruce Evans In-Reply-To: <20050526090743.S75084@delplex.bde.org> References: <1117055183.13183.57.camel@lanshark.dmv.com> <20050526090743.S75084@delplex.bde.org> Content-Type: text/plain Date: Thu, 26 May 2005 09:02:59 -0400 Message-Id: <1117112579.15065.30.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 Cc: freebsd-amd64@FreeBSD.org Subject: Re: BKVASIZE for large block-size filesystems 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, 26 May 2005 13:02:25 -0000 On Thu, 2005-05-26 at 10:38 +1000, Bruce Evans wrote: > On Wed, 25 May 2005, Sven Willenberger wrote: > > > [originally posted to freebsd-stable, realized that some amd64-specific > > info may be needed here too] > > It's not very amd64-specific due to bugs. BKVASIZE and algorithms that > use it are tuned for i386's. This gives mistuning for arches that have > more kernel virtual address space. > > > FreeBSD5.4-Stable amd64 on a dual-opteron system with LSI-Megaraid 400G+ > > partion. The filesystem was created with: newfs -b 65536 -f 8192 -e > > 15835 /dev/amrd2s1d > > > > This is the data filesystem for a PostgreSQL database; as the default > > page size (files) is 8k, the above newfs scheme has 8k fragments which > > should fit nicely with the PostgreSQL page size. Now by default param.h > > Fragments don't work very well. It might be better to fit files to the > block size. If all files had size 8K, then -b 8192 -f 8192 would work > best (slightly better than -b 8192 -f 1024, that slightly better than > the current defaults, and all much better than -b 65536 -f 8192). > Oh, how I wish I would have known that prior to creating the filesystem. I wanted to avoid -b 8192 -f 1024 because of the small fragment size; I had assumned that fragment size matching the file page size used by the database would be ideal. Since the manpages seem to imply that anything other than 8:1 ratio of blocksize to fragment size would be detrimental I stayed away from -b 8192 -f 8192. I am curious as to what the concept behind fragments are then (versus my picture) and why they "don't work very well" ... > > defines BKVASIZE as 16384 (which has been pointed out in other posts as > > being *not* twice the default blocksize of 16k). I have modified it to > > be set at 32768 but still see a high and increasing value of > > vfs.bufdefragcnt which makes sense given the blocksize of the major > > filesystem in use. > > Yes, a block size larger than BKVASIZE will cause lots of fragmentation. > I'm not sure if this is still a large pessimization. > > > My question is are there any caveats about increasing BKVASIZE to 65536? > > The system has 8G of RAM and I understand that nbufs decreases with > > increasing BKVASIZE; > > The decrease in nbufs is a bug. It defeats half of the point of increasing > BKVASIZE: if most buffers have size 64K, then increasing BKVASIZE from 16K > to 64K gives approximately nbuf/4 buffers all of size 64K instead of nbuf > buffers, with nbuf/4 of them of size 64K and 3*nbuf/4 of them unusable. > Thus it avoids some resource wastage at a cost of possibly not using enough > resources for effective caching. However, little is lost if most buffers > have size 64K. Then the reduced nbuf consumes all of the kva resources that > we are willing to allocate. The problem is when file systems are mixed and > ones with a block size of 64K are not used much or at all. The worst case > is when all blocks have size 512, which can happen for msdosfs. Then up > to (BKVASIZE - 512) / BKVASIZE of the kva resource is wasted (> 99% for > BKVASIZE = 65536 but only 97% for BKVASIZE = 16384). > > To fix the bug, change BKVASIZE in kern_vfs_bio_buffer_alloc() to 16384 > and consider adjusting the machbcache tunable (see below). > Ahh, so this is literal replace the word "BKVASIZE" in that function with the word "16384". I am assuming that I can leave other instances of BKVASIZE and BKVAMASK in that file (vfs_bio.c) alone then? > > how can I either determine if the resulting nbufs > > will be sufficient or calculate what is needed based on RAM and system > > usage? > > nbuf is not directly visible except using a debugger, but vfs.maxbufspace > gives it indirectly -- divide the latter by BKVASIZE to get nbuf. A few > thousand for it is plenty. > > I used to use BKVASIZE = 65536, and fixed the bug as above, and also doubled > nbuf in kern_vfs_bio_buffer_alloc(), and also configured VM_BCACHE_SIZE_MAX > to 512M so that the elevated nbuf was actually used, but the need for > significantly increasing the default nbuf (at least with BKVASIZE = 16384) > went away many years ago when memory sizes started exceeding 256M or so. > My doubling of nbuf broke a few years later when memory sizes started > exceeding 1GB. i386's just don't have enough virtual address space to use > a really large nbuf, so when there is enough physical memory the default > nbuf is as large as possible. I was only tuning BKVASIZE and > VM_BCACHE_SIZE_MAX to benchmark file systems with large block sizes, but > the performance with large block sizes was poor even with this tuning so > I lost interest in it. Now I just use the defaults and the bug fix > reduces to a spelling change. nbuf defeaults to about 7000 on my machines > with 1GB of memory. This is plenty. With BKVASIZE = 64K and without the > fix, it would be 1/4 as much, which seems a little low. > > nbuf is also limited by kernel virtual memory. amd's have more (I'm not > sure how much), and they should have so much more that the bcache part > is effectively infinity, but it is or was actually only twice as much > as on i386's (default VM_BCACHE_SIZE_MAX = 200MB on i386's and 400MB > on amd64's). Even i386's can spare more provided the memory is not > needed for other things, e.g., networking. The default of 400MB on > amd64's combined with BKVASIZE gives a limit on nbuf of 400MB/64K = 6400 > which is plently, so you shouldn't need to change the bcache tunable. > I shall leave that tunable alone then. > > Also, will increasing BKVASIZE require a complete make buildworld or, if > > not, how can I remake the portions of system affected by BKVASIZE? > > It's not a properly supported option, so the way to change it is to > edit it in the sys/param.h source file. After changing it there, > the everything will be rebuilt as necessary by makeworld and/or > rebuilding kernels. Unfortunately, almost everything will be rebuilt > because too many things depend on sys/param.h. When testing > changes to BKVASIZE, I used to cheat by preserving the timestamp of > sys/param.h and manually recompiling only the necessary things. Very > little depends on BKVASIZE. IIRC, there used to be 2 object files > per kernel, but now there is only 1 (vfs_bio.o). > > Bruce Sounds good; I appreciate the input and the explanations -- really cleared up a good bit of stuff for me. Thanks, Sven From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 15:55:25 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4194116A41F for ; Thu, 26 May 2005 15:55:25 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id F29F243D1D for ; Thu, 26 May 2005 15:55:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D540D5138D; Thu, 26 May 2005 08:56:12 -0700 (PDT) Date: Thu, 26 May 2005 08:56:12 -0700 From: Kris Kennaway To: Michael VInce Message-ID: <20050526155612.GA38421@xor.obsecurity.org> References: <200505251317.22128.nb_root@videotron.ca> <429514AF.5000306@roq.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <429514AF.5000306@roq.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 optimized gcc? 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, 26 May 2005 15:55:25 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 26, 2005 at 10:13:35AM +1000, Michael VInce wrote: > Interesting. > I have been playing with GCC optimizations my self latterly and have=20 > been wondering how much it helps, haven't done any benchmarks though. > I some times wonder if the GCC people are doing good working with=20 > optimization flags. >=20 > I recently lost my hard drive on my ASUS A4K (AMD64) laptop, > so bought a new 16meg cache 80gig Toshiba hard drive for it, while I=20 > wait for warranty to come through on my old one. > I did a buildworld under 'CPUTYPE=3Dathlon64' in make.conf and 'CFLAGS= =3D=20 > -O2 -pipe -funroll-loops' for the the kernel. > I also used both to build all my ports including xorg and KDE. > All this combined has made my laptop feel a lot faster. Google for 'placebo effect' :-) Unfortunately, leet optimization flags do not measurably effect everyday system performance, only specific CPU-intensive operations. Kris --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFClfGcWry0BWjoQKURAhCVAKC+HLlTdGM/B+pFs/gJgPvTJAzA3QCgkOt2 3z1cwuAWWf1nQw3yI20EAqs= =AZ0I -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 16:12:47 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65EF216A435 for ; Thu, 26 May 2005 16:12:47 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D95243D6A for ; Thu, 26 May 2005 16:12:41 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp105.rog.mail.re2.yahoo.com with SMTP; 26 May 2005 16:12:41 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Thu, 26 May 2005 12:12:39 -0400 (EDT) Message-ID: <2302.172.16.0.199.1117123959.squirrel@172.16.0.1> In-Reply-To: <20050526155612.GA38421@xor.obsecurity.org> References: <200505251317.22128.nb_root@videotron.ca> <429514AF.5000306@roq.com> <20050526155612.GA38421@xor.obsecurity.org> Date: Thu, 26 May 2005 12:12:39 -0400 (EDT) From: "Mike Jakubik" To: "Kris Kennaway" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 optimized gcc? 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, 26 May 2005 16:12:47 -0000 On Thu, May 26, 2005 11:56 am, Kris Kennaway said: > On Thu, May 26, 2005 at 10:13:35AM +1000, Michael VInce wrote: >> for warranty to come through on my old one. I did a buildworld under >> 'CPUTYPE=athlon64' in make.conf and 'CFLAGS= >> -O2 -pipe -funroll-loops' for the the kernel. >> I also used both to build all my ports including xorg and KDE. >> > >> All this combined has made my laptop feel a lot faster. >> > > Google for 'placebo effect' :-) Unfortunately, leet optimization flags > do not measurably effect everyday system performance, only specific > CPU-intensive operations. Tell that to the Gentoo people :) From owner-freebsd-amd64@FreeBSD.ORG Thu May 26 16:18:09 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C34F716A41C for ; Thu, 26 May 2005 16:18:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D02843D4C for ; Thu, 26 May 2005 16:18:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 59C6F512BD; Thu, 26 May 2005 09:18:57 -0700 (PDT) Date: Thu, 26 May 2005 09:18:56 -0700 From: Kris Kennaway To: Mike Jakubik Message-ID: <20050526161856.GA47336@xor.obsecurity.org> References: <200505251317.22128.nb_root@videotron.ca> <429514AF.5000306@roq.com> <20050526155612.GA38421@xor.obsecurity.org> <2302.172.16.0.199.1117123959.squirrel@172.16.0.1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <2302.172.16.0.199.1117123959.squirrel@172.16.0.1> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org, Kris Kennaway Subject: Re: amd64 optimized gcc? 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, 26 May 2005 16:18:10 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 26, 2005 at 12:12:39PM -0400, Mike Jakubik wrote: > On Thu, May 26, 2005 11:56 am, Kris Kennaway said: > > On Thu, May 26, 2005 at 10:13:35AM +1000, Michael VInce wrote: >=20 > >> for warranty to come through on my old one. I did a buildworld under > >> 'CPUTYPE=3Dathlon64' in make.conf and 'CFLAGS=3D > >> -O2 -pipe -funroll-loops' for the the kernel. > >> I also used both to build all my ports including xorg and KDE. > >> > > > >> All this combined has made my laptop feel a lot faster. > >> > > > > Google for 'placebo effect' :-) Unfortunately, leet optimization flags > > do not measurably effect everyday system performance, only specific > > CPU-intensive operations. >=20 > Tell that to the Gentoo people :) There's nothing wrong with appropriately chosen optimizations (but e.g. -funroll-loops is probably stupid), but pretending you can "feel the power" is self-deception. Kris --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFClfbwWry0BWjoQKURAjG3AJ4vbrfYYGHUrrbIj6yCeLAGnIUY3ACg3OYB RUI9W9ZEYHt82YiTN2BWD+s= =eJ2L -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 03:44:49 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAAAA16A41C for ; Fri, 27 May 2005 03:44:49 +0000 (GMT) (envelope-from lists@natserv.com) Received: from mail1.acecape.com (mail1.acecape.com [66.114.74.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FF6443D54 for ; Fri, 27 May 2005 03:44:49 +0000 (GMT) (envelope-from lists@natserv.com) Received: from zoraida.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mail1.acecape.com (8.12.11/8.12.11) with ESMTP id j4R3imeu023539 for ; Thu, 26 May 2005 23:44:48 -0400 Date: Thu, 26 May 2005 23:44:48 -0400 (EDT) From: Francisco Reyes X-X-Sender: fran@zoraida.natserv.net To: FreeBSD amd64 List Message-ID: <20050526233707.O5798@zoraida.natserv.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Memory usage for 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: Fri, 27 May 2005 03:44:50 -0000 Is the memory usage on AMD64 comparable to i386? A current i386 machine that I plan to replace is using less than 128MB of RAM out of the 256MB installed. The swap is less than 500K. The only processes are SSH, postfix and samba. Will an AMD64 setup be in the same memory usage range? Under 128MB. I am planning on getting 256MB anyways, but want to make sure that AMD64 doesn't have a bigger memory footprint for the OS and that apps don't use significantly more memory when compiled under AMD64. Thanks. From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 04:43:58 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1069916A41C for ; Fri, 27 May 2005 04:43:58 +0000 (GMT) (envelope-from kolicz@EUnet.yu) Received: from smtpclu-1.eunet.yu (smtpclu-1.eunet.yu [194.247.192.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F47E43D49 for ; Fri, 27 May 2005 04:43:56 +0000 (GMT) (envelope-from kolicz@EUnet.yu) Received: from faust.net (P-2.105.EUnet.yu [213.240.2.105]) by smtpclu-1.eunet.yu (8.12.11/8.12.11) with ESMTP id j4R4hlSP018228 for ; Fri, 27 May 2005 06:43:47 +0200 Received: by faust.net (Postfix, from userid 1001) id A3EFB420F; Fri, 27 May 2005 06:43:10 +0200 (CEST) Date: Fri, 27 May 2005 06:43:10 +0200 From: Zoran Kolic To: freebsd-amd64@freebsd.org Message-ID: <20050527044310.GB541@faust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scan: EUnet-AVAS-Milter X-AVAS-Virus-Status: clean X-Spam-Checker: EUnet-AVAS-Milter X-AVAS-Spam-Score: 0.0 X-AVAS-Spam-Status: unchecked X-AVAS-Spam-Symbols: UNCHECKED Subject: xorg+amd64+nv5700 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, 27 May 2005 04:43:58 -0000 Dear all! I have 5.4, amd64 version and question about graphic cards. After upgrading the box, there was ati9550. It is not necessary for me, but... The picture was a little bit hazy. I went to the shop and replaced it after little testing for nvidia 5700. I don't realy need this too. The situation is better, still the picture is not crispy I would like. Am I gone crazy or should tweak something? Driver = "nv". Old ati7000 worked perfect and gave clear picture in all ocasions. What info should I post? Best regards Zoran From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 08:03:12 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36A8F16A41C for ; Fri, 27 May 2005 08:03:11 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4219F43D49 for ; Fri, 27 May 2005 08:03:10 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j4R838E4072151; Fri, 27 May 2005 11:03:08 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 99468-12; Fri, 27 May 2005 11:03:07 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j4R837tp072147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 May 2005 11:03:07 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j4R83TJK005699; Fri, 27 May 2005 11:03:29 +0300 (EEST) (envelope-from ru) Date: Fri, 27 May 2005 11:03:29 +0300 From: Ruslan Ermilov To: Francisco Reyes Message-ID: <20050527080329.GA5586@ip.net.ua> References: <20050526233707.O5798@zoraida.natserv.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <20050526233707.O5798@zoraida.natserv.net> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: FreeBSD amd64 List Subject: Re: Memory usage for 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: Fri, 27 May 2005 08:03:12 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 26, 2005 at 11:44:48PM -0400, Francisco Reyes wrote: > Is the memory usage on AMD64 comparable to i386? >=20 > A current i386 machine that I plan to replace is using less than 128MB of= =20 > RAM out of the 256MB installed. The swap is less than 500K. The only=20 > processes are SSH, postfix and samba. >=20 > Will an AMD64 setup be in the same memory usage range? Under 128MB. >=20 > I am planning on getting 256MB anyways, but want to make sure that AMD64= =20 > doesn't have a bigger memory footprint for the OS and that apps don't use= =20 > significantly more memory when compiled under AMD64. >=20 I'd estimate it's 1.5-2 times more on AMD64 than on i386. At least simple tesing of binary sizes and memory sizes of simple progs shows the difference in this range. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCltRRqRfpzJluFF4RAvhxAJ9zFxDr+V7SDY9z8tWrQQrJISqXnwCfaOSL K57CKjZWhKplCJkBXUBbTuk= =Q3+p -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 14:53:25 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E0FA16A41C for ; Fri, 27 May 2005 14:53:25 +0000 (GMT) (envelope-from groot@kde.org) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B73AB43D49 for ; Fri, 27 May 2005 14:53:24 +0000 (GMT) (envelope-from groot@kde.org) Received: from solo.sci.kun.nl [131.174.16.134] (helo=localhost) by pandora.cs.kun.nl (8.12.10/5.2) with ESMTP id j4RErJkk026897; Fri, 27 May 2005 16:53:20 +0200 (MEST) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Fri, 27 May 2005 16:14:14 +0200 User-Agent: KMail/1.8 References: <20050526233707.O5798@zoraida.natserv.net> <20050527080329.GA5586@ip.net.ua> In-Reply-To: <20050527080329.GA5586@ip.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505271614.15092.groot@kde.org> X-Scanned-By: MIMEDefang 2.48 on 131.174.33.4 Cc: Subject: Re: Memory usage for 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: Fri, 27 May 2005 14:53:25 -0000 On Friday 27 May 2005 10:03, Ruslan Ermilov wrote: > On Thu, May 26, 2005 at 11:44:48PM -0400, Francisco Reyes wrote: > > A current i386 machine that I plan to replace is using less than 128MB of > > RAM out of the 256MB installed. The swap is less than 500K. The only > > processes are SSH, postfix and samba. > > > > Will an AMD64 setup be in the same memory usage range? Under 128MB. > > > > I am planning on getting 256MB anyways, but want to make sure that AMD64 > > doesn't have a bigger memory footprint for the OS and that apps don't use > > significantly more memory when compiled under AMD64. So then -- if you insist on using only a tiny memory size -- run it in i386 mode; it;ll be a fast x86 system then. -- As of September 1st, 2004, the University of Nijmegen will _still_ be the University of Nijmegen, but with a different nonsensical adjective in front. Reach me at groot@kde.org instead. GPG FEA2 A3FE From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 15:23:31 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B59F616A41C for ; Fri, 27 May 2005 15:23:31 +0000 (GMT) (envelope-from lists@natserv.com) Received: from mail1.acecape.com (mail1.acecape.com [66.114.74.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5889C43D1F for ; Fri, 27 May 2005 15:23:31 +0000 (GMT) (envelope-from lists@natserv.com) Received: from zoraida.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mail1.acecape.com (8.12.11/8.12.11) with ESMTP id j4RFNUYG022128; Fri, 27 May 2005 11:23:30 -0400 Date: Fri, 27 May 2005 11:23:29 -0400 (EDT) From: Francisco Reyes X-X-Sender: fran@zoraida.natserv.net To: Adriaan de Groot In-Reply-To: <200505271614.15092.groot@kde.org> Message-ID: <20050527112223.L12855@zoraida.natserv.net> References: <20050526233707.O5798@zoraida.natserv.net> <20050527080329.GA5586@ip.net.ua> <200505271614.15092.groot@kde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@freebsd.org Subject: Re: Memory usage for 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: Fri, 27 May 2005 15:23:31 -0000 On Fri, 27 May 2005, Adriaan de Groot wrote: >>> I am planning on getting 256MB anyways, but want to make sure that AMD64 >>> doesn't have a bigger memory footprint for the OS and that apps don't use >>> significantly more memory when compiled under AMD64. > > So then -- if you insist on using only a tiny memory size -- run it in i386 > mode; it;ll be a fast x86 system then. Based on the feedback I got AMD64 uses more memory. Increased the memory to 512MB. From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 15:29:39 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 184DB16A41F; Fri, 27 May 2005 15:29:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1D7543D48; Fri, 27 May 2005 15:29:38 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (jhb@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4RFTcuL037170; Fri, 27 May 2005 15:29:38 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4RFTW92037166; Fri, 27 May 2005 15:29:32 GMT (envelope-from jhb) Date: Fri, 27 May 2005 15:29:32 GMT From: John Baldwin Message-Id: <200505271529.j4RFTW92037166@freefall.freebsd.org> To: vivek@khera.org, jhb@FreeBSD.org, freebsd-amd64@FreeBSD.org Cc: Subject: Re: amd64/81279: /usr/games/random returns every line 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, 27 May 2005 15:29:39 -0000 Synopsis: /usr/games/random returns every line State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Fri May 27 15:29:13 GMT 2005 State-Changed-Why: Fix committed to HEAD. Will MFC after a week. http://www.freebsd.org/cgi/query-pr.cgi?pr=81279 From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 15:29:53 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B291416A41C for ; Fri, 27 May 2005 15:29:53 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7497743D1F for ; Fri, 27 May 2005 15:29:53 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24600 invoked from network); 27 May 2005 15:29:53 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender ) by mail26.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 May 2005 15:29:52 -0000 Received: from [10.50.40.212] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j4RFTeke012684; Fri, 27 May 2005 11:29:45 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-amd64@FreeBSD.org, Adriaan de Groot Date: Fri, 27 May 2005 11:26:27 -0400 User-Agent: KMail/1.8 References: <200505192130.j4JLU7wg078285@freefall.freebsd.org> In-Reply-To: <200505192130.j4JLU7wg078285@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505271126.28696.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Cc: Subject: Re: amd64/81279: /usr/games/random returns every line 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, 27 May 2005 15:29:53 -0000 On Thursday 19 May 2005 05:30 pm, Adriaan de Groot wrote: > The following reply was made to PR amd64/81279; it has been noted by GNATS. > > From: Adriaan de Groot > To: bug-followup@freebsd.org, vivek@khera.org > Cc: > Subject: Re: amd64/81279: /usr/games/random returns every line > Date: Thu, 19 May 2005 23:26:08 +0200 > > Problem is lines like > > selected = (int)(denom * random() / LONG_MAX) == 0; > > which cause the overflow. Replacing LONG_MAX with INT_MAX here fixes the > bug. (The same replacement should probably be done in the other two places > that LONG_MAX occurs, since the -e flag is similarly broken.) I can't see how the overflow happens. Oh. From the manpage: DESCRIPTION The random() function uses a non-linear additive feedback random number generator employing a default table of size 31 long integers to return successive pseudo-random numbers in the range from 0 to (2**31)-1. The period of this random number generator is very large, approximately 16*((2**31)-1). So I guess the real fix is to replace LONG_MAX with RAND_MAX? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 16:41:02 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21AD916A41C for ; Fri, 27 May 2005 16:41:02 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from amd64.molecon.ru (amd64.molecon.ru [213.219.245.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id B463343D1D for ; Fri, 27 May 2005 16:41:01 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from [194.154.84.54] (helo=[10.20.5.22]) by amd64.molecon.ru with esmtp (Exim 4.51 (FreeBSD)) id 1Dbhsu-000HgN-8P for freebsd-amd64@freebsd.org; Fri, 27 May 2005 20:40:32 +0400 Date: Fri, 27 May 2005 20:40:50 +0400 From: Oleg Rusanov X-Mailer: The Bat! (v3.0) Professional Organization: Molecon X-Priority: 3 (Normal) Message-ID: <111938140.20050527204050@molecon.ru> To: freebsd-amd64 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - amd64.molecon.ru X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - molecon.ru X-Source: X-Source-Args: X-Source-Dir: Subject: ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on !i386. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Rusanov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 16:41:02 -0000 Hello. amd64# cd /usr/ports/lang/ocaml amd64# make ===> ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on !i386. amd64# uname -a FreeBSD amd64.molecon.ru 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue May 24 20:55:37 MSD 2005 lavandas@amd64.molecon.ru:/usr/obj/usr/src/sys/L66 amd64 amd64# -- REgards, Oleg mailto:freebsd-amd64@molecon.ru From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 16:58:20 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7911416A41C for ; Fri, 27 May 2005 16:58:20 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92CDC43D49 for ; Fri, 27 May 2005 16:58:19 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 96142 invoked by uid 89); 27 May 2005 16:57:31 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 27 May 2005 16:57:31 -0000 Date: Fri, 27 May 2005 18:58:15 +0200 From: Oliver Lehmann To: Oleg Rusanov Message-Id: <20050527185815.6d5b4c80.lehmann@ans-netz.de> In-Reply-To: <111938140.20050527204050@molecon.ru> References: <111938140.20050527204050@molecon.ru> X-Mailer: Sylpheed version 1.9.11 (GTK+ 2.6.7; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on !i386. 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, 27 May 2005 16:58:20 -0000 Hi Oleg, Oleg Rusanov wrote: > Hello. > > amd64# cd /usr/ports/lang/ocaml > amd64# make > ===> ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on !i386. > > amd64# uname -a > FreeBSD amd64.molecon.ru 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue May 24 > 20:55:37 MSD 2005 lavandas@amd64.molecon.ru:/usr/obj/usr/src/sys/L66 > amd64 > amd64# What are you trying to tell us? Greetings, Oliver -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 18:16:38 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE0CF16A423 for ; Fri, 27 May 2005 18:16:38 +0000 (GMT) (envelope-from andy@athame.co.uk) Received: from hex.athame.co.uk (guru164.netsonic.fi [194.29.193.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F27A43D4C for ; Fri, 27 May 2005 18:16:37 +0000 (GMT) (envelope-from andy@athame.co.uk) Received: from ping.int.athame.co.uk ([192.168.1.8]) by hex.athame.co.uk with esmtp (Exim 4.51 (FreeBSD)) id 1DbjNo-000Ffv-UG; Fri, 27 May 2005 21:16:32 +0300 From: Andy Fawcett To: freebsd-amd64@freebsd.org Date: Fri, 27 May 2005 21:17:03 +0300 User-Agent: KMail/1.8 References: <111938140.20050527204050@molecon.ru> <20050527185815.6d5b4c80.lehmann@ans-netz.de> In-Reply-To: <20050527185815.6d5b4c80.lehmann@ans-netz.de> X-Face: ?fLK282oT!Ss!(krp%ft%TWfrkz*Mxz<2hwkRBzd); #D/=!=XjYKFBh1wVeov4K&<=?utf-8?q?Z6bi=5F=0A=09=7BBvAjk1diod2?=,DQo`Xz<\$~fX7B>U`u0HC\Gc+B9Hxu"bjBc16tg~i4.,2A1>=?utf-8?q?=7BrcRK=5Fi!i=0A=097e79f=7CT=3B9=23gfr=3DG1u=27xS=3D?=(}_NSP,Gs>HDq Cc: Subject: Re: ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on !i386. 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, 27 May 2005 18:16:39 -0000 On Friday 27 May 2005 19:58, Oliver Lehmann wrote: > Hi Oleg, > > Oleg Rusanov wrote: > > Hello. > > > > amd64# cd /usr/ports/lang/ocaml > > amd64# make > > ===> ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on > > !i386. > > > > amd64# uname -a > > FreeBSD amd64.molecon.ru 5.4-STABLE FreeBSD 5.4-STABLE #0: Tue May > > 24 20:55:37 MSD 2005 > > lavandas@amd64.molecon.ru:/usr/obj/usr/src/sys/L66 amd64 > > amd64# > > What are you trying to tell us? I was wondering the same, but this piqued my interest... So commenting out the BROKEN entry, I tried the port, and it actually compiles just fine on 5.4/amd64, with all possible makefile options tried. I've not runtime tested it (I don't know the slightest thing about ocaml) but at least for me the BROKEN seems wrong on amd64. A. -- Andy Fawcett | andy@athame.co.uk | tap@kde.org "In an open world without walls and fences, | tap@lspace.org we wouldn't need Windows and Gates." -- anon | tap@fruitsalad.org From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 18:34:35 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC38616A41C for ; Fri, 27 May 2005 18:34:35 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5C8543D1D for ; Fri, 27 May 2005 18:34:35 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4RIYZLF009458; Fri, 27 May 2005 11:34:35 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4RIYYBn009457; Fri, 27 May 2005 11:34:34 -0700 (PDT) (envelope-from obrien) Date: Fri, 27 May 2005 11:34:34 -0700 From: "David O'Brien" To: Oleg Rusanov Message-ID: <20050527183434.GA9158@dragon.NUXI.org> References: <111938140.20050527204050@molecon.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <111938140.20050527204050@molecon.ru> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64 Subject: Re: ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on !i386. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 18:34:36 -0000 On Fri, May 27, 2005 at 08:40:50PM +0400, Oleg Rusanov wrote: > Hello. > > amd64# cd /usr/ports/lang/ocaml > amd64# make > ===> ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on !i386. Not sure why Kris marked it that way. 'make WITHOUT_TK=1' built, installed, and ran (best as I could test it) for me. The ocaml README even says: Tier 1 (actively used and maintained by the core Caml team): AMD64 (Opteron) Linux Tier 2 (maintained but less actively, with help from users): AMD64 FreeBSD, OpenBSD But you should ask him directly. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 18:38:39 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 994B216A41C for ; Fri, 27 May 2005 18:38:39 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F43043D1D for ; Fri, 27 May 2005 18:38:39 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4RIcUqv009660; Fri, 27 May 2005 11:38:31 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4RIcT5W009659; Fri, 27 May 2005 11:38:29 -0700 (PDT) (envelope-from obrien) Date: Fri, 27 May 2005 11:38:29 -0700 From: "David O'Brien" To: Palle Girgensohn Message-ID: <20050527183829.GB9158@dragon.NUXI.org> References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 18:38:39 -0000 On Thu, May 26, 2005 at 01:53:45AM +0200, Palle Girgensohn wrote: > cooling, yes. You can see my previous posts for more info, but in > short, we run php apache-1.3, postgresql-8.0.3, perl-5.8.6 (amavisd), > postfix, named, clamd. httpd is very busy. > > CPUTYPE?=nocona > CFLAGS= -O -pipe > COPTFLAGS= -O -pipe I would try a system+kernel built w/o any thing in /etc/make.conf. I don't know of any issue that could be affecting you, but the data point could be useful. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 19:25:17 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DE8916A41C; Fri, 27 May 2005 19:25:17 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B25BD43D4C; Fri, 27 May 2005 19:25:16 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j4RJPgxs002271; Fri, 27 May 2005 15:25:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j4RJPEjR026701; Fri, 27 May 2005 15:25:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AFC957306E; Fri, 27 May 2005 15:25:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050527192514.AFC957306E@freebsd-current.sentex.ca> Date: Fri, 27 May 2005 15:25:14 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [releng_5 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: Fri, 27 May 2005 19:25:17 -0000 TB --- 2005-05-27 17:42:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-05-27 17:42:52 - starting RELENG_5 tinderbox run for amd64/amd64 TB --- 2005-05-27 17:42:52 - cleaning the object tree TB --- 2005-05-27 17:43:30 - checking out the source tree TB --- 2005-05-27 17:43:30 - cd /home/tinderbox/RELENG_5/amd64/amd64 TB --- 2005-05-27 17:43:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-05-27 17:52:05 - building world (CFLAGS=-O -pipe) TB --- 2005-05-27 17:52:05 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-05-27 17:52:05 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-05-27 19:07:35 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-05-27 19:07:35 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-05-27 19:07:35 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri May 27 19:07:35 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Fri May 27 19:17:30 UTC 2005 TB --- 2005-05-27 19:17:30 - generating LINT kernel config TB --- 2005-05-27 19:17:30 - cd /home/tinderbox/RELENG_5/amd64/amd64/src/sys/amd64/conf TB --- 2005-05-27 19:17:30 - /usr/bin/make -B LINT TB --- 2005-05-27 19:17:30 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2005-05-27 19:17:30 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-05-27 19:17:30 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri May 27 19:17:30 UTC 2005 >>> 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 -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_async.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_atmllc.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_base.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_bpf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_bridge.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_cisco.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_device.c /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_device.c:137: warning: 'ng_device_mod_event' defined but not used *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/obj/amd64/tinderbox/RELENG_5/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/src. TB --- 2005-05-27 19:25:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-05-27 19:25:14 - ERROR: failed to build lint kernel TB --- 2005-05-27 19:25:14 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 21:48:38 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C677E16A41C for ; Fri, 27 May 2005 21:48:38 +0000 (GMT) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75C3E43D1D for ; Fri, 27 May 2005 21:48:38 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) by smtp-gw-cl-c.dmv.com (8.12.10/8.12.10) with ESMTP id j4RLmYFU006161; Fri, 27 May 2005 17:48:36 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: Bruce Evans In-Reply-To: <1117112579.15065.30.camel@lanshark.dmv.com> References: <1117055183.13183.57.camel@lanshark.dmv.com> <20050526090743.S75084@delplex.bde.org> <1117112579.15065.30.camel@lanshark.dmv.com> Content-Type: text/plain Date: Fri, 27 May 2005 17:49:12 -0400 Message-Id: <1117230552.16920.9.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Cc: freebsd-amd64@freebsd.org Subject: Re: BKVASIZE for large block-size filesystems 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, 27 May 2005 21:48:38 -0000 On Thu, 2005-05-26 at 09:02 -0400, Sven Willenberger wrote: > On Thu, 2005-05-26 at 10:38 +1000, Bruce Evans wrote: > > On Wed, 25 May 2005, Sven Willenberger wrote: > > <> > > > > > My question is are there any caveats about increasing BKVASIZE to 65536? > > > The system has 8G of RAM and I understand that nbufs decreases with > > > increasing BKVASIZE; > > > > The decrease in nbufs is a bug. It defeats half of the point of increasing > > BKVASIZE: if most buffers have size 64K, then increasing BKVASIZE from 16K > > to 64K gives approximately nbuf/4 buffers all of size 64K instead of nbuf > > buffers, with nbuf/4 of them of size 64K and 3*nbuf/4 of them unusable. > > Thus it avoids some resource wastage at a cost of possibly not using enough > > resources for effective caching. However, little is lost if most buffers > > have size 64K. Then the reduced nbuf consumes all of the kva resources that > > we are willing to allocate. The problem is when file systems are mixed and > > ones with a block size of 64K are not used much or at all. The worst case > > is when all blocks have size 512, which can happen for msdosfs. Then up > > to (BKVASIZE - 512) / BKVASIZE of the kva resource is wasted (> 99% for > > BKVASIZE = 65536 but only 97% for BKVASIZE = 16384). > > > > To fix the bug, change BKVASIZE in kern_vfs_bio_buffer_alloc() to 16384 > > and consider adjusting the machbcache tunable (see below). > > > Alas this did not work ... I replaced BKVASIZE in that function (and only that function ) with 16384 and adjusted BKVASIZE to 65536 in sys/param.h. After make buildworld, make buildkernel, make installkernel I rebooted (attempted to into single user mode). However, after the post and the BSD splash screen (where I am prompted to choose single user) the machine gets almost nowhere into the boot process and gets as far as: Copyright (c) 1992-2005 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 5.4-STABLE #1: Sat May 14 17:37:43 EDT 2005 root@myserver:/usr/obj/usr/src/sys/NORACCT Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 248 (2190.75-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 real memory = 8589934592 (8192 MB) avail memory = 8255700992 (7873 MB) then the console completely locks up and there is no further response. Booting kernel.old does work fine and it proceeds to the next section (ACPI APIC table). > Ahh, so this is literal replace the word "BKVASIZE" in that function > with the word "16384". I am assuming that I can leave other instances of > BKVASIZE and BKVAMASK in that file (vfs_bio.c) alone then? > > > > how can I either determine if the resulting nbufs > > > will be sufficient or calculate what is needed based on RAM and system > > > usage? > > > > nbuf is not directly visible except using a debugger, but vfs.maxbufspace > > gives it indirectly -- divide the latter by BKVASIZE to get nbuf. A few > > thousand for it is plenty. > > > > I used to use BKVASIZE = 65536, and fixed the bug as above, and also doubled > > nbuf in kern_vfs_bio_buffer_alloc(), and also configured VM_BCACHE_SIZE_MAX > > to 512M so that the elevated nbuf was actually used, but the need for > > significantly increasing the default nbuf (at least with BKVASIZE = 16384) > > went away many years ago when memory sizes started exceeding 256M or so. > > My doubling of nbuf broke a few years later when memory sizes started > > exceeding 1GB. i386's just don't have enough virtual address space to use > > a really large nbuf, so when there is enough physical memory the default > > nbuf is as large as possible. I was only tuning BKVASIZE and > > VM_BCACHE_SIZE_MAX to benchmark file systems with large block sizes, but > > the performance with large block sizes was poor even with this tuning so > > I lost interest in it. Now I just use the defaults and the bug fix > > reduces to a spelling change. nbuf defeaults to about 7000 on my machines > > with 1GB of memory. This is plenty. With BKVASIZE = 64K and without the > > fix, it would be 1/4 as much, which seems a little low. > > I may have to try some of these other tricks and see what I can do .. first I need to build a regular kernel again so I can have a "safe" kernel.old after trying some further changes. Sven From owner-freebsd-amd64@FreeBSD.ORG Fri May 27 23:23:50 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E430116A41C for ; Fri, 27 May 2005 23:23:50 +0000 (GMT) (envelope-from bilbo@hobbiton.org) Received: from smaug.hobbiton.org (smaug.hobbiton.org [216.161.238.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AEB943D48 for ; Fri, 27 May 2005 23:23:50 +0000 (GMT) (envelope-from bilbo@hobbiton.org) Received: from hobbiton.org (localhost [IPv6:::1]) by smaug.hobbiton.org (8.12.9/8.12.9) with SMTP id j4RNNmEV023091; Fri, 27 May 2005 18:23:48 -0500 (CDT) Received: from 66.97.248.164 (SquirrelMail authenticated user bilbo) by hobbiton.org with HTTP; Fri, 27 May 2005 18:23:48 -0500 (CDT) Message-ID: <57540.66.97.248.164.1117236228.squirrel@hobbiton.org> In-Reply-To: <2fd864e05052018504d596da1@mail.gmail.com> References: <200505202201.j4KM17IW020782@legolas.hobbiton.org> <2fd864e05052018504d596da1@mail.gmail.com> Date: Fri, 27 May 2005 18:23:48 -0500 (CDT) From: bilbo@hobbiton.org To: "Astrodog" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/81325: KLD if_ath.ko: depends on ath_hal - not available, kldload: Unsupported file type 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, 27 May 2005 23:23:51 -0000 I guess I'm still suck with 32-bit software then. :( Thanks for the info. >> >Number: 81325 >> >Category: amd64 >> >Synopsis: KLD if_ath.ko: depends on ath_hal - not >> available, kldload: Unsupported file type >> >Confidential: no >> >Severity: serious >> >Priority: medium >> >Responsible: freebsd-amd64 >> >State: open >> >Quarter: >> >Keywords: >> >Date-Required: >> >Class: sw-bug >> >Submitter-Id: current-users >> >Arrival-Date: Fri May 20 22:10:00 GMT 2005 >> >Closed-Date: >> >Last-Modified: >> >Originator: Leif Pedersen >> >Release: FreeBSD 5.4-RELEASE amd64 >> >Organization: >> >Environment: >> System: FreeBSD legolas.hobbiton.org 5.4-RELEASE FreeBSD >> 5.4-RELEASE #0: Sun May 8 07:00:26 UTC 2005 >> root@portnoy.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> >> >> >> >Description: >> kldload if_ath fails with the following dmesgs: >> KLD if_ath.ko: depends on ath_hal - not available >> kldload: Unsupported file type >> >> The file /boot/kernel/ath_hal.ko appears to be missing on the >> amd64 port. It is present on the i386 port. > > As far as I'm aware, the AMD64 version of ath_hal for FreeBSD is > avalible only in 6-CURRENT. Perhaps someone wants to back-port it, > but > short of that, its -CURRENT, or i386, for ath support on Athlon64 > processors. > From owner-freebsd-amd64@FreeBSD.ORG Sat May 28 08:49:21 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7260916A41C for ; Sat, 28 May 2005 08:49:21 +0000 (GMT) (envelope-from charisma@schluessel24.ch) Received: from 200-160-104-147-sne.cpe.vivax.com.br (200-160-104-147-sne.cpe.vivax.com.br [200.160.104.147]) by mx1.FreeBSD.org (Postfix) with SMTP id DCCBB43D1F for ; Sat, 28 May 2005 08:49:20 +0000 (GMT) (envelope-from charisma@schluessel24.ch) Received: from [128.65.35.157] (port=4426 helo=[Karamazov]) by 200-160-104-147-sne.cpe.vivax.com.br with esmtp id 11096369889Latinizers55178 for freebsd-amd64@freebsd.org; Thu, 28 Dec 2006 04:49:08 -0300 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <3372756368.104528123750@200-160-104-147-sne.cpe.vivax.com.br> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-amd64@freebsd.org From: Helena X-Mailer: Apple Mail (2.728) Subject: GET CD AND DOWNLOADS, all software under $99-$15 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: , Date: Sat, 28 May 2005 08:49:21 -0000 X-Original-Date: Thu, 28 Dec 2006 04:49:07 -0300 X-List-Received-Date: Sat, 28 May 2005 08:49:21 -0000 Want to learn how to build your own website? http://zuk.ryvocqr261ry6a9.happycdz.com Strong reasons make strong actions. Part of being sane, is being a little bit crazy. From owner-freebsd-amd64@FreeBSD.ORG Sat May 28 09:09:33 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B121E16A41C for ; Sat, 28 May 2005 09:09:33 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from melon.pingpong.net (82.milagro.bahnhof.net [195.178.168.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FB8143D1F for ; Sat, 28 May 2005 09:09:32 +0000 (GMT) (envelope-from girgen@pingpong.net) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 7C1F94AC66; Sat, 28 May 2005 11:09:31 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28525-04-7; Sat, 28 May 2005 11:09:31 +0200 (CEST) Received: from [82.182.157.67] (1-2-8-5b.asp.sth.bostream.se [82.182.157.67]) by melon.pingpong.net (Postfix) with ESMTP id C996B4AC47; Sat, 28 May 2005 11:09:30 +0200 (CEST) In-Reply-To: <20050527183829.GB9158@dragon.NUXI.org> References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> <20050527183829.GB9158@dragon.NUXI.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1184102613a53e017f166672b1a2e5e5@pingpong.net> Content-Transfer-Encoding: 7bit From: Palle Girgensohn Date: Sat, 28 May 2005 11:09:31 +0200 To: freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at pingpong.net Cc: Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Sat, 28 May 2005 09:09:33 -0000 2005-05-27 kl. 20.38 skrev David O'Brien: > On Thu, May 26, 2005 at 01:53:45AM +0200, Palle Girgensohn wrote: >> cooling, yes. You can see my previous posts for more info, but in >> short, we run php apache-1.3, postgresql-8.0.3, perl-5.8.6 (amavisd), >> postfix, named, clamd. httpd is very busy. >> >> CPUTYPE?=nocona >> CFLAGS= -O -pipe >> COPTFLAGS= -O -pipe > > I would try a system+kernel built w/o any thing in /etc/make.conf. > I don't know of any issue that could be affecting you, but the data > point > could be useful. I'll try that next week. It's odd that the machine crashes so hard that it cannot create a core dump or even reboot. My gut feeling is that it is a hardware problem of some kind...? /Palle From owner-freebsd-amd64@FreeBSD.ORG Sat May 28 17:19:17 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC52F16A41C for ; Sat, 28 May 2005 17:19:17 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66BB343D48 for ; Sat, 28 May 2005 17:19:17 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 40D542A8F3 for ; Sat, 28 May 2005 10:19:17 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 75994E2B3 for ; Sat, 28 May 2005 10:19:16 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.3/8.13.1) with ESMTP id j4SHJFN4007531; Sat, 28 May 2005 10:19:15 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.3/8.13.1/Submit) id j4SHJFmq007530; Sat, 28 May 2005 10:19:15 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-amd64@freebsd.org, Claus Guttesen Date: Sat, 28 May 2005 10:19:14 -0700 User-Agent: KMail/1.8 References: <75f1b24e6dc7e145f7d36a874b825ab1@pingpong.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505281019.15334.peter@wemm.org> Cc: Palle Girgensohn Subject: Re: Dual Xeon EM64T crashes reliably w/ 5.x 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: Sat, 28 May 2005 17:19:18 -0000 On Thursday 26 May 2005 12:10 am, Claus Guttesen wrote: > I saw the dmesg and noticed this at the bottom: > > Interrupt storm detected on "irq18: uhci2"; throttling interrupt > source Interrupt storm detected on "irq16: uhci0"; throttling > interrupt source > > This indicates USB, if so try adding usbd_enable="NO" to > /etc/rc.conf. Yes, this is a known bug in the Intel PCI-Express chipsets. They botched the APIC interrupt masking and it causes interrupt storms to appear on the USB interrupts. The upshot is that you'll have to completely and utterly disable any usb on the system. I'm not sure if this is the cause of this poster's problem though. It certainly will not be helping though. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sat May 28 18:15:56 2005 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6E6016A41C; Sat, 28 May 2005 18:15:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 617D043D48; Sat, 28 May 2005 18:15:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j4SIGN5O039777; Sat, 28 May 2005 14:16:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j4SIFtJF027927; Sat, 28 May 2005 14:15:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 36EBC7306E; Sat, 28 May 2005 14:15:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050528181555.36EBC7306E@freebsd-current.sentex.ca> Date: Sat, 28 May 2005 14:15:55 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [releng_5 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: Sat, 28 May 2005 18:15:57 -0000 TB --- 2005-05-28 16:33:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-05-28 16:33:16 - starting RELENG_5 tinderbox run for amd64/amd64 TB --- 2005-05-28 16:33:16 - cleaning the object tree TB --- 2005-05-28 16:33:47 - checking out the source tree TB --- 2005-05-28 16:33:47 - cd /home/tinderbox/RELENG_5/amd64/amd64 TB --- 2005-05-28 16:33:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-05-28 16:42:24 - building world (CFLAGS=-O -pipe) TB --- 2005-05-28 16:42:24 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-05-28 16:42:24 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-05-28 17:58:29 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-05-28 17:58:29 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-05-28 17:58:29 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 28 17:58:30 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Sat May 28 18:08:12 UTC 2005 TB --- 2005-05-28 18:08:12 - generating LINT kernel config TB --- 2005-05-28 18:08:12 - cd /home/tinderbox/RELENG_5/amd64/amd64/src/sys/amd64/conf TB --- 2005-05-28 18:08:12 - /usr/bin/make -B LINT TB --- 2005-05-28 18:08:12 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2005-05-28 18:08:12 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-05-28 18:08:12 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 28 18:08:12 UTC 2005 >>> 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 -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_async.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_atmllc.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_base.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_bpf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_bridge.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_cisco.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/amd64/amd64/src/sys -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/altq -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/pf -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreest anding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_device.c /tinderbox/RELENG_5/amd64/amd64/src/sys/netgraph/ng_device.c:137: warning: 'ng_device_mod_event' defined but not used *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/obj/amd64/tinderbox/RELENG_5/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/src. TB --- 2005-05-28 18:15:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-05-28 18:15:55 - ERROR: failed to build lint kernel TB --- 2005-05-28 18:15:55 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Sat May 28 21:30:02 2005 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33A8A16A41C for ; Sat, 28 May 2005 21:30:02 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA94243D49 for ; Sat, 28 May 2005 21:30:01 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4SLU156086895 for ; Sat, 28 May 2005 21:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4SLU1lp086893; Sat, 28 May 2005 21:30:01 GMT (envelope-from gnats) Resent-Date: Sat, 28 May 2005 21:30:01 GMT Resent-Message-Id: <200505282130.j4SLU1lp086893@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, "Klaus-J.Wolf" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11A8A16A41C for ; Sat, 28 May 2005 21:21:12 +0000 (GMT) (envelope-from kjwolf@seismic.de) Received: from dd5114.kasserver.com (dd5114.kasserver.com [83.133.48.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6889A43D48 for ; Sat, 28 May 2005 21:21:11 +0000 (GMT) (envelope-from kjwolf@seismic.de) Received: from golulu.logelhorst.de (dsl-084-058-003-021.arcor-ip.net [84.58.3.21]) by dd5114.kasserver.com (Postfix) with ESMTP id 9EA08BFEC6 for ; Sat, 28 May 2005 23:21:08 +0200 (CEST) Received: by golulu.logelhorst.de (Postfix, from userid 1000) id 48A3828486; Sat, 28 May 2005 23:21:01 +0200 (CEST) Message-Id: <20050528212101.48A3828486@golulu.logelhorst.de> Date: Sat, 28 May 2005 23:21:01 +0200 (CEST) From: "Klaus-J.Wolf" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: amd64/81602: SATA crashes with parallel pcm access 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: Sat, 28 May 2005 21:30:02 -0000 >Number: 81602 >Category: amd64 >Synopsis: SATA crashes with parallel pcm access >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat May 28 21:30:01 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Klaus-J. Wolf >Release: FreeBSD 5.4-RELEASE amd64 >Organization: >Environment: System: FreeBSD daywalker.logelhorst.xy 5.4-RELEASE FreeBSD 5.4-RELEASE #4: Sat May 28 23:07:33 CEST 2005 root@:/usr/src/sys/amd64/compile/DAYWALKER amd64 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1802.31-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 Features=0x78bfbff AMD Features=0xe2500800,LM,3DNow+,3DNow> real memory = 1073414144 (1023 MB) avail memory = 1026969600 (979 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) atapci0: port 0x9800-0x987f,0xa000-0xa00f, 0xa400-0xa43f mem 0xfa700000-0xfa71ffff,0xfa800000-0xfa800fff irq 18 at device 8 .0 on pci0 atapci0: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 ata4: channel #2 on atapci0 ... pcm0: port 0xb400-0xb4ff irq 19 at device 14.0 on pci0 atapci1: port 0xb800-0xb8ff,0xc000-0xc00f,0xc400-0 xc403,0xc800-0xc807,0xd000-0xd003,0xd400-0xd407 irq 20 at device 15.0 on pci0 ata5: channel #0 on atapci1 ata6: channel #1 on atapci1 atapci2: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f 6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci2 ata1: channel #1 on atapci2 ... ad4: 239372MB [486344/16/63] at ata2-master SATA150 ad6: 239372MB [486344/16/63] at ata3-master SATA150 >Description: A few accesses to the sound device are sufficient to make the system stall. This often happens after boot, when someone logs into KDE and the welcome melody is played. In a simulated environment, the following messages could be read on the console: ad4: TIMEOUT - READ_DMA retrying (2 tries left) LBA=369695071 ad4: FAILURE - ATA_IDENTIFY timed out ad4: FAILURE - ATA_IDENTIFY timed out ad4: WARNING - removed from configuration ata2-master: FAILURE - READ_DMA timed out >How-To-Repeat: Combine vivid disk access (e.g. find /) with some sound output (e.g. ogg123 /somewhere/*.ogg). >Fix: n/a >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Sat May 28 21:48:05 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 888FA16A41C for ; Sat, 28 May 2005 21:48:05 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D5C443D1D for ; Sat, 28 May 2005 21:48:05 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5326452640; Sat, 28 May 2005 14:48:04 -0700 (PDT) Date: Sat, 28 May 2005 14:48:04 -0700 From: Kris Kennaway To: freebsd-amd64@freebsd.org Message-ID: <20050528214804.GA71033@xor.obsecurity.org> References: <111938140.20050527204050@molecon.ru> <20050527183434.GA9158@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20050527183434.GA9158@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: ocaml-nox11-3.08.3_1 is marked as broken: Does not compile on !i386. 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: Sat, 28 May 2005 21:48:05 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2005 at 11:34:34AM -0700, David O'Brien wrote: > On Fri, May 27, 2005 at 08:40:50PM +0400, Oleg Rusanov wrote: > > Hello. > >=20 > > amd64# cd /usr/ports/lang/ocaml > > amd64# make > > =3D=3D=3D> ocaml-nox11-3.08.3_1 is marked as broken: Does not compile = on !i386. >=20 > Not sure why Kris marked it that way. 'make WITHOUT_TK=3D1' built, > installed, and ran (best as I could test it) for me. The ocaml README > even says: >=20 > Tier 1 (actively used and maintained by the core Caml team): > AMD64 (Opteron) Linux > Tier 2 (maintained but less actively, with help from users): > AMD64 FreeBSD, OpenBSD >=20 > But you should ask him directly. See pointyhat.freebsd.org kris --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCmOcTWry0BWjoQKURAnt4AJ0TV3JtoHgWMzxiwQCJymzxHrRCCwCbBzL1 7aE7AxWmT7220cU5G+EExRU= =CefQ -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/--