From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 20 05:13:22 2005 Return-Path: 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 8A9DF16A4CE for ; Sun, 20 Feb 2005 05:13:22 +0000 (GMT) Received: from tibor.swiftdsl.com.au (tibor.swiftdsl.com.au [202.154.92.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44C6143D48 for ; Sun, 20 Feb 2005 05:13:21 +0000 (GMT) (envelope-from mv@roq.com) Received: (qmail 24169 invoked from network); 20 Feb 2005 05:18:26 -0000 Received: from unknown (HELO [10.0.0.55]) ([218.214.143.85]) (envelope-sender ) by tibor.swiftdsl.com.au (qmail-ldap-1.03) with SMTP for ; 20 Feb 2005 05:18:26 -0000 Message-ID: <42181C6E.4040305@roq.com> Date: Sun, 20 Feb 2005 16:13:18 +1100 From: Michael Vince User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: virek References: <20041207222242.51423.qmail@webmail.thai.com> In-Reply-To: <20041207222242.51423.qmail@webmail.thai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-amd64@freebsd.org Subject: Re: asus a2000k ? 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, 20 Feb 2005 05:13:22 -0000 Yeah I just bought the A4000K Which appears to be almost exactly the same but with larger 15.4 screen, AMD64 mobile laptop right? http://www.asus.com/products4.aspx?l1=5&l2=25&l3=130&model=18&modelmenu=1 http://www.asus.com/products4.aspx?l1=5&l2=24&l3=133&model=346&modelmenu=1 The only obvious difference I see is mine is a "ATI Mobility™ Radeon™ 9700" while the A2000K is a " ATI Mobility™ Radeon™ 9700 PRO" The sk ethernet didn't come up on 5.3release ISO until I installed the 5.x stable snapshot ISO. http://lists.freebsd.org/pipermail/freebsd-current/2005-February/046535.html It worked fine all night doing a big portupgrade install of xorg kde etc, the sk0 watchdog timing started when trying to download the Linux Java 1.4 stuff to it for a native java compile, but it almost appeared that it just didn't like that big file, after a few reboots it downloaded successfully. Also my wireless device has come up, while I don't plan to use anyway. Running xorgcfg did load up a nice basic xwindow (and working usb mouse) without a problem, but I haven't setup my full environment yet, will when my Java etc is done. FYI I am using i386 instead of amd64 FreeBSD simply because there are to many "ONLY_FOR_ARCHS = i386" ports that I need right now. I did first boot from the AMD64 5.3release ISO and it booted up fine if you choose "3" for safe mode else it will sit there when its about to mount the hard drive? and the sk0 device didn't come up either in amd64 release The only real gripes I have with this laptop is the fan noise is quite load for a laptop when the machine is busy compiling stuff, its fan is quiet when its not busy most of the time, and its also not as thin as I would like it to be.. maybe the A2000k is thiner? Cheers, Michael virek wrote: > Hello. > Anyone been able to try 5.3 on the Asus A2000K? > thanks.. > > be yourself@thai.com! > Shop all amazing products and get our special offers! > _______________________________________________ > 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 Feb 20 07:40:58 2005 Return-Path: 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 1CB4016A4CE; Sun, 20 Feb 2005 07:40:58 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90FBE43D31; Sun, 20 Feb 2005 07:40:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j1K7euZp053736; Sun, 20 Feb 2005 02:40:56 -0500 (EST) (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.1/8.13.1) with ESMTP id j1K7etY0062267; Sun, 20 Feb 2005 02:40:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 68A197306E; Sun, 20 Feb 2005 02:40:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050220074055.68A197306E@freebsd-current.sentex.ca> Date: Sun, 20 Feb 2005 02:40:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.82/714/Sat Feb 19 23:45:08 2005 on smarthost2.sentex.ca X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner1 X-Virus-Status: Clean Subject: [releng_5 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2005 07:40:58 -0000 TB --- 2005-02-20 06:21:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-20 06:21:36 - starting RELENG_5 tinderbox run for amd64/amd64 TB --- 2005-02-20 06:21:36 - checking out the source tree TB --- 2005-02-20 06:21:36 - cd /home/tinderbox/RELENG_5/amd64/amd64 TB --- 2005-02-20 06:21:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-02-20 06:39:08 - building world (CFLAGS=-O -pipe) TB --- 2005-02-20 06:39:08 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-02-20 06:39:08 - /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 TB --- 2005-02-20 07:36:39 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-02-20 07:36:39 - cd /home/tinderbox/RELENG_5/amd64/amd64/src TB --- 2005-02-20 07:36:39 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Feb 20 07:36:40 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 -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_mib.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 -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_module.c /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_module.c:441: warning: "struct freebsd32_modstat_args" declared inside parameter list /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_module.c:441: warning: its scope is only this definition or declaration, which is probably not what you want /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_module.c:442: warning: no previous prototype for 'freebsd32_modstat' /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_module.c: In function `freebsd32_modstat': /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_module.c:451: error: dereferencing pointer to incomplete type /tinderbox/RELENG_5/amd64/amd64/src/sys/kern/kern_module.c:465: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/obj/amd64/tinderbox/RELENG_5/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/amd64/amd64/src. TB --- 2005-02-20 07:40:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-20 07:40:55 - ERROR: failed to build generic kernel TB --- 2005-02-20 07:40:55 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 20 09:14:15 2005 Return-Path: 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 94AC816A4CE; Sun, 20 Feb 2005 09:14:15 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E699443D45; Sun, 20 Feb 2005 09:14:14 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j1K9EDHn005479; Sun, 20 Feb 2005 20:14:13 +1100 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j1K9E9Mq001438; Sun, 20 Feb 2005 20:14:11 +1100 Date: Sun, 20 Feb 2005 20:14:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Alexander Leidinger In-Reply-To: <20050219214719.2b4c8c59@Magellan.Leidinger.net> Message-ID: <20050220190416.H4624@epsplex.bde.org> References: <41F62EE7.6070808@fsn.hu> <20050216110434.rmi718fcw0o44sgs@netchild.homeip.net> <421337C2.7040800@fsn.hu> <200502171411.15827.peter@wemm.org> <20050219214719.2b4c8c59@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: amd64@FreeBSD.org cc: freebsd-amd64@FreeBSD.org Subject: Re: kernel message while running icc-em64t 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, 20 Feb 2005 09:14:15 -0000 On Sat, 19 Feb 2005, Alexander Leidinger wrote: > On Thu, 17 Feb 2005 14:11:15 -0800 > Peter Wemm wrote: > > > > >> fpudna: fpcurthread == curthread 2342 times > > > >> fpudna: fpcurthread == curthread 2343 times > > > If I had to guess, I'd guess that it is trying to issue SSE3 > > instructions to see if they work.. Does SSE3 cause DNA traps that are not associated with the FPU and/or not cleared by calling stop_emulating()? > I think the question is: Does this needs to get printed and if yes, > does the information it represents has to be that cryptic? This needs to panic like it used to, and the broken invariant reported by the panic needs to be fixed instead of mishandled. The panic was broken in rev.1.131 of npx.c. I use the following fix for the non-panic and for some nearby style (-only?) bugs: %%% Index: npx.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v retrieving revision 1.152 diff -u -2 -r1.152 npx.c --- npx.c 19 Jun 2004 22:24:16 -0000 1.152 +++ npx.c 20 Feb 2005 07:49:45 -0000 @@ -764,7 +764,4 @@ * access foreign pcb's. */ - -static int err_count = 0; - int npxdna() @@ -776,18 +773,8 @@ if (!npx_exists) return (0); - if (PCPU_GET(fpcurthread) == curthread) { - printf("npxdna: fpcurthread == curthread %d times\n", - ++err_count); - stop_emulating(); - return (1); - } - if (PCPU_GET(fpcurthread) != NULL) { - printf("npxdna: fpcurthread = %p (%d), curthread = %p (%d)\n", - PCPU_GET(fpcurthread), - PCPU_GET(fpcurthread)->td_proc->p_pid, - curthread, curthread->td_proc->p_pid); - panic("npxdna"); - } s = intr_disable(); + if (PCPU_GET(fpcurthread) != NULL) + panic("npxdna: fpcurthread = %p, curthread = %p", + (void *)PCPU_GET(fpcurthread), (void *)curthread); stop_emulating(); /* %%% The changes here are: - back out the bogus code related to this bug in rev.1.131, so that there is a panic again and not too much code for (mis)handing a case that can't happen. - move the invariant check inside the critical region. I think it was OK, but this depends on the delicate point that interrupts can only change fpcurthread from non-null to null, and since we are asserting that fpcurthread is null, it shouldn't change underneath us. See rev.1.90 for the addition of the critical region. - catch up with 4.4BSD and use panic()'s support for variadic args - don't invoke undefined behaviour by printing non-`void *'s using %p - use KNF continuation indent of 4 (npx.c gets this wrong in several places since I didn't know the rule when I wrote most of npx.c). Bruce From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 20 09:14:15 2005 Return-Path: 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 94AC816A4CE; Sun, 20 Feb 2005 09:14:15 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E699443D45; Sun, 20 Feb 2005 09:14:14 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j1K9EDHn005479; Sun, 20 Feb 2005 20:14:13 +1100 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j1K9E9Mq001438; Sun, 20 Feb 2005 20:14:11 +1100 Date: Sun, 20 Feb 2005 20:14:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Alexander Leidinger In-Reply-To: <20050219214719.2b4c8c59@Magellan.Leidinger.net> Message-ID: <20050220190416.H4624@epsplex.bde.org> References: <41F62EE7.6070808@fsn.hu> <20050216110434.rmi718fcw0o44sgs@netchild.homeip.net> <421337C2.7040800@fsn.hu> <200502171411.15827.peter@wemm.org> <20050219214719.2b4c8c59@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: amd64@FreeBSD.org cc: freebsd-amd64@FreeBSD.org Subject: Re: kernel message while running icc-em64t 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, 20 Feb 2005 09:14:15 -0000 On Sat, 19 Feb 2005, Alexander Leidinger wrote: > On Thu, 17 Feb 2005 14:11:15 -0800 > Peter Wemm wrote: > > > > >> fpudna: fpcurthread == curthread 2342 times > > > >> fpudna: fpcurthread == curthread 2343 times > > > If I had to guess, I'd guess that it is trying to issue SSE3 > > instructions to see if they work.. Does SSE3 cause DNA traps that are not associated with the FPU and/or not cleared by calling stop_emulating()? > I think the question is: Does this needs to get printed and if yes, > does the information it represents has to be that cryptic? This needs to panic like it used to, and the broken invariant reported by the panic needs to be fixed instead of mishandled. The panic was broken in rev.1.131 of npx.c. I use the following fix for the non-panic and for some nearby style (-only?) bugs: %%% Index: npx.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v retrieving revision 1.152 diff -u -2 -r1.152 npx.c --- npx.c 19 Jun 2004 22:24:16 -0000 1.152 +++ npx.c 20 Feb 2005 07:49:45 -0000 @@ -764,7 +764,4 @@ * access foreign pcb's. */ - -static int err_count = 0; - int npxdna() @@ -776,18 +773,8 @@ if (!npx_exists) return (0); - if (PCPU_GET(fpcurthread) == curthread) { - printf("npxdna: fpcurthread == curthread %d times\n", - ++err_count); - stop_emulating(); - return (1); - } - if (PCPU_GET(fpcurthread) != NULL) { - printf("npxdna: fpcurthread = %p (%d), curthread = %p (%d)\n", - PCPU_GET(fpcurthread), - PCPU_GET(fpcurthread)->td_proc->p_pid, - curthread, curthread->td_proc->p_pid); - panic("npxdna"); - } s = intr_disable(); + if (PCPU_GET(fpcurthread) != NULL) + panic("npxdna: fpcurthread = %p, curthread = %p", + (void *)PCPU_GET(fpcurthread), (void *)curthread); stop_emulating(); /* %%% The changes here are: - back out the bogus code related to this bug in rev.1.131, so that there is a panic again and not too much code for (mis)handing a case that can't happen. - move the invariant check inside the critical region. I think it was OK, but this depends on the delicate point that interrupts can only change fpcurthread from non-null to null, and since we are asserting that fpcurthread is null, it shouldn't change underneath us. See rev.1.90 for the addition of the critical region. - catch up with 4.4BSD and use panic()'s support for variadic args - don't invoke undefined behaviour by printing non-`void *'s using %p - use KNF continuation indent of 4 (npx.c gets this wrong in several places since I didn't know the rule when I wrote most of npx.c). Bruce From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 20 12:45:20 2005 Return-Path: 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 B5E5116A4CF for ; Sun, 20 Feb 2005 12:45:20 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57B1343D2D for ; Sun, 20 Feb 2005 12:45:20 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so692227wra for ; Sun, 20 Feb 2005 04:45:19 -0800 (PST) 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:references; b=hTtaC4pOr+v87kgVJq0J4XBF/rqiey8qaMrrrZt+nreR5/EdlB2pSQXTVvd9Qvqt81ACchPolk0zqVgJRbeTezsgsEyQaXklMMG+epA5XrtXnUPhZExlO7bO8aJmqLPLnjKNbc/9lV3Z6T4ob3wf4u0HESmAnaoCzItDX2o/j4w= Received: by 10.54.51.55 with SMTP id y55mr49629wry; Sun, 20 Feb 2005 04:45:19 -0800 (PST) Received: by 10.54.40.69 with HTTP; Sun, 20 Feb 2005 04:45:19 -0800 (PST) Message-ID: <2fd864e050220044564260f57@mail.gmail.com> Date: Sun, 20 Feb 2005 04:45:19 -0800 From: Astrodog To: Vinod Kashyap In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: cc: freebsd-amd64@freebsd.org Subject: Re: CLI and 3DM2 for amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 20 Feb 2005 12:45:20 -0000 Original Message----- > > > From: owner-freebsd-amd64@freebsd.org > > > [mailto:owner-freebsd-amd64@freebsd.org] On Behalf Of Vinod Kashyap > > > Sent: 17 February 2005 19:04 > > > To: freebsd-amd64@freebsd.org > > > Subject: CLI and 3DM2 for amd64 > > > > > > > > > CLI and 3DM2, the management tools for 3ware's 7xxx/8xxx and > > > 9xxx controllers are now available for FreeBSD amd64, here: > > > http://www.3ware.com/support/downloadnew.asp > > > > > > Please note that these are not official releases, and have not gone > > > through exhaustive testing. However, they are expected to work > > > satisfactorily. Please report any problems to 3ware support. > > > > > > > > > Thanks, > > > > > > Vinod. > > > > > > > > > _______________________________________________ > > > 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" > > > Figured I'd let you know, the client works great on Tyan S2850, and S2882-based machines with 7506-4LP cards. Thanks! --- Harrison Grundy From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 20 13:48:24 2005 Return-Path: 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 AA55016A4CE for ; Sun, 20 Feb 2005 13:48:24 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE35E43D4C for ; Sun, 20 Feb 2005 13:48:21 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so149252rnf for ; Sun, 20 Feb 2005 05:48:21 -0800 (PST) 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:references; b=bc0q/TuIP3WEvY1AWkxChqXC0vFmmMiSNrZVKlr2WDj02gLJOUacPjGh+jcs15EtpAnU4MAKHgaQhQufgnpEZ5Xzd1h5z7RqmNzGzbAa9u3V3JmKIvDMeljX/1i1N/DJDNG64YejLDDEdQddAdxPZGQ6FhI9OxpzynAZe/BHOZc= Received: by 10.38.66.40 with SMTP id o40mr23734rna; Sun, 20 Feb 2005 05:48:20 -0800 (PST) Received: by 10.38.208.52 with HTTP; Sun, 20 Feb 2005 05:48:20 -0800 (PST) Message-ID: <28edec3c05022005482799e795@mail.gmail.com> Date: Sun, 20 Feb 2005 21:48:20 +0800 From: "Mars G. Miro" To: Ruslan Ermilov In-Reply-To: <20050218163705.GD50352@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <28edec3c0502180441444a4af@mail.gmail.com> <20050218163705.GD50352@ip.net.ua> cc: freebsd-amd64@freebsd.org Subject: Re: NOFOO->NO_FOO changes breaks installworld to 5.3p5 in RELENG_5_3 in FreeBSD/AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 20 Feb 2005 13:48:24 -0000 On Fri, 18 Feb 2005 18:37:05 +0200, Ruslan Ermilov wrote: > On Fri, Feb 18, 2005 at 08:41:18PM +0800, Mars G. Miro wrote: > > At: > > > > ===> gnu/usr.bin/groff/font/devX100 > > Segmentation fault (core dumped) > > *** Error code 139 > > > What's dumping core here, make(1)? > yep ;-) > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > > > cheers mars From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 20 13:56:01 2005 Return-Path: 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 68E8A16A4CE for ; Sun, 20 Feb 2005 13:56:01 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE9EE43D4C for ; Sun, 20 Feb 2005 13:56:00 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 138E1530C; Sun, 20 Feb 2005 14:55:58 +0100 (CET) Received: from xps.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 94B375308 for ; Sun, 20 Feb 2005 14:55:21 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id 2C97233C3E; Sun, 20 Feb 2005 14:55:21 +0100 (CET) To: amd64@freebsd.org From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sun, 20 Feb 2005 14:55:21 +0100 Message-ID: <86y8dje3p2.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 Subject: VM panics 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, 20 Feb 2005 13:56:01 -0000 With recent -CURRENT, I get recurrent VM panics on amd64: panic: mutex vm object not owned at /usr/src/sys/vm/vm_page.c:608 which corresponds to the following code at the beginning of in vm_page_remove(): 605: mtx_assert(&vm_page_queue_mtx, MA_OWNED); 606: if ((object =3D m->object) =3D=3D NULL) 607: return; 608: VM_OBJECT_LOCK_ASSERT(object, MA_OWNED); 609: if (m->flags & PG_BUSY) { 610: vm_page_flag_clear(m, PG_BUSY); 611: vm_page_flash(m); This only happens under load (e.g. buildworld). Serial console does not work properly ("sio0: configured irq 3 not in bitmap of probed irqs 0"), and I don't currently have a firewire cable. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 20 21:43:28 2005 Return-Path: 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 4674716A4CE for ; Sun, 20 Feb 2005 21:43:28 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE30343D1F for ; Sun, 20 Feb 2005 21:43:27 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.3/8.13.1) with ESMTP id j1KLhI9M001024; Sun, 20 Feb 2005 13:43:18 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.3/8.13.1/Submit) id j1KLhHbH001023; Sun, 20 Feb 2005 13:43:17 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86y8dje3p2.fsf@xps.des.no> References: <86y8dje3p2.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Feb 2005 13:43:17 -0800 Message-Id: <1108935797.944.8.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: amd64@freebsd.org Subject: Re: VM panics 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, 20 Feb 2005 21:43:28 -0000 On Sun, 2005-02-20 at 14:55 +0100, Dag-Erling Sm=F8rgrav wrote: > With recent -CURRENT, I get recurrent VM panics on amd64: >=20 > panic: mutex vm object not owned at /usr/src/sys/vm/vm_page.c:608 >=20 > which corresponds to the following code at the beginning of in > vm_page_remove(): >=20 > 605: mtx_assert(&vm_page_queue_mtx, MA_OWNED); > 606: if ((object =3D m->object) =3D=3D NULL) > 607: return; > 608: VM_OBJECT_LOCK_ASSERT(object, MA_OWNED); > 609: if (m->flags & PG_BUSY) { > 610: vm_page_flag_clear(m, PG_BUSY); > 611: vm_page_flash(m); >=20 > This only happens under load (e.g. buildworld). >=20 > Serial console does not work properly ("sio0: configured irq 3 not in > bitmap of probed irqs 0"), and I don't currently have a firewire > cable. Same for me, and it takes very little to trigger -- savecore of my first dump reproduced it twice. Backtrace (copied from digicam due to broken kgdb): panic() _mtx_assert() vm_page_remove() vm_page_free_toq() vm_page_free() uma_small_free() zone_drain() zone_foreach() uma_reclaim() vm_pageout() fork_exit() fork_trampoline) --=20 Eric Anholt eta@lclark.edu =20 http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 21 03:02:31 2005 Return-Path: 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 F1B0A16A4CE for ; Mon, 21 Feb 2005 03:02:30 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56F4D43D45 for ; Mon, 21 Feb 2005 03:02:30 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 5B813F138; Sun, 20 Feb 2005 22:02:29 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id D117A6A45; Sun, 20 Feb 2005 22:02:26 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16921.20290.33143.373069@canoe.dclg.ca> Date: Mon, 21 Feb 2005 03:02:26 +0000 To: amd64@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: Status of java on amd64? 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: Mon, 21 Feb 2005 03:02:31 -0000 I've got a couple of AMD 64 hosts ... and they refuse to compile the java ports. I find myself needing 1.5 and the 1.5 ia32 code is segfulting on java -version. The amd64 compile of jdk15 is also non functional. ia32 linux java appears to run, but so far, only in the jdk14 version. Has someone an native amd64 jdk15 binary? Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 21 04:44:37 2005 Return-Path: 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 6768A16A4CE for ; Mon, 21 Feb 2005 04:44:37 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1BA243D3F for ; Mon, 21 Feb 2005 04:44:36 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so213108rng for ; Sun, 20 Feb 2005 20:44:36 -0800 (PST) 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:references; b=OvrSNAQIdVwsvad6L9ATyuubUNh/Fih8X0B1qij6wxDN/pndTtfzYtjmhG3dCEFd9oHwJvC38tL+FUnAT0BIxnVgQrw2fl8D9cVNhROP5C7bwhclrbsZBViDerqg4rNcQiaEObqN1MVwsb9gxav8S+K1Inl/mBlkK5yTkPq550I= Received: by 10.38.22.16 with SMTP id 16mr454412rnv; Sun, 20 Feb 2005 20:44:36 -0800 (PST) Received: by 10.38.22.22 with HTTP; Sun, 20 Feb 2005 20:44:36 -0800 (PST) Message-ID: <346a802205022020441b38e756@mail.gmail.com> Date: Sun, 20 Feb 2005 23:44:36 -0500 From: Coleman Kane To: David Gilbert In-Reply-To: <16921.20290.33143.373069@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16921.20290.33143.373069@canoe.dclg.ca> cc: amd64@freebsd.org Subject: Re: Status of java on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cokane@cokane.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 04:44:37 -0000 I was able to build it on -CURRENT on Feb 16th. A friend of mine got it built under -STABLE earlier that week. My build went by without issue. His -STABLE build had a long string of problems which needed patching. You may want to search for it in the archives. -- coleman On Mon, 21 Feb 2005 03:02:26 +0000, David Gilbert wrote: > I've got a couple of AMD 64 hosts ... and they refuse to compile the > java ports. I find myself needing 1.5 and the 1.5 ia32 code is > segfulting on java -version. The amd64 compile of jdk15 is also non > functional. > > ia32 linux java appears to run, but so far, only in the jdk14 > version. > > Has someone an native amd64 jdk15 binary? > > Dave. > > -- > ============================================================================ > |David Gilbert, Independent Contractor. | Two things can only be | > |Mail: dave@daveg.ca | equal if and only if they | > |http://daveg.ca | are precisely opposite. | > =========================================================GLO================ > _______________________________________________ > 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 Mon Feb 21 11:01:46 2005 Return-Path: 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 6614E16A4DF for ; Mon, 21 Feb 2005 11:01:46 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E22643D46 for ; Mon, 21 Feb 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.1/8.13.1) with ESMTP id j1LB1jnU034264 for ; Mon, 21 Feb 2005 11:01:45 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1LB1imk034258 for freebsd-amd64@freebsd.org; Mon, 21 Feb 2005 11:01:44 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 21 Feb 2005 11:01:44 GMT Message-Id: <200502211101.j1LB1imk034258@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 Subject: Current problem reports assigned to you 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: Mon, 21 Feb 2005 11:01:46 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/27] amd64/73211 amd64 FAST_IPSEC broken on amd64 o [2005/02/17] amd64/77629 amd64 aMule hardlocks AMD64 system 2 problems 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 17 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/25] amd64/75488 amd64 ntfs_iconv not working on amd64 o [2005/02/13] amd64/77470 amd64 Using of cyrillic filenames conversion le 9 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 21 18:01:38 2005 Return-Path: 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 C20A816A4CE for ; Mon, 21 Feb 2005 18:01:38 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51D1843D31 for ; Mon, 21 Feb 2005 18:01:38 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id j1LI1TH4048090; Mon, 21 Feb 2005 10:01:30 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id j1LI1S3Z048089; Mon, 21 Feb 2005 10:01:28 -0800 (PST) (envelope-from obrien) Date: Mon, 21 Feb 2005 10:01:28 -0800 From: "David O'Brien" To: David Gilbert Message-ID: <20050221180128.GA47957@dragon.nuxi.com> References: <16921.20290.33143.373069@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16921.20290.33143.373069@canoe.dclg.ca> 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.8i cc: freebsd-amd64@freebsd.org Subject: Re: Status of java on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 21 Feb 2005 18:01:38 -0000 On Mon, Feb 21, 2005 at 03:02:26AM +0000, David Gilbert wrote: > I've got a couple of AMD 64 hosts ... and they refuse to compile the > java ports. I find myself needing 1.5 and the 1.5 ia32 code is > segfulting on java -version. The amd64 compile of jdk15 is also non > functional. ... > Has someone an native amd64 jdk15 binary? This is an FAQ -- please search this mailing list's archives. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 21 21:06:41 2005 Return-Path: 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 41FB616A4D0 for ; Mon, 21 Feb 2005 21:06:41 +0000 (GMT) Received: from ybbsmtp06.mail.mci.yahoo.co.jp (ybbsmtp06.mail.mci.yahoo.co.jp [210.80.241.155]) by mx1.FreeBSD.org (Postfix) with SMTP id E7DE043D5A for ; Mon, 21 Feb 2005 21:06:39 +0000 (GMT) (envelope-from takeharu1219@ybb.ne.jp) Received: from unknown (HELO ?192.168.1.14?) (takeharu1219@219.35.170.20 with plain) by ybbsmtp06.mail.mci.yahoo.co.jp with SMTP; 21 Feb 2005 21:06:38 -0000 X-Apparently-From: Message-ID: <421A4D5D.6040205@ybb.ne.jp> Date: Tue, 22 Feb 2005 06:06:37 +0900 From: Takeharu KATO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-amd64@FreeBSD.org Content-Type: multipart/mixed; boundary="------------030802060005060601090600" cc: takeharu1219@ybb.ne.jp cc: nork@FreeBSD.org Subject: AMD64 Local APIC Timer 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: Mon, 21 Feb 2005 21:06:41 -0000 This is a multi-part message in MIME format. --------------030802060005060601090600 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi I ported the local APIC timer tick feature to AMD64. Please take a look on this patch. Regards, -- Takeharu KATO --------------030802060005060601090600 Content-Type: text/plain; name="amd64-lapic-timer.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="amd64-lapic-timer.patch" SW5kZXg6IGFtZDY0L2FtZDY0L2FwaWNfdmVjdG9yLlMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmls ZTogL2hvbWUva2F0by9jdnMva2F0by1zeXMvYW1kNjQvYW1kNjQvYXBpY192ZWN0b3IuUyx2 CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMgpk aWZmIC11IC1yMS4xLjEuMSAtcjEuMgotLS0gYW1kNjQvYW1kNjQvYXBpY192ZWN0b3IuUwkx OCBGZWIgMjAwNSAxNDowNTo1NSAtMDAwMAkxLjEuMS4xCisrKyBhbWQ2NC9hbWQ2NC9hcGlj X3ZlY3Rvci5TCTIwIEZlYiAyMDA1IDE4OjE1OjI5IC0wMDAwCTEuMgpAQCAtMTM3LDYgKzEz NywyNiBAQAogCUlTUl9WRUMoNiwgYXBpY19pc3I2KQogCUlTUl9WRUMoNywgYXBpY19pc3I3 KQogCisvKgorICogTG9jYWwgQVBJQyBwZXJpb2RpYyB0aW1lciBoYW5kbGVyLgorICovCisJ LnRleHQKKwlTVVBFUkFMSUdOX1RFWFQKK0lEVFZFQyh0aW1lcmludCkKKwlQVVNIX0ZSQU1F CisKKwltb3ZxCWxhcGljLCAlcmR4CisJbW92bAkkMCwgTEFfRU9JKCVyZHgpCS8qIEVuZCBP ZiBJbnRlcnJ1cHQgdG8gQVBJQyAqLworCQorCUZBS0VfTUNPVU5UKFRGX1JJUCglcnNwKSkK KworCisJcHVzaHEJJDAJCS8qIFhYWCBjb252ZXJ0IHRyYXBmcmFtZSB0byBjbG9ja2ZyYW1l ICovCisJY2FsbAlsYXBpY19oYW5kbGVfdGltZXIKKwlhZGRxCSQ4LCAlcnNwCS8qIFhYWCBj b252ZXJ0IGNsb2NrZnJhbWUgdG8gdHJhcGZyYW1lICovCisJTUVYSVRDT1VOVAorCWptcAlk b3JldGkKKwogI2lmZGVmIFNNUAogLyoKICAqIEdsb2JhbCBhZGRyZXNzIHNwYWNlIFRMQiBz aG9vdGRvd24uCkluZGV4OiBhbWQ2NC9hbWQ2NC9sb2NhbF9hcGljLmMKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQpSQ1MgZmlsZTogL2hvbWUva2F0by9jdnMva2F0by1zeXMvYW1kNjQvYW1kNjQvbG9jYWxf YXBpYy5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEuMS4xCmRpZmYgLXUgLXIxLjEuMS4x IGxvY2FsX2FwaWMuYwotLS0gYW1kNjQvYW1kNjQvbG9jYWxfYXBpYy5jCTE4IEZlYiAyMDA1 IDE0OjA1OjU1IC0wMDAwCTEuMS4xLjEKKysrIGFtZDY0L2FtZDY0L2xvY2FsX2FwaWMuYwky MCBGZWIgMjAwNSAxOTo0MzowNiAtMDAwMApAQCAtMSw0ICsxLDYgQEAKIC8qLQorICogQ29w eXJpZ2h0IChjKSAyMDA1IFRha2VoYXJ1IEtBVE88dGFrZWhhcnUxMjE5QHliYi5uZS5qcD4K KyAqICAgICAgICAgICAgICAgICAgICAoQWRkIExBUElDIHRpbWVyIHN1cHBvcnQpLgogICog Q29weXJpZ2h0IChjKSAyMDAzIEpvaG4gQmFsZHdpbiA8amhiQEZyZWVCU0Qub3JnPgogICog Q29weXJpZ2h0IChjKSAxOTk2LCBieSBTdGV2ZSBQYXNzZQogICogQWxsIHJpZ2h0cyByZXNl cnZlZC4KQEAgLTY2LDYgKzY4LDkgQEAKIENUQVNTRVJUKEFQSUNfTE9DQUxfSU5UUyA9PSAy NDApOwogQ1RBU1NFUlQoSVBJX1NUT1AgPCBBUElDX1NQVVJJT1VTX0lOVCk7CiAKKyNkZWZp bmUJTEFQSUNfVElNRVJfU1RBVEhaCTEyOAorI2RlZmluZQlMQVBJQ19USU1FUl9QUk9GSFoJ MTAyNAorCiAvKgogICogU3VwcG9ydCBmb3IgbG9jYWwgQVBJQ3MuICBMb2NhbCBBUElDcyBt YW5hZ2UgaW50ZXJydXB0cyBvbiBlYWNoCiAgKiBpbmRpdmlkdWFsIHByb2Nlc3NvciBhcyBv cHBvc2VkIHRvIEkvTyBBUElDcyB3aGljaCByZWNlaXZlIGludGVycnVwdHMKQEAgLTkwLDYg Kzk1LDkgQEAKIAl1X2ludCBsYV9jbHVzdGVyOjQ7CiAJdV9pbnQgbGFfY2x1c3Rlcl9pZDoy OwogCXVfaW50IGxhX3ByZXNlbnQ6MTsKKwl1X2xvbmcgKmxhX3RpbWVyX2NvdW50OworCXVf bG9uZyBsYV9zdGF0X3RpY2tzOworCXVfbG9uZyBsYV9wcm9mX3RpY2tzOwogfSBzdGF0aWMg bGFwaWNzW01BWF9BUElDSURdOwogCiAvKiBYWFg6IHNob3VsZCB0aGVybWFsIGJlIGFuIE5N ST8gKi8KQEAgLTExNSw5ICsxMjMsMjMgQEAKIAlJRFRWRUMoYXBpY19pc3I3KSwJLyogMjI0 IC0gMjU1ICovCiB9OwogCitzdGF0aWMgdV9pbnQzMl90IGxhcGljX3RpbWVyX2Rpdmlzb3Jz W10gPSB7IAorCUFQSUNfVERDUl8xLCBBUElDX1REQ1JfMiwgQVBJQ19URENSXzQsIEFQSUNf VERDUl84LCBBUElDX1REQ1JfMTYsCisJQVBJQ19URENSXzMyLCBBUElDX1REQ1JfNjQsIEFQ SUNfVERDUl8xMjgKK307CisKKwogdm9sYXRpbGUgbGFwaWNfdCAqbGFwaWM7CitzdGF0aWMg dV9sb25nIGxhcGljX3RpbWVyX2Rpdmlzb3IsIGxhcGljX3RpbWVyX3BlcmlvZDsKK3N0YXRp YyB1X2xvbmcgKmxhcGljX3ZpcnR1YWxfaGFyZGNsb2NrLCAqbGFwaWNfdmlydHVhbF9zdGF0 Y2xvY2ssCisJKmxhcGljX3ZpcnR1YWxfcHJvZmNsb2NrOwogCiBzdGF0aWMgdm9pZAlsYXBp Y19lbmFibGUodm9pZCk7CitzdGF0aWMgdm9pZAlsYXBpY190aW1lcl9lbmFibGVfaW50cih2 b2lkKTsKK3N0YXRpYyB1X2xvbmcgICBjYWxjdWxhdGVfbGFwaWNfdGltZXJfcGVyaW9kKHZv aWQpOworc3RhdGljIHZvaWQJbGFwaWNfdGltZXJfb25lc2hvdCh1X2ludCBjb3VudCk7Citz dGF0aWMgdm9pZAlsYXBpY190aW1lcl9wZXJpb2RpYyh1X2ludCBjb3VudCk7CitzdGF0aWMg dm9pZAlsYXBpY190aW1lcl9zZXRfZGl2aXNvcih1X2ludCBkaXZpc29yKTsKIHN0YXRpYyB1 aW50MzJfdAlsdnRfbW9kZShzdHJ1Y3QgbGFwaWMgKmxhLCB1X2ludCBwaW4sIHVpbnQzMl90 IHZhbHVlKTsKIAogc3RhdGljIHVpbnQzMl90CkBAIC0xODEsNiArMjAzLDcgQEAKIAlQQ1BV X1NFVChhcGljX2lkLCBsYXBpY19pZCgpKTsKIAogCS8qIFhYWDogdGltZXIvZXJyb3IvdGhl cm1hbCBpbnRlcnJ1cHRzICovCisJc2V0aWR0KEFQSUNfVElNRVJfSU5ULCBJRFRWRUModGlt ZXJpbnQpLCBTRFRfU1lTSUdULCBTRUxfS1BMLDApOwogfQogCiAvKgpAQCAtMjQ0LDEzICsy NjcsNTYgQEAKIAkgICAgKCJObyBJU1IgaGFuZGxlciBmb3IgSVJRICV1IiwgaXJxKSk7CiAJ c2V0aWR0KHZlY3RvciwgaW9pbnRfaGFuZGxlcnNbdmVjdG9yIC8gMzJdLCBTRFRfU1lTSUdU LCBTRUxfS1BMLCAgMCk7CiB9CitzdGF0aWMgdV9sb25nCitjYWxjdWxhdGVfbGFwaWNfdGlt ZXJfcGVyaW9kKHZvaWQpCit7CisJdV9sb25nIHBlcmlvZCx2YWx1ZTsKKworCS8qIFN0YXJ0 IG9mZiB3aXRoIGEgZGl2aXNvciBvZiAyIChwb3dlciBvbiByZXNldCBkZWZhdWx0KS4gKi8K KwlsYXBpY190aW1lcl9kaXZpc29yID0gODsKKworCS8qIFRyeSB0byBjYWxpYnJhdGUgdGhl IGxvY2FsIEFQSUMgdGltZXIuICovCisJZG8geworCQlwcmludGYoImxhcGljIHRpbWVyIGRp dmlzb3I6JWx1XG4iLGxhcGljX3RpbWVyX2Rpdmlzb3IpOworCQlsYXBpY190aW1lcl9zZXRf ZGl2aXNvcihsYXBpY190aW1lcl9kaXZpc29yKTsKKwkJbGFwaWNfdGltZXJfb25lc2hvdChB UElDX1RJTUVSX01BWF9DT1VOVCk7CisJCURFTEFZKDIwMDAwMDApOworCQl2YWx1ZSA9IEFQ SUNfVElNRVJfTUFYX0NPVU5UIC0gbGFwaWMtPmNjcl90aW1lcjsKKwkJcHJpbnRmKCJ2YWx1 ZTolbHUoY2NyOiV1KVxuIix2YWx1ZSxsYXBpYy0+Y2NyX3RpbWVyKTsKKwkJaWYgKHZhbHVl ICE9IEFQSUNfVElNRVJfTUFYX0NPVU5UKQorCQkJYnJlYWs7CisJCWxhcGljX3RpbWVyX2Rp dmlzb3IgPDw9IDE7CisJfSB3aGlsZSAobGFwaWNfdGltZXJfZGl2aXNvciA8PSAxMjgpOwor CWlmIChsYXBpY190aW1lcl9kaXZpc29yID4gMTI4KQorCQlwYW5pYygibGFwaWM6IERpdmlz b3IgdG9vIGJpZyIpOworCXZhbHVlIC89IDI7CisJcHJpbnRmKCJsYXBpYzogRnJlcXVlbmN5 ICVsdSBoelxuIiwgdmFsdWUpOwogCisJLyoKKwkgKiBXZSB3aWxsIGRyaXZlIHRoZSB0aW1l ciB2aWEgaHouICBSZXF1aXJlIGh6IHRvIGJlIGdyZWF0ZXIgdGhhbgorCSAqIHN0YXRoeiwg YnV0IGlmIGh6IGlzIGxlc3MgdGhhbiB0aGUgZGVmYXVsdCBwcm9maHosIGNhcCBwcm9maHoK KwkgKiBhdCBoei4KKwkgKi8KKwlzdGF0aHogPSBMQVBJQ19USU1FUl9TVEFUSFo7CisJaWYg KGh6IDwgc3RhdGh6KSB7CisJCXByaW50ZigibGFwaWM6IEFkanVzdGluZyBoeiBmcm9tICVk IHRvICVkXG4iLCBoeiwgc3RhdGh6KTsKKwkJaHogPSBzdGF0aHo7CisJfQorCXBlcmlvZD12 YWx1ZSAvIGh6OworCUtBU1NFUlQocGVyaW9kIT0wLCAoIkNQVTolZCBsYXBpYyV1OiB6ZXJv IGRpdmlzb3IiLFBDUFVfR0VUKGNwdWlkKSxsYXBpY19pZCgpKSk7CisjaWYgMCAgLyogIFBs ZWFzZSBlbmFibGUgZm9sbG93aW5nIGxpbmVzIGlmIHlvdSB3YW50IHRvIHNob3cgcGVyaW9k L2Rpdmlzb3IgKi8KKwlwcmludGYoIlNldHVwIENQVTolZCBwZXJpb2Q6JWx1IHZhbD0lbHVc biIsUENQVV9HRVQoY3B1aWQpLGxhcGljX3RpbWVyX3BlcmlvZCx2YWx1ZSk7CisJcHJpbnRm KCJTZXR1cCBDUFU6JWQgZGl2PSVsdVxuIixQQ1BVX0dFVChjcHVpZCksbGFwaWNfdGltZXJf ZGl2aXNvcik7CisjZW5kaWYKKwlyZXR1cm4gIHBlcmlvZDsKK30KIHZvaWQKIGxhcGljX3Nl dHVwKHZvaWQpCiB7CiAJc3RydWN0IGxhcGljICpsYTsKIAl1X2ludDMyX3QgdmFsdWUsIG1h eGx2dDsKIAlyZWdpc3Rlcl90IGVmbGFnczsKKwljaGFyIGJ1ZltNQVhDT01MRU4gKyAxXTsK IAogCWxhID0gJmxhcGljc1tsYXBpY19pZCgpXTsKIAlLQVNTRVJUKGxhLT5sYV9wcmVzZW50 LCAoIm1pc3NpbmcgQVBJQyBzdHJ1Y3R1cmUiKSk7CkBAIC0yODEsOSArMzQ3LDQ3IEBACiAJ bGFwaWMtPmx2dF9saW50MSA9IGx2dF9tb2RlKGxhLCBMVlRfTElOVDEsIGxhcGljLT5sdnRf bGludDEpOwogCiAJLyogWFhYOiBtb3JlIExWVCBlbnRyaWVzICovCisJLyogUHJvZ3JhbSB0 aW1lciBMVlQgYW5kIHNldHVwIGhhbmRsZXIuICovCisJbGFwaWMtPmx2dF90aW1lciA9IGx2 dF9tb2RlKGxhLCBMVlRfVElNRVIsIGxhcGljLT5sdnRfdGltZXIpOworCXNucHJpbnRmKGJ1 Ziwgc2l6ZW9mKGJ1ZiksICJsYXBpYyVkOiB0aW1lciIsIGxhcGljX2lkKCkpOworCWludHJj bnRfYWRkKGJ1ZiwgJmxhLT5sYV90aW1lcl9jb3VudCk7CisJaWYgKFBDUFVfR0VUKGNwdWlk KSAhPSAwKSB7CisJCWxhcGljX3RpbWVyX3BlcmlvZD1jYWxjdWxhdGVfbGFwaWNfdGltZXJf cGVyaW9kKCk7CisJCWxhcGljX3RpbWVyX3NldF9kaXZpc29yKGxhcGljX3RpbWVyX2Rpdmlz b3IpOworCQlsYXBpY190aW1lcl9wZXJpb2RpYyhsYXBpY190aW1lcl9wZXJpb2QpOworCQls YXBpY190aW1lcl9lbmFibGVfaW50cigpOworCX0KIAogCWludHJfcmVzdG9yZShlZmxhZ3Mp OwogfQorLyoKKyAqIENhbGxlZCBieSBjcHVfaW5pdGNsb2NrcygpIG9uIHRoZSBCU1AgdG8g c2V0dXAgdGhlIGxvY2FsIEFQSUMgdGltZXIgc28KKyAqIHRoYXQgaXQgY2FuIGRyaXZlIGhh cmRjbG9jaywgc3RhdGNsb2NrLCBhbmQgcHJvZmNsb2NrLiAgVGhpcyBmdW5jdGlvbgorICog cmV0dXJucyB0cnVlIGlmIGl0IGlzIGFibGUgdG8gdXNlIHRoZSBsb2NhbCBBUElDIHRpbWVy IHRvIGRyaXZlIHRoZQorICogY2xvY2tzIGFuZCBmYWxzZSBpZiBpdCBpcyBub3QgYWJsZS4K KyAqLworaW50CitsYXBpY19zZXR1cF9jbG9jayh2b2lkKQoreworCS8qIENhbid0IGRyaXZl IHRoZSB0aW1lciB3aXRob3V0IGEgbG9jYWwgQVBJQy4gKi8KKwlpZiAobGFwaWMgPT0gTlVM TCkKKwkJcmV0dXJuICgwKTsKKworCWxhcGljX3RpbWVyX3BlcmlvZCA9IGNhbGN1bGF0ZV9s YXBpY190aW1lcl9wZXJpb2QoKTsKKwlwcm9maHogPSBpbWluKGh6LCBMQVBJQ19USU1FUl9Q Uk9GSFopOworCWludHJjbnRfYWRkKCJsYXBpYzogaGFyZGNsb2NrIiwgJmxhcGljX3ZpcnR1 YWxfaGFyZGNsb2NrKTsKKwlpbnRyY250X2FkZCgibGFwaWM6IHN0YXRjbG9jayIsICZsYXBp Y192aXJ0dWFsX3N0YXRjbG9jayk7CisJaW50cmNudF9hZGQoImxhcGljOiBwcm9mY2xvY2si LCAmbGFwaWNfdmlydHVhbF9wcm9mY2xvY2spOworCisJLyoKKwkgKiBTdGFydCB1cCB0aGUg dGltZXIgb24gdGhlIEJTUC4gIFRoZSBBUHMgd2lsbCBraWNrIG9mZiB0aGVpcgorCSAqIHRp bWVyIGR1cmluZyBsYXBpY19zZXR1cCgpLgorCSAqLworCWxhcGljX3RpbWVyX3BlcmlvZGlj KGxhcGljX3RpbWVyX3BlcmlvZCk7CisJbGFwaWNfdGltZXJfZW5hYmxlX2ludHIoKTsKKwly ZXR1cm4gKDEpOworfQorCiAKIHZvaWQKIGxhcGljX2Rpc2FibGUodm9pZCkKQEAgLTUxNSw2 ICs2MTksODcgQEAKIAlpc3JjID0gaW50cl9sb29rdXBfc291cmNlKGFwaWNfaWR0X3RvX2ly cSh2ZWMpKTsKIAlpbnRyX2V4ZWN1dGVfaGFuZGxlcnMoaXNyYywgJmZyYW1lKTsKIH0KK3Zv aWQKK2xhcGljX2hhbmRsZV90aW1lcihzdHJ1Y3QgY2xvY2tmcmFtZSBmcmFtZSkKK3sKKwlz dHJ1Y3QgbGFwaWMgKmxhOworCisJbGEgPSAmbGFwaWNzW1BDUFVfR0VUKGFwaWNfaWQpXTsK KwkoKmxhLT5sYV90aW1lcl9jb3VudCkrKzsKKwljcml0aWNhbF9lbnRlcigpOworCisJLyog SGFyZGNsb2NrIGZpcmVzIG9uIGV2ZXJ5IGludGVycnVwdCBzaW5jZSB3ZSBpbnRlcnJ1cHQg YXQgaHouICovCisJaWYgKFBDUFVfR0VUKGNwdWlkKSA9PSAwKSB7CisJCSgqbGFwaWNfdmly dHVhbF9oYXJkY2xvY2spKys7CisJCWhhcmRjbG9jaygmZnJhbWUpOworCX0gZWxzZQorCQlo YXJkY2xvY2tfcHJvY2VzcygmZnJhbWUpOworCisJLyogVXNlIGEgcG9vciBtYW4ncyBhbGdv cml0aG0gdG8gZmlyZSBzdGF0Y2xvY2sgYXQgc3RhdGh6LiAqLworCWxhLT5sYV9zdGF0X3Rp Y2tzICs9IHN0YXRoejsKKwlpZiAobGEtPmxhX3N0YXRfdGlja3MgPj0gaHopIHsKKwkJbGEt PmxhX3N0YXRfdGlja3MgLT0gaHo7CisJCWlmIChQQ1BVX0dFVChjcHVpZCkgPT0gMCkKKwkJ CSgqbGFwaWNfdmlydHVhbF9zdGF0Y2xvY2spKys7CisJCXN0YXRjbG9jaygmZnJhbWUpOwor CX0KKworCS8qIFVzZSB0aGUgc2FtZSB0cmljayBmb3IgcHJvZmh6LiAqLworCWxhLT5sYV9w cm9mX3RpY2tzICs9IHByb2ZoejsKKwlpZiAobGEtPmxhX3Byb2ZfdGlja3MgPj0gaHopIHsK KwkJbGEtPmxhX3Byb2ZfdGlja3MgLT0gaHo7CisJCWlmIChQQ1BVX0dFVChjcHVpZCkgPT0g MCkKKwkJCSgqbGFwaWNfdmlydHVhbF9wcm9mY2xvY2spKys7CisJCWlmIChwcm9mcHJvY3Mg IT0gMCkKKwkJCXByb2ZjbG9jaygmZnJhbWUpOworCX0KKwljcml0aWNhbF9leGl0KCk7Cit9 CisKK3N0YXRpYyB2b2lkCitsYXBpY190aW1lcl9zZXRfZGl2aXNvcih1X2ludCBkaXZpc29y KQoreworCisJS0FTU0VSVChwb3dlcm9mMihkaXZpc29yKSwgKCJsYXBpYzogaW52YWxpZCBk aXZpc29yICV1IiwgZGl2aXNvcikpOworCUtBU1NFUlQoZmZzKGRpdmlzb3IpIDw9IHNpemVv ZihsYXBpY190aW1lcl9kaXZpc29ycykgLworCSAgICBzaXplb2YodV9pbnQzMl90KSwgKCJs YXBpYzogaW52YWxpZCBkaXZpc29yICV1IiwgZGl2aXNvcikpOworCWxhcGljLT5kY3JfdGlt ZXIgPSBsYXBpY190aW1lcl9kaXZpc29yc1tmZnMoZGl2aXNvcikgLSAxXTsKK30KKworc3Rh dGljIHZvaWQKK2xhcGljX3RpbWVyX29uZXNob3QodV9pbnQgY291bnQpCit7CisJdV9pbnQz Ml90IHZhbHVlOworCisJdmFsdWUgPSBsYXBpYy0+bHZ0X3RpbWVyOworCXZhbHVlICY9IH5B UElDX0xWVFRfVE07CisJdmFsdWUgfD0gQVBJQ19MVlRUX1RNX09ORV9TSE9UOworCWxhcGlj LT5sdnRfdGltZXIgPSB2YWx1ZTsKKwlsYXBpYy0+aWNyX3RpbWVyID0gY291bnQ7Cit9CisK K3N0YXRpYyB2b2lkCitsYXBpY190aW1lcl9wZXJpb2RpYyh1X2ludCBjb3VudCkKK3sKKwl1 X2ludDMyX3QgdmFsdWU7CisKKwl2YWx1ZSA9IGxhcGljLT5sdnRfdGltZXI7CisJdmFsdWUg Jj0gfkFQSUNfTFZUVF9UTTsKKwl2YWx1ZSB8PSBBUElDX0xWVFRfVE1fUEVSSU9ESUM7CisJ bGFwaWMtPmx2dF90aW1lciA9IHZhbHVlOworCWxhcGljLT5pY3JfdGltZXIgPSBjb3VudDsK K30KKworc3RhdGljIHZvaWQKK2xhcGljX3RpbWVyX2VuYWJsZV9pbnRyKHZvaWQpCit7CisJ dV9pbnQzMl90IHZhbHVlOworCisJdmFsdWUgPSBsYXBpYy0+bHZ0X3RpbWVyOworCXZhbHVl ICY9IH5BUElDX0xWVF9NOworCWxhcGljLT5sdnRfdGltZXIgPSB2YWx1ZTsKK30KKwogCiAv KiBUcmFuc2xhdGUgYmV0d2VlbiBJRFQgdmVjdG9ycyBhbmQgSVJRIHZlY3RvcnMuICovCiB1 X2ludApJbmRleDogYW1kNjQvYW1kNjQvbXBfbWFjaGRlcC5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNT IGZpbGU6IC9ob21lL2thdG8vY3ZzL2thdG8tc3lzL2FtZDY0L2FtZDY0L21wX21hY2hkZXAu Yyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQpyZXRyaWV2aW5nIHJldmlzaW9uIDEu MgpkaWZmIC11IC1yMS4xLjEuMSAtcjEuMgotLS0gYW1kNjQvYW1kNjQvbXBfbWFjaGRlcC5j CTE4IEZlYiAyMDA1IDE0OjA1OjU1IC0wMDAwCTEuMS4xLjEKKysrIGFtZDY0L2FtZDY0L21w X21hY2hkZXAuYwkyMCBGZWIgMjAwNSAxODoxNToyOSAtMDAwMAkxLjIKQEAgLTg3MSw3ICs4 NzEsNyBAQAogCQlzbXBfdGFyZ2V0ZWRfdGxiX3Nob290ZG93bihtYXNrLCBJUElfSU5WTFJO RywgYWRkcjEsIGFkZHIyKTsKIH0KIAotCisjaWYgMAogLyoKICAqIEZvciBzdGF0Y2xvY2ss IHdlIHNlbmQgYW4gSVBJIHRvIGFsbCBDUFUncyB0byBoYXZlIHRoZW0gY2FsbCB0aGlzCiAg KiBmdW5jdGlvbi4KQEAgLTkxNCwxNiArOTE0LDE2IEBACiAJaWYgKG1hcCAhPSAwKQogCQlp cGlfc2VsZWN0ZWQobWFwLCBJUElfSEFSRENMT0NLKTsKIH0KLQorI2VuZGlmIAogdm9pZAog aXBpX2JpdG1hcF9oYW5kbGVyKHN0cnVjdCBjbG9ja2ZyYW1lIGZyYW1lKQogewogCWludCBj cHUgPSBQQ1BVX0dFVChjcHVpZCk7CiAJdV9pbnQgaXBpX2JpdG1hcDsKLQlzdHJ1Y3QgdGhy ZWFkICp0ZDsKIAotCWlwaV9iaXRtYXAgPSBhdG9taWNfcmVhZGFuZGNsZWFyX2ludCgmY3B1 X2lwaV9wZW5kaW5nW2NwdV0pOwogCisJaXBpX2JpdG1hcCA9IGF0b21pY19yZWFkYW5kY2xl YXJfaW50KCZjcHVfaXBpX3BlbmRpbmdbY3B1XSk7CisjaWYgMAogCWNyaXRpY2FsX2VudGVy KCk7CiAKIAkvKiBOb3RoaW5nIHRvIGRvIGZvciBBU1QgKi8KQEAgLTk0OCw2ICs5NDgsNyBA QAogCX0KIAogCWNyaXRpY2FsX2V4aXQoKTsKKyNlbmRpZgogfQogCiAvKgpJbmRleDogYW1k NjQvY29uZi9DVVJSRU5ULU1BUlMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUva2F0 by9jdnMva2F0by1zeXMvYW1kNjQvY29uZi9DVVJSRU5ULU1BUlMsdgpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMS4xLjEKcmV0cmlldmluZyByZXZpc2lvbiAxLjIKZGlmZiAtdSAtcjEuMS4x LjEgLXIxLjIKSW5kZXg6IGFtZDY0L2luY2x1ZGUvYXBpY3Zhci5oCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K UkNTIGZpbGU6IC9ob21lL2thdG8vY3ZzL2thdG8tc3lzL2FtZDY0L2luY2x1ZGUvYXBpY3Zh ci5oLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEuMS4xCnJldHJpZXZpbmcgcmV2aXNpb24g MS4yCmRpZmYgLXUgLXIxLjEuMS4xIC1yMS4yCi0tLSBhbWQ2NC9pbmNsdWRlL2FwaWN2YXIu aAkxOCBGZWIgMjAwNSAxNDowNTo1NSAtMDAwMAkxLjEuMS4xCisrKyBhbWQ2NC9pbmNsdWRl L2FwaWN2YXIuaAkyMCBGZWIgMjAwNSAxODoxNTozMyAtMDAwMAkxLjIKQEAgLTEyMyw5ICsx MjMsMTIgQEAKIAogLyogSVBJcyBoYW5kbGVkIGJ5IElQSV9CSVRNQVBFRF9WRUNUT1IgIChY WFggdXBzIGlzIHRoZXJlIGEgYmV0dGVyIHBsYWNlPykgKi8KICNkZWZpbmUJSVBJX0FTVAkJ MCAJLyogR2VuZXJhdGUgc29mdHdhcmUgdHJhcC4gKi8KKyNpZiAwCiAjZGVmaW5lCUlQSV9I QVJEQ0xPQ0sJMQkvKiBJbnRlci1DUFUgY2xvY2sgaGFuZGxpbmcuICovCiAjZGVmaW5lCUlQ SV9TVEFUQ0xPQ0sJMgogI2RlZmluZSBJUElfQklUTUFQX0xBU1QgSVBJX1NUQVRDTE9DSwor I2VuZGlmCisjZGVmaW5lIElQSV9CSVRNQVBfTEFTVCBJUElfQVNUCiAjZGVmaW5lIElQSV9J U19CSVRNQVBFRCh4KSAoKHgpIDw9IElQSV9CSVRNQVBfTEFTVCkKIAogI2RlZmluZQlJUElf U1RPUAkoQVBJQ19JUElfSU5UUyArIDYpCS8qIFN0b3AgQ1BVIHVudGlsIHJlc3RhcnRlZC4g Ki8KQEAgLTE3Miw3ICsxNzUsNyBAQAogaW50aGFuZF90CiAJSURUVkVDKGFwaWNfaXNyMSks IElEVFZFQyhhcGljX2lzcjIpLCBJRFRWRUMoYXBpY19pc3IzKSwKIAlJRFRWRUMoYXBpY19p c3I0KSwgSURUVkVDKGFwaWNfaXNyNSksIElEVFZFQyhhcGljX2lzcjYpLAotCUlEVFZFQyhh cGljX2lzcjcpLCBJRFRWRUMoc3B1cmlvdXNpbnQpOworCUlEVFZFQyhhcGljX2lzcjcpLCBJ RFRWRUMoc3B1cmlvdXNpbnQpLElEVFZFQyh0aW1lcmludCk7CiAKIHVfaW50CWFwaWNfaXJx X3RvX2lkdCh1X2ludCBpcnEpOwogdV9pbnQJYXBpY19pZHRfdG9faXJxKHVfaW50IHZlY3Rv cik7CkBAIC0yMDMsNiArMjA2LDcgQEAKIHZvaWQJbGFwaWNfaXBpX3ZlY3RvcmVkKHVfaW50 IHZlY3RvciwgaW50IGRlc3QpOwogaW50CWxhcGljX2lwaV93YWl0KGludCBkZWxheSk7CiB2 b2lkCWxhcGljX2hhbmRsZV9pbnRyKHZvaWQgKmNvb2tpZSwgc3RydWN0IGludHJmcmFtZSBm cmFtZSk7Cit2b2lkCWxhcGljX2hhbmRsZV90aW1lcihzdHJ1Y3QgY2xvY2tmcmFtZSBmcmFt ZSk7CiB2b2lkCWxhcGljX3NldF9sb2dpY2FsX2lkKHVfaW50IGFwaWNfaWQsIHVfaW50IGNs dXN0ZXIsIHVfaW50IGNsdXN0ZXJfaWQpOwogaW50CWxhcGljX3NldF9sdnRfbWFzayh1X2lu dCBhcGljX2lkLCB1X2ludCBsdnQsIHVfY2hhciBtYXNrZWQpOwogaW50CWxhcGljX3NldF9s dnRfbW9kZSh1X2ludCBhcGljX2lkLCB1X2ludCBsdnQsIHVfaW50MzJfdCBtb2RlKTsKQEAg LTIxMiw2ICsyMTYsNyBAQAogCSAgICBlbnVtIGludHJfdHJpZ2dlciB0cmlnZ2VyKTsKIHZv aWQJbGFwaWNfc2V0X3Rwcih1X2ludCB2ZWN0b3IpOwogdm9pZAlsYXBpY19zZXR1cCh2b2lk KTsKK2ludAlsYXBpY19zZXR1cF9jbG9jayh2b2lkKTsKIAogI2VuZGlmIC8qICFMT0NPUkUg Ki8KICNlbmRpZiAvKiBfTUFDSElORV9BUElDVkFSX0hfICovCkluZGV4OiBhbWQ2NC9pc2Ev Y2xvY2suYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9rYXRvL2N2cy9rYXRvLXN5 cy9hbWQ2NC9pc2EvY2xvY2suYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQpkaWZm IC11IC1yMS4xLjEuMSBjbG9jay5jCi0tLSBhbWQ2NC9pc2EvY2xvY2suYwkxOCBGZWIgMjAw NSAxNDowNTo1NSAtMDAwMAkxLjEuMS4xCisrKyBhbWQ2NC9pc2EvY2xvY2suYwkyMCBGZWIg MjAwNSAxODoyNTo1MCAtMDAwMApAQCAtNjQsMTMgKzY0LDE0IEBACiAjaW5jbHVkZSA8c3lz L3N5c2N0bC5oPgogI2luY2x1ZGUgPHN5cy9jb25zLmg+CiAjaW5jbHVkZSA8c3lzL3Bvd2Vy Lmg+Ci0KKyNkZWZpbmUgTEFQSUNfVElNRVIKICNpbmNsdWRlIDxtYWNoaW5lL2Nsb2NrLmg+ CiAjaW5jbHVkZSA8bWFjaGluZS9mcmFtZS5oPgogI2luY2x1ZGUgPG1hY2hpbmUvaW50cl9t YWNoZGVwLmg+CiAjaW5jbHVkZSA8bWFjaGluZS9tZF92YXIuaD4KICNpbmNsdWRlIDxtYWNo aW5lL3BzbC5oPgotI2lmZGVmIFNNUAorI2lmZGVmIExBUElDX1RJTUVSCisjaW5jbHVkZSA8 bWFjaGluZS9hcGljdmFyLmg+CiAjaW5jbHVkZSA8bWFjaGluZS9zbXAuaD4KICNlbmRpZgog I2luY2x1ZGUgPG1hY2hpbmUvc3BlY2lhbHJlZy5oPgpAQCAtMTEzLDYgKzExNCw3IEBACiBz dGF0aWMJdV9pbnQzMl90IGk4MjU0X29mZnNldDsKIHN0YXRpYwlpbnQJKCppODI1NF9wZW5k aW5nKShzdHJ1Y3QgaW50c3JjICopOwogc3RhdGljCWludAlpODI1NF90aWNrZWQ7CitzdGF0 aWMJaW50CXVzaW5nX2xhcGljX3RpbWVyOwogc3RhdGljCXVfY2hhcglydGNfc3RhdHVzYSA9 IFJUQ1NBX0RJVklERVIgfCBSVENTQV9OT1BST0Y7CiBzdGF0aWMJdV9jaGFyCXJ0Y19zdGF0 dXNiID0gUlRDU0JfMjRIUiB8IFJUQ1NCX1BJTlRSOwogCkBAIC0xMzksNyArMTQxLDYgQEAK IHN0YXRpYyB2b2lkCiBjbGtpbnRyKHN0cnVjdCBjbG9ja2ZyYW1lICpmcmFtZSkKIHsKLQog CWlmICh0aW1lY291bnRlci0+dGNfZ2V0X3RpbWVjb3VudCA9PSBpODI1NF9nZXRfdGltZWNv dW50KSB7CiAJCW10eF9sb2NrX3NwaW4oJmNsb2NrX2xvY2spOwogCQlpZiAoaTgyNTRfdGlj a2VkKQpAQCAtMTUxLDEwICsxNTIsOCBAQAogCQljbGtpbnRyX3BlbmRpbmcgPSAwOwogCQlt dHhfdW5sb2NrX3NwaW4oJmNsb2NrX2xvY2spOwogCX0KLQloYXJkY2xvY2soZnJhbWUpOwot I2lmZGVmIFNNUAotCWZvcndhcmRfaGFyZGNsb2NrKCk7Ci0jZW5kaWYKKwlpZiAoIXVzaW5n X2xhcGljX3RpbWVyKQkKKwkJaGFyZGNsb2NrKGZyYW1lKTsKIH0KIAogaW50CkBAIC0yMjEs OSArMjIwLDYgQEAKIAkJfQogCQlpZiAocHNjbnQgPT0gcHNkaXYpCiAJCQlzdGF0Y2xvY2so ZnJhbWUpOwotI2lmZGVmIFNNUAotCQlmb3J3YXJkX3N0YXRjbG9jaygpOwotI2VuZGlmCiAJ fQogfQogCkBAIC03MzEsNiArNzI3LDkgQEAKIAlpbnQgZGlhZzsKIAogCWlmIChzdGF0Y2xv Y2tfZGlzYWJsZSkgeworI2lmZGVmIExBUElDX1RJTUVSCisJdXNpbmdfbGFwaWNfdGltZXIg PSBsYXBpY19zZXR1cF9jbG9jaygpOworI2VuZGlmCiAJCS8qCiAJCSAqIFRoZSBzdGF0IGlu dGVycnVwdCBtYXNrIGlzIGRpZmZlcmVudCB3aXRob3V0IHRoZQogCQkgKiBzdGF0aXN0aWNz IGNsb2NrLiAgQWxzbywgZG9uJ3Qgc2V0IHRoZSBpbnRlcnJ1cHQKQEAgLTc1Niw3ICs3NTUs NyBAQAogCXdyaXRlcnRjKFJUQ19TVEFUVVNCLCBSVENTQl8yNEhSKTsKIAogCS8qIERvbid0 IGJvdGhlciBlbmFibGluZyB0aGUgc3RhdGlzdGljcyBjbG9jay4gKi8KLQlpZiAoIXN0YXRj bG9ja19kaXNhYmxlKSB7CisJaWYgKCFzdGF0Y2xvY2tfZGlzYWJsZSAmJiAhdXNpbmdfbGFw aWNfdGltZXIpIHsKIAkJZGlhZyA9IHJ0Y2luKFJUQ19ESUFHKTsKIAkJaWYgKGRpYWcgIT0g MCkKIAkJCXByaW50ZigiUlRDIEJJT1MgZGlhZ25vc3RpYyBlcnJvciAlYlxuIiwgZGlhZywg UlRDREdfQklUUyk7CkBAIC03NzQsNyArNzczLDggQEAKIHZvaWQKIGNwdV9zdGFydHByb2Zj bG9jayh2b2lkKQogewotCisJaWYgKHVzaW5nX2xhcGljX3RpbWVyKQorCQlyZXR1cm47CiAJ cnRjX3N0YXR1c2EgPSBSVENTQV9ESVZJREVSIHwgUlRDU0FfUFJPRjsKIAl3cml0ZXJ0YyhS VENfU1RBVFVTQSwgcnRjX3N0YXR1c2EpOwogCXBzZGl2ID0gcHNjbnQgPSBwc3JhdGlvOwpA QCAtNzgzLDcgKzc4Myw4IEBACiB2b2lkCiBjcHVfc3RvcHByb2ZjbG9jayh2b2lkKQogewot CisJaWYgKHVzaW5nX2xhcGljX3RpbWVyKQorCQlyZXR1cm47CiAJcnRjX3N0YXR1c2EgPSBS VENTQV9ESVZJREVSIHwgUlRDU0FfTk9QUk9GOwogCXdyaXRlcnRjKFJUQ19TVEFUVVNBLCBy dGNfc3RhdHVzYSk7CiAJcHNkaXYgPSBwc2NudCA9IDE7Cg== --------------030802060005060601090600-- From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 21 21:10:57 2005 Return-Path: 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 0785C16A4CF for ; Mon, 21 Feb 2005 21:10:57 +0000 (GMT) Received: from gigave.com (mail.gigave.com [38.113.228.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC1C743D5C for ; Mon, 21 Feb 2005 21:10:56 +0000 (GMT) (envelope-from sean@sean.gigave.com) Received: from sean.gigave.com [38.113.228.242](2m9t8mc26yyhebgi)by gigave.comwith esmtp(Exim 4.43 #1 (Gentoo Linux))id 1D3Kpg-0005IR-Tc; Mon, 21 Feb 2005 13:11:08 -0800 Received: by sean.gigave.com (Postfix, from userid 1001) id 913C411739; Mon, 21 Feb 2005 13:10:56 -0800 (PST) Date: Mon, 21 Feb 2005 13:10:56 -0800 From: Sean Chittenden To: amd64@FreeBSD.org Message-ID: <20050221211056.GC826@sean.gigave.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Crash dumps not working correctly for amd64? 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: Mon, 21 Feb 2005 21:10:57 -0000 Howdy. I've got myself an interesting situation. It seems as though amd64 is unable to collect crash dumps via savecore(8). Has anyone else seen this? From dmesg(1): Checking for core dump on /dev/da0s1b ... savecore: first and last dump headers disagree on /dev/da0s1b Feb 21 12:45:59 host savecore: first and last dump headers disagree on /dev/da0s1b savecore: unsaved dumps found but not saved ??? sys/amd64/amd64/dump_machdep.c and sys/i386/i386/dump_machdep.c are essentially identical. I'm not familiar enough with these innards, but reviewing savecore(8) didn't point out anything obvious. I'm dumping onto a twa(4) controller. Are there any known workarounds to get this info? I'm tempted to turn off swap in fstab(5) that way the next time the machine comes up after a crash, it'll still have the dump in tact and could poke at it as time permitted. Other suggestions? -sc -- Sean Chittenden From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 05:40:21 2005 Return-Path: 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 43FD116A4CE for ; Tue, 22 Feb 2005 05:40:21 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 113AE43D1D for ; Tue, 22 Feb 2005 05:40:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1M5eKbV087306 for ; Tue, 22 Feb 2005 05:40:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1M5eKnx087305; Tue, 22 Feb 2005 05:40:20 GMT (envelope-from gnats) Date: Tue, 22 Feb 2005 05:40:20 GMT Message-Id: <200502220540.j1M5eKnx087305@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: "Mars G. Miro" Subject: Re: amd64/77011: consisten 5.3-p5 make crash on installworld. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 22 Feb 2005 05:40:21 -0000 The following reply was made to PR amd64/77011; it has been noted by GNATS. From: "Mars G. Miro" To: freebsd-gnats-submit@FreeBSD.org Cc: dgilbert@daveg.ca Subject: Re: amd64/77011: consisten 5.3-p5 make crash on installworld. Date: Tue, 22 Feb 2005 13:34:25 +0800 See my post at http://lists.freebsd.org/pipermail/freebsd-amd64/2005-February/003670.html Thanks. cheers mars From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 06:08:53 2005 Return-Path: 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 D67F516A4CE for ; Tue, 22 Feb 2005 06:08:53 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1398E43D1F for ; Tue, 22 Feb 2005 06:08:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j1M69BOb046427; Mon, 21 Feb 2005 23:09:11 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <421ACBFF.6030606@samsco.org> Date: Mon, 21 Feb 2005 23:06:55 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Chittenden References: <20050221211056.GC826@sean.gigave.com> In-Reply-To: <20050221211056.GC826@sean.gigave.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: amd64@freebsd.org Subject: Re: Crash dumps not working correctly for amd64? 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: Tue, 22 Feb 2005 06:08:53 -0000 Sean Chittenden wrote: > Howdy. I've got myself an interesting situation. It seems as though > amd64 is unable to collect crash dumps via savecore(8). Has anyone > else seen this? From dmesg(1): > > Checking for core dump on /dev/da0s1b ... > savecore: first and last dump headers disagree on /dev/da0s1b > Feb 21 12:45:59 host savecore: first and last dump headers disagree on /dev/da0s1b > savecore: unsaved dumps found but not saved > > ??? sys/amd64/amd64/dump_machdep.c and sys/i386/i386/dump_machdep.c > are essentially identical. I'm not familiar enough with these > innards, but reviewing savecore(8) didn't point out anything obvious. > I'm dumping onto a twa(4) controller. > > Are there any known workarounds to get this info? I'm tempted to turn > off swap in fstab(5) that way the next time the machine comes up after > a crash, it'll still have the dump in tact and could poke at it as > time permitted. Other suggestions? -sc > Can you modify savecore to dump the headers anyways so they can be inspected? Scott From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 06:20:07 2005 Return-Path: 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 5475616A4CE for ; Tue, 22 Feb 2005 06:20:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2608843D45 for ; Tue, 22 Feb 2005 06:20:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1M6K73p015353 for ; Tue, 22 Feb 2005 06:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1M6K7nR015352; Tue, 22 Feb 2005 06:20:07 GMT (envelope-from gnats) Date: Tue, 22 Feb 2005 06:20:07 GMT Message-Id: <200502220620.j1M6K7nR015352@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Markus Trippelsdorf Subject: Re: amd64/77629: aMule hardlocks AMD64 system X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Markus Trippelsdorf List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 06:20:07 -0000 The following reply was made to PR amd64/77629; it has been noted by GNATS. From: Markus Trippelsdorf To: freebsd-gnats-submit@FreeBSD.org, markus@trippelsdorf.de Cc: Subject: Re: amd64/77629: aMule hardlocks AMD64 system Date: Tue, 22 Feb 2005 07:15:27 +0100 After further investigation it turned out that fxp Ethernet driver was the cause of my problems. I bought a new NIC (RealTek 8169S chip) yesterday and everything is working fine and stable now. For the record: I'm using an AMD64 939 motherboard (ASUS A8V) with a 64bit kernel. From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 13:15:38 2005 Return-Path: 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 18CF416A4CE for ; Tue, 22 Feb 2005 13:15:38 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B1B43D41 for ; Tue, 22 Feb 2005 13:15:37 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 4769 invoked by uid 89); 22 Feb 2005 13:17:54 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 22 Feb 2005 13:17:54 -0000 Date: Tue, 22 Feb 2005 14:15:49 +0100 From: Oliver Lehmann To: amd64@freebsd.org Message-Id: <20050222141549.054a1416.lehmann@ans-netz.de> X-Mailer: Sylpheed version 1.9.3 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Matrox G400DH + amd64 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: Tue, 22 Feb 2005 13:15:38 -0000 Hi, I've thought about kicking out my celeron 600 and get a new amd64 system (Asus A8V) - AGP because I want to reuse my old G400DH. I know that the binary drivers matrox supplies are only fuer i386... but did someone took the source and tried to compile it with xorg/xfree and amd64? Did it work? If not.. any suggestion for a new graphic card which gives me the opportunity to connect two CRT monitors to it (no DVI) and is supported by xorg (xinerama)? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 13:27:49 2005 Return-Path: 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 4B59616A4CE for ; Tue, 22 Feb 2005 13:27:49 +0000 (GMT) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B33C043D49 for ; Tue, 22 Feb 2005 13:27:48 +0000 (GMT) (envelope-from groot@kde.org) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost) by pandora.cs.kun.nl (8.12.10/4.23) with ESMTP id j1MDRl9W008316 for ; Tue, 22 Feb 2005 14:27:47 +0100 (MET) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Tue, 22 Feb 2005 14:27:46 +0100 User-Agent: KMail/1.7.92 References: <20050222141549.054a1416.lehmann@ans-netz.de> In-Reply-To: <20050222141549.054a1416.lehmann@ans-netz.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502221427.46568.groot@kde.org> Subject: Re: Matrox G400DH + amd64 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: Tue, 22 Feb 2005 13:27:49 -0000 On Tuesday 22 February 2005 14:15, Oliver Lehmann wrote: > I've thought about kicking out my celeron 600 and get a new amd64 system > (Asus A8V) - AGP because I want to reuse my old G400DH. I know that the > binary drivers matrox supplies are only fuer i386... but did someone took > the source and tried to compile it with xorg/xfree and amd64? Did it work? > If not.. any suggestion for a new graphic card which gives me the > opportunity to connect two CRT monitors to it (no DVI) and is supported > by xorg (xinerama)? My G450 + two monitors works / worked fine (found out I didn't like xinerama at all), nothing special to be done about it, using whatever xorg provides. glgears puts in a lousy 182 fps, but this is a workstation, not a gaming rig, so who cares? -- These are your friends - Adem GPG: FEA2 A3FE Adriaan de Groot From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 13:35:05 2005 Return-Path: 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 0EE8B16A4CE for ; Tue, 22 Feb 2005 13:35:05 +0000 (GMT) Received: from peedub.jennejohn.org (Jba95.j.pppool.de [85.74.186.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3798243D49 for ; Tue, 22 Feb 2005 13:35:04 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.1/8.11.6) with ESMTP id j1MDZ1sM023867; Tue, 22 Feb 2005 14:35:01 +0100 (CET) (envelope-from garyj@jennejohn.org) Message-Id: <200502221335.j1MDZ1sM023867@peedub.jennejohn.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Oliver Lehmann In-Reply-To: Message from Oliver Lehmann <20050222141549.054a1416.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Feb 2005 14:35:01 +0100 From: Gary Jennejohn cc: amd64@freebsd.org Subject: Re: Matrox G400DH + amd64 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: Tue, 22 Feb 2005 13:35:05 -0000 Oliver Lehmann writes: > I've thought about kicking out my celeron 600 and get a new amd64 system > (Asus A8V) - AGP because I want to reuse my old G400DH. I know that the > binary drivers matrox supplies are only fuer i386... but did someone took > the source and tried to compile it with xorg/xfree and amd64? Did it work? AFAIK you have to use the mga_hal driver in order to support DVI, at least, I did with my card. Matrox doesn't seem to provide any 64 bit version of the mga_hal, so you can forget it. I had to switch to a cheap AVI card to use my TFT in 64-bit mode. There doesn't seem to be any source available for the mga_hal. > If not.. any suggestion for a new graphic card which gives me the > opportunity to connect two CRT monitors to it (no DVI) and is supported > by xorg (xinerama)? Don't know about xinerama. I'm only using one screen. --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org garyj[at]denx.de From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 13:57:22 2005 Return-Path: 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 14B7C16A4CE for ; Tue, 22 Feb 2005 13:57:22 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id B432F43D49 for ; Tue, 22 Feb 2005 13:57:17 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 5603 invoked by uid 89); 22 Feb 2005 13:59:35 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 22 Feb 2005 13:59:35 -0000 Date: Tue, 22 Feb 2005 14:57:31 +0100 From: Oliver Lehmann To: Adriaan de Groot Message-Id: <20050222145731.140f9a0c.lehmann@ans-netz.de> In-Reply-To: <200502221427.46568.groot@kde.org> References: <20050222141549.054a1416.lehmann@ans-netz.de> <200502221427.46568.groot@kde.org> X-Mailer: Sylpheed version 1.9.3 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org Subject: Re: Matrox G400DH + amd64 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: Tue, 22 Feb 2005 13:57:22 -0000 Adriaan de Groot wrote: > On Tuesday 22 February 2005 14:15, Oliver Lehmann wrote: > > I've thought about kicking out my celeron 600 and get a new amd64 system > > (Asus A8V) - AGP because I want to reuse my old G400DH. I know that the > > binary drivers matrox supplies are only fuer i386... but did someone took > > the source and tried to compile it with xorg/xfree and amd64? Did it work? > > If not.. any suggestion for a new graphic card which gives me the > > opportunity to connect two CRT monitors to it (no DVI) and is supported > > by xorg (xinerama)? > > My G450 + two monitors works / worked fine (found out I didn't like xinerama > at all), nothing special to be done about it, using whatever xorg provides. > glgears puts in a lousy 182 fps, but this is a workstation, not a gaming rig, > so who cares? Hmmm I've removed my mga_hal binary and only got one monitor to work: (EE) MGA: Failed to load module "mga_hal" (module does not exist, 0) (==) MGA(1): Matrox HAL module not loaded - using builtin mode setup instead (EE) MGA(1): This card requires the "mga_hal" module for dual- head operation It can be found at the Matrox web site (II) UnloadModule: "mga" (II) UnloadModule: "vgahw" so what did you do? ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 13:59:36 2005 Return-Path: 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 8B24B16A4CE for ; Tue, 22 Feb 2005 13:59:36 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6F4A43D49 for ; Tue, 22 Feb 2005 13:59:35 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 5728 invoked by uid 89); 22 Feb 2005 14:01:54 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 22 Feb 2005 14:01:54 -0000 Date: Tue, 22 Feb 2005 14:59:49 +0100 From: Oliver Lehmann To: groot@kde.org Message-Id: <20050222145949.2df0211d.lehmann@ans-netz.de> In-Reply-To: <20050222145731.140f9a0c.lehmann@ans-netz.de> References: <20050222141549.054a1416.lehmann@ans-netz.de> <200502221427.46568.groot@kde.org> <20050222145731.140f9a0c.lehmann@ans-netz.de> X-Mailer: Sylpheed version 1.9.3 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org Subject: Re: Matrox G400DH + amd64 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: Tue, 22 Feb 2005 13:59:36 -0000 Oliver Lehmann wrote: > so what did you do? ;) Ok, regarding to the readme... The HAL library is not required for basic DualHead support (without a DVI monitor) with G450- and G550-based graphics hardware. I need at least a G450 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 16:20:53 2005 Return-Path: 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 19ED316A4CE for ; Tue, 22 Feb 2005 16:20:53 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B737043D58 for ; Tue, 22 Feb 2005 16:20:52 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.3/8.13.1) with ESMTP id j1MGKndW004316; Tue, 22 Feb 2005 08:20:49 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.3/8.13.1/Submit) id j1MGKmB1004315; Tue, 22 Feb 2005 08:20:48 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Oliver Lehmann In-Reply-To: <20050222141549.054a1416.lehmann@ans-netz.de> References: <20050222141549.054a1416.lehmann@ans-netz.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 22 Feb 2005 08:20:47 -0800 Message-Id: <1109089247.4267.4.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: amd64@freebsd.org Subject: Re: Matrox G400DH + amd64 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: Tue, 22 Feb 2005 16:20:53 -0000 On Tue, 2005-02-22 at 14:15 +0100, Oliver Lehmann wrote: > Hi, > > I've thought about kicking out my celeron 600 and get a new amd64 system > (Asus A8V) - AGP because I want to reuse my old G400DH. I know that the > binary drivers matrox supplies are only fuer i386... but did someone took > the source and tried to compile it with xorg/xfree and amd64? Did it work? > If not.. any suggestion for a new graphic card which gives me the > opportunity to connect two CRT monitors to it (no DVI) and is supported > by xorg (xinerama)? Unfortunately the HAL is a i386-only binary provided by Matrox which is required for G400 dualhead. The source Matrox provides is just the same open-source driver with a few minor changes. Is there a reason you can't use a DVI-to-VGA connector and use one of the various cheap, faster video cards with two heads out there? -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 16:23:15 2005 Return-Path: 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 226FB16A4CE for ; Tue, 22 Feb 2005 16:23:15 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC5BD43D55 for ; Tue, 22 Feb 2005 16:23:14 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.3/8.13.1) with ESMTP id j1MGNAlB013754; Tue, 22 Feb 2005 08:23:10 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.3/8.13.1/Submit) id j1MGN9Xf013675; Tue, 22 Feb 2005 08:23:09 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86y8dje3p2.fsf@xps.des.no> References: <86y8dje3p2.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2005 08:23:09 -0800 Message-Id: <1109089389.4267.7.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: amd64@freebsd.org Subject: Re: VM panics 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: Tue, 22 Feb 2005 16:23:15 -0000 On Sun, 2005-02-20 at 14:55 +0100, Dag-Erling Sm=F8rgrav wrote: > With recent -CURRENT, I get recurrent VM panics on amd64: >=20 > panic: mutex vm object not owned at /usr/src/sys/vm/vm_page.c:608 >=20 > which corresponds to the following code at the beginning of in > vm_page_remove(): >=20 > 605: mtx_assert(&vm_page_queue_mtx, MA_OWNED); > 606: if ((object =3D m->object) =3D=3D NULL) > 607: return; > 608: VM_OBJECT_LOCK_ASSERT(object, MA_OWNED); > 609: if (m->flags & PG_BUSY) { > 610: vm_page_flag_clear(m, PG_BUSY); > 611: vm_page_flash(m); >=20 > This only happens under load (e.g. buildworld). >=20 > Serial console does not work properly ("sio0: configured irq 3 not in > bitmap of probed irqs 0"), and I don't currently have a firewire > cable. Backing vm/uma_core.c to r1.114 has fixed the issue for me, sufficient to survive two savecore -f (which no kernel with 1.115 had yet), a night of being a kaffe tinderbox, and me on the desktop sending this email. --=20 Eric Anholt eta@lclark.edu =20 http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 16:30:59 2005 Return-Path: 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 8E8D416A4D1 for ; Tue, 22 Feb 2005 16:30:59 +0000 (GMT) Received: from ybbsmtp13.mail.mci.yahoo.co.jp (ybbsmtp13.mail.mci.yahoo.co.jp [210.80.241.187]) by mx1.FreeBSD.org (Postfix) with SMTP id 2DA2D43D49 for ; Tue, 22 Feb 2005 16:30:57 +0000 (GMT) (envelope-from takeharu1219@ybb.ne.jp) Received: from unknown (HELO ?192.168.1.14?) (takeharu1219@219.35.170.20 with plain) by ybbsmtp13.mail.mci.yahoo.co.jp with SMTP; 22 Feb 2005 16:30:55 -0000 X-Apparently-From: Message-ID: <421B5E3D.60209@ybb.ne.jp> Date: Wed, 23 Feb 2005 01:30:53 +0900 From: Takeharu KATO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takeharu KATO References: <421A4D5D.6040205@ybb.ne.jp> In-Reply-To: <421A4D5D.6040205@ybb.ne.jp> Content-Type: multipart/mixed; boundary="------------080009050006090500050304" cc: freebsd-current@freebsd.org cc: nork@FreeBSD.org cc: freebsd-amd64@FreeBSD.org Subject: Re: AMD64 Local APIC Timer 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: Tue, 22 Feb 2005 16:30:59 -0000 This is a multi-part message in MIME format. --------------080009050006090500050304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi I found my bug in the patch which I sent before. I re-post the local-apic-timer patch for AMD64. Takeharu KATO wrote: > Hi > > I ported the local APIC timer tick feature to AMD64. > Please take a look on this patch. > > Regards, > > -- Takeharu KATO --------------080009050006090500050304 Content-Type: text/plain; name="amd64-lapic-timer.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="amd64-lapic-timer.patch" Index: amd64/amd64/apic_vector.S =================================================================== RCS file: /home/kato/cvs/kato-sys/amd64/amd64/apic_vector.S,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- amd64/amd64/apic_vector.S 18 Feb 2005 14:05:55 -0000 1.1.1.1 +++ amd64/amd64/apic_vector.S 20 Feb 2005 18:15:29 -0000 1.2 @@ -137,6 +137,26 @@ ISR_VEC(6, apic_isr6) ISR_VEC(7, apic_isr7) +/* + * Local APIC periodic timer handler. + */ + .text + SUPERALIGN_TEXT +IDTVEC(timerint) + PUSH_FRAME + + movq lapic, %rdx + movl $0, LA_EOI(%rdx) /* End Of Interrupt to APIC */ + + FAKE_MCOUNT(TF_RIP(%rsp)) + + + pushq $0 /* XXX convert trapframe to clockframe */ + call lapic_handle_timer + addq $8, %rsp /* XXX convert clockframe to trapframe */ + MEXITCOUNT + jmp doreti + #ifdef SMP /* * Global address space TLB shootdown. Index: amd64/amd64/local_apic.c =================================================================== RCS file: /home/kato/cvs/kato-sys/amd64/amd64/local_apic.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 local_apic.c --- amd64/amd64/local_apic.c 18 Feb 2005 14:05:55 -0000 1.1.1.1 +++ amd64/amd64/local_apic.c 22 Feb 2005 16:16:33 -0000 @@ -1,4 +1,6 @@ /*- + * Copyright (c) 2005 Takeharu KATO + * (Add LAPIC timer support). * Copyright (c) 2003 John Baldwin * Copyright (c) 1996, by Steve Passe * All rights reserved. @@ -66,6 +68,9 @@ CTASSERT(APIC_LOCAL_INTS == 240); CTASSERT(IPI_STOP < APIC_SPURIOUS_INT); +#define LAPIC_TIMER_STATHZ 128 +#define LAPIC_TIMER_PROFHZ 1024 + /* * Support for local APICs. Local APICs manage interrupts on each * individual processor as opposed to I/O APICs which receive interrupts @@ -90,6 +95,9 @@ u_int la_cluster:4; u_int la_cluster_id:2; u_int la_present:1; + u_long *la_timer_count; + u_long la_stat_ticks; + u_long la_prof_ticks; } static lapics[MAX_APICID]; /* XXX: should thermal be an NMI? */ @@ -115,9 +123,23 @@ IDTVEC(apic_isr7), /* 224 - 255 */ }; +static u_int32_t lapic_timer_divisors[] = { + APIC_TDCR_1, APIC_TDCR_2, APIC_TDCR_4, APIC_TDCR_8, APIC_TDCR_16, + APIC_TDCR_32, APIC_TDCR_64, APIC_TDCR_128 +}; + + volatile lapic_t *lapic; +static u_long lapic_timer_divisor, lapic_timer_period; +static u_long *lapic_virtual_hardclock, *lapic_virtual_statclock, + *lapic_virtual_profclock; static void lapic_enable(void); +static void lapic_timer_enable_intr(void); +static u_long calculate_lapic_timer_period(void); +static void lapic_timer_oneshot(u_int count); +static void lapic_timer_periodic(u_int count); +static void lapic_timer_set_divisor(u_int divisor); static uint32_t lvt_mode(struct lapic *la, u_int pin, uint32_t value); static uint32_t @@ -181,6 +203,7 @@ PCPU_SET(apic_id, lapic_id()); /* XXX: timer/error/thermal interrupts */ + setidt(APIC_TIMER_INT, IDTVEC(timerint), SDT_SYSIGT, SEL_KPL,0); } /* @@ -244,13 +267,56 @@ ("No ISR handler for IRQ %u", irq)); setidt(vector, ioint_handlers[vector / 32], SDT_SYSIGT, SEL_KPL, 0); } +static u_long +calculate_lapic_timer_period(void) +{ + u_long period,value; + + /* Start off with a divisor of 2 (power on reset default). */ + lapic_timer_divisor = 8; + + /* Try to calibrate the local APIC timer. */ + do { + printf("lapic timer divisor:%lu\n",lapic_timer_divisor); + lapic_timer_set_divisor(lapic_timer_divisor); + lapic_timer_oneshot(APIC_TIMER_MAX_COUNT); + DELAY(2000000); + value = APIC_TIMER_MAX_COUNT - lapic->ccr_timer; + printf("value:%lu(ccr:%u)\n",value,lapic->ccr_timer); + if (value != APIC_TIMER_MAX_COUNT) + break; + lapic_timer_divisor <<= 1; + } while (lapic_timer_divisor <= 128); + if (lapic_timer_divisor > 128) + panic("lapic: Divisor too big"); + value /= 2; + printf("lapic: Frequency %lu hz\n", value); + /* + * We will drive the timer via hz. Require hz to be greater than + * stathz, but if hz is less than the default profhz, cap profhz + * at hz. + */ + stathz = LAPIC_TIMER_STATHZ; + if (hz < stathz) { + printf("lapic: Adjusting hz from %d to %d\n", hz, stathz); + hz = stathz; + } + period=value / hz; + KASSERT(period!=0, ("CPU:%d lapic%u: zero divisor",PCPU_GET(cpuid),lapic_id())); +#if 0 /* Please enable following lines if you want to show period/divisor */ + printf("Setup CPU:%d period:%lu val=%lu\n",PCPU_GET(cpuid),lapic_timer_period,value); + printf("Setup CPU:%d div=%lu\n",PCPU_GET(cpuid),lapic_timer_divisor); +#endif + return period; +} void lapic_setup(void) { struct lapic *la; u_int32_t value, maxlvt; register_t eflags; + char buf[MAXCOMLEN + 1]; la = &lapics[lapic_id()]; KASSERT(la->la_present, ("missing APIC structure")); @@ -281,9 +347,47 @@ lapic->lvt_lint1 = lvt_mode(la, LVT_LINT1, lapic->lvt_lint1); /* XXX: more LVT entries */ + /* Program timer LVT and setup handler. */ + lapic->lvt_timer = lvt_mode(la, LVT_TIMER, lapic->lvt_timer); + snprintf(buf, sizeof(buf), "lapic%d: timer", lapic_id()); + intrcnt_add(buf, &la->la_timer_count); + if (PCPU_GET(cpuid) != 0) { + lapic_timer_period=calculate_lapic_timer_period(); + lapic_timer_set_divisor(lapic_timer_divisor); + lapic_timer_periodic(lapic_timer_period); + lapic_timer_enable_intr(); + } intr_restore(eflags); } +/* + * Called by cpu_initclocks() on the BSP to setup the local APIC timer so + * that it can drive hardclock, statclock, and profclock. This function + * returns true if it is able to use the local APIC timer to drive the + * clocks and false if it is not able. + */ +int +lapic_setup_clock(void) +{ + /* Can't drive the timer without a local APIC. */ + if (lapic == NULL) + return (0); + + lapic_timer_period = calculate_lapic_timer_period(); + profhz = imin(hz, LAPIC_TIMER_PROFHZ); + intrcnt_add("lapic: hardclock", &lapic_virtual_hardclock); + intrcnt_add("lapic: statclock", &lapic_virtual_statclock); + intrcnt_add("lapic: profclock", &lapic_virtual_profclock); + + /* + * Start up the timer on the BSP. The APs will kick off their + * timer during lapic_setup(). + */ + lapic_timer_periodic(lapic_timer_period); + lapic_timer_enable_intr(); + return (1); +} + void lapic_disable(void) @@ -515,6 +619,87 @@ isrc = intr_lookup_source(apic_idt_to_irq(vec)); intr_execute_handlers(isrc, &frame); } +void +lapic_handle_timer(struct clockframe frame) +{ + struct lapic *la; + + la = &lapics[PCPU_GET(apic_id)]; + (*la->la_timer_count)++; + critical_enter(); + + /* Hardclock fires on every interrupt since we interrupt at hz. */ + if (PCPU_GET(cpuid) == 0) { + (*lapic_virtual_hardclock)++; + hardclock(&frame); + } else + hardclock_process(&frame); + + /* Use a poor man's algorithm to fire statclock at stathz. */ + la->la_stat_ticks += stathz; + if (la->la_stat_ticks >= hz) { + la->la_stat_ticks -= hz; + if (PCPU_GET(cpuid) == 0) + (*lapic_virtual_statclock)++; + statclock(&frame); + } + + /* Use the same trick for profhz. */ + la->la_prof_ticks += profhz; + if (la->la_prof_ticks >= hz) { + la->la_prof_ticks -= hz; + if (PCPU_GET(cpuid) == 0) + (*lapic_virtual_profclock)++; + if (profprocs != 0) + profclock(&frame); + } + critical_exit(); +} + +static void +lapic_timer_set_divisor(u_int divisor) +{ + + KASSERT(powerof2(divisor), ("lapic: invalid divisor %u", divisor)); + KASSERT(ffs(divisor) <= sizeof(lapic_timer_divisors) / + sizeof(u_int32_t), ("lapic: invalid divisor %u", divisor)); + lapic->dcr_timer = lapic_timer_divisors[ffs(divisor) - 1]; +} + +static void +lapic_timer_oneshot(u_int count) +{ + u_int32_t value; + + value = lapic->lvt_timer; + value &= ~APIC_LVTT_TM; + value |= APIC_LVTT_TM_ONE_SHOT; + lapic->lvt_timer = value; + lapic->icr_timer = count; +} + +static void +lapic_timer_periodic(u_int count) +{ + u_int32_t value; + + value = lapic->lvt_timer; + value &= ~APIC_LVTT_TM; + value |= APIC_LVTT_TM_PERIODIC; + lapic->lvt_timer = value; + lapic->icr_timer = count; +} + +static void +lapic_timer_enable_intr(void) +{ + u_int32_t value; + + value = lapic->lvt_timer; + value &= ~APIC_LVT_M; + lapic->lvt_timer = value; +} + /* Translate between IDT vectors and IRQ vectors. */ u_int Index: amd64/amd64/mp_machdep.c =================================================================== RCS file: /home/kato/cvs/kato-sys/amd64/amd64/mp_machdep.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- amd64/amd64/mp_machdep.c 18 Feb 2005 14:05:55 -0000 1.1.1.1 +++ amd64/amd64/mp_machdep.c 20 Feb 2005 18:15:29 -0000 1.2 @@ -871,7 +871,7 @@ smp_targeted_tlb_shootdown(mask, IPI_INVLRNG, addr1, addr2); } - +#if 0 /* * For statclock, we send an IPI to all CPU's to have them call this * function. @@ -914,16 +914,16 @@ if (map != 0) ipi_selected(map, IPI_HARDCLOCK); } - +#endif void ipi_bitmap_handler(struct clockframe frame) { int cpu = PCPU_GET(cpuid); u_int ipi_bitmap; - struct thread *td; - ipi_bitmap = atomic_readandclear_int(&cpu_ipi_pending[cpu]); + ipi_bitmap = atomic_readandclear_int(&cpu_ipi_pending[cpu]); +#if 0 critical_enter(); /* Nothing to do for AST */ @@ -948,6 +948,7 @@ } critical_exit(); +#endif } /* Index: amd64/conf/CURRENT-MARS =================================================================== RCS file: /home/kato/cvs/kato-sys/amd64/conf/CURRENT-MARS,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 CURRENT-MARS Index: amd64/include/apicvar.h =================================================================== RCS file: /home/kato/cvs/kato-sys/amd64/include/apicvar.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- amd64/include/apicvar.h 18 Feb 2005 14:05:55 -0000 1.1.1.1 +++ amd64/include/apicvar.h 20 Feb 2005 18:15:33 -0000 1.2 @@ -123,9 +123,12 @@ /* IPIs handled by IPI_BITMAPED_VECTOR (XXX ups is there a better place?) */ #define IPI_AST 0 /* Generate software trap. */ +#if 0 #define IPI_HARDCLOCK 1 /* Inter-CPU clock handling. */ #define IPI_STATCLOCK 2 #define IPI_BITMAP_LAST IPI_STATCLOCK +#endif +#define IPI_BITMAP_LAST IPI_AST #define IPI_IS_BITMAPED(x) ((x) <= IPI_BITMAP_LAST) #define IPI_STOP (APIC_IPI_INTS + 6) /* Stop CPU until restarted. */ @@ -172,7 +175,7 @@ inthand_t IDTVEC(apic_isr1), IDTVEC(apic_isr2), IDTVEC(apic_isr3), IDTVEC(apic_isr4), IDTVEC(apic_isr5), IDTVEC(apic_isr6), - IDTVEC(apic_isr7), IDTVEC(spuriousint); + IDTVEC(apic_isr7), IDTVEC(spuriousint),IDTVEC(timerint); u_int apic_irq_to_idt(u_int irq); u_int apic_idt_to_irq(u_int vector); @@ -203,6 +206,7 @@ void lapic_ipi_vectored(u_int vector, int dest); int lapic_ipi_wait(int delay); void lapic_handle_intr(void *cookie, struct intrframe frame); +void lapic_handle_timer(struct clockframe frame); void lapic_set_logical_id(u_int apic_id, u_int cluster, u_int cluster_id); int lapic_set_lvt_mask(u_int apic_id, u_int lvt, u_char masked); int lapic_set_lvt_mode(u_int apic_id, u_int lvt, u_int32_t mode); @@ -212,6 +216,7 @@ enum intr_trigger trigger); void lapic_set_tpr(u_int vector); void lapic_setup(void); +int lapic_setup_clock(void); #endif /* !LOCORE */ #endif /* _MACHINE_APICVAR_H_ */ Index: amd64/isa/clock.c =================================================================== RCS file: /home/kato/cvs/kato-sys/amd64/isa/clock.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 clock.c --- amd64/isa/clock.c 18 Feb 2005 14:05:55 -0000 1.1.1.1 +++ amd64/isa/clock.c 22 Feb 2005 15:38:24 -0000 @@ -64,13 +64,14 @@ #include #include #include - +#define LAPIC_TIMER #include #include #include #include #include -#ifdef SMP +#ifdef LAPIC_TIMER +#include #include #endif #include @@ -113,6 +114,7 @@ static u_int32_t i8254_offset; static int (*i8254_pending)(struct intsrc *); static int i8254_ticked; +static int using_lapic_timer; static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; static u_char rtc_statusb = RTCSB_24HR | RTCSB_PINTR; @@ -139,7 +141,6 @@ static void clkintr(struct clockframe *frame) { - if (timecounter->tc_get_timecount == i8254_get_timecount) { mtx_lock_spin(&clock_lock); if (i8254_ticked) @@ -151,10 +152,8 @@ clkintr_pending = 0; mtx_unlock_spin(&clock_lock); } - hardclock(frame); -#ifdef SMP - forward_hardclock(); -#endif + if (!using_lapic_timer) + hardclock(frame); } int @@ -221,9 +220,6 @@ } if (pscnt == psdiv) statclock(frame); -#ifdef SMP - forward_statclock(); -#endif } } @@ -730,7 +726,11 @@ { int diag; - if (statclock_disable) { +#ifdef LAPIC_TIMER + using_lapic_timer = lapic_setup_clock(); +#endif + + if ( statclock_disable || using_lapic_timer ) { /* * The stat interrupt mask is different without the * statistics clock. Also, don't set the interrupt @@ -756,7 +756,7 @@ writertc(RTC_STATUSB, RTCSB_24HR); /* Don't bother enabling the statistics clock. */ - if (!statclock_disable) { + if (!statclock_disable && !using_lapic_timer) { diag = rtcin(RTC_DIAG); if (diag != 0) printf("RTC BIOS diagnostic error %b\n", diag, RTCDG_BITS); @@ -774,7 +774,8 @@ void cpu_startprofclock(void) { - + if (using_lapic_timer) + return; rtc_statusa = RTCSA_DIVIDER | RTCSA_PROF; writertc(RTC_STATUSA, rtc_statusa); psdiv = pscnt = psratio; @@ -783,7 +784,8 @@ void cpu_stopprofclock(void) { - + if (using_lapic_timer) + return; rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; writertc(RTC_STATUSA, rtc_statusa); psdiv = pscnt = 1; --------------080009050006090500050304-- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 17:07:46 2005 Return-Path: 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 110DA16A4CE for ; Tue, 22 Feb 2005 17:07:46 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DD5C43D4C for ; Tue, 22 Feb 2005 17:07:45 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 9681 invoked by uid 89); 22 Feb 2005 17:10:03 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 22 Feb 2005 17:10:03 -0000 Date: Tue, 22 Feb 2005 18:07:59 +0100 From: Oliver Lehmann To: amd64@freebsd.org Message-Id: <20050222180759.399aab57.lehmann@ans-netz.de> In-Reply-To: <20050222180601.27c400ec.lehmann@ans-netz.de> References: <20050222141549.054a1416.lehmann@ans-netz.de> <1109089247.4267.4.camel@leguin> <20050222180601.27c400ec.lehmann@ans-netz.de> X-Mailer: Sylpheed version 1.9.3 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Matrox G400DH + amd64 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: Tue, 22 Feb 2005 17:07:46 -0000 Oliver Lehmann wrote: > Any known problems with ATI X300 (not SE!) and xorgs radeon driver? btw.. since X300 is PCIe - any PCIe board suggestions? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 17:29:14 2005 Return-Path: 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 DF0D516A4CE for ; Tue, 22 Feb 2005 17:29:14 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF70843D1D for ; Tue, 22 Feb 2005 17:29:13 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 10147 invoked by uid 89); 22 Feb 2005 17:31:31 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 22 Feb 2005 17:31:31 -0000 Date: Tue, 22 Feb 2005 18:29:28 +0100 From: Oliver Lehmann To: amd64@freebsd.org Message-Id: <20050222182928.5bc87b64.lehmann@ans-netz.de> In-Reply-To: <20050222180759.399aab57.lehmann@ans-netz.de> References: <20050222141549.054a1416.lehmann@ans-netz.de> <1109089247.4267.4.camel@leguin> <20050222180601.27c400ec.lehmann@ans-netz.de> <20050222180759.399aab57.lehmann@ans-netz.de> X-Mailer: Sylpheed version 1.9.3 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Matrox G400DH + amd64 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: Tue, 22 Feb 2005 17:29:15 -0000 Oliver Lehmann wrote: > Oliver Lehmann wrote: > > > Any known problems with ATI X300 (not SE!) and xorgs radeon driver? > > btw.. since X300 is PCIe - any PCIe board suggestions? am I right, that there are no PCIe boards w/o active cooled northbridge arround? :( -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 19:57:51 2005 Return-Path: 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 A32BA16A51E for ; Tue, 22 Feb 2005 19:57:51 +0000 (GMT) Received: from gigave.com (mail.gigave.com [38.113.228.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D78B43D1D for ; Tue, 22 Feb 2005 19:57:51 +0000 (GMT) (envelope-from sean@sean.gigave.com) Received: from sean.gigave.com [38.113.228.242](05pjdsl42vli7dmr)by gigave.comwith esmtp(Exim 4.43 #1 (Gentoo Linux))id 1D3gAf-0006Yn-Qj; Tue, 22 Feb 2005 11:58:14 -0800 Received: by sean.gigave.com (Postfix, from userid 1001) id 7B5B411739; Tue, 22 Feb 2005 11:57:50 -0800 (PST) Date: Tue, 22 Feb 2005 11:57:50 -0800 From: Sean Chittenden To: Scott Long Message-ID: <20050222195750.GA40969@sean.gigave.com> References: <20050221211056.GC826@sean.gigave.com> <421ACBFF.6030606@samsco.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <421ACBFF.6030606@samsco.org> User-Agent: Mutt/1.5.6i cc: amd64@freebsd.org Subject: Re: Crash dumps not working correctly for amd64? 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: Tue, 22 Feb 2005 19:57:51 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > >Howdy. I've got myself an interesting situation. It seems as though > >amd64 is unable to collect crash dumps via savecore(8). Has anyone > >else seen this? From dmesg(1): > > > >Checking for core dump on /dev/da0s1b ... > >savecore: first and last dump headers disagree on /dev/da0s1b > >Feb 21 12:45:59 host savecore: first and last dump headers disagree on > >/dev/da0s1b > >savecore: unsaved dumps found but not saved > > > >??? sys/amd64/amd64/dump_machdep.c and sys/i386/i386/dump_machdep.c > >are essentially identical. I'm not familiar enough with these > >innards, but reviewing savecore(8) didn't point out anything obvious. > >I'm dumping onto a twa(4) controller. > > > >Are there any known workarounds to get this info? I'm tempted to turn > >off swap in fstab(5) that way the next time the machine comes up after > >a crash, it'll still have the dump in tact and could poke at it as > >time permitted. Other suggestions? -sc > > Can you modify savecore to dump the headers anyways so they can be > inspected? Yup... yikes! This is far from good or correct. Hrm... I'm at a loss as to the reason, however. It's like the last dump header is never overwritten in the dump process and is massively stale. I've made some changes to savecore(8) (can someone give me approval to commit these?). The resulting output is below using the new format/verbose output: # savecore -vf bounds number: 9 checking for kernel dump on device /dev/da0s1b mediasize = 3221225472 sectorsize = 512 magic mismatch on last dump header on /dev/da0s1b forcing magic on /dev/da0s1b savecore: first and last dump headers disagree on /dev/da0s1b savecore: reboot after panic: vrele: negative ref cnt Checking for available free space Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 16777216 Dump Length: 2146631680B (2047 MB) Blocksize: 512 Dumptime: Thu Dec 16 03:06:24 2004 Hostname: nfs.example.com Magic: FreeBSD Kernel Dump Version String: FreeBSD 5.3-STABLE #1: Wed Dec 8 22:20:38 PST 2004 root@nfs.example.com:/usr/obj/usr/src/sys/NFS Panic String: vrele: negative ref cnt Dump Parity: 1999448632 Bounds: 9 Dump Status: bad savecore: writing core to vmcore.9 2146631680 If you run it w/ two -v's, you get the first and last header info: # savecore -vvf bounds number: 10 checking for kernel dump on device /dev/da0s1b mediasize = 3221225472 sectorsize = 512 magic mismatch on last dump header on /dev/da0s1b forcing magic on /dev/da0s1b First dump headers: Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 16777216 Dump Length: 2146631680B (2047 MB) Blocksize: 512 Dumptime: Mon Feb 21 19:12:48 2005 Hostname: www.example.com Magic: FreeBSD Kernel Dump Version String: FreeBSD 5.3-STABLE #0: Wed Feb 16 21:42:19 PST 2005 root@www.example.com:/usr/obj/usr/src/sys/WWW Panic String: page fault Dump Parity: 1475841892 Bounds: 10 Dump Status: unknown Last dump headers: Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 16777216 Dump Length: 2146631680B (2047 MB) Blocksize: 512 Dumptime: Thu Dec 16 03:06:24 2004 Hostname: nfs.example.com Magic: FreeBSD Kernel Dump Version String: FreeBSD 5.3-STABLE #1: Wed Dec 8 22:20:38 PST 2004 root@nfs.example.com:/usr/obj/usr/src/sys/NFS Panic String: vrele: negative ref cnt Dump Parity: 1999448632 Bounds: 10 Dump Status: unknown savecore: first and last dump headers disagree on /dev/da0s1b savecore: reboot after panic: vrele: negative ref cnt Checking for available free space Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 16777216 Dump Length: 2146631680B (2047 MB) Blocksize: 512 Dumptime: Thu Dec 16 03:06:24 2004 Hostname: nfs.example.com Magic: FreeBSD Kernel Dump Version String: FreeBSD 5.3-STABLE #1: Wed Dec 8 22:20:38 PST 2004 root@nfs.example.com:/usr/obj/usr/src/sys/NFS Panic String: vrele: negative ref cnt Dump Parity: 1999448632 Bounds: 10 Dump Status: bad savecore: writing core to vmcore.10 2146631680 Why there are different dump header values, I'm not sure. But, with the -f option, you can get a core regardless of the state of the dump and its header values. That doesn't mean you get a good dump, but you at least get something. It looks like my core dumps are hosed or swapon(8) has clobbered some data on the image such that kgdb(1) can't extract anything useful. kgdb: core file: vmcore.0 kgdb: kernel image: /boot/kernel/kernel kgdb: cannot read KPML4phys Ah well, savecore_flags="-vvf" should do the trick next time this box dumps. -sc -- Sean Chittenden --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="savecore.patch" Index: savecore.8 =================================================================== RCS file: /home/ncvs/src/sbin/savecore/savecore.8,v retrieving revision 1.22 diff -u -r1.22 savecore.8 --- savecore.8 18 Jan 2005 10:09:37 -0000 1.22 +++ savecore.8 22 Feb 2005 19:24:27 -0000 @@ -71,11 +71,13 @@ .Nm will ignore it. .It Fl f -Force a dump to be taken even if the dump was cleared. +Force a dump to be taken even if either the dump was cleared or if the +dump header information is inconsistent. .It Fl k Do not clear the dump after saving it. .It Fl v Print out some additional debugging information. +Speicify twice for more information. .It Fl z Compress the core dump and kernel (see .Xr gzip 1 ) . Index: savecore.c =================================================================== RCS file: /home/ncvs/src/sbin/savecore/savecore.c,v retrieving revision 1.71 diff -u -r1.71 savecore.c --- savecore.c 10 Feb 2005 09:19:33 -0000 1.71 +++ savecore.c 22 Feb 2005 19:41:53 -0000 @@ -88,6 +88,10 @@ /* The size of the buffer used for I/O. */ #define BUFFERSIZE (1024*1024) +#define STATUS_BAD 0 +#define STATUS_GOOD 1 +#define STATUS_UNKNOWN 2 + static int checkfor, compress, clear, force, keep, verbose; /* flags */ static int nfound, nsaved, nerr; /* statistics */ @@ -95,25 +99,39 @@ static void printheader(FILE *f, const struct kerneldumpheader *h, const char *device, - int bounds) + int bounds, const int status) { uint64_t dumplen; time_t t; + const char *stat_str; - fprintf(f, "Good dump found on device %s\n", device); + fprintf(f, "Dump header from device %s\n", device); fprintf(f, " Architecture: %s\n", h->architecture); - fprintf(f, " Architecture version: %d\n", - dtoh32(h->architectureversion)); + fprintf(f, " Architecture Version: %u\n", h->architectureversion); dumplen = dtoh64(h->dumplength); - fprintf(f, " Dump length: %lldB (%lld MB)\n", (long long)dumplen, + fprintf(f, " Dump Length: %lldB (%lld MB)\n", (long long)dumplen, (long long)(dumplen >> 20)); fprintf(f, " Blocksize: %d\n", dtoh32(h->blocksize)); t = dtoh64(h->dumptime); fprintf(f, " Dumptime: %s", ctime(&t)); fprintf(f, " Hostname: %s\n", h->hostname); - fprintf(f, " Versionstring: %s", h->versionstring); - fprintf(f, " Panicstring: %s\n", h->panicstring); + fprintf(f, " Magic: %s\n", h->magic); + fprintf(f, " Version String: %s", h->versionstring); + fprintf(f, " Panic String: %s\n", h->panicstring); + fprintf(f, " Dump Parity: %u\n", h->parity); fprintf(f, " Bounds: %d\n", bounds); + + switch(status) { + case STATUS_BAD: + stat_str = "bad"; + break; + case STATUS_GOOD: + stat_str = "good"; + break; + default: + stat_str = "unknown"; + } + fprintf(f, " Dump Status: %s\n", stat_str); fflush(f); } @@ -214,12 +232,14 @@ FILE *info, *fp; int fd, fdinfo, error, wl; int nr, nw, hs, he = 0; - int bounds; + int bounds, status; u_int sectorsize; mode_t oumask; + bounds = getbounds(); dmpcnt = 0; mediasize = 0; + status = STATUS_UNKNOWN; if (buf == NULL) { buf = malloc(BUFFERSIZE); @@ -266,6 +286,7 @@ printf("magic mismatch on last dump header on %s\n", device); + status = STATUS_BAD; if (force == 0) goto closefd; @@ -284,7 +305,10 @@ syslog(LOG_ERR, "unknown version (%d) in last dump header on %s", dtoh32(kdhl.version), device); - goto closefd; + + status = STATUS_BAD; + if (force == 0) + goto closefd; } nfound++; @@ -295,7 +319,9 @@ syslog(LOG_ERR, "parity error on last dump header on %s", device); nerr++; - goto closefd; + status = STATUS_BAD; + if (force == 0) + goto closefd; } dumpsize = dtoh64(kdhl.dumplength); firsthd = lasthd - dumpsize - sizeof kdhf; @@ -308,11 +334,25 @@ nerr++; goto closefd; } + + if (verbose >= 2) { + printf("First dump headers:\n"); + printheader(stdout, &kdhf, device, bounds, -1); + + printf("\nLast dump headers:\n"); + printheader(stdout, &kdhl, device, bounds, -1); + printf("\n"); + } + if (memcmp(&kdhl, &kdhf, sizeof kdhl)) { syslog(LOG_ERR, "first and last dump headers disagree on %s", device); nerr++; - goto closefd; + status = STATUS_BAD; + if (force == 0) + goto closefd; + } else { + status = STATUS_GOOD; } if (checkfor) { @@ -333,12 +373,10 @@ goto closefd; } - bounds = getbounds(); - sprintf(buf, "info.%d", bounds); /* - * Create or overwrite any existing files. + * Create or overwrite any existing dump header files. */ fdinfo = open(buf, O_WRONLY | O_CREAT | O_TRUNC, 0600); if (fdinfo < 0) { @@ -365,9 +403,9 @@ info = fdopen(fdinfo, "w"); if (verbose) - printheader(stdout, &kdhl, device, bounds); + printheader(stdout, &kdhl, device, bounds, status); - printheader(info, &kdhl, device, bounds); + printheader(info, &kdhl, device, bounds, status); fclose(info); syslog(LOG_NOTICE, "writing %score to %s", @@ -492,6 +530,9 @@ struct fstab *fsp; char *savedir; + checkfor = compress = clear = force = keep = verbose = 0; + nfound = nsaved = nerr = 0; + openlog("savecore", LOG_PERROR, LOG_DAEMON); savedir = strdup("."); @@ -511,7 +552,7 @@ keep = 1; break; case 'v': - verbose = 1; + verbose++; break; case 'f': force = 1; --gKMricLos+KVdGMg-- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 20:05:11 2005 Return-Path: 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 B4D0A16A4CE for ; Tue, 22 Feb 2005 20:05:11 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D43543D48 for ; Tue, 22 Feb 2005 20:05:08 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 1F1F0530C; Tue, 22 Feb 2005 21:05:07 +0100 (CET) Received: from xps.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 316565308; Tue, 22 Feb 2005 21:04:32 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id C5FE733C3E; Tue, 22 Feb 2005 21:04:31 +0100 (CET) To: Eric Anholt References: <86y8dje3p2.fsf@xps.des.no> <1109089389.4267.7.camel@leguin> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 22 Feb 2005 21:04:31 +0100 In-Reply-To: <1109089389.4267.7.camel@leguin> (Eric Anholt's message of "Tue, 22 Feb 2005 08:23:09 -0800") Message-ID: <86r7j8mkds.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: amd64@freebsd.org Subject: Re: VM panics 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: Tue, 22 Feb 2005 20:05:11 -0000 Eric Anholt writes: > Backing vm/uma_core.c to r1.114 has fixed the issue for me, sufficient > to survive two savecore -f (which no kernel with 1.115 had yet), a night > of being a kaffe tinderbox, and me on the desktop sending this email. Thanks, I'll try that. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 21:42:23 2005 Return-Path: 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 71B7B16A4CE for ; Tue, 22 Feb 2005 21:42:23 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0C2243D1F for ; Tue, 22 Feb 2005 21:42:22 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 3D35A530C; Tue, 22 Feb 2005 22:42:21 +0100 (CET) Received: from xps.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id A3B075308; Tue, 22 Feb 2005 22:41:49 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id 85EF033C3E; Tue, 22 Feb 2005 22:41:49 +0100 (CET) To: Eric Anholt References: <86y8dje3p2.fsf@xps.des.no> <1109089389.4267.7.camel@leguin> <86r7j8mkds.fsf@xps.des.no> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 22 Feb 2005 22:41:49 +0100 In-Reply-To: <86r7j8mkds.fsf@xps.des.no> (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav's?= message of "Tue, 22 Feb 2005 21:04:31 +0100") Message-ID: <86d5usmfvm.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: amd64@freebsd.org Subject: Re: VM panics 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: Tue, 22 Feb 2005 21:42:23 -0000 des@des.no (Dag-Erling Sm=F8rgrav) writes: > Eric Anholt writes: > > Backing vm/uma_core.c to r1.114 has fixed the issue for me, sufficient > > to survive two savecore -f (which no kernel with 1.115 had yet), a night > > of being a kaffe tinderbox, and me on the desktop sending this email. > Thanks, I'll try that. Seems to work. I was actually able to build world & kernel without a panic. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 22:03:09 2005 Return-Path: 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 E122016A4CE for ; Tue, 22 Feb 2005 22:03:09 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 394EB43D1F for ; Tue, 22 Feb 2005 22:03:09 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 16898 invoked by uid 89); 22 Feb 2005 22:05:27 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 22 Feb 2005 22:05:27 -0000 Date: Tue, 22 Feb 2005 23:03:23 +0100 From: Oliver Lehmann To: amd64@freebsd.org Message-Id: <20050222230323.420445cf.lehmann@ans-netz.de> X-Mailer: Sylpheed version 1.9.3 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: no machine/ioctl_bt848.h machine/ioctl_meteor.h? 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: Tue, 22 Feb 2005 22:03:10 -0000 Hi, since bktr is now available on amd64, I've tried to compile my multimedia/ xawtv on amd64, but it fails because of missing machine/ioctl_bt848.h and machine/ioctl_meteor.h. Is there a point why they are not there? (at least not on sledge.freebsd.org - the machine I'm trying to compile on) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 22:18:35 2005 Return-Path: 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 558F416A4D7 for ; Tue, 22 Feb 2005 22:18:34 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id E68E243D39 for ; Tue, 22 Feb 2005 22:18:33 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21027 invoked from network); 22 Feb 2005 22:18:33 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 22 Feb 2005 22:18:33 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1MMHvgD017494; Tue, 22 Feb 2005 17:18:28 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-amd64@FreeBSD.org, obrien@FreeBSD.org Date: Tue, 22 Feb 2005 17:01:57 -0500 User-Agent: KMail/1.6.2 References: <200502141722.10259.jhb@FreeBSD.org> <20050215014037.GA51389@dragon.nuxi.com> In-Reply-To: <20050215014037.GA51389@dragon.nuxi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502221701.57560.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 Subject: Re: [PATCH] Updated quirk-driven R3000Z patches 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: Tue, 22 Feb 2005 22:18:36 -0000 On Monday 14 February 2005 08:40 pm, David O'Brien wrote: > On Mon, Feb 14, 2005 at 05:22:10PM -0500, John Baldwin wrote: > > it to work, please let me know and include the FADT header from your > > acpidump in your reply, thanks. > > .. > > > +# Compaq R3000Z > > +name: Compaq_R3000Z > > +oem: FADT "NVIDIA" "CK8 " > > +oem_rev: FADT = 0x6040000 > > +creator: FADT "PTL_" > > Exactly which parts of 'acpidump -t FADT' are pulled for these entries? > Given this output, I'm not sure which one would make an ACPI quirk from > if they needed to. > > /* > RSD PTR: OEM=ACPIAM, ACPI_Rev=2.0x (2) > XSDT=0x1ff30100, length=33, cksum=204 > */ > /* > XSDT: Length=60, Revision=1, Checksum=93, > OEMID=A M I, OEM Table ID=OEMXSDT, OEM Revision=0x10000427, > Creator ID=MSFT, Creator Revision=0x97 > Entries={ 0x1ff30290, 0x1ff30390, 0x1ff40040 } > */ > /* > FACP: Length=244, Revision=3, Checksum=239, > OEMID=A M I, OEM Table ID=OEMFACP, OEM Revision=0x10000427, > Creator ID=MSFT, Creator Revision=0x97 > FACS=0x1ff40000, DSDT=0x1ff303e0 > INT_MODEL=APIC Does this machine need the quirk? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 22 23:57:48 2005 Return-Path: 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 BF88416A4D0; Tue, 22 Feb 2005 23:57:48 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8083C43D1D; Tue, 22 Feb 2005 23:57:48 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id j1MNvmeC097456; Tue, 22 Feb 2005 15:57:48 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id j1MNvmKt097455; Tue, 22 Feb 2005 15:57:48 -0800 (PST) (envelope-from obrien) Date: Tue, 22 Feb 2005 15:57:47 -0800 From: "David O'Brien" To: John Baldwin Message-ID: <20050222235747.GA97415@dragon.nuxi.com> References: <200502141722.10259.jhb@FreeBSD.org> <20050215014037.GA51389@dragon.nuxi.com> <200502221701.57560.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502221701.57560.jhb@FreeBSD.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.8i cc: freebsd-amd64@FreeBSD.org Subject: Re: [PATCH] Updated quirk-driven R3000Z patches X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 22 Feb 2005 23:57:48 -0000 On Tue, Feb 22, 2005 at 05:01:57PM -0500, John Baldwin wrote: > On Monday 14 February 2005 08:40 pm, David O'Brien wrote: > > On Mon, Feb 14, 2005 at 05:22:10PM -0500, John Baldwin wrote: > > > it to work, please let me know and include the FADT header from your > > > acpidump in your reply, thanks. ... > > Exactly which parts of 'acpidump -t FADT' are pulled for these entries? > > Given this output, I'm not sure which one would make an ACPI quirk from > > if they needed to. > Does this machine need the quirk? Nope. It is a VIA K8T800-based system and just the one I was sitting on when I was reading your email. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 07:30:23 2005 Return-Path: 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 39FFF16A4CE for ; Wed, 23 Feb 2005 07:30:23 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C21F43D53 for ; Wed, 23 Feb 2005 07:30:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1N7UMW9060754 for ; Wed, 23 Feb 2005 07:30:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1N7UMAF060753; Wed, 23 Feb 2005 07:30:22 GMT (envelope-from gnats) Resent-Date: Wed, 23 Feb 2005 07:30:22 GMT Resent-Message-Id: <200502230730.j1N7UMAF060753@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, thierry Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C979516A4D5 for ; Wed, 23 Feb 2005 07:23:42 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DFC943D31 for ; Wed, 23 Feb 2005 07:23:42 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j1N7NgN0046545 for ; Wed, 23 Feb 2005 07:23:42 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j1N7Ngsb046541; Wed, 23 Feb 2005 07:23:42 GMT (envelope-from nobody) Message-Id: <200502230723.j1N7Ngsb046541@www.freebsd.org> Date: Wed, 23 Feb 2005 07:23:42 GMT From: thierry To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: amd64/77949: Pb boot FreeBSD 64 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: Wed, 23 Feb 2005 07:30:23 -0000 >Number: 77949 >Category: amd64 >Synopsis: Pb boot FreeBSD 64 >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 23 07:30:22 GMT 2005 >Closed-Date: >Last-Modified: >Originator: thierry >Release: 5.3-RELEASE-amd64-miniinst.iso >Organization: >Environment: >Description: Unable to boot this cd on my Laptop Acer Aspire 1501 LMi Using AMD Athlon 64 / VIA K8T800. I can see the menu option, i try with noapci .... but do not want to boot. >How-To-Repeat: Boot on the cd. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 09:21:20 2005 Return-Path: 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 C8F3216A4CE for ; Wed, 23 Feb 2005 09:21:20 +0000 (GMT) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4728A43D2D for ; Wed, 23 Feb 2005 09:21:20 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [134.93.180.218] (edda.Physik.Uni-Mainz.DE [134.93.180.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id F1D053000260 for ; Wed, 23 Feb 2005 10:21:18 +0100 (CET) Message-ID: <421C4B1B.5070102@mail.uni-mainz.de> Date: Wed, 23 Feb 2005 10:21:31 +0100 From: "O. Hartmann" Organization: Institut =?ISO-8859-15?Q?f=FCr_Geophysik?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-AT; rv:1.7.5) Gecko/20050202 X-Accept-Language: de-de, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Subject: More than 4 GBytes RAM on Socket939 system? 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: Wed, 23 Feb 2005 09:21:20 -0000 Dear Sirs. I'm not a technical thug, so I do not know many about recent chipsets. I just build up a ASUS A8N-SLI Deluxe based AMD64 sytem, socket 939, AMD 64 3500+ (Winchester), 2 GB ECC RAm for some numerical calculations. 2GByte DDR400 RAM seems to become available within the next few months and I though about increasing the avaiable memory in my AMD64 box -if possible. Socket 939 mainboards do have several benefits compared to Socket 940 boards (for single chip mahines, not SMP), especially PCIe. So that is the reason why I decided to obtain a Socket 939 machine. Will it be possible to address more than 4GBytes of RAM with the above mentioned board (nVidia nForce4-SLI chipset)? The limitations are settled in the chip core, I think. AMD64 processores only address 4 memory slots and can not address 128MBit memory chips, as I found in the net so maximum memroy capacity is 4GB with available 1GB modules. But what is about 2GB modules as I mentioned above? Will it be possible to just increase or double the memory? Especially for our scientific calculations, which are hungry of memory, this would be a great benefit ... Thnaks in advance, Oliver From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 11:14:35 2005 Return-Path: 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 B875E16A4CE for ; Wed, 23 Feb 2005 11:14:35 +0000 (GMT) Received: from 21322530218.direct.eti.at (21322530218.direct.eti.at [213.225.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id A34C143D5F for ; Wed, 23 Feb 2005 11:14:34 +0000 (GMT) (envelope-from tilman@arved.at) Received: from jim.arved.de (localhost [127.0.0.1])j1NBEVhw064168; Wed, 23 Feb 2005 12:14:31 +0100 (CET) (envelope-from tilman@arved.at) Received: (from arved@localhost) by jim.arved.de (8.13.1/8.13.1/Submit) id j1NBEV4b064167; Wed, 23 Feb 2005 12:14:31 +0100 (CET) (envelope-from tilman@arved.at) X-Authentication-Warning: jim.arved.de: arved set sender to tilman@arved.at using -f Date: Wed, 23 Feb 2005 12:14:31 +0100 From: Tilman Linneweh To: Oliver Lehmann Message-ID: <20050223111431.GA64128@arved.at> References: <20050222230323.420445cf.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050222230323.420445cf.lehmann@ans-netz.de> User-Agent: Mutt/1.4.2.1i cc: amd64@FreeBSD.org Subject: Re: no machine/ioctl_bt848.h machine/ioctl_meteor.h? 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: Wed, 23 Feb 2005 11:14:35 -0000 * Oliver Lehmann [Tue, 22 Feb 2005 at 23:03 GMT]: > since bktr is now available on amd64, I've tried to compile my multimedia/ > xawtv on amd64, but it fails because of missing machine/ioctl_bt848.h and > machine/ioctl_meteor.h. Is there a point why they are not there? (at > least not on sledge.freebsd.org - the machine I'm trying to compile on) They are in /usr/include/dev/bktr on RELENG_5 and CURRENT on all archs. BTW there are a lot of ports that use bktr(4) that are excluded from running on amd64 by ONLY_FOR_ARCHS. Someone with the combination of amd64 + bktr-card should test them. regards tilman From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 12:18:46 2005 Return-Path: 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 A982F16A4CE for ; Wed, 23 Feb 2005 12:18:46 +0000 (GMT) Received: from falcon.loomes.de (smtp.loomes.de [212.40.161.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 635BC43D41 for ; Wed, 23 Feb 2005 12:18:46 +0000 (GMT) (envelope-from markus@trippelsdorf.de) Received: from port-212-202-34-139.dynamic.qsc.de ([212.202.34.139] helo=[192.68.0.2]) by falcon.loomes.de with asmtp (Exim 4.30) id 1D3vTU-0000z2-Rd; Wed, 23 Feb 2005 13:18:41 +0100 From: Markus Trippelsdorf To: Oliver Lehmann In-Reply-To: <20050222230323.420445cf.lehmann@ans-netz.de> References: <20050222230323.420445cf.lehmann@ans-netz.de> Content-Type: text/plain Date: Wed, 23 Feb 2005 13:18:39 +0100 Message-Id: <1109161119.4716.8.camel@bsd.trippelsdorf.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: amd64@freebsd.org Subject: Re: no machine/ioctl_bt848.h machine/ioctl_meteor.h? 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: Wed, 23 Feb 2005 12:18:46 -0000 On Tue, 2005-02-22 at 23:03 +0100, Oliver Lehmann wrote: > since bktr is now available on amd64, I've tried to compile my multimedia/ > xawtv on amd64, but it fails because of missing machine/ioctl_bt848.h and > machine/ioctl_meteor.h. This may be slightly OT, but I suggest that you take a look at mplayer. It has excellent TV support and is way ahead of the other TV applications in terms of picture quality. (Try something like: mplayer -tv driver=bsdbt848:input=1:channels=SE14-BBC,SE9-3sat,E10-ARD,E8-ZDF,SE4-arte,S22-WDR tv://) HTH, Markus From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 14:45:08 2005 Return-Path: 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 51FD816A4D2 for ; Wed, 23 Feb 2005 14:45:08 +0000 (GMT) Received: from www1.brozs.net (www1.brozs.net [195.154.177.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 065D443D1D for ; Wed, 23 Feb 2005 14:45:03 +0000 (GMT) (envelope-from tfagart@brozs.net) Received: from localhost (localhost.brozs.net [127.0.0.1]) by www1.brozs.net (Postfix) with ESMTP id 9B0AF410E; Wed, 23 Feb 2005 15:39:20 +0100 (CET) Received: from www1.brozs.net ([127.0.0.1]) by localhost (www1.brozs.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00581-07; Wed, 23 Feb 2005 15:39:20 +0100 (CET) Received: from webmail.brozs.net (localhost.brozs.net [127.0.0.1]) by www1.brozs.net (Postfix) with ESMTP id 10F4940B7; Wed, 23 Feb 2005 15:39:20 +0100 (CET) Received: from 64.236.219.241 (SquirrelMail authenticated user tfagart@brozs.net); by webmail.brozs.net with HTTP; Wed, 23 Feb 2005 15:39:20 +0100 (CET) Message-ID: <16766.64.236.219.241.1109169560.squirrel@64.236.219.241> In-Reply-To: <1109161119.4716.8.camel@bsd.trippelsdorf.de> References: <20050222230323.420445cf.lehmann@ans-netz.de> <1109161119.4716.8.camel@bsd.trippelsdorf.de> Date: Wed, 23 Feb 2005 15:39:20 +0100 (CET) From: tfagart@brozs.net To: "Markus Trippelsdorf" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at brozs.net cc: amd64@freebsd.org Subject: Re: no machine/ioctl_bt848.h machine/ioctl_meteor.h? 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: Wed, 23 Feb 2005 14:45:08 -0000 > On Tue, 2005-02-22 at 23:03 +0100, Oliver Lehmann wrote: >> since bktr is now available on amd64, I've tried to compile my >> multimedia/ >> xawtv on amd64, but it fails because of missing machine/ioctl_bt848.h >> and >> machine/ioctl_meteor.h. > > This may be slightly OT, but I suggest that you take a look at mplayer. > It has excellent TV support and is way ahead of the other TV > applications in terms of picture quality. > (Try something like: mplayer -tv > driver=bsdbt848:input=1:channels=SE14-BBC,SE9-3sat,E10-ARD,E8-ZDF,SE4-arte,S22-WDR > tv://) I've succesfully compiled fxtv and mplayer with bsdbt8484 support (note it does not detect it automaticaly). These apps works properly but no way to display anything coming from bsdbt848 card. (All of this is working on i386 release on the same equipment). At the boot time I've got that Feb 23 12:53:16 www1 kernel: bktr0: mem 0xf7e00000-0xf7e00fff irq 16 at device 9.0 on pci0 Feb 23 12:53:16 www1 kernel: bktr0: [GIANT-LOCKED] Feb 23 12:53:16 www1 kernel: bktr0: Hauppauge Model 37266 B109 Feb 23 12:53:16 www1 kernel: bktr0: Detected a MSP3410D-B4 at 0x80 Feb 23 12:53:16 www1 kernel: bktr0: Detected a DPL3418A-A2 at 0x84 Feb 23 12:53:16 www1 kernel: bktr0: Hauppauge WinCast/TV, Philips SECAM tuner, msp3400c stereo, dpl3518a dolby, remote control But weirdly, sysctls are not updated properly www1# sysctl -a | grep bt848 hw.bt848.slow_msp_audio: -1 hw.bt848.format: -1 hw.bt848.reverse_mute: -1 hw.bt848.tuner: -1 hw.bt848.card: -1 In bktr's man, it says that device iicbus device iicbb device smbus should be added to kern conf, but these devices doesn't seems to be detected as it should. I don't know it this helps. Cheers Thomas > > HTH, > Markus > > > _______________________________________________ > 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 Feb 23 15:29:23 2005 Return-Path: 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 008CC16A4CE for ; Wed, 23 Feb 2005 15:29:23 +0000 (GMT) Received: from falcon.loomes.de (smtp.loomes.de [212.40.161.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B613B43D2D for ; Wed, 23 Feb 2005 15:29:22 +0000 (GMT) (envelope-from markus@trippelsdorf.de) Received: from port-212-202-34-139.dynamic.qsc.de ([212.202.34.139] helo=[192.68.0.2]) by falcon.loomes.de with asmtp (Exim 4.30) id 1D3yS1-0003pk-Bt for amd64@freebsd.org; Wed, 23 Feb 2005 16:29:21 +0100 From: Markus Trippelsdorf To: amd64@freebsd.org Content-Type: text/plain Date: Wed, 23 Feb 2005 16:29:19 +0100 Message-Id: <1109172559.702.13.camel@bsd.trippelsdorf.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: ext2 filesystem lockups 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: Wed, 23 Feb 2005 15:29:23 -0000 When copying large files to a locally mounted ext2 filesystem my system always locks up. Is this a known problem in 64bit mode? Which filesystem is recommended for multi-OS file exchange? __ Markus From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 17:57:27 2005 Return-Path: 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 4F1E516A4CE for ; Wed, 23 Feb 2005 17:57:27 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1878E43D4C for ; Wed, 23 Feb 2005 17:57:27 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id j1NHvQQ1026524; Wed, 23 Feb 2005 09:57:26 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id j1NHvPVA026523; Wed, 23 Feb 2005 09:57:25 -0800 (PST) (envelope-from obrien) Date: Wed, 23 Feb 2005 09:57:25 -0800 From: "David O'Brien" To: Markus Trippelsdorf Message-ID: <20050223175725.GA26395@dragon.nuxi.com> References: <1109172559.702.13.camel@bsd.trippelsdorf.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109172559.702.13.camel@bsd.trippelsdorf.de> 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.8i cc: freebsd-amd64@freebsd.org Subject: Re: ext2 filesystem lockups X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Feb 2005 17:57:27 -0000 On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wrote: > When copying large files to a locally mounted ext2 filesystem > my system always locks up. > Is this a known problem in 64bit mode? > Which filesystem is recommended for multi-OS file exchange? I've heard enought reports of ext2 problems on 32-bit i386, that I don't trust it in situations that "have to work". By far the most widely supported FS is vfat32 [mount_msdosfs(8)]. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 18:01:43 2005 Return-Path: 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 D256716A4CE for ; Wed, 23 Feb 2005 18:01:43 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 954BE43D5F for ; Wed, 23 Feb 2005 18:01:43 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id j1NI1gue026631; Wed, 23 Feb 2005 10:01:43 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id j1NI1gFL026630; Wed, 23 Feb 2005 10:01:42 -0800 (PST) (envelope-from obrien) Date: Wed, 23 Feb 2005 10:01:42 -0800 From: "David O'Brien" To: "O. Hartmann" Message-ID: <20050223180142.GB26395@dragon.nuxi.com> References: <421C4B1B.5070102@mail.uni-mainz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421C4B1B.5070102@mail.uni-mainz.de> 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.8i cc: freebsd-amd64@freebsd.org Subject: Re: More than 4 GBytes RAM on Socket939 system? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Feb 2005 18:01:43 -0000 On Wed, Feb 23, 2005 at 10:21:31AM +0100, O. Hartmann wrote: > Will it be possible to address more than 4GBytes of RAM with the above > mentioned board (nVidia nForce4-SLI chipset)? Yes. If you can install >4GB RAM, the CPU+motherboard will use it. > The limitations are settled in the chip core, I think. No the limitation is with the CPU, which has 40 physical address lines. So you use 2^40 bytes of RAM. > AMD64 processores only address 4 memory slots and can not address > 128MBit memory chips, What is a 128 MBit chip? > But what is about 2GB modules as I mentioned above? See the recomendations for your motherboard. The motherboard+CPU can use 2GB modules, but some aren't made well and aren't fully to JEDEC spec. So do some research to find good 2GB DIMM's. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 18:10:37 2005 Return-Path: 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 920BF16A4D0 for ; Wed, 23 Feb 2005 18:10:37 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6883143D54 for ; Wed, 23 Feb 2005 18:10:37 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1NIAb0s046395 for ; Wed, 23 Feb 2005 18:10:37 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1NIAbqG046394; Wed, 23 Feb 2005 18:10:37 GMT (envelope-from gnats) Date: Wed, 23 Feb 2005 18:10:37 GMT Message-Id: <200502231810.j1NIAbqG046394@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: "David O'Brien" Subject: Re: amd64/77949: Pb boot FreeBSD 64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David O'Brien List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 18:10:37 -0000 The following reply was made to PR amd64/77949; it has been noted by GNATS. From: "David O'Brien" To: thierry Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: amd64/77949: Pb boot FreeBSD 64 Date: Wed, 23 Feb 2005 10:04:04 -0800 On Wed, Feb 23, 2005 at 07:23:42AM +0000, thierry wrote: > >Description: > Unable to boot this cd on my Laptop Acer Aspire 1501 LMi > Using AMD Athlon 64 / VIA K8T800. What in the world is a "Pb" cdrom? -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 18:16:33 2005 Return-Path: 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 AC8E016A4CE for ; Wed, 23 Feb 2005 18:16:33 +0000 (GMT) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FDA343D3F for ; Wed, 23 Feb 2005 18:16:33 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [134.93.180.218] (edda.Physik.Uni-Mainz.DE [134.93.180.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 77CC330003FA for ; Wed, 23 Feb 2005 19:16:31 +0100 (CET) Message-ID: <421CC86E.2050509@mail.uni-mainz.de> Date: Wed, 23 Feb 2005 19:16:14 +0100 From: "O. Hartmann" Organization: Institut =?ISO-8859-1?Q?f=FCr_Geophysik?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-AT; rv:1.7.5) Gecko/20050202 X-Accept-Language: de-de, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <421C4B1B.5070102@mail.uni-mainz.de> <20050223180142.GB26395@dragon.nuxi.com> In-Reply-To: <20050223180142.GB26395@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Subject: Re: More than 4 GBytes RAM on Socket939 system? 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: Wed, 23 Feb 2005 18:16:33 -0000 David O'Brien schrieb: >On Wed, Feb 23, 2005 at 10:21:31AM +0100, O. Hartmann wrote: > > >>Will it be possible to address more than 4GBytes of RAM with the above >>mentioned board (nVidia nForce4-SLI chipset)? >> >> > >Yes. If you can install >4GB RAM, the CPU+motherboard will use it. > > > >>The limitations are settled in the chip core, I think. >> >> > >No the limitation is with the CPU, which has 40 physical address lines. >So you use 2^40 bytes of RAM. > > > >>AMD64 processores only address 4 memory slots and can not address >>128MBit memory chips, >> >> > >What is a 128 MBit chip? > > Dear David. I found this info on ASUS homepage for the A8N-SLI and it means (I think) a single IC, 128MBit x 8 organized. Thanks for this really good news! > > >>But what is about 2GB modules as I mentioned above? >> >> > >See the recomendations for your motherboard. The motherboard+CPU can use >2GB modules, but some aren't made well and aren't fully to JEDEC spec. >So do some research to find good 2GB DIMM's. > > > From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 18:46:43 2005 Return-Path: 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 1FF8416A4CE; Wed, 23 Feb 2005 18:46:43 +0000 (GMT) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47CC043D3F; Wed, 23 Feb 2005 18:46:42 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 807B711673; Wed, 23 Feb 2005 19:48:38 +0100 (CET) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22022-10; Wed, 23 Feb 2005 19:48:33 +0100 (CET) Received: from [192.168.42.3] (innercity.xbsd.org [192.168.42.3]) by smtp.xbsd.org (Postfix) with ESMTP id 676B411421; Wed, 23 Feb 2005 19:48:33 +0100 (CET) Message-ID: <421CCF89.8010105@xbsd.org> Date: Wed, 23 Feb 2005 19:46:33 +0100 From: Florent Thoumie User-Agent: Mozilla Thunderbird 1.0 (X11/20050107) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David O'Brien References: <200502231810.j1NIAbqG046394@freefall.freebsd.org> In-Reply-To: <200502231810.j1NIAbqG046394@freefall.freebsd.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0B0727FCBF6ADD0E6BF4579C" X-Virus-Scanned: amavisd-new at xbsd.org cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64/77949: Pb boot FreeBSD 64 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: Wed, 23 Feb 2005 18:46:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B0727FCBF6ADD0E6BF4579C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David O'Brien wrote: > What in the world is a "Pb" cdrom? That's french abbreviation for "problem". -- flz --------------enig0B0727FCBF6ADD0E6BF4579C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHM+JMxEkbVFH3PQRAtfdAJ9igXqxiXs1hrGibMoXmuXAFnkMZgCffhWO L0jWGDwdzUtbQrPdAzrmEfw= =m6a0 -----END PGP SIGNATURE----- --------------enig0B0727FCBF6ADD0E6BF4579C-- From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 19:04:27 2005 Return-Path: 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 2F7BC16A4CE for ; Wed, 23 Feb 2005 19:04:27 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1DE143D2D for ; Wed, 23 Feb 2005 19:04:26 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j1NJ4W7s056571; Wed, 23 Feb 2005 12:04:32 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <421CD345.2060305@samsco.org> Date: Wed, 23 Feb 2005 12:02:29 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "O. Hartmann" References: <421C4B1B.5070102@mail.uni-mainz.de> <20050223180142.GB26395@dragon.nuxi.com> <421CC86E.2050509@mail.uni-mainz.de> In-Reply-To: <421CC86E.2050509@mail.uni-mainz.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-amd64@freebsd.org Subject: Re: More than 4 GBytes RAM on Socket939 system? 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: Wed, 23 Feb 2005 19:04:27 -0000 O. Hartmann wrote: > David O'Brien schrieb: > >> On Wed, Feb 23, 2005 at 10:21:31AM +0100, O. Hartmann wrote: >> >> >>> Will it be possible to address more than 4GBytes of RAM with the above >>> mentioned board (nVidia nForce4-SLI chipset)? >>> >> >> >> Yes. If you can install >4GB RAM, the CPU+motherboard will use it. >> >> >> >>> The limitations are settled in the chip core, I think. >>> >> >> >> No the limitation is with the CPU, which has 40 physical address lines. >> So you use 2^40 bytes of RAM. >> >> >> >>> AMD64 processores only address 4 memory slots and can not address >>> 128MBit memory chips, >>> >> >> >> What is a 128 MBit chip? >> >> > > Dear David. > I found this info on ASUS homepage for the A8N-SLI and it means (I think) > a single IC, 128MBit x 8 organized. > > Thanks for this really good news! I guess you're implying that the memory controller on the 939 only has enough address decode and refresh logic to drive DRAM chips of a certain maximum size? David, can you comment? Scott From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 23 22:35:39 2005 Return-Path: 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 E366D16A4CE for ; Wed, 23 Feb 2005 22:35:39 +0000 (GMT) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DDE343D31 for ; Wed, 23 Feb 2005 22:35:39 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id 8D5B617018; Wed, 23 Feb 2005 19:35:35 -0300 (BRT) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89409-04; Wed, 23 Feb 2005 19:35:26 -0300 (BRT) Received: from [10.0.8.17] (nat.int.gov.br [200.20.196.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id 7679917017; Wed, 23 Feb 2005 19:35:26 -0300 (BRT) Message-ID: <421D052D.3030909@jonny.eng.br> Date: Wed, 23 Feb 2005 19:35:25 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <1109172559.702.13.camel@bsd.trippelsdorf.de> <20050223175725.GA26395@dragon.nuxi.com> In-Reply-To: <20050223175725.GA26395@dragon.nuxi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at coe.ufrj.br cc: Markus Trippelsdorf Subject: Re: ext2 filesystem lockups 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: Wed, 23 Feb 2005 22:35:40 -0000 David O'Brien wrote: > On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wrote: > >>When copying large files to a locally mounted ext2 filesystem >>my system always locks up. >>Is this a known problem in 64bit mode? Just curious: what is the drive interface with the ext2fs? IDE? I had lots of freezing problems on an ASUS K8V SE deluxe, 2 Seagate SATA 200G drives under Promise Raid. It appeared to me that the problems were caused by something in the IDE interface after lots of data have flowed through it. The very same hardware is now on 32-bit mode FreeBSD 5.3-stable, without any problems at all. >>Which filesystem is recommended for multi-OS file exchange? > > I've heard enought reports of ext2 problems on 32-bit i386, that I don't > trust it in situations that "have to work". By far the most widely > supported FS is vfat32 [mount_msdosfs(8)]. The last time I had to use msdosfs, on 4.* it was extremely slow compared to UFS on the same disk. Did this get better on 5.*? From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 00:06:57 2005 Return-Path: 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 C983A16A4CE for ; Thu, 24 Feb 2005 00:06:57 +0000 (GMT) Received: from falcon.loomes.de (smtp.loomes.de [212.40.161.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BA3643D1D for ; Thu, 24 Feb 2005 00:06:57 +0000 (GMT) (envelope-from markus@trippelsdorf.de) Received: from port-212-202-34-139.dynamic.qsc.de ([212.202.34.139] helo=[192.68.0.2]) by falcon.loomes.de with asmtp (Exim 4.30) id 1D46Wt-0000sS-Jf; Thu, 24 Feb 2005 01:06:55 +0100 From: Markus Trippelsdorf To: =?ISO-8859-1?Q?Jo=E3o?= Carlos Mendes =?ISO-8859-1?Q?Lu=EDs?= In-Reply-To: <421D052D.3030909@jonny.eng.br> References: <1109172559.702.13.camel@bsd.trippelsdorf.de> <421D052D.3030909@jonny.eng.br> Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 24 Feb 2005 01:06:54 +0100 Message-Id: <1109203614.577.5.camel@bsd.trippelsdorf.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable cc: freebsd-amd64@freebsd.org Subject: Re: ext2 filesystem lockups 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: Thu, 24 Feb 2005 00:06:57 -0000 On Wed, 2005-02-23 at 19:35 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote: > David O'Brien wrote: > > On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wrote: > >=20 > >>When copying large files to a locally mounted ext2 filesystem > >>my system always locks up. > >>Is this a known problem in 64bit mode? >=20 > Just curious: what is the drive interface with the ext2fs? IDE? Yes, it's the normal IDE interface (ATA UDMA133 drive). > The very same hardware is now on 32-bit mode FreeBSD 5.3-stable, without=20 > any problems at all. >=20 > >>Which filesystem is recommended for multi-OS file exchange? =20 > >=20 > > I've heard enought reports of ext2 problems on 32-bit i386, that I don'= t > > trust it in situations that "have to work". By far the most widely > > supported FS is vfat32 [mount_msdosfs(8)]. >=20 > The last time I had to use msdosfs, on 4.* it was extremely slow=20 > compared to UFS on the same disk. Did this get better on 5.*? I want to use the filesystem for my music collection, so I'm willing to trade fastness for reliability. __ Markus From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 01:21:07 2005 Return-Path: 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 EE3DA16A4CE for ; Thu, 24 Feb 2005 01:21:07 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82B2543D48 for ; Thu, 24 Feb 2005 01:21:07 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so61817wra for ; Wed, 23 Feb 2005 17:21:06 -0800 (PST) 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:references; b=sCm+nkfyMAQzLp+zsGRrPcXtYLXw4G/jNbf7dlnKj+FhiY87BAnXI5Y06jjRIerBnSi9pJvYFGr8EA7j6yFcDwqaJUY1h46hunmD5SXH3rmMFNT578nBhAI7Kgm9vy8CsiQaVgl75YNIQCJDM0GhBKFI0yTWWwCCaARlnaKH1VE= Received: by 10.54.37.78 with SMTP id k78mr53105wrk; Wed, 23 Feb 2005 17:21:05 -0800 (PST) Received: by 10.54.40.69 with HTTP; Wed, 23 Feb 2005 17:21:05 -0800 (PST) Message-ID: <2fd864e05022317214525e8f2@mail.gmail.com> Date: Wed, 23 Feb 2005 17:21:05 -0800 From: Astrodog To: Markus Trippelsdorf In-Reply-To: <1109203614.577.5.camel@bsd.trippelsdorf.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <1109172559.702.13.camel@bsd.trippelsdorf.de> <421D052D.3030909@jonny.eng.br> <1109203614.577.5.camel@bsd.trippelsdorf.de> cc: freebsd-amd64@freebsd.org Subject: Re: ext2 filesystem lockups X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Feb 2005 01:21:08 -0000 On Thu, 24 Feb 2005 01:06:54 +0100, Markus Trippelsdorf wrote: > On Wed, 2005-02-23 at 19:35 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote: > > David O'Brien wrote: > > > On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wrote: > > > > > >>When copying large files to a locally mounted ext2 filesystem > > >>my system always locks up. > > >>Is this a known problem in 64bit mode? > > > > Just curious: what is the drive interface with the ext2fs? IDE? >=20 > Yes, it's the normal IDE interface (ATA UDMA133 drive). >=20 > > The very same hardware is now on 32-bit mode FreeBSD 5.3-stable, withou= t > > any problems at all. > > > > >>Which filesystem is recommended for multi-OS file exchange? > > > > > > I've heard enought reports of ext2 problems on 32-bit i386, that I do= n't > > > trust it in situations that "have to work". By far the most widely > > > supported FS is vfat32 [mount_msdosfs(8)]. > > > > The last time I had to use msdosfs, on 4.* it was extremely slow > > compared to UFS on the same disk. Did this get better on 5.*? >=20 > I want to use the filesystem for my music collection, so I'm willing to > trade fastness for reliability. >=20 > __ > Markus >=20 >=20 > _______________________________________________ > 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" >=20 vfat32/MSDOSFS is going to be the most supported, seeing as I can mount these types of filesystems on just about every OS out there. Regarding speed, there's a pretty big tradeoff, but even if it reduces drive I/O by %50, you're still above the speed of a 10/100 NIC, and certainly above the speed an MP3 streams at. (You're right at the limit, for DVD Video) In short, yes, it will be slower, but for the purposes of storing MP3s, and whatnot, the speed tradeoff is inconsequencial(sp), and it beats loosing everything every once in awhile. --- Harrison Grundy From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 02:39:45 2005 Return-Path: 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 016BD16A4CE for ; Thu, 24 Feb 2005 02:39:45 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5FF543D48 for ; Thu, 24 Feb 2005 02:39:44 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id j1O2dhAf039538; Wed, 23 Feb 2005 18:39:43 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id j1O2dgrb039537; Wed, 23 Feb 2005 18:39:42 -0800 (PST) (envelope-from obrien) Date: Wed, 23 Feb 2005 18:39:42 -0800 From: "David O'Brien" To: Scott Long Message-ID: <20050224023942.GA39443@dragon.nuxi.com> References: <421C4B1B.5070102@mail.uni-mainz.de> <20050223180142.GB26395@dragon.nuxi.com> <421CC86E.2050509@mail.uni-mainz.de> <421CD345.2060305@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421CD345.2060305@samsco.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.8i cc: "O. Hartmann" cc: freebsd-amd64@freebsd.org Subject: Re: More than 4 GBytes RAM on Socket939 system? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Thu, 24 Feb 2005 02:39:45 -0000 On Wed, Feb 23, 2005 at 12:02:29PM -0700, Scott Long wrote: > O. Hartmann wrote: > > > >AMD64 processores only address 4 memory slots and can not address > > > >128MBit memory chips, > > > > > >What is a 128 MBit chip? > > > >I found this info on ASUS homepage for the A8N-SLI and it means (I think) > >a single IC, 128MBit x 8 organized. > > I guess you're implying that the memory controller on the 939 only has > enough address decode and refresh logic to drive DRAM chips of a certain > maximum size? David, can you comment? I don't know enough about the ?weirder? DIMM organizations to comment. I can say that a 939-pin Athlon64 has a dual-channel memory controller. If only one of the dual-channels is populated, one does 64-bit accesses. If both channels are [evenly] populated, one does 128-bit accesses. One can use 2GB non-registered DIMM's in a 939-pin Athlon64 system. 4GB DIMM's don't exist in the desktop(workstation) space yet, so I won't comment on them. From an address-line POV, they will work fine. From an electrical POV maybe there could be issues if manufacturers push the JEDEC spec beyond its limits. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 08:33:13 2005 Return-Path: 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 770E416A4CE for ; Thu, 24 Feb 2005 08:33:13 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D1E343D2D for ; Thu, 24 Feb 2005 08:33:13 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 924A1C9BEE for ; Thu, 24 Feb 2005 00:33:12 -0800 (PST) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21836-04 for ; Thu, 24 Feb 2005 00:33:10 -0800 (PST) Received: from [192.168.15.103] (dsl081-069-073.sfo1.dsl.speakeasy.net [64.81.69.73]) by mail.trippynames.com (Postfix) with ESMTP id 5E562C9BE7 for ; Thu, 24 Feb 2005 00:33:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050222195750.GA40969@sean.gigave.com> References: <20050221211056.GC826@sean.gigave.com> <421ACBFF.6030606@samsco.org> <20050222195750.GA40969@sean.gigave.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8c775b6238bd39c25bc895142ca5190c@chittenden.org> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Thu, 24 Feb 2005 00:33:09 -0800 To: amd64@freebsd.org X-Mailer: Apple Mail (2.619.2) Subject: vrele: negative ref cnt (was: Re: Crash dumps not working correctly for amd64?) 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: Thu, 24 Feb 2005 08:33:13 -0000 So, buried in the last email I sent out was the actual panic string for the dumps I've been having. Has anyone else seen this or is this a known problem? I haven't been able to extract a correct dump yet. I just dd(1)'ed the swap partition hoping that next time it dumps, there will be a clean dump that I can extract a backtrace from, however I'm not too hopeful that this will work as a fix for me. Regardless, I'd assume that twa(1) + amd64 work fine together? This crash seems to emanate from the file system code so I doubt it's driver related. Anyone know what could lead to this? Feel free to send me in the direction of fs@ if I'm not the only one having this problem or that this isn't amd64 specific. Right now I can generally trigger this once every 24hrs, so it's becoming something of a problem for me and without a valid dump, I'm not sure where to begin. -sc > # savecore -vf > bounds number: 9 > checking for kernel dump on device /dev/da0s1b > mediasize = 3221225472 > sectorsize = 512 > magic mismatch on last dump header on /dev/da0s1b > forcing magic on /dev/da0s1b > savecore: first and last dump headers disagree on /dev/da0s1b > savecore: reboot after panic: vrele: negative ref cnt > Checking for available free space > Dump header from device /dev/da0s1b > Architecture: amd64 > Architecture Version: 16777216 > Dump Length: 2146631680B (2047 MB) > Blocksize: 512 > Dumptime: Thu Dec 16 03:06:24 2004 > Hostname: nfs.example.com > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 5.3-STABLE #1: Wed Dec 8 22:20:38 PST 2004 > root@nfs.example.com:/usr/obj/usr/src/sys/NFS > Panic String: vrele: negative ref cnt > Dump Parity: 1999448632 > Bounds: 9 > Dump Status: bad > savecore: writing core to vmcore.9 > 2146631680 -- Sean Chittenden From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 12:05:21 2005 Return-Path: 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 7B42616A4CE for ; Thu, 24 Feb 2005 12:05:21 +0000 (GMT) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id F411943D3F for ; Thu, 24 Feb 2005 12:05:20 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id C40A217017; Thu, 24 Feb 2005 09:05:19 -0300 (BRT) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35026-03; Thu, 24 Feb 2005 09:05:16 -0300 (BRT) Received: from [10.0.8.17] (nat.int.gov.br [200.20.196.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id 1255B1701B; Thu, 24 Feb 2005 09:05:16 -0300 (BRT) Message-ID: <421DC2FB.1020300@jonny.eng.br> Date: Thu, 24 Feb 2005 09:05:15 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Trippelsdorf References: <1109172559.702.13.camel@bsd.trippelsdorf.de> <20050223175725.GA26395@dragon.nuxi.com> <421D052D.3030909@jonny.eng.br> <1109203614.577.5.camel@bsd.trippelsdorf.de> In-Reply-To: <1109203614.577.5.camel@bsd.trippelsdorf.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at coe.ufrj.br cc: freebsd-amd64@freebsd.org Subject: IDE lockups - Was: ext2 filesystem lockups 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: Thu, 24 Feb 2005 12:05:21 -0000 Markus Trippelsdorf wrote: > On Wed, 2005-02-23 at 19:35 -0300, Joăo Carlos Mendes Luís wrote: > >>David O'Brien wrote: >> >>>On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wrote: >>> >>> >>>>When copying large files to a locally mounted ext2 filesystem >>>>my system always locks up. >>>>Is this a known problem in 64bit mode? >> >>Just curious: what is the drive interface with the ext2fs? IDE? > > > Yes, it's the normal IDE interface (ATA UDMA133 drive). Could you please test it under UFS, just for debugging purposes? My experience shows that it needs a very large dataset to make the system freeze. My last lock up happened during the pre-downgrade backup, which means copying 200G from one disk to the other on the same IDE interface. Your mileage may vary. A question for the list: Is there an official "maintainer" for IDE/ATA interface? What kind of debugging could we do to help? >>The very same hardware is now on 32-bit mode FreeBSD 5.3-stable, without >>any problems at all. >> >> >>>>Which filesystem is recommended for multi-OS file exchange? >>> >>>I've heard enought reports of ext2 problems on 32-bit i386, that I don't >>>trust it in situations that "have to work". By far the most widely >>>supported FS is vfat32 [mount_msdosfs(8)]. >> >>The last time I had to use msdosfs, on 4.* it was extremely slow >>compared to UFS on the same disk. Did this get better on 5.*? > > I want to use the filesystem for my music collection, so I'm willing to > trade fastness for reliability. If you use only linux and BSD, choose ext2fs or ufs depending on which OS you use most. If you need windows, then you must choose between msdosfs or ext2fs, since I do not yet know about an UFS driver for windows. From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 12:20:27 2005 Return-Path: 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 4A0CC16A4CE for ; Thu, 24 Feb 2005 12:20:27 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A83743D75 for ; Thu, 24 Feb 2005 12:20:27 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1OCKQP0037759 for ; Thu, 24 Feb 2005 12:20:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1OCKQIo037758; Thu, 24 Feb 2005 12:20:26 GMT (envelope-from gnats) Date: Thu, 24 Feb 2005 12:20:26 GMT Message-Id: <200502241220.j1OCKQIo037758@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Kent Palmkvist Subject: Re: amd64/77949: Pb boot FreeBSD 64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Kent Palmkvist List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 12:20:27 -0000 The following reply was made to PR amd64/77949; it has been noted by GNATS. From: Kent Palmkvist To: freebsd-gnats-submit@FreeBSD.org, lenaig@wanadoo.fr Cc: Subject: Re: amd64/77949: Pb boot FreeBSD 64 Date: Thu, 24 Feb 2005 13:12:18 +0100 Hi, Please try to disable the legacy USB Support in BIOS. This helped with an Acer Aspire 1522 WLMi (also a VIA chipset) that did not like to boot from any amd64 FreeBSD version. Remember to still disable the acpi. The latest current snapshot will probably allow the ACPI to be enabled. /Kent From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 15:13:52 2005 Return-Path: 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 7DD7616A4CE for ; Thu, 24 Feb 2005 15:13:52 +0000 (GMT) Received: from wmptl.net (mail.wmptl.com [216.8.159.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1BA843D46 for ; Thu, 24 Feb 2005 15:13:51 +0000 (GMT) (envelope-from nvidican@wmptl.com) Received: from r3140ca ([10.0.0.104]) by wmptl.net (8.13.1/8.12.9) with ESMTP id j1OFDrmn036787 for ; Thu, 24 Feb 2005 10:13:53 -0500 (EST) From: "Nathan Vidican" To: Date: Thu, 24 Feb 2005 10:13:52 -0500 Message-ID: <000201c51a83$73157070$6800000a@r3140ca> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 Importance: Normal X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.44 Subject: OT Hardware reccomendtions (need MB for Dual Opterons) 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: Thu, 24 Feb 2005 15:13:52 -0000 Hey all We've got several dual opteron boxes now running FreeBSD, (they've been great thus far btw), and we're looking to add a few more... Problem seems to be that the motherboard we've been using is quite difficult to obtain, so does anyone have any good suggestions towards another? Here's the configuration as we're using now: Dual AMD Opteron 246 CPU MSI K8D Master3-FA4R ( http://www.msicomputer.com/product/p_spec.asp?model=K8D_Master3-FA4R&class=s pd ) 2 GB ECC Registered PC2700 (DDR333) Memory 3Ware Escalade 9500s-4LP RAID Controller 250GB WDC RAID Edition Hardrives Ideally, we need to find a new motherboard to source for similar if not identical systems. We tend to find one board we like and stick with it, but having little experience with Opterons in general outside of the ones we already have using this MSI board, I'm hoping you all might have a suggestion or two. I've been told the Tyan boards are usually pretty good, but have not used any before and figured I might as well ask around first. Please reply via email if you will, and cc the list if need be; this address is not subscribed to the list - thanks. -- Nathan Vidican nvidican@wmptl.com Windsor Match Plate & Tool Ltd. http://www.wmplt.com/ From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 17:20:19 2005 Return-Path: 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 BFA2F16A4CE for ; Thu, 24 Feb 2005 17:20:19 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F4C043D5C for ; Thu, 24 Feb 2005 17:20:19 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j1OHKHA6010199; Fri, 25 Feb 2005 04:20:17 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j1OHKFMq022211; Fri, 25 Feb 2005 04:20:16 +1100 Date: Fri, 25 Feb 2005 04:20:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Astrodog In-Reply-To: <2fd864e05022317214525e8f2@mail.gmail.com> Message-ID: <20050225033921.C99633@delplex.bde.org> References: <1109172559.702.13.camel@bsd.trippelsdorf.de> <421D052D.3030909@jonny.eng.br> <2fd864e05022317214525e8f2@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-amd64@freebsd.org cc: Markus Trippelsdorf Subject: Re: ext2 filesystem lockups 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: Thu, 24 Feb 2005 17:20:19 -0000 On Wed, 23 Feb 2005, Astrodog wrote: > On Thu, 24 Feb 2005 01:06:54 +0100, Markus Trippelsdorf > wrote: > > On Wed, 2005-02-23 at 19:35 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote: > > > David O'Brien wrote: > > > > On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wrote= : > > > >>Which filesystem is recommended for multi-OS file exchange? > > > > > > > > I've heard enought reports of ext2 problems on 32-bit i386, that I = don't > > > > trust it in situations that "have to work". By far the most widely I use it with no problems and trust it is easy to fix if some turn up. I haven't tried it on amd64. > > > > supported FS is vfat32 [mount_msdosfs(8)]. > > > > > > The last time I had to use msdosfs, on 4.* it was extremely slow > > > compared to UFS on the same disk. Did this get better on 5.*? The main slownesses in msdosfs are pessimal (random) block allocation for the first block in a file, and non-use of some important system features (clustering and VMIO). This has not been fixed in 5.x AFAIK. > > I want to use the filesystem for my music collection, so I'm willing to > > trade fastness for reliability. ffs is the most reliable of the read-write file systems in FreeBSD. cd9660 is probably more reliable, and it is most portable, but it is less convenient since it is read-only in the kernel. If you only need to write under one OS then it is fairly safe to use ffs for writing under FreeBSD and ext2fs for writing under Linux. > vfat32/MSDOSFS is going to be the most supported, seeing as I can > mount these types of filesystems on just about every OS out there. > Regarding speed, there's a pretty big tradeoff, but even if it reduces > drive I/O by %50, you're still above the speed of a 10/100 NIC, and A big reduction is 99% :-). Reductions of 90% are common for small files. > certainly above the speed an MP3 streams at. (You're right at the > limit, for DVD Video) In short, yes, it will be slower, but for the > purposes of storing MP3s, and whatnot, the speed tradeoff is > inconsequencial(sp), and it beats loosing everything every once in > awhile. But msdosfs is fundamentally very unreliable. Corrupted FATs give more global problems than corrupted inodes. It doesn't help that the msdosfs implementation cheats with FAT updates and does them fully asynchronously (delayed up to 30+ seconds) using delayed writes unless you mount with "-o sync" (which gives sync data too, and thus extreme slowness). So msdosfs by default is closer to ffs with "-o async" and thus more unreliable then necessary. Bruce From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 03:57:11 2005 Return-Path: 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 D84B216A4CE for ; Fri, 25 Feb 2005 03:57:11 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F46C43D60 for ; Fri, 25 Feb 2005 03:57:11 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so316966wra for ; Thu, 24 Feb 2005 19:57:10 -0800 (PST) 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:references; b=SkuVP3Pfh5ampjcUirBYQHCvEoqIVeXMxOYcAI/d4LfyrCueJUVc6MuXTa8g57PbuEKKX3EzPQqeW8CdFVE2J70Woe89Bg2RZooxInLhAsxIGrUmM/nuKPdC1ZGMi7ck+YwiiupeAbNBeFw3q73LsHWHYdtiMc6PTYRQWksk/0Q= Received: by 10.54.40.16 with SMTP id n16mr104528wrn; Thu, 24 Feb 2005 19:57:10 -0800 (PST) Received: by 10.54.40.69 with HTTP; Thu, 24 Feb 2005 19:57:10 -0800 (PST) Message-ID: <2fd864e05022419574174f2c0@mail.gmail.com> Date: Thu, 24 Feb 2005 19:57:10 -0800 From: Astrodog To: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= In-Reply-To: <421DC2FB.1020300@jonny.eng.br> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <1109172559.702.13.camel@bsd.trippelsdorf.de> <20050223175725.GA26395@dragon.nuxi.com> <421D052D.3030909@jonny.eng.br> <1109203614.577.5.camel@bsd.trippelsdorf.de> <421DC2FB.1020300@jonny.eng.br> cc: freebsd-amd64@freebsd.org cc: Markus Trippelsdorf Subject: Re: IDE lockups - Was: ext2 filesystem lockups X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 25 Feb 2005 03:57:12 -0000 On Thu, 24 Feb 2005 09:05:15 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote: > Markus Trippelsdorf wrote: > > On Wed, 2005-02-23 at 19:35 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote: > > > >>David O'Brien wrote: > >> > >>>On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wrote: > >>> > >>> > >>>>When copying large files to a locally mounted ext2 filesystem > >>>>my system always locks up. > >>>>Is this a known problem in 64bit mode? > >> > >>Just curious: what is the drive interface with the ext2fs? IDE? > > > > > > Yes, it's the normal IDE interface (ATA UDMA133 drive). >=20 > Could you please test it under UFS, just for debugging purposes? > My experience shows that it needs a very large dataset to make the > system freeze. My last lock up happened during the pre-downgrade > backup, which means copying 200G from one disk to the other on the same > IDE interface. Your mileage may vary. >=20 > A question for the list: Is there an official "maintainer" for > IDE/ATA interface? What kind of debugging could we do to help? >=20 > >>The very same hardware is now on 32-bit mode FreeBSD 5.3-stable, withou= t > >>any problems at all. > >> > >> > >>>>Which filesystem is recommended for multi-OS file exchange? > >>> > >>>I've heard enought reports of ext2 problems on 32-bit i386, that I don= 't > >>>trust it in situations that "have to work". By far the most widely > >>>supported FS is vfat32 [mount_msdosfs(8)]. > >> > >>The last time I had to use msdosfs, on 4.* it was extremely slow > >>compared to UFS on the same disk. Did this get better on 5.*? > > > > I want to use the filesystem for my music collection, so I'm willing to > > trade fastness for reliability. >=20 > If you use only linux and BSD, choose ext2fs or ufs depending on > which OS you use most. If you need windows, then you must choose > between msdosfs or ext2fs, since I do not yet know about an UFS driver > for windows. > _______________________________________________ > 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" >=20 Reliability, on something that may be detatched is.... non-existant on ext2 in my experence. From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 03:58:28 2005 Return-Path: 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 EE69416A4CE for ; Fri, 25 Feb 2005 03:58:28 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 707B143D3F for ; Fri, 25 Feb 2005 03:58:28 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so317154wra for ; Thu, 24 Feb 2005 19:58:28 -0800 (PST) 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:references; b=sl637keCtsNCpcj/JePw3UGVH4sOkcrUm8keDji3VbmV3RYBKIG0IeR+ZwQpfsfA7l3s7CnPjxJka+J/butCdvE/dLHi4+3kN2USje4AeOzXw92DDyd5TIMmp1R/nrO3ocjSN2/xqKeVWP6RPo+HitUGmaFnZxWrQn0JjxMZE3o= Received: by 10.54.7.72 with SMTP id 72mr22759wrg; Thu, 24 Feb 2005 19:58:28 -0800 (PST) Received: by 10.54.40.69 with HTTP; Thu, 24 Feb 2005 19:58:27 -0800 (PST) Message-ID: <2fd864e0502241958501f8f6a@mail.gmail.com> Date: Thu, 24 Feb 2005 19:58:27 -0800 From: Astrodog To: Nathan Vidican In-Reply-To: <000201c51a83$73157070$6800000a@r3140ca> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000201c51a83$73157070$6800000a@r3140ca> cc: amd64@freebsd.org Subject: Re: OT Hardware reccomendtions (need MB for Dual Opterons) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 25 Feb 2005 03:58:29 -0000 On Thu, 24 Feb 2005 10:13:52 -0500, Nathan Vidican wrote: > Hey all > > We've got several dual opteron boxes now running FreeBSD, (they've been > great thus far btw), and we're looking to add a few more... Problem seems to > be that the motherboard we've been using is quite difficult to obtain, so > does anyone have any good suggestions towards another? Here's the > configuration as we're using now: > > Dual AMD Opteron 246 CPU > MSI K8D Master3-FA4R ( > http://www.msicomputer.com/product/p_spec.asp?model=K8D_Master3-FA4R&class=s > pd ) > 2 GB ECC Registered PC2700 (DDR333) Memory > 3Ware Escalade 9500s-4LP RAID Controller > 250GB WDC RAID Edition Hardrives > > Ideally, we need to find a new motherboard to source for similar if not > identical systems. We tend to find one board we like and stick with it, but > having little experience with Opterons in general outside of the ones we > already have using this MSI board, I'm hoping you all might have a > suggestion or two. I've been told the Tyan boards are usually pretty good, > but have not used any before and figured I might as well ask around first. > > Please reply via email if you will, and cc the list if need be; this address > is not subscribed to the list - thanks. > > -- > Nathan Vidican > nvidican@wmptl.com > Windsor Match Plate & Tool Ltd. > http://www.wmplt.com/ > > _______________________________________________ > 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" > Tyan S2850s and S2882s have run great for me. For some reason, the BGE nic does much better on -STABLE though. *shrug* From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 04:00:13 2005 Return-Path: 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 D37F016A4CF for ; Fri, 25 Feb 2005 04:00:13 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 211BF43D60 for ; Fri, 25 Feb 2005 04:00:13 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so317345wra for ; Thu, 24 Feb 2005 20:00:12 -0800 (PST) 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:references; b=R0nGfbrv2XpeCK8AHgDS1LunSE820BAsYZvziqRCvaySsMpbJ+lbeqoYl126qzyogqA9XEgU3dHXKMkg85/SBL5vYTrOAHzrKrEjoiFOYjBqIXatfv1OTw0DCTYyp7EndYO1c11T7BNtc3XQeyzuY2j27lxE9EqM/1En7rQkjvI= Received: by 10.54.41.68 with SMTP id o68mr170692wro; Thu, 24 Feb 2005 20:00:12 -0800 (PST) Received: by 10.54.40.69 with HTTP; Thu, 24 Feb 2005 20:00:12 -0800 (PST) Message-ID: <2fd864e050224200035fa57ae@mail.gmail.com> Date: Thu, 24 Feb 2005 20:00:12 -0800 From: Astrodog To: Bruce Evans In-Reply-To: <20050225033921.C99633@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <1109172559.702.13.camel@bsd.trippelsdorf.de> <421D052D.3030909@jonny.eng.br> <1109203614.577.5.camel@bsd.trippelsdorf.de> <2fd864e05022317214525e8f2@mail.gmail.com> <20050225033921.C99633@delplex.bde.org> cc: freebsd-amd64@freebsd.org cc: Markus Trippelsdorf Subject: Re: ext2 filesystem lockups X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 25 Feb 2005 04:00:14 -0000 On Fri, 25 Feb 2005 04:20:15 +1100 (EST), Bruce Evans wro= te: > On Wed, 23 Feb 2005, Astrodog wrote: >=20 > > On Thu, 24 Feb 2005 01:06:54 +0100, Markus Trippelsdorf > > wrote: > > > On Wed, 2005-02-23 at 19:35 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote: > > > > David O'Brien wrote: > > > > > On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wro= te: > > > > >>Which filesystem is recommended for multi-OS file exchange? > > > > > > > > > > I've heard enought reports of ext2 problems on 32-bit i386, that = I don't > > > > > trust it in situations that "have to work". By far the most wide= ly >=20 > I use it with no problems and trust it is easy to fix if some turn up. > I haven't tried it on amd64. >=20 > > > > > supported FS is vfat32 [mount_msdosfs(8)]. > > > > > > > > The last time I had to use msdosfs, on 4.* it was extremely slow > > > > compared to UFS on the same disk. Did this get better on 5.*? >=20 > The main slownesses in msdosfs are pessimal (random) block allocation > for the first block in a file, and non-use of some important system > features (clustering and VMIO). This has not been fixed in 5.x AFAIK. >=20 > > > I want to use the filesystem for my music collection, so I'm willing = to > > > trade fastness for reliability. >=20 > ffs is the most reliable of the read-write file systems in FreeBSD. > cd9660 is probably more reliable, and it is most portable, but it is > less convenient since it is read-only in the kernel. If you only need > to write under one OS then it is fairly safe to use ffs for writing > under FreeBSD and ext2fs for writing under Linux. >=20 > > vfat32/MSDOSFS is going to be the most supported, seeing as I can > > mount these types of filesystems on just about every OS out there. > > Regarding speed, there's a pretty big tradeoff, but even if it reduces > > drive I/O by %50, you're still above the speed of a 10/100 NIC, and >=20 > A big reduction is 99% :-). Reductions of 90% are common for small > files. >=20 > > certainly above the speed an MP3 streams at. (You're right at the > > limit, for DVD Video) In short, yes, it will be slower, but for the > > purposes of storing MP3s, and whatnot, the speed tradeoff is > > inconsequencial(sp), and it beats loosing everything every once in > > awhile. >=20 > But msdosfs is fundamentally very unreliable. Corrupted FATs give more > global problems than corrupted inodes. It doesn't help that the msdosfs > implementation cheats with FAT updates and does them fully asynchronously > (delayed up to 30+ seconds) using delayed writes unless you mount with > "-o sync" (which gives sync data too, and thus extreme slowness). So > msdosfs by default is closer to ffs with "-o async" and thus more > unreliable then necessary. >=20 > Bruce >=20 I suppose the real lesson here, is why would you want to use anything that doesn't support UFS? ;) From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 04:50:22 2005 Return-Path: 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 4304C16A4CE; Fri, 25 Feb 2005 04:50:22 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C413243D55; Fri, 25 Feb 2005 04:50:21 +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 j1P4oLlL011680; Thu, 24 Feb 2005 23:50:21 -0500 (EST) (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.1/8.13.1) with ESMTP id j1P4oLFZ057762; Thu, 24 Feb 2005 23:50:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 378527306E; Thu, 24 Feb 2005 23:50:21 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050225045021.378527306E@freebsd-current.sentex.ca> Date: Thu, 24 Feb 2005 23:50:21 -0500 (EST) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2005 04:50:22 -0000 TB --- 2005-02-25 03:21:51 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-25 03:21:51 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-02-25 03:21:51 - checking out the source tree TB --- 2005-02-25 03:21:51 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-02-25 03:21:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-25 03:27:45 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-25 03:27:45 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-02-25 03:27:45 - /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 TB --- 2005-02-25 04:35:07 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-25 04:35:07 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-02-25 04:35:07 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Feb 25 04:35:07 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 Feb 25 04:50:19 UTC 2005 TB --- 2005-02-25 04:50:19 - generating LINT kernel config TB --- 2005-02-25 04:50:19 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-02-25 04:50:19 - /usr/bin/make -B LINT TB --- 2005-02-25 04:50:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-25 04:50:19 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-02-25 04:50:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 25 04:50:19 UTC 2005 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT config: Error: device "acpi_perf" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-02-25 04:50:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-25 04:50:20 - ERROR: failed to build lint kernel TB --- 2005-02-25 04:50:20 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 08:07:40 2005 Return-Path: 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 CBED316A4CE for ; Fri, 25 Feb 2005 08:07:40 +0000 (GMT) Received: from webmail.uoi.gr (webmail.uoi.gr [195.130.120.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DCE743D5C for ; Fri, 25 Feb 2005 08:07:39 +0000 (GMT) (envelope-from dkouroun@cc.uoi.gr) Received: from webmail.uoi.gr (localhost [127.0.0.1])j1P87ZM3002471 for ; Fri, 25 Feb 2005 10:07:35 +0200 Received: (from wwwrun@localhost) by webmail.uoi.gr (8.12.10/8.12.10/Submit) id j1P87ZnQ002470 for freebsd-amd64@freebsd.org; Fri, 25 Feb 2005 10:07:35 +0200 Received: from pc159.materials.uoi.gr (pc159.materials.uoi.gr [195.130.113.159]) by webmail.uoi.gr (IMP) with HTTP for ; Fri, 25 Feb 2005 10:07:34 +0200 Message-ID: <1109318854.421edcc6f2438@webmail.uoi.gr> Date: Fri, 25 Feb 2005 10:07:34 +0200 From: dkouroun@cc.uoi.gr To: freebsd-amd64@freebsd.org References: <20050224120052.EBFB416A4CE@hub.freebsd.org> In-Reply-To: <20050224120052.EBFB416A4CE@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 195.130.113.159 Subject: FreeBSD 4.? or 5.? for a quad AMD-OPTERON 848 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: Fri, 25 Feb 2005 08:07:40 -0000 Dear AMD64 people, I just bought a quad AMD Opteron 848 server. I am interested in running numerically intensive programs which write large files (about 128MB) of scientific data on the hard disk and simulations last for -3 days! What I desperately need is having intel-icc doing well its OpenMP job in FreeBSD as well it does in Linux! 1) Having all that in mind can anybody let me know which FreeBSD to install 4.11 or 5.X such that I have as few stability problems as possible and at the same time performance similar or even better than Linux? 2:) I have encountered a lot of stability problems with 5-3 RELEASE for i386 architectures. How can I upgrade 5-3 to some stable version? 3:) Would it be preferable to upgrade to some 6-current? Thanks in advance! D.K. From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 10:02:22 2005 Return-Path: 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 AFDE916A4CE for ; Fri, 25 Feb 2005 10:02:22 +0000 (GMT) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2AE243D31 for ; Fri, 25 Feb 2005 10:02:19 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id E17A084451; Fri, 25 Feb 2005 11:02:14 +0100 (CET) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 96462-01; Fri, 25 Feb 2005 11:02:06 +0100 (CET) Received: from [172.16.129.72] (japan.axelero.com [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTP id 9364D84408; Fri, 25 Feb 2005 11:02:05 +0100 (CET) Message-ID: <421EF79D.4030105@fsn.hu> Date: Fri, 25 Feb 2005 11:02:05 +0100 From: Attila Nagy User-Agent: Mozilla Thunderbird 1.0 (X11/20050103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dkouroun@cc.uoi.gr References: <20050224120052.EBFB416A4CE@hub.freebsd.org> <1109318854.421edcc6f2438@webmail.uoi.gr> In-Reply-To: <1109318854.421edcc6f2438@webmail.uoi.gr> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu cc: freebsd-amd64@freebsd.org Subject: Re: FreeBSD 4.? or 5.? for a quad AMD-OPTERON 848 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: Fri, 25 Feb 2005 10:02:22 -0000 dkouroun@cc.uoi.gr wrote: > I just bought a quad AMD Opteron 848 server. I am interested > in running numerically intensive programs which write large files > (about 128MB) of scientific data on the hard disk and simulations last for > -3 days! What I desperately need is having intel-icc doing well its OpenMP > job in FreeBSD as well it does in Linux! If you want to generate AMD64 code (EM64T) with Intel icc, you have to wait. Alexander Leidinger is currently working on the issues which arose with the 32 bit Linux icc binary on FreeBSD/AMD64. I am eagerly waiting for his patches :) -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758 From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 12:53:52 2005 Return-Path: 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 8FB2716A4CE for ; Fri, 25 Feb 2005 12:53:52 +0000 (GMT) Received: from web52310.mail.yahoo.com (web52310.mail.yahoo.com [206.190.39.105]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D85843D53 for ; Fri, 25 Feb 2005 12:53:52 +0000 (GMT) (envelope-from dystopianrebel@yahoo.com) Received: (qmail 51803 invoked by uid 60001); 25 Feb 2005 12:53:50 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=doc4FxnUT0vUA0Jo8WGDuCOwVd12srHUSNz6G3amFqnMgrxLFTpyFBrEHXPXuDZheAa9dOMwnkj/MIDYl2nnmCW3wj6nxMAYzfH8CzQvVQW3JQpP68exRfYSzqhQZFIZFJcdmVpE3eUJqJElRpSsDfyc8KQThF7ifMn8HyC/Wws= ; Message-ID: <20050225125350.51801.qmail@web52310.mail.yahoo.com> Received: from [64.26.160.170] by web52310.mail.yahoo.com via HTTP; Fri, 25 Feb 2005 04:53:50 PST Date: Fri, 25 Feb 2005 04:53:50 -0800 (PST) From: dR To: freebsd-amd64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: OpenOffice, 5.3 Release, AMD64: is it true there's no love? 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: Fri, 25 Feb 2005 12:53:52 -0000 I really need OpenOffice to complete a project. I have the impression that other people have got {5.3, amd64, OO} working. Let's see if I have grokked the possibilities. WITH JAVA: - OO ~with~ Java requires JDK with patchfiles - there is no native binary distribution of JDK for FreeBSD - to build the JDK, we need patchfiles in ports/distfiles and some Sun files, an fstab entry for Linux, and Linux compatibility - Linux compatibility requires recompiling the kernel; I've done that, but I can't reboot the box just any old time -- it's a server WITHOUT JAVA: - OO ~without~ Java requires gcc32 - gcc32 fails to compile with the message, "===> gcc-3.2.3_3 does not run on amd64, and you are running amd64." - I read in the archive (January 1st message) that we could use "gcc-OOO" but all the mirrors return "File unavailable (e.g., file not found, no access)"; and in the same post, it was said that there would be further compiling problems with OO anyway If you have {5.3, amd64, OO} working, or can tell me what to do, for the love of G*d please mail me or post a reply. Will submit patches for food. Marko __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 13:12:45 2005 Return-Path: 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 B9ACD16A4CE for ; Fri, 25 Feb 2005 13:12:45 +0000 (GMT) Received: from mail.cpinternet.com (mail.cpinternet.com [209.240.224.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D2E443D5D for ; Fri, 25 Feb 2005 13:12:45 +0000 (GMT) (envelope-from mharnois@cpinternet.com) X-Node: 4 Received: from mharnois.mdharnois.net (customer-mpls-23.cpinternet.com [209.240.253.23]) by mail.cpinternet.com (8.12.10/8.12.10) with ESMTP id j1PDCiUR015706 for ; Fri, 25 Feb 2005 07:12:44 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mharnois.mdharnois.net (Postfix) with ESMTP id 9DF277AC2D for ; Fri, 25 Feb 2005 07:12:40 -0600 (CST) Received: from mharnois.mdharnois.net ([127.0.0.1]) by localhost (mharnois.mdharnois.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26717-10 for ; Fri, 25 Feb 2005 07:12:40 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mharnois.mdharnois.net (Postfix) with ESMTP id 50E527AC2C for ; Fri, 25 Feb 2005 07:12:40 -0600 (CST) From: Michael Harnois To: freebsd-amd64@freebsd.org Date: Fri, 25 Feb 2005 07:12:37 -0600 User-Agent: KMail/1.7 References: <20050225125350.51801.qmail@web52310.mail.yahoo.com> In-Reply-To: <20050225125350.51801.qmail@web52310.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502250712.38173.mharnois@cpinternet.com> X-Virus-Scanned: amavisd-new at mdharnois.net Subject: Re: OpenOffice, 5.3 Release, AMD64: is it true there's no love? 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: Fri, 25 Feb 2005 13:12:45 -0000 On Friday 25 February 2005 06:53 am, dR wrote: > - I read in the archive (January 1st message) that we > could use "gcc-OOO" but all the mirrors return "File > unavailable (e.g., file not found, no access)"; and in > the same post, it was said that there would be further > compiling problems with OO anyway The path is wrong. I can't tell you now what the correct path is but if you ftp to any of the servers it will be apparent where to go. Once I got the sources gcc-OOO built fine. As for OO ... it's building now. I couldn't get Java or Mozilla integration to work. -- Michael D. Harnois Hugo, Minnesota Wise men talk because they have something to say; fools, because they have to say something. -- Plato From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 14:14:24 2005 Return-Path: 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 05E9416A4CE for ; Fri, 25 Feb 2005 14:14:24 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DA5B43D39 for ; Fri, 25 Feb 2005 14:14:23 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ICH00B5T0N1N0E0@bgo1smout1.broadpark.no> for freebsd-amd64@freebsd.org; Fri, 25 Feb 2005 15:09:01 +0100 (CET) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ICH00IGW0ZJVL00@bgo1sminn1.broadpark.no> for freebsd-amd64@freebsd.org; Fri, 25 Feb 2005 15:16:31 +0100 (CET) Received: by dsa.des.no (Pony Express, from userid 666) id 99D7545408; Fri, 25 Feb 2005 15:14:21 +0100 (CET) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id D39CC4516B; Fri, 25 Feb 2005 15:14:01 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id BD15033C3E; Fri, 25 Feb 2005 15:14:01 +0100 (CET) Date: Fri, 25 Feb 2005 15:14:01 +0100 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <1109318854.421edcc6f2438@webmail.uoi.gr> To: dkouroun@cc.uoi.gr Message-id: <86psyo4thy.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on dsa.des.no References: <20050224120052.EBFB416A4CE@hub.freebsd.org> <1109318854.421edcc6f2438@webmail.uoi.gr> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.0.1 X-Spam-Level: cc: freebsd-amd64@freebsd.org Subject: Re: FreeBSD 4.? or 5.? for a quad AMD-OPTERON 848 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: Fri, 25 Feb 2005 14:14:24 -0000 dkouroun@cc.uoi.gr writes: > 1) Having all that in mind can anybody let me know which FreeBSD to insta= ll > 4.11 or 5.X such that I have as few stability problems as possible and=20 > at the same time performance similar or even better than Linux?=20 FreeBSD 4 won't run in 64-bit mode. You'll have to run FreeBSD 5 or 6. > 3:) Would it be preferable to upgrade to some 6-current? I would. Performance is likely to be better (especially with the soon-to-come thread library improvements). It's more work, though. Beware that -CURRENT snapshots between 2005/02/16 and 2005/02/24 will be very unstable due to a VM bug which was fixed yesterday. A snapshot built from today's sources should be fine. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 17:00:10 2005 Return-Path: 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 781F116A4CE for ; Fri, 25 Feb 2005 17:00:10 +0000 (GMT) Received: from ares.wolfpond.org (ns1.wolfpond.org [62.212.96.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BD2B43D31 for ; Fri, 25 Feb 2005 17:00:09 +0000 (GMT) (envelope-from ftigeot@wolfpond.org) Received: from aoi.wolfpond.org (aoi.wolfpond.org [IPv6:2001:7a8:24db:1:20c:76ff:feb4:27e1]) by ares.wolfpond.org (8.13.3/8.13.3) with ESMTP id j1PH07Tw037688; Fri, 25 Feb 2005 18:00:07 +0100 (CET) (envelope-from ftigeot@aoi.wolfpond.org) Received: from aoi.wolfpond.org (localhost [127.0.0.1]) by aoi.wolfpond.org (8.13.3/8.13.1) with ESMTP id j1PH0AWB006882; Fri, 25 Feb 2005 18:00:10 +0100 (CET) (envelope-from ftigeot@aoi.wolfpond.org) Received: (from ftigeot@localhost) by aoi.wolfpond.org (8.13.3/8.13.1/Submit) id j1PH0AeC006881; Fri, 25 Feb 2005 18:00:10 +0100 (CET) (envelope-from ftigeot) Date: Fri, 25 Feb 2005 18:00:09 +0100 From: Francois Tigeot To: dR Message-ID: <20050225170009.GA6633@aoi.wolfpond.org> References: <20050225125350.51801.qmail@web52310.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050225125350.51801.qmail@web52310.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-amd64@freebsd.org Subject: Re: OpenOffice, 5.3 Release, AMD64: is it true there's no love? 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: Fri, 25 Feb 2005 17:00:10 -0000 On Fri, Feb 25, 2005 at 04:53:50AM -0800, dR wrote: > I really need OpenOffice to complete a project. I have > the impression that other people have got {5.3, amd64, > OO} working. > > If you have {5.3, amd64, OO} working, or can tell me > what to do, for the love of G*d please mail me or post > a reply. Will submit patches for food. I'm afraid the OpenOffice code is not clean enough to run as a 64-bit binary. The only way I found to run OpenOffice was to install the Linux 32-bit version. -- Francois Tigeot From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 17:22:44 2005 Return-Path: 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 8842116A4CE for ; Fri, 25 Feb 2005 17:22:44 +0000 (GMT) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD95743D3F for ; Fri, 25 Feb 2005 17:22:43 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id 735B717018; Fri, 25 Feb 2005 14:22:41 -0300 (BRT) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66261-04; Fri, 25 Feb 2005 14:22:37 -0300 (BRT) Received: from [10.0.8.17] (nat.int.gov.br [200.20.196.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id 80DFE17017; Fri, 25 Feb 2005 14:22:37 -0300 (BRT) Message-ID: <421F5EDC.3070906@jonny.eng.br> Date: Fri, 25 Feb 2005 14:22:36 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Tigeot References: <20050225125350.51801.qmail@web52310.mail.yahoo.com> <20050225170009.GA6633@aoi.wolfpond.org> In-Reply-To: <20050225170009.GA6633@aoi.wolfpond.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at coe.ufrj.br cc: freebsd-amd64@freebsd.org Subject: Re: OpenOffice, 5.3 Release, AMD64: is it true there's no love? 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: Fri, 25 Feb 2005 17:22:44 -0000 Francois Tigeot wrote: > On Fri, Feb 25, 2005 at 04:53:50AM -0800, dR wrote: >>I really need OpenOffice to complete a project. I have >>the impression that other people have got {5.3, amd64, >>OO} working. >> >>If you have {5.3, amd64, OO} working, or can tell me >>what to do, for the love of G*d please mail me or post >>a reply. Will submit patches for food. > > I'm afraid the OpenOffice code is not clean enough to run as a 64-bit > binary. Doesn´t it run natively on Solaris 64??? From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 17:51:15 2005 Return-Path: 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 BB2A816A4CE for ; Fri, 25 Feb 2005 17:51:15 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 595A843D62 for ; Fri, 25 Feb 2005 17:51:15 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id E9562B2586; Fri, 25 Feb 2005 09:51:14 -0800 (PST) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 66577-07; Fri, 25 Feb 2005 09:51:12 -0800 (PST) Received: from [192.168.15.103] (dsl081-069-073.sfo1.dsl.speakeasy.net [64.81.69.73]) by mail.trippynames.com (Postfix) with ESMTP id 85C7FB24B6; Fri, 25 Feb 2005 09:51:09 -0800 (PST) In-Reply-To: <2fd864e0502241956929bf43@mail.gmail.com> References: <20050221211056.GC826@sean.gigave.com> <421ACBFF.6030606@samsco.org> <20050222195750.GA40969@sean.gigave.com> <8c775b6238bd39c25bc895142ca5190c@chittenden.org> <2fd864e0502241956929bf43@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/mixed; boundary=Apple-Mail-17-50164787 Message-Id: From: Sean Chittenden Date: Fri, 25 Feb 2005 09:51:07 -0800 To: amd64@freebsd.org X-Mailer: Apple Mail (2.619.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: vrele: negative ref cnt (was: Re: Crash dumps not working correctly for amd64?) 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: Fri, 25 Feb 2005 17:51:15 -0000 --Apple-Mail-17-50164787 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed >> So, buried in the last email I sent out was the actual panic string >> for >> the dumps I've been having. Has anyone else seen this or is this a >> known problem? I haven't been able to extract a correct dump yet. I >> just dd(1)'ed the swap partition hoping that next time it dumps, there >> will be a clean dump that I can extract a backtrace from, however I'm >> not too hopeful that this will work as a fix for me. Regardless, I'd >> assume that twa(1) + amd64 work fine together? This crash seems to >> emanate from the file system code so I doubt it's driver related. >> Anyone know what could lead to this? Feel free to send me in the >> direction of fs@ if I'm not the only one having this problem or that >> this isn't amd64 specific. Right now I can generally trigger this >> once >> every 24hrs, so it's becoming something of a problem for me and >> without >> a valid dump, I'm not sure where to begin. -sc >> >>> # savecore -vf >>> bounds number: 9 >>> checking for kernel dump on device /dev/da0s1b >>> mediasize = 3221225472 >>> sectorsize = 512 >>> magic mismatch on last dump header on /dev/da0s1b >>> forcing magic on /dev/da0s1b >>> savecore: first and last dump headers disagree on /dev/da0s1b >>> savecore: reboot after panic: vrele: negative ref cnt >>> Checking for available free space >>> Dump header from device /dev/da0s1b >>> Architecture: amd64 >>> Architecture Version: 16777216 >>> Dump Length: 2146631680B (2047 MB) >>> Blocksize: 512 >>> Dumptime: Thu Dec 16 03:06:24 2004 >>> Hostname: nfs.example.com >>> Magic: FreeBSD Kernel Dump >>> Version String: FreeBSD 5.3-STABLE #1: Wed Dec 8 22:20:38 PST 2004 >>> root@nfs.example.com:/usr/obj/usr/src/sys/NFS >>> Panic String: vrele: negative ref cnt >>> Dump Parity: 1999448632 >>> Bounds: 9 >>> Dump Status: bad >>> savecore: writing core to vmcore.9 >>> 2146631680 > > twe and twa have worked great on my side. Re: the dumps, thats a > bizzare one, what hardware do you have? twa (9K Escalade 8 port), 8x 200GB 7200RPM Maxtor SATA (7x RAID5, 1x hotspare), Athlon64 3000, 2GB of RAM, and... here's the kicker ASUS KV8 Deluxe mobo. I'm not suspecting the hardware, however. > I may be able to recreate, if you've got exact specs, and last time > you cvsup'd to stable. Wednesday, Feb 16th. The machine's doing an insane amount of load for one macchine, esp of this hardware class. Once every few hours (about every 12-24 or so), the machine craps out. It doesn't crap out at peak load, nor at low load times or any time that makes sense. It's been doing this for about a week and I'm certain this bug has nothing to do with usage in any way, shape, or form. I've verified the RAID, the memory, and CPU. I have MySQL listening on lo0, same with memcached(8). What is interesting to me is that before the machine goes AWOL for 20min while it reboots, traffic on lo0 goes crazy insane, then reboots after lo0 goes into its FUBAR state. I'm sure what I'm hitting is a kernel bug and not a bug in the hardware since there are clear indicators that the system dynamics change, but I can't seem to get any dumps out of the machine to even begin diagnosing the problem. It doesn't leave a core, however, and that's irritating, to say the least. Now that it's dumped a few times after I dd(1)'ed the swap partition, I'm not convinced the above error is even the correct error since I haven't seen any core dumps since the dd(1). Strange, no? Anyway, I'm at a loss as to where to begin since I get no diagnostics other than noticing lo0 usage is an indicator of an impending reboot. Here's a graph of lo0. What's important for me to note is that when lo0 starts pushing 100+MB of data across it, it has no bearing on the actual load of the machine or the delivery of the content for the userland programs. Everything looks nominal and is within normal parameters. --Apple-Mail-17-50164787 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I sure hope someone has an "a ha!" brewing, 'cause this isn't making a whole lot of sense to me. I'm probably going to bind everything to a non lo0 interface (ie, em0) in the hopes that there is a locking issue with lo0. If I had to point to any one thing that's strange about the configuration of this machine, it's its very heavy use on lo0 my multiple programs. tia. -sc -- Sean Chittenden --Apple-Mail-17-50164787-- From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 19:06:05 2005 Return-Path: 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 3568C16A4CE for ; Fri, 25 Feb 2005 19:06:05 +0000 (GMT) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B5843D1D for ; Fri, 25 Feb 2005 19:05:59 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from [192.168.245.231] ([213.112.167.149] [213.112.167.149]) by mxfep01.bredband.com with ESMTP id <20050225190554.JWJH17717.mxfep01.bredband.com@[192.168.245.231]> for ; Fri, 25 Feb 2005 20:05:54 +0100 Message-ID: <421F764D.5020107@bredband.net> Date: Fri, 25 Feb 2005 20:02:37 +0100 From: Lars Tunkrans Organization: None User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20041024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <20050225125350.51801.qmail@web52310.mail.yahoo.com> <20050225170009.GA6633@aoi.wolfpond.org> <421F5EDC.3070906@jonny.eng.br> In-Reply-To: <421F5EDC.3070906@jonny.eng.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: OpenOffice, 5.3 Release, AMD64: is it true there's no love? 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: Fri, 25 Feb 2005 19:06:05 -0000 Jo=E3o Carlos Mendes Lu=EDs wrote: > Francois Tigeot wrote: >=20 >> I'm afraid the OpenOffice code is not clean enough to run as a 64-bit >> binary. >=20 >=20 > Doesn=B4t it run natively on Solaris 64??? Yes it does but is still 32-bit binaries. the simultaneous executability of 32-bit and 64-bit apps has been in solaris since the release of Solaris 7. ( 1998 ? ) $ uname -a SunOS rigel 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Blade-1500 $ isainfo -k sparcv9 $ isainfo -v 64-bit sparcv9 applications 32-bit sparc applications $ pwd /opt/staroffice8-beta/program $ file soffice.bin soffice.bin: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Require= d, dynamically linked, stripped //Lars From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 19:43:15 2005 Return-Path: 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 C9ECF16A4CE for ; Fri, 25 Feb 2005 19:43:15 +0000 (GMT) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3342443D46 for ; Fri, 25 Feb 2005 19:43:15 +0000 (GMT) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (localhost [127.0.0.1]) by manor.msen.com (8.12.9p2/8.12.9) with ESMTP id j1PJhBTA041147 for ; Fri, 25 Feb 2005 14:43:14 -0500 (EST) (envelope-from wayne@manor.msen.com) Received: (from wayne@localhost) by manor.msen.com (8.12.9p2/8.12.9/Submit) id j1PJhBtt041146 for freebsd-amd64@freebsd.org; Fri, 25 Feb 2005 14:43:11 -0500 (EST) (envelope-from wayne) Date: Fri, 25 Feb 2005 14:43:11 -0500 From: "Michael R. Wayne" To: freebsd-amd64@freebsd.org Message-ID: <20050225194311.GH1168@manor.msen.com> Mail-Followup-To: freebsd-amd64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: AMD64 on Xenon ? 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: Fri, 25 Feb 2005 19:43:16 -0000 I just powered up a dual Xenon system from one of our suppliers. It is acting a bit odd, Eventaully, I realized: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.11-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x441d,MON,DS_CPL,CNTX-ID,> AMD Features=0x20000800 Hyperthreading: 2 logical CPUs But note the last word on uname -a: FreeBSD test.x.com 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 03:50:01 UTC 2004 root@fanboy.samsco.home:/usr/obj/usr/src/sys/GENERIC amd64 So, why would this run at all? I was planning on reinstalling anyway so it's not a huge deal but it seems pretty odd... /\/\ \/\/ From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 20:03:56 2005 Return-Path: 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 E84AC16A4CE for ; Fri, 25 Feb 2005 20:03:56 +0000 (GMT) Received: from ack.Berkeley.EDU (ack.Berkeley.EDU [128.32.206.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4D6543D58 for ; Fri, 25 Feb 2005 20:03:56 +0000 (GMT) (envelope-from mhunter@ack.Berkeley.EDU) Received: (from mhunter@localhost) by ack.Berkeley.EDU (8.11.3/8.11.3) id j1PK3uS29550 for freebsd-amd64@freebsd.org; Fri, 25 Feb 2005 12:03:56 -0800 (PST) Date: Fri, 25 Feb 2005 12:03:56 -0800 From: Mike Hunter To: freebsd-amd64@freebsd.org Message-ID: <20050225200356.GA29206@ack.Berkeley.EDU> References: <20050225194311.GH1168@manor.msen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050225194311.GH1168@manor.msen.com> User-Agent: Mutt/1.5.6i Subject: Re: AMD64 on Xenon ? 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: Fri, 25 Feb 2005 20:03:57 -0000 On Feb 25, "Michael R. Wayne" wrote: > I just powered up a dual Xenon system from one of our suppliers. > It is acting a bit odd, Eventaully, I realized: > > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.11-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 > Features=0xbfebfbff ,TM,PBE> > Features2=0x441d,MON,DS_CPL,CNTX-ID,> > AMD Features=0x20000800 > Hyperthreading: 2 logical CPUs > > But note the last word on uname -a: > FreeBSD test.x.com 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 03:50:01 UTC 2004 root@fanboy.samsco.home:/usr/obj/usr/src/sys/GENERIC amd64 > > So, why would this run at all? I was planning on reinstalling > anyway so it's not a huge deal but it seems pretty odd... The "amd64" architecture should work just fine on Intel EM64 systems. EM64 is intel's codename for their knock-off implementation of AMD's 64 bit x86 extensions. Mike From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 20:05:30 2005 Return-Path: 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 98FD516A4CE for ; Fri, 25 Feb 2005 20:05:30 +0000 (GMT) Received: from ack.Berkeley.EDU (ack.Berkeley.EDU [128.32.206.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66CDD43D2D for ; Fri, 25 Feb 2005 20:05:30 +0000 (GMT) (envelope-from mhunter@ack.Berkeley.EDU) Received: (from mhunter@localhost) by ack.Berkeley.EDU (8.11.3/8.11.3) id j1PK5Un29669 for freebsd-amd64@freebsd.org; Fri, 25 Feb 2005 12:05:30 -0800 (PST) Date: Fri, 25 Feb 2005 12:05:30 -0800 From: Mike Hunter To: freebsd-amd64@freebsd.org Message-ID: <20050225200530.GB29206@ack.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: bash malloc() error on login 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: Fri, 25 Feb 2005 20:05:30 -0000 Hi, I had the following happen when I logged in to my amd64 box: ... You may also use sysinstall(8) to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. You can `set autologout = 30' to have tcsh log you off automatically if you leave the shell idle for more than 30 minutes. -bash in malloc(): warning: recursive call -bash: xmalloc: cannot allocate 48 bytes (0 bytes allocated) I logged in again and everything was fine. Should I write this off as "bash sucks" or is it possible there's something more sinister going on here? Thanks, Mike From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 22:43:29 2005 Return-Path: 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 A9B9B16A4CE for ; Fri, 25 Feb 2005 22:43:29 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99D1D43D55 for ; Fri, 25 Feb 2005 22:43:28 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 8036 invoked by uid 89); 25 Feb 2005 22:45:42 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 25 Feb 2005 22:45:42 -0000 Date: Fri, 25 Feb 2005 23:43:29 +0100 From: Oliver Lehmann To: freebsd-amd64@freebsd.org Message-Id: <20050225234329.0710bc2a.lehmann@ans-netz.de> In-Reply-To: <20050225170009.GA6633@aoi.wolfpond.org> References: <20050225125350.51801.qmail@web52310.mail.yahoo.com> <20050225170009.GA6633@aoi.wolfpond.org> X-Mailer: Sylpheed version 1.9.3 (GTK+ 2.4.14; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: OpenOffice, 5.3 Release, AMD64: is it true there's no love? 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: Fri, 25 Feb 2005 22:43:29 -0000 Francois Tigeot wrote: > I'm afraid the OpenOffice code is not clean enough to run as a 64-bit > binary. > so.. there is no way to run any openoffice on FreeBSD/amd64? I think I've to reconsider buying an amd64 system then... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 25 22:52:47 2005 Return-Path: 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 E2D9A16A4CE for ; Fri, 25 Feb 2005 22:52:47 +0000 (GMT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5738743D39 for ; Fri, 25 Feb 2005 22:52:46 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from [192.168.245.231] ([213.112.167.149] [213.112.167.149]) by mxfep02.bredband.com with ESMTP <20050225225245.KLHP17521.mxfep02.bredband.com@[192.168.245.231]>; Fri, 25 Feb 2005 23:52:45 +0100 Message-ID: <421FAB78.8010708@bredband.net> Date: Fri, 25 Feb 2005 23:49:28 +0100 From: Lars Tunkrans Organization: None User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20041024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oliver Lehmann References: <20050225125350.51801.qmail@web52310.mail.yahoo.com> <20050225170009.GA6633@aoi.wolfpond.org> <20050225234329.0710bc2a.lehmann@ans-netz.de> In-Reply-To: <20050225234329.0710bc2a.lehmann@ans-netz.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org Subject: Re: OpenOffice, 5.3 Release, AMD64: is it true there's no love? 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: Fri, 25 Feb 2005 22:52:48 -0000 Oliver Lehmann wrote: > Francois Tigeot wrote: > > >>I'm afraid the OpenOffice code is not clean enough to run as a 64-bit >>binary. >> > > > so.. there is no way to run any openoffice on FreeBSD/amd64? I think I've > to reconsider buying an amd64 system then... > It is of course possible to install the i386 FreeBSD 5.3 port on an AMD64 system. I have both i386 and AMD64 installations on my Athlon64 3800+ machine. That way I can experiment with 64 bit environment and run 32 bit apps. //Lars From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 26 00:04:11 2005 Return-Path: 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 8212716A4CE for ; Sat, 26 Feb 2005 00:04:11 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21E7A43D1D for ; Sat, 26 Feb 2005 00:04:10 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id j1Q0477d017635; Fri, 25 Feb 2005 16:04:07 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id j1Q046K2017634; Fri, 25 Feb 2005 16:04:06 -0800 (PST) (envelope-from obrien) Date: Fri, 25 Feb 2005 16:04:06 -0800 From: "David O'Brien" To: Oliver Lehmann Message-ID: <20050226000406.GA17586@dragon.nuxi.com> References: <20050225125350.51801.qmail@web52310.mail.yahoo.com> <20050225170009.GA6633@aoi.wolfpond.org> <20050225234329.0710bc2a.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050225234329.0710bc2a.lehmann@ans-netz.de> 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.8i cc: freebsd-amd64@freebsd.org Subject: Re: OpenOffice, 5.3 Release, AMD64: is it true there's no love? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 26 Feb 2005 00:04:11 -0000 On Fri, Feb 25, 2005 at 11:43:29PM +0100, Oliver Lehmann wrote: > Francois Tigeot wrote: > > I'm afraid the OpenOffice code is not clean enough to run as a 64-bit > > binary. > > > > so.. there is no way to run any openoffice on FreeBSD/amd64? I think I've > to reconsider buying an amd64 system then... That's a shame for you -- and amd64 system is the fastest 32-bit system in the world today. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 26 00:07:12 2005 Return-Path: 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 3EB0716A4CE for ; Sat, 26 Feb 2005 00:07:12 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD9D943D1D for ; Sat, 26 Feb 2005 00:07:11 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so595048rng for ; Fri, 25 Feb 2005 16:07:11 -0800 (PST) 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:references; b=Nu4P09fCqbjAaKGGbHccfE2ll8RNsOG2UEVi5XEMttAU3bi4nuEbKERGlmVoOHOH3MJ4PnedV2WuusFtzacvMWLM58ki/ZAO9L3R53M/qtTUMC0AJxenXsSEcgkIKN5GNt+0UcXD67yxHVsTRQvhS7hx+6rJ1X17TjQqAoWQfcg= Received: by 10.38.22.76 with SMTP id 76mr197093rnv; Fri, 25 Feb 2005 16:07:10 -0800 (PST) Received: by 10.38.22.22 with HTTP; Fri, 25 Feb 2005 16:07:10 -0800 (PST) Message-ID: <346a80220502251607152cf556@mail.gmail.com> Date: Fri, 25 Feb 2005 19:07:10 -0500 From: Coleman Kane To: obrien@freebsd.org In-Reply-To: <20050226000406.GA17586@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050225125350.51801.qmail@web52310.mail.yahoo.com> <20050225170009.GA6633@aoi.wolfpond.org> <20050225234329.0710bc2a.lehmann@ans-netz.de> <20050226000406.GA17586@dragon.nuxi.com> cc: freebsd-amd64@freebsd.org Subject: Re: OpenOffice, 5.3 Release, AMD64: is it true there's no love? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cokane@cokane.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2005 00:07:12 -0000 In addition, it was said that OOo for linux runs just fine in the linuxulator. On Fri, 25 Feb 2005 16:04:06 -0800, David O'Brien wrote: > On Fri, Feb 25, 2005 at 11:43:29PM +0100, Oliver Lehmann wrote: > > Francois Tigeot wrote: > > > I'm afraid the OpenOffice code is not clean enough to run as a 64-bit > > > binary. > > > > > > > so.. there is no way to run any openoffice on FreeBSD/amd64? I think I've > > to reconsider buying an amd64 system then... > > That's a shame for you -- and amd64 system is the fastest 32-bit system > in the world today. > > -- > -- David (obrien@FreeBSD.org) > _______________________________________________ > 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 Sat Feb 26 00:17:49 2005 Return-Path: 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 27A6D16A4CE for ; Sat, 26 Feb 2005 00:17:49 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD06B43D39 for ; Sat, 26 Feb 2005 00:17:48 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so595881rng for ; Fri, 25 Feb 2005 16:17:48 -0800 (PST) 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:references; b=C1uTVU2q0HDr2hcjc2UjpOcGdvfZipbuy43KozaCzn/O6QQFxeK4lpo4d7Dw2O7QnLdHEASY0ijKDM2HBikXyPs/4pxiIiqWxFRycN3qllvBybm6rXF3F4fjPp09r0cg/zze4436IPyJ1ma+lcQlYcoY8TodGtKSbSsZd40tIjI= Received: by 10.39.1.40 with SMTP id d40mr202187rni; Fri, 25 Feb 2005 16:17:48 -0800 (PST) Received: by 10.38.22.22 with HTTP; Fri, 25 Feb 2005 16:17:48 -0800 (PST) Message-ID: <346a80220502251617476e336a@mail.gmail.com> Date: Fri, 25 Feb 2005 19:17:48 -0500 From: Coleman Kane To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <86d5usmfvm.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <86y8dje3p2.fsf@xps.des.no> <1109089389.4267.7.camel@leguin> <86r7j8mkds.fsf@xps.des.no> <86d5usmfvm.fsf@xps.des.no> cc: amd64@freebsd.org Subject: Re: VM panics X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cokane@cokane.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2005 00:17:49 -0000 The committed fix seems to have solved my kernel crash while building OOo. On Tue, 22 Feb 2005 22:41:49 +0100, Dag-Erling Sm=F8rgrav wrot= e: > des@des.no (Dag-Erling Sm=F8rgrav) writes: > > Eric Anholt writes: > > > Backing vm/uma_core.c to r1.114 has fixed the issue for me, sufficien= t > > > to survive two savecore -f (which no kernel with 1.115 had yet), a ni= ght > > > of being a kaffe tinderbox, and me on the desktop sending this email. > > Thanks, I'll try that. >=20 > Seems to work. I was actually able to build world & kernel without a > panic. >=20 > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > _______________________________________________ > 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 Sat Feb 26 02:34:15 2005 Return-Path: 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 605D616A4CE for ; Sat, 26 Feb 2005 02:34:15 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4172943D3F for ; Sat, 26 Feb 2005 02:34:15 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 3352A72DD8; Fri, 25 Feb 2005 18:34:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 2DE1E72DD5; Fri, 25 Feb 2005 18:34:15 -0800 (PST) Date: Fri, 25 Feb 2005 18:34:15 -0800 (PST) From: Doug White To: Astrodog In-Reply-To: <2fd864e0502241958501f8f6a@mail.gmail.com> Message-ID: <20050225183149.W32072@carver.gumbysoft.com> References: <000201c51a83$73157070$6800000a@r3140ca> <2fd864e0502241958501f8f6a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: amd64@freebsd.org cc: Nathan Vidican Subject: Re: OT Hardware reccomendtions (need MB for Dual Opterons) 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: Sat, 26 Feb 2005 02:34:15 -0000 On Thu, 24 Feb 2005, Astrodog wrote: > > We've got several dual opteron boxes now running FreeBSD, (they've been > > great thus far btw), and we're looking to add a few more... Problem seems to > > be that the motherboard we've been using is quite difficult to obtain, so > > does anyone have any good suggestions towards another? Here's the > > configuration as we're using now: > > > > Dual AMD Opteron 246 CPU > > MSI K8D Master3-FA4R ( > > http://www.msicomputer.com/product/p_spec.asp?model=K8D_Master3-FA4R&class=s > > pd ) > > 2 GB ECC Registered PC2700 (DDR333) Memory > > 3Ware Escalade 9500s-4LP RAID Controller > > 250GB WDC RAID Edition Hardrives > Tyan S2850s and S2882s have run great for me. For some reason, the BGE > nic does much better on -STABLE though. *shrug* I've got a S2881 on the bench right now that we'll be putting through its paces against an Intel Nacona-based S5360. FreeBSD went on the S2881 without issues, but has ATA problems on the S5360. The S2881 has a SiI 3114 controller, but if you turn that off and use the 3ware then it shouldn't be a problem :-) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 26 04:04:54 2005 Return-Path: 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 13B2116A4CE for ; Sat, 26 Feb 2005 04:04:54 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACA9643D58 for ; Sat, 26 Feb 2005 04:04:53 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id j1Q44rt8024773; Fri, 25 Feb 2005 20:04:53 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id j1Q44qQC024772; Fri, 25 Feb 2005 20:04:52 -0800 (PST) (envelope-from obrien) Date: Fri, 25 Feb 2005 20:04:52 -0800 From: "David O'Brien" To: Astrodog , freebsd-amd64@freebsd.org, Nathan Vidican Message-ID: <20050226040452.GA21842@dragon.nuxi.com> References: <000201c51a83$73157070$6800000a@r3140ca> <2fd864e0502241958501f8f6a@mail.gmail.com> <20050225183149.W32072@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050225183149.W32072@carver.gumbysoft.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.8i Subject: Re: OT Hardware reccomendtions (need MB for Dual Opterons) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 26 Feb 2005 04:04:54 -0000 > We've got several dual opteron boxes now running FreeBSD, (they've > been great thus far btw), and we're looking to add a few more... > Problem seems to be that the motherboard we've been using is quite > difficult to obtain, so does anyone have any good suggestions > towards another? Here's the configuration as we're using now: > > Dual AMD Opteron 246 CPU MSI K8D Master3-FA4R ( > http://www.msicomputer.com/product/p_spec.asp?model=K8D_Master3-FA4R&class=s > pd ) 2 GB ECC Registered PC2700 (DDR333) Memory 3Ware Escalade > 9500s-4LP RAID Controller 250GB WDC RAID Edition Hardrives For a 1U system, I would definately go with the Tyan Thunder K8SR (S2881) http://www.tyan.com/products/html/opteron.html It is the only Taiwan 2P Opteron motherboard with the CPU sockets and DIMM slots properly positioned for 1U termals. It only has 8 DIMM slots, so you loose one of the nice things about the Master3-FAR -- the 12 DIMM slots. My second choice is a tie between the Tyan Thunder K8S Pro (S2882) and Iwill DK8S2-SATA/DK8S2 (http://www.iwill.net/product_adns.asp). -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 26 17:39:11 2005 Return-Path: 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 B8C2316A4CE for ; Sat, 26 Feb 2005 17:39:11 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E98F43D2F for ; Sat, 26 Feb 2005 17:39:10 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so660263rng for ; Sat, 26 Feb 2005 09:39:10 -0800 (PST) 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:references; b=tJWX0KuTCSFnR0NhypFYvzgYubvBN7aYS+FVrKBKRKfX9n4xtC8vAleiNBpC7Epx84n1doj11iP13QlGvoYfGXXpK1H9FdwVV8OATmMN6ERCE4YqFptyvoKz5lk7p58jej+RVZ8qc3wmxp6C35xpp0YDuO9Z27KaOJHXVOhXlWo= Received: by 10.38.165.44 with SMTP id n44mr548210rne; Sat, 26 Feb 2005 09:39:09 -0800 (PST) Received: by 10.38.22.22 with HTTP; Sat, 26 Feb 2005 09:39:09 -0800 (PST) Message-ID: <346a80220502260939848bdf6@mail.gmail.com> Date: Sat, 26 Feb 2005 12:39:09 -0500 From: Coleman Kane To: Takeharu KATO In-Reply-To: <421B5E3D.60209@ybb.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <421A4D5D.6040205@ybb.ne.jp> <421B5E3D.60209@ybb.ne.jp> cc: freebsd-current@freebsd.org cc: nork@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 Local APIC Timer X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cokane@cokane.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2005 17:39:11 -0000 Hi, The lapic timer patch seems to break something in the timeout(9)/untimeout(9) handling. I have a mobile athlon64 laptop, and have been using Fukuda Nobuhiko's acpi_ppc driver for the Cool'n'Quiet operation. With your patch applied, this driver no longer scales the CPU frequency. It seems to use timeout(9) to have the kernel call a polling function regularly to monitor CPU usage and scales the CPU speed to match the usage. This helps maintain bettery life. The driver is at: http://www.spa.is.uec.ac.jp/~nfukuda/software/dist/acpi_ppc-20050210.tgz -- coleman kane On Wed, 23 Feb 2005 01:30:53 +0900, Takeharu KATO wrote: > Hi > > I found my bug in the patch which I sent before. > I re-post the local-apic-timer patch for AMD64. > > Takeharu KATO wrote: > > Hi > > > > I ported the local APIC timer tick feature to AMD64. > > Please take a look on this patch. > > > > Regards, > > > > > > -- > Takeharu KATO > > > Index: amd64/amd64/apic_vector.S > =================================================================== > RCS file: /home/kato/cvs/kato-sys/amd64/amd64/apic_vector.S,v > retrieving revision 1.1.1.1 > retrieving revision 1.2 > diff -u -r1.1.1.1 -r1.2 > --- amd64/amd64/apic_vector.S 18 Feb 2005 14:05:55 -0000 1.1.1.1 > +++ amd64/amd64/apic_vector.S 20 Feb 2005 18:15:29 -0000 1.2 > @@ -137,6 +137,26 @@ > ISR_VEC(6, apic_isr6) > ISR_VEC(7, apic_isr7) > > +/* > + * Local APIC periodic timer handler. > + */ > + .text > + SUPERALIGN_TEXT > +IDTVEC(timerint) > + PUSH_FRAME > + > + movq lapic, %rdx > + movl $0, LA_EOI(%rdx) /* End Of Interrupt to APIC */ > + > + FAKE_MCOUNT(TF_RIP(%rsp)) > + > + > + pushq $0 /* XXX convert trapframe to clockframe */ > + call lapic_handle_timer > + addq $8, %rsp /* XXX convert clockframe to trapframe */ > + MEXITCOUNT > + jmp doreti > + > #ifdef SMP > /* > * Global address space TLB shootdown. > Index: amd64/amd64/local_apic.c > =================================================================== > RCS file: /home/kato/cvs/kato-sys/amd64/amd64/local_apic.c,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 local_apic.c > --- amd64/amd64/local_apic.c 18 Feb 2005 14:05:55 -0000 1.1.1.1 > +++ amd64/amd64/local_apic.c 22 Feb 2005 16:16:33 -0000 > @@ -1,4 +1,6 @@ > /*- > + * Copyright (c) 2005 Takeharu KATO > + * (Add LAPIC timer support). > * Copyright (c) 2003 John Baldwin > * Copyright (c) 1996, by Steve Passe > * All rights reserved. > @@ -66,6 +68,9 @@ > CTASSERT(APIC_LOCAL_INTS == 240); > CTASSERT(IPI_STOP < APIC_SPURIOUS_INT); > > +#define LAPIC_TIMER_STATHZ 128 > +#define LAPIC_TIMER_PROFHZ 1024 > + > /* > * Support for local APICs. Local APICs manage interrupts on each > * individual processor as opposed to I/O APICs which receive interrupts > @@ -90,6 +95,9 @@ > u_int la_cluster:4; > u_int la_cluster_id:2; > u_int la_present:1; > + u_long *la_timer_count; > + u_long la_stat_ticks; > + u_long la_prof_ticks; > } static lapics[MAX_APICID]; > > /* XXX: should thermal be an NMI? */ > @@ -115,9 +123,23 @@ > IDTVEC(apic_isr7), /* 224 - 255 */ > }; > > +static u_int32_t lapic_timer_divisors[] = { > + APIC_TDCR_1, APIC_TDCR_2, APIC_TDCR_4, APIC_TDCR_8, APIC_TDCR_16, > + APIC_TDCR_32, APIC_TDCR_64, APIC_TDCR_128 > +}; > + > + > volatile lapic_t *lapic; > +static u_long lapic_timer_divisor, lapic_timer_period; > +static u_long *lapic_virtual_hardclock, *lapic_virtual_statclock, > + *lapic_virtual_profclock; > > static void lapic_enable(void); > +static void lapic_timer_enable_intr(void); > +static u_long calculate_lapic_timer_period(void); > +static void lapic_timer_oneshot(u_int count); > +static void lapic_timer_periodic(u_int count); > +static void lapic_timer_set_divisor(u_int divisor); > static uint32_t lvt_mode(struct lapic *la, u_int pin, uint32_t value); > > static uint32_t > @@ -181,6 +203,7 @@ > PCPU_SET(apic_id, lapic_id()); > > /* XXX: timer/error/thermal interrupts */ > + setidt(APIC_TIMER_INT, IDTVEC(timerint), SDT_SYSIGT, SEL_KPL,0); > } > > /* > @@ -244,13 +267,56 @@ > ("No ISR handler for IRQ %u", irq)); > setidt(vector, ioint_handlers[vector / 32], SDT_SYSIGT, SEL_KPL, 0); > } > +static u_long > +calculate_lapic_timer_period(void) > +{ > + u_long period,value; > + > + /* Start off with a divisor of 2 (power on reset default). */ > + lapic_timer_divisor = 8; > + > + /* Try to calibrate the local APIC timer. */ > + do { > + printf("lapic timer divisor:%lu\n",lapic_timer_divisor); > + lapic_timer_set_divisor(lapic_timer_divisor); > + lapic_timer_oneshot(APIC_TIMER_MAX_COUNT); > + DELAY(2000000); > + value = APIC_TIMER_MAX_COUNT - lapic->ccr_timer; > + printf("value:%lu(ccr:%u)\n",value,lapic->ccr_timer); > + if (value != APIC_TIMER_MAX_COUNT) > + break; > + lapic_timer_divisor <<= 1; > + } while (lapic_timer_divisor <= 128); > + if (lapic_timer_divisor > 128) > + panic("lapic: Divisor too big"); > + value /= 2; > + printf("lapic: Frequency %lu hz\n", value); > > + /* > + * We will drive the timer via hz. Require hz to be greater than > + * stathz, but if hz is less than the default profhz, cap profhz > + * at hz. > + */ > + stathz = LAPIC_TIMER_STATHZ; > + if (hz < stathz) { > + printf("lapic: Adjusting hz from %d to %d\n", hz, stathz); > + hz = stathz; > + } > + period=value / hz; > + KASSERT(period!=0, ("CPU:%d lapic%u: zero divisor",PCPU_GET(cpuid),lapic_id())); > +#if 0 /* Please enable following lines if you want to show period/divisor */ > + printf("Setup CPU:%d period:%lu val=%lu\n",PCPU_GET(cpuid),lapic_timer_period,value); > + printf("Setup CPU:%d div=%lu\n",PCPU_GET(cpuid),lapic_timer_divisor); > +#endif > + return period; > +} > void > lapic_setup(void) > { > struct lapic *la; > u_int32_t value, maxlvt; > register_t eflags; > + char buf[MAXCOMLEN + 1]; > > la = &lapics[lapic_id()]; > KASSERT(la->la_present, ("missing APIC structure")); > @@ -281,9 +347,47 @@ > lapic->lvt_lint1 = lvt_mode(la, LVT_LINT1, lapic->lvt_lint1); > > /* XXX: more LVT entries */ > + /* Program timer LVT and setup handler. */ > + lapic->lvt_timer = lvt_mode(la, LVT_TIMER, lapic->lvt_timer); > + snprintf(buf, sizeof(buf), "lapic%d: timer", lapic_id()); > + intrcnt_add(buf, &la->la_timer_count); > + if (PCPU_GET(cpuid) != 0) { > + lapic_timer_period=calculate_lapic_timer_period(); > + lapic_timer_set_divisor(lapic_timer_divisor); > + lapic_timer_periodic(lapic_timer_period); > + lapic_timer_enable_intr(); > + } > > intr_restore(eflags); > } > +/* > + * Called by cpu_initclocks() on the BSP to setup the local APIC timer so > + * that it can drive hardclock, statclock, and profclock. This function > + * returns true if it is able to use the local APIC timer to drive the > + * clocks and false if it is not able. > + */ > +int > +lapic_setup_clock(void) > +{ > + /* Can't drive the timer without a local APIC. */ > + if (lapic == NULL) > + return (0); > + > + lapic_timer_period = calculate_lapic_timer_period(); > + profhz = imin(hz, LAPIC_TIMER_PROFHZ); > + intrcnt_add("lapic: hardclock", &lapic_virtual_hardclock); > + intrcnt_add("lapic: statclock", &lapic_virtual_statclock); > + intrcnt_add("lapic: profclock", &lapic_virtual_profclock); > + > + /* > + * Start up the timer on the BSP. The APs will kick off their > + * timer during lapic_setup(). > + */ > + lapic_timer_periodic(lapic_timer_period); > + lapic_timer_enable_intr(); > + return (1); > +} > + > > void > lapic_disable(void) > @@ -515,6 +619,87 @@ > isrc = intr_lookup_source(apic_idt_to_irq(vec)); > intr_execute_handlers(isrc, &frame); > } > +void > +lapic_handle_timer(struct clockframe frame) > +{ > + struct lapic *la; > + > + la = &lapics[PCPU_GET(apic_id)]; > + (*la->la_timer_count)++; > + critical_enter(); > + > + /* Hardclock fires on every interrupt since we interrupt at hz. */ > + if (PCPU_GET(cpuid) == 0) { > + (*lapic_virtual_hardclock)++; > + hardclock(&frame); > + } else > + hardclock_process(&frame); > + > + /* Use a poor man's algorithm to fire statclock at stathz. */ > + la->la_stat_ticks += stathz; > + if (la->la_stat_ticks >= hz) { > + la->la_stat_ticks -= hz; > + if (PCPU_GET(cpuid) == 0) > + (*lapic_virtual_statclock)++; > + statclock(&frame); > + } > + > + /* Use the same trick for profhz. */ > + la->la_prof_ticks += profhz; > + if (la->la_prof_ticks >= hz) { > + la->la_prof_ticks -= hz; > + if (PCPU_GET(cpuid) == 0) > + (*lapic_virtual_profclock)++; > + if (profprocs != 0) > + profclock(&frame); > + } > + critical_exit(); > +} > + > +static void > +lapic_timer_set_divisor(u_int divisor) > +{ > + > + KASSERT(powerof2(divisor), ("lapic: invalid divisor %u", divisor)); > + KASSERT(ffs(divisor) <= sizeof(lapic_timer_divisors) / > + sizeof(u_int32_t), ("lapic: invalid divisor %u", divisor)); > + lapic->dcr_timer = lapic_timer_divisors[ffs(divisor) - 1]; > +} > + > +static void > +lapic_timer_oneshot(u_int count) > +{ > + u_int32_t value; > + > + value = lapic->lvt_timer; > + value &= ~APIC_LVTT_TM; > + value |= APIC_LVTT_TM_ONE_SHOT; > + lapic->lvt_timer = value; > + lapic->icr_timer = count; > +} > + > +static void > +lapic_timer_periodic(u_int count) > +{ > + u_int32_t value; > + > + value = lapic->lvt_timer; > + value &= ~APIC_LVTT_TM; > + value |= APIC_LVTT_TM_PERIODIC; > + lapic->lvt_timer = value; > + lapic->icr_timer = count; > +} > + > +static void > +lapic_timer_enable_intr(void) > +{ > + u_int32_t value; > + > + value = lapic->lvt_timer; > + value &= ~APIC_LVT_M; > + lapic->lvt_timer = value; > +} > + > > /* Translate between IDT vectors and IRQ vectors. */ > u_int > Index: amd64/amd64/mp_machdep.c > =================================================================== > RCS file: /home/kato/cvs/kato-sys/amd64/amd64/mp_machdep.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.2 > diff -u -r1.1.1.1 -r1.2 > --- amd64/amd64/mp_machdep.c 18 Feb 2005 14:05:55 -0000 1.1.1.1 > +++ amd64/amd64/mp_machdep.c 20 Feb 2005 18:15:29 -0000 1.2 > @@ -871,7 +871,7 @@ > smp_targeted_tlb_shootdown(mask, IPI_INVLRNG, addr1, addr2); > } > > - > +#if 0 > /* > * For statclock, we send an IPI to all CPU's to have them call this > * function. > @@ -914,16 +914,16 @@ > if (map != 0) > ipi_selected(map, IPI_HARDCLOCK); > } > - > +#endif > void > ipi_bitmap_handler(struct clockframe frame) > { > int cpu = PCPU_GET(cpuid); > u_int ipi_bitmap; > - struct thread *td; > > - ipi_bitmap = atomic_readandclear_int(&cpu_ipi_pending[cpu]); > > + ipi_bitmap = atomic_readandclear_int(&cpu_ipi_pending[cpu]); > +#if 0 > critical_enter(); > > /* Nothing to do for AST */ > @@ -948,6 +948,7 @@ > } > > critical_exit(); > +#endif > } > > /* > Index: amd64/conf/CURRENT-MARS > =================================================================== > RCS file: /home/kato/cvs/kato-sys/amd64/conf/CURRENT-MARS,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 CURRENT-MARS > Index: amd64/include/apicvar.h > =================================================================== > RCS file: /home/kato/cvs/kato-sys/amd64/include/apicvar.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.2 > diff -u -r1.1.1.1 -r1.2 > --- amd64/include/apicvar.h 18 Feb 2005 14:05:55 -0000 1.1.1.1 > +++ amd64/include/apicvar.h 20 Feb 2005 18:15:33 -0000 1.2 > @@ -123,9 +123,12 @@ > > /* IPIs handled by IPI_BITMAPED_VECTOR (XXX ups is there a better place?) */ > #define IPI_AST 0 /* Generate software trap. */ > +#if 0 > #define IPI_HARDCLOCK 1 /* Inter-CPU clock handling. */ > #define IPI_STATCLOCK 2 > #define IPI_BITMAP_LAST IPI_STATCLOCK > +#endif > +#define IPI_BITMAP_LAST IPI_AST > #define IPI_IS_BITMAPED(x) ((x) <= IPI_BITMAP_LAST) > > #define IPI_STOP (APIC_IPI_INTS + 6) /* Stop CPU until restarted. */ > @@ -172,7 +175,7 @@ > inthand_t > IDTVEC(apic_isr1), IDTVEC(apic_isr2), IDTVEC(apic_isr3), > IDTVEC(apic_isr4), IDTVEC(apic_isr5), IDTVEC(apic_isr6), > - IDTVEC(apic_isr7), IDTVEC(spuriousint); > + IDTVEC(apic_isr7), IDTVEC(spuriousint),IDTVEC(timerint); > > u_int apic_irq_to_idt(u_int irq); > u_int apic_idt_to_irq(u_int vector); > @@ -203,6 +206,7 @@ > void lapic_ipi_vectored(u_int vector, int dest); > int lapic_ipi_wait(int delay); > void lapic_handle_intr(void *cookie, struct intrframe frame); > +void lapic_handle_timer(struct clockframe frame); > void lapic_set_logical_id(u_int apic_id, u_int cluster, u_int cluster_id); > int lapic_set_lvt_mask(u_int apic_id, u_int lvt, u_char masked); > int lapic_set_lvt_mode(u_int apic_id, u_int lvt, u_int32_t mode); > @@ -212,6 +216,7 @@ > enum intr_trigger trigger); > void lapic_set_tpr(u_int vector); > void lapic_setup(void); > +int lapic_setup_clock(void); > > #endif /* !LOCORE */ > #endif /* _MACHINE_APICVAR_H_ */ > Index: amd64/isa/clock.c > =================================================================== > RCS file: /home/kato/cvs/kato-sys/amd64/isa/clock.c,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 clock.c > --- amd64/isa/clock.c 18 Feb 2005 14:05:55 -0000 1.1.1.1 > +++ amd64/isa/clock.c 22 Feb 2005 15:38:24 -0000 > @@ -64,13 +64,14 @@ > #include > #include > #include > - > +#define LAPIC_TIMER > #include > #include > #include > #include > #include > -#ifdef SMP > +#ifdef LAPIC_TIMER > +#include > #include > #endif > #include > @@ -113,6 +114,7 @@ > static u_int32_t i8254_offset; > static int (*i8254_pending)(struct intsrc *); > static int i8254_ticked; > +static int using_lapic_timer; > static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; > static u_char rtc_statusb = RTCSB_24HR | RTCSB_PINTR; > > @@ -139,7 +141,6 @@ > static void > clkintr(struct clockframe *frame) > { > - > if (timecounter->tc_get_timecount == i8254_get_timecount) { > mtx_lock_spin(&clock_lock); > if (i8254_ticked) > @@ -151,10 +152,8 @@ > clkintr_pending = 0; > mtx_unlock_spin(&clock_lock); > } > - hardclock(frame); > -#ifdef SMP > - forward_hardclock(); > -#endif > + if (!using_lapic_timer) > + hardclock(frame); > } > > int > @@ -221,9 +220,6 @@ > } > if (pscnt == psdiv) > statclock(frame); > -#ifdef SMP > - forward_statclock(); > -#endif > } > } > > @@ -730,7 +726,11 @@ > { > int diag; > > - if (statclock_disable) { > +#ifdef LAPIC_TIMER > + using_lapic_timer = lapic_setup_clock(); > +#endif > + > + if ( statclock_disable || using_lapic_timer ) { > /* > * The stat interrupt mask is different without the > * statistics clock. Also, don't set the interrupt > @@ -756,7 +756,7 @@ > writertc(RTC_STATUSB, RTCSB_24HR); > > /* Don't bother enabling the statistics clock. */ > - if (!statclock_disable) { > + if (!statclock_disable && !using_lapic_timer) { > diag = rtcin(RTC_DIAG); > if (diag != 0) > printf("RTC BIOS diagnostic error %b\n", diag, RTCDG_BITS); > @@ -774,7 +774,8 @@ > void > cpu_startprofclock(void) > { > - > + if (using_lapic_timer) > + return; > rtc_statusa = RTCSA_DIVIDER | RTCSA_PROF; > writertc(RTC_STATUSA, rtc_statusa); > psdiv = pscnt = psratio; > @@ -783,7 +784,8 @@ > void > cpu_stopprofclock(void) > { > - > + if (using_lapic_timer) > + return; > rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; > writertc(RTC_STATUSA, rtc_statusa); > psdiv = pscnt = 1; > > > _______________________________________________ > 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 Sat Feb 26 23:17:34 2005 Return-Path: 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 F409216A4CE; Sat, 26 Feb 2005 23:17:33 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F30943D39; Sat, 26 Feb 2005 23:17:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j1QNHW3B032902; Sat, 26 Feb 2005 18:17:32 -0500 (EST) (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.1/8.13.1) with ESMTP id j1QNHWlZ004093; Sat, 26 Feb 2005 18:17:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 854D67306E; Sat, 26 Feb 2005 18:17:32 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050226231732.854D67306E@freebsd-current.sentex.ca> Date: Sat, 26 Feb 2005 18:17:32 -0500 (EST) X-Virus-Scanned: ClamAV 0.82/729/Sat Feb 26 14:48:56 2005 on smarthost2.sentex.ca X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner2 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2005 23:17:34 -0000 TB --- 2005-02-26 22:35:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-26 22:35:57 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-02-26 22:35:57 - checking out the source tree TB --- 2005-02-26 22:35:57 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-02-26 22:35:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-26 22:41:50 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-26 22:41:50 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-02-26 22:41:50 - /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 [...] rm -f .depend mkdep -f .depend -a -I/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/pkg_install/version/../lib /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/pkg_install/version/main.c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/pkg_install/version/perform.c echo pkg_version: /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libc.a /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/pkg_install/version/../lib/libinstall.a /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libfetch.a /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libmd.a /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssl.a /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libcrypto.a >> .depend ===> usr.sbin/powerd (depend) rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/powerd/powerd.c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/powerd/powerd.c:38:30: machine/apm_bios.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/powerd. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-02-26 23:17:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-26 23:17:32 - ERROR: failed to build world TB --- 2005-02-26 23:17:32 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 26 23:41:08 2005 Return-Path: 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 F3EF616A4DE for ; Sat, 26 Feb 2005 23:41:06 +0000 (GMT) Received: from ybbsmtp10.mail.mci.yahoo.co.jp (ybbsmtp10.mail.mci.yahoo.co.jp [210.80.241.184]) by mx1.FreeBSD.org (Postfix) with SMTP id B342A43D5F for ; Sat, 26 Feb 2005 23:41:04 +0000 (GMT) (envelope-from takeharu1219@ybb.ne.jp) Received: from unknown (HELO ?192.168.1.14?) (takeharu1219@219.35.170.20 with plain) by ybbsmtp10.mail.mci.yahoo.co.jp with SMTP; 26 Feb 2005 23:41:03 -0000 X-Apparently-From: Message-ID: <4221090E.4020401@ybb.ne.jp> Date: Sun, 27 Feb 2005 08:41:02 +0900 From: Takeharu KATO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cokane@cokane.org References: <421A4D5D.6040205@ybb.ne.jp> <421B5E3D.60209@ybb.ne.jp> <346a80220502260939848bdf6@mail.gmail.com> In-Reply-To: <346a80220502260939848bdf6@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 Local APIC Timer 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: Sat, 26 Feb 2005 23:41:08 -0000 Hi Sorry, in fact , my patch has some problem. If you need local apic timer AMD64 please try peter wemm'work: http://people.freebsd.org/~peter/hammer.diff > > The lapic timer patch seems to break something in the > timeout(9)/untimeout(9) handling. I have a mobile athlon64 laptop, and > have been using Fukuda Nobuhiko's acpi_ppc driver for the Cool'n'Quiet > operation. With your patch applied, this driver no longer scales the > CPU frequency. It seems to use timeout(9) to have the kernel call a > polling function regularly to monitor CPU usage and scales the CPU > speed to match the usage. This helps maintain bettery life. > > The driver is at: > http://www.spa.is.uec.ac.jp/~nfukuda/software/dist/acpi_ppc-20050210.tgz > > -- > coleman kane -- Takeharu KATO