From: Maarten B. <sou...@ds...> - 2012-04-23 21:01:30
|
Hi all, When I run the regression tests I have a few hanging tests: gcc-torture-execute-961017-2.c hangs on ucgbz80 and ucr2k and thus generates a timeout. It passes for ucz80 and ucz180. This fails with a proper timeout. But gcc-torture-execute-930529-1.c hangs when running test-host. And it does not timeout! It fails after printing __prints("Running testTortureExecute\n"); and I see nothing wrong in the generated asm. (gdb) disassemble Dump of assembler code for function __prints: 0x080484d0 <+0>: push %ebp 0x080484d1 <+1>: mov %esp,%ebp 0x080484d3 <+3>: push %ebx 0x080484d4 <+4>: sub $0x14,%esp => 0x080484d7 <+7>: mov 0x8(%ebp),%ebx 0x080484da <+10>: movzbl (%ebx),%eax 0x080484dd <+13>: test %al,%al 0x080484df <+15>: je 0x80484fd <__prints+45> 0x080484e1 <+17>: lea 0x0(%esi,%eiz,1),%esi 0x080484e8 <+24>: movsbl %al,%eax 0x080484eb <+27>: add $0x1,%ebx 0x080484ee <+30>: mov %eax,(%esp) 0x080484f1 <+33>: call 0x8048760 <_putchar> 0x080484f6 <+38>: movzbl (%ebx),%eax 0x080484f9 <+41>: test %al,%al 0x080484fb <+43>: jne 0x80484e8 <__prints+24> 0x080484fd <+45>: add $0x14,%esp 0x08048500 <+48>: pop %ebx 0x08048501 <+49>: pop %ebp 0x08048502 <+50>: ret End of assembler dump. I have gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) installed and run linux inside VirtualBox. Could this be the reason? Is anyone else experiencing this too? Greetings, Maarten |
From: Philipp K. K. <pk...@sp...> - 2012-04-24 09:04:02
|
Am 23.04.2012 23:01, schrieb Maarten Brock: > Hi all, > > When I run the regression tests I have a few hanging tests: > > gcc-torture-execute-961017-2.c hangs on ucgbz80 and ucr2k and thus > generates a timeout. It passes for ucz80 and ucz180. This fails with a > proper timeout. > > But gcc-torture-execute-930529-1.c hangs when running test-host. And it > does not timeout! > It fails after printing __prints("Running testTortureExecute\n"); and I > see nothing wrong in the generated asm. > > (gdb) disassemble > Dump of assembler code for function __prints: > 0x080484d0 <+0>: push %ebp > 0x080484d1 <+1>: mov %esp,%ebp > 0x080484d3 <+3>: push %ebx > 0x080484d4 <+4>: sub $0x14,%esp > => 0x080484d7 <+7>: mov 0x8(%ebp),%ebx > 0x080484da <+10>: movzbl (%ebx),%eax > 0x080484dd <+13>: test %al,%al > 0x080484df <+15>: je 0x80484fd <__prints+45> > 0x080484e1 <+17>: lea 0x0(%esi,%eiz,1),%esi > 0x080484e8 <+24>: movsbl %al,%eax > 0x080484eb <+27>: add $0x1,%ebx > 0x080484ee <+30>: mov %eax,(%esp) > 0x080484f1 <+33>: call 0x8048760 <_putchar> > 0x080484f6 <+38>: movzbl (%ebx),%eax > 0x080484f9 <+41>: test %al,%al > 0x080484fb <+43>: jne 0x80484e8 <__prints+24> > 0x080484fd <+45>: add $0x14,%esp > 0x08048500 <+48>: pop %ebx > 0x08048501 <+49>: pop %ebp > 0x08048502 <+50>: ret > End of assembler dump. > > I have gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) installed and run > linux inside VirtualBox. Could this be the reason? Is anyone else > experiencing this too? It all passes for me. gcc 4.4.3 was released in 2010. gcc-torture-execute-930529-1.c is a gcc bug from 1993. Could you post the asm output you get for gcc-torture-execute-961017-2.c on ucgbz80 and ucr2k, so I can compare to what I get? Philipp |
From: Maarten B. <sou...@ds...> - 2012-04-24 21:30:08
Attachments:
gcc-torture-execute-961017-2.asm
|
Hello Philipp, > Am 23.04.2012 23:01, schrieb Maarten Brock: > > Hi all, > > > > When I run the regression tests I have a few hanging tests: > > > > gcc-torture-execute-961017-2.c hangs on ucgbz80 and ucr2k and thus > > generates a timeout. It passes for ucz80 and ucz180. This fails with a > > proper timeout. > > > > But gcc-torture-execute-930529-1.c hangs when running test-host. And it > > does not timeout! > > It fails after printing __prints("Running testTortureExecute\n"); and I > > see nothing wrong in the generated asm. > > > > (gdb) disassemble > > Dump of assembler code for function __prints: > > 0x080484d0 <+0>: push %ebp > > 0x080484d1 <+1>: mov %esp,%ebp > > 0x080484d3 <+3>: push %ebx > > 0x080484d4 <+4>: sub $0x14,%esp > > => 0x080484d7 <+7>: mov 0x8(%ebp),%ebx > > 0x080484da <+10>: movzbl (%ebx),%eax > > 0x080484dd <+13>: test %al,%al > > 0x080484df <+15>: je 0x80484fd <__prints+45> > > 0x080484e1 <+17>: lea 0x0(%esi,%eiz,1),%esi > > 0x080484e8 <+24>: movsbl %al,%eax > > 0x080484eb <+27>: add $0x1,%ebx > > 0x080484ee <+30>: mov %eax,(%esp) > > 0x080484f1 <+33>: call 0x8048760 <_putchar> > > 0x080484f6 <+38>: movzbl (%ebx),%eax > > 0x080484f9 <+41>: test %al,%al > > 0x080484fb <+43>: jne 0x80484e8 <__prints+24> > > 0x080484fd <+45>: add $0x14,%esp > > 0x08048500 <+48>: pop %ebx > > 0x08048501 <+49>: pop %ebp > > 0x08048502 <+50>: ret > > End of assembler dump. > > > > I have gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) installed and run > > linux inside VirtualBox. Could this be the reason? Is anyone else > > experiencing this too? > > It all passes for me. gcc 4.4.3 was released in 2010. > gcc-torture-execute-930529-1.c is a gcc bug from 1993. Yes, that is why I was very surprised. I also ran it in a proxmox virtual machine with debian and gcc 4.4.5 and the same happens. > Could you post the asm output you get for gcc-torture-execute-961017-2.c > on ucgbz80 and ucr2k, so I can compare to what I get? The compiled asm is attached. And while we're discussing regression tests. There are a lot of failing snapshots. Maarten |
From: Philipp K. K. <pk...@sp...> - 2012-04-25 08:58:33
|
Am 24.04.2012 23:30, schrieb Maarten Brock: > The compiled asm is attached. It is identical to the asm I get with current trunk. The test passes for me: touch tests/gcc-torture-execute-961017-2.c && time make test-ucgbz80 Running ucgbz80 regression tests gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 3278, t: 8656305) Summary for 'ucgbz80': 0 failures, 6849 tests, 1539 test cases, 4559600 bytes, 28496866 ticks real 0m3.472s user 0m1.164s sys 0m2.188s This is on an Intel(R) Core(TM) i5 CPU 670 @ 3.47GHz. Philipp |
From: Philipp K. K. <pk...@sp...> - 2012-04-25 17:11:24
|
On 24.04.2012 23:30, Maarten Brock wrote: > > And while we're discussing regression tests. There are a > lot of failing snapshots. Yes, I'll try to look into them a bit tomorrow, maybe setup a virtual machine, like you have (using qemu). The most recent gbz80 one should be fixed by my commit this morning. Philipp |
From: Maarten B. <sou...@ds...> - 2012-04-25 20:17:34
|
Hi again, > Am 24.04.2012 23:30, schrieb Maarten Brock: > > The compiled asm is attached. > > It is identical to the asm I get with current trunk. The test passes for me: > > touch tests/gcc-torture-execute-961017-2.c && time make test-ucgbz80 > Running ucgbz80 regression tests > gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 3278, t: 8656305) > Summary for 'ucgbz80': 0 failures, 6849 tests, 1539 test cases, 4559600 > bytes, 28496866 ticks > > > real 0m3.472s > user 0m1.164s > sys 0m2.188s > > This is on an Intel(R) Core(TM) i5 CPU 670 @ 3.47GHz. I already tried extending the timeout for ucgbz80 from 20s to 30s, but that didn't help. Now I know why: $ time make test-ucgbz80 Running ucgbz80 regression tests gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 3278, t: 8656305) Summary for 'ucgbz80': 0 failures, 6849 tests, 1539 test cases, 4559615 bytes, 28665374 ticks real 0m47.556s user 0m37.402s sys 0m8.937s This is on a virtual machine in virtualbox on a Pentium 4 @ 3.0GHz. And for the ucr2k: Running ucr2k regression tests gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 2574, t: 3936475) Summary for 'ucr2k': 0 failures, 6853 tests, 1539 test cases, 3765745 bytes, 15590124 ticks real 0m23.536s user 0m17.881s sys 0m5.124s So it looks like I either need: - a new computer or - a better virtual machine server or - a faster simulator or - loooong timeouts. Maarten |
From: Borut R. <bor...@gm...> - 2012-04-26 06:19:48
|
On 25. 04. 2012 19:11, Philipp Klaus Krause wrote: > On 24.04.2012 23:30, Maarten Brock wrote: > >> And while we're discussing regression tests. There are a >> lot of failing snapshots. > Yes, I'll try to look into them a bit tomorrow, maybe setup a virtual > machine, like you have (using qemu). The most recent gbz80 one should be > fixed by my commit this morning. > > Philipp Why not using the snapshot build machines? You have access to them (if something is still missing, just let me know). I created a svn_snapshots directory on each snapshot build machine, containing sdcc directory with sdcc svn snapshot and do_config[XXX].sh shell script which creates the sdcc[_XXX].build directory and runs configure in it. So you have to: cd ~/svn_snapshots/sdcc svn update # update the svn snapshot cd .. rm -rf sdcc.build # (optionally) remove old build directory ./do_config 2>&1 | tee clog.txt # create sdcc.build directory & run configure into it, results in clog.txt cd sdcc.build # change dir to sdcc.build make 2>&1 | tee mlog.txt # run make, results in mlog.txt to run regression tests: cd ~/svn_snapshots/sdcc/support/regression # change dir to sdcc.build make 2>&1 | tee mlog.txt # run make, results in mlog.txt Borut |
From: Philipp K. K. <pk...@sp...> - 2012-04-26 16:32:50
|
Am 25.04.2012 22:17, schrieb Maarten Brock: > Hi again, > >> Am 24.04.2012 23:30, schrieb Maarten Brock: >>> The compiled asm is attached. >> >> It is identical to the asm I get with current trunk. The test passes for me: >> >> touch tests/gcc-torture-execute-961017-2.c && time make test-ucgbz80 >> Running ucgbz80 regression tests >> gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 3278, t: 8656305) >> Summary for 'ucgbz80': 0 failures, 6849 tests, 1539 test cases, 4559600 >> bytes, 28496866 ticks >> >> >> real 0m3.472s >> user 0m1.164s >> sys 0m2.188s >> >> This is on an Intel(R) Core(TM) i5 CPU 670 @ 3.47GHz. > > I already tried extending the timeout for ucgbz80 from 20s to 30s, but > that didn't help. Now I know why: > > $ time make test-ucgbz80 > Running ucgbz80 regression tests > gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 3278, t: > 8656305) > Summary for 'ucgbz80': 0 failures, 6849 tests, 1539 test cases, 4559615 > bytes, 28665374 ticks > > real 0m47.556s > user 0m37.402s > sys 0m8.937s > > This is on a virtual machine in virtualbox on a Pentium 4 @ 3.0GHz. > > And for the ucr2k: > Running ucr2k regression tests > gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 2574, t: > 3936475) > Summary for 'ucr2k': 0 failures, 6853 tests, 1539 test cases, 3765745 > bytes, 15590124 ticks > > real 0m23.536s > user 0m17.881s > sys 0m5.124s > > So it looks like I either need: > - a new computer or > - a better virtual machine server or > - a faster simulator or > - loooong timeouts. > > Maarten Weirdly I see a similar problem when running Debian GNU/Hurd inside a qemu-kvm vm: Running the simulator takes a really long time, but neither the host nor the guest show particularly high cpu usage. Maybe there's something in our simulator that just happen to be very inefficient when running on an OS inside a VM? Philipp |
From: Philipp K. K. <pk...@sp...> - 2012-04-26 16:47:12
|
Am 26.04.2012 18:32, schrieb Philipp Klaus Krause: > Weirdly I see a similar problem when running Debian GNU/Hurd inside a > qemu-kvm vm: Running the simulator takes a really long time, but neither > the host nor the guest show particularly high cpu usage. Maybe there's > something in our simulator that just happen to be very inefficient when > running on an OS inside a VM? In particular, I see very low cpu usage by the simulator when run inside the vm, but it nevertheless takes a lot of time. Philipp |
From: Leland M. <ljm...@so...> - 2012-04-28 02:02:40
|
Hi, I have two questions about this: 1) What guest OS / OSes are running on that virtual machine? Are they simulated linux, windows, or other ? 2) Would Maarten try running the simulator directly (without the overhead of make) on the virtualbox machine: time ../../sim/ucsim/z80.src/sz80.src/sz80.exe -tr2k gen/ucr2k/gcc-torture-execute-961017-2/gcc-torture-execute-961017-2.ihx < ports/ucr2k/uCsim.cmd On cygwin, "make" has an order of magnitude more overhead vs. building on linux as result of differences in how memory is managed in linux vs windows. Thanks, Leland On 4/26/2012 12:32 PM, Philipp Klaus Krause wrote: > gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 3278, t: > 8656305) > Summary for 'ucgbz80': 0 failures, 6849 tests, 1539 test cases, 4559615 > bytes, 28665374 ticks > > real 0m47.556s > user 0m37.402s > sys 0m8.937s > > This is on a virtual machine in virtualbox on a Pentium 4 @ 3.0GHz. > > And for the ucr2k: > Running ucr2k regression tests > gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 2574, t: > 3936475) > Summary for 'ucr2k': 0 failures, 6853 tests, 1539 test cases, 3765745 > bytes, 15590124 ticks > > real 0m23.536s > user 0m17.881s > sys 0m5.124s > > ... > > Maarten > Weirdly I see a similar problem when running Debian GNU/Hurd inside a > qemu-kvm vm: Running the simulator takes a really long time, but neither > the host nor the guest show particularly high cpu usage. Maybe there's > something in our simulator that just happen to be very inefficient when > running on an OS inside a VM? > > Philipp > > |
From: Philipp K. K. <pk...@sp...> - 2012-04-27 14:52:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.04.2012 08:19, Borut Ražem wrote: > > Why not using the snapshot build machines? You have access to them > (if something is still missing, just let me know). 1) I cannot log into the snapshot machines, and do not know why. I can log into other machines (my Debian GNU/Linux box at university) using the same key. ssh debug output from ssh -vvv can be found below. 2) I wanted to try Hurd in a virtual machine some time anyway, so these failures seemed like a good excuse. So far I've made someo changes to sdcc that make sdcc compile and work on Hurd (already commited to trunk), but there's an issue with our simulator that makes running regression tests _really_ slow. Philipp philipp@notebook3:~$ ssh -vvv sdc...@my... OpenSSH_5.9p1 Debian-5, OpenSSL 1.0.1b 26 Apr 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to mypants.neurotica.com [50.73.179.2] port 22. debug1: Connection established. debug1: identity file /home/philipp/.ssh/id_rsa type -1 debug1: identity file /home/philipp/.ssh/id_rsa-cert type -1 debug1: identity file /home/philipp/.ssh/id_dsa type -1 debug1: identity file /home/philipp/.ssh/id_dsa-cert type -1 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/philipp/.ssh/id_ecdsa" as a RSA1 public key debug1: identity file /home/philipp/.ssh/id_ecdsa type 3 debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-521 debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-521 debug1: identity file /home/philipp/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.0 NetBSD_Secure_Shell-20080403-hpn13v1 debug1: match: OpenSSH_5.0 NetBSD_Secure_Shell-20080403-hpn13v1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "mypants.neurotica.com" from file "/home/philipp/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/philipp/.ssh/known_hosts:7 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh...@op...,ssh...@op...,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh...@op...,ssh...@op...,ssh-rsa,ecd...@op...,ecd...@op...,ecd...@op...,ssh...@op...,ssh...@op...,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rij...@ly... debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rij...@ly... debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,um...@op...,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,um...@op...,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zl...@op...,zlib debug2: kex_parse_kexinit: none,zl...@op...,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rij...@ly...,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rij...@ly...,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zl...@op... debug2: kex_parse_kexinit: none,zl...@op... debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 122/256 debug2: bits set: 500/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 4d:5c:e7:c3:d9:f3:d1:47:18:d1:67:88:22:ed:f6:69 debug3: load_hostkeys: loading entries for host "mypants.neurotica.com" from file "/home/philipp/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/philipp/.ssh/known_hosts:7 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "50.73.179.2" from file "/home/philipp/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/philipp/.ssh/known_hosts:8 debug3: load_hostkeys: loaded 1 keys debug1: Host 'mypants.neurotica.com' is known and matches the RSA host key. debug1: Found key in /home/philipp/.ssh/known_hosts:7 debug2: bits set: 496/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/philipp/.ssh/id_rsa ((nil)) debug2: key: /home/philipp/.ssh/id_dsa ((nil)) debug2: key: /home/philipp/.ssh/id_ecdsa (0x7fb584234160) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/philipp/.ssh/id_rsa debug3: no such identity: /home/philipp/.ssh/id_rsa debug1: Trying private key: /home/philipp/.ssh/id_dsa debug3: no such identity: /home/philipp/.ssh/id_dsa debug1: Offering ECDSA public key: /home/philipp/.ssh/id_ecdsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 sdcc_builder@NEUROTICA.COM's Password: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+asqkACgkQbtUV+xsoLpoo/QCeKj6X1ENtfTJDGsNf7lVmaCXo 0c4AoJsHBX/LSYxUSMwcMABn4FzTTEmb =/J3W -----END PGP SIGNATURE----- |
From: Borut R. <bor...@gm...> - 2012-04-27 17:54:58
|
Hi Philipp, have you tried to log in also to other build machines? I suspect that ecdsa type key files are not supported on NetBSD. Can you please generate the dsa tpe ssh key files and send me the id_dsa.pub public file? $ ssh-keygen -t dsa Borut On 27. 04. 2012 16:52, Philipp Klaus Krause wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 26.04.2012 08:19, Borut Ražem wrote: >> Why not using the snapshot build machines? You have access to them >> (if something is still missing, just let me know). > 1) I cannot log into the snapshot machines, and do not know why. I can > log into other machines (my Debian GNU/Linux box at university) using > the same key. ssh debug output from ssh -vvv can be found below. > > 2) I wanted to try Hurd in a virtual machine some time anyway, so > these failures seemed like a good excuse. So far I've made someo > changes to sdcc that make sdcc compile and work on Hurd (already > commited to trunk), but there's an issue with our simulator that makes > running regression tests _really_ slow. > > Philipp > > philipp@notebook3:~$ ssh -vvv sdc...@my... > OpenSSH_5.9p1 Debian-5, OpenSSL 1.0.1b 26 Apr 2012 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to mypants.neurotica.com [50.73.179.2] port 22. > debug1: Connection established. > debug1: identity file /home/philipp/.ssh/id_rsa type -1 > debug1: identity file /home/philipp/.ssh/id_rsa-cert type -1 > debug1: identity file /home/philipp/.ssh/id_dsa type -1 > debug1: identity file /home/philipp/.ssh/id_dsa-cert type -1 > debug3: Incorrect RSA1 identifier > debug3: Could not load "/home/philipp/.ssh/id_ecdsa" as a RSA1 public key > debug1: identity file /home/philipp/.ssh/id_ecdsa type 3 > debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-521 > debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-521 > debug1: identity file /home/philipp/.ssh/id_ecdsa-cert type -1 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_5.0 NetBSD_Secure_Shell-20080403-hpn13v1 > debug1: match: OpenSSH_5.0 NetBSD_Secure_Shell-20080403-hpn13v1 pat > OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5 > debug2: fd 3 setting O_NONBLOCK > debug3: load_hostkeys: loading entries for host > "mypants.neurotica.com" from file "/home/philipp/.ssh/known_hosts" > debug3: load_hostkeys: found key type RSA in file > /home/philipp/.ssh/known_hosts:7 > debug3: load_hostkeys: loaded 1 keys > debug3: order_hostkeyalgs: prefer hostkeyalgs: > ssh...@op...,ssh...@op...,ssh-rsa > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: > ssh...@op...,ssh...@op...,ssh-rsa,ecd...@op...,ecd...@op...,ecd...@op...,ssh...@op...,ssh...@op...,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rij...@ly... > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rij...@ly... > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,um...@op...,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,um...@op...,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zl...@op...,zlib > debug2: kex_parse_kexinit: none,zl...@op...,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rij...@ly...,aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rij...@ly...,aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zl...@op... > debug2: kex_parse_kexinit: none,zl...@op... > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_setup: found hmac-md5 > debug1: kex: server->client aes128-ctr hmac-md5 none > debug2: mac_setup: found hmac-md5 > debug1: kex: client->server aes128-ctr hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: dh_gen_key: priv key bits set: 122/256 > debug2: bits set: 500/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Server host key: RSA > 4d:5c:e7:c3:d9:f3:d1:47:18:d1:67:88:22:ed:f6:69 > debug3: load_hostkeys: loading entries for host > "mypants.neurotica.com" from file "/home/philipp/.ssh/known_hosts" > debug3: load_hostkeys: found key type RSA in file > /home/philipp/.ssh/known_hosts:7 > debug3: load_hostkeys: loaded 1 keys > debug3: load_hostkeys: loading entries for host "50.73.179.2" from > file "/home/philipp/.ssh/known_hosts" > debug3: load_hostkeys: found key type RSA in file > /home/philipp/.ssh/known_hosts:8 > debug3: load_hostkeys: loaded 1 keys > debug1: Host 'mypants.neurotica.com' is known and matches the RSA host > key. > debug1: Found key in /home/philipp/.ssh/known_hosts:7 > debug2: bits set: 496/1024 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: Roaming not allowed by server > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /home/philipp/.ssh/id_rsa ((nil)) > debug2: key: /home/philipp/.ssh/id_dsa ((nil)) > debug2: key: /home/philipp/.ssh/id_ecdsa (0x7fb584234160) > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug3: start over, passed a different list > publickey,password,keyboard-interactive > debug3: preferred > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Trying private key: /home/philipp/.ssh/id_rsa > debug3: no such identity: /home/philipp/.ssh/id_rsa > debug1: Trying private key: /home/philipp/.ssh/id_dsa > debug3: no such identity: /home/philipp/.ssh/id_dsa > debug1: Offering ECDSA public key: /home/philipp/.ssh/id_ecdsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug2: we did not send a packet, disable method > debug3: authmethod_lookup keyboard-interactive > debug3: remaining preferred: password > debug3: authmethod_is_enabled keyboard-interactive > debug1: Next authentication method: keyboard-interactive > debug2: userauth_kbdint > debug2: we sent a keyboard-interactive packet, wait for reply > debug2: input_userauth_info_req > debug2: input_userauth_info_req: num_prompts 1 > sdcc_builder@NEUROTICA.COM's Password: > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+asqkACgkQbtUV+xsoLpoo/QCeKj6X1ENtfTJDGsNf7lVmaCXo > 0c4AoJsHBX/LSYxUSMwcMABn4FzTTEmb > =/J3W > -----END PGP SIGNATURE----- > |
From: Philipp K. K. <pk...@sp...> - 2012-04-27 18:07:57
|
On 27.04.2012 19:54, Borut Ražem wrote: > Hi Philipp, > > have you tried to log in also to other build machines? Yes. None of them works for me. > I suspect that ecdsa type key files are not supported on NetBSD. AFAIK openssh has supported ecdsa at least since 5.7, which was released in january 2011. Philipp |
From: Borut R. <bor...@gm...> - 2012-04-28 05:44:32
|
On 27. 04. 2012 20:07, Philipp Klaus Krause wrote: > On 27.04.2012 19:54, Borut Ražem wrote: >> Hi Philipp, >> >> have you tried to log in also to other build machines? > Yes. None of them works for me. > >> I suspect that ecdsa type key files are not supported on NetBSD. > AFAIK openssh has supported ecdsa at least since 5.7, which was released > in january 2011. On NetBSD sparc64: $ sshd -V sshd: unknown option -- V OpenSSH_5.0 NetBSD_Secure_Shell-20080403, OpenSSL 0.9.9-dev 09 May 2008 So it is older then 5.7. The support of ecdsa is not mentioned in man sshd. Please generate dsa keys and send me the public one. Borut |
From: Borut R. <bor...@gm...> - 2012-04-28 10:13:12
|
On 28. 04. 2012 07:44, Borut Ražem wrote: > On 27. 04. 2012 20:07, Philipp Klaus Krause wrote: >> On 27.04.2012 19:54, Borut Ražem wrote: >>> Hi Philipp, >>> >>> have you tried to log in also to other build machines? >> Yes. None of them works for me. I verified the sshd versions on all snapshot build machines: they are all older then 5.7 (from 5.0 to 5.5p1). That's why none of them work with ecdsa keys. Borut |
From: Maarten B. <sou...@ds...> - 2012-04-28 18:51:20
|
Hello Leland, > 1) What guest OS / OSes are running on that virtual machine? > Are they simulated linux, windows, or other ? Yes, I have ubuntu linux on the virtual machine. > 2) Would Maarten try running the simulator directly > (without the overhead of make) on the virtualbox machine: > > time ../../sim/ucsim/z80.src/sz80.src/sz80.exe -tr2k > > gen/ucr2k/gcc-torture-execute-961017-2/gcc-torture-execute-961017-2.ihx < > ports/ucr2k/uCsim.cmd Well, it is a little shorter, but there is also less to do as both make and python are not involved now. real 0m19.745s user 0m16.453s sys 0m3.144s > On cygwin, "make" has an order of magnitude more overhead vs. building > on linux > as result of differences in how memory is managed in linux vs windows. Cygwin is not involved here. But I do have an idea why the simulator is slow though not necessarily slower on a VM. It uses a lot of malloc's because every target memory cell is encapsulated in a C++ class with a constructor. And malloc is notoriously slow. Maarten > Thanks, > Leland > > > On 4/26/2012 12:32 PM, Philipp Klaus Krause wrote: > > gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 3278, t: > > 8656305) > > Summary for 'ucgbz80': 0 failures, 6849 tests, 1539 test cases, 4559615 > > bytes, 28665374 ticks > > > > real 0m47.556s > > user 0m37.402s > > sys 0m8.937s > > > > This is on a virtual machine in virtualbox on a Pentium 4 @ 3.0GHz. > > > > And for the ucr2k: > > Running ucr2k regression tests > > gcc-torture-execute-961017-2 (f: 0, t: 0, c: 1, b: 2574, t: > > 3936475) > > Summary for 'ucr2k': 0 failures, 6853 tests, 1539 test cases, 3765745 > > bytes, 15590124 ticks > > > > real 0m23.536s > > user 0m17.881s > > sys 0m5.124s > > > > ... > > > > Maarten > > Weirdly I see a similar problem when running Debian GNU/Hurd inside a > > qemu-kvm vm: Running the simulator takes a really long time, but neither > > the host nor the guest show particularly high cpu usage. Maybe there's > > something in our simulator that just happen to be very inefficient when > > running on an OS inside a VM? > > > > Philipp |
From: Leland M. <ljm...@so...> - 2012-04-29 00:12:39
|
The "user time" of 16.453s should compare to the earlier time of 17.881s. Which definitely pins it down to ucsim running slow. And I'm really not sure why the memory cells are individually malloc'd, but they currently are. If you are curious, those malloc happen at load time (before the 'run' command), so you time starting ucsim, and then exiting within executing any commands to test your theory that most of the time used is malloc being slow. You would just need to make a copy of uCsim.cmd, remove the line with 'run' and time the execution. -Leland On 4/28/2012 2:51 PM, Maarten Brock wrote: > Well, it is a little shorter, but there is also less to > do as both make and python are not involved now. > > real 0m19.745s > user 0m16.453s > sys 0m3.144s > > > Cygwin is not involved here. But I do have an idea why > the simulator is slow though not necessarily slower on a > VM. It uses a lot of malloc's because every target > memory cell is encapsulated in a C++ class with a > constructor. And malloc is notoriously slow. > > Maarten > > |
From: Maarten B. <sou...@ds...> - 2012-04-29 08:47:51
|
Hi, > If you are curious, those malloc happen at load time (before the 'run' > command), so you time starting ucsim, and then exiting within executing any > commands to test your theory that most of the time used is malloc being slow. > > You would just need to make a copy of uCsim.cmd, remove the line with > 'run' and time the execution. real 0m0.154s user 0m0.012s sys 0m0.032s So, not much time is spent there. Maarten > On 4/28/2012 2:51 PM, Maarten Brock wrote: > > Well, it is a little shorter, but there is also less to > > do as both make and python are not involved now. > > > > real 0m19.745s > > user 0m16.453s > > sys 0m3.144s > > > > > > Cygwin is not involved here. But I do have an idea why > > the simulator is slow though not necessarily slower on a > > VM. It uses a lot of malloc's because every target > > memory cell is encapsulated in a C++ class with a > > constructor. And malloc is notoriously slow. > > > > Maarten > > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Raphael N. <rn...@we...> - 2012-04-29 10:19:01
|
Hi, >> If you are curious, those malloc happen at load time (before the 'run' >> command), so you time starting ucsim, and then exiting within executing any >> commands to test your theory that most of the time used is malloc being slow. >> >> You would just need to make a copy of uCsim.cmd, remove the line with >> 'run' and time the execution. > > real 0m0.154s > user 0m0.012s > sys 0m0.032s > > So, not much time is spent there. > Easy to say after the fact, but that was to be expected: malloc of small amounts of memory is usually pure user-space code, which runs unaffected by virtualization (no overhead here). Virtual machines tend to have a high(er) impact on (a) system calls / thread switches / kernel- vs. usermode transitons and (b) I/O access latency (included in (a), but even more costly due to device emulation overhead). Intuitively, I would rule out (b) as the culprit here, which leaves (a) to be investigated. Does the simulator use a lot of * read(), write() (depending on the library, these might be efficiently processed on library-mmapped files or go through the VMM into the guest OS)? * select()? * inter-process communication? * multiple threads in general? * usleep() / nanosleep() / ...? * stat()? $ strace -c ucsim [args] could shed some light on this. Other useful options to strace include -F -f -T, all of which can be combined to arbitrarily verbose output ;-) Just my 2c Raphael |
From: Maarten B. <sou...@ds...> - 2012-04-30 12:01:01
|
Hi, Here's the output of strace, which took a very long time btw. strace -c ../../sim/ucsim/z80.src/sz80 -tr2k gen/ucr2k/gcc-torture-execute- 961017-2/gcc-torture-execute-961017-2.ihx < ports/ucr2k/uCsim.cmd uCsim 0.5.4, Copyright (C) 1997 Daniel Drotos, Talker Bt. uCsim comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. 2573 words read from gen/ucr2k/gcc-torture-execute-961017-2/gcc-torture- execute-961017-2.ihx 0> 0> 0> 0> 0> Simulation started, PC=0x000000 --- Running: gen/ucr2k/gcc-torture-execute-961017-2/gcc-torture-execute- 961017-2 Running testTortureExecute --- Summary: 0/0/1: 0 failed of 0 tests in 1 cases. Stop at 0x000207: (104) Breakpoint SZ-A-PNC Flags= 0x44 68 D A= 0x00 0 . 01-0-100 BC= 0x0008 [BC]= ed 237 . DE= 0x0416 [DE]= 00 0 . HL= 0x000a [HL]= ba 186 . IX= 0x0000 [IX]= c3 195 . IY= 0x0000 [IY]= c3 195 . SP= 0xfffb [SP]= d1 209 . ? 0x0207 18 fe JR #-2 F 0x000207 0> CPU state= OK PC= 0x000207 XTAL= 1.10592e+07 Total time since last reset= 0.355946 sec (3936475 clks) Time in isr = 0 sec (0 clks) 0% Time in idle= 0 sec (0 clks) 0% Max value of stack pointer= 0x000000, avg= 0x000000 0> % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 99.95 29.421685 7 3936476 select 0.01 0.004355 22 201 write 0.01 0.004001 572 7 open 0.01 0.003952 329 12 12 ioctl 0.01 0.001688 77 22 mmap2 0.00 0.000000 0 8 read 0.00 0.000000 0 9 close 0.00 0.000000 0 1 execve 0.00 0.000000 0 7 7 access 0.00 0.000000 0 13 brk 0.00 0.000000 0 4 munmap 0.00 0.000000 0 7 mprotect 0.00 0.000000 0 9 fstat64 0.00 0.000000 0 1 set_thread_area ------ ----------- ----------- --------- --------- ---------------- 100.00 29.435681 3936777 19 total So, it's constantly stuck in select. Maarten > Hi, > > >> If you are curious, those malloc happen at load time (before the 'run' > >> command), so you time starting ucsim, and then exiting within executing any > >> commands to test your theory that most of the time used is malloc being slow. > >> > >> You would just need to make a copy of uCsim.cmd, remove the line with > >> 'run' and time the execution. > > > > real 0m0.154s > > user 0m0.012s > > sys 0m0.032s > > > > So, not much time is spent there. > > > > Easy to say after the fact, but that was to be expected: malloc of > small amounts of memory is usually pure user-space code, which runs > unaffected by virtualization (no overhead here). > > Virtual machines tend to have a high(er) impact on (a) system calls / > thread switches / kernel- vs. usermode transitons and (b) I/O access > latency (included in (a), but even more costly due to device emulation > overhead). Intuitively, I would rule out (b) as the culprit here, > which leaves (a) to be investigated. Does the simulator use a lot of > * read(), write() (depending on the library, these might be > efficiently processed on library-mmapped files or go through the VMM > into the guest OS)? > * select()? > * inter-process communication? > * multiple threads in general? > * usleep() / nanosleep() / ...? > * stat()? > > $ strace -c ucsim [args] > > could shed some light on this. Other useful options to strace include > -F -f -T, all of which can be combined to arbitrarily verbose output > ;-) > > Just my 2c > Raphael > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Lee M. <ljm...@so...> - 2012-05-01 21:34:31
|
I checked in a small change to ucsim that should help with this. Under the cygwin environment it makes a small improvent, but should have a big improvement for the virtual machine since most of the time is spent in select( ). -Leland On 4/30/2012 8:00 AM, Maarten Brock wrote: > Hi, > > Here's the output of strace, which took a very long time > btw. > > strace -c ../../sim/ucsim/z80.src/sz80 -tr2k gen/ucr2k/gcc-torture-execute- > 961017-2/gcc-torture-execute-961017-2.ihx< ports/ucr2k/uCsim.cmd > uCsim 0.5.4, Copyright (C) 1997 Daniel Drotos, Talker Bt. > uCsim comes with ABSOLUTELY NO WARRANTY; for details type `show > w'. > This is free software, and you are welcome to redistribute it > under certain conditions; type `show c' for details. > 2573 words read from gen/ucr2k/gcc-torture-execute-961017-2/gcc-torture- > execute-961017-2.ihx > 0> 0> 0> 0> 0> Simulation started, PC=0x000000 > --- Running: gen/ucr2k/gcc-torture-execute-961017-2/gcc-torture-execute- > 961017-2 > Running testTortureExecute > --- Summary: 0/0/1: 0 failed of 0 tests in 1 cases. > Stop at 0x000207: (104) Breakpoint > SZ-A-PNC Flags= 0x44 68 D A= 0x00 0 . > 01-0-100 > BC= 0x0008 [BC]= ed 237 . DE= 0x0416 [DE]= 00 0 . HL= 0x000a [HL]= > ba 186 . > IX= 0x0000 [IX]= c3 195 . IY= 0x0000 [IY]= c3 195 . SP= 0xfffb [SP]= d1 > 209 . > ? 0x0207 18 fe JR #-2 > F 0x000207 > 0> CPU state= OK PC= 0x000207 XTAL= 1.10592e+07 > Total time since last reset= 0.355946 sec (3936475 clks) > Time in isr = 0 sec (0 clks) 0% > Time in idle= 0 sec (0 clks) 0% > Max value of stack pointer= 0x000000, avg= 0x000000 > 0> % time seconds usecs/call calls errors syscall > ------ ----------- ----------- --------- --------- ---------------- > 99.95 29.421685 7 3936476 select > 0.01 0.004355 22 201 write > 0.01 0.004001 572 7 open > 0.01 0.003952 329 12 12 ioctl > 0.01 0.001688 77 22 mmap2 > 0.00 0.000000 0 8 read > 0.00 0.000000 0 9 close > 0.00 0.000000 0 1 execve > 0.00 0.000000 0 7 7 access > 0.00 0.000000 0 13 brk > 0.00 0.000000 0 4 munmap > 0.00 0.000000 0 7 mprotect > 0.00 0.000000 0 9 fstat64 > 0.00 0.000000 0 1 set_thread_area > ------ ----------- ----------- --------- --------- ---------------- > 100.00 29.435681 3936777 19 total > > So, it's constantly stuck in select. > > Maarten > > |
From: Borut R. <bor...@gm...> - 2012-05-02 11:47:51
|
Hi Leland, please pay attention to the coding style when you commit changes: - use spaces instead tabs - use if (...) { ... } else { ... } instead of if (...) { ... } else { ... } You could also use a #define or const instead of hardcoded 50, for example: const unsigned input_check_freq = 50; P.S.: It is always difficult for me to bother the developers for such "irrelevant" matters, but OTOH it doesn't take much to maintain the code "clean". No offence, Borut On Wed, May 2, 2012 at 12:44 AM, Lee Morrison < ljm...@so...> wrote: > I checked in a small change to ucsim that should help with this. > Under the cygwin environment it makes a small improvent, but should > have a big improvement for the virtual machine since most of the time > is spent in select( ). > > -Leland |
From: Maarten B. <sou...@ds...> - 2012-05-01 23:04:52
|
Leland, This is great! real 0m1.607s user 0m1.348s sys 0m0.136s % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 99.15 1.880768 24 78737 select 0.60 0.011313 56 201 write 0.25 0.004736 215 22 mmap2 0.00 0.000000 0 8 read 0.00 0.000000 0 7 open 0.00 0.000000 0 9 close 0.00 0.000000 0 1 execve 0.00 0.000000 0 7 7 access 0.00 0.000000 0 13 brk 0.00 0.000000 0 12 12 ioctl 0.00 0.000000 0 4 munmap 0.00 0.000000 0 7 mprotect 0.00 0.000000 0 9 fstat64 0.00 0.000000 0 1 set_thread_area ------ ----------- ----------- --------- --------- ---------------- 100.00 1.896817 79038 19 total Thank you very much! Maarten > I checked in a small change to ucsim that should help with this. > Under the cygwin environment it makes a small improvent, but should > have a big improvement for the virtual machine since most of the time > is spent in select( ). > > -Leland > > On 4/30/2012 8:00 AM, Maarten Brock wrote: > > Hi, > > > > Here's the output of strace, which took a very long time > > btw. > > > > strace -c ../../sim/ucsim/z80.src/sz80 -tr2k gen/ucr2k/gcc-torture-execute- > > 961017-2/gcc-torture-execute-961017-2.ihx< ports/ucr2k/uCsim.cmd > > uCsim 0.5.4, Copyright (C) 1997 Daniel Drotos, Talker Bt. > > uCsim comes with ABSOLUTELY NO WARRANTY; for details type `show > > w'. > > This is free software, and you are welcome to redistribute it > > under certain conditions; type `show c' for details. > > 2573 words read from gen/ucr2k/gcc-torture-execute-961017-2/gcc-torture- > > execute-961017-2.ihx > > 0> 0> 0> 0> 0> Simulation started, PC=0x000000 > > --- Running: gen/ucr2k/gcc-torture-execute-961017-2/gcc-torture-execute- > > 961017-2 > > Running testTortureExecute > > --- Summary: 0/0/1: 0 failed of 0 tests in 1 cases. > > Stop at 0x000207: (104) Breakpoint > > SZ-A-PNC Flags= 0x44 68 D A= 0x00 0 . > > 01-0-100 > > BC= 0x0008 [BC]= ed 237 . DE= 0x0416 [DE]= 00 0 . HL= 0x000a [HL]= > > ba 186 . > > IX= 0x0000 [IX]= c3 195 . IY= 0x0000 [IY]= c3 195 . SP= 0xfffb [SP]= d1 > > 209 . > > ? 0x0207 18 fe JR #-2 > > F 0x000207 > > 0> CPU state= OK PC= 0x000207 XTAL= 1.10592e+07 > > Total time since last reset= 0.355946 sec (3936475 clks) > > Time in isr = 0 sec (0 clks) 0% > > Time in idle= 0 sec (0 clks) 0% > > Max value of stack pointer= 0x000000, avg= 0x000000 > > 0> % time seconds usecs/call calls errors syscall > > ------ ----------- ----------- --------- --------- ---------------- > > 99.95 29.421685 7 3936476 select > > 0.01 0.004355 22 201 write > > 0.01 0.004001 572 7 open > > 0.01 0.003952 329 12 12 ioctl > > 0.01 0.001688 77 22 mmap2 > > 0.00 0.000000 0 8 read > > 0.00 0.000000 0 9 close > > 0.00 0.000000 0 1 execve > > 0.00 0.000000 0 7 7 access > > 0.00 0.000000 0 13 brk > > 0.00 0.000000 0 4 munmap > > 0.00 0.000000 0 7 mprotect > > 0.00 0.000000 0 9 fstat64 > > 0.00 0.000000 0 1 set_thread_area > > ------ ----------- ----------- --------- --------- ---------------- > > 100.00 29.435681 3936777 19 total > > > > So, it's constantly stuck in select. > > > > Maarten > > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Philipp K. K. <pk...@sp...> - 2012-05-02 07:34:47
Attachments:
id_rsa.pub
|
Am 28.04.2012 12:13, schrieb Borut Ražem: > On 28. 04. 2012 07:44, Borut Ražem wrote: >> On 27. 04. 2012 20:07, Philipp Klaus Krause wrote: >>> On 27.04.2012 19:54, Borut Ražem wrote: >>>> Hi Philipp, >>>> >>>> have you tried to log in also to other build machines? >>> Yes. None of them works for me. > > I verified the sshd versions on all snapshot build machines: they are > all older then 5.7 (from 5.0 to 5.5p1). That's why none of them work > with ecdsa keys. > > Borut Ok, here's an RSA key. Philipp |
From: Borut R. <bor...@gm...> - 2012-05-02 12:31:42
|
Public key added to all build machines except mirror-doors (Mac OS X/ppc) since it is currently not accessible. Phillip lease try it and let me know if you are able to access the machines. Borut On 02. 05. 2012 09:34, Philipp Klaus Krause wrote: > Am 28.04.2012 12:13, schrieb Borut Ražem: >> On 28. 04. 2012 07:44, Borut Ražem wrote: >>> On 27. 04. 2012 20:07, Philipp Klaus Krause wrote: >>>> On 27.04.2012 19:54, Borut Ražem wrote: >>>>> Hi Philipp, >>>>> >>>>> have you tried to log in also to other build machines? >>>> Yes. None of them works for me. >> I verified the sshd versions on all snapshot build machines: they are >> all older then 5.7 (from 5.0 to 5.5p1). That's why none of them work >> with ecdsa keys. >> >> Borut > Ok, here's an RSA key. > > Philipp > |