Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 May 2014 14:39:50 -0600
From:      Alan Somers <asomers@freebsd.org>
To:        Michael Jung <mikej@mikej.com>
Cc:        FreeBSD CURRENT <freebsd-current@freebsd.org>, owner-freebsd-current@freebsd.org
Subject:   Re: Gallium debugging and crash dumps
Message-ID:  <CAOtMX2jmxo24zUxOLLcnxsTxjj0F9Bx6ejx5_zOjKXWMVA-yDA@mail.gmail.com>
In-Reply-To: <b1eb1ecd7b976efd0d073697a368b9f6@mail.mikej.com>
References:  <ad725ea72025b1b7cccc9c0bc686c67d@mail.mikej.com> <b1eb1ecd7b976efd0d073697a368b9f6@mail.mikej.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 15, 2014 at 2:33 PM, Michael Jung <mikej@mikej.com> wrote:
> On , Michael Jung wrote:
>>
>> Hi:
>>
>> If there is a better list to post this to please let me know.
>>
>> I've started playing with VT and gallium. I boot on ZFS but have a UFS
>> drive
>> and swap partition.  Anyone with idea's why I'm not getting any crash
>> info?
>>
>> I am guessing it is because the machine is not rebooting but locks up hard
>> so
>> is there any extra debugging that can be turned on?
>>
>> On the surface Gallium seems to be the root of the problem.
>>
>> Here is my dump/swap config:
>>
>> FreeBSD charon 10.0-STABLE FreeBSD 10.0-STABLE #0 r265914M: Wed May 14
>> 15:44:17 EDT 2014     mikej@charon:/usr/obj/usr/src/sys/VT  amd64
>>
>> root@charon:/usr/home/mikej # swapinfo
>> Device          1K-blocks     Used    Avail Capacity
>> /dev/ada2s1a     16777216        0 16777216     0%
>> root@charon:/usr/home/mikej #
>>
>> root@charon:/usr/home/mikej # dumpon  -l
>> ada2s1a
>> root@charon:/usr/home/mikej #
>>
>> root@charon:/usr/home/mikej # grep dump /etc/rc.conf
>> dumpdev="AUTO"            # Device to crashdump to (device name, AUTO, or
>> NO).
>> dumpdir="/data/crash"    # Directory where crash dumps are to be stored
>> root@charon:/usr/home/mikej #
>>
>> root@charon:/usr/home/mikej # ls -lad /data/crash/
>> drwxr-xr-x  2 root  wheel  512 Apr 20 13:15 /data/crash/
>> root@charon:/usr/home/mikej #
>>
>> http://216.26.158.189/Xorg.0.log
>>
>> --mikej
>> _______________________________________________
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
>
>
> OK another crash today and the machine did reboot but still nothing in
> /data/crash
>
>
> [mikej@charon ~]$ gpart list ada2
> Geom name: ada2
> modified: false
> state: OK
> fwheads: 16
> fwsectors: 63
> last: 3907029167
> first: 63
> entries: 4
> scheme: MBR
> Providers:
> 1. Name: ada2s1
>    Mediasize: 2000398901760 (1.8T)
>    Sectorsize: 512
>    Stripesize: 0
>    Stripeoffset: 32256
>    Mode: r2w2e3
>    rawtype: 165
>    length: 2000398901760
>    offset: 32256
>    type: freebsd
>    index: 1
>    end: 3907029167
>    start: 63
> Consumers:
> 1. Name: ada2
>    Mediasize: 2000398934016 (1.8T)
>    Sectorsize: 512
>    Mode: r2w2e5
>
> [mikej@charon ~]$ ls /dev/ada2
> ada2     ada2s1   ada2s1a  ada2s1b
> [mikej@charon ~]$ ls /dev/ada2
>
> I simply must just not understand something that is fundamental here.
>
> If I get this right swap is a slice ada2s1b, not a partition which
> should be fine for core dumps right?  On reboot dumps to swap are not
> being wrote to /data/dump!
>
> If UFS is dirty and auto-fsck runs - is this an issue?
>
> I obviously don't get something. Please someone enlighten me ;-)

Try doing "sysctl debug.kdb.panic=1".  That will forcibly panic your
system.  If you still don't get a crashdump, then it's not Gallium's
fault.

Also, check that /data/crash is mounted before savecore runs.

-Alan

>
> Regards,
>
> --mikej
> Michael Jung
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jmxo24zUxOLLcnxsTxjj0F9Bx6ejx5_zOjKXWMVA-yDA>