arp panic

2017-02-03 Thread Chagin Dmitry 

chd.heemeyer.club dumped core - see /var/crash/vmcore.8

Sat Feb  4 09:01:35 MSK 2017

FreeBSD chd.heemeyer.club 12.0-CURRENT FreeBSD 12.0-CURRENT #237 
r313172+c19dc6ff09(lemul): Fri Feb  3 22:38:44 MSK 2017 
r...@chd.heemeyer.club:/home/rootobj/home/git/head/sys/YOY  amd64

panic: 

GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x807833ed
stack pointer   = 0x28:0xfe032db70430
frame pointer   = 0x28:0xfe032db704f0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 11 (swi4: clock (0))

Reading symbols from /boot/kernel/drm2.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/drm2.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/pseudofs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/procfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/procfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/i915kms.ko.debug...done.
done.
doadump (textdump=766966752) at /home/git/head/sys/kern/kern_shutdown.c:318
318 dumptid = curthread->td_tid;
(kgdb) #0  doadump (textdump=766966752)
at /home/git/head/sys/kern/kern_shutdown.c:318
#1  0x803fbcc5 in db_fncall_generic (addr=-2139566720, 
rv=0xfe032db6fb90, nargs=0, args=0xfe032db6fba0)
at /home/git/head/sys/ddb/db_command.c:581
#2  0x803fb284 in db_fncall (dummy1=-2185371386672, dummy2=false, 
dummy3=0, dummy4=0xfe032db6fcd0 "\360\374\266-\003\376\377\377")
at /home/git/head/sys/ddb/db_command.c:629
#3  0x803fabee in db_command (
last_cmdp=0x81703940 , cmd_table=0x0, dopager=1)
at /home/git/head/sys/ddb/db_command.c:453
#4  0x803fa789 in db_command_loop ()
at /home/git/head/sys/ddb/db_command.c:506
#5  0x803ff5da in db_trap (type=9, code=0)
at /home/git/head/sys/ddb/db_main.c:248
#6  0x807f6b3f in kdb_trap (type=9, code=0, tf=0xfe032db70370)
at /home/git/head/sys/kern/subr_kdb.c:654
#7  0x80ceb21c in trap_fatal (frame=0xfe032db70370, eva=0)
at /home/git/head/sys/amd64/amd64/trap.c:819
#8  0x80cea651 in trap (frame=0xfe032db70370)
at /home/git/head/sys/amd64/amd64/trap.c:553
#9  0x80cebd2a in trap_check (frame=0xfe032db70370)
at /home/git/head/sys/amd64/amd64/trap.c:625
#10 
#11 0x807833ed in _rw_wlock_cookie (c=0xdeadc0dedeadc2de, 
file=0x80ea3d10 "/home/git/head/sys/netinet/if_ether.c", line=287)
at /home/git/head/sys/kern/kern_rwlock.c:295
#12 0x80a2c723 in arptimer (arg=0xf80007d67a00)
at /home/git/head/sys/netinet/if_ether.c:287
#13 0x807b60bc in softclock_call_cc (c=0xf80007d67ab8, 
cc=0x81a31a00 , direct=0)
at /home/git/head/sys/kern/kern_timeout.c:729
#14 0x807b68ec in softclock (arg=0x81a31a00 )
at /home/git/head/sys/kern/kern_timeout.c:867
#15 0x807350c8 in intr_event_execute_handlers (p=0xf80003df9000, 
ie=0xf80003deea00) at /home/git/head/sys/kern/kern_intr.c:1262
#16 0x80735e57 in ithread_execute_handlers (p=0xf80003df9000, 
ie=0xf80003deea00) at /home/git/head/sys/kern/kern_intr.c:1275
#17 0x80735c86 in ithread_loop (arg=0xf80003e30060)
at /home/git/head/sys/kern/kern_intr.c:1356
#18 0x807306ee in fork_exit (
callout=0x80735b10 , arg=0xf80003e30060, 
frame=0xfe032db70ac0) at /home/git/head/sys/kern/kern_fork.c:1038
#19 
(kgdb) 

(kgdb) up

Re: resolvconf Makefile RESTARTCMD sed after r312992

2017-02-03 Thread Pedro Giffuni 

Committed as r313160.

Thanks!

Pedro.

On 2/3/2017 3:24 AM, Guy Yur wrote:

Hi,

In openresolv 3.9.0, the only RESTARTCMD pattern left is @RESTARTCMD@.
The '@RESTARTCMD something@' pattern was dropped from pdns_recursor.in.

r312992 removed RESTARTCMD_WITH_ARG for @RESTARTCMD something@ but
reverted the sed to be '@RESTARTCMD \(.*\)@' and RESTARTCMD= to be
the value of RESTARTCMD_WITH_ARG.

After the change /sbin/resolvconf has 'RESTARTCMD=@RESTARTCMD@' again.

Attaching patch to restore RESTARTCMD=, CMD1=, CMD2= and sed pattern
to values before r312992.

Thanks,
Guy


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: zfs snapshot_limit is not respected

