9FRONT "опен-сссл" Released

9FRONT "опен-сссл" Released

[sl]

New 9front release "опен-сссл" *
--------------------------------

http://r-36.net/9front/9front-3571.141e241178e6.iso.bz2.torrent
http://r-36.net/9front/9front-3571.141e241178e6.iso.bz2


kernel and drivers:
-------------------

kernel: devproc: change address format in segment file to %8p (thanks eekee)
kernel: icmp: use snprint, add more unreachable error messages (from erik quanstro)
kernel: fix printing wrong memory sizes in pageinit(), overflowed on amd64 (thanks aram)
kernel: add secstore and wpa to bootfs

pc, pc64: process acpi interrupt source override entries in a 2nd pass over the madt (APIC) table (thanks erik)

pc64: prevent dat.h from getting overwritten by ../pc/dat.h

nusb/kb: fix trackpoint on thinkpad usb keyboard
nusb: dont include <bio.h>, we'r not using it (thanks erik)
nusb/ether: add RNDIS support (tested on Nexus 5)
nusb: resolve endpoint id conflict with different input and output types
nusb: workaround for endpoints with same index but different types

pmmc: recognize generic mmc controllers (untested)

vga: add support nVidia 7600GS (and possibly 7950) (from kenji okamoto)

wifi: set ether->mbps to highest supported rate of the associated ap
etheriwl: set msb for all rates
etheriwl: add Wifi Link 5150 did
etheriwl: support another (broken) variant of centrino ultimate-n 6300


compilers and debuggers:
------------------------

6c, 8c: optimize away CMPL/CMPQ reg, $0 instruction in peephole pass


programs:
---------

aanuke: new program, print commands to kill idle aan processes

audio/oggdec: wait for pcmconv child process to exit

auth/login: find authdom instead of using hardcoded cs.bell-labs.com (thanks erik)

btc mkfile: mkdir -p

eqn: fix parallel build (thanks eekee)

games/gb: better video scaler from games/nes

games/geigerstats: fix usage() to exit

games/snes: improved cpu timing
games/snes: fix dspclock signed overflow (music stoping for minute)
games/snes: upsample audio to 44100 hz instead of setting audio device frequency
games/snes: faster scaling
games/snes: mode 5/6; overscan fix

grep: fix wrong rlcass splitting (thanks erik and kenji)
grep: fix tab2, use int instead of Rune to be compatible to 16bit rune system

newt: new program, NNTP client for use with nttpfs(4)

ramfs: fix srvname; postmountsrv() already prepends /srv/

sam, acme: fix character classes quoting for 21-bit runes

secstore: fix gfile/pfile/rfile array sizes
secstore: fix wrong "readnvram %r" error status

termrc, cpurc: exclude wpa from oom kill and swap

tr: fix 4-byte runes fix (thanks rsc)

webfs: do not unescape escape

wpa support for tcp boot, remove duplicate secstore code from factotum


libraries:
----------

libauthsrv: recognize amd64 $cputype in readnvram() to look for default locations

libc: allow announce address of the form #I1/tcp!*!564

libmach: fix printing of amd64 modrm byte register with rex prefix

libmemdraw: improve readbyte() and writebyte() routines

libsec: tlshand: fix memory leaks, fix alloc element size for certs pointer array, error handling, cleanup 36 -> MD5dlen+SHA1dlen

vgadb: add EIZO Flexscan S2231W (from kenji okamoto)


documentation:
--------------

aan(8): add aanuke and HISTORY

draw(2): fix missing arg of bezspline on page 5

games(1): geigerstats args


* http://9front.org/img/openssl.png 
http://9front.org/img/misc-cookie.gif

cwfs fsmempercent

[arisawa]

Hello,

recent cwfs restricts memory size to 1GB max to be allocated to cwfs.
is there any reason to restrict the value?
nowadays we have much memory such as 16GB on MB.
I would be happier if I can allocate much memory to cwfs.

Kenji Arisawa

/sys/src/cmd/cwfs/malloc.c
static ulong
memsize(void)
{
	...
		userpgs = (userpgs*mpcnt)/100;
		pgmax = (1024*1024*1024)/pgsize;	/* 1GB max */
		if(userpgs > pgmax)
			userpgs = pgmax;
		return userpgs*pgsize;
	…
}

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

the pool allocator uses 32 bit length fields in its allocation
block structure and arenas. you can allocate above 4GB on pc64,
but not in a single allocation right now.

