> MBR...PBS1...Bad Format or I/O error
> Press a key to reboot...
I also had this issue with Openbox-ubuntu-core2duo-ich9/ahci-sata, although
it was intermittent, sometimes it would barely work (painfully slowly) clear
into the part where I was looking for a distro to copy. I dont mean just
"pain
On Mon, Jan 10, 2011 at 4:26 PM, a z wrote:
>> MBR...PBS1...Bad Format or I/O error
>> Press a key to reboot...
>
> I also had this issue with Openbox-ubuntu-core2duo-ich9/ahci-sata, although
> it was intermittent, sometimes it would barely work (painfully slowly) clear
> into the part where I was
Hello all,
I just posted this golang-nuts. I would like someone to advise on what
needs to be done to install
Google Go on The Plan 9 Operating System.
Can Federico G. Benavento [FGB] please help?
I've searched for ages on the net but can't find any info.
So far have the following (with the aid o
I want to build Plan9 from scratch under Windows/*NIX.
I built working (seems :) toolchain (yacc, 8a, 8c, 8l) under Windows
XP using Open Watcom Compiller.
Has anyone done something similar?
run:
% 9fs sources
% /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
% contrib/install -f bichued/python
% contrib/install -f fgb/hg
that should work
On Mon, Jan 10, 2011 at 7:01 AM, ROuNIN wrote:
> Hello all,
> I just posted this golang-nuts. I would like someone to advise on wh
On Sunday, January 9, 2011, ron minnich wrote:
> On Sun, Jan 9, 2011 at 1:38 PM, Bakul Shah wrote:
>
>> I didn't say plan9 "suffers". Merely that one has to look at
>> other aspects as well (implying putting in Tstream may not
>> make a huge difference).
>
> well, what we do know from one set of
I think it's fair to say that the IO path for fossil is
> considerably slower than the IO path for kernel-based file systems in
> Linux: slower as in multiples of 10, not multiples. There's a fair
> amount of copying, allocation, and bouncing in and out of the kernel,
for common applications you'd
I don't believe there is a way to build go on plan9. You have to build it on a
Linux box. Then compile go programs on the Linux box and run them on Plan 9. If
you use drawterm your Linux fs will be accessible via /mnt/term
-Skip
On Jan 10, 2011, at 10:01 AM, ROuNIN wrote:
> Hello all,
> I jus
>
> Right, my results were that you get pretty much exactly the same
> performance when you're working over a LAN whether you choose streams
> or regular 9P. Streaming only really starts to help when you're up
> into the multiple-millisecond RTT range.
This is weird. Didn't read the thesis yet, so
I'm curious: do you plan on executing the output of 8c and 8l in an
environment as strange as one the you are building in? You could try
building only programs and then try executing those, i.e., by using
one of
http://www.chunder.com/plan9/9ee.html
http://swtch.com/9vx/
If you just want an x86
i assume you know about 9pm for win32 and p9p for bsd/linux/osx. not
sure why you want to duplicate them. it would be more useful to port
p9p to win32.
-Skip
On Mon, Jan 10, 2011 at 2:01 AM, Artem Novikov wrote:
> I want to build Plan9 from scratch under Windows/*NIX.
> I built working (seems :)
What bandwidth? With a gbit I could notice a difference. But probably
the fault of the linux v9fs modules I used (half usec RTT).
On 1/10/11, Francisco J Ballesteros wrote:
>>
>> Right, my results were that you get pretty much exactly the same
>> performance when you're working over a LAN whether
> I want to build Plan9 from scratch under Windows/*NIX.
> I built working (seems :) toolchain (yacc, 8a, 8c, 8l) under Windows
> XP using Open Watcom Compiller.
> Has anyone done something similar?
a few years ago, using the Inferno compiler suite, I built an
environment on Solaris/sparc to cross
On Mon Jan 10 13:50:09 EST 2011, 23h...@googlemail.com wrote:
> What bandwidth? With a gbit I could notice a difference. But probably
> the fault of the linux v9fs modules I used (half usec RTT).
>
could you perhaps have intended 0.5ms, not µs? here's mellanox
bragging about 4µs latency for 10gb
I was using a slightly weird configuration, partially because it's the
hardware I had available, and partly because I thought it might more
adequately represent a typical internet connection. On one side of the
Linux bridge was a 10 Mbit hub, on the other side, a 100 Mbit switch.
The average laten
There is a fast and dirty jtagfs now, with two files so that people
can play with it.
This is the kind of things it can do, though there are no breakpoints yet:
usb/serial
echo b115200 s15 l8 pn > /dev/eiaU5.1/eiaUctl
window -m
con /dev/eiaU5.1/eiaU
kill 8.tagfs|rc
/usr/paurea/src/jtag/jtag/8.
i cleaned up the code i wrote to make installing a new file server
a bit easier. pull contrib quanstro/fs again and read mkfsconf(8).
there is an example configuration in /sys/src/fs/wrens/conf, complete
with a plan9.ini, this is the edited (so cavet emptor) configuration
installed on saturday.
i
Hi all
I am testing the non-block socket of ape/plan9 the code below seems to
succeed in making a non-block sockets on unix, but not in plan9/ape it
still blocks with no error from fcntl.
Is this intended?
/* A simple server in the internet domain using TCP
The port number is passed as an ar
isn't this the intended behavior?
lotte% 8.out 777
NON BLOCK Succeeded
Here is the message: hola
from a different window:
lotte% telnet tcp!localhost!777
connected to tcp!localhost!777 on /net/tcp/20
hola
I got your messagelotte%
On Mon, Jan 10, 2011 at 10:31 PM, Fernan Bolando
wrote:
> Hi al
I need to apologize, my sample code made things more confusing.
In unix the code I posted would have raised an error because
newsockfs=accept()...would not block and just pass through. The idea
is you can loop through accept() and multiplex multiple inputs.
but in plan9/ape it works just as how y
it's not fcnlt's fault, ape replaces your sockfd with a pipe
when you do listen(), you could call fcntl again after the
listen() call...
all this is usually combined with select() which in turns does
more magic behind the scenes and this behavior isn't
exposed.
On Tue, Jan 11, 2011 at 3:53 AM, Fe
hell-o.go is like hello.go but uses println. 8.hell-o works properly
on a plan9 cpu. but it faults when running on 9vx. i built vx32 --
including 9vx -- on a linux/x86-64 from sources in the last couple of
days.
% 8.hell-o
8.hell-o 270: suicide: sys: trap: page fault pc=0x10bc
/dev/kprint rep
22 matches
Mail list logo
