On Wed, May 28, 2014 at 12:34 PM, Aram Hăvărneanu ara...@mgk.ro wrote:
Plan 9 doesn't have virtio ethernet driver (except mischief's, which I
don't think is ready for public consumption yet).
You will also need a virtio-scsi driver; GCE does not offer
virtio-blk. But it should work just fine
How was 3E different from 2E and from 4E?
-- vs;
the pae kernel deserves a word or so. the pae kernel brings
with it a streamlined kernel, supporting only very modern
machines, such as the pentium pro.
If it requires PAE, it will not run on Banias and Dothan B-stepping
and C-stepping (on 400MHz FSB) CPUs (most Pentium M's).
Hi,
Also, this is somewhat unrelated, but I was wondering whether each Go
executable contains the garbage collector. (It must, it seems, but just
checking).
It does.
-- vs
When my home directory is less than 2 gigabytes in size, I use
dump9660 from Plan 9 port (or a standalone relative).
Otherwise I rsync my home to a DragonFly BSD system and take a HAMMER snapshot.
-- vs
Just asynchronous TClunk is enough to improve 9P's performance over
high-latency links dramatically.
-- vs
Using the hacky inferno-npe async clunk implementation, from october
2010; from a Linux server running inferno-npe to a Linux client
running inferno-npe; latency ~15ms. Getting the sources of cwfs from
the server fell from 5.6 sec to 4.5 sec. For the 9 kernel sources, 51
sec fell to 41 sec.
Got
On Thu, Sep 8, 2011 at 7:32 PM, erik quanstrom quans...@quanstro.net wrote:
On Thu Sep 8 19:31:19 EDT 2011, rminn...@gmail.com wrote:
On Thu, Sep 8, 2011 at 4:19 PM, Venkatesh Srinivas m...@acm.jhu.edu wrote:
Just asynchronous TClunk is enough to improve 9P's performance over
high-latency
On i386 systems with MONITOR/MWAIT, you could use them; simpler than
adding support for IPIs, I imagine.
-- vs
I use xcip on a modern Unix;
http://plan9.bell-labs.com/sources/contrib/vsrinivas/xcip-modern.jpg
There is a tarball in my contrib, xcip.tar; it is a copy of 1995-era
xcip, made to build on recent linux systems. It needs Plan9port to
build (9's lex and yacc, iirc).
-- vs
at coraid, we're considering asking new hires use ed for
a week exclusively.
sam -d allowed? :)
-- vs
sam -d
-- vs
Hi,
In 9P, if I wish to list a directory, I need to TWalk to the directory,
TOpen the directory fid from the walk, and then TRead till I have all of the
contents of the directory.
If the directory's contents do not fit in a single read, I imagine I need to
loop around TOpen / Tread / / Tread
Don't forget platforms != x86; an emulator would be needed on ARM (say) if a
PC-like graphics chip found its way over there. I believe X has had such a
beast (x86emu?) and used it heavily on PPCen.
-- vs
On Fri, Feb 25, 2011 at 1:51 AM, Russ Cox r...@swtch.com wrote:
your layout in your first email (i think) assumes that wakeup
can be called twice.
it doesn't. the scenario in my first email has exactly one
sleep and one wakeup.
the canonical problem you have to avoid when implementing
On Fri, Jan 28, 2011 at 4:56 PM, erik quanstrom quans...@quanstro.netwrote:
On Fri Jan 28 16:33:03 EST 2011, m...@acm.jhu.edu wrote:
The Tegra is probably one of the best ARM chips out there...
No it isn't; the Tegra lacks NEON.
why do you think simd support is key? we have simd
On Sat, Jan 29, 2011 at 5:51 AM, Lawrence E. Bakst m...@iridescent.orgwrote:
At 4:31 PM -0500 1/28/11, Venkatesh Srinivas wrote:
The Tegra is probably one of the best ARM chips out there...
No it isn't; the Tegra lacks NEON.
-- vs
1. I should have said:
The Tegra 2 is probably one
The Tegra is probably one of the best ARM chips out there...
No it isn't; the Tegra lacks NEON.
-- vs
There exist two different AC97 drivers; look at the port of Doom to plan9
for pointers to one of them.
-- vs
On Wed, Jan 12, 2011 at 11:53 AM, Steve Simon st...@quintile.net wrote:
anyone know the lineage of plan9's ape/make,
I would like to find a manual page and understand what
clever features it does / doesn't support.
-Steve
Use -vga std at the qemu command line. All of the modes work okay then.
-- vs
On Wed, Nov 17, 2010 at 11:51 AM, David Leimbach leim...@gmail.com 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
On Wed, Nov 17, 2010 at 12:23 PM, dexen deVries dexen.devr...@gmail.com 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
Under certain situations, 9p can do some forms of pipelining. The tagged
requests don't have to be waited on in order, for the next outgoing request
to be sent, unless there's a dependency of one completing before the other,
or the evaluation of completion of a previous one on another.
Only
Hi,
In the paper 'Semaphores in Plan 9' by Sape and Russ Cox, there was this
note:
The performance of the semaphore-based lock implementation is sometimes
much better and never noticeably worse than the spin locks. We will replace
the spin lock implementation in the Plan 9 distribution soon.
As
one interesting thing about that example is that if it were done again
for the Plan 9 environment, mk might well be even smaller, since
some of the existing functionality isn't really used,
or might be achieved by simpler mechanisms, or with functionality
added instead by further composition
On Fri, Oct 29, 2010 at 5:01 AM, Charles Forsyth fors...@terzarima.netwrote:
What you are saying is that the problem could be something like:
- Tclunk
(do not wait for response)
- Topen (the file is exclusive)
no, because what actually happens is closer to
A: Topen
...
On Fri, Oct 29, 2010 at 12:01 PM, Charles Forsyth fors...@terzarima.netwrote:
Do you do completely asynch clunks or just the wait for the response?.
it uses `completely' async clunks, which is why it can be broken.
having the original process send the Tclunk and not wait
for the Rclunk is
erik quanstrom wrote:
what's a reasonable definition of standard?
I've been using 'decent' in much the same way 'standard' or 'disk' is being
used; I'd actually prefer nemo's idea of a QTDECENT qidtype to marking the
file server. The original QTDECENT proposal (actually originally inverted
On Thu, Oct 28, 2010 at 11:53 AM, Francisco J Ballesteros n...@lsub.orgwrote:
Yes, in general, agree, but this was about clunk usage and
semantics, and I think it's important to have the I'm done message
synchronous when you need that.
Btw, I think you mean Tstat, don't you?
I'm not sure
On Thu, Oct 28, 2010 at 8:12 AM, Charles Forsyth fors...@terzarima.netwrote:
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
On Thu, Oct 28, 2010 at 4:18 PM, Charles Forsyth fors...@terzarima.netwrote:
the race is that there's nothing to say that the clunk completes before the
process continues on to do something more, including some action that
depends on the clunk completing,
such as simply repeating the open.
On Thu, Oct 28, 2010 at 4:55 PM, Nemo nemo.m...@gmail.com wrote:
i have decent servers that wait for clunk to operate on written data once
it's complete. all octopus spoolers do that.
Heh; when I wrote 'decent', I was recalling the old proposed QTDECENT qid
type. I didn't mean to impugn your
Hi folks,
I just committed a very simple implementation of asynchronous TClunk to
inferno-npe. The implementation will only defer sending clunks when MCACHE
is specified on the mount (via the new -j option to Inferno's mount,
analogous to Plan 9's mount -C) and when the file is not marked
2) you can't pipeline requests if the result of one request depends on the
result of a previous. for instance: walk to file, open it, read it, close
it.
if the first operation fails, then subsequent operations will be invalid.
Given careful allocation of FIDs by a client, that can be dealt
Hi,
For those of us who can't be at IWP9, are there any plans to videotape the
talks?
Thanks,
-- vs
virtio is available in vanilla qemu nowadays.
Why do you want to run your file server in qemu anyway, though?
For snapshots, I use dump9660 on my host, coupled with inferno; u9fs would
work just as well.
-- vs
On Tue, Aug 17, 2010 at 9:50 AM, Brad Frank brad.fr...@gmail.com wrote:
Hi, I recently did a clean install of plan9 on qemu on linux. I've noticed
that the load is spiking on an interval every 30 seconds or something like
that. I looked at suggestions that it might be venti and timesync. But
Hi 9fans,
So GSoC is more or less over!
First, I really need to thank David Eckhardt and Erik Quanstrom for putting
up with me this summer; dealing with me can be as frustrating as pulling
teeth with a screwdriver when a patient only speaks another language. Next
time I see either/both of them,
typically, accessing memory above the stack is not a problem, so a single
red zone below the stack is enough. this red zone need not be an actual
segment, if the thread library picks segment addresses. although this
would force the thread library to keep tabs on the top of the heap.
Yep!
On Sat, Aug 7, 2010 at 5:33 PM, Charles Forsyth fors...@terzarima.netwrote:
close must be synchronous, unless you aim for NFS semantics.
to be more explicit: think of exclusive-use services, services that wait
for a close to commit,
files with DMEXCL, and files opened ORCLOSE
For DMEXCL
On Sun, Aug 8, 2010 at 3:10 AM, Charles Forsyth fors...@terzarima.netwrote:
Perhaps we could turn on async clunk for other files when the chan has
CCACHE set (mount -C iirc). We already believe that the fileserver is
'decent' then...
that's more plausible, since you've declared that you're
clearly, coraid won't send commandos to make sure that you don't use zfs
with coraid storage.
If they do, will they be from outer space?
-- vs
Hi,
Erik's thread about a 16-processor x86 machine convinced me to try something
related to spinlocks.
The current 9 spinlocks are portable code, calling an arch-provided tas() in
a loop to do their thing. On i386, Intel recommends 'PAUSE' in the core of a
spin-lock loop; I modified tas to PAUSE
Hi,
I've asked about this before, but I still don't see the reason;
In 9/port/sysproc.c:sysrfork(), after a new process has been created, dupseg
is called on each of the donor process's segments; why is the new process's
p-seglock locked for this duration? The new process hasn't been published
On Mon, Jun 21, 2010 at 10:40 AM, erik quanstrom quans...@quanstro.netwrote:
void
lock(ulong *l)
{
ulong old;
ushort next, owner;
old = _xadd(l, 1);
for(;;){
next = old;
owner = old16;
old = *l;
knowing which locks would rock.
i imagine the easiest way to find out would be modify lock() to bump a
per-lock ctr on failure-to-acquire. on i386 lock add would be the easiest
way to do that, i think. add an 'inited' field to the spinlock and a list
linkage as well, to allow for easy examination
Are the canonical sources to 9atom online/web-viewable someplace?
-- vs
erik quanstrom wrote:
/sys/src/cmd/aux/vga/radeon.c uses radeon_pciids in radeon.h.
it ignores the vids and dids in /lib/vgadb. this is probablly a
mistake.
Agreed.
erik quanstrom wrote:
i think it's mainly a question of getting the best graphics
performance. but these days the 2d
On Thu, Apr 29, 2010 at 7:17 AM, erik quanstrom quans...@quanstro.net wrote:
I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
vga and kernel; added line to /lib/vgadb.
Now kernel sees the device (and I see it too: cat /dev/vgactl), but
attempt to start framebuffer gives
Hi,
A few months ago, I added a patch to inferno-npe to use LOCK XADD
instead of the current lock/add/unlock sequence for incref and decref:
(http://code.google.com/p/inferno-npe/source/detail?r=b83540e1e77e62a19cbd21d2eb54d43d338716a5
and
Not that this is a great answer, but the way I've done SMP boot without
parsing either the ACPI or MPS tables was to issue broadcast init and
startup IPIs, rather than targeted ones. All the CPUs in an i7-based machine
came up, fwiw...
-- vs
Hi,
In Russ Cox's and Sape Mullender's 2008 IWP9 paper on semaphores in Plan 9,
they suggest that semaphore (semacquire/semrelease)-based locks in libc were
better than the current spinning ones; they note that the locks would be
replaced in the distribution soon.
Is that still in the cards?
--
What is /sys/src/cmd/fossil/xx?
-- vs
Not quite what I was asking; I was asking about lock() / unlock() in libc
being changed to use semacquire/semrelease (the syscalls)...
-- vs
On Wed, Mar 3, 2010 at 6:40 PM, David Leimbach leim...@gmail.com wrote:
What's the current state of the following:
...
3. Cpu from Inferno to Plan 9? (i think this might be in npe's inferno
fork)
...
Yep, its there. :D
-- vs
On Sat, Feb 6, 2010 at 11:16 AM, erik quanstrom quans...@quanstro.net wrote:
ilock() (pc/lock.c) calls splhi() and then calls lock(). If that lock were
contended,
how would the system not stop? And on a UP system, if you're inside an
splhi() block,
why would you need to take an uncontended
Perhaps the time to talk about QTDECENT is at hand?
-- vs
Hi,
If I'm writing a library and I'd like to use procdata, is there any
way to safely do so, considering that applications using the library
might be using procdata as well? Perhaps it should take a key, like
pthread_getspecific/_setspecific?
Thanks,
-- vs
On Sun, Feb 7, 2010 at 5:42 AM, Charles Forsyth fors...@terzarima.net wrote:
I guess I wasn't clear; what I was asking was why it was safe to
attempt to take a lock when splhi() at all.
because such a lock is always taken with splhi, using ilock.
you might find in older code the use of lock
Hi,
I was looking at the sources to kenfs and saw something that confused me -
ilock() (pc/lock.c) calls splhi() and then calls lock(). If that lock were contended,
how would the system not stop? And on a UP system, if you're inside an splhi() block,
why would you need to take an uncontended
Hi,
I guess I wasn't clear; what I was asking was why it was safe to
attempt to take a lock when splhi() at all.
On a UP, if that lock is contended and interrupts are off, you'll
lockup, no? (The timer interrupt handler will never run, reschedule
will never happen, the lock holder will never
Hi,
I am working on a 32-bit microprocessor-on-an-FPGA; anyone know
what'd be involved in retargeting 8{al} (or friends) to a new
CPU? Where is the line between what 8a and 8l do? (which is
responsible for the pseudoregisters? instruction selection?)
Thanks,
-- vs
Hi,
I started mirroring /sys/src and /sys/include into an hg repository regularly,
usually daily. The tree is available at http://code.google.com/p/plan9os.
hg clone https://plan9os.googlecode.org/hg/ plan9 should do the trick to clone a
copy.
Hopefully this will be useful,
-- vs
On Mon, Jan 11, 2010 at 01:01:43PM +, Steve Simon wrote:
Interessting idea. Do you use a fossil only configuration and
mirroring with fs(3)?
I use fossil and venti with everything mirrored with fs(3) - each partition.
Hi!
An alternate configuration, which takes more memory, but might
On Mon, Jan 11, 2010 at 10:22:49AM -0500, erik quanstrom wrote:
An alternate configuration, which takes more memory, but might offer
a bit more in the way of survivability, would be to not use fs for venti.
Instead,
run one venti daemon per disk, with independent arenas/indexes. Insert a
On Mon, Jan 11, 2010 at 12:24 PM, erik quanstrom quans...@coraid.com wrote:
Venti deals with incompletely written blocks; the arenas and index structures
are still workable. The situation is even recoverable - a proxy could notice
that one of the backends failed to return a read, so it rewrite
Hi,
In _allocb() in port/allocb.c, there is an _xinc(b-ref) on a long
inside the Block header. No one else ought have a pointer to this
block yet, seeing as its not done being allocated. Is there any reason
a locked increment is being used?
-- vs
On Tue, Dec 8, 2009 at 7:05 PM, ge...@plan9.bell-labs.com wrote:
I've just pushed out a small change to /sys/src/9/pc/realmode.c that
allows monitor=vesa to work on multiprocessor pcs without *nomp being
defined in plan9.ini (i.e., you can use all available processors [or
cores] and still use
Hi,
I have constructed a standalone package of Sam (command-line half only) for
UNIX, for systems that you don't want to / can't build Plan 9 Ports for and
wish to connect to with samterm via ssh.
http://grex.org/~vsrinivas/src/sam.tar.bz2
I extracted enough of lib9/libkern, libbio, and
Hi,
I've gotten and graphed a quick trace of all requests in-kernel to poolalloc
during a session with my terminal, where I booted up, created a few
windows, built a kernel, and shutdown.
http://grex.org/~vsrinivas/p9malloc-traces/
(There's even some eye-candy!)
Quick summary: 50% of all
http://www.peereboom.us/epitome/
-- vs
The other (Byron Rakitzis) unix port of rc can be linked against
either readline or editline.
-- vs
Hi,
Thanks to everyone who attended and to Erik Quanstrom and Coraid for a rockin'
IWP9.
-- vs
Hi,
For those of us traveling to IWP9, what are recommended ways to get
from Atlanta to Athens? We were likely going to Atlanta by train...
Thanks,
-- vs
Hi,
In order to construct an authenticated mount of sources, you will need
to start factotum, use srv -a to create an auth-ed connection to the
server and to post it, and to mount the posted connection.
(assuming you have a working plan9port install and are on a unix):
$ 9 factotum
(start
So in my example, va = 0x10001001, len = 0x1000. I understood that to
mean [0x10001001, 0x10002001) was the newly-valid interval, which
would mean 0x10002000 was a valid address...
The segattach manpage says va+len is 'rounded up'; wouldn't that mean
the expanded interval was [0x10001000,
Hi,
This little program:
#include u.h
#include libc.h
#define SEGBASE ((char *) 0x10001001)
#define SEGSIZE 0x1000
void main(void) {
segattach(0, shared, SEGBASE, SEGSIZE);
// Works fine (writing to 0x10001fff)
*(char *) (SEGBASE + SEGSIZE - 2) = 'a';
// Suicide! (writing to
Hi,
I executed the fossil 'sync' command when my terminal was under
moderate I/O load earlier today. Fossil seems to have locked up. Has
anyone seen anything like this?
I have a dump of the first 256mb of kernel memory and all physical
memory. Are there any structures that are kept at reasonably
On Sun, Sep 6, 2009 at 11:54 AM, erik quanstromquans...@quanstro.net wrote:
I executed the fossil 'sync' command when my terminal was under
moderate I/O load earlier today. Fossil seems to have locked up. Has
anyone seen anything like this?
The locking I can see along the path of 'sync' is
Thanks!
How long has the current sources server been running?
-- vs
On Sun, Aug 30, 2009 at 1:07 PM, erik quanstromquans...@quanstro.net wrote:
Simple example: file systems on Plan 9 are slow. Why is that? How do
they work? How would you go about finding out how to make them faster?
which ones? there are quite a number to choose from.
i've found that ken's
On Fri, Aug 28, 2009 at 4:54 AM, hiro23h...@googlemail.com wrote:
perhaps we should try to boot plan 9 from a linux kernel? Sounds great to
me...
this probably makes me a troll...
I hear ron minnich did that with his lguest port. Does that make him a troll?
-- vs
Did you use the plan 9 kencc to build that inferno kernel? As I
understand, inferno's 8c doesn't have the H5 option...
-- vs
On Tue, Aug 25, 2009 at 8:08 PM, erik quanstromquans...@quanstro.net wrote:
Any chance this is related to the issues we discussed on #plan9?
No, I'm pretty sure not. This dealt with a relatively rare case, a
filesystem with an optimal read size larger than a constant in the
Venti source. The
I'm having trouble with venti's tools, creating an arena partition
greater than 89.6GB... anyone seen anything like this before?
m...@centaur:~/u% dd if=/dev/zero of=arenas bs=1024k count=1 seek=89500
worked
m...@centaur:~/u% dd if=/dev/zero of=isect bs=1024k count=1 seek=4900
worked
Hi,
I'm using unvac to try to extract some vac archives I made in the fall
of 2008. I'm running into a pair of problems.
First, unvac is outputting directories with the write bit off. This
causes it to fail pretty early, as it can't write files to the
newly-extracted directories. Is this
Hi,
Plan 9's venti/copy has an undocumented -m option. What does it do?
Thanks,
-- vs
Hi,
I have a few score trees in Venti that p9p's venti/copy wouldn't copy,
but p9's would. venti/copy aborted with:
copy: reading block (type
16): read asked for got
da39a3ee5e6b4b0d3255bfef95601890afd80709
P9's
Thanks for the answer,
In p9's venti/copy, in scoretreecmp, there are two casts, from Avl* to
ScoreTree*; this depends on scoretree's avl being the first member of
the structure; I thought kencc was allowed to reorder structure
members, is that the case?
Thanks,
-- vs
Hi,
Do any of you still use dump9660? Any recent experiences or stuff I
should watch out for using it?
Thanks,
-- vs
Hi,
How come you can't TWalk along an open Fid?
Thanks,
-- vs
I believe that the bug that people have been having with vac and venti
in p9p (create bsize 8192 psize 8160vac: vacfscreate: vacfileroot:
read too small: asked for 0 need at least 389) can be fixed by this
change:
(in plan9port/src/libventi/fcall.c:185), change f-count = (buf[2]
8) | buf[3]; to
Hi,
I noticed that p9p has threadpin() and threadunpin() in its thread
library... they claim to make the current thread the only one runnable
in this proc. I'm failing to see the purpose of these... a thread is
not subject to preemptive scheduling, it can achieve the same effect
by not calling
Hi,
Has anyone had any success setting up aux/sshserve on Plan 9? I've
used aux/ssh_genkey, but have had no luck getting the server to accept
connections...
Thanks,
-- vs
On Wed, Jun 24, 2009 at 7:39 PM, erik quanstromquans...@coraid.com wrote:
So I went ahead and reinstalled fossil and venti--this time I went
with a RAID-10 configuration on the Coraid.
for data integrety, raid 5 is a better solution because
on a raid 10, if one block is wrong, it's a coin
mtrrs work on any number of processors. it is plan 9's
vesa which does not.
Is this just because the driver uses realmode()? Or is there something else?
To solve the realmode() problem, we could link rsc's 8i into the
kernel and use that to execute the vesa bios code, right?
-- vs
Inside plan9port/src/cmd/venti/srv/lump.c, in readlump(), could you
check that the score being read is a sane one? (not the zero-score)
Just printing it out for now would be enough.
Thanks,
-- vs
% unvac -t vac:8ab4746b0fb06da481158624afb7509cefc35e07
unvac: vacfsopen: read too small 1: asked for 0 need at least 300
% venti/copy 'tcp!localhost!17034' 'tcp!localhost!17034'
vac:8ab4746b0fb06da481158624afb7509cefc35e07
venti/copy: reading block
On Thu, Jun 11, 2009 at 11:00 PM, J.R. Maurojrm8...@gmail.com wrote:
I can't help with this in particular, but QEMU does some really
low-level hackery to the point where it wouldn't compile with GCC 4,
so it's possible something like that is going on here.
Thankfully, this is no longer true.
1 - 100 of 130 matches
Mail list logo
