From owner-freebsd-questions@FreeBSD.ORG Thu Oct 13 14:52:55 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4C0C16A41F for ; Thu, 13 Oct 2005 14:52:54 +0000 (GMT) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8825143D45 for ; Thu, 13 Oct 2005 14:52:54 +0000 (GMT) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: (qmail 3561 invoked from network); 13 Oct 2005 14:52:54 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail25.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Oct 2005 14:52:53 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id CC15F41; Thu, 13 Oct 2005 10:52:52 -0400 (EDT) Sender: lowell@be-well.ilk.org To: Wayne Witzke References: <4348ACCD.7050203@sstire.com> <44irw5wion.fsf@be-well.ilk.org> <434BB9B5.5070309@sstire.com> <441x2r9524.fsf@be-well.ilk.org> <434D1439.3040903@sstire.com> <443bn6hauh.fsf@be-well.ilk.org> <434E5EDA.2010109@sstire.com> From: Lowell Gilbert Date: 13 Oct 2005 10:52:52 -0400 In-Reply-To: <434E5EDA.2010109@sstire.com> Message-ID: <443bn5o4e3.fsf@be-well.ilk.org> Lines: 73 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-questions-local@be-well.ilk.org, freebsd-questions@freebsd.org Subject: Re: CDROM Unknown Transfer Error crashes system X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 14:52:55 -0000 Wayne Witzke writes: > Lowell Gilbert wrote: > > Wayne Witzke writes: > > > >>I'm a little confused... I thought I had RELENG_5_4. "uname -a" says: > >> > >>FreeBSD wlaptop 5.4-RELEASE FreeBSD 5.4-RELEASE #1: Thu Oct 6 > >>21:18:29 EDT 2005 > >> root@wlaptop:/usr/obj/usr/src/sys/WLAPTOP i386 > >> > >>Isn't this RELENG_5_4? > > It was, but some patches have been applied since the release was > > made. I was suggesting RELENG_5, not RELENG_5_4; in other words, the > > branch that will eventually become the 5.5 release. > > I'll see if I can't figure out how to do this, then. I had no idea > that I wasn't running the most current. What you are running is the more recent release. But FreeBSD's developers have continued to modify code in the six months or so since then. > >>Lowell Gilbert wrote: > > > >>>>Is there anything that I can do to capture more information the next > >>>>time my computer reboots spontaneously? > >>> > >>>Try to get a crash dump. There's more information on it in the > >>>Handbook. And some related information on panic analysis (if you can > >>>get it to that point) in the FAQ. > >>> > >> > >>I'll try that, it doens't sound too difficult. Just so I know, if I > >>was going to see a kernel panic message, I'd be seeing one before the > >>computer reboots, right? > > I thought that was what you were describing in earlier messages. > > I'm *NOT* getting anything of this form (from the FAQ): > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x40 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf014a7e5 > stack pointer = 0x10:0xf4ed6f24 > frame pointer = 0x10:0xf4ed6f28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 80 (mount) > interrupt mask = > trap number = 12 > panic: page fault > > All I get is the single line error message in the system log: > > acd0: unknown transfer phase > > and then the computer drops to a POST and reboots. I see nothing on > my screen between the error and the POST. Ah. A spontaneous reboot, not a panic. Sorry I misunderstood. > One of the diagnostic steps that the FAQ mentions is to trace the > instruction pointer. My assumption was that if the system was going > to give me a message like that, I'd see it before the POST, but I > wanted to make sure that I didn't need to be looking for that message > in a log somewhere, or changing a configuration option somewhere to > make the system generate an error message of that form, because I > definitely don't see that before the POST. A debugging kernel may help.