Date: Thu, 22 Jun 2006 20:58:06 +0000 From: "Wojciech A. Koszek" <wkoszek@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-stable@freebsd.org, Martin Blapp <mb@imp.ch>, Patrick Guelat <patg@imp.ch> Subject: Re: Crash with FreeBSD 6.1 STABLE of today Message-ID: <20060622205806.GA6542@FreeBSD.czest.pl> In-Reply-To: <20060621193941.Y8526@fledge.watson.org> References: <20060621202508.S17514@godot.imp.ch> <20060621193941.Y8526@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On śro, cze 21, 2006 at 07:43:15 +0100, Robert Watson wrote: > On Wed, 21 Jun 2006, Martin Blapp wrote: > > >I just upgraded from 5.5 (stable btw.) to 6.1 and after 10 hours I got a > >nice panic. Does this look like some tty problem ? > > It looks like a tty or devfs problem. > > >This is the machine which made that many problems with PREEMTION enabled > >in earlier releases of 5.x. Is it possible that I'm hitting now again the > >same bugs or is it clearly a tty related problem ? > > I'm not sure there's evidence it's caused by preemption, but it's not > impossible that preemption makes it more likely to happen, or facilitates > it happening on non-SMP systems. Wojciech Koszek has recently been looking > into devfs-related races that trigger for pty's, which could be relevant to > what you're seeing, so I've CC'd him. Robert, Thanks for CCing me, even with wrong address ;-) I'll look into that. > >kgdb /var/core/kernel.debug /var/core/vmcore.6 > > > >#0 0xc0663002 in doadump () > >#1 0xc066355e in boot () > >#2 0xc06638b5 in panic () > >#3 0xc085c6b6 in trap_fatal () > >#4 0xc085c3bf in trap_pfault () > >#5 0xc085bfb5 in trap () > >#6 0xc0848bea in calltrap () > >#7 0xc0693b51 in ttymodem () > >#8 0xc0698362 in ptcclose () > >#9 0xc0638a6f in giant_close () > >#10 0xc06162bf in devfs_close () > >#11 0xc086dc1c in VOP_CLOSE_APV () > >#12 0xc06c87e2 in vn_close () > >#13 0xc06c974a in vn_closefile () > >#14 0xc06162e7 in devfs_close_f () > >#15 0xc0642cdc in fdrop_locked () > >#16 0xc0642c29 in fdrop () > >#17 0xc06411c7 in closef () > >#18 0xc063e329 in close () > >#19 0xc085c9f7 in syscall () > >#20 0xc0848c3f in Xint0x80_syscall () > >#21 0x00000033 in ?? () > >Previous frame inner to this frame (corrupt stack?) > > > >Unfortunaltly I get this with the debug kernel. > >Does one have to boot with the debug.kernel itself > >to get a trace which is usable ? I think your problem is that one I wanted to know more about. > >kgdb /var/core/kernel.debug /var/core/vmcore.6 > > > >kgdb: kvm_read: invalid address (0x21) [..] > >kgdb: kvm_read: invalid address (0x21) > > Martin, Could you make sure your kernel and kernel.debug are in sync? It look like you have kernel and kernel.debug compiled from different sources or different configuration files. After 'bt' typed in kgdb you should get a backtrace. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/dunstan/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060622205806.GA6542>