gmane.os.plan9.general

atagenioretry: nondma

arisawa — 2013-05-19T04:32:52

Hello,

yesterday day I had error messages below:

automatic dump Fri May 17 05:00:07 2013
automatic dump Sat May 18 05:00:08 2013
command 30
data f7aea8a0 limit f7aec0a0 dlen 16384 status 0 error 0
lba 163565804 -> 163565804, count 32 -> 32 (32)
atagenioretry: nondma w:163565804:32 < at >163565804:32
wrenwrite: error on w"/dev/sdD0/fsworm"(2315949): i/o error 040804 163565804
mirrwrite: error at w"/dev/sdD0/fsworm" block 2315949
atagenioretry: nondma w:163565836:32 < at >163565836:32
wrenwrite: error on w"/dev/sdD0/fsworm"(2315950): i/o error 040804 163565836
mirrwrite: error at w"/dev/sdD0/fsworm" block 2315950
atagenioretry: nondma w:163565900:32 < at >163565900:32
wrenwrite: error on w"/dev/sdD0/fsworm"(2315952): i/o error 040804 163565900
mirrwrite: error at w"/dev/sdD0/fsworm" block 2315952
atagenioretry: nondma w:163565932:32 < at >163565932:32
...
...

it seems that wrenwrite/mirrwrite errors from cwfs are induced by "atagenioretry: nondma"
which come from kernel (/sys/src/9/pc/sdide.c).

have you ever seen messages like this?

I suspected my sata drive (/dev/sdD0) has broken. but it seems the drive is alive.

Kenji Arisawa

Re: Go for systems programming

erik quanstrom — 2013-05-18T03:17:45

hey, that's cool.  thanks for the reference.

- erik

Re: Go for systems programming

Kurt H Maier — 2013-05-17T21:53:42

you are a master troll this is awesome

Re: Go for systems programming

Bakul Shah — 2013-05-17T21:05:19

And the problem with that is?

Re: Go for systems programming

Matthew Veety — 2013-05-17T20:46:25

Oh lord this is degenerating to lisp machines.

On May 17, 2013, at 16:42, Bakul Shah <bakul< at >bitblocks.com> wrote:

Re: Go for systems programming

Bakul Shah — 2013-05-17T20:42:40

In response to

See http://en.wikipedia.org/wiki/Genera_(operating_system)
Look under the Features section.

Re: Go for systems programming

erik quanstrom — 2013-05-17T20:37:06

i don't see the troll here.  there is nothing magic about user space.

- erik

Re: Go for systems programming

Kurt H Maier — 2013-05-17T20:31:43


This is a fantastic troll.  

khm

Re: Go for systems programming

Charles Forsyth — 2013-05-17T20:29:40


The Plan 9 C compiler does the preprocessor actions during lexical
analysis. It isn't a separate pass.

Re: Go for systems programming

hiro — 2013-05-17T19:23:35

I also want my microwave and wristband to run GO code first.

Re: Go for systems programming

Bakul Shah — 2013-05-17T18:45:06


Agreed.

I don't see what's the big deal about doing GC In an OS kernel. And the features that make Go interesting can be useful at the kernel level too.

On the other hand, may be the kernel can be made much more minimal and where most everything is done by user level services. But as Erik says it wouldn't be plan9. In Go it might be more natural to have a syschannel instead of syscalls (actual syscalls might end up being just send and receive).

On the other other hand, to really dethrone C, there needs to be a Go compiler in Go and an OS in Go! We know both can be done but actually doing so can throw up a bunch of surprises.

Re: Go for systems programming

lamg — 2013-05-17T17:53:00

What about lack of makefiles and fast compilation times?, I don´t want
to "remove" that.  The  point is making a more practical C, not a
Go--. Go´s grammar is designed for being easy to parse (and is
different), so it wouldn´t be C without punctuation symbols; and Go´s
package system makes the compilation faster. What about the
preprocessor? Can we get rid of that?
 If think if we can make better our lives, why wouldn´t do we? About
the support, well is difficult to break our links with the past, but
as a parallel long term project changing one thing at the time when it
is ready would be possible to achieve stability and to write programs
more easy.

2013/5/17, Skip Tavakkolian <skip.tavakkolian< at >gmail.com>:

Re: Go for systems programming

Skip Tavakkolian — 2013-05-17T17:28:27

Go's is a great language that makes it easy to write applications of all
sizes well, but its greatest benefit to Plan 9 is the plethora of packages
that make it possible to deal with the numerous Web standards.



