[UPDATE] Re: FreeBSD 12.0-RC2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The freebsd-update(8) binary upgrade patches are now available for 12.0-RC2. The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 12.0-RC2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 11.x. Alternatively, the user can install misc/compat11x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install Regards, Glen -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlv6J3YACgkQAxRYpUeP 4pMLwA/8Dm+j0l31l7LLY+N0SSZ/V87Gkp878to/v7IzJZtbFYNG1zYOq3zJeaXg 1fG71q0TnmpyUQq75MHJssTwzupUWMPI1QSzC5+NIk2VMlC67Td75JU4nW00022Y 0XTH7Q+FleuGRqM+3MYE0oEsHUgMnCVhVWtz5iuJhOBzGI2pR7nsujqka+SIvGuU bsqy66Zj1HdQmOW/2yDxdOI7iaTamz1I1aXaGB3+nnwGtHgmfx9fKZpHSkrmfQak SV1Aroowovg+QMHeprhZBGPx5AQO1WaxwFs0LgpE0JzrSJDgnu1iYqipGsuf66ab NObhRRy5xDDVfnVRs7w3oFM4KwElo2WZg4r/vorJpSyNIqirdIDoatmb2pcb0Ezz q3DG/mUUleb4HLqZizaKsYJYkkIPPNMTDdtbY+e5vQrdi4kYe3wzEgW+zZm5TT+m vHI1nErPEIRFIe3J1kAvlJX6T9xSbATBVifNWJUU7KQDsfNRaNAGmCyQBF9gNOBe IDli6gmavZD6q/popJLM8eIZfLjW6Jktsprl5cf45S4TMYdwWt+HsHE/g5WgSSXi wO19beXw2YcwmehpelrjMVe4MXP57UTSmyAP808htsNOe34osnt2fLMF755R4l1K 6hZPNNjxX9zxzWyLfnO2WE8Xq3Y6twVMYRs1coSW6TJ5AfxJOEo= =tHW5 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 12.0-RC2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The second RC build of the 12.0-RELEASE release cycle is now available. Installation images are available for: o 12.0-RC2 amd64 GENERIC o 12.0-RC2 i386 GENERIC o 12.0-RC2 powerpc GENERIC o 12.0-RC2 powerpc64 GENERIC64 o 12.0-RC2 powerpcspe MPC85XXSPE o 12.0-RC2 sparc64 GENERIC o 12.0-RC2 armv6 RPI-B o 12.0-RC2 armv7 BANANAPI o 12.0-RC2 armv7 BEAGLEBONE o 12.0-RC2 armv7 CUBIEBOARD o 12.0-RC2 armv7 CUBIEBOARD2 o 12.0-RC2 armv7 CUBOX-HUMMINGBOARD o 12.0-RC2 armv7 PANDABOARD o 12.0-RC2 armv7 WANDBOARD o 12.0-RC2 armv7 GENERICSD o 12.0-RC2 aarch64 GENERIC o 12.0-RC2 aarch64 RPI3 o 12.0-RC2 aarch64 PINE64 o 12.0-RC2 aarch64 PINE64-LTS Note: The 12.0-RC2 armv7 RPI2 build failed, and the cause is being investigated. Also note, at present, freebsd-update(8) patch builds are still in progress. A followup email will be sent in reply to this announcement when they are available. Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/12.0" branch. A summary of changes since 12.0-RC1 includes: o Kernel debugging support in various kernel configurations has been disabled, which was missed when branching releng/12.0 from stable/12. o Allow set ether/vlan PCP operation from the VNET jails. o Align IA32_ARCH_CAP MSR definitions and use with SDM rev. 068. o Several IFLIB-related fixes. o Regressions when using 'pciconf -l' were fixed. o Handle kernel superpage mappings in pmap_remove_l2(). (PR 233088) o Fix /etc/ntp permissions. o OpenSSL has been updated to version 1.1.1a. o Various fixes to libbe(3) and bectl(8). o A src.conf knob to build userland with retpoline was added (off by default). o Various other miscellaneous fixes. A list of changes since 11.2-RELEASE is available in the releng/12.0 release notes: https://www.freebsd.org/releases/12.0R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 12.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/12.0-RC2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: ap-south-1 region: ami-0285a4b0c311d9e5e eu-west-3 region: ami-01989f54cc5fc3425 eu-west-2 region: ami-0058f626d39ade7dc eu-west-1 region: ami-07cca4933d62d5d22 ap-northeast-2 region: ami-084b8fc685e73d718 ap-northeast-1 region: ami-0fd072608bc5cc041 sa-east-1 region: ami-0df9e331ad6b563cd ca-central-1 region: ami-01360ca27677e8deb ap-southeast-1 region: ami-0dc6b473d0770bd29 ap-southeast-2 region: ami-0d83b7616da65ae6d eu-central-1 region: ami-0def9b7e1dfdbcb2a us-east-1 region: ami-0e1ca2c649ab4283e us-east-2 region: ami-044bc638def5a1bae us-west-1 region: ami-004ed88ea47546bfb us-west-2 region: ami-0edf97a8cbdffdaf9 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-12.0-RC2 % vagrant up === Upgrading === At present, freebsd-update(8) patch builds are still in progress.
Re: GNU binutils 2.17.50 retirement planning
On 23/11/2018 11:23, Ed Maste wrote: > Retiring GNU as requires further investigation and effort as we have > some assembly files (for amd64 at least) which cannot be assembled by > Clang's integrated assembler. If Clang gains support for the required > functionality we'll switch to using IAS for all assembly files, and if > not we could rewrite the few assembly files to work with IAS. > I've been using the port binutils as for quite some time on amd64 (with WITHOUT_BINUTILS and WITHOUT_BINUTILS_BOOTSTRAP) with success by specifying XAS, although some Makefile logic in stand/i386/btx specify a hard-coded /usr/bin/as without bootstrapped binutils, necessitating a symlink. I temporarily re-enabled binutils bootstrap in trying to figure out the r339898 regression with retpoline, so things may have changed in light of r340681. If it is true that the only assembly files that clang IAS cannot assemble are for amd64 and i386, has there been any research into nasm and yasm at least? nasm is specified as a build dependency in certain multimedia/ ports, and yasm in gecko@, for amd64 and i386 assembly code. Both are licensed under some BSD licence variant. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: maxswzone NOT used correctly and defaults incorrect?
Konstantin Belousov wrote this message on Sat, Nov 24, 2018 at 12:40 +0200: > On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote: > > I have an BeagleBoard Black. I'm running a recent snapshot: > > FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r340239 GENERIC arm > > > > aka: > > FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20181107-r340239.img.xz > > > > It has 512MB of memory on board. I created a 4GB swap file. According > > to loader(8), this should be the default capable: > >in bytes of KVA space. If no value is provided, the > > system > >allocates enough memory to handle an amount of swap that > >corresponds to eight times the amount of physical memory > >present in the system. > > > > avail memory = 505909248 (482 MB) > > > > but I get this: > > warning: total configured swap (1048576 pages) exceeds maximum recommended > > amount (248160 pages). > > warning: increase kern.maxswzone or reduce amount of swap. > > > > So, this appears that it's only 2x amount of memory, NOT 8x like the > > documentation says. > > > > When running make in sbin/ggate/ggated, make consumes a large amount > > of memory. Before the OOM killer just kicked in, top showed: > > Mem: 224M Active, 4096 Inact, 141M Laundry, 121M Wired, 57M Buf, 2688K Free > > Swap: 1939M Total, 249M Used, 1689M Free, 12% Inuse, 1196K Out > > > > PIDUID THR PRI NICE SIZERES STATETIMEWCPU COMMAND > > 1029 10011 440 594M 3848K RUN 2:03 38.12% make > > > > swapinfo -k showed: > > /dev/md99 4194304 254392 3939912 6% > > > > sysctl: > > vm.swzone: 4466880 > > vm.swap_maxpages: 496320 > > kern.maxswzone: 0 > > > > dmesg when OOM strikes: > > swap blk zone exhausted, increase kern.maxswzone > > pid 1029 (make), uid 1001, was killed: out of swap space > > pid 984 (bash), uid 1001, was killed: out of swap space > > pid 956 (bash), uid 1001, was killed: out of swap space > > pid 952 (sshd), uid 0, was killed: out of swap space > > pid 1043 (bash), uid 1001, was killed: out of swap space > > pid 626 (dhclient), uid 65, was killed: out of swap space > > pid 955 (sshd), uid 1001, was killed: out of swap space > > pid 1025 (bash), uid 1001, was killed: out of swap space > > swblk zone ok > > lock order reversal: > > 1st 0xd374d028 filedesc structure (filedesc structure) @ > > /usr/src/sys/kern/sys_generic.c:1451 > > 2nd 0xd41a5bc4 devfs (devfs) @ /usr/src/sys/kern/vfs_vnops.c:1513 > > stack backtrace: > > swap blk zone exhausted, increase kern.maxswzone > > pid 981 (tmux), uid 1001, was killed: out of swap space > > pid 983 (tmux), uid 1001, was killed: out of swap space > > pid 1031 (bash), uid 1001, was killed: out of swap space > > pid 580 (dhclient), uid 0, was killed: out of swap space > > swblk zone ok > > swap blk zone exhausted, increase kern.maxswzone > > pid 577 (dhclient), uid 0, was killed: out of swap space > > pid 627 (devd), uid 0, was killed: out of swap space > > swblk zone ok > > swap blk zone exhausted, increase kern.maxswzone > > pid 942 (getty), uid 0, was killed: out of swap space > > swblk zone ok > > swap blk zone exhausted, increase kern.maxswzone > > pid 1205 (init), uid 0, was killed: out of swap space > > swblk zone ok > > swap blk zone exhausted, increase kern.maxswzone > > pid 1206 (init), uid 0, was killed: out of swap space > > swblk zone ok > > swap blk zone exhausted, increase kern.maxswzone > > swblk zone ok > > swap blk zone exhausted, increase kern.maxswzone > > swblk zone ok > > > > So, as you can see, despite having plenty of swap, and swap usage being > > well below any of the maximums, the OOM killer kicked in, and killed off > > a bunch of processes. > OOM is guided by the pagedaemon progress, not by the swap amount left. > If the system cannot meet the pagedaemon targetp by doing > $(sysctl vm.pageout_oom_seq) back-to-back page daemon passes, > it declares OOM condition. E.g. if you have very active process which > keeps a lot of active memory by referencing the pages, and simultenously > a slow or stuck swap device, then you get into this state. > > Just by looking at the top stats, you have a single page in the inactive > queue, which means that pagedaemon desperately frees clean pages and > moves dirty pages into the laundry. Also, you have relatively large > laundry queue, which supports the theory about slow swap. Yes, swap is "slow" by modern standards, but not really that slow... I'm swapping out at over 10MB/sec... For such a system, this is quite fast... Though maybe I wasn't explicit, it's very clear that I'm running out of the swap blk zone, per the very first message, and the vmstat -z stats below (and the resulting failures): swap blk zone exhausted > You may try to increase vm.pageout_oom_seq to move OOM trigger furhter > after the system is overloaded with swapping. > > > > > It also looks like the algorithm for
Re: maxswzone NOT used correctly and defaults incorrect?
On 2018-Nov-24, at 02:40, Konstantin Belousov wrote: > On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote: >> . . . > OOM is guided by the pagedaemon progress, not by the swap amount left. It would help if the "was killed: out of swap space" messages did not incorrectly point to being out of swap space as the issue. > If the system cannot meet the pagedaemon targetp by doing > $(sysctl vm.pageout_oom_seq) back-to-back page daemon passes, > it declares OOM condition. E.g. if you have very active process which > keeps a lot of active memory by referencing the pages, and simultenously > a slow or stuck swap device, then you get into this state. > > Just by looking at the top stats, you have a single page in the inactive > queue, which means that pagedaemon desperately frees clean pages and > moves dirty pages into the laundry. Also, you have relatively large > laundry queue, which supports the theory about slow swap. > > You may try to increase vm.pageout_oom_seq to move OOM trigger furhter > after the system is overloaded with swapping. > >> . . . > The swap metadata zones must have all the KVA reserved in advance, > because we cannot wait for AS or memory while we try to free some > memory. At boot, the swap init code allocates KVA starting with the > requested amount. If the allocation fails, it reduces the amount by > 2/3 and retries, until the allocation succeeds. What you see in limits > is the actual amount of KVA that your platform is able to provide for > reserve, so increasing the maxswzone only results in more iterations to > allocate. The documentation's "corresponds to eight times the amount of physical memory" text again seems not helpful unless it happens to be about the figure for the actual context. Could something like your wording above be put in place instead? An example: armv7 rpi2's and aarch64 rpi3's, both with 1GiByte of RAM, get very different figures for the "exceeds maximum recommended amount" figure, different by very roughly a factor of 2 if I remember right, neither near what the documentation suggests. Suggesting a fixed ratio to RAM-size just seems to be wrong. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: maxswzone NOT used correctly and defaults incorrect?
On Sat, 24 Nov 2018 01:04:29 -0800 John-Mark Gurney wrote: > I have an BeagleBoard Black. I'm running a recent snapshot: > FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r340239 GENERIC arm > > aka: > FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20181107-r340239.img.xz > > It has 512MB of memory on board. I created a 4GB swap file. According > to loader(8), this should be the default capable: >in bytes of KVA space. If no value is provided, the system >allocates enough memory to handle an amount of swap that >corresponds to eight times the amount of physical memory >present in the system. > > avail memory = 505909248 (482 MB) > > but I get this: > warning: total configured swap (1048576 pages) exceeds maximum recommended > amount (248160 pages). > warning: increase kern.maxswzone or reduce amount of swap. > > So, this appears that it's only 2x amount of memory, NOT 8x like the > documentation says. > > When running make in sbin/ggate/ggated, make consumes a large amount > of memory. Before the OOM killer just kicked in, top showed: > Mem: 224M Active, 4096 Inact, 141M Laundry, 121M Wired, 57M Buf, 2688K Free > Swap: 1939M Total, 249M Used, 1689M Free, 12% Inuse, 1196K Out > > PIDUID THR PRI NICE SIZERES STATETIMEWCPU COMMAND > 1029 10011 440 594M 3848K RUN 2:03 38.12% make > > swapinfo -k showed: > /dev/md99 4194304 254392 3939912 6% > > sysctl: > vm.swzone: 4466880 > vm.swap_maxpages: 496320 > kern.maxswzone: 0 > > dmesg when OOM strikes: > swap blk zone exhausted, increase kern.maxswzone > pid 1029 (make), uid 1001, was killed: out of swap space > pid 984 (bash), uid 1001, was killed: out of swap space > pid 956 (bash), uid 1001, was killed: out of swap space > pid 952 (sshd), uid 0, was killed: out of swap space > pid 1043 (bash), uid 1001, was killed: out of swap space > pid 626 (dhclient), uid 65, was killed: out of swap space > pid 955 (sshd), uid 1001, was killed: out of swap space > pid 1025 (bash), uid 1001, was killed: out of swap space > swblk zone ok > lock order reversal: > 1st 0xd374d028 filedesc structure (filedesc structure) @ > /usr/src/sys/kern/sys_generic.c:1451 > 2nd 0xd41a5bc4 devfs (devfs) @ /usr/src/sys/kern/vfs_vnops.c:1513 > stack backtrace: > swap blk zone exhausted, increase kern.maxswzone > pid 981 (tmux), uid 1001, was killed: out of swap space > pid 983 (tmux), uid 1001, was killed: out of swap space > pid 1031 (bash), uid 1001, was killed: out of swap space > pid 580 (dhclient), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 577 (dhclient), uid 0, was killed: out of swap space > pid 627 (devd), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 942 (getty), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 1205 (init), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 1206 (init), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > swblk zone ok > > So, as you can see, despite having plenty of swap, and swap usage being > well below any of the maximums, the OOM killer kicked in, and killed off > a bunch of processes. > > It also looks like the algorithm for calculating kern.maxswzone is not > correct. > > I just tried to run the system w/: > kern.maxswzone: 21474836 > > and it again died w/ plenty of swap free: > /dev/md99 4194304 238148 3956156 6% > > This time I had vmstat -z | grep sw running, and saw: > swpctrie:48, 62084, 145, 270, 203, 0, 0 > swblk: 72, 62040, 56357, 18, 56587, 0, 0 > > after the system died, I logged back in as see: > swpctrie:48, 62084, 28, 387, 240, 0, 0 > swblk: 72, 62040, 175, 61865, 62957, 16, 0 > > so, it clearly ran out of swblk space VERY early, when only consuming > around 232MB of swap... > > Hmm... it looks like swblk and swpctrie are not affected by the setting > of kern.maxswzone... I just set it to: > kern.maxswzone: 85899344 > > and the limits for the zones did not increase at ALL: > swpctrie:48, 62084, 0, 0, 0, 0, 0 > swblk: 72, 62040, 0, 0, 0, 0, 0 Can you try this patch? I've been running with it for a few months now and no longer observe weird OOM kills. IIUC in shortfall mode when nfreed equals zero, this change makes it stay in shortfall mode instead of going to background mode. I don't know enough about VM internals to know if this is the correct fix though. Index:
Re: SCSI and dmesg
Warner Losh wrote: > Greetings > > a few weeks ago I pointed people to the nycbug dmesg service. I said I was > looking at data to drive SCSI retirement. I've gatherd some preliminary > data, which I've uploaded to > https://github.com/bsdimp/device-data/blob/master/cam.md along with some > preliminary notions of disposition for the hardware. I'm still working out > the kinks in the dmesg parsing, but this is interesting data. > > If you've not recently submitted, please consider doing so. We'll be > finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a > few weeks, and I'm going to base much of what list I come up with based on > what is submitted. The glitches with FreeBSD dmesgs have been cleared up as > well. > > http://dmesgd.nycbug.org/index.cgi > > or > > curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d > "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv > smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ > /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi Got another system to submit, but continuously getting "500 Internal Server Error" using the curl one-liner. dmesg.boot attached in case it's the source of the problem. ---<>--- Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT r340744 GENERIC-NODEBUG amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT(efifb): resolution 3440x1440 CPU: Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz (3504.14-MHz K8-class CPU) Origin="GenuineIntel" Id=0x806e9 Family=0x6 Model=0x8e Stepping=9 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c67af Structured Extended Features3=0x9c00 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16472522752 (15709 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-119 on motherboard Launching APs: 1 3 2 Timecounter "TSC-low" frequency 1752072050 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8113f150, 0) error 19 kbd0 at kbdmux0 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" netmap: loaded module nexus0 efirtc0: on motherboard efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 550 Event timer "HPET1" frequency 2400 Hz quality 440 Event timer "HPET2" frequency 2400 Hz quality 440 Event timer "HPET3" frequency 2400 Hz quality 440 Event timer "HPET4" frequency 2400 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0x2ffe00-0x2ffeff,0x2f-0x2f7fff at device 2.0 on pci0 vgapci0: Boot video device xhci0: mem 0x2fff01-0x2fff01 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xde424000-0xde425fff,0xde427000-0xde4270ff,0xde426000-0xde4267ff at device 23.0 on pci0 ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 pcib1: at device 28.0 on pci0 pcib1: [GIANT-LOCKED] pcib2: at device 28.5 on pci0 pci1: on pcib2 pci1: at device 0.0 (no driver attached) pcib3: at device 28.7 on pci0 pci2: on pcib3 pci2: at device 0.0 (no driver attached) pcib4: at device 29.0 on pci0 pci3: on pcib4 nvme0: mem 0xde10-0xde103fff at device 0.0 on pci3 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0x2fff02-0x2fff023fff,0x2fff00-0x2fff00 at device 31.3 on pci0 em0: mem 0xde40-0xde41 at device 31.6 on pci0
Re: Kernel Panic - Sublime Text - 12.0-PRERELEASE r340650M
Updated to r340868 and the issue has been resolved, thank you for your time! James On 24/11/2018 09:53, Tijl Coosemans wrote: On Sat, 24 Nov 2018 02:05:51 + James Wright wrote: When trying to run sublime text via the linuxulator my system panics and reboots. Unfortunately I do not have much extra info as it crashes immediately and seems to corrupt the UFS filesystem in the process (which has to be fixed with a few runs of fsck on next boot). I've tried enabling "dumpdev=AUTO" in rc.conf but don't find anything in /var/crash/ afterwards. $ uname FreeBSD macbook 12.0-PRERELEASE FreeBSD 12.0-PRERELEASE #0 r340650M: Mon Nov 19 23:09:39 GMT 2018 root@macbook:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 $ pkg info | grep sublime linux-sublime-2.0.2_6 Happy to provide any extra info required to help diagnose the issue! Try upgrading to at least r340762. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #16 from Matías Pizarro --- Hi all, FYI, I had the same issue with 13-CURRENT but it now works fine in today';s stable/12 | 12-PRERELEASE which I understand should be the same as 12-RC2. Thanks for your work on this, All the best, -- matías -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: maxswzone NOT used correctly and defaults incorrect?
On Sat, Nov 24, 2018 at 01:04:29AM -0800, John-Mark Gurney wrote: > I have an BeagleBoard Black. I'm running a recent snapshot: > FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r340239 GENERIC arm > > aka: > FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20181107-r340239.img.xz > > It has 512MB of memory on board. I created a 4GB swap file. According > to loader(8), this should be the default capable: >in bytes of KVA space. If no value is provided, the system >allocates enough memory to handle an amount of swap that >corresponds to eight times the amount of physical memory >present in the system. > > avail memory = 505909248 (482 MB) > > but I get this: > warning: total configured swap (1048576 pages) exceeds maximum recommended > amount (248160 pages). > warning: increase kern.maxswzone or reduce amount of swap. > > So, this appears that it's only 2x amount of memory, NOT 8x like the > documentation says. > > When running make in sbin/ggate/ggated, make consumes a large amount > of memory. Before the OOM killer just kicked in, top showed: > Mem: 224M Active, 4096 Inact, 141M Laundry, 121M Wired, 57M Buf, 2688K Free > Swap: 1939M Total, 249M Used, 1689M Free, 12% Inuse, 1196K Out > > PIDUID THR PRI NICE SIZERES STATETIMEWCPU COMMAND > 1029 10011 440 594M 3848K RUN 2:03 38.12% make > > swapinfo -k showed: > /dev/md99 4194304 254392 3939912 6% > > sysctl: > vm.swzone: 4466880 > vm.swap_maxpages: 496320 > kern.maxswzone: 0 > > dmesg when OOM strikes: > swap blk zone exhausted, increase kern.maxswzone > pid 1029 (make), uid 1001, was killed: out of swap space > pid 984 (bash), uid 1001, was killed: out of swap space > pid 956 (bash), uid 1001, was killed: out of swap space > pid 952 (sshd), uid 0, was killed: out of swap space > pid 1043 (bash), uid 1001, was killed: out of swap space > pid 626 (dhclient), uid 65, was killed: out of swap space > pid 955 (sshd), uid 1001, was killed: out of swap space > pid 1025 (bash), uid 1001, was killed: out of swap space > swblk zone ok > lock order reversal: > 1st 0xd374d028 filedesc structure (filedesc structure) @ > /usr/src/sys/kern/sys_generic.c:1451 > 2nd 0xd41a5bc4 devfs (devfs) @ /usr/src/sys/kern/vfs_vnops.c:1513 > stack backtrace: > swap blk zone exhausted, increase kern.maxswzone > pid 981 (tmux), uid 1001, was killed: out of swap space > pid 983 (tmux), uid 1001, was killed: out of swap space > pid 1031 (bash), uid 1001, was killed: out of swap space > pid 580 (dhclient), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 577 (dhclient), uid 0, was killed: out of swap space > pid 627 (devd), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 942 (getty), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 1205 (init), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > pid 1206 (init), uid 0, was killed: out of swap space > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > swblk zone ok > swap blk zone exhausted, increase kern.maxswzone > swblk zone ok > > So, as you can see, despite having plenty of swap, and swap usage being > well below any of the maximums, the OOM killer kicked in, and killed off > a bunch of processes. OOM is guided by the pagedaemon progress, not by the swap amount left. If the system cannot meet the pagedaemon targetp by doing $(sysctl vm.pageout_oom_seq) back-to-back page daemon passes, it declares OOM condition. E.g. if you have very active process which keeps a lot of active memory by referencing the pages, and simultenously a slow or stuck swap device, then you get into this state. Just by looking at the top stats, you have a single page in the inactive queue, which means that pagedaemon desperately frees clean pages and moves dirty pages into the laundry. Also, you have relatively large laundry queue, which supports the theory about slow swap. You may try to increase vm.pageout_oom_seq to move OOM trigger furhter after the system is overloaded with swapping. > > It also looks like the algorithm for calculating kern.maxswzone is not > correct. > > I just tried to run the system w/: > kern.maxswzone: 21474836 > > and it again died w/ plenty of swap free: > /dev/md99 4194304 238148 3956156 6% > > This time I had vmstat -z | grep sw running, and saw: > swpctrie:48, 62084, 145, 270, 203, 0, 0 > swblk: 72, 62040, 56357, 18, 56587, 0, 0 > > after the system died, I logged back in as see: > swpctrie:48, 62084, 28, 387, 240, 0, 0 > swblk: 72, 62040, 175, 61865, 62957, 16, 0 > > so, it
Re: Kernel Panic - Sublime Text - 12.0-PRERELEASE r340650M
On Sat, 24 Nov 2018 02:05:51 + James Wright wrote: > When trying to run sublime text via the linuxulator my system panics > and reboots. Unfortunately I do not have much extra info as it crashes > immediately and seems to corrupt the UFS filesystem in the process > (which has to be fixed with a few runs of fsck on next boot). I've > tried enabling "dumpdev=AUTO" in rc.conf but don't find anything in > /var/crash/ afterwards. > > $ uname > FreeBSD macbook 12.0-PRERELEASE FreeBSD 12.0-PRERELEASE #0 r340650M: > Mon Nov 19 23:09:39 GMT 2018 > root@macbook:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > $ pkg info | grep sublime > linux-sublime-2.0.2_6 > > Happy to provide any extra info required to help diagnose the issue! Try upgrading to at least r340762. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
maxswzone NOT used correctly and defaults incorrect?
I have an BeagleBoard Black. I'm running a recent snapshot: FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r340239 GENERIC arm aka: FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20181107-r340239.img.xz It has 512MB of memory on board. I created a 4GB swap file. According to loader(8), this should be the default capable: in bytes of KVA space. If no value is provided, the system allocates enough memory to handle an amount of swap that corresponds to eight times the amount of physical memory present in the system. avail memory = 505909248 (482 MB) but I get this: warning: total configured swap (1048576 pages) exceeds maximum recommended amount (248160 pages). warning: increase kern.maxswzone or reduce amount of swap. So, this appears that it's only 2x amount of memory, NOT 8x like the documentation says. When running make in sbin/ggate/ggated, make consumes a large amount of memory. Before the OOM killer just kicked in, top showed: Mem: 224M Active, 4096 Inact, 141M Laundry, 121M Wired, 57M Buf, 2688K Free Swap: 1939M Total, 249M Used, 1689M Free, 12% Inuse, 1196K Out PIDUID THR PRI NICE SIZERES STATETIMEWCPU COMMAND 1029 10011 440 594M 3848K RUN 2:03 38.12% make swapinfo -k showed: /dev/md99 4194304 254392 3939912 6% sysctl: vm.swzone: 4466880 vm.swap_maxpages: 496320 kern.maxswzone: 0 dmesg when OOM strikes: swap blk zone exhausted, increase kern.maxswzone pid 1029 (make), uid 1001, was killed: out of swap space pid 984 (bash), uid 1001, was killed: out of swap space pid 956 (bash), uid 1001, was killed: out of swap space pid 952 (sshd), uid 0, was killed: out of swap space pid 1043 (bash), uid 1001, was killed: out of swap space pid 626 (dhclient), uid 65, was killed: out of swap space pid 955 (sshd), uid 1001, was killed: out of swap space pid 1025 (bash), uid 1001, was killed: out of swap space swblk zone ok lock order reversal: 1st 0xd374d028 filedesc structure (filedesc structure) @ /usr/src/sys/kern/sys_generic.c:1451 2nd 0xd41a5bc4 devfs (devfs) @ /usr/src/sys/kern/vfs_vnops.c:1513 stack backtrace: swap blk zone exhausted, increase kern.maxswzone pid 981 (tmux), uid 1001, was killed: out of swap space pid 983 (tmux), uid 1001, was killed: out of swap space pid 1031 (bash), uid 1001, was killed: out of swap space pid 580 (dhclient), uid 0, was killed: out of swap space swblk zone ok swap blk zone exhausted, increase kern.maxswzone pid 577 (dhclient), uid 0, was killed: out of swap space pid 627 (devd), uid 0, was killed: out of swap space swblk zone ok swap blk zone exhausted, increase kern.maxswzone pid 942 (getty), uid 0, was killed: out of swap space swblk zone ok swap blk zone exhausted, increase kern.maxswzone pid 1205 (init), uid 0, was killed: out of swap space swblk zone ok swap blk zone exhausted, increase kern.maxswzone pid 1206 (init), uid 0, was killed: out of swap space swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok So, as you can see, despite having plenty of swap, and swap usage being well below any of the maximums, the OOM killer kicked in, and killed off a bunch of processes. It also looks like the algorithm for calculating kern.maxswzone is not correct. I just tried to run the system w/: kern.maxswzone: 21474836 and it again died w/ plenty of swap free: /dev/md99 4194304 238148 3956156 6% This time I had vmstat -z | grep sw running, and saw: swpctrie:48, 62084, 145, 270, 203, 0, 0 swblk: 72, 62040, 56357, 18, 56587, 0, 0 after the system died, I logged back in as see: swpctrie:48, 62084, 28, 387, 240, 0, 0 swblk: 72, 62040, 175, 61865, 62957, 16, 0 so, it clearly ran out of swblk space VERY early, when only consuming around 232MB of swap... Hmm... it looks like swblk and swpctrie are not affected by the setting of kern.maxswzone... I just set it to: kern.maxswzone: 85899344 and the limits for the zones did not increase at ALL: swpctrie:48, 62084, 0, 0, 0, 0, 0 swblk: 72, 62040, 0, 0, 0, 0, 0 Thoughts? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
