panic: destroying non-empty racct: 2113536 allocated for resource 4

2016-05-16 Thread Andriy Gapon 

To be fair I got this panic after some exotic sequence of events: running
poudriere, sending SIGSTOP to one of build processes, forgetting about it,
seeing poudriere timeout that job, sending SIGCONT...

This is amd64 head r297350.

Some details:
(kgdb) bt
#0  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:295
#1  0x8062d7ef in kern_reboot (howto=) at
/usr/src/sys/kern/kern_shutdown.c:363
#2  0x8062de38 in vpanic (fmt=, ap=0xfe0519b73920) at
/usr/src/sys/kern/kern_shutdown.c:639
#3  0x8062db43 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:572
#4  0x8061ef1c in racct_destroy_locked (racctp=) at
/usr/src/sys/kern/kern_racct.c:478
#5  0x8061ee45 in racct_destroy (racct=0xf802f6301518) at
/usr/src/sys/kern/kern_racct.c:495
#6  0x805fdd3c in prison_racct_free_locked (prr=0xf802f6301400) at
/usr/src/sys/kern/kern_jail.c:4564
#7  0x805fdc8d in prison_racct_free (prr=0xf802f6301400) at
/usr/src/sys/kern/kern_jail.c:4583
#8  0x805fddee in prison_racct_detach (pr=0xf802b073) at
/usr/src/sys/kern/kern_jail.c:4658
#9  0x805fb2cb in prison_deref (pr=, flags=3) at
/usr/src/sys/kern/kern_jail.c:2663
#10 0x805fca25 in prison_remove_one (pr=) at
/usr/src/sys/kern/kern_jail.c:2358
#11 0x805fc8e4 in sys_jail_remove (td=, uap=) at /usr/src/sys/kern/kern_jail.c:2313
#12 0x80820ddd in syscallenter (td=0xf801146019e0,
sa=0xfe0519b73b80) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#13 0x808209af in amd64_syscall (td=0xf801146019e0, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:943

RACCT_RSS is 4.

(kgdb) p *prr
$5 = {
  prr_next = {
le_next = 0xf80382fe4400,
le_prev = 0xf8017ac90600
  },
  prr_name = "basejail-default-job-03", '\000' ,
  prr_refcount = 0,
  prr_racct = 0xf802e3f520b0
}
(kgdb) p *prr->prr_racct
$6 = {
  r_resources = {13884177072, 0, 0, 0, 2113536, 0 ,
13611325009, 0},
  r_rule_links = {
lh_first = 0x0
  }
}

Could it be that somehow the CONT'd process failed to deduct its resources from
the jail's resources because the jail was already marked for destruction or
something like that?

-- 
Andriy Gapon
___
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: Kernel panic - help

2016-05-16 Thread Greg Quinlan 
And again, at almost the same time ... kernel panic!!!
May 17 03:06:18 dns0 syslogd: kernel boot file is /boot/kernel/kernel
May 17 03:06:18 dns0 kernel: panic: softdep_deallocate_dependencies: dangling 
deps
May 17 03:06:18 dns0 kernel: cpuid = 1
May 17 03:06:18 dns0 kernel: KDB: stack backtrace:
May 17 03:06:18 dns0 kernel: #0 0x80ae4737 at kdb_backtrace+0x67
May 17 03:06:18 dns0 kernel: #1 0x80a9f502 at vpanic+0x182
May 17 03:06:18 dns0 kernel: #2 0x80a9f373 at panic+0x43
May 17 03:06:18 dns0 kernel: #3 0x80d5fa81 at 
softdep_deallocate_dependencies+0x71
May 17 03:06:18 dns0 kernel: #4 0x80b47eb9 at brelse+0x1b9
May 17 03:06:18 dns0 kernel: #5 0x80b456c2 at bufwrite+0x182
May 17 03:06:18 dns0 kernel: #6 0x80d8245c at ffs_write+0x39c
May 17 03:06:18 dns0 kernel: #7 0x81093459 at VOP_WRITE_APV+0x139
May 17 03:06:18 dns0 kernel: #8 0x80dce82a at 
vnode_pager_generic_putpages+0x38a
May 17 03:06:18 dns0 kernel: #9 0x810953b6 at VOP_PUTPAGES_APV+0xa6
May 17 03:06:18 dns0 kernel: #10 0x80dcc4be at vnode_pager_putpages+0xfe
May 17 03:06:18 dns0 kernel: #11 0x80dc19ca at vm_pageout_flush+0xea
May 17 03:06:18 dns0 kernel: #12 0x80db848a at 
vm_object_page_collect_flush+0x21a
May 17 03:06:18 dns0 kernel: #13 0x80db81c7 at 
vm_object_page_clean+0x197
May 17 03:06:18 dns0 kernel: #14 0x80db7c79 at vm_object_terminate+0x99
May 17 03:06:18 dns0 kernel: #15 0x80dccb96 at 
vnode_destroy_vobject+0xc6
May 17 03:06:18 dns0 kernel: #16 0x80d8a336 at ufs_reclaim+0x26
May 17 03:06:18 dns0 kernel: #17 0x810944b6 at VOP_RECLAIM_APV+0xa6
May 17 03:06:18 dns0 kernel: Uptime: 16h54m12s
May 17 03:06:18 dns0 kernel: Dumping 896 out of 8113 
MB:..2%..11%..22%..31%..42%..52%..61%..72%..81%..92%

On Monday, 16 May 2016, 7:24, Greg Quinlan  wrote:
 

 FreeBSD dns0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r299817M: Sun May 15 
18:55:50 AEST 2016    root@dns0:/usr/obj/usr/src/sys/GENERIC  amd64