you can allocate virtual memory with brk()/sbrk() beyond 4gb with
the pc64 kernel.

--
cinap

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

i might add, this should be easy to fix. its just low on my
priority list because my fileserver is 32 bit and has just
1gb of ram.

local cwfs filesystem on x200s under 64 bit has 4gb of ram.
the x230 here has 16gb of ram, but i only use it diskless.

--
cinap

Re: [9front] cwfs fsmempercent

[arisawa]

setting pgmax to 2GB makes problem?

2014/04/29 2:26、cinap_lenrek@felloff.net のメール：

> i might add, this should be easy to fix. its just low on my
> priority list because my fileserver is 32 bit and has just
> 1gb of ram.
> 
> local cwfs filesystem on x200s under 64 bit has 4gb of ram.
> the x230 here has 16gb of ram, but i only use it diskless.
> 
> --
> cinap

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

that might work. i havnt tried it. you need to be carefull
with overflows as 2GB becomes negative with signed 32 bit ints.

	if(dsize >= 0x80000000UL){	/* for sanity, overflow */
		werrstr("invalid allocation size");
		return nil;
	}

the only routine that does substantial allocation is iobufinit()
in cwfs/malloc.c.

as far as i can see, this memory is never freed, so we might
just remove the define:

all.h:13: #define malloc(n)	ialloc(n, 0)

and provide our own ialloc() that just uses brk().

--
cinap

Re: [9front] cwfs fsmempercent

[Kenji Arisawa]

thanks. I will try and report.
by the way, I cannot compile pc64

term% pwd
/sys/src/9/pc64
term% mk
mk: ambiguous recipes for devusb.6:
	devusb.6 <-(mkfile:94)- ../pc/devusb.c
	devusb.6 <-(../port/portmkfile:3)- ../port/devusb.c
term% 

what's wrong?

On 2014/04/30, at 5:11, cinap_lenrek@felloff.net wrote:

> that might work. i havnt tried it. you need to be carefull
> with overflows as 2GB becomes negative with signed 32 bit ints.
> 
> 	if(dsize >= 0x80000000UL){	/* for sanity, overflow */
> 		werrstr("invalid allocation size");
> 		return nil;
> 	}
> 
> the only routine that does substantial allocation is iobufinit()
> in cwfs/malloc.c.
> 
> as far as i can see, this memory is never freed, so we might
> just remove the define:
> 
> all.h:13: #define malloc(n)	ialloc(n, 0)
> 
> and provide our own ialloc() that just uses brk().
> 
> --
> cinap

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

the problem is that there shouldnt be a pc/devusb.c as
there are two meta rules to build dev*.$O from port/dev*.c and
pc/dev*.c files but due to the existence of both pc/devusb.c and
port/devusb.c it cant decide which rule applies.

9front has only port/devusb.c file.

--
cinap

9pc64

[arisawa]

thanks,

9pc64 is now running on one of my machines. (ga-h77m-d3h)
it seems working steady. thanks.

probably that is the first step to full 64bit support.
I am looking forward to see the next version.

thanks again.

Kenji Arisawa

2014/05/01 5:14、cinap_lenrek@felloff.net のメール：

> the problem is that there shouldnt be a pc/devusb.c as
> there are two meta rules to build dev*.$O from port/dev*.c and
> pc/dev*.c files but due to the existence of both pc/devusb.c and
> port/devusb.c it cant decide which rule applies.
> 
> 9front has only port/devusb.c file.
> 
> --
> cinap

Re: [9front] 9pc64

[Aram Hăvărneanu]

Great, don't forget to submit sysinfo.

On Thu, May 1, 2014 at 12:39 PM, arisawa <arisawa@ar.aichi-u.ac.jp> wrote:
> probably that is the first step to full 64bit support.

What do you mean by this?

-- 
Aram Hăvărneanu

Re: [9front] 9pc64

[arisawa]

Hello,

>> 
>> probably that is the first step to full 64bit support.
> 
> What do you mean by this?

need more tuning.
for example
term% memory
total          3.4 GB
total kernel   1.36 GB
total user     2.04 GB

used  user     6.14 MB
used  kernel   7.76 MB
used  draw     12.9 MB

term% cat /dev/kmesg
meminit - lost 13411430400 bytes
…

the MB has as much as 16GB.

Kenji Arisawa

Re: [9front] 9pc64

[cinap_lenrek]

the pc64 kernel supports memory over 4GB. there is probably
something wrong with your bios e820 memory map. please run:

