[00:31:48] --- jaltman has left: Disconnected [00:31:57] --- jaltman has become available [00:37:41] --- jaltman has left: Replaced by new connection [00:37:42] --- jaltman has become available [00:38:19] --- Russ has left: Disconnected [01:18:11] --- jaltman has left: Disconnected [01:18:19] --- jaltman has become available [01:35:31] --- Simon Wilkinson has become available [02:09:34] --- Jeffrey Altman has left [02:50:49] --- Simon Wilkinson has left [03:51:49] --- Simon Wilkinson has become available [04:03:02] --- Simon Wilkinson has left [04:03:04] --- Simon Wilkinson has become available [04:22:22] --- Simon Wilkinson has left [04:49:16] --- Simon Wilkinson has become available [05:55:19] --- meffie has become available [06:24:52] --- Jeffrey Altman has become available [06:25:03] --- Jeffrey Altman has left [07:32:28] --- deason has become available [08:39:48] --- jaltman has left: Disconnected [08:42:36] --- jaltman has become available [10:10:28] --- meffie has left [10:42:07] --- jaltman has left: Disconnected [11:25:37] --- Simon Wilkinson has left [11:42:38] --- rra has become available [11:49:54] --- meffie has become available [12:45:45] --- meffie has left [13:02:06] --- rra has left: Disconnected [13:20:18] --- matt has become available [13:20:23] --- matt has left [13:23:46] --- jaltman has become available [13:24:33] --- rra has become available [13:27:43] --- jaltman has left: Disconnected [13:39:28] --- matt has become available [13:48:14] I cannot load libafs on FBSD 81, post 5b71bab, "Bad system call: 12" [13:48:44] Is there something I need to do (ideally, not make buildkernel...") [13:52:44] ? [13:57:47] --- jaltman has become available [14:07:46] So, if this patch could only work if FreeBSD has AFS_SYSCALL (339) in a registry, then it should not be unconditional. What we had worked for me...yesterday on FreeBSD 8 ad 8.1. [14:10:02] so we want to use the "old way" before and the "new way" into the future? [14:10:26] Yes, looks like it. If we can get the registry updated before RELENG_9? [14:10:53] (Assuming that's he issue. If there's a way to fix syscall_register, I'm all for it.) [14:11:06] ben already pinged robert as far as registry goes [14:11:30] So, it is a registry thing, and probably/hopefully something that will work when 9 is releng? [14:11:52] yes to the former and no clue to the latter [14:12:14] Well, sure, but we can hope. If not, ew. [14:12:47] we could do the hack we do on macos [14:13:41] We seem to get by on differet platforms, but are they trying to forbid us a syscal? [14:13:52] freebsd or the others? [14:14:00] Freebsd, I meant. [14:14:38] i doubt they are trying to deny us. oversight i bet [14:14:55] That's what I'd say too, crossing fingers. [14:18:15] Hi all. [14:18:46] hi dr nick. [14:22:10] In looking back at the patch I wrote for this, I did mess up the version checks. syscall_register() is broken for us on all FreeBSD versions, since there is already something there that is not lkmnosys. What we previously did is broken on FreeBSD HEAD, since now the syscall dispatcher does more checks and we didn't hackishly patch ourselves in correctly to deal with that. It is possible (and fairly easy, really) to patch syscalls.master to populate syscalls 339 (and 377, I suppose, though we seem to not actually be using it) with lkmnosys, and then syscall_register() works just fine. This does require rebuilding a kernel, though. [14:22:41] --- jaltman has left: Disconnected [14:23:05] I guess we may want to keep the old (hackful) syscall-hooking code around for old fbsd releases, since people may not want to upgrade their kernel just to use openafs. [14:24:19] Sorry for being sloppy in reading the code; I had just assumed that an UNIMPL syscall would be register-able, but that is clearly not the case. [14:42:15] So, are you going to send a new change fitting it the way you want? [14:42:29] --- jaltman has become available [14:45:02] I was working on making it conditional on AFS_FBSD90_ENV. I'll stop if you're going to do it, esp. if you want to do it differently. [14:49:14] I can't look at it right now; I could do something tonight, but it would just be making it conditional on AFS_FBSD90_ENV. [14:54:01] Ok, I'll continue--thanks for the quick response. [14:54:16] Thanks. Sorry about the mess. [14:54:29] No problem. [15:21:55] Sun relicensed their RPC code to remove their bizarre license. [15:21:57] http://spot.livejournal.com/315383.html [15:22:03] I suspect this applies to us as well. [15:23:09] Since as I recall we have some of that code in our tree. [15:25:23] reading. [15:27:11] It's not a huge deal, since everyone always assumed they really meant that license to be free and wouldn't enforce it anyway, but we may want to change the license statement as a cleanup. [15:27:21] i think we do [15:27:28] also our LICENSE file [15:39:04] --- deason has left [16:26:39] --- matt has left [18:07:01] --- deason has become available [18:23:16] --- jaltman has left: Disconnected [18:40:02] --- rra has left: Disconnected [19:01:57] --- Russ has become available [19:20:16] --- jaltman has become available [19:37:04] --- jaltman has left: Disconnected [19:40:34] I forget; do I have an easy way to figure out which process/thread has the GLOCK, or do I have to infer from the source line at which it was locked? [20:12:14] --- phalenor has left [20:14:48] afs_global_owner should tell you which process or thread, but there's no helpful way to query it [20:21:38] --- phalenor has become available [20:26:03] kgdb is a perfecly helpful way to query it :) [21:17:33] --- jaltman has become available [21:33:53] --- jaltman has left: Disconnected [21:34:13] --- jaltman has become available [22:16:52] --- jaltman has left: Replaced by new connection [22:16:53] --- jaltman has become available [22:37:23] --- jaltman has left: Replaced by new connection [22:37:23] --- jaltman has become available [22:52:56] Hm. With a 4M (memory) cache, copying a directory tree with largest file 150k or so, how plausible is it that CacheTruncateDaemon would fail to clear up space, causing the copy to hang? [22:53:20] --- Russ has left: Disconnected [23:03:11] --- deason has left