> % venti/venti
> 2010/1116 20:44:14 venti: conf...2010/1116 20:44:14 err 4: read
> /Users/dave/venti/disks/bloom offset 0x0 count 65536 buf 380 returned
> 65536: No such file or directory
A read of 65536 returning 65536 should not be an error.
If you want to dig in, this is $PLAN9/src/cmd/ven
lock loops are about Locks (spin locks), not QLocks.
the relative ordering of any two calls to qlock and qunlock
is irrelevant.
russ
On Wed, Nov 17, 2010 at 6:36 AM, Russ Cox wrote:
> > % venti/venti
> > 2010/1116 20:44:14 venti: conf...2010/1116 20:44:14 err 4: read
> > /Users/dave/venti/disks/bloom offset 0x0 count 65536 buf 380 returned
> > 65536: No such file or directory
>
> A read of 65536 returning 65536 should not
I'm giving consideration to maintaining a venti-based setup for my house for
all the digital media we have (since getting our Apple TV, we've had more
stuff to stream around the house).
I've just now started playing with things like vac/unvac, to backup and
extract trees of my HFS+ file system and
i pushed a minor update to sources. i've
been able to boot an auth server with
nfactotum built into the kernel. i've been
able to cpu and drawterm into this machine.
but testing has been light (and at 4am) so
ymmv.
- erik
On Wed, Nov 17, 2010 at 11:51 AM, David Leimbach wrote:
> I'm giving consideration to maintaining a venti-based setup for my house for
> all the digital media we have (since getting our Apple TV, we've had more
> stuff to stream around the house).
> I've just now started playing with things like v
On Wednesday 17 November 2010 18:14:35 Venkatesh Srinivas wrote:
> (...)
> I'd be very careful with vac -m and -a on Unix; both have been at the
> root of considerable data-loss on a unix venti for me. I'd recommend
> vac-ing tarballs, rather than using vac's on unix trees directly. But
> your mile
On Wed, Nov 17, 2010 at 9:14 AM, Venkatesh Srinivas wrote:
> On Wed, Nov 17, 2010 at 11:51 AM, David Leimbach
> wrote:
> > I'm giving consideration to maintaining a venti-based setup for my house
> for
> > all the digital media we have (since getting our Apple TV, we've had more
> > stuff to str
On Wed, Nov 17, 2010 at 12:23 PM, dexen deVries wrote:
> On Wednesday 17 November 2010 18:14:35 Venkatesh Srinivas wrote:
>> (...)
>> I'd be very careful with vac -m and -a on Unix; both have been at the
>> root of considerable data-loss on a unix venti for me. I'd recommend
>> vac-ing tarballs, r
On Wed, Nov 17, 2010 at 9:23 AM, dexen deVries wrote:
> On Wednesday 17 November 2010 18:14:35 Venkatesh Srinivas wrote:
> > (...)
> > I'd be very careful with vac -m and -a on Unix; both have been at the
> > root of considerable data-loss on a unix venti for me. I'd recommend
> > vac-ing tarballs
On 11/14/2010 04:44 PM, Charles Forsyth wrote:
> the list of unimplemented items in /sys/src/cmd/cc/c99* is:
> i can think of something else that's not been noticed, but what other things
> have you found?
Why is __func__ listed as “unwanted”? I’ve found it useful for some
logging functions.
-
> one could move:
>
> up->qpc = getcallerpc(&q);
>
> from qlock() before the lock(&q->use); so we can see from where that
> qlock gets called that hangs the exportfs call, or add another magic
> debug pointer (qpctry) to the proc stucture and print it in dumpaproc().
Cinap, I tried your
> Anyway, I have moved the assignment to "qpctry" to after "up" is
> tested. Let's see what happens. I'll have to get back to you once
> the system is back up.
The system is working now. I have to wait for a problem to arise, next.
++L
> Strangely, later in the qlock() code "up" is checked and a panic
> issued if zero. I'm missing something here: it is possible to execute
> this code
you must be in process context to qlock, because only
processes can sleep.
- erik
> Why is __func__ listed as “unwanted”? I’ve found it useful for some
> logging functions.
i think the correct interpretation of unwanted in this
context is either don't want or don't want to implement.
one former member of the don't-want list was varadic macros,
which are now supported by both
i tried out the changes to pc/^(apic.c mp.^(c h))
to explictly support processors with apic id >= 8.
unfortunately my testing machine hangs with the
changes even though its processors have apic ids
0-7.
chula; aux/cpuid -t
thread 0001 0002 0100
core0004 0008 0
16 matches
Mail list logo