2017-02-03 Thread Ultima 
Yes just tested this and it is how it works.

Thanks for the explanation.

Ultima
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: zfs snapshot_limit is not respected

2017-02-03 Thread Gary Palmer 
On Fri, Feb 03, 2017 at 10:27:48AM -0500, Ultima wrote:
> Hey Gary,
> 
> You are probably right. Do you know how to "lock" this property by chance?
> I'v read this exact line several times trying to understand the exact
> meaning. The "user is allowed to change the limit" I *think* is referring
> to the zfs allow command. The problem is that I checked the dataset and it
> is showing no permissions granted to a user. So I guess user in this case
> is also including the root user, but how does one lock the property from
> root? I keep going through the manpage looking for something I may have
> missed but keep coming up empty.

Hi,

I suspect you can't lock root out, but you could allow a different user
to create snapshots.  If you use that user to create snapshots, they
should be subject to the snapshot limit, assuming you don't let them
change that property.

Regards,

Gary

> Thanks for replying,
> Ultima
> 
> On Fri, Feb 3, 2017 at 7:42 AM, Gary Palmer  wrote:
> 
> > On Thu, Feb 02, 2017 at 09:31:58PM -0500, Ultima wrote:
> > > I recently moved some data on a box with limited space. I decided I
> > should
> > > limit the snapshots so that space would not become an issue. I just check
> > > back a week later to find out the box is hitting the borderline. Doing I
> > > quick check I realized that the snapshot_limit is not being respected.
> > >
> > > # uname -a
> > > FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15
> > 10:59:10
> > > EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/
> > MYKERNEL
> > >  amd64
> > >
> > > # zfs create zroot/bhyve/test
> > > # zfs set snapshot_limit=0 zroot/bhyve/test
> > > # zfs snapshot zroot/bhyve/test@1
> > >
> > >
> > > # zfs snapshot zroot/bhyve/test@2
> > > # zfs snapshot zroot/bhyve/test@3
> > > # zfs list -t snapshot | grep zroot/bhyve/test
> > > zroot/bhyve/test@1   0  -
> > >  88K  -
> > > zroot/bhyve/test@2   0  -
> > >  88K  -
> > > zroot/bhyve/test@3   0  -
> > >  88K  -
> > > # zfs get all zroot/bhyve/test | grep snapshot
> > > zroot/bhyve/test  usedbysnapshots   0  -
> > > zroot/bhyve/test  snapshot_limit0  local
> > > zroot/bhyve/test  snapshot_count3  local
> > >
> > > Also wanted to verify 0 was not being mistaken for none.
> > >
> > > # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk
> > > '{print $1}'`; do zfs destroy $snapshot ; done
> > >
> > > # zfs get all zroot/bhyve/test | grep snapshot
> > > zroot/bhyve/test  usedbysnapshots   0  -
> > > zroot/bhyve/test  snapshot_limit0  local
> > > zroot/bhyve/test  snapshot_count0  local
> > >
> > > # zfs set snapshot_limit=1 zroot/bhyve/test
> > > # zfs snapshot zroot/bhyve/test@1
> > > # zfs snapshot zroot/bhyve/test@2
> > > # zfs snapshot zroot/bhyve/test@3
> > > # zfs get all zroot/bhyve/test | grep snapshot
> > > zroot/bhyve/test  usedbysnapshots   0  -
> > > zroot/bhyve/test  snapshot_limit1  local
> > > zroot/bhyve/test  snapshot_count3  local
> > >
> > >
> > > Also tested on head
> > > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18
> > > 12:38:52 EST 2017
> > > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG
> > >  amd64
> >
> > Hi,
> >
> > I suspect this line from the manpage is key:
> >
> > The limit is not enforced if the user is allowed to change the limit
> >
> > Regards,
> >
> > Gary
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: zfs snapshot_limit is not respected

2017-02-03 Thread Ultima 
Hey Gary,

You are probably right. Do you know how to "lock" this property by chance?
I'v read this exact line several times trying to understand the exact
meaning. The "user is allowed to change the limit" I *think* is referring
to the zfs allow command. The problem is that I checked the dataset and it
is showing no permissions granted to a user. So I guess user in this case
is also including the root user, but how does one lock the property from
root? I keep going through the manpage looking for something I may have
missed but keep coming up empty.

Thanks for replying,
Ultima

On Fri, Feb 3, 2017 at 7:42 AM, Gary Palmer  wrote:

> On Thu, Feb 02, 2017 at 09:31:58PM -0500, Ultima wrote:
> > I recently moved some data on a box with limited space. I decided I
> should
> > limit the snapshots so that space would not become an issue. I just check
> > back a week later to find out the box is hitting the borderline. Doing I
> > quick check I realized that the snapshot_limit is not being respected.
> >
> > # uname -a
> > FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15
> 10:59:10
> > EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/
> MYKERNEL
> >  amd64
> >
> > # zfs create zroot/bhyve/test
> > # zfs set snapshot_limit=0 zroot/bhyve/test
> > # zfs snapshot zroot/bhyve/test@1
> >
> >
> > # zfs snapshot zroot/bhyve/test@2
> > # zfs snapshot zroot/bhyve/test@3
> > # zfs list -t snapshot | grep zroot/bhyve/test
> > zroot/bhyve/test@1   0  -
> >  88K  -
> > zroot/bhyve/test@2   0  -
> >  88K  -
> > zroot/bhyve/test@3   0  -
> >  88K  -
> > # zfs get all zroot/bhyve/test | grep snapshot
> > zroot/bhyve/test  usedbysnapshots   0  -
> > zroot/bhyve/test  snapshot_limit0  local
> > zroot/bhyve/test  snapshot_count3  local
> >
> > Also wanted to verify 0 was not being mistaken for none.
> >
> > # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk
> > '{print $1}'`; do zfs destroy $snapshot ; done
> >
> > # zfs get all zroot/bhyve/test | grep snapshot
> > zroot/bhyve/test  usedbysnapshots   0  -
> > zroot/bhyve/test  snapshot_limit0  local
> > zroot/bhyve/test  snapshot_count0  local
> >
> > # zfs set snapshot_limit=1 zroot/bhyve/test
> > # zfs snapshot zroot/bhyve/test@1
> > # zfs snapshot zroot/bhyve/test@2
> > # zfs snapshot zroot/bhyve/test@3
> > # zfs get all zroot/bhyve/test | grep snapshot
> > zroot/bhyve/test  usedbysnapshots   0  -
> > zroot/bhyve/test  snapshot_limit1  local
> > zroot/bhyve/test  snapshot_count3  local
> >
> >
> > Also tested on head
> > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18
> > 12:38:52 EST 2017
> > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG
> >  amd64
>
> Hi,
>
> I suspect this line from the manpage is key:
>
> The limit is not enforced if the user is allowed to change the limit
>
> Regards,
>
> Gary
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: zfs snapshot_limit is not respected

