Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Aug 2005 15:18:14 +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:  <20050822061813.GA712@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
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'.
 > 

GENERIC kernel without WITNESS/DEBUG works here on U60(CURRENT). 
But loading libiconv.ko or linking kernel with "options LIBICONV"
I got the panic in the following code path.

panic: trap: fast data access mmu miss
panic messages:
---
panic: trap: fast data access mmu miss
cpuid = 0
KDB: enter: panic
Dumping 512 MB (1 chunks)
  chunk at 0xa0000000: 536870912 bytes |\^H
---
#0  0x00000000c018730c in doadump ()
(kgdb) bt
#0  0x00000000c018730c in doadump ()
#1  0x00000000c00736e0 in db_fncall ()
#2  0x00000000c00738e4 in db_command_loop ()
#3  0x00000000c0076328 in db_trap ()
#4  0x00000000c01a98e4 in kdb_trap ()
#5  0x00000000c034e8a8 in trap ()
#6  0x00000000c01a92f8 in kdb_enter ()
#7  0x00000000c01a92f0 in kdb_enter ()
#8  0x00000000c018822c in panic ()
#9  0x00000000c034e7c4 in trap ()
#10 0x00000000c02082a0 in strlcpy ()
#11 0x00000000c0205c9c in iconv_sysctl_drvlist ()
#12 0x00000000c0192044 in sysctl_root ()
#13 0x00000000c019239c in userland_sysctl ()
#14 0x00000000c019251c in __sysctl ()
#15 0x00000000c034ec28 in syscall ()
(kgdb)
This trace is somewhat different in ddb. But I believe gdb53's trace
is correct. I can reliably panic the system with "sysctl kern.random"
command after loading libiconv.ko module. So I guess something is
wrong in iconv.

-- 
Regards,
Pyun YongHyeon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050822061813.GA712>