[00:24:11] --- reuteras has become available
[01:03:57] --- Russ has left: Disconnected
[02:02:55] --- Simon Wilkinson has left
[04:43:25] --- meffie has become available
[05:25:56] --- Simon Wilkinson has become available
[05:34:14] --- Simon Wilkinson has left
[07:03:27] --- Simon Wilkinson has become available
[07:17:51] --- Simon Wilkinson has left
[07:22:40] --- cclausen has become available
[07:23:02] --- kula has become available
[07:23:16] --- mfelliott has become available
[07:23:34] <mfelliott> Is the BuildBot Master around?
[07:24:45] <jaltman> jason is not here
[07:31:41] --- deason has become available
[08:07:03] <jakllsch> hah, so ... you have to compile the LKM with -fno-omit-frame-pointer on amd64 ...
[08:08:06] <shadow@gmail.com/owlF2E50C3B> i assume you have to compile it with the same options the kernel uses.
which if it's that, ...
[08:10:10] <jakllsch> yeah, the kernel has -fno-omit-frame-pointer, primarily so backtraces in the kernel debugger work :-)
[08:11:49] <jakllsch> the symptom was backtraces that stopped in the LKM
[08:12:13] <jakllsch> (making them ~useless)
[08:38:07] <kaduk@mit.edu/barnowl> I may as well warn you now to check on the use of red zones -- a
mismatch between kernel and LKM on FBSD caused some annoying random
crashes.
[08:40:54] <shadow@gmail.com/owlF2E50C3B> which istr you found because i had the issue on amd64 linux :)
[08:46:51] <kaduk@mit.edu/barnowl> Indeed. :)
[09:09:09] <kaduk@mit.edu/barnowl> Ah, this negative-refcnt-in-vputx is from afs_root ...
[09:14:01] --- rra has become available
[10:20:35] --- reuteras has left
[10:51:10] <deason> well that's fun; if you give buildbot the wrong branch/revision, it keeps retrying to fetch it from git forever, it looks like
[10:54:03] <jaltman> did you try telling buildbot to cancel it?
[10:56:48] <deason> yeah, it's been cancelled, but I didn't realize what was happening for a while :)
[11:09:56] <mfelliott> would MacOSX buildbot slaves be useful?
[11:16:06] <deason> I'd say buildbot slaves for any platform that currently builds would be useful
[11:16:13] <deason> (yes)
[11:16:24] <mfelliott> I'm ready to go then. just need to config info.
[11:17:44] <deason> email jason (or wait for him to show up here / contact him in some other way)
[13:36:22] <jhutz@jis.mit.edu/owl> Why does our specfile go out of its way to insist that krb5-config is in
/usr/kerberos/bin even when it's actually in /usr/bin ?
[13:37:40] <meffie> that is the redhat path
[13:38:04] <shadow@gmail.com/owlF2E50C3B> [shadow@localhost ~]$ which krb5-config
/usr/kerberos/bin/krb5-config
[shadow@localhost ~]$ cat /etc/redhat-release 
CentOS release 5.5 (Final)
[13:39:24] <jhutz@jis.mit.edu/owl> Maybe that's where it was on RHEL5.5.
It's not where it is on all RPM-based systems.
Why are we hardcoding it, when configure has perfectly good
logic for finding it on the path?
[13:39:39] <shadow@gmail.com/owlF2E50C3B> it didn't when the spec file was written
[13:40:48] <jhutz@jis.mit.edu/owl> Really?  Because I'm pretty sure autoconf had perfectly good support for
finding things on the path well before krb5-config existed.
[13:41:34] <shadow@gmail.com/owlF2E50C3B> no guarantee krb5-config was on anyone's path.
[13:42:20] --- meffie has left
[13:43:00] --- meffie has become available
[13:44:56] <jhutz@jis.mit.edu/owl> I'm sorry; it sounds like you're suggesting that because krb5-config
might not be on the path, our configure script didn't bother looking,
and instead expected an exact location to be provided on the command
line.  That's just silly.
[13:45:40] <jhutz@jis.mit.edu/owl> Particularly since it's well-known that the obvious places to look
are on the path, in $prefix, and in /usr/kerberos
[13:46:41] <deason> > Because I'm pretty sure autoconf had perfectly good support for
autoconf may have, but I wouldn't find it surprising if our configure did not at the time
[13:51:18] <shadow@gmail.com/owlF2E50C3B> it's not like some patch has been rejected. i'm not even sure why we're
still talking about this
[14:06:21] <rra> We used to not be able to find krb5-config.  That's fixed in the latest version of my krb5.m4, and I think that got rolled in, but if not, I can update it.
[14:07:18] <jhutz@jis.mit.edu/owl> OK; I'm confused.  Why does the i386 'openafs' package I just built
contain a /usr/bin/kpasswd, but the x86_64 one does not?
[14:16:21] <phalenor>  how did you build it? The 32-bit package for both 1.4.12 and 1.5.77 puts /usr/bin/kpasswd in an openafs-kpasswd package
[14:23:28] <phalenor> although, there was a commit that removed it from 'openafs' back in june, so presumably there could be versions that does just that
[15:25:00] --- meffie has left
[15:50:07] <jakllsch> why would afs_lookup() end up allocating more than one vnode?
[15:51:04] <jakllsch> and why does one of these vnodes, the vnode it doesn't return, end up having a lock held on it that there shouldn't be?
[15:53:08] <kaduk@mit.edu/barnowl> Uh, lookup should only have dvp and vpp, and dvp should exist before
lookup is called.
[15:54:20] <jakllsch> well, afs_nbsd_getnewvnode is being called twice within a lookup()
[15:55:02] <jakllsch> and one of those seems to come out of nowhere, and carrying a sleep lock that i'm not allowed to keep holding
[16:00:07] <jakllsch> i wonder if inactive() is supposed to unlock the vnode
[16:01:08] <jakllsch> let's try that
[16:03:12] <jakllsch> hum.
[16:03:14] <jakllsch> seems to be it
[16:03:33] --- deason has left
[16:03:46] <kaduk@mit.edu/barnowl> Inactive is supposed to unlock the vnode, yes.
[16:03:58] <kaduk@mit.edu/barnowl> But I'm still skeptical of two calls to getnewvnode.
[17:39:44] --- rra has left: Disconnected
[17:56:45] --- Russ has become available
[18:06:17] <jakllsch> well, i don't care too much if it seems to work
[18:06:52] <jakllsch> it's really surprising, i'm in my home dir modifying my files already, though creating new ones isn't there yet
[18:26:26] <shadow@gmail.com/owlF2E50C3B> >        why would afs_lookup() end up allocating more than one vnode?