2017-02-03 Thread Gary Palmer 
On Thu, Feb 02, 2017 at 09:31:58PM -0500, Ultima wrote:
> I recently moved some data on a box with limited space. I decided I should
> limit the snapshots so that space would not become an issue. I just check
> back a week later to find out the box is hitting the borderline. Doing I
> quick check I realized that the snapshot_limit is not being respected.
> 
> # uname -a
> FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15 10:59:10
> EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/MYKERNEL
>  amd64
> 
> # zfs create zroot/bhyve/test
> # zfs set snapshot_limit=0 zroot/bhyve/test
> # zfs snapshot zroot/bhyve/test@1
> 
> 
> # zfs snapshot zroot/bhyve/test@2
> # zfs snapshot zroot/bhyve/test@3
> # zfs list -t snapshot | grep zroot/bhyve/test
> zroot/bhyve/test@1   0  -
>  88K  -
> zroot/bhyve/test@2   0  -
>  88K  -
> zroot/bhyve/test@3   0  -
>  88K  -
> # zfs get all zroot/bhyve/test | grep snapshot
> zroot/bhyve/test  usedbysnapshots   0  -
> zroot/bhyve/test  snapshot_limit0  local
> zroot/bhyve/test  snapshot_count3  local
> 
> Also wanted to verify 0 was not being mistaken for none.
> 
> # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk
> '{print $1}'`; do zfs destroy $snapshot ; done
> 
> # zfs get all zroot/bhyve/test | grep snapshot
> zroot/bhyve/test  usedbysnapshots   0  -
> zroot/bhyve/test  snapshot_limit0  local
> zroot/bhyve/test  snapshot_count0  local
> 
> # zfs set snapshot_limit=1 zroot/bhyve/test
> # zfs snapshot zroot/bhyve/test@1
> # zfs snapshot zroot/bhyve/test@2
> # zfs snapshot zroot/bhyve/test@3
> # zfs get all zroot/bhyve/test | grep snapshot
> zroot/bhyve/test  usedbysnapshots   0  -
> zroot/bhyve/test  snapshot_limit1  local
> zroot/bhyve/test  snapshot_count3  local
> 
> 
> Also tested on head
> FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18
> 12:38:52 EST 2017
> root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG
>  amd64

Hi,

I suspect this line from the manpage is key:

The limit is not enforced if the user is allowed to change the limit

Regards,

Gary
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

resolvconf Makefile RESTARTCMD sed after r312992

2017-02-03 Thread Guy Yur 
Hi,

In openresolv 3.9.0, the only RESTARTCMD pattern left is @RESTARTCMD@.
The '@RESTARTCMD something@' pattern was dropped from pdns_recursor.in.

r312992 removed RESTARTCMD_WITH_ARG for @RESTARTCMD something@ but
reverted the sed to be '@RESTARTCMD \(.*\)@' and RESTARTCMD= to be
the value of RESTARTCMD_WITH_ARG.

After the change /sbin/resolvconf has 'RESTARTCMD=@RESTARTCMD@' again.

Attaching patch to restore RESTARTCMD=, CMD1=, CMD2= and sed pattern
to values before r312992.

Thanks,
Guy


resolvconf_RESTARTCMD_sed.patch
Description: Binary data
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"