cat '#ec/*e820'

--
cinap

Re: [9front] 9pc64

[cinap_lenrek]

i think i know whats wrong. it seems we ran out of
physical memory bank slots in Conf.mem[].

in pc64/dat.h:

struct Conf
{
	...
	Confmem	mem[4];		/* physical memory */
	...
};

so if there are more than 4 continuous ram banks,
only the first 4 banks will be available.

you can try increasing the size of the mem[]
array in the Conf structure to 16 (maximum).

--
cinap

Re: [9front] 9pc64

[cinap_lenrek]

pushed change increasing the number of bank slots in Conf.mem[]
can you try this one?

--
cinap

Re: [9front] 9pc64

[Kenji Arisawa]

already done and confirmed the result.

On 2014/05/02, at 0:27, cinap_lenrek@felloff.net wrote:

> pushed change increasing the number of bank slots in Conf.mem[]
> can you try this one?
> 
> --
> cinap

Re: [9front] 9pc64

[cinap_lenrek]

so it works?

--
cinap

Re: [9front] 9pc64

[Kenji Arisawa]

yes!
no trouble until now.

On 2014/05/02, at 6:51, cinap_lenrek@felloff.net wrote:

> so it works?
> 
> --
> cinap

Re: [9front] 9pc64

[Kenji Arisawa]

memory command on 9pc64 

term% memory
total          15.9 GB
total kernel   2 GB
total user     13.9 GB

used  user     8.32 MB
used  kernel   11.6 MB
used  draw     13.3 MB
term% 



Test if large memory is really allocated to a process.

H2: Test Code

void
main(int argc, char *argv[])
{
	char *p, buf[256];
	ulong i,n[4];
	ulong GB = 1024*1024*1024;

	ARGBEGIN{
	default: usage();
	}ARGEND

	n[0] = 1;
	n[1] = 1;
	n[2] = 1;
	n[3] = 1;

	for(i = 0; i< 4; i++){
		p = malloc(n[i]*GB);
		print("%d %dGB %08p\n",i,n[i],p);
	}
	read(0,buf, sizeof(buf));
}


H2: The Result

H3:	9front (9pc64)

term% 6.out
0 1GB 00401938
1 1GB 404019a0
2 1GB 80401a08
3 1GB 00000000

the 6.out is running
term% ps | grep 6.out
arisawa        1383    0:00   0:00       56K Pread    6.out
term% memory
total          15.9 GB
total kernel   2 GB
total user     13.9 GB

used  user     8.28 MB
used  kernel   10.5 MB
used  draw     13.3 MB
term% 

H3:	9front (9pcf)

term% 8.out
0 1GB 0000a4a0
1 1GB 00000000
2 1GB 00000000
3 1GB 00000000

the 8.out is running
term% ps |grep 8.out
arisawa        1843    0:00   0:00       48K Pread    8.out
term% memory
total          3.42 GB
total kernel   154 MB
total user     3.27 GB

used  user     859 MB
used  kernel   6.38 MB
used  draw     8.77 MB
term% 

Totally OK.
It would be better if we get total memory size allocated to a process.
memory command on both 9pcf and 9pc64 does not show malloced size.

On 2014/05/02, at 6:51, cinap_lenrek@felloff.net wrote:

> so it works?
> 
> --
> cinap

Re: [9front] 9pc64

[cinap_lenrek]

they show the *used* memory size. your program isnt using
the memory but is just allocating virtual address space.
to use the memory, you need to actually touch it. malloc()
doesnt touch the memory.

do a memset() on the allocated block or use mallocz(len, 1);

--
cinap

Re: [9front] 9pc64

[Aram Hăvărneanu]

This change also fixed the same problem observed in my QEMU VM with
8GB of memory.

-- 
Aram Hăvărneanu

malloc

[Kenji Arisawa]

It seems malloc() has a problem with large size allocation.

void
test1(void)
{
	char *p, buf[256];
	ulong i,n[16];
	ulong MB = 1024*1024;

	n[0] = 1024;
	n[1] = 1024;
	n[2] = 1024;
	n[3] = 512;
	n[4] = 0;

	for(i = 0; n[i]; i++){
		p = malloc(n[i]*MB);
		print("%d %uldMB %08p\n",i,n[i],p);
		if(p ==nil)
			continue;
	}
	read(0,buf, sizeof(buf));
}

term% 6.out
0 1024MB 00401948
1 1024MB 404019b0
2 1024MB 80401a18
3 512MB c0401a80

