ps performance acorn32 (was Re: Panic on acorn32 current)
Take back the performance comment. Something is monumentally wrong with the 8.0-BETA ps. It takes ages to run: For comparison: # file /bin/ps /bin/ps: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for NetBSD 6.99.40, compiled for: arm, not stripped # time ps>/dev/null 0.22 real 0.02 user 0.18 sys And in a chroot with the 8.0-BETA userland: # file /bin/ps /bin/ps: ELF 32-bit LSB shared object, ARM, version 1 (ARM), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 8.0, compiled for: arm, not stripped # time ps >/dev/null 8.19 real 1.25 user 6.62 sys # I'd guess the bug is in the libraries as running the 8.0 ps with the 6.99.40 libraries performs at the same speed as the native 6.99.40 binary. Not a bug. ktrace showed what was going on. Massive repeated lstats of /dev. I'd not run /etc/rc.d/sysdb start in the chroot. Once that was done ps worked entirely sensibly with no odd performance issues. :). Apologies for the false alarm. Mike
daily CVS update output
Updating src tree: P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/Makefile P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/aes-mips.S U src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/aes-mips64.S P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/bn.inc P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/crypto.inc P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/mips-mont.S U src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/mips-mont64.S U src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/mips64.S U src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/poly1305-mips64.S U src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/poly1305.inc P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/sha.inc U src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/sha1-mips64.S P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/sha512-mips.S U src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/sha512-mips64.S P src/doc/BRANCHES P src/doc/CHANGES.prev P src/games/fish/fish.c P src/lib/libc/sys/ptrace.2 P src/lib/libm/noieee_src/n_exp2.c P src/lib/libm/noieee_src/n_jn.c P src/share/man/man4/ugen.4 P src/share/mk/bsd.own.mk P src/sys/arch/amiga/dev/grf_et.c P src/sys/arch/x86/include/cacheinfo.h P src/sys/arch/x86/include/specialreg.h P src/sys/arch/x86/x86/procfs_machdep.c P src/sys/ddb/db_autoconf.c P src/sys/dev/mii/mii_physubr.c P src/sys/dev/usb/files.usb P src/sys/dev/usb/ugen.c P src/sys/kern/sys_ptrace_common.c P src/sys/netipsec/ipsec_mbuf.c P src/sys/netipsec/ipsec_output.c P src/sys/sys/ptrace.h P src/tests/lib/libc/sys/t_ptrace_wait.c P src/usr.sbin/cpuctl/arch/i386.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 51536707 Mar 6 03:03 ls-lRA.gz
Re: Panic on acorn32 current
On 04/03/2018 17:09, Mike Pumford wrote: Finally had some time to bring my system up to date and found a problem. Got a panic at start of day (transcribed from a shot of the screen): fdc0 at pioc0 offset 0x3f0-0x3f7 irq12 drq 0x2000 uvmfault(0xf036f42c, 217000, 2) -> e Fatal kernel mode ata abort: 'Translation Fault (P)' trapframe: 0xf03ccc40 FSR=183bd007, FAR=002170ef, spsr=2093 r0 =002170ef, r1 =f02f2a65, r2 =000d, r3 =00217047 r4 =0813, r5 =0066, r6 =f02f2a65, r7 =f0351190 r8 =f02f2a64, r9 =0005, r10=f02f2a64, r11=f040 r12=f03c, ssp=f04ccc94, slr=f0027288, pc =f02d90d8 Stopped in pid 0.1 (system) at netbsd:strlcpy+0x30:strb r5, [r0], #001 db>bt 0xf038: netbsd:irq_claim+0xc 0xf03cccf0: netbsd:intr_claim+0x58 0xf03ccd28: netbsd:fdcattach+0xc0 Tracking it back it was introduced quite a while back (rev 1.13) of the file which made the section of the file containg the irq description strings read only (but the irq_claim code writes them). The following patch fixes this issue and also corrects another bug that causes the interrupt names to get corrupted in systat. The legacy irq counter code expects all the irq names to be the same length and this patch restores that behaviour. This needs a pullup to 8.0 (which has exactly the same bug). 7.1 is also impacted but I've not actually run the patch there. With this patch applied current and 8.0-BETA actually boot up and work pretty much the same as the previous rather ancient 6.99.40 kernel it was running before and there doesn't appear to be any obvious performance drop with the new code. Take back the performance comment. Something is monumentally wrong with the 8.0-BETA ps. It takes ages to run: For comparison: # file /bin/ps /bin/ps: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for NetBSD 6.99.40, compiled for: arm, not stripped # time ps>/dev/null 0.22 real 0.02 user 0.18 sys And in a chroot with the 8.0-BETA userland: # file /bin/ps /bin/ps: ELF 32-bit LSB shared object, ARM, version 1 (ARM), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 8.0, compiled for: arm, not stripped # time ps >/dev/null 8.19 real 1.25 user 6.62 sys # I'd guess the bug is in the libraries as running the 8.0 ps with the 6.99.40 libraries performs at the same speed as the native 6.99.40 binary. Mike I've spotted some other issues: 1. Slight misdetect of the NE2000 derived ethernet chip 2. Hangs when attempt is made to reboot. 3. Bad behaviour in ddb. I've run into these before and I've got some rather hacky fixes. Once they are cleaned up I'll send out another message with patches for those as well. Mike
