From owner-freebsd-current@FreeBSD.ORG Sun May 9 20:27:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86DD71065674 for ; Sun, 9 May 2010 20:27:06 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6A98FC18 for ; Sun, 9 May 2010 20:27:05 +0000 (UTC) Received: by gyh20 with SMTP id 20so1624788gyh.13 for ; Sun, 09 May 2010 13:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8kcsceGeddOg5GgqLMhvSao8mO9uwUWeyJi+M1o5/wA=; b=iJiVhB8Wg82AdCi20fx0G2EGEkjj47dsdQ9Z66dnZwhRMlMJ5zBS89QncalBFn6tgl Fl+ki19OhLkNdLHTv+6EnFGUq2C2HhsvxEYlmEBDhhQRPSZ7eOnw2BkZout+HlQbQzz6 srij5lvG3SO8GwsMB3ReznD2f3WibSApON8OQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aoYHaoR0lNeqX1iM1/MJxrGg9rVwihF0sIUr3F3YU5ZwvVGb1S7BZnIV6iYy9YMLna pndJFdv8YhWalNRBPHc08AN6wmdaHocJbdHmPABV3pcsyH7lPSSi71ijwaGlknNrQS1I visfOBX7QKln2Mu29WG2UJ7kC3Eif9kjIC9zw= MIME-Version: 1.0 Received: by 10.231.143.137 with SMTP id v9mr1172297ibu.70.1273436825179; Sun, 09 May 2010 13:27:05 -0700 (PDT) Received: by 10.231.115.3 with HTTP; Sun, 9 May 2010 13:27:05 -0700 (PDT) In-Reply-To: <20100509032756.GA90127@darklight.org.ru> References: <20100508200032.GB31100@weongyo> <20100508203549.GA8088@exodus.desync.com> <20100509032756.GA90127@darklight.org.ru> Date: Sun, 9 May 2010 15:27:05 -0500 Message-ID: From: Brandon Gooch To: Yuri Pankov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: a panic on uart_z8530_class? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 20:27:06 -0000 On Sat, May 8, 2010 at 10:27 PM, Yuri Pankov wrote: > On Sat, May 08, 2010 at 09:59:23PM -0500, Brandon Gooch wrote: >> On Sat, May 8, 2010 at 3:35 PM, ben wilber wrote: >> > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: >> >> > [root@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 >> >> > GNU gdb 6.1.1 [FreeBSD] >> >> > Copyright 2004 Free Software Foundation, Inc. >> >> > GDB is free software, covered by the GNU General Public License, an= d you are >> >> > welcome to change it and/or distribute copies of it under certain c= onditions. >> >> > Type "show copying" to see the conditions. >> >> > There is absolutely no warranty for GDB. =A0Type "show warranty" fo= r details. >> >> > This GDB was configured as "amd64-marcel-freebsd"... >> >> > Cannot access memory at address 0xffffff0127ffffe0 >> >> > (kgdb) bt >> >> > #0 =A00x0000000000000000 in ?? () >> >> > Cannot access memory at address 0x0 >> >> > (kgdb) q >> >> >> >> >> >> I have seen this behavior from kgdb --- it doesn't seem to be able to >> >> handle coredumps I've made recently. =A0At first I thought that I man= aged to >> >> trash either my kernel image or kgdb binary with all the unclean >> >> shutdowns I've been having, but if you're seeing kgdb failures, maybe= it's >> >> not just my local system. >> >> >> >> Yet I am assuming that this is not broken for *everyone*, or we would= have >> >> heard more noise about it. >> >> >> >> I'm running a current snapshot from April 4th; maybe I will try updat= ing >> >> to a new snapshot tonight and see if kgdb behaves better after everyt= hing >> >> is rebuilt. >> > >> > Same here, for the last couple months maybe. >> >> I'll chime in here with a "me too". >> >> Since at early April, I've been trying to figure out why my laptop >> locks up overnight (something about the CPUs going into C3). I can >> nearly always get it to coredump, but the vmcore files I generate are >> unusable... >> >> -Brandon > > Just another "me too". May be we have something common in our setup? > (I'm dumping to /dev/gpt/swap 8Gb GPT partition, using ahci(4) on a ATI > IXP700 AHCI SATA controller). > > Another issue - dump is written extremely slow (1.5Gb in ~5 minutes). I'm dumping to /dev/gpt/swap0 and yes, the dump is VERY slow. I've only recently began doing dumps, so I have little to compare the experience to -- although it does seem to have been slowing down now for a while :( I'm actually in the middle of doadump() right now, and it's been about 4 minutes, and I'm not even halfway done... --Brandon