# this is OK


void
test2(void)
{
	char *p, buf[256];
	ulong i,n[16];
	ulong MB = 1024*1024;

	n[0] = 3*1024+512;
	n[1] = 0;

	for(i = 0; n[i]; i++){
		p = malloc(n[i]*MB);
		print("%d %uldMB %08p\n",i,n[i],p);
		if(p ==nil)
			continue;
	}
	read(0,buf, sizeof(buf));
}

term% 6.out
0 3584MB 00000000

# this is NG

Re: [9front] malloc

[arisawa]

I have understood what cinap said by this:

> 	if(dsize >= 0x80000000UL){	/* for sanity, overflow */
> 		werrstr("invalid allocation size");
> 		return nil;
> 	}


malloc(size) // size >= 2GB
is checked by this.
currently, this restriction is for both 9pc and 9pc64.

On 2014/05/04, at 14:24, Kenji Arisawa <arisawa@ar.aichi-u.ac.jp> wrote:

> It seems malloc() has a problem with large size allocation.

Re: [9front] cwfs fsmempercent

[arisawa]

Now we can allocate large memory allocation for cwfs on 9pc64.
it seems the change below works for me.

change of malloc.c

static ulong
memsize(void)
{
	...
//		pgmax = (1024*1024*1024)/pgsize;	/* 1GB max for 386 */
		pgmax = (3*1024*1024*1024)/pgsize;	/* 3GB max for x64 */
	...
}

void*
sbrkz(ulong n)
{
	char *p;
	p = sbrk(n);
	memset(p,0,n);
	return p;
}

/*
 * allocate rest of mem
 * for io buffers.
 */
void
iobufinit(void)
{
	...
//	hiob = ialloc(nhiob * sizeof(Hiob), 0);
	hiob = sbrkz(nhiob * sizeof(Hiob));
	...
//	p = ialloc(niob * sizeof(Iobuf), 0);
	p = sbrkz(niob * sizeof(Iobuf));
	...
//	xiop = ialloc(niob * RBUFSIZE, 0);
	xiop = sbrkz(niob * RBUFSIZE);
	...
}


term% ps
...
arisawa        2649    0:00   0:00  3160928K Semacqui 6.cwfs64x
arisawa        2650    0:00   0:00  3160928K Pread    6.cwfs64x
arisawa        2651    0:00   0:00  3160928K Pread    6.cwfs64x
arisawa        2652    0:00   0:00  3160928K Pread    6.cwfs64x
arisawa        2653    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2654    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2655    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2656    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2657    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2658    0:00   0:00  3160928K Semacqui 6.cwfs64x
arisawa        2659    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2660    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2661    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2662    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2663    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2664    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2665    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2666    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2667    0:00   0:00  3160928K Rendez   6.cwfs64x
arisawa        2668    0:00   0:00  3160928K Sleep    6.cwfs64x
arisawa        2669    0:00   0:00  3160928K Sleep    6.cwfs64x
...
term%

don't remove
 #define malloc(n)	ialloc(n, 0)
in all.h

thank you cinap.

Kenji Arisawa


On 2014/04/30, at 5:11, cinap_lenrek@felloff.net wrote:

> that might work. i havnt tried it. you need to be carefull
> with overflows as 2GB becomes negative with signed 32 bit ints.
> 
> 	if(dsize >= 0x80000000UL){	/* for sanity, overflow */
> 		werrstr("invalid allocation size");
> 		return nil;
> 	}
> 
> the only routine that does substantial allocation is iobufinit()
> in cwfs/malloc.c.
> 
> as far as i can see, this memory is never freed, so we might
> just remove the define:
> 
> all.h:13: #define malloc(n)	ialloc(n, 0)
> 
> and provide our own ialloc() that just uses brk().
> 
> --
> cinap

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

have you missed the last mails? i already commited
to 9front that doesnt have the limitation 2 days
ago.

--
cinap

Re: [9front] cwfs fsmempercent

[arisawa]

sorry cinap, but I could not see your update.

maia% sysupdate
pulling from https://plan9front.googlecode.com/hg/
searching for changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: data/sys/src/ape/lib/ap/sparc/main9p.s.i@478a95e61cc8: unknown parent!
maia% 

hg is very complicate and so I dislike it.

On 2014/05/05, at 8:22, cinap_lenrek@felloff.net wrote:

