Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

From: Gary Jennejohn <gljennjohn_at_gmail.com>
Date: Sun, 3 May 2020 16:13:30 +0200
On Sun, 3 May 2020 14:11:09 +0100
Grzegorz Junka <list1_at_gjunka.com> wrote:

> On 03/05/2020 08:05, Gary Jennejohn wrote:
> > On Sat, 02 May 2020 16:28:46 -0700
> > Chris <bsd-lists_at_BSDforge.com> wrote:
> >  
> >>  
> >>>  
> >>>>> Another thing is that I don't quite understand why the crash couldn't
> >>>>> be dumped.
> >>>>>
> >>>>> root_at_crayon2:~ # swapinfo
> >>>>> Device__________________ 1K-blocks________ Used______ Avail Capacity
> >>>>> /dev/zvol/tank3/swap__ 33554432______________ 0 33554432________ 0%
> >>>>>
> >>>>> There is no entry in /etc/fstab though, should it be there too?  
> >>>> How about your rc.conf(5) ?
> >>>>
> >>>> You need to define a dumpdev within it as:
> >>>>
> >>>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
> >>>> dumpdev="YES"
> >>>>
> >>>> Which defaults to the location of:
> >>>>
> >>>> /var/crash
> >>>>     
> >>> Yes, of course I have 'dumpdev="AUTO"'. Should it be "YES" instead?  
> >> Yes, it should of course be AUTO. I was distracted at the time of writing.
> >> Sorry.
> >> Does /var/crash exist?
> >>
> >> That _should_ be enough. Assuming /var/crash is writable.
> >>  
> > Sorry, but read the man page for rc.conf.
> >
> > This is the entry for dumpdev:
> >
> >       dumpdev     (str) Indicates the device (usually a swap partition) to
> >                   which a crash dump should be written in the event of a system
> >                   crash.  If the value of this variable is "AUTO", the first
> >                   suitable swap device listed in /etc/fstab will be used as
> >                   dump device.  Otherwise, the value of this variable is passed
> >                   as the argument to dumpon(8).  To disable crash dumps, set
> >                   this variable to "NO".
> >
> > If there are no swap devices in /etc/fstab then "AUTO" will not work.  But
> > a partition can be specified.  I have dumpdev="/dev/ada0p5" in my rc.conf.
> >
> > /var/crash is the target for crash dumps after the system is re-booted.
> >  
> 
> /var/crash existed but might not have had the right permissions. I think 
> it was 755 whereas the handbook recommends 700. Shouldn't matter though.
> 

/var/crash is irrelevant when a crash dump is being written out.

> I don't have anything about swap in fstab since I am using Root on ZFS. 
> swapinfo correctly recognizes the swap partition and uses it. This the 
> typical usage while I am compiling ports:
> 
> last pid: 85116;__ load averages:__ 8.95,__ 8.50, 8.34 up 0+18:06:31__ 13:02:32
> 72 processes:__ 14 running, 57 sleeping, 1 zombie
> CPU:__ 0.0% user, 90.5% nice,__ 9.5% system,__ 0.0% interrupt,__ 0.0% idle
> Mem: 993M Active, 594M Inact, 6400K Laundry, 12G Wired, 2225M Free
> ARC: 6160M Total, 3093M MFU, 2657M MRU, 214M Anon, 100M Header, 193M Other
>  ________ 5300M Compressed, 5861M Uncompressed, 1.11:1 Ratio
> Swap: 32G Total, 61M Used, 32G Free
> 
> The crash happened in similar conditions so there should be nothing 
> preventing dumping the crash to the zfs swap, unless dumpon isn't smart 
> enough to use zfs swap.
> 
> I don't have a partition that I could use for swap. I have two whole 
> disks added to ZFS. Maybe on the boot drive but that would require 
> repartitioning and I have Windows/FreeBSD there, so not so straightforward.
> 

As the dumpon man pages states, by the time a crash dump is needed the
files systems are dead.  No way to dump to a ZFS file system.  That's
why a raw partition is required.

The other option would be netdump.  See the dumpon man page.

-- 
Gary Jennejohn
Received on Sun May 03 2020 - 12:13:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC