[00:28:37] --- Russ has left: Disconnected [00:40:34] --- jaltman/FrogsLeap has left: Disconnected [02:06:37] --- reuteras has left [02:06:38] --- reuteras has become available [02:26:39] --- reuteras has left [02:26:40] --- reuteras has become available [05:14:57] --- reuteras has left [05:15:51] --- reuteras has become available [06:10:43] --- jaltman/FrogsLeap has become available [07:04:39] --- reuteras has left [07:32:07] --- deason has become available [08:50:43] hmmm (sol8) /opt/SUNWspro/bin/cc [...] -o librokenafs.so.1.1 daemon.o [...] ld: fatal: relocation error: file daemon.o: section .rela.text: relocation 0x53: relocation not currently supported [08:51:36] it _looks_ like the compiler may just be generating a relocation that all of the other tools don't understand for some reason (elfdump shows a '0x53' relocation, with no symbolic name) [08:51:53] what sunpro version? [08:52:57] looks like 11, and $ cc -V cc: Sun C 5.8 Patch 121015-04 2007/01/10 [08:53:11] it's possible someone did something weird/stupid with getting sunwspro on here [08:54:20] I'm getting it myself again now to see if that changes anything, but just wondering if anyone had any other idea / seen that before [08:55:56] oh, and it goes away for daemon.o if I compile it with -xcode=pic13 instead of -xcode=pic32 (aka -KPIC) [09:38:58] Is it normal or surprising that running 'ls /afs/grand.central.org/software/openafs/candidate/1.6.0pre1/' with no cache and not having talked to g.c.o before would sit in afs_rx_cv_wait for 30 seconds or more before returning? [09:39:50] i bet if you tcpdump you see you're trying to talk to something that doesn't respond and you are thus timing out a server [09:40:01] which would be "or more" [09:40:04] at some point Sun shipped a broken /usr/ccs/bin/ld [09:40:16] which affected sol7 and sol8 [09:40:43] my workaround was gnu ld, when I couldn't get my hands on the patch that fixed it (which I'll be damned if I can remember now) [09:41:50] in particular, if you put PIC object files in a static archive, ld trying to use it got completely confuddled about whether it was shared or static. that usually showed up in a later ld rrun trying to use the mangled output [09:42:02] (diagnosing that one was fun) [10:04:37] we're not in an archive here, though; this seems to be a rather simple "create a dso" [10:11:16] > or more Yeah, I walked out of the room for several minutes. [10:26:54] And yet I have the same as /afs/gco/service/csdb/ : >grand.central.org #GCO Public CellServDB 29 Jun 2009 18.9.48.14 #grand.mit.edu 128.2.203.61 #penn.central.org 130.237.48.87 #andrew.e.kth.se [10:27:30] andrew.e has been sad on and off for months [10:30:36] Right. [11:24:33] --- kaduk@mit.edu/barnowl has left [11:26:34] --- kaduk@mit.edu/barnowl has become available [12:21:05] --- andersk has left [12:23:08] --- andersk has become available [13:37:39] --- deason has left [13:37:40] --- deason has become available [13:46:04] we need a "i think i am waiting too long for answers, how do i debug it" page in the wiki [14:07:40] --- abo has left: Lost connection [14:07:40] --- mho has left: Lost connection [14:08:18] --- abo has become available [16:11:59] --- deason has left [16:18:26] Have we heard anything from matt recently? [16:19:00] "we". i talked to matt 6 hours ago [16:19:44] Is he on an im system accessible to me? [16:19:54] POTS? [16:20:34] Hmm, I could do POTS but I don't think the question is phone-interrupt-level urgent. [16:21:38] I am looking at whether we need to be mucking around with VFS_[UN]LOCK_GIANT, which he added in a 70-client commit under #ifdef AFS_FBSD80_ENV [16:21:55] But it's not clear to me that we need it at all. [16:23:47] probably not. that's how i talked tho [16:24:31] i bet he doesn'tremember [16:24:55] Yeah, me too. [16:30:00] Looking more carefully at how we call it, I'm becoming more confident we don't need it. [16:33:38] nuke [16:34:47] Yeah. Just have to find all the pieces. [17:24:04] There you go. [17:24:55] > [17:24:57] ? [17:25:54] 3656? [17:31:24] --- rra has left: Disconnected [17:49:33] --- Russ has become available [17:57:14] --- jaltman/FrogsLeap has left: Replaced by new connection [17:57:15] --- jaltman/FrogsLeap has become available [18:00:24] Also, before the hang on shutdown we have a LOR between a ufs vnode lock and the allproc lock (due to pfind, presumably). [18:00:32] It's not yet clear if this is causally related to the hang. [18:20:59] i bet it is [18:24:54] "Fun." [18:31:50] So, do we make another thread do the psignal() or do we store the struct proc * in a global variable? [18:32:07] for now? whatever's easier [18:32:18] the latter, probably [18:32:28] we have a global vp and vfs, so. [19:02:23] Actually, would the difference between 'extern' and 'extern volatile' make a difference for StopListener? [19:08:52] --- jaltman/FrogsLeap has left: Disconnected [19:09:00] --- jaltman/FrogsLeap has become available [19:31:42] --- shadow@gmail.com/owlFB78C669 has left [19:31:55] --- shadow@gmail.com/owl3BA35B6F has become available [19:34:18] well, you can try. i'd think no [19:34:43] Yeah, given that AFS_TERM_STATE works, it seems moot. [19:57:44] UnmaskRxkSignals... RxListener... lock order reversal: 1st 0xffffff003f8dedb8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1201 2nd 0xffffffff80c8c340 allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292 KDB: stack backtrace: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/kern/kern_mutex.c:147 cpuid = 1 KDB: enter: panic [19:57:55] :( [19:58:13] so set it in a global earlier [19:58:21] like, say, when it's started [19:58:29] I did. [19:58:41] so, what, pkill? [19:58:59] different thread then [19:59:38] psignal, I think. [20:00:11] The "locking destroyed mutex" is more worrying, really. [21:38:29] --- jaltman/FrogsLeap has left: Replaced by new connection [21:38:30] --- jaltman/FrogsLeap has become available [21:40:07] --- jaltman/FrogsLeap has left: Disconnected [21:43:00] --- jaltman/FrogsLeap has become available [22:22:01] --- Russ has left: Disconnected [23:31:25] --- reuteras has become available