> have you missed the last mails? i already commited
> to 9front that doesnt have the limitation 2 days
> ago.
> 
> --
> cinap

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

that looks like repository corruption. unclean shutdown?

the sparc main9p.s wasnt changed for at least a year, so
you might just recover the file from dump or from the iso.

do the following to get the file md5 checksum:

term% cd /dist/plan9front/.hg/store/data/sys/src/ape/lib/ap/sparc
term% md5sum main9p.s.i
f391ed700f136bf33c51cbf16ae2aa39	main9p.s.i

then compare it with the checksum above. if it doesnt match,
try to recover the file from backup/dump or take it from
the iso. (verify md5 checksum here as well).

--
cinap

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

you could also just delete /dist/plan9front/.hg and copy
it back from the iso (or from dump or whatever), then do a
hg pull; then; hg update. hg is very good at not destroying
local changes it doesnt know about.
so even if you have an old .hg/ repository, but new working files,
it will just report them as local modifications. once you
hg pull and hg update, it should see that the files are all
the same as in the repository and the modifications should
be gone. hg status -q to verify.

--
cinap

Re: [9front] cwfs fsmempercent

[arisawa]

> you could also just delete /dist/plan9front/.hg and copy
> it back from the iso (or from dump or whatever), then do a
> hg pull; then; hg update. 

I did.

what do you suspect?
of course I executed in allow mode.

term% auth/as glenda sysupdate
pulling from https://plan9front.googlecode.com/hg/
searching for changes
adding changesets
transaction abort!
rollback completed
** unknown exception encountered, details follow
** report bug details to http://mercurial.selenic.com/bts/
** or mercurial@selenic.com
** Mercurial Distributed SCM (version unknown)
** Extensions loaded: 
Traceback (most recent call last):
  File "/bin/hg", line 39, in <module>
    mercurial.dispatch.run()
  File "/sys/lib/python/mercurial/dispatch.py", line 16, in run
    sys.exit(dispatch(sys.argv[1:]))
  File "/sys/lib/python/mercurial/dispatch.py", line 27, in dispatch
    return _runcatch(u, args)
  File "/sys/lib/python/mercurial/dispatch.py", line 43, in _runcatch
    return _dispatch(ui, args)
  File "/sys/lib/python/mercurial/dispatch.py", line 449, in _dispatch
    return runcommand(lui, repo, cmd, fullargs, ui, options, d)
  File "/sys/lib/python/mercurial/dispatch.py", line 317, in runcommand
    ret = _runcommand(ui, options, cmd, d)
  File "/sys/lib/python/mercurial/dispatch.py", line 501, in _runcommand
    return checkargs()
  File "/sys/lib/python/mercurial/dispatch.py", line 454, in checkargs
    return cmdfunc()
  File "/sys/lib/python/mercurial/dispatch.py", line 448, in <lambda>
    d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/sys/lib/python/mercurial/util.py", line 402, in check
    return func(*args, **kwargs)
  File "/sys/lib/python/mercurial/commands.py", line 2305, in pull
    modheads = repo.pull(other, heads=revs, force=opts.get('force'))
  File "/sys/lib/python/mercurial/localrepo.py", line 1442, in pull
    return self.addchangegroup(cg, 'pull', remote.url())
  File "/sys/lib/python/mercurial/localrepo.py", line 2008, in addchangegroup
    if cl.addgroup(chunkiter, csmap, trp) is None and not emptyok:
  File "/sys/lib/python/mercurial/revlog.py", line 1246, in addgroup
    text = self.revision(chain)
  File "/sys/lib/python/mercurial/revlog.py", line 999, in revision
    text = mdiff.patches(text, bins)
mpatch.mpatchError: patch cannot be decoded
term% 


On 2014/05/05, at 9:43, cinap_lenrek@felloff.net wrote:

> you could also just delete /dist/plan9front/.hg and copy
> it back from the iso (or from dump or whatever), then do a
> hg pull; then; hg update. hg is very good at not destroying
> local changes it doesnt know about.
> so even if you have an old .hg/ repository, but new working files,
> it will just report them as local modifications. once you
> hg pull and hg update, it should see that the files are all
> the same as in the repository and the modifications should
> be gone. hg status -q to verify.
> 
> --
> cinap

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

this is an exception happening in

/sys/src/cmd/hg/mercurial/mpatch.c:424

parsing a revlog file. each file tracked by mercurial has
a revlog file containing the changes of this file. (binary
patches). these files are append only.

unfortunately, that stacktrace doesnt tell us what file
is corrupted.

