00:40:05 <jbk> oh duh!
00:41:43 <jbk> let me update
00:56:59 <jbk> hrm...
00:58:32 <jbk> when wcopen() is called, we call vt_open() which on the first open calls tem_init() which stashes the queue_t passed in from wcopen()
00:59:13 <jbk> however wcclose() doesn't call vt_close() if the minor# is 0, which means that queue_t stashed by tem_init() is never cleared
00:59:46 <jbk> and i'm not sure why we're explicitly skipping this for 0
01:01:27 <jbk> or if maybe the tem_cleanup should move from vt_close() to vt_clean()
16:44:36 <sommerfeld> jbk: it occurs to me that the right way to use cpuid leaf 0x15 would be to run the HPET calibration as a sanity check, and if the leaf 0x15 frequency was within some tolerance of the measured value, use the cpuid frequency.
16:55:26 <jbk> the intel sdm actually states that the TSC frequency is ecx * ebx/eax (if ecx and ebx are 'enumerated' -- not 0)
16:55:41 <jbk> just there's a fair amount of intel chips where it's not
16:56:34 <jbk> and of course nothing (AFAIK) for AMD
17:28:13 <jbk> hrm.. on this tem issue me and tsoome have been looking at...
17:29:37 <jbk> I'm going to go ahead and file a bug
17:29:45 <jbk> but apparently we get _really_ lucky
17:30:02 <jbk> at least most of the time
17:31:07 <jbk> we're stashing a free'd queue_t, but apparently kmem_cache_alloc() is recycling it so that it ends up getting used for the right thing
17:31:11 <jbk> at least most of the time
17:31:25 <jbk> so it mostly works by accident
17:40:58 <sommerfeld> I would have thought DEBUG kernels would catch that.
17:41:27 <sommerfeld> or are we not double-freeing it?
17:42:02 <jbk> well we free it, kmem_cache_alloc() appears to then recycle it so it's once again valid
17:42:11 <jbk> and most of the time it gets reused for the same thing as it originally was
17:42:17 <jbk> so by the time you access it again, it's valid
17:42:26 <jbk> assuming of course it's been recycled
17:42:32 <jbk> for that use
17:42:35 <jbk> and not some other stream
17:42:40 <sommerfeld> ah, dumb luck.   is it a queue_t-specific cache?
17:42:51 <jbk> yeah.. there's a kmem cache for queue_ts
17:44:22 <jbk> i don't know if there's a way offhand to maybe make kmem use an alternate reuse strategy
17:46:48 <sommerfeld> the magazine structure means you generally have very fast LIFO reuse
17:47:05 <sommerfeld> on a per-cpu basis
17:47:21 <sommerfeld> very cache friendly
18:22:50 <jbk> ok.. now to grab lunch :)
18:31:08 <jbk> i guess if I really wanted to, I could try to catch allocq() reusing it, but i think capturing where it's getting saved, and then later passed to freeq(), then later back and all valid looking is I hope enough