Last call for 2016Q2 quarterly status reports

2016-07-06 Thread Benjamin Kaduk 
Reminder: we're still looking for more submissions for the 2015Q2 status
report!  Please let us know if you wish to write an entry, even if it will
not be finished by today.

Thanks,

Ben (for the monthly@ team)

On Tue, 21 Jun 2016, Benjamin Kaduk wrote:

> Dear FreeBSD Community,
>
> The deadline for the next FreeBSD Quarterly Status update is July 7,
> 2016, for work done in April through June.
>
> Status report submissions do not have to be very long.  They may be about
> anything happening in the FreeBSD project and community, and provide a
> great way to inform FreeBSD users and developers about what you're working
> on.  Submission of reports is not restricted to committers.  Anyone doing
> anything interesting and FreeBSD-related can -- and should -- write one!
>
> The preferred and easiest submission method is to use the XML generator
> [1] with the results emailed to the status report team at monthly at
> FreeBSD.org .  There is also an XML template [2] which can be filled out
> manually and attached if preferred.  For the expected content and style,
> please study our guidelines on how to write a good status report [3].
> You can also review previous issues [4][5] for ideas on the style and
> format.
>
> We are looking forward to all of your 2016Q2 reports!
>
> Thanks,
>
> Ben (on behalf of monthly@)
>
> [1] http://www.freebsd.org/cgi/monthly.cgi
> [2] http://www.freebsd.org/news/status/report-sample.xml
> [3] http://www.freebsd.org/news/status/howto.html
> [4] http://www.freebsd.org/news/status/report-2015-10-2015-12.html
> [4] http://www.freebsd.org/news/status/report-2016-01-2016-03.html
>
>
___
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"

dtrace and kernel modules

2016-07-06 Thread Julian Elischer 
I'm specifically interested in the case of kernel modules that 
instantiate new syscalls.


How much support do we have for that?  In the one example in our 
sources of a kld with a syscall (kgssapi.ko) dtrace seems to find 
regular function entrypoints but not the syscall.



root@porridge:/usr/src # dtrace -n ":kgssapi::entry {}"
dtrace: description ':kgssapi::entry ' matched 138 probes
^C

root@porridge:/usr/src # dtrace -n "syscall:kgssapi::entry {}"
dtrace: invalid probe specifier syscall:kgssapi::entry {}: probe 
description syscall:kgssapi::entry does not match any probes

root@porridge:/usr/src #


Do we have plans to support dynamic syscall support?

___
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: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

2016-07-06 Thread K. Macy 
On Wednesday, July 6, 2016, Don Lewis  wrote:

> On  6 Jul, Matthew Macy wrote:
> > As a first step towards managing linux user space in a chrooted
> > /compat/linux, initially for i915 testing with intel gpu tools, later
> > on to get widevine and steam to work I'm trying to get apt to work.
> > I've fixed a number of issues to date in pseudofs/linprocfs but now
> > I'm running in to a bug caused by differences in SIGCHLD handling
> > between Linux and FreeBSD. The situation is that apt will spawn dpkg
> > and wait on a pipe read. On Linux when dpkg exits the  SIGCHLD to apt
> > causes a short read on the pipe which lets apt then continue. On
> > FreeBSD a SIGCHLD is silently ignored. I've even experimented with
> > doing a kill -20  to no effect.
> >
> > It would be easy enough to check sysvec against linux in pipe_read and
> > break out of the loop when it's awakened from msleep (assuming there
> > aren't deeper issues with signal propagation for anything other than
> > SIGINT/SIGKILL) and then do a short read. However, I'm assuming that
> > anyone who has worked in this area probably has a cleaner solution.
>
> It shoulds like SA_RESTART is set in sa_flags for SIGCHLD but shouldn't
> be in this case.



Good point.

Thinking more about it, this seems like a bug in FreeBSD. Not a valid
behavioral difference.

-M

>
> ___
> 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: difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

2016-07-06 Thread Don Lewis 
On  6 Jul, Matthew Macy wrote:
> As a first step towards managing linux user space in a chrooted
> /compat/linux, initially for i915 testing with intel gpu tools, later
> on to get widevine and steam to work I'm trying to get apt to work.
> I've fixed a number of issues to date in pseudofs/linprocfs but now
> I'm running in to a bug caused by differences in SIGCHLD handling
> between Linux and FreeBSD. The situation is that apt will spawn dpkg
> and wait on a pipe read. On Linux when dpkg exits the  SIGCHLD to apt
> causes a short read on the pipe which lets apt then continue. On
> FreeBSD a SIGCHLD is silently ignored. I've even experimented with
> doing a kill -20  to no effect.
>  
> It would be easy enough to check sysvec against linux in pipe_read and
> break out of the loop when it's awakened from msleep (assuming there
> aren't deeper issues with signal propagation for anything other than
> SIGINT/SIGKILL) and then do a short read. However, I'm assuming that
> anyone who has worked in this area probably has a cleaner solution.

It shoulds like SA_RESTART is set in sa_flags for SIGCHLD but shouldn't
be in this case.

___
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"

difference in SIGCHLD behavior between Linux and FreeBSD breaks apt

2016-07-06 Thread Matthew Macy 
As a first step towards managing linux user space in a chrooted /compat/linux, 
initially for i915 testing with intel gpu tools, later on to get widevine and 
steam to work I'm trying to get apt to work. I've fixed a number of issues to 
date in pseudofs/linprocfs but now I'm running in to a bug caused by 
differences in SIGCHLD handling between Linux and FreeBSD. The situation is 
that apt will spawn dpkg and wait on a pipe read. On Linux when dpkg exits the  
SIGCHLD to apt causes a short read on the pipe which lets apt then continue. On 
FreeBSD a SIGCHLD is silently ignored. I've even experimented with doing a kill 
-20  to no effect.
 
It would be easy enough to check sysvec against linux in pipe_read and break 
out of the loop when it's awakened from msleep (assuming there aren't deeper 
issues with signal propagation for anything other than SIGINT/SIGKILL) and then 
do a short read. However, I'm assuming that anyone who has worked in this area 
probably has a cleaner solution.

Thanks in advance.

-M

___
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: Setting sysctl vfs.zfs.arc_max failed: 22

2016-07-06 Thread Steven Hartland 

On 06/07/2016 21:39, Eric van Gyzen wrote:

On 07/06/16 03:35 PM, Steven Hartland wrote:

The ARC settings and kmem aren't initialised when tunables are loaded
so the tests fail.

I've fixed this locally by blindly setting if ARC is not configured.
Request to commit the fix is with re@

In the mean time the patch is attached.

Thanks for the report and sorry about the breakage.

No worries.  Thanks for the quick fix.


https://svnweb.freebsd.org/changeset/base/302382
___
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: Setting sysctl vfs.zfs.arc_max failed: 22

2016-07-06 Thread Nathan Bosley 
Awesome.
I'll probably try this tonight or tomorrow.

Thanks very much!

On Wed, Jul 6, 2016 at 4:35 PM, Steven Hartland 
wrote:

> The ARC settings and kmem aren't initialised when tunables are loaded so
> the tests fail.
>
> I've fixed this locally by blindly setting if ARC is not configured.
> Request to commit the fix is with re@
>
> In the mean time the patch is attached.
>
> Thanks for the report and sorry about the breakage.
>
>
> On 06/07/2016 07:20, Nathan Bosley wrote:
>
>> Maybe I misunderstood after all.
>> I took this:
>> "You can work around it temporarily by setting a lower arc_min first."
>>
>> To mean that I could do something like:
>> vfs.zfs.arc_min="1073741824"
>> vfs.zfs.arc_max="8589934592"
>>
>> in loader.conf, which would circumvent the problem.
>> But with the above, in that order, I still get:
>>
>> Setting sysctl vfs.zfs.arc_max failed: 22
>> Setting sysctl vfs.zfs.arc_min failed: 22
>>
>> As an FYI, WITHOUT any tunables set, my defaults are:
>> vfs.zfs.arc_meta_limit: 3903459328
>> vfs.zfs.arc_min: 1951729664
>> vfs.zfs.arc_max: 15613837312
>>
>> So even if I only specified:
>> vfs.zfs.arc_max="8589934592"
>>
>> in loader.conf, that's still not below my default min.
>>
>> However, if I make the changes with 'sysctl' after boot, it works fine:
>>
>> root@athlonbsd:~ # sysctl vfs.zfs.arc_min="1073741824"
>> vfs.zfs.arc_min: 1951729664 -> 1073741824
>>
>> root@athlonbsd:~ # sysctl vfs.zfs.arc_max="8589934592"
>>
>> vfs.zfs.arc_max: 15613837312 -> 8589934592
>>
>> They also work fine sysctl.conf.
>>
>> Sorry if this is a silly question:
>> I should still be able to set these max/min values in loader.conf,
>> right--not just in sysctl.conf?
>>
>> Thanks.
>>
>>
>> On Tue, Jul 5, 2016 at 10:16 PM, Nathan Bosley 
>> wrote:
>>
>> OK, I follow you now.
>>> Thanks for the explanation.
>>> I will try that later tonight or tomorrow.
>>>
>>> On Tue, Jul 5, 2016 at 9:45 PM, Allan Jude 
>>> wrote:
>>>
>>> On 2016-07-05 21:32, Nathan Bosley wrote:

> I think in about 4 - 5 hours I can show what values I'm using in
> loader.conf under, say, r302264 and r302265 for comparison. I'm not
> 100%
> sure that the problem arose for me in r302265; I merely suspect it.
>
> On Tue, Jul 5, 2016 at 9:25 PM, Allan Jude  > wrote:
>
>  On 2016-07-05 20:27, Steven Hartland wrote:
>  > Ahh right, let me check that.
>  >
>  > On 06/07/2016 00:51, Nathan Bosley wrote:
>  >> I actually have this same problem.
>  >> I'll send more details when I get home later.
>  >>
>  >> I think the problem started for me after r302265.
>  >> Before that, I can set vfs.zfs.arc_max and vfs.zfs.arc_min in
>  >> loader.conf.
>  >> After r302265, setting either vfs.zfs.arc_max or
> vfs.zfs.arc_min
>
 in

>  >> loader.conf results in the EINVAL errors in 'dmesg':
>  >>
>  >> Setting sysctl vfs.zfs.arc_max failed: 22
>  >> Setting sysctl vfs.zfs.arc_min failed: 22
>  >>
>  >> But setting vfs.zfs.arc_meta_limit in loader.conf works fine.
>  >>
>  >> But I did notice that using 'sysct' or sysctl.conf for
>
 vfs.zfs.arc_max

>  >> and vfs.zfs.arc_min works.
>  >> I only have problems with setting them now in loader.conf.
>  >>
>  >> Like I said, I'll try to send output from my setup later.
>  >>
>  >> Thanks.
>  >>
>  >> On Tue, Jul 5, 2016 at 6:10 PM, Steven Hartland
>  >> 
>  >>
>
 wrote:

>  >>
>  >> What is it currently?
>  >>
>  >> Just had a quick play here:
>  >> sysctl vfs.zfs.arc_max
>  >> vfs.zfs.arc_max: 32283127808
>  >> sysctl vfs.zfs.arc_max=32283127807
>  >> vfs.zfs.arc_max: 32283127808 -> 32283127807
>  >> sysctl vfs.zfs.arc_max=32283127808
>  >> vfs.zfs.arc_max: 32283127807 -> 32283127808
>  >>
>  >> Error 22 = EINVAL so I suspect you're requesting a value
>  which one
>  >> of the following:
>  >> * < arc_abs_min
>  >> * > kmem_size
>  >> * < arc_c_min
>  >> * < zfs_arc_meta_limit
>  >>
>  >> Regards
>  >> Steve
>  >>
>  >> On 05/07/2016 22:56, Eric van Gyzen wrote:
>  >>
>  >> Steven and -current:
>  >>
>  >> I just updated to r302350 with a GENERIC kernel config.
>  I see
>  >> this in
>  >> dmesg:
>  >>
>  >>

Re: refcnt 0 on LLE at boot....

2016-07-06 Thread Larry Rosenman 

Got a similar crash a few minutes later.


On 2016-07-06 18:17, Larry Rosenman wrote:

First boot, and I got the following panic.  2nd boot ran just fine.


borg.lerctr.org dumped core - see /var/crash/vmcore.0

Wed Jul  6 18:13:34 CDT 2016

FreeBSD borg.lerctr.org 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #5 r302379:
Wed Jul  6 16:59:11 CDT 2016
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64

panic: bogus refcnt 0 on lle 0xf800aa941200

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"...

Unread portion of the kernel message buffer:
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 
1994

The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-ALPHA6 #5 r302379: Wed Jul  6 16:59:11 CDT 2016
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
LLVM 3.8.0)
can't re-use a leaf (ixl_rx_miss_bufs)!
MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
MEMGUARD map base: 0xfe40
MEMGUARD map size: 128604256 KBytes
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  Stepping=6

Features=0xbfebfbff

Features2=0xce3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65382842368 (62353 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
random: unblocking device.
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
random: entropy device external interface
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80f2cb40, 0) error 19
kbd1 at kbdmux0
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
unknown: I/O range not supported
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 
on acpi0

Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 350
Event timer "HPET1" frequency 14318180 Hz quality 340
Event timer "HPET2" frequency 14318180 Hz quality 340
atrtc0:  port 0x70-0x71 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0:  port 0x2000-0x201f
mem 0xd922-0xd923,0xd920-0xd921 irq 18 at device 0.0
on pci6
em0: Using an MSI interrupt
em0: Ethernet address: 00:30:48:f2:29:9c
em0: netmap queues/slots: TX 1/1024, RX 1/1024
em1:  port 0x2020-0x203f
mem 0xd926-0xd927,0xd924-0xd925 irq 19 at device 0.1
on pci6
em1: Using an MSI interrupt
em1: Ethernet address: 00:30:48:f2:29:9d
em1: netmap queues/slots: TX 1/1024, RX 1/1024
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
vgapci0:  port 0x3000-0x307f mem
0xd800-0xd8ff,0xc000-0xc7ff,0xc800-0xc9ff irq
36 at device 0.0 on pci8
hdac0:  mem 0xd900-0xd9003fff irq 37
at device 0.1 on pci8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pcib10:  irq 17 at device 28.0 on pci0
pcib10: [GIANT-LOCKED]
pci10:  on pcib10
pcib11:  irq 32 at device 0.0 on pci10
pci11:  on pcib11
pcm0:  port 0x4080-0x409f,0x4000-0x407f irq
32 at device 0.0 on pci11
pcm0: system configuration
  SubVendorID: 0x1412, SubDeviceID: 0x2403
  XIN2 Clock Source: 24.576MHz(96kHz*256)
  MPU-401 UART(s) #: not implemented
  ADC #: 1 and SPDIF

refcnt 0 on LLE at boot....

2016-07-06 Thread Larry Rosenman 
First boot, and I got the following panic.  2nd boot ran just fine. 


borg.lerctr.org dumped core - see /var/crash/vmcore.0

Wed Jul  6 18:13:34 CDT 2016

FreeBSD borg.lerctr.org 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #5 r302379: Wed Jul  6 
16:59:11 CDT 2016 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64

panic: bogus refcnt 0 on lle 0xf800aa941200

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"...

Unread portion of the kernel message buffer:
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-ALPHA6 #5 r302379: Wed Jul  6 16:59:11 CDT 2016
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
3.8.0)
can't re-use a leaf (ixl_rx_miss_bufs)!
MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
MEMGUARD map base: 0xfe40
MEMGUARD map size: 128604256 KBytes
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  Stepping=6
  
Features=0xbfebfbff
  
Features2=0xce3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65382842368 (62353 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
random: unblocking device.
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
random: entropy device external interface
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80f2cb40, 0) error 19
kbd1 at kbdmux0
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
unknown: I/O range not supported
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 350
Event timer "HPET1" frequency 14318180 Hz quality 340
Event timer "HPET2" frequency 14318180 Hz quality 340
atrtc0:  port 0x70-0x71 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0:  port 0x2000-0x201f mem 
0xd922-0xd923,0xd920-0xd921 irq 18 at device 0.0 on pci6
em0: Using an MSI interrupt
em0: Ethernet address: 00:30:48:f2:29:9c
em0: netmap queues/slots: TX 1/1024, RX 1/1024
em1:  port 0x2020-0x203f mem 
0xd926-0xd927,0xd924-0xd925 irq 19 at device 0.1 on pci6
em1: Using an MSI interrupt
em1: Ethernet address: 00:30:48:f2:29:9d
em1: netmap queues/slots: TX 1/1024, RX 1/1024
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
vgapci0:  port 0x3000-0x307f mem 
0xd800-0xd8ff,0xc000-0xc7ff,0xc800-0xc9ff irq 36 at 
device 0.0 on pci8
hdac0:  mem 0xd900-0xd9003fff irq 37 at device 
0.1 on pci8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pcib10:  irq 17 at device 28.0 on pci0
pcib10: [GIANT-LOCKED]
pci10:  on pcib10
pcib11:  irq 32 at device 0.0 on pci10
pci11:  on pcib11
pcm0:  port 0x4080-0x409f,0x4000-0x407f irq 32 at 
device 0.0 on pci11
pcm0: system configuration
  SubVendorID: 0x1412, SubDeviceID: 0x2403
  XIN2 Clock Source: 24.576MHz(96kHz*256)
  MPU-401 UART(s) #: not implemented
  ADC #: 1 and SPDIF receiver connected
  DAC #: 4
  Multi-track converter type: AC'97(SDATA_OUT:packed)

Re: Setting sysctl vfs.zfs.arc_max failed: 22

2016-07-06 Thread Eric van Gyzen 
On 07/06/16 03:35 PM, Steven Hartland wrote:
> The ARC settings and kmem aren't initialised when tunables are loaded
> so the tests fail.
>
> I've fixed this locally by blindly setting if ARC is not configured.
> Request to commit the fix is with re@
>
> In the mean time the patch is attached.
>
> Thanks for the report and sorry about the breakage.

No worries.  Thanks for the quick fix.

Eric
___
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: Setting sysctl vfs.zfs.arc_max failed: 22

2016-07-06 Thread Steven Hartland 
The ARC settings and kmem aren't initialised when tunables are loaded so 
the tests fail.


I've fixed this locally by blindly setting if ARC is not configured. 
Request to commit the fix is with re@


In the mean time the patch is attached.

Thanks for the report and sorry about the breakage.

On 06/07/2016 07:20, Nathan Bosley wrote:

Maybe I misunderstood after all.
I took this:
"You can work around it temporarily by setting a lower arc_min first."

To mean that I could do something like:
vfs.zfs.arc_min="1073741824"
vfs.zfs.arc_max="8589934592"

in loader.conf, which would circumvent the problem.
But with the above, in that order, I still get:

Setting sysctl vfs.zfs.arc_max failed: 22
Setting sysctl vfs.zfs.arc_min failed: 22

As an FYI, WITHOUT any tunables set, my defaults are:
vfs.zfs.arc_meta_limit: 3903459328
vfs.zfs.arc_min: 1951729664
vfs.zfs.arc_max: 15613837312

So even if I only specified:
vfs.zfs.arc_max="8589934592"

in loader.conf, that's still not below my default min.

However, if I make the changes with 'sysctl' after boot, it works fine:

root@athlonbsd:~ # sysctl vfs.zfs.arc_min="1073741824"
vfs.zfs.arc_min: 1951729664 -> 1073741824

root@athlonbsd:~ # sysctl vfs.zfs.arc_max="8589934592"

vfs.zfs.arc_max: 15613837312 -> 8589934592

They also work fine sysctl.conf.

Sorry if this is a silly question:
I should still be able to set these max/min values in loader.conf,
right--not just in sysctl.conf?

Thanks.


On Tue, Jul 5, 2016 at 10:16 PM, Nathan Bosley 
wrote:


OK, I follow you now.
Thanks for the explanation.
I will try that later tonight or tomorrow.

On Tue, Jul 5, 2016 at 9:45 PM, Allan Jude  wrote:


On 2016-07-05 21:32, Nathan Bosley wrote:

I think in about 4 - 5 hours I can show what values I'm using in
loader.conf under, say, r302264 and r302265 for comparison. I'm not 100%
sure that the problem arose for me in r302265; I merely suspect it.

On Tue, Jul 5, 2016 at 9:25 PM, Allan Jude > wrote:

 On 2016-07-05 20:27, Steven Hartland wrote:
 > Ahh right, let me check that.
 >
 > On 06/07/2016 00:51, Nathan Bosley wrote:
 >> I actually have this same problem.
 >> I'll send more details when I get home later.
 >>
 >> I think the problem started for me after r302265.
 >> Before that, I can set vfs.zfs.arc_max and vfs.zfs.arc_min in
 >> loader.conf.
 >> After r302265, setting either vfs.zfs.arc_max or vfs.zfs.arc_min

in

 >> loader.conf results in the EINVAL errors in 'dmesg':
 >>
 >> Setting sysctl vfs.zfs.arc_max failed: 22
 >> Setting sysctl vfs.zfs.arc_min failed: 22
 >>
 >> But setting vfs.zfs.arc_meta_limit in loader.conf works fine.
 >>
 >> But I did notice that using 'sysct' or sysctl.conf for

vfs.zfs.arc_max

 >> and vfs.zfs.arc_min works.
 >> I only have problems with setting them now in loader.conf.
 >>
 >> Like I said, I'll try to send output from my setup later.
 >>
 >> Thanks.
 >>
 >> On Tue, Jul 5, 2016 at 6:10 PM, Steven Hartland
 >> 
 >>

wrote:

 >>
 >> What is it currently?
 >>
 >> Just had a quick play here:
 >> sysctl vfs.zfs.arc_max
 >> vfs.zfs.arc_max: 32283127808
 >> sysctl vfs.zfs.arc_max=32283127807
 >> vfs.zfs.arc_max: 32283127808 -> 32283127807
 >> sysctl vfs.zfs.arc_max=32283127808
 >> vfs.zfs.arc_max: 32283127807 -> 32283127808
 >>
 >> Error 22 = EINVAL so I suspect you're requesting a value
 which one
 >> of the following:
 >> * < arc_abs_min
 >> * > kmem_size
 >> * < arc_c_min
 >> * < zfs_arc_meta_limit
 >>
 >> Regards
 >> Steve
 >>
 >> On 05/07/2016 22:56, Eric van Gyzen wrote:
 >>
 >> Steven and -current:
 >>
 >> I just updated to r302350 with a GENERIC kernel config.
 I see
 >> this in
 >> dmesg:
 >>
 >>  VT(efifb): resolution 1024x768
 >>  Setting sysctl vfs.zfs.arc_max failed: 22
 >>  CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
 >> (3491.98-MHz K8-class
 >>  CPU)
 >>
 >> The relevant parts of /boot/loader.conf are:
 >>
 >>  zfs_load="YES"
 >>  vfs.zfs.arc_max="6442450944"
 >>
 >> Let me know what other information you need.
 >>
 >> Cheers,
 >>
 >> Eric
 >>
 >>
 >> ___
 >> freebsd-current@freebsd.org
 
 >
 >> mailing

Re: Issues to maybe prioritize before pkg-base

2016-07-06 Thread Mark Felder 


On Tue, Jul 5, 2016, at 13:01, Jeffrey Bouquet wrote:
> Main disk would not boot cleanly.
> could not fsck_ffs, cannot find inode
> files went missing from /etc (make.conf, pf.conf, firewall*, 
> file went missing from rc.d
> files went missing from /etc/X11
> shell history file remained locked.
> find suddenly could not find /usr/local/lib/*/libc.so.5
> freecolor could not find its libraries
> Xorg could not find lib* in /usr/local/lib
> 
> 
> etc
> somewhat fixed those from backup.
> Which hosed the latest pkg install * upgrades (byobu bump, etc) which I
> reinstalled
> Put the disk on backup, latter mountroot, ran fsck_ffs on the failing
> disk /root and /usr, multiple times,
> ..
> Inexplicably got all libraries back, working, and files restored AS FAR
> AS I KNOW
> but as usual in this case, which happens at least twice a year, although
> I restore
> the desktop and programs (usually) to a working state, with adequate
> backups,


Are you getting UFS corruption and have SU+J enabled? You might want to
turn off SU+J and just use SU. That's probably the issue.


-- 
  Mark Felder
  ports-secteam member
  f...@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: Setting sysctl vfs.zfs.arc_max failed: 22

2016-07-06 Thread Steven Hartland 

On 06/07/2016 02:25, Allan Jude wrote:

On 2016-07-05 20:27, Steven Hartland wrote:

Ahh right, let me check that.

On 06/07/2016 00:51, Nathan Bosley wrote:

I actually have this same problem.
I'll send more details when I get home later.

I think the problem started for me after r302265.
Before that, I can set vfs.zfs.arc_max and vfs.zfs.arc_min in
loader.conf.
After r302265, setting either vfs.zfs.arc_max or vfs.zfs.arc_min in
loader.conf results in the EINVAL errors in 'dmesg':

Setting sysctl vfs.zfs.arc_max failed: 22
Setting sysctl vfs.zfs.arc_min failed: 22

But setting vfs.zfs.arc_meta_limit in loader.conf works fine.

But I did notice that using 'sysct' or sysctl.conf for vfs.zfs.arc_max
and vfs.zfs.arc_min works.
I only have problems with setting them now in loader.conf.

Like I said, I'll try to send output from my setup later.

Thanks.

On Tue, Jul 5, 2016 at 6:10 PM, Steven Hartland
> wrote:

 What is it currently?

 Just had a quick play here:
 sysctl vfs.zfs.arc_max
 vfs.zfs.arc_max: 32283127808
 sysctl vfs.zfs.arc_max=32283127807
 vfs.zfs.arc_max: 32283127808 -> 32283127807
 sysctl vfs.zfs.arc_max=32283127808
 vfs.zfs.arc_max: 32283127807 -> 32283127808

 Error 22 = EINVAL so I suspect you're requesting a value which one
 of the following:
 * < arc_abs_min
 * > kmem_size
 * < arc_c_min
 * < zfs_arc_meta_limit

 Regards
 Steve

 On 05/07/2016 22:56, Eric van Gyzen wrote:

 Steven and -current:

 I just updated to r302350 with a GENERIC kernel config.  I see
 this in
 dmesg:

  VT(efifb): resolution 1024x768
  Setting sysctl vfs.zfs.arc_max failed: 22
  CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
 (3491.98-MHz K8-class
  CPU)

 The relevant parts of /boot/loader.conf are:

  zfs_load="YES"
  vfs.zfs.arc_max="6442450944"

 Let me know what other information you need.

 Cheers,

 Eric



I think the issue might be that the default value of arc_min is higher
than when the user is trying to set arc_max to. In that case we might
want sysctl to lower arc_min instead of giving an error?

It would definitely be a POLA violation to have to set arc_min lower to
be able to have existing lines that set arc_max in loader.conf work
correctly.

I'm actually thinking its because the initial calculation hasn't 
occurred yet.


This is not apparent on 10 because the tunable and the sysctl are 
separate. I'm waiting for my head box to rebuild ATM and will check when 
that's done.


Regard
Steve
___
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_HEAD_amd64_gcc - Build #1345 - Fixed

2016-07-06 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1345 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1345/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1345/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1345/console

Change summaries:

302369 by ngie:
Fix gcc warning

Remove -Wunused-but-set-variable (`mopt`).

Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D7119
MFC after: 1 week
X-MFC with: r302332
Reported by: Jenkins
Reviewed by: grehan (maintainer)
Sponsored by: EMC / Isilon Storage Division

302368 by ngie:
Fix gcc build errors with SSE 4.2 detection and gcc warnings

- Remove -Wunused-but-set-variable's (`len`, etc).
- Replace clang-specific tests in sse42_supported(..) with generic,
  FreeBSD-supported CPU feature tests, using macros and functions
  from machine/cpufunc.h and machine/specialreg.h . The previous method
  for determining SSE4.2 availability was only compatible with clang.
- Sort #includes per style(9).

Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D7119
MFC after: 1 week
X-MFC with: r302332
Reported by: Jenkins
Reviewed by: grehan (maintainer)
Sponsored by: EMC / Isilon Storage Division

302367 by ngie:
Fix gcc warnings

Remove unused function (`fifo_available`)

Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D7119
MFC after: 1 week
X-MFC with: r302332
Reported by: Jenkins
Reviewed by: grehan (maintainer)
Sponsored by: EMC / Isilon Storage Division

302366 by ngie:
Fix gcc warnings

- Put parentheses around bitwise OR'ed values in the `FIELD_COPY(..)` and
  `FIELD_REPLACE(..)` macros to mute warning from gcc 4.2.1.
- Remove -Wunused-but-set-variable's (`setup_addr`, `status_addr`).

Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D7119
MFC after: 1 week
X-MFC with: r302332
Reported by: Jenkins
Reviewed by: grehan (maintainer)
Sponsored by: EMC / Isilon Storage Division

302365 by ngie:
Fix gcc warnings

Remove -Wunused-but-set-variable (`error`). Cast calls with
`(void)` to note that the return value is explicitly ignored.

Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D7119
MFC after: 1 week
Reported by: Jenkins
Reviewed by: grehan (maintainer)
Sponsored by: EMC / Isilon Storage Division

302364 by ngie:
Fix gcc warnings

Add `WRAPPED_CTASSERT` macro by annotating CTASSERTs with __unused
to deal with -Wunused-local-typedefs warnings from gcc 4.8+.
All other compilers (clang, etc) use CTASSERT as-is. A more generic
solution for this issue will be proposed after ^/stable/11 is forked.

Consolidate all CTASSERTs under one block instead of inlining them in
functions.

Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D7119
MFC after: 1 week
Reported by: Jenkins
Reviewed by: grehan (maintainer)
Sponsored by: EMC / Isilon Storage Division

302363 by ngie:
Fix gcc warnings

Put cfl/prdt under AHCI_DEBUG #defines as they are only used in
those cases.

Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D7119
MFC after: 1 week
Reported by: Jenkins
Reviewed by: grehan (maintainer)
Sponsored by: EMC / Isilon Storage Division

302362 by ngie:
Fix gcc warnings

- Remove -Wunused-but-set-variable (newcpu)
- Always return VMEXIT_CONTINUE as the code always set retval to that value.

Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D7119
MFC after: 1 week
Reported by: Jenkins
Reviewed by: grehan (maintainer)
Sponsored by: EMC / Isilon Storage Division

___
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: Setting sysctl vfs.zfs.arc_max failed: 22

2016-07-06 Thread Nathan Bosley 
Maybe I misunderstood after all.
I took this:
"You can work around it temporarily by setting a lower arc_min first."

To mean that I could do something like:
vfs.zfs.arc_min="1073741824"
vfs.zfs.arc_max="8589934592"

in loader.conf, which would circumvent the problem.
But with the above, in that order, I still get:

Setting sysctl vfs.zfs.arc_max failed: 22
Setting sysctl vfs.zfs.arc_min failed: 22

As an FYI, WITHOUT any tunables set, my defaults are:
vfs.zfs.arc_meta_limit: 3903459328
vfs.zfs.arc_min: 1951729664
vfs.zfs.arc_max: 15613837312

So even if I only specified:
vfs.zfs.arc_max="8589934592"

in loader.conf, that's still not below my default min.

However, if I make the changes with 'sysctl' after boot, it works fine:

root@athlonbsd:~ # sysctl vfs.zfs.arc_min="1073741824"
vfs.zfs.arc_min: 1951729664 -> 1073741824

root@athlonbsd:~ # sysctl vfs.zfs.arc_max="8589934592"

vfs.zfs.arc_max: 15613837312 -> 8589934592

They also work fine sysctl.conf.

Sorry if this is a silly question:
I should still be able to set these max/min values in loader.conf,
right--not just in sysctl.conf?

Thanks.


On Tue, Jul 5, 2016 at 10:16 PM, Nathan Bosley 
wrote:

> OK, I follow you now.
> Thanks for the explanation.
> I will try that later tonight or tomorrow.
>
> On Tue, Jul 5, 2016 at 9:45 PM, Allan Jude  wrote:
>
>> On 2016-07-05 21:32, Nathan Bosley wrote:
>> > I think in about 4 - 5 hours I can show what values I'm using in
>> > loader.conf under, say, r302264 and r302265 for comparison. I'm not 100%
>> > sure that the problem arose for me in r302265; I merely suspect it.
>> >
>> > On Tue, Jul 5, 2016 at 9:25 PM, Allan Jude > > > wrote:
>> >
>> > On 2016-07-05 20:27, Steven Hartland wrote:
>> > > Ahh right, let me check that.
>> > >
>> > > On 06/07/2016 00:51, Nathan Bosley wrote:
>> > >> I actually have this same problem.
>> > >> I'll send more details when I get home later.
>> > >>
>> > >> I think the problem started for me after r302265.
>> > >> Before that, I can set vfs.zfs.arc_max and vfs.zfs.arc_min in
>> > >> loader.conf.
>> > >> After r302265, setting either vfs.zfs.arc_max or vfs.zfs.arc_min
>> in
>> > >> loader.conf results in the EINVAL errors in 'dmesg':
>> > >>
>> > >> Setting sysctl vfs.zfs.arc_max failed: 22
>> > >> Setting sysctl vfs.zfs.arc_min failed: 22
>> > >>
>> > >> But setting vfs.zfs.arc_meta_limit in loader.conf works fine.
>> > >>
>> > >> But I did notice that using 'sysct' or sysctl.conf for
>> vfs.zfs.arc_max
>> > >> and vfs.zfs.arc_min works.
>> > >> I only have problems with setting them now in loader.conf.
>> > >>
>> > >> Like I said, I'll try to send output from my setup later.
>> > >>
>> > >> Thanks.
>> > >>
>> > >> On Tue, Jul 5, 2016 at 6:10 PM, Steven Hartland
>> > >> 
>> > >>
>> wrote:
>> > >>
>> > >> What is it currently?
>> > >>
>> > >> Just had a quick play here:
>> > >> sysctl vfs.zfs.arc_max
>> > >> vfs.zfs.arc_max: 32283127808
>> > >> sysctl vfs.zfs.arc_max=32283127807
>> > >> vfs.zfs.arc_max: 32283127808 -> 32283127807
>> > >> sysctl vfs.zfs.arc_max=32283127808
>> > >> vfs.zfs.arc_max: 32283127807 -> 32283127808
>> > >>
>> > >> Error 22 = EINVAL so I suspect you're requesting a value
>> > which one
>> > >> of the following:
>> > >> * < arc_abs_min
>> > >> * > kmem_size
>> > >> * < arc_c_min
>> > >> * < zfs_arc_meta_limit
>> > >>
>> > >> Regards
>> > >> Steve
>> > >>
>> > >> On 05/07/2016 22:56, Eric van Gyzen wrote:
>> > >>
>> > >> Steven and -current:
>> > >>
>> > >> I just updated to r302350 with a GENERIC kernel config.
>> > I see
>> > >> this in
>> > >> dmesg:
>> > >>
>> > >>  VT(efifb): resolution 1024x768
>> > >>  Setting sysctl vfs.zfs.arc_max failed: 22
>> > >>  CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
>> > >> (3491.98-MHz K8-class
>> > >>  CPU)
>> > >>
>> > >> The relevant parts of /boot/loader.conf are:
>> > >>
>> > >>  zfs_load="YES"
>> > >>  vfs.zfs.arc_max="6442450944"
>> > >>
>> > >> Let me know what other information you need.
>> > >>
>> > >> Cheers,
>> > >>
>> > >> Eric
>> > >>
>> > >>
>> > >> ___
>> > >> freebsd-current@freebsd.org
>> > 
>> > > >