I tried putting our index on a single OCZ SSD and it died during buildindex.
The SSD was completely unresponsive thereafter, which is pretty
appalling behaviour for a storage device. Having since sworn off
OCZ, I would try again with a pair of Intel 330s in a RAID.
We are converting the system to 21-bit runes (also known as 32-bit
runes, but only 21 bits are ever used). The first step will be
pushing out versions of a few commands and library routines that have
been modified to be agnostic about Rune size.
The next step is recompiling the compilers and push
Sorry, `-Fphys' should be `-Pphys'.
The loader code to produce ELF or ELF64 binaries is now consolidated
into /sys/src/cmd/8l/elf.[ch], and it no longer modifies (in
loader-dependent ways) the text-start virtual address to produce a
physical equivalent. In the process, bugs such as incorrect
byte-order header elements were fixed. T
Our building electrical people are shutting off power
to our part of the building from 07:00 EDT Saturday
through about 15:00 EDT, they say. Thus we are shutting
down our Plan 9 systems today, starting at 19:00 EDT.
I'll probably come in Saturday and bring them back up.
9boot(8) is the place to start. 9boot replaces 9pxeload but is more
persistent. 9load and 9loadusb should behave much as the old ones
did, though I hope that the new ones will run on more machines. One
can boot through any PCI ethernet interface for which we have a kernel
driver now.
We are usi
New PC bootstraps and manual pages will be arriving
on sources soon. Highlights include amd64 booting,
using kernel device drivers, better CD booting, and
the ability to run on a wider range of machines.
See the upcoming manual pages for more information.
After you pull, you should see a new directory,
/sys/src/9/teg2. From the _announce file:
This is a preliminary Plan 9 port to the Compulab Trimslice,
containing a Tegra 2 SoC: a dual-core, (truly) dual-issue 1GHz
Cortex-A9 v7a-architecture ARM system, *and* it comes in a case. VFP
3 floating-po
pull, recompile and try again (kill all netssh processes first).
host key verification isn't working so it's been temporarily disabled.
I have fixed various bugs in ssh2; they'll be in the ssh2
on sources once it's all shaken down.
Parallels 6 runs Plan 9 for me.
Actually we have since found that even scheduling archival
and temporary snapshots at different times isn't always
enough to prevent fossil from hanging during archival
snapshots.
The T410 mostly works: ethernet, (vesa) video, lower-speed usb.
It has two EHCI controllers and that seems to interfere with
high-speed usb so far.
Haven't tried wifi but I wouldn't expect it to work.
See ndb(6).
Such programs need to be changed to use a proc rather than
a thread for dialing (or linked with the old version of dial.c
temporarily). Sorry.
Now that the world at large is waking up to IPv6, one problem I kept
tripping over is that dial(2) tries addresses serially, and since it's
not unusual for IPv6 connectivity to be broken, and since DNS servers
randomise the order of IP addresses they return, it's quite possible
to hang for a long t
If signedness matters, I use 1u or 1ul or 1ull. Doing so
will make your examples work as expected.
I don't pretend to understand the ansi rules and don't want
to devote the time to try to decode them.
The problem with the gumstix as a terminal is that
nobody has yet been able to figure why its USB doesn't
work, so though you can get video, it's hard to provide
mouse and keyboard. Plus Gumstix still don't seem to be
selling the aluminum case, so it's a bit delicate to
lug around the world with y
I've just consolidated the several variants of usbehci.c into
port/usbehci.c, and moved usb.h into port. There is now port-specific
ehci initialisation and shutdown code in files with names like
usbehcipc.c. mkfiles and kernel configuration files have had to be
changed; the configuration line for
The Guruplug Display is not vaporware. I ordered one just before
Christmas and it arrived a few days ago. It's a different SoC
than the other plugs use, but I don't expect much trouble porting
to it.
The omap port (/sys/src/9/omap) already runs on the gumstix overo,
though not all peripherals wo
The plugs make fine servers but there is also interest in
a small, portable terminal that boots quickly.
As far as I know, there isn't yet a good, inexpensive, well-documented
ARM system. I tend to prefer the Marvell Kirkwood systems (the plugs)
because they have faster processors, faster and smarter Ethernet
controllers, and somewhat simpler SoCs than the TI OMAP3 systems
(beagle, igep, gumstix). O
They are defined in port/devmouse.c. Did you get an updated
beagle config file when you pulled? You should have.
Sorry, the second line of my recipe should be
for(i in ?[acli])
As you'll see from my talk or paper, the beagleboard
doesn't work yet because it doesn't have real
ethernet and usb isn't working on the omap35 yet,
so even the kludge of ethernet over usb won't work.
Our main file server, after 215 days of up time, started getting
processes stuck in Fauth state and it spread to our cpu servers.
Restarting our authentication server and the main cpu servers
didn't fix it, so I took down the whole complex, turned the machines
off for a few minutes and restarted th
As the documentation says, the ARM ports are currently
only CPU kernels.
Mouse and keyboard support should be trivial to add
and will come once (if) video is working on the Guruplug
Display or OpenRD. This could take a long while, since
the video controller is undocumented (there isn't even
Linux
Insert
.rm CH
somewhere before .TL to turn off page numbers.
I've just pushed out a new tftpd.c that implements the
"blksize", "tsize" and "timeout" tftp options when reading
a file. I've tested it here against a variety of systems,
so I don't expect others to have trouble, but if pxe booting
suddenly stops working, you'll know where to look.
Actually we've had a nand flash driver for the plugs for a while
and I've been using it on the Guruplug.
The kw port now supports the Guruplug Server Plus, including both
Ethernet interfaces, and probably the other Guruplugs. booting(8) now
has the necessary instructions to get started. They are more diverse
than one might like because every version of u-boot we get for a new
board seems to have had
booting(8) has been updated; take a look if you're using an ARM port.
On the Kirkwood SoCs (Sheevaplug and Openrd-client), USB now works.
Nemo was helpful fixing this, as usual.
One of the people here is working on using the Kirkwood crypto
acceleration hardware.
The OMAP3530 port is now availab
What type is `smallnumber'?
If you think that shift operators aren't being translated
to shift instructions, you can examine the output of 8c -S.
x/2 is equal to x>>1 for non-negative integer x; for negative x,
the two expressions may yield different values, even if
x is a signed integer. The book Hacker's Delight, among ot
There are limits on the number of concurrent conversations per
protocol. For UDP, it's currently 1024, for TCP it's currently 1024
on terminals and 4096 on cpu servers. For ICMP, it's currently 128;
you may want to raise that. To find the current limits,
grep '>nc = ' /sys/src/9/ip/*.c
I've just pushed changed kirkwood kernel sources to sources.
The main visible changes are that the kirkwood kernel will now
parse a plan9.ini file found in low memory and will write its
#ec contents there just before a reboot, thus preserving them
for the next kernel. Now that this is possible, th
I'm running timesync here on a sheevaplug and an openrd-client.
The invocation was
aux/timesync -s /net -nl -d /sys/log/timesync.d chips time1 time2
100 µs accuracy seems unlikely; you might try dropping the
`-a 10' from your invocation.
The kbdq business is almost certainly a result
It's still undecided how to best cope with a mixed v4 and v6
world. I don't expect the ipv6 attribute to go away.
/cron/sys/cron is now in /dist/replica/plan9.proto.
--- Begin Message ---
> see the realitively
> new /cron/sys/cron:
No /cron/sys/cron on my system. It's not in /dist/replica/plan9.proto
so it doesn't get distributed from sources. Should it?
--- End Message ---
Can you provide more details of your `ipconfig ra6 recvra 1' failure?
What happens? What's printed? What's in /sys/log/v6routeradv (you
may have to create it first)?
It's not worth supporting any new 10Mb ethernet controllers,
and new 100Mb ones are borderline.
Sorry, I'd forgotten to push /sys/src/9/kw/sdscsi.c to sources.
It's fixed now.
usb has advanced a little; we can see usb devices now but attempts to
read or write them hang. I don't know of progress on flash access or
anything else.
nfsserver only serves NFS version 2 and not all clients are smart
enough to try multiple NFS versions, so you may have to specify it,
typically like this (in /etc/fstab):
nfs:/ /n/9nfs nfsvers=2,proto=udp,user,bg,intr
or as a command:
mount -o bg,intr,-2 thinktank:think
Or you could just type
abaco
or, better,
readweb
See abaco(1).
Yes, we only support the 16-bit runes of Unicode plane 0. That really
should be enough space, except for bungling by the Unicode Consortium.
I've extended old code using lex to accept utf by massaging the input
stream, before lex sees it, to parse utf and encode non-ascii Runes
into '\33' (escape) followed by 4 hex digits. A simple lex rule then
decodes for the benefit of yacc.
This encodes:
/*
* lex can't cope with character sets w
These drivers appear to be for pre-pci ([e]isa or vlb) vga cards:
vgaark2000pv.c
vgact65545.c
vgaet4000.c
I think that these are excellent candidates for removal. Are any of
you still using these drivers? If so, could you try using
monitor=vesa instead and see if that's acceptable, and let me k
Remember that, on the pc, you should always be able to revert to
monitor=vesa and indeed aux/vga attempts that if it can't recognise
your graphics controller, but it can fail if you're trying to use a
non-vesa resolution. It even works on multiprocessors now.
aux/vga -m vesa -p >/tmp/vesa
These two scripts should be enough to do what's needed:
; cat /bin/xargs
#!/bin/rc
# xargs cmd [arg ...] - emulate Unix xargs
# only needed for arg lists longer than TSTKSIZ*BY2PG
# (100*4096 = 400K on typical PC kernels).
rfork ne
ramfs
split -n 500 -f /tmp/x
for (f in /tmp/x*)
That's the wrong fix; ethernet drivers should always call
etheriq(edev, block, 1);
The sole exception is in devether.c.
--- Begin Message ---
Is anybody else currently using the ethervgbe driver? I'm had some
problems with it which don't seem to be caused by my hardware.
Sources has the latest USB source, no USB code is being held back.
I don't have enough experience with VirtualBox to make a sensible
comparison.
The thing that none of the VM monitors seem to offer (though I'd love
to be proven wrong) is debugging tools for the guest operating
systems. This is odd, as it was one of the major uses of VM/370. So
if a guest kernel
Yes, Plan 9 runs on Parallels 4 and 5, with or without video.
Richard Miller supplied a quick fix and a nicer fix.
The quick fix is in 9/kw/clock.c on sources now and
the nicer fix will follow.
Once you have this fix in your kernel, it's safe to
run aux/timesync.
I think it's just the idiom we adopted when we added reference
counting.
As far as I can tell, yes, that's all it took.
The old code had been turning off the old 8259 interrupt controllers
used by uniprocessors but didn't disable the lapic on mp systems.
--- Begin Message ---
On Tue, Dec 8, 2009 at 7:05 PM, wrote:
> I've just pushed out a small change to /sys/src/9/p
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 vesa mode). I've also pushed out new kernels, so
the distribution bui
I ordered an openrd-client from globalscale and it arrived within
a few days. It's the same SoC (Kirkwood) as the Sheevaplug, but more
(perhaps all) of the connectors are made available, plus vga output for $250.
Looking at mine, I see connectors for 7 usb 2 ports, 2 Gb ethernets,
esata, SMbus, sy
The slowness of loading openssl probably has something to do
with it being bloatware on a par with ghostscript.
There are two distinct issues: booting from USB devices and
partitioning USB devices. I believe that if you follow the directions
at the end of prep(8), you have a modern BIOS, and it isn't too buggy,
you should be able to boot from a FAT file system on a USB device
(that is, load a kernel from it
I just rediscovered that aux/timesync seems to freeze the stock 9plug
kernel. I don't yet know why. I worked around it weeks ago in
/bin/cpurc with this:
if (! ~ $sysname feared openrd) # timesync seems to kill /sys/src/9/sheeva
if(! ps|grep -s timesync) {
aux/timesync -n pool.ntp.org
/acme/bin/arm is already in the distribution. It's empty because we
only ship binaries for the 386 architecture (and that's only so that
installations can bootstrap themselves using PCs). You might want to
add to my earlier instructions:
cd /acme
objtype=arm mk install
If you run replica/pull (or have done so recently), you'll find a new
kernel subtree, /sys/src/9/kw, which contains a basic port of Plan 9
to the Sheevaplug, derived from the port of native Inferno. 9plug is
a diskless cpu server supporting a serial console and gigabit
ethernet. booting(8) and /s
I'd like to make the sheevaplug port available soon.
We've hit a bug in the latest 5c or 5l and I'd like
to wait for that to be fixed first. The initial port
was not done on a stock kernel, and adapting it to a
stock kernel produced a less reliable port (probably
my fault). I think I've just fixe
The cortex-a8 arms are arm v7-a architecture. L2 page table
entries have changed format. The a8 includes trustzone, so
many registers have forked, producing a "secure" and a "nonsecure"
version of the register. The arm v7-a manual is a 2,150-page pdf
file and the omap35x SoC manual is a 3,500-pa
The beagleboard is somewhat painful. It has a cortex-a8 cpu,
which is quite a bit more complex than older arms. The lack of
built-in ethernet means that getting USB going is vital, but the
EHCI registers provoke access exceptions and the OTG registers
are like no USB interface we've ever seen bef
The current sources server hasn't been in service for very long.
It's about the third one that I know of, and there may have
been others. In the past, we just replaced the machines, as
they died or became unreliable, with other machines that we
already had. Haggis is a new machine and it's using
I plan to replace sources with haggis (which will take the name
sources) during the afternoon of Tuesday, Sept. 8th. I will take a
final dump of sources, shut it down, change the dns, initialise
haggis's sources fossil from source's final dump score, and bring
haggis up as the new sources. This s
I've got a replacement for sources set up. It's a new machine (an
Intel Core 2) named haggis.cs.bell-labs.com and should look like a
slightly-old copy of sources.
Please try it out and see if it looks like sources from your
perspective. You may want to change your authdom declaration for
outside
It's not documented in a manual page, I think you have to read
/sys/doc/lp.*, section 4.
The final `FIFO' in the scheduler column of /sys/lib/lp/devices
has been optional for a while. Everybody uses FIFO now, so it's
the default.
Plan 9, including vga, runs fine in Parallels 4.
The new vesa driver will only use mtrrs if the cpuid
instruction says that they exist.
Sunday afternoon (EDT), August 2nd, we'll move the Murray Hill Plan
9 systems back into our newly-renovated machine room. Plan 9 will be
unavailable for some of this time.
Installing off floppy has been seriously suboptimal for a long time.
It's probably time to finally kill it. Surely no one still has
a machine with a floppy drive but no cd nor dvd drive.
I've just rebuilt /n/sources/plan9/386/9*load* from
/n/sources/plan9/sys/src/boot/pc.
I've just pushed out kernel sources and binaries to incorporate
Aki's mtrr and vesa changes. The combination makes monitor=vesa
run quite a bit faster; we saw a factor of three speed improvement
in one case.
It's still limited to a single processor, but we've got someone
investigating ways to fix
I forgot to mention one incompatible change in the
new kernel source: the cpuid function now takes different
arguments: a function code and a 4-word array in which
registers ax—dx are returned.
In principle you can boot from usb devices using "bios0" or
"sdB0" as boot methods; see 9load(8). In practice, BIOS bugs
may get in the way, but it's worth trying.
I've just pushed out to sources a new USB implementation, courtesy of
nemo, who debugged and repaired our old UHCI and OHCI drivers, wrote a
new EHCI driver for USB 2, converted the user-mode drivers in /bin/usb
and tested it all, among other things. Thank you, nemo.
I've updated on sources at le
Ignore the complaint about the BIOS; it's a red herring. Lots of
BIOSes have bugs that prevent 9load from booting through them, but
unless you're attempting to boot from bios0 or sdB0, 9load is not
using the BIOS to boot.
Taking the wiki's advice and specifying in plan9.ini
mouseport=ps2intellimouse
cures the middle-button problem.
I've just finished pushing out to sources changes to 9load to allow it
to boot load via the emulated Realtek 8029 of Parallels 4. These
changes should appear in tonight's CD image. One can thus boot
diskless Plan 9 systems via PXE in emulation.
You may find that you need to configure within Para
Setting ifs='' defeats rc's tokenisation, so the result
of `{} will be a series of rc `words', each limited to
Wordmax (8192) bytes and with the next byte of the input
stream after each word set to NUL.
Did you perhaps intend to write ifs=(), which has different
meaning?
Sorry about that. I've reverted to the older readpng.c.
The new one shouldn't have escaped yet.
The new one was an attempt to fix bugs in the old one
(there are some png files that the old one can't handle
correctly), but the new one has its own bugs.
We're suffering machine room renovation, major electrical
work and high winds. As a result of some combination of these,
we've had two major power outages and three minor ones today.
As a result of moving machines around recently, we hadn't had
all of our networking equipment and our computers on
I've turned it back on and will watch to see if our web server gets
swamped by it. This interface should not be used to mirror the
contents of sources.
The new vac has been misbehaving and we haven't yet
found the bug(s), so I've reverted to the previous vac,
which didn't include unvac. I'll break out the unvac
source from the new vac and put it on sources.
It's back now; we rebooted the venti server and sources.
I have one in a Plan 9 terminal, driving a Dell 2407WFP at 1920x1200x16.
pci -v reports:
1.0.0: vid 03.00.00 10de/00c3 11 0:dc00 16777216 1:c00c 268435456
2: 16 3:dd04 16777216 4: 16
NVIDIA
The label on the box says "GF 6800 XTreme 256MB DDR3 DUAL DVI TV PC
You don't want to use an amd29k (even if you could get one).
They look cute on paper but their freeze-mode interrupt
handling is a Chinese puzzle and unless you use Ken's compiler
(previously called 9c), you're stuck with register windows,
which tend to need to be spilled when an interrupt occurs,
No, we don't publish venti scores; that would be very
poor security practice.
We'll soon be announcing a way to mirror sources with replica,
once we've shaken the procedure down. We will then discourage
the existing mirroring schemes.
I've just pushed new 9load and kernel binaries to sources.
The places that DMAPPEND is used most commonly are log files and mail
boxes. In both cases, I don't want the decision of whether to
truncate or append left to the whims of some program. I want writes
to append, by god, and DMAPPEND on actual disk-based file servers such
as fossil and fs does that
Won't srvfs (see exportfs(4)) do what you want (packaging up a
namespace)?
Browsing the source via http is disabled again, probably temporarily.
I'm looking into what's consuming (or limiting) the bandwidth on our
internet connection and into improving the performance of our outside
web server.
It's working again. A script that had been working for years suddenly
needed $variable changed to $"variable. I'm not sure why it worked
previously.
There are several models of Soekris machines. We bought the 5501s,
and they each have 4 VT6105M Ethernet interfaces, which aren't stellar
but seem to be okay.
ipifc or ipmux, described in ip(3), are probably worth looking at.
6in4(8) is an example of a program that uses both to encapsulate ipv6
i
stat(5) specifies exclusive-access files, which we do use for locking.
In what sense is that not `doing locking'? It's not POSIX byte-range
read- or write-locking per fcntl, but it's not clear to me how often
that's actually useful. In quite a few situations, having a single
process directly acce
Sources is back up. We had a power outage and some of our machines
didn't come back up automatically, though they usually do.
I've turned off the ability to browse the Plan 9 sources
on our external web site, because it was being overwhelmed
by web crawlers. Each access spawned a command that ran
multiple seds, etc. I've added restrictions to our robots.txt
to prevent crawling the sources and instructed google to
crawl
Sorry about that. We're soaking a version of the kernel that includes
a reference count in the Block struct. It's so far used by the
Ethernet drivers, IP stack and USB code, and usbohci.c escaped a
little too early.
I've just pushed out a newer allocb.c to sources that initializes the
refence co
1 - 100 of 118 matches
Mail list logo
