Re: CTF: wpa_supplicant/hostapd 2.4 import

2015-04-27 Thread Ian FREISLICH 
Rui Paulo wrote:
> > locally_generated=1 Apr 22 12:28:34 zen kernel: wlan0: link state changed
> > to DOWN
> 
> Can you send me the log of the previous wpa_supplicant version?

Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: Trying to associate with 
06:27:22:6c:0b:8f (SSID='quasar' freq=2437 MHz)
Apr  6 18:06:38 zen kernel: wlan0: link state changed to UP
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: Associated with 
06:27:22:6c:0b:8f
Apr  6 18:06:38 zen dhclient[1758]: send_packet: No buffer space available
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-STARTED EAP 
authentication started
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD 
vendor=0 method=4 -> NAK
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD 
vendor=0 method=21
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-METHOD EAP 
vendor 0 method 21 (TTLS) selected
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT 
depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich 
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT 
depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich 
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT 
depth=0 subject='/C=ZA/ST=Western Cape/L=Cape Town/O=Freislich Home 
Network/OU=Freislich 
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-SUCCESS EAP 
authentication completed successfully
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: WPA: Key negotiation completed 
with 06:27:22:6c:0b:8f [PTK=CCMP GTK=CCMP]
Apr  6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-CONNECTED - 
Connection to 06:27:22:6c:0b:8f completed [id=7 id_str=]
Apr  6 18:06:43 zen dhclient: New IP Address (wlan0): 10.0.0.220
Apr  6 18:06:43 zen dhclient: New Subnet Mask (wlan0): 255.255.255.0
Apr  6 18:06:43 zen dhclient: New Broadcast Address (wlan0): 10.0.0.255
Apr  6 18:06:43 zen dhclient: New Routers (wlan0): 10.0.0.1

Ian

-- 
Ian Freislich
___
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

2015-04-27 Thread Hans Petter Selasky 

On 04/27/15 15:32, John Baldwin wrote:

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:


...


I think the patch looks good.  Feel free to commit it (someone) if I don't
get to it first.



Hi,

https://svnweb.freebsd.org/changeset/base/282120

Thank you!

--HPS
___
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)

2015-04-27 Thread Julian Elischer 

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 buff

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #984

2015-04-27 Thread jenkins-admin 
See 

___
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

2015-04-27 Thread Xin Li 
-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 
> 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 https://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"

Re: Merging GitHub Pull Requests into Subversion using git-svn

2015-04-27 Thread Alfred Perlstein 


[[ reply private ]]

On 4/25/15 12:30 AM, David Chisnall wrote:

On 23 Apr 2015, at 00:12, Craig Rodrigues  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

2015-04-27 Thread Craig Rodrigues 
On Mon, Apr 27, 2015 at 1:17 AM, Andriy Gapon  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: readdir/telldir/seekdir problem (i think)

2015-04-27 Thread Rick Macklem 
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

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #983

2015-04-27 Thread Garrett Cooper 
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 
> 
> ___
> 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"

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #983

2015-04-27 Thread jenkins-admin 
See 

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

2015-04-27 Thread Garrett Cooper 
On Apr 27, 2015, at 11:16, Garrett Cooper  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?

2015-04-27 Thread Garrett Cooper 
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

Re: readdir/telldir/seekdir problem (i think)

2015-04-27 Thread Julian Elischer 

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: [patch] fix add_bounce_page() for BUS_DMA_KEEP_PG_OFFSET

2015-04-27 Thread John Baldwin 
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"

Jenkins build became unstable: FreeBSD_HEAD-tests2 #982

2015-04-27 Thread jenkins-admin 
See 

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

backward dependencies on libzfs

2015-04-27 Thread Andriy Gapon 

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"