On Fri, May 17, 2013 at 9:31 AM, Matthew Veety <mveety< at >gmail.com> wrote:

Re: Go for systems programming

erik quanstrom — 2013-05-17T16:49:37

if you rewrote a kernel in go, i don't think you'd want something that
is exactly plan 9.

- erik

Re: Go for systems programming

Matthew Veety — 2013-05-17T16:31:22


In its own niche is the important point here. Just because writing a kernel or system utilities can be done in Go doesn't mean it should be. Go isn't even totally stable or feature complete on Plan 9 at this point. You get the same shit in C on Plan 9 as you do Go plus it's more stable and has better support.
At this point I would say keep using C unless you have some specific need to use Go on Plan 9.

--
Veety

Re: Go for systems programming

Nemo — 2013-05-17T16:07:55

If you remove the features that make go interesting you'd get C without
punctuation symbols.

Go for systems programming

lamg — 2013-05-17T15:51:01

 Can Go be used for replacing C in Plan9? Could be a kernel be written
in Go? If it is not possible, what about making a C-like Go? Where
C-like Go means having similar syntax, but not channels, garbage
collection, and other fancy 21st century runtime features; but with no
need for makefiles and fast compilation times. Could this be a sort of
plugable compiler, where we could select what features of the language
we would use for being included in the runtime?
 I think it will be nice for Plan9 having such language-compiler, Go
has proved to be an improvement over C in its own niche.

Re: 9pccpu: can't open /dev/sdXX/nvram

arisawa — 2013-05-17T12:36:40

thanks panic,

it does not take long time to switch message from (1) to (2).
the problem is in (2) that read single 512 byte block of data.

Kenji Arisawa

On 2013/05/16, at 22:44, kernel panic <cinap_lenrek< at >gmx.de> wrote:

Re: Installing Go

2013-05-17T07:22:06

Building the VERSION file is a minor glitch that seems too much bother
to fix in any practical way: those who have HG installed would in any
case not want it fixed :-(

On the other hand, applying the patch required (and probably by now
insufficient) to compile Go for the ARM is hard to do without HG, so I
suppose that says that we are a bit behind the curve.

I'm hoping to do at least some of the necessary catching up now that
Go 1.1 has been released, but of course the port to plan9/arm is only
one of many issues put on hold ahead of the 1.1 release.

Feel free to ontact me (at my Gmail address <lucio.dere< at >gmail.com>) if
you have specific issues you want to discuss.  Also, there are quite
few developers lurking on go-nuts, that is a good place to make
suggestions as well as to ask questions.

++L

PS: The VERSION file is a permanent version of VERSION.cache that is
generated by the more conventional Go builds.  All Go builds delete
VERSION.cache and create a fresh one, unless there is a VERSION file
in which case the latter is used unchanged.  What works for me is to
share the GOROOT between NetBSD and Plan 9 and build the NetBSD
version of Go first (I use "tip" normally).  Before building on the
Plan 9 servers, I rename $GOROOT/VERSION.cache to $GOROOT/VERSION.  I
am convinced that there isn't a mechanism that will please everyone;
I'll be pleased to be proven wrong.

Oh, I also need to delete VERSION before building on NetBSD and
usually I forget to do it :-(

Re: Installing Go

Peter A. Cejchan — 2013-05-17T06:08:11

If all fails, you can try out what worked for me some time ago:

version go-93dc7f0e302b compiles out-of the box.
Prerequisites:
kernel post-Aug2012
8* suite post-March2012
VERSION file is needed if hg is not installed.
Mercurial is only needed to generate the top-level VERSION file.
You can work around this by creating the file yourself after
pulling the code from the repository.
Either create a fake VERSION file
    echo fake >VERSION
or one that matches what the dist tool would have printed. With sh:
    v=`hg log -r tip --template '+{node|short} {date|date}'`
    echo devel $v >VERSION
Afterwards you can run tar to generate an archive that can
be moved to any system and built without Mercurial.
Cd to go/src and run:
    make.rc

---
++pac


On Fri, May 17, 2013 at 7:07 AM, <lucio< at >proxima.alt.za> wrote:

Re: Installing Go

2013-05-17T05:07:38

To Gorka, specially, but anybody else who may wish to know:


I've been caught up in a lot of different things and haven't been able
to focus on Go for Plan 9, but I'll try to re-focus in the next few
days.

I'll try out the 1.1 release as soon as I get a chance and report back
here with the outcome.

++L