Re: unp gc vs socket close/shutdown race

2015-07-08 Thread Andriy Gapon
Mateusz, this seems to be the same problem as reported here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194264 so you might want to use that PR for bookkeeping. Thank you for the patch! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing lis

Re: MS DNS doesn't answer to CURRENT under Hyper-V

2015-07-08 Thread Slawa Olhovchenkov
On Wed, Jul 08, 2015 at 11:05:39AM +0300, Pavel Timofeev wrote: > Ok, r284746 is the root of the problem. MS DNS works under r284745 and > doesn't work under r284746. > Slawa, what should I look at in wireshark output? I think developers can want look at same packet before entering in NIC and aft

FreeBSD_HEAD-tests - Build #1166 - Still Failing

2015-07-08 Thread jenkins-admin
FreeBSD_HEAD-tests - Build #1166 - Still Failing: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1166/ to view the results. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-curren

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread O'Connor, Daniel
> On 8 Jul 2015, at 08:11, Garrett Wollman > wrote: > Perhaps the test was (erroneously) written to assume that > gettimeofday() was a system call, and could therefore detect invalid > pointers and return [EFAULT]. This has not been the case for some > time. (In HEAD, not since r237434, which

Re: How should a driver shutdown a taskqueue on detach?

2015-07-08 Thread Konstantin Belousov
On Tue, Jul 07, 2015 at 07:52:56PM -0400, Ryan Stone wrote: > On Thu, Jul 2, 2015 at 3:08 AM, Konstantin Belousov > wrote: > > > Having taskqueue_enqueue() which could silently (?) not enqueue the given > > task is huge and IMO risky change to the KPI. If doing it, I think > > that there should

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Oliver Pinter
On 7/8/15, O'Connor, Daniel wrote: > >> On 8 Jul 2015, at 08:11, Garrett Wollman >> wrote: >> Perhaps the test was (erroneously) written to assume that >> gettimeofday() was a system call, and could therefore detect invalid >> pointers and return [EFAULT]. This has not been the case for some >>

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Garrett Cooper
On Jul 8, 2015, at 2:53, Oliver Pinter wrote: > On 7/8/15, O'Connor, Daniel wrote: >> >>> On 8 Jul 2015, at 08:11, Garrett Wollman >>> wrote: >>> Perhaps the test was (erroneously) written to assume that >>> gettimeofday() was a system call, and could therefore detect invalid >>> pointers and

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Konstantin Belousov
On Wed, Jul 08, 2015 at 11:53:39AM +0200, Oliver Pinter wrote: > On 7/8/15, O'Connor, Daniel wrote: > > > >> On 8 Jul 2015, at 08:11, Garrett Wollman > >> wrote: > >> Perhaps the test was (erroneously) written to assume that > >> gettimeofday() was a system call, and could therefore detect invali

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Oliver Pinter
er.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-100) Changing to HPET solves the problem: root@nyi-01 ~# sysctl kern.timecounter.hardware=HPET kern.timecounter.hardware: TSC-low -> HPET root@nyi-01 ~# cd /usr/tests/lib/libc/sys root@nyi-01 sys# kyua test gettimeofday_test gettimeofday_test:g

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Konstantin Belousov
On Wed, Jul 08, 2015 at 12:36:08PM +0200, Oliver Pinter wrote: > Changing to HPET solves the problem: No, it does not solve the problem, it only hides it. The solution is to remove the test. Or, if so inclined, only run the test when gettimeofday(2) is implemented by a syscall. __

Re: panic: negative refcount after dhclient during boot

2015-07-08 Thread Ermal Luçi
On Tue, Jul 7, 2015 at 6:11 PM, Rink Springer wrote: > Hi eri@, > > On Mon, Jul 06, 2015 at 09:21:54AM +0200, Rink Springer wrote: > > On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote: > > > On Jul 5, 2015, at 8:16, Rink Springer wrote: > > > > > > > Hi all, > > > > > > > > On my F

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Jamie Landeg-Jones
Oliver Pinter wrote: > On 7/8/15, O'Connor, Daniel wrote: > > > > In defence of the test, the man page says it can return EFAULT. > > That's fine, but why changed the behaviour since 2015. May 27.? I have > an older FreeBSD/HardenedBSD install, where this test passing. See > some previous email

gcc/amd64 head build error after r281316

2015-07-08 Thread Luigi Rizzo
Hi, the r281316 commit introduces the following lines which break compilation with gcc on amd64 (as far as i know immintrin.h is only available in our clang). If there are no objections I'd like to add a further check for the use of clang, see attached patch Index: /home/luigi/FreeBSD/head/lib/lib

FreeBSD_HEAD-tests - Build #1167 - Fixed

