Re: NetBSD-amd64 8.99.26 is very slow
On Mon, Nov 26, 2018 at 2:43 PM Joerg Sonnenberger wrote: > On Mon, Nov 26, 2018 at 09:33:27PM +0100, Adam wrote: > > I am try to compile lang/rust under NetBSD-amd64 8.99.26 (today's build) > on VirtualBox. The process is extremely slow, and top is showing weird > values: > > Rust loves to eat as much cores as possible. That doesn't play well with > limited amounts of RAM. WCPU (and CPU) over 100% means concurrent > running threads. > See also: http://mail-index.netbsd.org/current-users/2018/11/06/msg034552.html > Joerg >
daily CVS update output
Updating src tree: P src/bin/sh/eval.c P src/bin/sh/redir.c P src/distrib/sets/lists/modules/md.sparc64 P src/lib/csu/arch/aarch64/crt0.S P src/lib/csu/arch/alpha/crt0.S P src/lib/csu/arch/arm/crt0.S P src/lib/csu/arch/earm/crt0.S P src/lib/csu/arch/hppa/crt0.S P src/lib/csu/arch/i386/crt0.S P src/lib/csu/arch/ia64/crt0.S P src/lib/csu/arch/m68k/crt0.S P src/lib/csu/arch/mips/crt0.S P src/lib/csu/arch/or1k/crt0.S P src/lib/csu/arch/powerpc/crt0.S P src/lib/csu/arch/riscv/crt0.S P src/lib/csu/arch/sh3/crt0.S P src/lib/csu/arch/sparc/crt0.S P src/lib/csu/arch/sparc64/crt0.S P src/lib/csu/arch/vax/crt0.S P src/lib/csu/arch/x86_64/crt0.S P src/lib/csu/common/Makefile.inc P src/lib/csu/common/crt0-common.c P src/libexec/ld.elf_so/rtld.h P src/sys/arch/arm/marvell/pci_machdep.c P src/sys/arch/arm/s3c2xx0/s3c2800_pci.c P src/sys/arch/evbarm/ifpga/ifpga_pci.c P src/sys/arch/x86/include/specialreg.h P src/sys/dev/pci/ahcisata_pci.c P src/sys/kern/kern_lwp.c P src/sys/modules/Makefile P src/sys/modules/compat_linux32/Makefile P src/sys/modules/compat_netbsd32/Makefile P src/sys/modules/compat_netbsd32_mqueue/Makefile P src/sys/modules/compat_netbsd32_nfssrv/Makefile P src/sys/modules/compat_netbsd32_ptrace/Makefile P src/sys/modules/compat_netbsd32_sysvipc/Makefile P src/usr.sbin/cpuctl/arch/aarch64.c P src/usr.sbin/cpuctl/arch/i386.c P src/usr.sbin/tprof/tprof.8 P src/usr.sbin/tprof/arch/tprof_x86.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 52364315 Nov 27 03:04 ls-lRA.gz
Re: NetBSD-amd64 8.99.26 is very slow
On Mon, Nov 26, 2018 at 09:33:27PM +0100, Adam wrote: > I am try to compile lang/rust under NetBSD-amd64 8.99.26 (today's build) on > VirtualBox. The process is extremely slow, and top is showing weird values: Rust loves to eat as much cores as possible. That doesn't play well with limited amounts of RAM. WCPU (and CPU) over 100% means concurrent running threads. Joerg
Re: apu2 SATA patch
Committed this. Le lun. 26 nov. 2018 à 22:28, Mike Pumford a écrit : > > > > On 26/11/2018 15:16, Greg Troxel wrote: > > Mike Pumford writes: > > > >> I have one of these. The msata needs needs a small patch (needs an > >> entry in the quirks table to be properly recognised as an ahci > >> controller) but other than that it seems to work. No stability issues > >> using sdhc as the system disk. > > > > Could you mail a patch, or file a PR with it? This seems like something > > that should be applied in the main tree. > > > Heres the patch. I've not yet verified IO yet but the patch is based on > how OpenBSD and FreeBSD handle the device and the detection messages > match what they report. >
apu2 SATA patch
On 26/11/2018 15:16, Greg Troxel wrote:
Mike Pumford writes:
I have one of these. The msata needs needs a small patch (needs an
entry in the quirks table to be properly recognised as an ahci
controller) but other than that it seems to work. No stability issues
using sdhc as the system disk.
Could you mail a patch, or file a PR with it? This seems like something
that should be applied in the main tree.
Heres the patch. I've not yet verified IO yet but the patch is based on
how OpenBSD and FreeBSD handle the device and the detection messages
match what they report.
Index: sys/dev/pci/ahcisata_pci.c
===
RCS file: /cvsroot/src/sys/dev/pci/ahcisata_pci.c,v
retrieving revision 1.38
diff -u -r1.38 ahcisata_pci.c
--- sys/dev/pci/ahcisata_pci.c 13 Oct 2016 17:11:09 - 1.38
+++ sys/dev/pci/ahcisata_pci.c 26 Nov 2018 21:24:56 -
@@ -194,6 +194,8 @@
AHCI_PCI_QUIRK_FORCE },
{ PCI_VENDOR_ASMEDIA, PCI_PRODUCT_ASMEDIA_ASM1061_12,
AHCI_PCI_QUIRK_FORCE },
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON_SATA,
+ AHCI_PCI_QUIRK_FORCE },
};
struct ahci_pci_softc {
NetBSD-amd64 8.99.26 is very slow
Greetings, I am try to compile lang/rust under NetBSD-amd64 8.99.26 (today's build) on VirtualBox. The process is extremely slow, and top is showing weird values: load averages: 3.41, 3.15, 3.74; up 0+00:52:47 21:30:15 24 processes: 21 sleeping, 3 on CPU CPU states: 48.3% user, 0.0% nice, 7.8% system, 0.0% interrupt, 43.8% idle Memory: 1183M Act, 32K Inact, 28K Wired, 103M Exec, 690M File, 2477M Free Swap: PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 1902 root 370 626M 419M CPU/4 6:39 7609% 372% rustc 0 root 00 0K 4416K CPU/5 5:24 0.00% 0.00% [system] 253 root 85027M 2204K kqueue/5 0:02 0.00% 0.00% syslogd 409 root 85087M 6572K select/5 0:01 0.00% 0.00% sshd 181 root 85010M 1796K kqueue/0 0:01 0.00% 0.00% dhcpcd What is going on? How to make it better? :) Kind regards, Adam
Re: failed to create llentry
co...@sdf.org writes: > Apparentlysome of the route table entries are special and should not be > deleted. indeed. > After flushing them and attempting to add a default route, I get these > messages over and over again. > > ifconfig iwm0 10.0.0.1 delete > ifconfig iwm0 10.0.0.1 > > re-creates the magical route stuff so I can add a default route again The entry with flags "UC" is a "cloning route" which instructs the kernel to perform ARP/ND and insert llinfo routes. Typically these are "UHLc". Without the C route for the subnet, a packet will still match the default route, but then there is no route for the IP addess of the gateway. Without a C route and without a UHLc route, there is no way to arp. It's the C route that directs that the prefix should be handled by arping (and on which interface). So when you are flushing routes, don't delete that one.
Re: failed to create llentry
Apparentlysome of the route table entries are special and should not be deleted. After flushing them and attempting to add a default route, I get these messages over and over again. ifconfig iwm0 10.0.0.1 delete ifconfig iwm0 10.0.0.1 re-creates the magical route stuff so I can add a default route again
mfii0 kudos to bouyer@ Was Re: dmesg | grep -c "not configured" = 240...
Thanks Manuel! [ 1.048805] mfii0 at pci11 dev 0 function 0: "RAID 930-8i 2GB Flash", firmware 50.3.0-1075, 2048MB cache [ 1.048805] mfii0: interrupting at ioapic4 pin 2 [ 1.048805] scsibus0 at mfii0: 64 targets, 8 luns per target [ 2.161214] scsibus0: waiting 2 seconds for devices to settle... [ 2.161214] mfii0: physical disk inserted id 18 enclosure 134 [ 2.161214] mfii0: physical disk inserted id 19 enclosure 134 [ 2.161214] mfii0: physical disk inserted id 20 enclosure 134 [ 2.161214] mfii0: physical disk inserted id 21 enclosure 134 [ 4.163289] sd0 at scsibus0 target 0 lun 0: disk fixed [ 4.163289] sd0: fabricating a geometry [ 4.163289] sd0: 2234 GB, 2287864 cyl, 64 head, 32 sec, 512 bytes/sect x 4685545472 sectors [ 4.163289] sd0: fabricating a geometry [ 4.163289] sd0: tagged queueing [ 4.163289] sd1 at scsibus0 target 1 lun 0: disk fixed [ 4.163289] sd1: fabricating a geometry [ 4.163289] sd1: 744 GB, 761985 cyl, 64 head, 32 sec, 512 bytes/sect x 1560545280 sectors [ 4.163289] sd1: fabricating a geometry [ 4.163289] sd1: tagged queueing [32.192359] mfii0: critical limit on 'mfii0 BBU state' [32.192359] mfii0: normal state on 'mfii0:0' (online) [32.192359] mfii0: normal state on 'mfii0:1' (online) # bioctl mfii0 show Volume Status Size Device/LabelLevel Stripe = 0 Online 2.2T System RAID 1N/A 65535 seconds 0:0 Online 2.2T 1:0.0 noencl 0:1 Online 2.2T 1:1.0 noencl 1 Online 744G WriteCache RAID 1N/A 65535 seconds 1:0 Online 745G 1:2.0 noencl 1:1 Online 745G 1:3.0 noencl dmesg | grep -c "not configured" = 239 :-) On Mon, 19 Feb 2018, Stephen Borrill wrote: So I've just got a Lenovo ThinkSystem SR630 and: # dmesg | grep -c "not configured" 240 http://www.netbsd.org/~sborrill/sr630.dmesg.txt Main issues are missing Ethernet (Intel X722) and RAID controller: vendor 8086 product 37d2 (ethernet network, revision 0x09) at pci7 dev 0 function 0 not configured vendor 8086 product 37d2 (ethernet network, revision 0x09) at pci7 dev 0 function 1 not configured vendor 8086 product 37d2 (ethernet network, revision 0x09) at pci7 dev 0 function 2 not configured vendor 8086 product 37d2 (ethernet network, revision 0x09) at pci7 dev 0 function 3 not configured vendor 1000 product 0016 (RAID mass storage, revision 0x01) at pci11 dev 0 function 0 not configured msaitoh@ - have you looked at the Intel X722 gigabit controllers? As for the RAID controller, we are missing support for all recent LSI/Symbios/Avago/Broadcom controllers meaning no support for lots of servers from Lenovo/HP, etc. OpenBSD's mfii supports most of these: https://www.precedence.co.uk/wiki/Support-KB-IBM/PCIIDs NetBSD has extended mfi to support a few variants, but OpenBSD has split the driver into mfi and mfii which makes porting more tricky. I tried OpenBSD 6.2 (last release), but the support for the RAID controller in this server was added after 6.2. On OpenBSD: # dmesg | grep -c "not configured" 350 -- Stephen