what exactly did you do?

--
cinap

Re: [9front] cwfs fsmempercent

[arisawa]

I have cleaned directories below:
/dist/plan9front/
/sys/lib/python/mercurial/
/sys/lib/python/hgext/
/sys/src/cmd/hg/
and reinstalled them using latest iso image from 9front (опен-сссл).
and then
(1) allowed mode to cwfs64x
(2) auth/as glenda sysupdate

note that host owner of my terminal is "arisawa".

term% pwd
/dist/plan9front
term% ls -l
d-rwxrwxr-x M 20 glenda sys   0 Apr 28 06:31 .hg
--rw-rw-r-- M 20 glenda sys 724 Jun 15  2013 .hgignore
term% ls -ld .hg/store
d-rwxrwxr-x M 20 glenda sys 0 May  5 15:47 .hg/store
term% ls -l .hg/store
--rw-rw-r-- M 20 glenda sys  745978 May  4 22:05 .hg/store/00changelog.d
--rw-rw-r-- M 20 glenda sys  228608 Apr 28 06:20 .hg/store/00changelog.i
--rw-rw-r-- M 20 glenda sys 1521917 May  4 22:05 .hg/store/00manifest.d
--rw-rw-r-- M 20 glenda sys  165888 May  4 22:05 .hg/store/00manifest.i
d-rwxrwxr-x M 20 glenda sys       0 Apr 12  2013 .hg/store/data
--rw-rw-r-- M 20 glenda sys  967509 May  4 22:05 .hg/store/fncache
--rw-rw-r-- M 20 glenda sys     222 Apr 28 06:20 .hg/store/undo
term% 

what else should I examine?

it seems "*.d" and "*.i" files are compressed.
I am happier if I can decompress these file, because I have your update in "*.i" format.

term% ls -tl .hg/store/data/sys/src/cmd/cwfs |head
--rw-rw-r-- M 20 glenda sys  2777 May  4 22:05 .hg/store/data/sys/src/cmd/cwfs/iobuf.c.i
--rw-rw-r-- M 20 glenda sys  1686 May  4 20:15 .hg/store/data/sys/src/cmd/cwfs/all.h.i
--rw-rw-r-- M 20 glenda sys  2777 Feb 14 23:09 .hg/store/data/sys/src/cmd/cwfs/malloc.c.i
--rw-rw-r-- M 20 glenda sys  7113 Feb  4 04:05 .hg/store/data/sys/src/cmd/cwfs/portdat.h.i
--rw-rw-r-- M 20 glenda sys  5523 Oct 17  2013 .hg/store/data/sys/src/cmd/cwfs/chk.c.i
--rw-rw-r-- M 20 glenda sys 16946 Oct 16  2013 .hg/store/data/sys/src/cmd/cwfs/cw.c.i
--rw-rw-r-- M 20 glenda sys  9457 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/sub.c.i
--rw-rw-r-- M 20 glenda sys  5470 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/net.c.i
--rw-rw-r-- M 20 glenda sys  3357 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/srv.c.i
--rw-rw-r-- M 20 glenda sys  7795 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/main.c.i
term% 

On 2014/05/05, at 13:32, cinap_lenrek@felloff.net wrote:

> this is an exception happening in
> 
> /sys/src/cmd/hg/mercurial/mpatch.c:424
> 
> parsing a revlog file. each file tracked by mercurial has
> a revlog file containing the changes of this file. (binary
> patches). these files are append only.
> 
> unfortunately, that stacktrace doesnt tell us what file
> is corrupted.
> 
> what exactly did you do?
> 
> --
> cinap

Re: [9front] cwfs fsmempercent

[arisawa]

now I could succeed to update by hg.

I don't know why I was in trouble.
probably straggling led me to bad way.
send time, I reinstalled /dist/plan9front/ and get success.
your fix is nice!

thanks a lot.

by the way, a command name 9hg may be useful.

#!/bin/rc
rfork n
cd /
if(! test -d .hg)
	bind -ac /dist/plan9front /