===8<===
May 16 03:03:48 dns0 syslogd: kernel boot file is /boot/kernel/kernel
May 16 03:03:48 dns0 kernel: panic: softdep_deallocate_dependencies: dangling 
deps
May 16 03:03:48 dns0 kernel: cpuid = 0
May 16 03:03:48 dns0 kernel: KDB: stack backtrace:
May 16 03:03:48 dns0 kernel: #0 0x80ae4737 at kdb_backtrace+0x67
May 16 03:03:48 dns0 kernel: #1 0x80a9f502 at vpanic+0x182
May 16 03:03:48 dns0 kernel: #2 0x80a9f373 at panic+0x43
May 16 03:03:48 dns0 kernel: #3 0x80d5fa81 at 
softdep_deallocate_dependencies+0x71
May 16 03:03:48 dns0 kernel: #4 0x80b47eb9 at brelse+0x1b9
May 16 03:03:48 dns0 kernel: #5 0x80b456c2 at bufwrite+0x182
May 16 03:03:48 dns0 kernel: #6 0x80d8245c at ffs_write+0x39c
May 16 03:03:48 dns0 kernel: #7 0x81093459 at VOP_WRITE_APV+0x139
May 16 03:03:48 dns0 kernel: #8 0x80dce82a at 
vnode_pager_generic_putpages+0x38a
May 16 03:03:48 dns0 kernel: #9 0x810953b6 at VOP_PUTPAGES_APV+0xa6
May 16 03:03:48 dns0 kernel: #10 0x80dcc4be at vnode_pager_putpages+0xfe
May 16 03:03:48 dns0 kernel: #11 0x80dc19ca at vm_pageout_flush+0xea
May 16 03:03:48 dns0 kernel: #12 0x80db848a at 
vm_object_page_collect_flush+0x21a
May 16 03:03:48 dns0 kernel: #13 0x80db81c7 at 
vm_object_page_clean+0x197
May 16 03:03:48 dns0 kernel: #14 0x80db7c79 at vm_object_terminate+0x99
May 16 03:03:48 dns0 kernel: #15 0x80dccb96 at 
vnode_destroy_vobject+0xc6
May 16 03:03:48 dns0 kernel: #16 0x80d8a336 at ufs_reclaim+0x26
May 16 03:03:48 dns0 kernel: #17 0x810944b6 at VOP_RECLAIM_APV+0xa6
May 16 03:03:48 dns0 kernel: Uptime: 7h31m3s
May 16 03:03:48 dns0 kernel: Dumping 953 out of 8113 
MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91% 

Not sure if the above is useful, seems to happen early morning.

Thanks

Greg

  
___
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 #1247 - Fixed

2016-05-16 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1247 - Fixed:

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

Change summaries:

299960 by hselasky:
Only lock Giant when needed in the LinuxKPI.

Suggested by:   ngie @
MFC after:  1 week
Sponsored by:   Mellanox Technologies

299957 by mav:
Reduce verbosity of "now sending synthesized status" message.

MFC after:  1 week

299955 by mav:
No need to check login status for ZOMBIE ports.

ZOMBIE ports are always logged out, and so initiator may try to relogin.

MFC after:  1 weeks

299953 by truckman:
Fix an off by one error to avoid overflowing rp[].

Reported by:Coverity
CID:1007579

299952 by truckman:
Increase size of argv[] array to avoid running off the end.

Reported by:Coverity
CID:1193819
MFC after:  1 week

299951 by avg:
do not destroy 'snapdir' when it becomes  inactive

