Jenkins build became unstable: FreeBSD_HEAD-tests2 #982
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/982/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: readdir/telldir/seekdir problem (i think)
Julian Elischer wrote:
On 4/25/15 4:28 AM, John Baldwin wrote:
On Saturday, April 25, 2015 02:36:24 AM Julian Elischer wrote:
On 4/25/15 1:30 AM, Julian Elischer wrote:
On 4/24/15 10:59 PM, John Baldwin wrote:
Index: head/lib/libc/gen/telldir.c
===
--- head/lib/libc/gen/telldir.c (revision 281929)
+++ head/lib/libc/gen/telldir.c (working copy)
@@ -101,8 +101,10 @@
return;
if (lp-loc_loc == dirp-dd_loc lp-loc_seek ==
dirp-dd_seek)
return;
- (void) lseek(dirp-dd_fd, (off_t)lp-loc_seek,
SEEK_SET);
- dirp-dd_seek = lp-loc_seek;
+ if (lp-loc_seek != dirp-dd_seek) {
+ (void) lseek(dirp-dd_fd, (off_t)lp-loc_seek,
SEEK_SET);
+ dirp-dd_seek = lp-loc_seek;
+ }
yes I did that yesterday but it still fails when you transition
blocks.. (badly).
I also tried bigger blocks.. also fails (eventually)
I did find a way to make it work... you had to seek back
to the first block you deleted on each set..
then work forward from there again.. unfortunately since
I'm trying to make a microsoft program not fail (via samba)
I have no control over how it does things and seekdir doesn't
know what was deleted anyway... (so the fix is fine for the
test program but not for real life)
I think I can make the BSD one act like the linux one by changing
the lseek being done to use the offset (loc) plus the buffer seek
address of the target, instead of just going for the buffer base
and
stepping forward through the entries..
maybe tomorrow.
The following conditional code makes ours behave the same as the
linux
one.
it breaks several 'rules' but works where ours is clean but
fails..
as Rick said.. maybe that's what we should do too.
this is at the end of seekdir()
The new code does what linux does.. and shouldn't work.. but does
// at least in the limited conditions I need it to.
// We'll probably need to do this at work...:
The original code is what we have now, but gets mightily confused
sometimes.
// This is clean(er) but fails in specific
situations(when
doing commands
// from Microft windows, via samba).
root@vps1:/tmp # diff -u dir.c.orig dir.c
--- dir.c.orig2015-04-24 11:29:36.855317000 -0700
+++ dir.c2015-04-24 11:15:49.05850 -0700
@@ -1105,6 +1105,13 @@
dirp-dd_loc = lp-loc_loc;
return;
}
+#ifdef GLIBC_SEEK
+(void) lseek(dirp-dd_fd, (off_t)lp-loc_seek + lp-loc_loc,
SEEK_SET);
+dirp-dd_seek = lp-loc_seek + lp-loc_loc;
+dirp-dd_loc = 0;
+lp-loc_seek = dirp-dd_seek;
+lp-loc_loc = 0;
+#else
(void) lseek(dirp-dd_fd, (off_t)lp-loc_seek, SEEK_SET);
dirp-dd_seek = lp-loc_seek;
dirp-dd_loc = 0;
@@ -1114,6 +1121,7 @@
if (dp == NULL)
break;
}
+#endif
}
Yes, this isn't at all safe. There's no guarantee whatsoever that
the offset on the directory fd that isn't something returned by
getdirentries has any meaning. In particular, the size of the
directory entry in a random filesystem might be a different size
than the structure returned by getdirentries (since it converts
things into a FS-independent format).
This might work for UFS by accident, but this is probably why ZFS
doesn't work.
However, this might be properly fixed by the thing that ino64 is
doing where each directory entry returned by getdirentries gives
you a seek offset that you _can_ directly seek to (as opposed to
seeking to the start of the block and then walking forward N
entries until you get an inter-block entry that is the same).
I just made the stunning discovery that our seekdir/readdir/telldir
code in libc works with
FreeBSD 8.0.
so maybe the problem is that the kernel changed it's behaviour, and
no-one thought to fix libc..
(at least it works on one of our 8.0 base appliances.. I'll do more
testing tomorrow.. it's past midnight.)
I suspect that pre-r252438 systems work better for UFS than r252438
or later. That patch changed ufs_readdir() so that it no longer returned
the on-disk directory structure. (Among other things, it added code that
skipped over d_ino == 0 entries.)
As such, r252438 and later systems have UFS where the logical offset
of a directory entry returned by getdirentries() isn't the same as the
physical offset for it in the on-disk directory.
Having said the above, I have two somewhat inconsistent thoughts:
1 - As jhb has explained, the libc functions aren't safe for telldir()/seekdir()
when entries are added/deleted. It just happens that UFS might work
ok (and is more likely to work ok when logical offset == physical
offset).
2 - I'm not sure r252438 was a good idea (at least the part that skips
backward dependencies on libzfs
I am not sure what's the best list to discuss this issue, so let me raise it here. It seems that libzfs_core can not be used without also linking / loading libzfs: /lib/libzfs_core.so.2: Undefined symbol zcmd_ioctl_compat The same is true for libnvpair but for a different reason (and it looks like mea culpa): /lib/libnvpair.so.2: Undefined symbol aok Both dependencies seem to be backward, because: $ ldd /lib/libzfs.so.2 /lib/libzfs.so.2: libmd.so.6 = /lib/libmd.so.6 (0x801647000) libthr.so.3 = /lib/libthr.so.3 (0x801857000) libumem.so.2 = /lib/libumem.so.2 (0x801a7c000) libutil.so.9 = /lib/libutil.so.9 (0x801c7d000) libuutil.so.2 = /lib/libuutil.so.2 (0x801e8f000) libm.so.5 = /lib/libm.so.5 (0x802098000) *libnvpair.so.2 = /lib/libnvpair.so.2 (0x8022c1000)* libavl.so.2 = /lib/libavl.so.2 (0x8024d6000) libbsdxml.so.4 = /lib/libbsdxml.so.4 (0x8026d8000) libgeom.so.5 = /lib/libgeom.so.5 (0x8028ff000) *libzfs_core.so.2 = /lib/libzfs_core.so.2 (0x802b04000)* libc.so.7 = /lib/libc.so.7 (0x80081f000) libsbuf.so.6 = /lib/libsbuf.so.6 (0x802d08000) So, there are circular dependencies between libzfs and the other library in both cases. It seems that those dependencies do not cause much, if any trouble, in practice, but they are not nice, because they are unexpected and they are not present on other OpenZFS platforms. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] fix add_bounce_page() for BUS_DMA_KEEP_PG_OFFSET
On Saturday, April 25, 2015 07:59:50 AM Hans Petter Selasky wrote: On 04/24/15 15:29, Ian Lepore wrote: On Fri, 2015-04-24 at 13:34 +0200, Svatopluk Kraus wrote: The add_bounce_page() can be called from _bus_dmamap_load_phys(). Client virtual address is zero (not valid) in that case. So, client physical address must be used to get an offset when BUS_DMA_KEEP_PG_OFFSET flag is set. Note that client physical address is always valid. Svatopluk Kraus The only user of BUS_DMA_KEEP_PG_OFFSET in the system is USB. If the flag didn't exist, we could do bouncing with a whole lot more efficiency, at least in the ARM world. I wonder if it would be possible to just eliminate the flag (and of course, USB's need for it, which I fully admit I don't understand even a little bit). Hi, USB (EHCI/UHCI/OHCI) needs this flag when computing scatter/gather lists. Please ensure it works like expected. The good news is XHCI needs it less than the EHCI. Ian: The patch looks good - will you commit it? I think the patch looks good. Feel free to commit it (someone) if I don't get to it first. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: backward dependencies on libzfs
On Mon, Apr 27, 2015 at 1:17 AM, Andriy Gapon a...@freebsd.org wrote: I am not sure what's the best list to discuss this issue, so let me raise it here. It seems that libzfs_core can not be used without also linking / loading libzfs: /lib/libzfs_core.so.2: Undefined symbol zcmd_ioctl_compat The same is true for libnvpair but for a different reason (and it looks like mea culpa): /lib/libnvpair.so.2: Undefined symbol aok Both dependencies seem to be backward, because: $ ldd /lib/libzfs.so.2 /lib/libzfs.so.2: libmd.so.6 = /lib/libmd.so.6 (0x801647000) libthr.so.3 = /lib/libthr.so.3 (0x801857000) libumem.so.2 = /lib/libumem.so.2 (0x801a7c000) libutil.so.9 = /lib/libutil.so.9 (0x801c7d000) libuutil.so.2 = /lib/libuutil.so.2 (0x801e8f000) libm.so.5 = /lib/libm.so.5 (0x802098000) *libnvpair.so.2 = /lib/libnvpair.so.2 (0x8022c1000)* libavl.so.2 = /lib/libavl.so.2 (0x8024d6000) libbsdxml.so.4 = /lib/libbsdxml.so.4 (0x8026d8000) libgeom.so.5 = /lib/libgeom.so.5 (0x8028ff000) *libzfs_core.so.2 = /lib/libzfs_core.so.2 (0x802b04000)* libc.so.7 = /lib/libc.so.7 (0x80081f000) libsbuf.so.6 = /lib/libsbuf.so.6 (0x802d08000) So, there are circular dependencies between libzfs and the other library in both cases. It seems that those dependencies do not cause much, if any trouble, in practice, but they are not nice, because they are unexpected and they are not present on other OpenZFS platforms. Fixes similar to this: https://svnweb.freebsd.org/changeset/base/272484 need to be done to plug these symbol dependency problems in the libraries. -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Merging GitHub Pull Requests into Subversion using git-svn
[[ reply private ]] On 4/25/15 12:30 AM, David Chisnall wrote: On 23 Apr 2015, at 00:12, Craig Rodrigues rodr...@freebsd.org wrote: While not as smooth as clicking a merge button in GitHub, this is a valid way to accept patches submitted via GitHub pull requests, and integrate them in our FreeBSD Subversion repo. The merge button on GitHub does the wrong thing anyway (merges without fast-forward, so you end up with a tangled history), so (after the initial setup) the steps that I use for merging pull requests from GitHub projects are very similar (locally pull the branch with fast-fordward, test, push). Not to bikeshed this, but you really almost never want a fast-forward commit. The reason is that it becomes challenging to git-bisect things to sort out where a bad commit was. In addition then the merge is actually one atomic commit. Getting over viewing merge commits as messy was the final hurdle I faced going towards git-nirvana. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: backward dependencies on libzfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/27/15 17:57, Craig Rodrigues wrote: On Mon, Apr 27, 2015 at 1:17 AM, Andriy Gapon a...@freebsd.org wrote: I am not sure what's the best list to discuss this issue, so let me raise it here. It seems that libzfs_core can not be used without also linking / loading libzfs: /lib/libzfs_core.so.2: Undefined symbol zcmd_ioctl_compat The same is true for libnvpair but for a different reason (and it looks like mea culpa): /lib/libnvpair.so.2: Undefined symbol aok Both dependencies seem to be backward, because: $ ldd /lib/libzfs.so.2 /lib/libzfs.so.2: libmd.so.6 = /lib/libmd.so.6 (0x801647000) libthr.so.3 = /lib/libthr.so.3 (0x801857000) libumem.so.2 = /lib/libumem.so.2 (0x801a7c000) libutil.so.9 = /lib/libutil.so.9 (0x801c7d000) libuutil.so.2 = /lib/libuutil.so.2 (0x801e8f000) libm.so.5 = /lib/libm.so.5 (0x802098000) *libnvpair.so.2 = /lib/libnvpair.so.2 (0x8022c1000)* libavl.so.2 = /lib/libavl.so.2 (0x8024d6000) libbsdxml.so.4 = /lib/libbsdxml.so.4 (0x8026d8000) libgeom.so.5 = /lib/libgeom.so.5 (0x8028ff000) *libzfs_core.so.2 = /lib/libzfs_core.so.2 (0x802b04000)* libc.so.7 = /lib/libc.so.7 (0x80081f000) libsbuf.so.6 = /lib/libsbuf.so.6 (0x802d08000) So, there are circular dependencies between libzfs and the other library in both cases. It seems that those dependencies do not cause much, if any trouble, in practice, but they are not nice, because they are unexpected and they are not present on other OpenZFS platforms. Fixes similar to this: https://svnweb.freebsd.org/changeset/base/272484 need to be done to plug these symbol dependency problems in the libraries. Well I think it's different issue. The backward dependency was because of our libzfs_core depends on some compatibility shims (I think it was introduced in r248445). I don't have much time to work on it right now though. Andriy -- maybe file a bug and assign it to me? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.2 (FreeBSD) iQIcBAEBCgAGBQJVPt+QAAoJEJW2GBstM+ns5g8P/jchSVar1TjU2HoJymmthwPM W5mwFSp0f0XWbtd2tkOSUHL6DGvV5pVpzhg3Oj20lrSGJv3s7tymffUSwBtKEA5q fptapAeg/2hXT2U27ns0d5BgaoNz87y0BZgwcWrM4lsDOLpOLt++NPvqf5Jjoq18 y9cRvO06JCZV087Ou/mqU981b7f1T6T+eEUdGXGltP6uynF10HMAlwe53d4hJLgl mhXvZcK78rjf8swtUCBzvkeTkB1OH/O1kL/w8p1oSTUbTERJneNFHEb1+o18XHsA 3aWrnDtweEDgK6mItK3HI26Rq1HvxdqbaYVnfmQikkufyamehzQofXb0AewJuRNf EG4DYp1Y48USD2feQRF0an+lGcro6IQPv1GdKox2VdgR6lF0mOUPJr2TMvKNsumQ 4pxPNsM0b637YzL0mp/bt6t2C6YNaStn+PQ8gWCeOzBM2AJIUqliAP8eghEuAR2a 4kFGOOzLlzITdsg8Y7UNvTmiAMJVGm2XIwkOQA7pUR8LfkFeqyFqb846kR0HOK9w Ce01BAsgM1OFgbo/WELd8ZTTrh+B2eV8dPJhPVEO1tmcniJoeUg3Qj76IPAK34U0 q5FTs5iaEWk2/N+jkd8kAGnZrHhVTLl88aEcdak+eyLj/VtUuvHakZckteDTlYak k5ZJG2p/nxiY5NJPbDJJ =tf6a -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #984
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/984/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: readdir/telldir/seekdir problem (i think)
On 4/28/15 4:03 AM, Rick Macklem wrote:
Julian Elischer wrote:
On 4/25/15 4:28 AM, John Baldwin wrote:
On Saturday, April 25, 2015 02:36:24 AM Julian Elischer wrote:
On 4/25/15 1:30 AM, Julian Elischer wrote:
On 4/24/15 10:59 PM, John Baldwin wrote:
Index: head/lib/libc/gen/telldir.c
===
--- head/lib/libc/gen/telldir.c (revision 281929)
+++ head/lib/libc/gen/telldir.c (working copy)
@@ -101,8 +101,10 @@
return;
if (lp-loc_loc == dirp-dd_loc lp-loc_seek ==
dirp-dd_seek)
return;
- (void) lseek(dirp-dd_fd, (off_t)lp-loc_seek,
SEEK_SET);
- dirp-dd_seek = lp-loc_seek;
+ if (lp-loc_seek != dirp-dd_seek) {
+ (void) lseek(dirp-dd_fd, (off_t)lp-loc_seek,
SEEK_SET);
+ dirp-dd_seek = lp-loc_seek;
+ }
yes I did that yesterday but it still fails when you transition
blocks.. (badly).
I also tried bigger blocks.. also fails (eventually)
I did find a way to make it work... you had to seek back
to the first block you deleted on each set..
then work forward from there again.. unfortunately since
I'm trying to make a microsoft program not fail (via samba)
I have no control over how it does things and seekdir doesn't
know what was deleted anyway... (so the fix is fine for the
test program but not for real life)
I think I can make the BSD one act like the linux one by changing
the lseek being done to use the offset (loc) plus the buffer seek
address of the target, instead of just going for the buffer base
and
stepping forward through the entries..
maybe tomorrow.
The following conditional code makes ours behave the same as the
linux
one.
it breaks several 'rules' but works where ours is clean but
fails..
as Rick said.. maybe that's what we should do too.
this is at the end of seekdir()
The new code does what linux does.. and shouldn't work.. but does
// at least in the limited conditions I need it to.
// We'll probably need to do this at work...:
The original code is what we have now, but gets mightily confused
sometimes.
// This is clean(er) but fails in specific
situations(when
doing commands
// from Microft windows, via samba).
root@vps1:/tmp # diff -u dir.c.orig dir.c
--- dir.c.orig2015-04-24 11:29:36.855317000 -0700
+++ dir.c2015-04-24 11:15:49.05850 -0700
@@ -1105,6 +1105,13 @@
dirp-dd_loc = lp-loc_loc;
return;
}
+#ifdef GLIBC_SEEK
+(void) lseek(dirp-dd_fd, (off_t)lp-loc_seek + lp-loc_loc,
SEEK_SET);
+dirp-dd_seek = lp-loc_seek + lp-loc_loc;
+dirp-dd_loc = 0;
+lp-loc_seek = dirp-dd_seek;
+lp-loc_loc = 0;
+#else
(void) lseek(dirp-dd_fd, (off_t)lp-loc_seek, SEEK_SET);
dirp-dd_seek = lp-loc_seek;
dirp-dd_loc = 0;
@@ -1114,6 +1121,7 @@
if (dp == NULL)
break;
}
+#endif
}
Yes, this isn't at all safe. There's no guarantee whatsoever that
the offset on the directory fd that isn't something returned by
getdirentries has any meaning. In particular, the size of the
directory entry in a random filesystem might be a different size
than the structure returned by getdirentries (since it converts
things into a FS-independent format).
This might work for UFS by accident, but this is probably why ZFS
doesn't work.
However, this might be properly fixed by the thing that ino64 is
doing where each directory entry returned by getdirentries gives
you a seek offset that you _can_ directly seek to (as opposed to
seeking to the start of the block and then walking forward N
entries until you get an inter-block entry that is the same).
I just made the stunning discovery that our seekdir/readdir/telldir
code in libc works with
FreeBSD 8.0.
so maybe the problem is that the kernel changed it's behaviour, and
no-one thought to fix libc..
(at least it works on one of our 8.0 base appliances.. I'll do more
testing tomorrow.. it's past midnight.)
actually that was a mistake.. it fails on 8.0 as much as it fails on
10.x and 11.
the patch above also fixes it on 8.0. (UFS and ZFS)
I suspect that pre-r252438 systems work better for UFS than r252438
or later. That patch changed ufs_readdir() so that it no longer returned
the on-disk directory structure. (Among other things, it added code that
skipped over d_ino == 0 entries.)
yes but it was broken even before that.
basically here's the difference between what Linux (and mu patched
code) does and what we do..
in Linux they seek directly to the base address of the block PLUS the
offset of the entry being seeked.
The filesystem somehow correctly interprets this as teh start of the
correct entry.
I guess it must return the correct information in the dirent structure
in the first place.
in the unmodified BSD version, we seek to the start of the 'block'
(actually the start of the buffer we asked for, which may or may
Re: readdir/telldir/seekdir problem (i think)
On 4/25/15 4:28 AM, John Baldwin wrote:
On Saturday, April 25, 2015 02:36:24 AM Julian Elischer wrote:
On 4/25/15 1:30 AM, Julian Elischer wrote:
On 4/24/15 10:59 PM, John Baldwin wrote:
Index: head/lib/libc/gen/telldir.c
===
--- head/lib/libc/gen/telldir.c (revision 281929)
+++ head/lib/libc/gen/telldir.c (working copy)
@@ -101,8 +101,10 @@
return;
if (lp-loc_loc == dirp-dd_loc lp-loc_seek ==
dirp-dd_seek)
return;
- (void) lseek(dirp-dd_fd, (off_t)lp-loc_seek, SEEK_SET);
- dirp-dd_seek = lp-loc_seek;
+ if (lp-loc_seek != dirp-dd_seek) {
+ (void) lseek(dirp-dd_fd, (off_t)lp-loc_seek,
SEEK_SET);
+ dirp-dd_seek = lp-loc_seek;
+ }
yes I did that yesterday but it still fails when you transition
blocks.. (badly).
I also tried bigger blocks.. also fails (eventually)
I did find a way to make it work... you had to seek back
to the first block you deleted on each set..
then work forward from there again.. unfortunately since
I'm trying to make a microsoft program not fail (via samba)
I have no control over how it does things and seekdir doesn't
know what was deleted anyway... (so the fix is fine for the
test program but not for real life)
I think I can make the BSD one act like the linux one by changing
the lseek being done to use the offset (loc) plus the buffer seek
address of the target, instead of just going for the buffer base and
stepping forward through the entries..
maybe tomorrow.
The following conditional code makes ours behave the same as the linux
one.
it breaks several 'rules' but works where ours is clean but fails..
as Rick said.. maybe that's what we should do too.
this is at the end of seekdir()
The new code does what linux does.. and shouldn't work.. but does
// at least in the limited conditions I need it to.
// We'll probably need to do this at work...:
The original code is what we have now, but gets mightily confused
sometimes.
// This is clean(er) but fails in specific situations(when
doing commands
// from Microft windows, via samba).
root@vps1:/tmp # diff -u dir.c.orig dir.c
--- dir.c.orig2015-04-24 11:29:36.855317000 -0700
+++ dir.c2015-04-24 11:15:49.05850 -0700
@@ -1105,6 +1105,13 @@
dirp-dd_loc = lp-loc_loc;
return;
}
+#ifdef GLIBC_SEEK
+(void) lseek(dirp-dd_fd, (off_t)lp-loc_seek + lp-loc_loc,
SEEK_SET);
+dirp-dd_seek = lp-loc_seek + lp-loc_loc;
+dirp-dd_loc = 0;
+lp-loc_seek = dirp-dd_seek;
+lp-loc_loc = 0;
+#else
(void) lseek(dirp-dd_fd, (off_t)lp-loc_seek, SEEK_SET);
dirp-dd_seek = lp-loc_seek;
dirp-dd_loc = 0;
@@ -1114,6 +1121,7 @@
if (dp == NULL)
break;
}
+#endif
}
Yes, this isn't at all safe. There's no guarantee whatsoever that
the offset on the directory fd that isn't something returned by
getdirentries has any meaning. In particular, the size of the
directory entry in a random filesystem might be a different size
than the structure returned by getdirentries (since it converts
things into a FS-independent format).
This might work for UFS by accident, but this is probably why ZFS
doesn't work.
However, this might be properly fixed by the thing that ino64 is
doing where each directory entry returned by getdirentries gives
you a seek offset that you _can_ directly seek to (as opposed to
seeking to the start of the block and then walking forward N
entries until you get an inter-block entry that is the same).
I just made the stunning discovery that our seekdir/readdir/telldir
code in libc works with
FreeBSD 8.0.
so maybe the problem is that the kernel changed it's behaviour, and
no-one thought to fix libc..
(at least it works on one of our 8.0 base appliances.. I'll do more
testing tomorrow.. it's past midnight.)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #983
I'll fix these tonight. Forgot to add appropriate modfind calls to these testcases, and GENERIC doesn't appear to have mqueuefs or aio built into it... Interesting data points. On Apr 27, 2015, at 11:27, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cam(4) timeouts in bhyve/kyua runs up on Jenkins?
On Apr 27, 2015, at 11:16, Garrett Cooper yaneurab...@gmail.com wrote: Hi mav! I was looking at the console log for the latest kyua run and I’ve noticed that it’s timing out a bit more [1] than it was previously [2]. I’ve seen some of your commits recently to cam(4) dealing with bhyve — has there been a performance regression there? Thanks! -NGie 1. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/940/console 2. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/console (Sorry for not being more explicit for the archives) These are the timeouts I’m referring to: ahcich0: is cs ss 1f00 rs 1f00 tfd 50 serr cmd 1000dc17 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 a8 54 1e 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command signature.asc Description: Message signed with OpenPGP using GPGMail
cam(4) timeouts in bhyve/kyua runs up on Jenkins?
Hi mav! I was looking at the console log for the latest kyua run and I’ve noticed that it’s timing out a bit more [1] than it was previously [2]. I’ve seen some of your commits recently to cam(4) dealing with bhyve — has there been a performance regression there? Thanks! -NGie 1. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/940/console 2. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/console signature.asc Description: Message signed with OpenPGP using GPGMail
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #983
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
