From owner-freebsd-stable@FreeBSD.ORG Thu Jun 29 08:00:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4772516A47B for ; Thu, 29 Jun 2006 08:00:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2487F43D5A for ; Thu, 29 Jun 2006 08:00:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E244446C74; Thu, 29 Jun 2006 04:00:50 -0400 (EDT) Date: Thu, 29 Jun 2006 09:00:50 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Fabian Keil In-Reply-To: <20060629021509.13ff7341@localhost> Message-ID: <20060629085650.H9293@fledge.watson.org> References: <20060627175853.765a590e@localhost> <20060628101729.J50845@fledge.watson.org> <20060628235258.3414b074@localhost> <20060628230255.M78211@fledge.watson.org> <20060629021509.13ff7341@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Thoenen , freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.1 Tor issues (Once More, with Feeling) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 08:00:58 -0000 On Thu, 29 Jun 2006, Fabian Keil wrote: > I wish I could. The machine died before I read your message. > > I was logged in on the serial console running tail -f /var/log/messages. > Last messages were: > > Jun 29 00:42:20 tor kernel: Memory modified after free 0xc4275000(2048) val=a020c0de @ 0xc4275000 > Jun 29 00:42:20 tor kernel: Memory modified after free 0xc4055800(2048) val=a020c0de @ 0xc4055800 > Jun 29 00:42:20 tor kernel: Memory modified after free 0xc4ca0000(2048) val=a020c0de @ 0xc4ca0000 > Jun 29 00:42:20 tor kernel: Memory modified after free 0xc39ef000(2048) val=a020c0de @ 0xc39ef000 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc4bd7000(2048) val=a020c0de @ 0xc4bd7000 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc3c8a000(2048) val=a020c0de @ 0xc3c8a000 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc33bd000(2048) val=a020c0de @ 0xc33bd000 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc3f1d000(2048) val=a020c0de @ 0xc3f1d000 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc45dc800(2048) val=a020c0de @ 0xc45dc800 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc429e000(2048) val=a020c0de @ 0xc429e000 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc3aef800(2048) val=a020c0de @ 0xc3aef800 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc432a000(2048) val=a020c0de @ 0xc432a000 > Jun 29 00:42:24 tor kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=34263674 > Jun 29 00:42:24 tor kernel: Memory modified after free 0xc3dff800(2048) val=a020c0d > > Ctrl+Alt+ESC didn't trigger any reaction, so I caused a reset through the > ISP's webinterface. Now the system appears to be hosed, at least FreeBSD > never reaches the login: > > PXELINUX 3.11 2005-09-02 Copyright (C) 1994-2005 H. Peter Anvin > Booting from local disk... > > 1 Linux > 2 FreeBSD > 3 FreeBSD > > Default: 2 > > [nothing] > > Probably something which would be easy to resolve with keyboard access and a > screen, but I think I'm forced to use the "RecoveryManager". Unfortunately > "recovery" means reinstalling the preconfigured GNU/Linux which I than can > replace with FreeBSD again. If there ever was a core dump it will be gone, > and so will be kernel.debug. > > On the bright side you can chose the OS to go with. Should I use Current to > see if the problem still exists? The ATA error above is a bit distressing, as is the fact that it won't boot. Is "[nothing]" normally the FreeBSD boot loader rather than nothing? I would suggest running some hardware diagnostics to make sure we're dealing with reliable hardware before continuing so that we're not chasing both hardware and software problems, since you can't reliably debug software problems in the presence of hardware failures. Robert N M Watson Computer Laboratory University of Cambridge