a panic on uart_z8530_class?

[Brandon Gooch]

On Sat, May 8, 2010 at 10:27 PM, Yuri Pankov <yuri.pankov at gmail.com> 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 <ben at desync.com> wrote:
>> > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote:
>> >> > [root at 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, and you are
>> >> > welcome to change it and/or distribute copies of it under certain conditions.
>> >> > Type "show copying" to see the conditions.
>> >> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> >> > This GDB was configured as "amd64-marcel-freebsd"...
>> >> > Cannot access memory at address 0xffffff0127ffffe0
>> >> > (kgdb) bt
>> >> > #0  0x0000000000000000 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.  At first I thought that I managed 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 updating
>> >> to a new snapshot tonight and see if kgdb behaves better after everything
>> >> 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