From owner-freebsd-sparc64@FreeBSD.ORG Tue Aug 23 08:18:35 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A517016A422 for ; Tue, 23 Aug 2005 08:18:35 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 603B243D58 for ; Tue, 23 Aug 2005 08:18:34 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so1112832rne for ; Tue, 23 Aug 2005 01:18:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ZJGXGPGoo3IQ8LsZJazHmrD2j3c7nRiF0cI6NNDRyD3+GXhtqDvX0PVBDSxo2x5UndcrmTaMTSqkknQbTEoee9Sa3PvKVTS9adOOnneYE0r4lOF33pg/BOIlTsUxJGNi6lzgijzLsjMjpstKv2mgdQGSqIxwIQbj7qEgX8ozGVI= Received: by 10.38.89.10 with SMTP id m10mr326484rnb; Tue, 23 Aug 2005 01:18:33 -0700 (PDT) Received: from michelle.rndsoft.co.kr ([211.32.202.211]) by mx.gmail.com with ESMTP id k3sm4504485rnb.2005.08.23.01.18.32; Tue, 23 Aug 2005 01:18:33 -0700 (PDT) Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j7N8FPZ9006693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2005 17:15:25 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j7N8FHbU006692; Tue, 23 Aug 2005 17:15:17 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Date: Tue, 23 Aug 2005 17:15:17 +0900 From: Pyun YongHyeon To: John Baldwin Message-ID: <20050823081517.GB4956@rndsoft.co.kr> References: <200508110931.13802.john@jnielsen.net> <20050819043026.GC10519@rndsoft.co.kr> <200508190217.15943.john@jnielsen.net> <200508201453.40439.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <200508201453.40439.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: John Nielsen , freebsd-sparc64@FreeBSD.org Subject: Re: "fast data access mmu miss" on kernels w/o "makeoptions DEBUG=-g" X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 08:18:35 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Aug 20, 2005 at 02:53:39PM -0400, John Baldwin wrote: > On Friday 19 August 2005 02:17 am, John Nielsen wrote: > > On Friday 19 August 2005 12:30 am, Pyun YongHyeon wrote: > > > On Thu, Aug 18, 2005 at 09:24:58AM -0400, John Nielsen wrote: > > > > On Wednesday 17 August 2005 16:59, Marius Strobl wrote: > > > > > On Mon, Aug 15, 2005 at 10:42:36AM -0400, John Nielsen wrote: > > > > > > On Friday 12 August 2005 00:53, Andrew Belashov wrote: > > > > > > > John Nielsen wrote: > > > > > > > > Can anyone say why removing "makeoptions DEBUG=-g" from a > > > > > > > > kernel would make it unreliable? I'm on an Ultra 5, and it's > > > > > > > > quite stable with either GENERIC or the kernel specified > > > > > > > > below. However, commenting out the "makeoptions DEBUG=-g" > > > > > > > > line builds a kernel that boots but then panics right after > > > > > > > > mounting /: > > > > > > > > > > > > > > > > Entropy harvesting: interrupts ethernet point_to_pointpanic: > > > > > > > > trap: fast data access mmu miss > > > > > > > > Uptime:2s > > > > > > > > Dumping 512 MB (2 chunks) > > > > > > > > > > > > > > Try to clean rebuild kernel (remove build directory > > > > > > > /usr/obj/usr/src/sys/KERNCONF or /sys/compile/KERNCONF). > > > > > > > > > > > > No change even after a fresh buildworld (using RELENG_6): > > > > > > > > > > > > cvsup /etc/supfile-src && rm -r /usr/obj/* && cd /usr/src && make > > > > > > make && make clean && make cleandir && make cleandir && make > > > > > > buildworld && make buildkernel && make installkernel && make > > > > > > installworld && mergemaster > > > > > > > > > > > > I don't mind leaving the option in the kernel, but it does seem > > > > > > like a strange bug. Let me know if anyone has any other ideas. > > > > > > Thanks, > > > > > > > > > > When the DEBUG make option is defined the compiler optimization > > > > > flags (COPTFLAGS) default to '-O -pipe' whereas without DEBUG the > > > > > default is '-O2 -pipe' ('-O2' can cause bogus stack traces so it's > > > > > not the default for debugging kernels). So in case you also get a > > > > > panic with a kernel having both: > > > > > makeoptions DEBUG=-g > > > > > and: > > > > > makeoptions COPTFLAGS="-O2 -pipe" > > > > > this probably means that there's bogus code that breaks at higher > > > > > optimization levels or a compiler bug. A stack trace from such a > > > > > panic might help to track this down in case it's not screwed due > > > > > to the '-O2'. > > > > > > > > That's what it was. A kernel with only > > > > makeoptions COPTFLAGS="-O -pipe" > > > > builds and runs just fine. > > > > > > Are you sure that GENERIC kernel panics too? > > > I couldn't verify it(I'm on a business trip) but I guess you should > > > remove smbfs related kernel options. smbfs never worked on sparc64 > > > and it needs more clean up on various places. > > > If you encounter the panic again would you post stack traces? > > > > Yes, I built about 20 kernels trying to track it down, including GENERIC > > sans makeoptions DEBUG=-g (but with WITNESS, etc). > > > > I haven't actually tried to use SMBFS yet, but simply having it in the > > kernel doesn't seem to be affecting anything. > > > > I'll see if I can get a stacktrace from an existing dump. > > My ultra60 won't boot a kernel that doesn't have WITNESS in it FWIW. Try a > stock GENERIC kernel and see if it works. You can disable witness with the > loader tunable 'debug.witness.watch=0'. > It seems that iconv needs default KOBJMETHOD for ICONV_CONVERTER_NAME. With attached patch I can boot my system with LIBICONV. John Nielsen, would you please let me know how the attached patch goes on your system? -- Regards, Pyun YongHyeon --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iconv.patch" --- sys/libkern/iconv.c.orig Wed Aug 17 11:34:33 2005 +++ sys/libkern/iconv.c Tue Aug 23 15:54:14 2005 @@ -419,6 +419,12 @@ return 0; } +const char * +iconv_converter_namestub(struct iconv_converter_class *dp) +{ + return (NULL); +} + int iconv_converter_handler(module_t mod, int type, void *data) { --- sys/libkern/iconv_converter_if.m.orig Sat Apr 30 14:32:31 2005 +++ sys/libkern/iconv_converter_if.m Tue Aug 23 15:37:47 2005 @@ -67,4 +67,4 @@ STATICMETHOD const char * name { struct iconv_converter_class *dcp; -}; +} DEFAULT iconv_converter_namestub; --- sys/sys/iconv.h.orig Fri Jul 8 09:32:11 2005 +++ sys/sys/iconv.h Tue Aug 23 15:38:38 2005 @@ -231,6 +231,7 @@ int iconv_converter_initstub(struct iconv_converter_class *dp); int iconv_converter_donestub(struct iconv_converter_class *dp); +const char*iconv_converter_namestub(struct iconv_converter_class *dp); int iconv_converter_handler(module_t mod, int type, void *data); #ifdef ICONV_DEBUG --6c2NcOVqGQ03X4Wi--