* 9FRONT "опен-сссл" Released @ 2014-04-28 4:25 sl 2014-04-28 10:52 ` cwfs fsmempercent arisawa 0 siblings, 1 reply; 33+ messages in thread From: sl @ 2014-04-28 4:25 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* cwfs fsmempercent 2014-04-28 4:25 9FRONT "опен-сссл" Released sl @ 2014-04-28 10:52 ` arisawa 2014-04-28 17:08 ` [9front] " cinap_lenrek ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: arisawa @ 2014-04-28 10:52 UTC (permalink / raw) To: 9front 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; … } ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-04-28 10:52 ` cwfs fsmempercent arisawa @ 2014-04-28 17:08 ` cinap_lenrek 2014-04-28 17:26 ` cinap_lenrek 2014-05-03 0:37 ` cinap_lenrek 2 siblings, 0 replies; 33+ messages in thread From: cinap_lenrek @ 2014-04-28 17:08 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-04-28 10:52 ` cwfs fsmempercent arisawa 2014-04-28 17:08 ` [9front] " cinap_lenrek @ 2014-04-28 17:26 ` cinap_lenrek 2014-04-28 22:55 ` arisawa 2014-05-03 0:37 ` cinap_lenrek 2 siblings, 1 reply; 33+ messages in thread From: cinap_lenrek @ 2014-04-28 17:26 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-04-28 17:26 ` cinap_lenrek @ 2014-04-28 22:55 ` arisawa 2014-04-29 20:11 ` cinap_lenrek 0 siblings, 1 reply; 33+ messages in thread From: arisawa @ 2014-04-28 22:55 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-04-28 22:55 ` arisawa @ 2014-04-29 20:11 ` cinap_lenrek 2014-04-30 14:41 ` Kenji Arisawa 2014-05-04 12:40 ` [9front] cwfs fsmempercent arisawa 0 siblings, 2 replies; 33+ messages in thread From: cinap_lenrek @ 2014-04-29 20:11 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-04-29 20:11 ` cinap_lenrek @ 2014-04-30 14:41 ` Kenji Arisawa 2014-04-30 20:14 ` cinap_lenrek 2014-05-04 12:40 ` [9front] cwfs fsmempercent arisawa 1 sibling, 1 reply; 33+ messages in thread From: Kenji Arisawa @ 2014-04-30 14:41 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-04-30 14:41 ` Kenji Arisawa @ 2014-04-30 20:14 ` cinap_lenrek 2014-05-01 10:39 ` 9pc64 arisawa 0 siblings, 1 reply; 33+ messages in thread From: cinap_lenrek @ 2014-04-30 20:14 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* 9pc64 2014-04-30 20:14 ` cinap_lenrek @ 2014-05-01 10:39 ` arisawa 2014-05-01 11:07 ` [9front] 9pc64 Aram Hăvărneanu 0 siblings, 1 reply; 33+ messages in thread From: arisawa @ 2014-05-01 10:39 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 10:39 ` 9pc64 arisawa @ 2014-05-01 11:07 ` Aram Hăvărneanu 2014-05-01 14:06 ` arisawa 0 siblings, 1 reply; 33+ messages in thread From: Aram Hăvărneanu @ 2014-05-01 11:07 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 11:07 ` [9front] 9pc64 Aram Hăvărneanu @ 2014-05-01 14:06 ` arisawa 2014-05-01 14:25 ` cinap_lenrek ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: arisawa @ 2014-05-01 14:06 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 14:06 ` arisawa @ 2014-05-01 14:25 ` cinap_lenrek 2014-05-01 14:39 ` cinap_lenrek 2014-05-01 15:27 ` cinap_lenrek 2 siblings, 0 replies; 33+ messages in thread From: cinap_lenrek @ 2014-05-01 14:25 UTC (permalink / raw) To: 9front the pc64 kernel supports memory over 4GB. there is probably something wrong with your bios e820 memory map. please run: cat '#ec/*e820' -- cinap ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 14:06 ` arisawa 2014-05-01 14:25 ` cinap_lenrek @ 2014-05-01 14:39 ` cinap_lenrek 2014-05-01 15:27 ` cinap_lenrek 2 siblings, 0 replies; 33+ messages in thread From: cinap_lenrek @ 2014-05-01 14:39 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 14:06 ` arisawa 2014-05-01 14:25 ` cinap_lenrek 2014-05-01 14:39 ` cinap_lenrek @ 2014-05-01 15:27 ` cinap_lenrek 2014-05-01 21:49 ` Kenji Arisawa 2 siblings, 1 reply; 33+ messages in thread From: cinap_lenrek @ 2014-05-01 15:27 UTC (permalink / raw) To: 9front pushed change increasing the number of bank slots in Conf.mem[] can you try this one? -- cinap ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 15:27 ` cinap_lenrek @ 2014-05-01 21:49 ` Kenji Arisawa 2014-05-01 21:51 ` cinap_lenrek 0 siblings, 1 reply; 33+ messages in thread From: Kenji Arisawa @ 2014-05-01 21:49 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 21:49 ` Kenji Arisawa @ 2014-05-01 21:51 ` cinap_lenrek 2014-05-01 23:22 ` Kenji Arisawa 2014-05-01 23:34 ` Kenji Arisawa 0 siblings, 2 replies; 33+ messages in thread From: cinap_lenrek @ 2014-05-01 21:51 UTC (permalink / raw) To: 9front so it works? -- cinap ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 21:51 ` cinap_lenrek @ 2014-05-01 23:22 ` Kenji Arisawa 2014-05-01 23:34 ` Kenji Arisawa 1 sibling, 0 replies; 33+ messages in thread From: Kenji Arisawa @ 2014-05-01 23:22 UTC (permalink / raw) To: 9front yes! no trouble until now. On 2014/05/02, at 6:51, cinap_lenrek@felloff.net wrote: > so it works? > > -- > cinap ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 21:51 ` cinap_lenrek 2014-05-01 23:22 ` Kenji Arisawa @ 2014-05-01 23:34 ` Kenji Arisawa 2014-05-02 0:22 ` cinap_lenrek 1 sibling, 1 reply; 33+ messages in thread From: Kenji Arisawa @ 2014-05-01 23:34 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-01 23:34 ` Kenji Arisawa @ 2014-05-02 0:22 ` cinap_lenrek 2014-05-02 11:02 ` Aram Hăvărneanu 0 siblings, 1 reply; 33+ messages in thread From: cinap_lenrek @ 2014-05-02 0:22 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] 9pc64 2014-05-02 0:22 ` cinap_lenrek @ 2014-05-02 11:02 ` Aram Hăvărneanu 2014-05-04 5:24 ` malloc Kenji Arisawa 0 siblings, 1 reply; 33+ messages in thread From: Aram Hăvărneanu @ 2014-05-02 11:02 UTC (permalink / raw) To: 9front This change also fixed the same problem observed in my QEMU VM with 8GB of memory. -- Aram Hăvărneanu ^ permalink raw reply [flat|nested] 33+ messages in thread
* malloc 2014-05-02 11:02 ` Aram Hăvărneanu @ 2014-05-04 5:24 ` Kenji Arisawa 2014-05-04 8:22 ` [9front] malloc arisawa 0 siblings, 1 reply; 33+ messages in thread From: Kenji Arisawa @ 2014-05-04 5:24 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] malloc 2014-05-04 5:24 ` malloc Kenji Arisawa @ 2014-05-04 8:22 ` arisawa 0 siblings, 0 replies; 33+ messages in thread From: arisawa @ 2014-05-04 8:22 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-04-29 20:11 ` cinap_lenrek 2014-04-30 14:41 ` Kenji Arisawa @ 2014-05-04 12:40 ` arisawa 2014-05-04 23:22 ` cinap_lenrek 1 sibling, 1 reply; 33+ messages in thread From: arisawa @ 2014-05-04 12:40 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-04 12:40 ` [9front] cwfs fsmempercent arisawa @ 2014-05-04 23:22 ` cinap_lenrek 2014-05-05 0:11 ` arisawa 0 siblings, 1 reply; 33+ messages in thread From: cinap_lenrek @ 2014-05-04 23:22 UTC (permalink / raw) To: 9front have you missed the last mails? i already commited to 9front that doesnt have the limitation 2 days ago. -- cinap ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-04 23:22 ` cinap_lenrek @ 2014-05-05 0:11 ` arisawa 2014-05-05 0:31 ` cinap_lenrek 0 siblings, 1 reply; 33+ messages in thread From: arisawa @ 2014-05-05 0:11 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-05 0:11 ` arisawa @ 2014-05-05 0:31 ` cinap_lenrek 2014-05-05 0:43 ` cinap_lenrek 0 siblings, 1 reply; 33+ messages in thread From: cinap_lenrek @ 2014-05-05 0:31 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-05 0:31 ` cinap_lenrek @ 2014-05-05 0:43 ` cinap_lenrek 2014-05-05 2:04 ` arisawa 0 siblings, 1 reply; 33+ messages in thread From: cinap_lenrek @ 2014-05-05 0:43 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-05 0:43 ` cinap_lenrek @ 2014-05-05 2:04 ` arisawa 2014-05-05 4:32 ` cinap_lenrek 0 siblings, 1 reply; 33+ messages in thread From: arisawa @ 2014-05-05 2:04 UTC (permalink / raw) To: 9front > 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-05 2:04 ` arisawa @ 2014-05-05 4:32 ` cinap_lenrek 2014-05-05 8:00 ` arisawa 0 siblings, 1 reply; 33+ messages in thread From: cinap_lenrek @ 2014-05-05 4:32 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-05 4:32 ` cinap_lenrek @ 2014-05-05 8:00 ` arisawa 2014-05-05 11:15 ` arisawa 0 siblings, 1 reply; 33+ messages in thread From: arisawa @ 2014-05-05 8:00 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-05 8:00 ` arisawa @ 2014-05-05 11:15 ` arisawa 2014-05-05 12:08 ` arisawa 0 siblings, 1 reply; 33+ messages in thread From: arisawa @ 2014-05-05 11:15 UTC (permalink / raw) To: 9front 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 > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-05-05 11:15 ` arisawa @ 2014-05-05 12:08 ` arisawa 0 siblings, 0 replies; 33+ messages in thread From: arisawa @ 2014-05-05 12:08 UTC (permalink / raw) To: 9front 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 >> > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] cwfs fsmempercent 2014-04-28 10:52 ` cwfs fsmempercent arisawa 2014-04-28 17:08 ` [9front] " cinap_lenrek 2014-04-28 17:26 ` cinap_lenrek @ 2014-05-03 0:37 ` cinap_lenrek 2 siblings, 0 replies; 33+ messages in thread From: cinap_lenrek @ 2014-05-03 0:37 UTC (permalink / raw) To: 9front just pushed change removing the 1GB restriction in cwfs. -- cinap ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2014-05-05 12:08 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-28 4:25 9FRONT "опен-сссл" Released sl 2014-04-28 10:52 ` cwfs fsmempercent arisawa 2014-04-28 17:08 ` [9front] " cinap_lenrek 2014-04-28 17:26 ` cinap_lenrek 2014-04-28 22:55 ` arisawa 2014-04-29 20:11 ` cinap_lenrek 2014-04-30 14:41 ` Kenji Arisawa 2014-04-30 20:14 ` cinap_lenrek 2014-05-01 10:39 ` 9pc64 arisawa 2014-05-01 11:07 ` [9front] 9pc64 Aram Hăvărneanu 2014-05-01 14:06 ` arisawa 2014-05-01 14:25 ` cinap_lenrek 2014-05-01 14:39 ` cinap_lenrek 2014-05-01 15:27 ` cinap_lenrek 2014-05-01 21:49 ` Kenji Arisawa 2014-05-01 21:51 ` cinap_lenrek 2014-05-01 23:22 ` Kenji Arisawa 2014-05-01 23:34 ` Kenji Arisawa 2014-05-02 0:22 ` cinap_lenrek 2014-05-02 11:02 ` Aram Hăvărneanu 2014-05-04 5:24 ` malloc Kenji Arisawa 2014-05-04 8:22 ` [9front] malloc arisawa 2014-05-04 12:40 ` [9front] cwfs fsmempercent arisawa 2014-05-04 23:22 ` cinap_lenrek 2014-05-05 0:11 ` arisawa 2014-05-05 0:31 ` cinap_lenrek 2014-05-05 0:43 ` cinap_lenrek 2014-05-05 2:04 ` arisawa 2014-05-05 4:32 ` cinap_lenrek 2014-05-05 8:00 ` arisawa 2014-05-05 11:15 ` arisawa 2014-05-05 12:08 ` arisawa 2014-05-03 0:37 ` cinap_lenrek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).