Date: Tue, 23 Aug 2005 17:15:17 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: John Baldwin <jhb@FreeBSD.org> Cc: John Nielsen <john@jnielsen.net>, freebsd-sparc64@FreeBSD.org Subject: Re: "fast data access mmu miss" on kernels w/o "makeoptions DEBUG=-g" Message-ID: <20050823081517.GB4956@rndsoft.co.kr> In-Reply-To: <200508201453.40439.jhb@FreeBSD.org> References: <200508110931.13802.john@jnielsen.net> <20050819043026.GC10519@rndsoft.co.kr> <200508190217.15943.john@jnielsen.net> <200508201453.40439.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050823081517.GB4956>