if(! ~ $#* 0)
	hg $*
if not
	hg help | awk '/^ [a-z]*/ {s=$0; sub(" *[a-z]* *","",s); printf("9hg %s\t# %s\n", $1, s)}'





On 2014/05/05, at 17:00, arisawa <arisawa@ar.aichi-u.ac.JP> wrote:

> I have cleaned directories below:
> /dist/plan9front/
> /sys/lib/python/mercurial/
> /sys/lib/python/hgext/
> /sys/src/cmd/hg/
> and reinstalled them using latest iso image from 9front (опен-сссл).
> and then
> (1) allowed mode to cwfs64x
> (2) auth/as glenda sysupdate
> 
> note that host owner of my terminal is "arisawa".
> 
> term% pwd
> /dist/plan9front
> term% ls -l
> d-rwxrwxr-x M 20 glenda sys   0 Apr 28 06:31 .hg
> --rw-rw-r-- M 20 glenda sys 724 Jun 15  2013 .hgignore
> term% ls -ld .hg/store
> d-rwxrwxr-x M 20 glenda sys 0 May  5 15:47 .hg/store
> term% ls -l .hg/store
> --rw-rw-r-- M 20 glenda sys  745978 May  4 22:05 .hg/store/00changelog.d
> --rw-rw-r-- M 20 glenda sys  228608 Apr 28 06:20 .hg/store/00changelog.i
> --rw-rw-r-- M 20 glenda sys 1521917 May  4 22:05 .hg/store/00manifest.d
> --rw-rw-r-- M 20 glenda sys  165888 May  4 22:05 .hg/store/00manifest.i
> d-rwxrwxr-x M 20 glenda sys       0 Apr 12  2013 .hg/store/data
> --rw-rw-r-- M 20 glenda sys  967509 May  4 22:05 .hg/store/fncache
> --rw-rw-r-- M 20 glenda sys     222 Apr 28 06:20 .hg/store/undo
> term% 
> 
> what else should I examine?
> 
> it seems "*.d" and "*.i" files are compressed.
> I am happier if I can decompress these file, because I have your update in "*.i" format.
> 
> term% ls -tl .hg/store/data/sys/src/cmd/cwfs |head
> --rw-rw-r-- M 20 glenda sys  2777 May  4 22:05 .hg/store/data/sys/src/cmd/cwfs/iobuf.c.i
> --rw-rw-r-- M 20 glenda sys  1686 May  4 20:15 .hg/store/data/sys/src/cmd/cwfs/all.h.i
> --rw-rw-r-- M 20 glenda sys  2777 Feb 14 23:09 .hg/store/data/sys/src/cmd/cwfs/malloc.c.i
> --rw-rw-r-- M 20 glenda sys  7113 Feb  4 04:05 .hg/store/data/sys/src/cmd/cwfs/portdat.h.i
> --rw-rw-r-- M 20 glenda sys  5523 Oct 17  2013 .hg/store/data/sys/src/cmd/cwfs/chk.c.i
> --rw-rw-r-- M 20 glenda sys 16946 Oct 16  2013 .hg/store/data/sys/src/cmd/cwfs/cw.c.i
> --rw-rw-r-- M 20 glenda sys  9457 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/sub.c.i
> --rw-rw-r-- M 20 glenda sys  5470 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/net.c.i
> --rw-rw-r-- M 20 glenda sys  3357 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/srv.c.i
> --rw-rw-r-- M 20 glenda sys  7795 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/main.c.i
> term% 
> 
> On 2014/05/05, at 13:32, cinap_lenrek@felloff.net wrote:
> 
>> this is an exception happening in
>> 
>> /sys/src/cmd/hg/mercurial/mpatch.c:424
>> 
>> parsing a revlog file. each file tracked by mercurial has
>> a revlog file containing the changes of this file. (binary
>> patches). these files are append only.
>> 
>> unfortunately, that stacktrace doesnt tell us what file
>> is corrupted.
>> 
>> what exactly did you do?
>> 
>> --
>> cinap
> 

Re: [9front] cwfs fsmempercent

[arisawa]

Hello cinap,

by the way, I am feeling uneasy.
you don't memset().
assuming that other processes can know only physical memory and used memory of the system,
that is, if they don't know reserved memory (allocated memory),
then they might misunderstand memory size they can allocate.
isn't this make a problem?

On 2014/05/05, at 20:15, arisawa <arisawa@ar.aichi-u.ac.JP> wrote:

> now I could succeed to update by hg.
> 
> I don't know why I was in trouble.
> probably straggling led me to bad way.
> send time, I reinstalled /dist/plan9front/ and get success.
> your fix is nice!
> 
> thanks a lot.
> 
> by the way, a command name 9hg may be useful.
> 
> #!/bin/rc
> rfork n
> cd /
> if(! test -d .hg)
> 	bind -ac /dist/plan9front /
> if(! ~ $#* 0)
> 	hg $*
> if not
> 	hg help | awk '/^ [a-z]*/ {s=$0; sub(" *[a-z]* *","",s); printf("9hg %s\t# %s\n", $1, s)}'
> 
> 
> 
> 
> 
> On 2014/05/05, at 17:00, arisawa <arisawa@ar.aichi-u.ac.JP> wrote:
> 
>> I have cleaned directories below:
>> /dist/plan9front/
>> /sys/lib/python/mercurial/
>> /sys/lib/python/hgext/
>> /sys/src/cmd/hg/
>> and reinstalled them using latest iso image from 9front (опен-сссл).
>> and then
>> (1) allowed mode to cwfs64x
>> (2) auth/as glenda sysupdate
>> 
>> note that host owner of my terminal is "arisawa".
>> 
>> term% pwd
>> /dist/plan9front
>> term% ls -l
>> d-rwxrwxr-x M 20 glenda sys   0 Apr 28 06:31 .hg
>> --rw-rw-r-- M 20 glenda sys 724 Jun 15  2013 .hgignore
>> term% ls -ld .hg/store
>> d-rwxrwxr-x M 20 glenda sys 0 May  5 15:47 .hg/store
>> term% ls -l .hg/store
>> --rw-rw-r-- M 20 glenda sys  745978 May  4 22:05 .hg/store/00changelog.d
>> --rw-rw-r-- M 20 glenda sys  228608 Apr 28 06:20 .hg/store/00changelog.i
>> --rw-rw-r-- M 20 glenda sys 1521917 May  4 22:05 .hg/store/00manifest.d
>> --rw-rw-r-- M 20 glenda sys  165888 May  4 22:05 .hg/store/00manifest.i
>> d-rwxrwxr-x M 20 glenda sys       0 Apr 12  2013 .hg/store/data
>> --rw-rw-r-- M 20 glenda sys  967509 May  4 22:05 .hg/store/fncache
>> --rw-rw-r-- M 20 glenda sys     222 Apr 28 06:20 .hg/store/undo
>> term% 
>> 
>> what else should I examine?
>> 
>> it seems "*.d" and "*.i" files are compressed.
>> I am happier if I can decompress these file, because I have your update in "*.i" format.
>> 
>> term% ls -tl .hg/store/data/sys/src/cmd/cwfs |head
>> --rw-rw-r-- M 20 glenda sys  2777 May  4 22:05 .hg/store/data/sys/src/cmd/cwfs/iobuf.c.i
>> --rw-rw-r-- M 20 glenda sys  1686 May  4 20:15 .hg/store/data/sys/src/cmd/cwfs/all.h.i
>> --rw-rw-r-- M 20 glenda sys  2777 Feb 14 23:09 .hg/store/data/sys/src/cmd/cwfs/malloc.c.i
>> --rw-rw-r-- M 20 glenda sys  7113 Feb  4 04:05 .hg/store/data/sys/src/cmd/cwfs/portdat.h.i
>> --rw-rw-r-- M 20 glenda sys  5523 Oct 17  2013 .hg/store/data/sys/src/cmd/cwfs/chk.c.i
>> --rw-rw-r-- M 20 glenda sys 16946 Oct 16  2013 .hg/store/data/sys/src/cmd/cwfs/cw.c.i
>> --rw-rw-r-- M 20 glenda sys  9457 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/sub.c.i
>> --rw-rw-r-- M 20 glenda sys  5470 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/net.c.i
>> --rw-rw-r-- M 20 glenda sys  3357 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/srv.c.i
>> --rw-rw-r-- M 20 glenda sys  7795 Aug  8  2013 .hg/store/data/sys/src/cmd/cwfs/main.c.i
>> term% 
>> 
>> On 2014/05/05, at 13:32, cinap_lenrek@felloff.net wrote:
>> 
>>> this is an exception happening in
>>> 
>>> /sys/src/cmd/hg/mercurial/mpatch.c:424
>>> 
>>> parsing a revlog file. each file tracked by mercurial has
>>> a revlog file containing the changes of this file. (binary
>>> patches). these files are append only.
>>> 
>>> unfortunately, that stacktrace doesnt tell us what file
>>> is corrupted.
>>> 
>>> what exactly did you do?
>>> 
>>> --
>>> cinap
>> 
> 

Re: [9front] cwfs fsmempercent

[cinap_lenrek]

just pushed change removing the 1GB restriction in cwfs.

--
cinap