2015-07-08 Thread jenkins-admin
FreeBSD_HEAD-tests - Build #1167 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1167/ to view the results. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To uns

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Doug Rabson
As far as I can tell, POSIX doesn't require either EFAULT or any other behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf just says, "No errors are defined". Our man page is wrong and any real program which relies on gettimeofday not faulting when given bad inputs is broken.

[PATCH] uart_core: start countdown for non-interrupt mode

2015-07-08 Thread Aleksey Kuleshov
The uart_intr will never be called if interrupts are not available. Start counter with callout_reset call. --- sys/dev/uart/uart_core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sys/dev/uart/uart_core.c b/sys/dev/uart/uart_core.c index bbb06ff..c1b64ba 100644 --- a/sys/dev/uart/uart_c

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Garrett Cooper
On Jul 8, 2015, at 12:17, Doug Rabson wrote: > As far as I can tell, POSIX doesn't require either EFAULT or any other > behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf > just says, "No errors are defined". Our man page is wrong and any real > program which relies on getti

[PATCH] ofw: fix infinite loop

2015-07-08 Thread Aleksey Kuleshov
Fix obvious typo in ofw bus when there is no interrupt-parent for the node. --- sys/dev/ofw/ofw_bus_subr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys/dev/ofw/ofw_bus_subr.c b/sys/dev/ofw/ofw_bus_subr.c index 233675d..c7a50db 100644 --- a/sys/dev/ofw/ofw_bus_subr.c +++

Re: unp gc vs socket close/shutdown race

2015-07-08 Thread Mateusz Guzik
On Wed, Jul 08, 2015 at 10:14:53AM +0300, Andriy Gapon wrote: > Mateusz, > > this seems to be the same problem as reported here > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194264 so you might want to > use that PR for bookkeeping. Taken. Note that the code in question is overall super fi

Re: Kernel Link issue

2015-07-08 Thread O. Hartmann
Am Mon, 06 Jul 2015 16:17:23 -0500 Larry Rosenman schrieb: > On 2015-07-06 16:12, O. Hartmann wrote: > > Am Sun, 05 Jul 2015 09:42:16 -0500 > > Larry Rosenman schrieb: > > > >> On 2015-07-05 04:14, O. Hartmann wrote: > >> > Am Sat, 04 Jul 2015 18:56:31 -0500 > >> > Larry Rosenman schrieb: > >>

Re: gcc/amd64 head build error after r281316

2015-07-08 Thread Dimitry Andric
On 08 Jul 2015, at 19:05, Luigi Rizzo wrote: > > the r281316 commit introduces the following lines > which break compilation with gcc on amd64 (as far as i know > immintrin.h is only available in our clang). > If there are no objections I'd like to add a further check > for the use of clang, see

Re: gcc/amd64 head build error after r281316

2015-07-08 Thread Luigi Rizzo
On Wed, Jul 8, 2015 at 9:36 PM, Dimitry Andric wrote: > On 08 Jul 2015, at 19:05, Luigi Rizzo wrote: > > > > the r281316 commit introduces the following lines > > which break compilation with gcc on amd64 (as far as i know > > immintrin.h is only available in our clang). > > If there are no obje

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Andriy Gapon
On 08/07/2015 22:22, Garrett Cooper wrote: > On Jul 8, 2015, at 12:17, Doug Rabson wrote: > >> As far as I can tell, POSIX doesn't require either EFAULT or any other >> behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf >> just says, "No errors are defined". Our man page i

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Garrett Wollman
In article <559d8e55.9050...@freebsd.org> a...@freebsd.org writes: >I am not suggesting this but if our man pages used all capitals to signify >important auxiliary verbs then the ERRORS sections would read as > The following error codes MAY be set in errno: >Perhaps in that case it would be m

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

2015-07-08 Thread Peter Jeremy
On 2015-Jul-08 12:22:03 -0700, Garrett Cooper wrote: >On Jul 8, 2015, at 12:17, Doug Rabson wrote: > >> As far as I can tell, POSIX doesn't require either EFAULT or any other >> behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf >> just says, "No errors are defined". Our man

Call for FreeBSD 2015Q2 (April-June) Status Reports

2015-07-08 Thread Benjamin Kaduk
Dear FreeBSD Community, Only one week remains before the deadline to submit entries for the next FreeBSD Quarterly Status update -- the deadline is July 14, 2015, for work done in April through June. Status report submissions do not have to be very long. They may be about anything happening in t

Why shoud we cause panic in scsi_da.c?

2015-07-08 Thread Kohji Okuno
Hi, I found panic() in scsi_da.c. Please find the following. I think we should return with error without panic(). What do you think about this? scsi_da.c: 3018} else if (bp != NULL) { 3019if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) 3020