On Sat, May 8, 2010 at 10:27 PM, Yuri Pankov <yuri.pan...@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 <b...@desync.com> wrote: >> > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: >> >> > [r...@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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"