That was just wrong.  In fact, we can safely keep this static entry when
it's inactive.
Now the destructive action is moved to the reclaim method and the
function is renamed from zfsctl_snapdir_inactive(0 to
zfsctl_snapdir_reclaim().

Also, we can use gfs_vop_reclaim() instead of gfs_dir_inactive() +
kmem_free().

Lastly, we can just assert that the node does not any children when it
is reclaimed, even on the force unmount.  That's because zfs_umount()
does an extra vflush() pass which should destroy all snapshot-mountpoint
vnodes that are the snapdir's children.

MFC after:  5 weeks

299950 by truckman:
Fix off by one error in index limit calculation

Reported by:Coverity
CID:1193826

299949 by avg:
try to recycle "snap" vnodes as soon as possible

Those vnodes should not linger.  "Stale" nodes may get out of
synchronization with actual snapshots.  For example if we destroy a
snapshot and create a new one with the same name.  Or when we rename a
snapshot.

While there fix the argument type for zfsctl_snapshot_reclaim().
Also, its original argument can be passed to gfs_vop_reclaim() directly.

Bug 209093 could be related although I have not specifically verified
that.  Referencing just in case.

PR: 209093
MFC after:  5 weeks

299948 by truckman:
Set retval in the empty password case to avoid a path through the
code that fails to set retval before falling through to the final
return().

Reported by:emaste
Reported by:Coverity
CID:1018711
MFC after:  1 week

299947 by avg:
fix locking in zfsctl_root_lookup

Dropping the root vnode's lock after VFS_ROOT() didn't really help the
fact that we acquired the lock while holding its child's, .zfs, lock
while performing the operaiton.
So, directly use zfs_zget() to get the root vnode.

While there simplify the code in zfsctl_freebsd_root_lookup.
We know that .zfs is always exclusively locked.
We know that there is already a reference on *vpp, so no need for an
extra one.
Account for the fact that .. lookup may ask for a different lock type,
not necessarily LK_EXCLUSIVE.  And handle a possible failure to acquire
the lock given the lock flags.

MFC after:  5 weeks

299946 by avg:
gfs_lookup_dot() does not have to acquire any locks

In fact, that was dangerous.  For example, zfsctl_snapshot_reclaim()
calls gfs_dir_lookup() on ".." path and that ends up calling
gfs_lookup_dot() which violated locking order by acquiring the parent's
directory vnode lock after the child's vnode lock.

Also, the previous behavior was inconsistent as gfs_dir_lookup()
returned a locked vnode for . and .. lookups, but not for any other.

Now gfs_lookup_dot() just references a resulting vnode and the locking
is done in its consumers, where necessary.
Note that we do not enable shared locking support for any gfs / zfsctl
vnodes.

This commit partially reverts r273641.

MFC after:  5 weeks

299945 by avg:
avoid deadlock between zfsctl_snapdir_lookup and zfsctl_snapshot_reclaim

The former acquired a snap vnode lock while holding sd_lock while the
latter does the opposite.

The solution is drop sd_lock before acquiring the vnode lock.  That
should be okay as we are still holding a lock on the 'snapshot'
directory in the exclusive mode.  That lock ensures that there are no
concurrent lookups in the directory and thus no concurrent mount attempts.

But now we have to account for the possibility that the snap vnode
might get reclaim after we drop sd_lock and before we can get
the node lock.  So, check for that case and retry.

MFC after:  5 weeks

299944 by andrew:
Add intrng support to the GICv3 driver. It lacks ITS support so won't handle
MSI or MSI-X interrupts, however this is enought to boot FreeBSD under the
ARM Foundation Model with a GICv3 interrupt controller.

Approved by:ABT Systems Ltd
Relnotes:   yes
Sponsored by:   The FreeBSD Foundation

299943 by ji

Re: EARLY_AP_STARTUP hangs during boot

2016-05-16 Thread John Baldwin 
On Monday, May 16, 2016 12:22:42 PM Gary Jennejohn wrote:
> I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't
> break into DDB.
> 
> I did a verbose boot and the last lines I see are related to routing
> MSI-X to various local APIC vectors.  I copied the last few lines and
> they look like this:
> 
> msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
> msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
> msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
> msi: routing MSI-X IRQ 256 to local APIC 0 vector 49
> 
> I tried disabling msi and msix in /boot/loader.conf, but the settings
> were ignored (probabaly too early).

No, those settings are not too early.  However, the routing to different
CPUs now happens earlier than it used to.  What is the line before the
MSI lines?  You can take a picture with your phone/camera if that's simplest.

> I'm running on a AMD Phenom(tm) II X6 1090T Processor.
> 
> So, maybe this option only really works correctly on Intel CPUs?

No, there is absolutely zero/zilch/nada about this that is specific to
Intel CPUs.  Very, very little in FreeBSD is specific to AMD vs Intel
CPUs.  It is, OTOH, quite likely that this is specific to device driver
for a piece of hardware.

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

Jenkins build is back to normal : FreeBSD_HEAD #276

2016-05-16 Thread jenkins-admin 
See 

___
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_i386 - Build #3134 - Fixed

2016-05-16 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3134 - Fixed:

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

Change summaries:

299942 by jilles:
install: Revert utimensat usage (r299850).

This should fix the build on older stable/10, since install is a bootstrap
tool.

Pending a decision how to fix this properly, revert utimensat usage. Copies
with the -p option will again appear older than the original almost always,
but -p is not commonly used.

299941 by andrew:
Call ofw_bus_msimap to find the parent MSI controller, it may not use the
msi-parent property.

Obtained from:  ABT Systems Ltd
Sponsored by:   The FreeBSD Foundation

299940 by avg:
fix a vnode reference leak caused by illumos compat traverse()

This commit partially reverts r273641 which introduced the leak.
It did so to accomodate for some consumers of traverse() that expected
the starting vnode to stay as-is.  But that introduced the leak in the
case when a mounted filesystem was found and its root vnode was
returned.

r299914 removed the troublesome consumers and now there is no reason to
keep the starting vnode.  So, now the new rules are:
- if there is no mounted filesystem, then nothing is changed
- otherwise the starting vnode is always released
- the root vnode of the mounted filesystem is returned locked and
  referenced in the case of success

MFC after:  5 weeks
X-MFC after:r299914

299939 by andrew:
Move the call to intr_pic_init_secondary to the same place as in the
non-intrng case.

Obtained from:  ABT Systems Ltd
Sponsored by:   The FreeBSD Foundation

299938 by avg:
fix up r299902: mount_snapshot requires that the covered vnode is locked

Previously that was not strictly enforced.

MFC after:  4 weeks
X-MFC with: r299902

___
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: EARLY_AP_STARTUP hangs during boot

2016-05-16 Thread Gary Jennejohn 
On Mon, 16 May 2016 13:38:35 +0300
Konstantin Belousov  wrote:

> On Mon, May 16, 2016 at 12:27:31PM +0200, Gary Jennejohn wrote:
> > On Mon, 16 May 2016 12:22:42 +0200
> > Gary Jennejohn  wrote:
> >   
> > > I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't
> > > break into DDB.
> > > 
> > > I did a verbose boot and the last lines I see are related to routing
> > > MSI-X to various local APIC vectors.  I copied the last few lines and
> > > they look like this:
> > > 
> > > msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
> > > msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
> > > msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
> > > msi: routing MSI-X IRQ 256 to local APIC 0 vector 49  
> > 
> > Oops, the the last line should read
> > msi: Assigning MSI-X IRQ 256 to local APIC 0 vector 49  
> You should be able to enter ddb at this point. Methods depend on the
> console used, serial break for serial console, ctrl-alt-esc for sc/vt
> AFAIR. If you have IPMI/DRAC/ILO, send nmi.
> 
> After getting at ddb> prompt, do 'bt' then 'ps' then 'alltrace' and
> show the output.

I tried ctrl-alt-esc, nothing happens.  Maybe because USB isn't
up yet.

Judging from the way the case fan starts ramping up it seems like
the CPU is in a tight loop.

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

Build failed in Jenkins: FreeBSD_HEAD #275

2016-05-16 Thread jenkins-admin 
See 

--
[...truncated 2591 lines...]
sh /builds/workspace/FreeBSD_HEAD/src/tools/install.sh  -o root  -g wheel -m 
555  /builds/workspace/FreeBSD_HEAD/src/usr.bin/lorder/lorder.sh  
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/bin/lorder
--- _bootstrap-tools-lib/clang/libllvmsupport ---
--- Locale.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.Locale.o -MTLocale.o -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/builds/workspace/FreeBSD_HEAD/src/lib/clang/
 libllvmsupport/../../../contrib/llvm/lib/Support/Locale.cpp -o Locale.o
--- _bootstrap-tools-lib/libopenbsd ---
===> lib/libopenbsd (obj,all,install)
--- obj ---
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd
 created for /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd
--- getdtablecount.o ---
cc  -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd  -MD  
-MF.depend.getdtablecount.o -MTgetdtablecount.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd/getdtablecount.c -o 
getdtablecount.o
--- imsg-buffer.o ---
cc  -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd  -MD  
-MF.depend.imsg-buffer.o -MTimsg-buffer.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd/imsg-buffer.c -o 
imsg-buffer.o
--- _bootstrap-tools-lib/libsqlite3 ---
===> lib/libsqlite3 (obj,all,install)
--- obj ---
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/builds/workspace/FreeBSD_HEAD/src/lib/libsqlite3
 created for /builds/workspace/FreeBSD_HEAD/src/lib/libsqlite3
--- _bootstrap-tools-lib/libopenbsd ---
--- imsg.o ---
cc  -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd  -MD  
-MF.depend.imsg.o -MTimsg.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd/imsg.c -o imsg.o
--- _bootstrap-tools-lib/libsqlite3 ---
--- sqlite3.o ---
cc  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/libsqlite3/../../contrib/sqlite3  
-DUSE_PREAD=1  -DSTDC_HEADERS=1  -DHAVE_SYS_TYPES_H=1  -DHAVE_SYS_STAT_H=1  
-DHAVE_STDLIB_H=1  -DHAVE_STRING_H=1  -DHAVE_MEMORY_H=1  -DHAVE_STRINGS_H=1  
-DHAVE_INTTYPES_H=1  -DHAVE_STDINT_H=1  -DHAVE_UNISTD_H=1  -DHAVE_DLFCN_H=1  
-DHAVE_USLEEP=1  -DHAVE_LOCALTIME_R=1  -DHAVE_GMTIME_R=1  
-DHAVE_DECL_STRERROR_R=1  -DHAVE_STRERROR_R=1  -DHAVE_POSIX_FALLOCATE=1  
-D_REENTRANT=1  -DSQLITE_THREADSAFE=1  -DSQLITE_ENABLE_FTS3  
-DSQLITE_ENABLE_FTS4  -DSQLITE_ENABLE_RTREE  -MD  -MF.depend.sqlite3.o 
-MTsqlite3.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c 
/builds/workspace/FreeBSD_HEAD/src/lib/libsqlite3/../../contrib/sqlite3/sqlite3.c
 -o sqlite3.o
--- _bootstrap-tools-lib/libopenbsd ---
--- ohash.o ---
cc  -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd  -MD  
-MF.depend.ohash.o -MTohash.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd/ohash.c -o ohash.o
--- libopenbsd.a ---
building static openbsd library
ar -crD libopenbsd.a `NM='nm' NMFLAGS='' lorder getdtablecount.o imsg-buffer.o 
imsg.o ohash.o  | tsort -q` 
ranlib -D libopenbsd.a
--- _bootstrap-tools-usr.bin/rpcgen ---
===> usr.bin/rpcgen (obj,all,install)
--- obj ---
--- _bootstrap-tools-lib/liby ---
--- _bootstrap-tools-usr.bin/rpcgen ---
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/builds/workspace/FreeBSD_HEAD/src/usr.bin/rpcgen
 created for /builds/workspace/FreeBSD_HEAD/src/usr.bin/rpcgen
--- _bootstrap-tools-lib/liby ---
===> lib/liby (obj,all,install)
--- obj

FreeBSD_HEAD_amd64_gcc - Build #1246 - Failure

2016-05-16 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1246 - Failure:

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

Change summaries:

299937 by avos:
rtwn: fix double free in raw xmit path.

Reported by:mva

299936 by andrew:
Add support for intrng to arm64. As the GICv3 drivers will need to be
updated, and until further testing can be done, this is disabled for now.

It is expected arm64 will switch to this interface, and the old interface
will be removed before 11.0 is released.

Obtained from:  ABT Systems Ltd
Relnotes:   yes
Sponsored by:   The FreeBSD Foundation

299934 by andrew:
Teach the ThunderX PCI PEM driver about intrng. This will be used later
when arm64 is supported by intrng.

Obtained from:  ABT Systems Ltd
Sponsored by:   The FreeBSD Foundation

299933 by hselasky:
Implement more Linux device related functions in the LinuxKPI. While
at it use NULL for some pointer checks.

Bump the FreeBSD version to force recompilation of all kernel modules
due to a structure size change.

Obtained from:  kmacy @
MFC after:  1 week
Sponsored by:   Mellanox Technologies

299932 by andrew:
Add a pcib interface for use by interrupt controllers that need to
translate the pci rid to a controller ID. The translation could be based
on the 'msi-map' OFW property, a similar ACPI option, or hard-coded for
hardware lacking the above options.

Reviewed by:wma
Obtained from:  ABT Systems Ltd
Sponsored by:   The FreeBSD Foundation

299931 by hselasky:
Don't dereference parent pointer when it is NULL.

MFC after:  1 week
Sponsored by:   Mellanox Technologies

299930 by hselasky:
Properly implement "cpu_has_clflush" macro.

Suggested by:   kib, jhb
MFC after:  1 week
Sponsored by:   Mellanox Technologies

299929 by andrew:
Re-commit r299467 having fixed the build:

Add a new get_id interface to pci and pcib. This will allow us to both
detect failures, and get different PCI IDs.

For the former the interface returns an int to signal an error. The ID is
returned at a uintptr_t * argument.

For the latter there is a type argument that allows selecting the ID type.
This only specifies a single type, however a MSI type will be added
to handle the need to find the ID the hardware passes to the ARM GICv3
interrupt controller.

A follow up commit will be made to remove pci_get_rid.

Reviewed by:jhb, rstone (previous version)
Obtained from:  ABT Systems Ltd
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D6239

299928 by andrew:
Introduce MSI and MSI-X support to intrng. This adds a new msi device
interface with 5 methods to mirror the 5 MSI/MSI-X methods in the pcib
interface. The pcib driver will need to perform a device specific lookup
to find the MSI controller and pass this to intrng as the xref. Intrng
will finally find the controller and have it handle the requested operation.

Obtained from:  ABT Systems Ltd
MFH:yes
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D5985

299927 by sephe:
hyperv/vmbus: Use atomic_testandclear

Prepare to use unsigned long for event channel bit array.

Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6382

299926 by truckman:
Hoist the getpwnam() call outside the first if/else block in
pam_sm_chauthtok().  Set user = getlogin() inside the true
branch so that it is initialized for the following PAM_LOG()
call.  This is how it is done in pam_sm_authenticate().

Reported by:Coverity
CID:272498
MFC after:  1 week

299925 by arybchik:
sfxge(4): cleanup: quieten more common code MCDI handlers

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299924 by arybchik:
sfxge(4): cleanup: remove misnamed function declaration

Submitted by:   Richard Houldsworth 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299923 by arybchik:
sfxge(4): cleanup: make MCDI license queries quieter in common code

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299922 by truckman:
Don't call free_addrselectpolicy(&policyhead) before policyhead has been
initialized.

Reported by:Coverity
CID:1018727

299921 by truckman:
Add an assertion to catch a potential underflow in an array index
calculation, though this should not happen in the current code.

Reported by:Coverity
CID:1008486
MFC after:  3 weeks

299920 by arybchik:
sfxge(4): cleanup: simplify ef10_ev_qcreate

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299919 by arybchik:
sfxge(4): translate MC_CMD_ERR_EEXIST to host errno value

This is needed because the new MCDI command nvram_private_a

Re: rtwn(0) panics with RTL8188CE

2016-05-16 Thread Andriy Voskoboinyk 
Mon, 16 May 2016 12:35:35 +0300 було написано Marcus von Appen  
:



m_freem() at m_freem+0x38/frame 0xfe04535f5810


There is double free in xmit path; I will fix it soon.
___
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_i386 - Build #3133 - Still Failing

2016-05-16 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3133 - Still Failing:

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

Change summaries:

299937 by avos:
rtwn: fix double free in raw xmit path.

Reported by:mva

299936 by andrew:
Add support for intrng to arm64. As the GICv3 drivers will need to be
updated, and until further testing can be done, this is disabled for now.

It is expected arm64 will switch to this interface, and the old interface
will be removed before 11.0 is released.

Obtained from:  ABT Systems Ltd
Relnotes:   yes
Sponsored by:   The FreeBSD Foundation

299934 by andrew:
Teach the ThunderX PCI PEM driver about intrng. This will be used later
when arm64 is supported by intrng.

Obtained from:  ABT Systems Ltd
Sponsored by:   The FreeBSD Foundation

299933 by hselasky:
Implement more Linux device related functions in the LinuxKPI. While
at it use NULL for some pointer checks.

Bump the FreeBSD version to force recompilation of all kernel modules
due to a structure size change.

Obtained from:  kmacy @
MFC after:  1 week
Sponsored by:   Mellanox Technologies

299932 by andrew:
Add a pcib interface for use by interrupt controllers that need to
translate the pci rid to a controller ID. The translation could be based
on the 'msi-map' OFW property, a similar ACPI option, or hard-coded for
hardware lacking the above options.

Reviewed by:wma
Obtained from:  ABT Systems Ltd
Sponsored by:   The FreeBSD Foundation

299931 by hselasky:
Don't dereference parent pointer when it is NULL.

MFC after:  1 week
Sponsored by:   Mellanox Technologies

299930 by hselasky:
Properly implement "cpu_has_clflush" macro.

Suggested by:   kib, jhb
MFC after:  1 week
Sponsored by:   Mellanox Technologies

299929 by andrew:
Re-commit r299467 having fixed the build:

Add a new get_id interface to pci and pcib. This will allow us to both
detect failures, and get different PCI IDs.

For the former the interface returns an int to signal an error. The ID is
returned at a uintptr_t * argument.

For the latter there is a type argument that allows selecting the ID type.
This only specifies a single type, however a MSI type will be added
to handle the need to find the ID the hardware passes to the ARM GICv3
interrupt controller.

A follow up commit will be made to remove pci_get_rid.

Reviewed by:jhb, rstone (previous version)
Obtained from:  ABT Systems Ltd
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D6239



The end of the build log:

[...truncated 2765 lines...]
===> gnu/usr.bin/groff/font (install)
--- realinstall ---
===> gnu/usr.bin/groff/font/devX100 (install)
--- _FILESINS ---
sh /usr/src/tools/install.sh  -o root -g wheel  -m 444 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/DESC
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/TR
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/TI
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/TB
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/TBI
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/CR
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/CI
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/CB
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/CBI
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/HR
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/HI
 /usr
 
/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/HB
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/HBI
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/NR
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/NI
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/NB
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/NBI
 
/usr/src/gnu/usr.bin/groff/font/devX100/../../../../../contrib/groff/font/devX100/S
 /usr/obj/usr/src/tmp/legacy/usr/share/groff_font/devX100/
===> gnu/usr.bin/groff/font/devX100-12 (install)
--- _FILESINS ---
sh /usr/src/tools/install.sh  -o root -g wheel  -m 444 
/usr/src/gnu/usr.bin/groff/font/devX100-12/../../../../../contrib/groff/font/devX100-12/DESC
 
/usr/src/gnu/usr.bin/groff/font/devX100-12/../../../../../contrib/groff/font/devX100-12/TR
 
/usr/src/gnu/usr.bin/groff/font/devX100-12/../../../../../contrib/groff/font/devX100-12/TI
 
/usr/src/gnu/usr.bin/groff/font/devX100-12/../../../../..

Re: EARLY_AP_STARTUP hangs during boot

2016-05-16 Thread Konstantin Belousov 
On Mon, May 16, 2016 at 12:27:31PM +0200, Gary Jennejohn wrote:
> On Mon, 16 May 2016 12:22:42 +0200
> Gary Jennejohn  wrote:
> 
> > I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't
> > break into DDB.
> > 
> > I did a verbose boot and the last lines I see are related to routing
> > MSI-X to various local APIC vectors.  I copied the last few lines and
> > they look like this:
> > 
> > msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
> > msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
> > msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
> > msi: routing MSI-X IRQ 256 to local APIC 0 vector 49
> 
> Oops, the the last line should read
> msi: Assigning MSI-X IRQ 256 to local APIC 0 vector 49
You should be able to enter ddb at this point. Methods depend on the
console used, serial break for serial console, ctrl-alt-esc for sc/vt
AFAIR. If you have IPMI/DRAC/ILO, send nmi.

After getting at ddb> prompt, do 'bt' then 'ps' then 'alltrace' and
show the output.
___
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: EARLY_AP_STARTUP hangs during boot

2016-05-16 Thread Gary Jennejohn 
On Mon, 16 May 2016 12:22:42 +0200
Gary Jennejohn  wrote:

> I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't
> break into DDB.
> 
> I did a verbose boot and the last lines I see are related to routing
> MSI-X to various local APIC vectors.  I copied the last few lines and
> they look like this:
> 
> msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
> msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
> msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
> msi: routing MSI-X IRQ 256 to local APIC 0 vector 49

Oops, the the last line should read
msi: Assigning MSI-X IRQ 256 to local APIC 0 vector 49

> I tried disabling msi and msix in /boot/loader.conf, but the settings
> were ignored (probabaly too early).
> 
> I'm running on a AMD Phenom(tm) II X6 1090T Processor.
> 
> So, maybe this option only really works correctly on Intel CPUs?
> 

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

EARLY_AP_STARTUP hangs during boot

2016-05-16 Thread Gary Jennejohn 
I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't
break into DDB.

I did a verbose boot and the last lines I see are related to routing
MSI-X to various local APIC vectors.  I copied the last few lines and
they look like this:

msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
msi: routing MSI-X IRQ 256 to local APIC 0 vector 49

I tried disabling msi and msix in /boot/loader.conf, but the settings
were ignored (probabaly too early).

I'm running on a AMD Phenom(tm) II X6 1090T Processor.

So, maybe this option only really works correctly on Intel CPUs?

-- 
Gary Jennejohn
___
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: rtwn(0) panics with RTL8188CE

2016-05-16 Thread Marcus von Appen 
On, Mon May 16, 2016, Marcus von Appen wrote:

[...]

this one seems to provide some more information. I have no idea,
if both crash types are related or not.

Unread portion of the kernel message buffer:
rtwn0: can't map mbuf (error 12)
panic: Duplicate free of 0xf800c94c1300 from zone 
0xf800056c4900(mbuf_packet) slab 0xf800c94c1f90(3)

cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe04535f5660
vpanic() at vpanic+0x186/frame 0xfe04535f56e0
panic() at panic+0x43/frame 0xfe04535f5740
uma_dbg_free() at uma_dbg_free+0xee/frame 0xfe04535f5770
uma_zfree_arg() at uma_zfree_arg+0x64/frame 0xfe04535f57c0
mb_free_ext() at mb_free_ext+0x155/frame 0xfe04535f57f0
m_freem() at m_freem+0x38/frame 0xfe04535f5810
rtwn_raw_xmit() at rtwn_raw_xmit+0x7b/frame 0xfe04535f5840
ieee80211_send_probereq() at ieee80211_send_probereq+0x514/frame 
0xfe04535f58e0
ieee80211_swscan_probe_curchan() at ieee80211_swscan_probe_curchan+0x5a/frame 
0xfe04535f5920
scan_curchan() at scan_curchan+0x68/frame 0xfe04535f5960
scan_curchan_task() at scan_curchan_task+0x247/frame 0xfe04535f59e0
taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfe04535f5a40
taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfe04535f5a70
fork_exit() at fork_exit+0x84/frame 0xfe04535f5ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe04535f5ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---


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

Build failed in Jenkins: FreeBSD_HEAD #274

2016-05-16 Thread jenkins-admin 
See 

--
[...truncated 2691 lines...]
--- RandomNumberGenerator.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.RandomNumberGenerator.o -MTRandomNumberGenerator.o 
-Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/builds/workspa
 
ce/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/RandomNumberGenerator.cpp
 -o RandomNumberGenerator.o
--- Regex.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.Regex.o -MTRegex.o -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/builds/workspace/FreeBSD_HEAD/src/lib/clang/li
 bllvmsupport/../../../contrib/llvm/lib/Support/Regex.cpp -o Regex.o
--- ScaledNumber.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.ScaledNumber.o -MTScaledNumber.o -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/builds/workspace/FreeBSD_HEAD/sr
 c/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ScaledNumber.cpp 
-o ScaledNumber.o
--- SearchForAddressOfSpecialSymbol.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.SearchForAddressOfSpecialSymbol.o 
-MTSearchForAddressOfSpecialSymbol.o -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions
   -c 
/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SearchForAddressOfSpecialSymbol.cpp
 -o SearchForAddressOfSpecialSymbol.o
--- Signals.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/c

FreeBSD_HEAD_i386 - Build #3132 - Still Failing

2016-05-16 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3132 - Still Failing:

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

Change summaries:

299928 by andrew:
Introduce MSI and MSI-X support to intrng. This adds a new msi device
interface with 5 methods to mirror the 5 MSI/MSI-X methods in the pcib
interface. The pcib driver will need to perform a device specific lookup
to find the MSI controller and pass this to intrng as the xref. Intrng
will finally find the controller and have it handle the requested operation.

Obtained from:  ABT Systems Ltd
MFH:yes
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D5985

299927 by sephe:
hyperv/vmbus: Use atomic_testandclear

Prepare to use unsigned long for event channel bit array.

Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6382

299926 by truckman:
Hoist the getpwnam() call outside the first if/else block in
pam_sm_chauthtok().  Set user = getlogin() inside the true
branch so that it is initialized for the following PAM_LOG()
call.  This is how it is done in pam_sm_authenticate().

Reported by:Coverity
CID:272498
MFC after:  1 week

299925 by arybchik:
sfxge(4): cleanup: quieten more common code MCDI handlers

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299924 by arybchik:
sfxge(4): cleanup: remove misnamed function declaration

Submitted by:   Richard Houldsworth 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299923 by arybchik:
sfxge(4): cleanup: make MCDI license queries quieter in common code

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299922 by truckman:
Don't call free_addrselectpolicy(&policyhead) before policyhead has been
initialized.

Reported by:Coverity
CID:1018727

299921 by truckman:
Add an assertion to catch a potential underflow in an array index
calculation, though this should not happen in the current code.

Reported by:Coverity
CID:1008486
MFC after:  3 weeks

299920 by arybchik:
sfxge(4): cleanup: simplify ef10_ev_qcreate

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299919 by arybchik:
sfxge(4): translate MC_CMD_ERR_EEXIST to host errno value

This is needed because the new MCDI command nvram_private_append can
return MC_CMD_ERR_EEXIST

Submitted by:   Tom Millington 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299918 by arybchik:
fxge(4): cleanup: run genfwdef to propogate prior changes to TLV headers

Submitted by:   Andrew Lee 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299917 by arybchik:
sfxge(4): set TSOv2 feature flag on Medford

Submitted by:   Mark Spender 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299916 by avg:
vfs_read_dirent: increment ncookies after adding a cookie

It seems that at present vfs_read_dirent() is used only with filesystems
that do not support cookies, so the bug never manifested itself.

MFC after:  1 week

299915 by arybchik:
sfxge(4): improve TX/RX queue error messages

Report the full error descriptor in a form that can be passed to
firmwaresrc/dpcpu/scripts/evdecode

Submitted by:   Mark Spender 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299914 by avg:
zfsctl_ops_snapshot: remove methods should never be called

We pretend that snapshots mounted under .zfs are part of the original
filesystem and we try very hard to hide vnodes on top of which the snapshots
are mounted.  Given that I believe that the removed operations should
never be called.  They might have been called previously because
of issues fixed in r299906, r299908 and r299913.

MFC after:  5 weeks

299913 by avg:
dounmount: do not call mountcheckdirs() for mounts with MNT_IGNORE

This is a bit hackish, but the flag is currently set only for ZFS
snapshots mounted under .zfs.  mountcheckdirs() can change cdir/rdir
references to a covered vnode.  But for the said snapshots the covered
vnode is really ephemeral and it must never be accessed (except
for a few specific cases).

To do:  consider removing mountcheckdirs() entirely

MFC after:  5 days

299912 by sephe:
atomic: Add testandclear on i386/amd64

Reviewed by:kib
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6381



The end of the build log:

[...truncated 2756 lines...]
--- _bootstrap-tools-lib/libopenbsd ---
--- imsg.o ---
cc  -O2 -pipe -I/usr/src/lib/libopenbsd  -MD -MP -MF.depend.imsg.o -MTimsg.o 
-std=gnu99  -Qunused-arguments  -I/usr/obj/usr/src/tmp/legacy/usr/include -c 
/usr/src/lib/libopenbsd/imsg.c -o imsg.o
--- _boots

Re: Lock order reversal errors during boot

2016-05-16 Thread Bjoern A. Zeeb 

> On 15 May 2016, at 07:44 , Kurt Jaeger  wrote:
> 
> Hi!
> 
>> I am seeing 'lock order reversal' errors during boot on 11-CURRENT - 
>> r298793.  A sample error:
>> 
>> lock order reversal:
>>  1st 0xf8011280d068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
>>  2nd 0xfe01ca539400 bufwait (bufwait) @ 
>> /usr/src/sys/ufs/ffs/ffs_vnops.c:263
>>  3rd 0xf80112a23b78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
>> stack backtrace:
>> #0 0x80a94bf0 at witness_debugger+0x70
>> #1 0x80a94ae4 at witness_checkorder+0xe54
>> #2 0x80a0fdd6 at __lockmgr_args+0x4d6
>> #3 0x80ce9626 at ffs_lock+0xa6
>> [...snip...]
>> 
>> I'm not sure if this is even something I should report, but better safe 
>> than sorry, yes?
> 
> Yes, and there's even a page to compare your LOR against other ones:
> 
> http://sources.zabbadoz.net/freebsd/lor.html
> 
> Can you try if you find your LOR there ? If not, can you add it
> to that page ?

No he can’t and I haven’t in years either.   Searching bugs might however be a 
good idea;  there is a LOR category or tag somewhere.

/bz


___
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_i386 - Build #3131 - Still Failing

2016-05-16 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3131 - Still Failing:

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

Change summaries:

299911 by arybchik:
sfxge(4): fix license validation check for V3 licenses

Length consistency checks were failing for ECC hashes.

Submitted by:   Richard Houldsworth 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299910 by sgalabov:
Introduce basic etherswitch support for Ralink SoCs

This revision introduces basic support for the internal ESW switch found
Ralink/Mediatek SoCs such as RT3050, RT3352, RT5350, MT7628; and GSW
found in MT7620 and MT7621.

It only supports 802.1q VLANs and doesn't support external PHYs at the
moment (only the ones that are built into the switch itself).

Approved by:adrian (mentor)
Sponsored by:   Smartcom - Bulgaria AD
Differential Revision:  https://reviews.freebsd.org/D6348

299909 by arybchik:
sfxge(4): regenerate MCDI headers from firmwaresrc .yml

Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299908 by avg:
zfsctl_snapdir_lookup: always clear VV_ROOT flag of snapshot's root VV_ROOT

Previosuly we did that only if the snapshot was mounted earlier, its
root vnode got recycled and then we accessed it again.
We never cleared the flag for a freshly mounted snapshot.

That was very inconsistent and probably a source of some bugs.
Or maybe that painted over some bugs which might get revealed now.

We should consistently clear the flag because we try very hard to
pretend that snapshots auto-mounted under .zfs are part of their
original filesystem.  In other words, we try to hide the fact that they
are different filesystems / mountpoints.

MFC after:  5 weeks

299907 by arybchik:
sfxge(4): increase maximum size of license keys

Increase buffer sizes for license keys to 160 bytes to accomodate ECDSA
hashes.

Submitted by:   Richard Houldsworth 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week

299906 by avg:
add zfs_vptocnp with special handling for snapshots under .zfs

The logic is similar to that already present in zfs_dirlook() to handle
a dot-dot lookup on a root vnode of a snapshot mounted under
.zfs/snapshot/.
illumos does not have an equivalent of vop_vptocnp, so there only the
lookup had to be patched up.

MFC after:  4 weeks

299905 by arybchik:
sfxge(4): fix V1 licensing MCDI operations

Implementation of the MCDI commands for Siena boards was requesting
the wrong operation.

Submitted by:   Richard Houldsworth 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D6370

299904 by arybchik:
sfxge(4): improve PCIe link speed and width check

Perform a more accurate check of whether the PCIe bandwidth is
sufficient for the current/supported port modes.

Give a different warning if there is sufficient bandwidth to achieve
line rate, but the link is not fast enough for optimal latency.

Submitted by:   Mark Spender 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D6369

299903 by arybchik:
sfxge(4): cleanup: make TLV scans quieter

Find end of segments in a more direct way that avoids an error report at
the terminator.

Submitted by:   Richard Houldsworth 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D6367

299902 by avg:
mount_snapshot: consolidate all error handling

This makes sure that the original vnode is always unlocked and released
if any error happens.

MFC after:  4 weeks

299901 by arybchik:
sfxge(4): cleanup: make VPD lookups quieter

A lookup on a VPD entry which is missing reports several failure
messages as it propagates through wrapper functions. Restructured
the wrappers to treat this gracefully as an expected case.

Submitted by:   Richard Houldsworth 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D6366

299900 by avg:
zfsctl: fix several problems with reference counts

* Remove excessive references on a snapshot mountpoint vnode.
  zfsctl_snapdir_lookup() called VN_HOLD() on a vnode returned from
  zfsctl_snapshot_mknode() and the latter also had a call to VN_HOLD()
  on the same vnode.
  On top of that gfs_dir_create() already returns the vnode with the
  use count of 1 (set in getnewvnode).
  So there was 3 references on the vnode.

* mount_snapshot() should keep a reference to a covered vnode.
  That reference is owned by the mountpoint (mounted snapshot filesystem).

* Remove cryptic manipulations of a covered vnode in zfs_umount().
  FreeBSD dounmount() already does the right thing and releases the covered
  vnode.

PR: 207464
Reported by:dustinw...@eb

Build failed in Jenkins: FreeBSD_HEAD #273

2016-05-16 Thread jenkins-admin 
See 

--
[...truncated 2516 lines...]
sh /builds/workspace/FreeBSD_HEAD/src/tools/install.sh  -o root -g wheel -m 444 
 dd.debug 
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/lib/debug/bin/dd.debug
--- _bootstrap-tools-usr.bin/lorder ---
===> usr.bin/lorder (obj,all,install)
--- obj ---
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/builds/workspace/FreeBSD_HEAD/src/usr.bin/lorder
 created for /builds/workspace/FreeBSD_HEAD/src/usr.bin/lorder
--- _bootstrap-tools-usr.bin/compile_et ---
--- compile_et.debug ---
objcopy --only-keep-debug compile_et.full compile_et.debug
--- compile_et ---
objcopy --strip-debug --add-gnu-debuglink=compile_et.debug  compile_et.full 
compile_et
--- _bootstrap-tools-usr.bin/lorder ---
--- _SCRIPTSINS_lorder.sh ---
sh /builds/workspace/FreeBSD_HEAD/src/tools/install.sh  -o root  -g wheel -m 
555  /builds/workspace/FreeBSD_HEAD/src/usr.bin/lorder/lorder.sh  
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/bin/lorder
--- _bootstrap-tools-lib/libopenbsd ---
===> lib/libopenbsd (obj,all,install)
--- _bootstrap-tools-usr.bin/compile_et ---
--- _proginstall ---
sh /builds/workspace/FreeBSD_HEAD/src/tools/install.sh  -s -o root -g wheel -m 
555   compile_et 
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/bin/compile_et
sh /builds/workspace/FreeBSD_HEAD/src/tools/install.sh  -o root -g wheel -m 444 
 compile_et.debug 
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/lib/debug/usr/bin/compile_et.debug
--- _bootstrap-tools-lib/libopenbsd ---
--- obj ---
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd
 created for /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd
--- _bootstrap-tools-lib/libsqlite3 ---
===> lib/libsqlite3 (obj,all,install)
--- _bootstrap-tools-lib/libopenbsd ---
--- getdtablecount.o ---
cc  -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd  -MD  
-MF.depend.getdtablecount.o -MTgetdtablecount.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd/getdtablecount.c -o 
getdtablecount.o
--- _bootstrap-tools-lib/libsqlite3 ---
--- obj ---
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/builds/workspace/FreeBSD_HEAD/src/lib/libsqlite3
 created for /builds/workspace/FreeBSD_HEAD/src/lib/libsqlite3
--- sqlite3.o ---
cc  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/libsqlite3/../../contrib/sqlite3  
-DUSE_PREAD=1  -DSTDC_HEADERS=1  -DHAVE_SYS_TYPES_H=1  -DHAVE_SYS_STAT_H=1  
-DHAVE_STDLIB_H=1  -DHAVE_STRING_H=1  -DHAVE_MEMORY_H=1  -DHAVE_STRINGS_H=1  
-DHAVE_INTTYPES_H=1  -DHAVE_STDINT_H=1  -DHAVE_UNISTD_H=1  -DHAVE_DLFCN_H=1  
-DHAVE_USLEEP=1  -DHAVE_LOCALTIME_R=1  -DHAVE_GMTIME_R=1  
-DHAVE_DECL_STRERROR_R=1  -DHAVE_STRERROR_R=1  -DHAVE_POSIX_FALLOCATE=1  
-D_REENTRANT=1  -DSQLITE_THREADSAFE=1  -DSQLITE_ENABLE_FTS3  
-DSQLITE_ENABLE_FTS4  -DSQLITE_ENABLE_RTREE  -MD  -MF.depend.sqlite3.o 
-MTsqlite3.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c 
/builds/workspace/FreeBSD_HEAD/src/lib/libsqlite3/../../contrib/sqlite3/sqlite3.c
 -o sqlite3.o
--- _bootstrap-tools-lib/libopenbsd ---
--- imsg-buffer.o ---
cc  -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd  -MD  
-MF.depend.imsg-buffer.o -MTimsg-buffer.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd/imsg-buffer.c -o 
imsg-buffer.o
--- _bootstrap-tools-usr.sbin/kbdcontrol ---
--- kbdcontrol.full ---
cc -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/usr.sbin/kbdcontrol -g 
-std=gnu99 -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -static 
-L/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/lib
 -o kbdcontrol.full kbdcontrol.o lex.o   -ll -legacy
--- _bootstrap-tools-lib/libopenbsd ---
--- imsg.o ---
cc  -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd  -MD  
-MF.depend.imsg.o -MTimsg.o -std=gnu99  -Qunused-arguments  
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
 -c /builds/workspace/FreeBSD_HEAD/src/lib/libopenbsd/imsg.c -o imsg.o
--- _bootstrap-tools-usr.sbin/kbdcontrol ---
--- kbdcontrol.debug ---
objcopy --only-keep-debug kbdcontrol.full kbdcontrol.debug
--- kbdcontrol ---
objcopy --strip-debug --add-gnu-debuglink=kbdcontrol.debug  kbdcontrol.full 
kbdcontrol
--- _proginstall ---
sh /builds/workspace/FreeBSD_HEAD/src/tools/install.sh  -s -o