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
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
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
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
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
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
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
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:
> >>
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
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
+++
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
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
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.
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
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
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
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
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.
__
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
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
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
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
>>
> 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
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
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
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
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
27 matches
Mail list logo
