> Is anyone else seeing this? I'm running bleeding edge labs code,
> compiled from a pull from this afternoon. (And I have been running
> very up-to-date labs pulls all the way along.)
The dns failures occur this side too, once, sometimes a few times a
day. The responsible party is the auth/cpu
btw, what did traceroute output on your linux system show (i.e. traceroute
)
On Mon, May 26, 2014 at 6:51 PM, Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:
> the firewall here wont answer pings.
>
> you could check with netstat on your plan 9 and/or traceroute from your
> linux system.
2014-05-27 0:01 GMT-04:00 有澤 健治 :
> Yan,
>
> probably, your host is waiting message from the "dial".
> simple program such as "dial" is useful for getting diagnostic.
> I have similar program named "connect" which is also useful
> for connection relay and long been used for may server.
> take a lo
Yan,
probably, your host is waiting message from the "dial".
simple program such as "dial" is useful for getting diagnostic.
I have similar program named "connect" which is also useful
for connection relay and long been used for may server.
take a look at
http://plan9.aichi-u.ac.jp/netlib/cmd/
Ke
Try rdline in Kirara package.
http://plan9.aichi-u.ac.jp/netlib/
On 2013/10/10, at 0:53, Steve Simon wrote:
> Hi all
>
> It has long been an irritation that Brdline returns failure (to match the
> end of line token) at end of file if the file does not end with a newline.
>
> This is correct but
2014-05-26 23:02 GMT-04:00 Bakul Shah :
> Does
>
> 9fs localhost
> ls /n/localhost
>
> work on your VM? If that works, and if you can ping in both directions,
>
these tests work on my system
> the other possibilities are
> a. firewall rules on the linux box or
> b. how you have set up your VM. If
Does
9fs localhost
ls /n/localhost
work on your VM? If that works, and if you can ping in both directions, the
other possibilities are
a. firewall rules on the linux box or
b. how you have set up your VM. If you are using it in the "bridge" mode, it
should work (except for a.).
sure.
cat ndb
ip=192.168.122.71 ipmask=255.255.255.0 ipgw=192.168.122.1
sys=super
dns=192.168.122.1
cat netstat
tcp 0bootes Listen 5640 ::
tcp 1bootes Listen 5670 ::
tcp 2none Listen 1100 ::
can you supply the output from your cpu?
% cat /net/ndb
% netstat -n
On Mon, May 26, 2014 at 7:18 PM, yan cui wrote:
> plan9 auth+cpu+file server runs on vm,
>
> $ telnet 192.168.122.71 564
> Trying 192.168.122.71...
> Connected to 192.168.122.71.
> Escape character is '^]'.
> Then, no respons
plan9 auth+cpu+file server runs on vm,
$ telnet 192.168.122.71 564
Trying 192.168.122.71...
Connected to 192.168.122.71.
Escape character is '^]'.
Then, no response.
2014-05-26 21:51 GMT-04:00 Skip Tavakkolian :
> the firewall here wont answer pings.
>
> you could check with netstat on your
the firewall here wont answer pings.
you could check with netstat on your plan 9 and/or traceroute from your
linux system. btw, does your plan 9 cpu run in a vm? also does telnet on
the linux system behave the same way as your dial? e.g.
$ telnet 564
On Mon, May 26, 2014 at 6:30 PM, yan cui
interesting.
I also dial tcp!www.9netics.com!http, but failed. Actually,
I cannot even ping it successfully. (other sites such as www.google.com can
be pinged on my system.) By the way, if fossil uses another ip, how to find
that?
2014-05-26 20:52 GMT-04:00 Skip Tavakkolian :
> works here (see b
OK, will try that. Thanks!
2014-05-26 20:13 GMT-04:00 Nick Owens :
> yan,
>
> did you try to use packet capture software like wireshark, or snoopy(8)
> on plan 9, to see the packets?
>
> running wireshark on linux, and snoopy on plan 9, will give you insight
> into if the packets reach the other
works here (see below). i wonder if fossil is announcing on a different ip
than you're expecting?
% 9c dial.c
% 9l -o dial dial.o
% ./dial tcp!www.9netics.com!http
GET / HTTP/1.0
HTTP/1.1 200 OK
Server: Plan9
Date: Tue, 27 May 2014 00:50:46 GMT
ETag: "364d3v1b"
Content-Length: 2682
Last-Modified:
On May 26, 2014, at 4:47 PM, Steve Simon wrote:
> Just thought I would ask, 9pccpuf is not built by the labs
> so you would need to rebuild it by hand.
It's not rebuilt, which is a shame, since I'm pretty sure this must be the
kernel they run on their file servers.
If not, I would really like
yan,
did you try to use packet capture software like wireshark, or snoopy(8)
on plan 9, to see the packets?
running wireshark on linux, and snoopy on plan 9, will give you insight
into if the packets reach the other side successfully.
On Mon, May 26, 2014 at 08:06:21PM -0400, yan cui wrote:
> Hi
dial.c has been attached.
2014-05-26 20:06 GMT-04:00 yan cui :
> Hi all,
>
> I used a program to dial from one system to another system, but
> it gives a connection time out error. I have searched on Internet for a
> long time and cannot get a solution. Could you please provide some
> sugges
Hi all,
I used a program to dial from one system to another system, but
it gives a connection time out error. I have searched on Internet for a
long time and cannot get a solution. Could you please provide some
suggestions or hints? Basically, one system is Linux based system with rc
shell ins
Ok,
Just thought I would ask, 9pccpuf is not built by the labs
so you would need to rebuild it by hand.
worth a try.
-Steve
On May 26, 2014, at 4:41 PM, Steve Simon wrote:
> I have to ask, when you rebuilt everything, you did rebuild
> 9pccpuf as well didn't you? i.e. its not the lack of he new
> nsec() systemcall biteing you is it?
No, I carefully did the Macarena around that mess ;-)
--lyndon
signature.asc
Des
I have to ask, when you rebuilt everything, you did rebuild
9pccpuf as well didn't you? i.e. its not the lack of he new
nsec() systemcall biteing you is it?
-Steve
For the last couple of days I have been plagued by many many diagnostics from
checkpages(), in conjunction with things like:
rc: note: sys: trap: fault read addr=0x0 pc=0x000101c4
rc 50675: suicide: sys: trap: fault read addr=0x0 pc=0x000101c4
The kernel print buffer holds corresponding entr
On Mon May 26 16:32:54 EDT 2014, cinap_len...@felloff.net wrote:
> excellent :)
why, do you plan a plan 9 botnet that exploits this hole :-).
- erik
excellent :)
--
cinap
On Mon May 26 16:10:59 EDT 2014, cinap_len...@felloff.net wrote:
> theres a bug in devproc again.
>
> the fd is not bounds checked for the "close fd"
> procctl command and the "closefiles" command misses
> the last fd as it iterates from:
good catch. appled patch to 9atom.
- erik
theres a bug in devproc again.
the fd is not bounds checked for the "close fd"
procctl command and the "closefiles" command misses
the last fd as it iterates from:
fd=0 to maxfd-1 and not to maxfd in procctlclosefiles()
static void
procctlcloseone(Proc *p, Fgrp *f, int fd)
{
Chan *c;
so, i've done a little bit more work characterizing the performance
of the scheduler correctness changes, and i know have some understanding
on why e.g. ping times are a bit slower.
the old code essentially let processor 0 spin in runproc, other processors
called
halt. the new code uses monmwait
> Where does the installer script live?
the usb installer is in /sys/lib/dist/amd64. the part that runs at boot is in
the install directory. i think the bug is in the vga script in that directory.
(not to be confused with aux/vga.) it may not do the right thing if there
are no edids.
> > a pro
On Mon, May 26, 2014 at 3:19 AM, erik quanstrom wrote:
>> It proceeded to show me a list of resolutions (8 different options).
>> Since my monitor has the highest resolution of 1920x1080, I selected
>> that. Next it asked for "image depth[no default]" where I typed in 16.
>> But it kept looking th
29 matches
Mail list logo