bulkstat?
[18:55:41] <kaduk@mit.edu/barnowl> Hm.  Derrick (or anybody, really), do you have a sense for how often
one would hit the 'goto tryagain;' in line 272 of FBSD/osi_vfsops.c
(afs_root)?
[19:07:05] --- deason has become available
[19:55:35] <shadow@gmail.com/owlF2E50C3B> rarely. on root.afs release if the root vnode changed
[19:58:53] <kaduk@mit.edu/barnowl> Hm.  Any other times?  If the pool of vcaches or vnodes was exhausted,
maybe?
[20:06:19] <shadow@gmail.com/owlF2E50C3B> it's possible. seems unlikely
[20:06:55] <shadow@gmail.com/owlF2E50C3B> tho, it looks wrong: it shouldn't put before getting a new one.
[20:07:02] <kaduk@mit.edu/barnowl> Yeah.
[20:07:03] <shadow@gmail.com/owlF2E50C3B> look at e.g. Solaris'
[20:07:22] <kaduk@mit.edu/barnowl> I've seen a panic twice, now, where putvcache was calle with a
negative ref count on the vnode.
[20:07:39] <kaduk@mit.edu/barnowl> (Well, "negative".  ISTR that the check is < 1)
[20:08:24] <kaduk@mit.edu/barnowl> But I've only seen it twice in some 20-30 hours of heavily loading the
machine.  That goto was a likely candidate, but I wasn't sure.
[20:16:21] <kaduk@mit.edu/barnowl> Hm.  Though, those both were overnight builds ....
[20:16:34] <kaduk@mit.edu/barnowl> And we do do a nightly release ...
[22:24:43] --- Russ has left: Disconnected
[22:35:41] --- deason has left