I'm just trying to customize the kernel configuration for Raspberry Pi 4B, to achieve a compact system image and quick startup, but as we can see in the logs there's approximate ~4.0s to start executing my 4.2MB kernel.
Logs:
23:20:06.198 ->
23:20:06.198 -> PM_RSTS: 0x00001000
23:20:06.198 -> RPi: BOOTLOADER release VERSION:f626c772 Sep 10 2019 10:41:52 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1568112110
23:20:06.231 -> uSD voltage 3.3V
23:20:06.430 -> SD HOST: 200000000 CTL0: 0x00000000 BUS: 100000 Hz div: 2000 status: 0x1fff0000 delay-ticks: 1080
23:20:06.463 -> SD HOST: 200000000 CTL0: 0x00000f00 BUS: 100000 Hz div: 2000 status: 0x1fff0000 delay-ticks: 1080
23:20:06.463 -> CID: 00035344534331364780411a41a20123
23:20:06.463 -> CSD: 400e00325b59000076b27f800a404000
23:20:06.496 -> CSD: VER: 1 logical blocks: 30386 mult: 1024 rd(len: 512 partial: 0 misalign: 0) sectors: 31116288
23:20:06.496 -> SD: bus-width: 4 spec: 2 SCR: 0x02358443 0x00000000
23:20:06.496 -> SWITCH_FUNC: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000038001c00180018001800180c800
23:20:06.529 -> SD HOST: 200000000 CTL0: 0x00000f04 BUS: 40000000 Hz div: 6 status: 0x1fff0000 delay-ticks: 2
23:20:06.529 -> MBR: 0x00000001, 32768 type: 0x0c
23:20:06.529 -> MBR: 0x00008001, 20376 type: 0x83
23:20:06.529 -> MBR: 0x0000cf99, 131072 type: 0x83
23:20:06.529 -> MBR: 0x00000000, 0 type: 0x00
23:20:06.529 -> part-offset: 1 oem: mkfs.fat volume: V ^
23:20:06.529 -> rsc: 4 sectors-per-fat: 32 clusters: 8167 cluster-size: 4 root-dir: 1 root-sectors: 32
23:20:06.562 -> WEL: 0x00000045 0x00008000
23:20:06.562 -> PM_RSTS: 0x00001000
23:20:06.562 -> Partition: 0
23:20:06.562 -> part-offset: 1 oem: mkfs.fat volume: V ^
23:20:06.562 -> rsc: 4 sectors-per-fat: 32 clusters: 8167 cluster-size: 4 root-dir: 1 root-sectors: 32
23:20:06.562 -> Loading config.txt hnd: 0x00000017
23:20:06.562 -> Initialising SDRAM 'Samsung' 8Gb x1 total-size: 8 Gbit 3200
23:20:07.258 -> Loading recovery.elf hnd: 0x00000000
23:20:07.258 -> Failed to read recovery.elf error: 6
23:20:07.291 -> Loading start4.elf hnd: 0x0000001b
23:20:07.655 -> Loading fixup4.dat hnd: 0x00000018
23:20:07.655 -> MEM GPU: 96 ARM: 928 TOTAL: 1024
23:20:07.655 -> FIXUP src: 128 256 dst: 928 1024
23:20:07.821 -> Starting start4.elf # 0xfec00200
23:20:07.821 ->
23:20:11.859 -> Booting Linux on physical CPU 0x0
23:20:11.859 -> Linux version 4.19.66-v7l (iman#MSI-7758) (gcc version 8.3.0 (Buildroot 2019.11.1-dirty)) #12 SMP PREEMPT Tue Feb 18 23:17:21 +0330 2020
23:20:11.859 -> CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=50c5383d
23:20:11.859 -> CPU: div instructions available: patching division code
23:20:11.859 -> CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
23:20:11.893 -> OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
23:20:11.893 -> Memory policy: Data cache writealloc
23:20:11.893 -> Ignoring RAM at 0x30000000-0x3a000000
23:20:11.893 -> Consider using a HIGHMEM enabled kernel.
23:20:11.893 -> cma: Reserved 64 MiB at 0x2ac00000
23:20:11.893 -> random: get_random_bytes called from start_kernel+0x63/0x2e4 with crng_init=0
23:20:11.893 -> percpu: Embedded 16 pages/cpu s34828 r8192 d22516 u65536
23:20:11.893 -> Built 1 zonelists, mobility grouping on. Total pages: 194880
23:20:11.926 -> Kernel command line: coherent_pool=1M 8250.nr_uarts=1 cma=64M bcm2708_fb.fbwidth=0 bcm2708_fb.fbheight=0 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:4C:50:2A vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200
23:20:11.926 -> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
23:20:12.010 -> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
23:20:12.010 -> Memory: 704556K/786432K available (4096K kernel code, 404K rwdata, 1748K rodata, 1024K init, 509K bss, 16340K reserved, 65536K cma-reserved)
23:20:12.010 -> Virtual kernel memory layout:
23:20:12.010 -> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
23:20:12.010 -> fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
23:20:12.010 -> vmalloc : 0xf0800000 - 0xff800000 ( 240 MB)
23:20:12.010 -> lowmem : 0xc0000000 - 0xf0000000 ( 768 MB)
23:20:12.010 -> modules : 0xbf800000 - 0xc0000000 ( 8 MB)
23:20:12.010 -> .text : 0x(ptrval) - 0x(ptrval) (5088 kB)
23:20:12.010 -> .init : 0x(ptrval) - 0x(ptrval) (1024 kB)
23:20:12.010 -> .data : 0x(ptrval) - 0x(ptrval) ( 405 kB)
23:20:12.010 -> .bss : 0x(ptrval) - 0x(ptrval) ( 510 kB)
23:20:12.010 -> ftrace: allocating 21664 entries in 43 pages
23:20:12.010 -> rcu: Preemptible hierarchical RCU implementation.
23:20:12.010 -> Tasks RCU enabled.
23:20:12.010 -> NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
23:20:12.010 -> GIC: Using split EOI/Deactivate mode
23:20:12.010 -> arch_timer: cp15 timer(s) running at 54.00MHz (phys).
23:20:12.010 -> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
23:20:12.032 -> sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
23:20:12.032 -> Switching to timer-based delay loop, resolution 18ns
23:20:12.032 -> Console: colour dummy device 80x30
23:20:12.058 -> console [tty1] enabled
23:20:12.058 -> Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=540000)
23:20:12.058 -> pid_max: default: 32768 minimum: 301
23:20:12.058 -> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
23:20:12.058 -> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
23:20:12.091 -> CPU: Testing write buffer coherency: ok
23:20:12.091 -> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
23:20:12.091 -> Setting up static identity map for 0x100000 - 0x100038
23:20:12.091 -> rcu: Hierarchical SRCU implementation.
23:20:12.091 -> smp: Bringing up secondary CPUs ...
23:20:12.091 -> CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
23:20:12.091 -> CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
23:20:12.091 -> CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
23:20:12.124 -> smp: Brought up 1 node, 4 CPUs
23:20:12.124 -> SMP: Total of 4 processors activated (432.00 BogoMIPS).
23:20:12.124 -> CPU: All CPU(s) started in HYP mode.
23:20:12.124 -> CPU: Virtualization extensions available.
23:20:12.124 -> devtmpfs: initialized
23:20:12.124 -> VFP support v0.3: implementor 41 architecture 3 part 40 variant 8 rev 0
23:20:12.124 -> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
23:20:12.158 -> futex hash table entries: 1024 (order: 4, 65536 bytes)
23:20:12.158 -> pinctrl core: initialized pinctrl subsystem
23:20:12.158 -> NET: Registered protocol family 16
23:20:12.158 -> DMA: preallocated 1024 KiB pool for atomic coherent allocations
23:20:12.158 -> hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
23:20:12.158 -> hw-breakpoint: maximum watchpoint size is 8 bytes.
23:20:12.158 -> Serial: AMBA PL011 UART driver
23:20:12.158 -> bcm2835-mbox fe00b880.mailbox: mailbox enabled
23:20:12.190 -> bcm2835-dma fe007000.dma: DMA legacy API manager at (ptrval), dmachans=0x1
23:20:12.190 -> usbcore: registered new interface driver usbfs
23:20:12.190 -> usbcore: registered new interface driver hub
23:20:12.190 -> usbcore: registered new device driver usb
23:20:12.190 -> raspberrypi-firmware soc:firmware: Attached to firmware from 2019-08-15 12:03, variant start
23:20:12.190 -> raspberrypi-firmware soc:firmware: Firmware hash is 9f8431fb7839c7f00f52b81f5822ddab2b31d0db
23:20:12.224 -> clocksource: Switched to clocksource arch_sys_counter
23:20:12.224 -> VFS: Disk quotas dquot_6.6.0
23:20:12.224 -> VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
23:20:12.224 -> FS-Cache: Loaded
23:20:12.224 -> CacheFiles: Loaded
23:20:12.224 -> NET: Registered protocol family 2
23:20:12.224 -> tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
23:20:12.224 -> TCP established hash table entries: 8192 (order: 3, 32768 bytes)
23:20:12.257 -> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
23:20:12.257 -> TCP: Hash tables configured (established 8192 bind 8192)
23:20:12.257 -> UDP hash table entries: 512 (order: 2, 16384 bytes)
23:20:12.257 -> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
23:20:12.257 -> NET: Registered protocol family 1
23:20:12.257 -> Initialise system trusted keyrings
23:20:12.257 -> workingset: timestamp_bits=14 max_order=18 bucket_order=4
23:20:12.290 -> squashfs: version 4.0 (2009/01/31) Phillip Lougher
23:20:12.290 -> Key type asymmetric registered
23:20:12.290 -> Asymmetric key parser 'x509' registered
23:20:12.290 -> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
23:20:12.290 -> io scheduler noop registered
23:20:12.290 -> io scheduler deadline registered
23:20:12.290 -> io scheduler cfq registered (default)
23:20:12.290 -> io scheduler mq-deadline registered
23:20:12.290 -> io scheduler kyber registered
23:20:12.290 -> bcm2708_fb soc:fb: Unable to determine number of FB's. Assuming 1
23:20:12.323 -> bcm2708_fb soc:fb: FB found 1 display(s)
23:20:12.323 -> raspberrypi-firmware soc:firmware: Request 0x00048003 returned status 0x80000001
23:20:12.323 -> bcm2708_fb soc:fb: Failed to allocate GPU framebuffer (-22)
23:20:12.323 -> bcm2708_fb soc:fb: probe failed, err -22
23:20:12.323 -> bcm2708_fb: probe of soc:fb failed with error -22
23:20:12.323 -> Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
23:20:12.356 -> iproc-rng200 fe104000.rng: hwrng registered
23:20:12.356 -> vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
23:20:12.356 -> vc-sm: Videocore shared memory driver
23:20:12.356 -> gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000
23:20:12.356 -> brd: module loaded
23:20:12.356 -> loop: module loaded
23:20:12.356 -> libphy: Fixed MDIO Bus: probed
23:20:12.356 -> bcmgenet fd580000.genet: failed to get enet clock
23:20:12.356 -> bcmgenet fd580000.genet: GENET 5.0 EPHY: 0x0000
23:20:12.389 -> bcmgenet fd580000.genet: failed to get enet-wol clock
23:20:12.389 -> bcmgenet fd580000.genet: failed to get enet-eee clock
23:20:12.389 -> bcmgenet: Skipping UMAC reset
23:20:12.389 -> unimac-mdio unimac-mdio.-19: DMA mask not set
23:20:12.389 -> libphy: bcmgenet MII bus: probed
23:20:12.389 -> unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus at 0x(ptrval)
23:20:12.389 -> dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
23:20:12.389 -> dwc_otg fe980000.usb: base=(ptrval)
23:20:12.422 -> Core Release: 2.80a
23:20:12.422 -> Setting default values for core params
23:20:12.422 -> Finished setting default values for core params
23:20:12.422 -> WARN::dwc_otg_core_reset:5114: dwc_otg_core_reset() HANG! Soft Reset GRSTCTL=80000001
23:20:12.422 ->
23:20:12.422 -> WARN::dwc_otg_core_reset:5114: dwc_otg_core_reset() HANG! Soft Reset GRSTCTL=80000001
23:20:12.422 ->
23:20:12.422 -> Using Buffer DMA mode
23:20:12.422 -> Periodic Transfer Interrupt Enhancement - disabled
23:20:12.455 -> Multiprocessor Interrupt Enhancement - disabled
23:20:12.455 -> OTG VER PARAM: 0, OTG VER FLAG: 0
23:20:12.455 -> Dedicated Tx FIFOs mode
23:20:12.455 -> WARN::dwc_otg_hcd_init:1045: FIQ DMA bounce buffers: virt = ead04000 dma = 0xead04000 len=9024
23:20:12.455 -> FIQ FSM acceleration enabled for :
23:20:12.455 -> Non-periodic Split Transactions
23:20:12.455 -> Periodic Split Transactions
23:20:12.455 -> High-Speed Isochronous Endpoints
23:20:12.455 -> Interrupt/Control Split Transaction hack enabled
23:20:12.489 -> WARN::hcd_init_fiq:457: FIQ on core 1
23:20:12.489 -> WARN::hcd_init_fiq:458: FIQ ASM at c038a680 length 26
23:20:12.489 -> WARN::hcd_init_fiq:497: MPHI regs_base at f0810200
23:20:12.489 -> dwc_otg fe980000.usb: DWC OTG Controller
23:20:12.489 -> dwc_otg fe980000.usb: new USB bus registered, assigned bus number 1
23:20:12.489 -> dwc_otg fe980000.usb: irq 38, io mem 0x00000000
23:20:12.489 -> Init: Port Power? op_state=1
23:20:12.489 -> Init: Power Port (0)
23:20:12.522 -> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
23:20:12.522 -> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
23:20:12.522 -> usb usb1: Product: DWC OTG Controller
23:20:12.522 -> usb usb1: Manufacturer: Linux 4.19.66-v7l dwc_otg_hcd
23:20:12.522 -> usb usb1: SerialNumber: fe980000.usb
23:20:12.522 -> hub 1-0:1.0: USB hub found
23:20:12.522 -> hub 1-0:1.0: 1 port detected
23:20:12.522 -> mousedev: PS/2 mouse device common for all mice
23:20:12.555 -> bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
23:20:12.555 -> sdhci: Secure Digital Host Controller Interface driver
23:20:12.555 -> sdhci: Copyright(c) Pierre Ossman
23:20:12.555 -> mmc-bcm2835 fe300000.mmcnr: could not get clk, deferring probe
23:20:12.555 -> sdhci-pltfm: SDHCI platform and OF driver helper
23:20:12.555 -> ledtrig-cpu: registered to indicate activity on CPUs
23:20:12.555 -> hidraw: raw HID events driver (C) Jiri Kosina
23:20:12.588 -> usbcore: registered new interface driver usbhid
23:20:12.588 -> usbhid: USB HID core driver
23:20:12.588 -> vchiq: vchiq_init_state: slot_zero = (ptrval), is_master = 0
23:20:12.588 -> [vc_sm_connected_init]: start
23:20:12.588 -> [vc_sm_connected_init]: end - returning 0
23:20:12.588 -> Initializing XFRM netlink socket
23:20:12.588 -> NET: Registered protocol family 17
23:20:12.588 -> Key type dns_resolver registered
23:20:12.588 -> Registering SWP/SWPB emulation handler
23:20:12.588 -> registered taskstats version 1
23:20:12.621 -> Loading compiled-in X.509 certificates
23:20:12.621 -> uart-pl011 fe201000.serial: cts_event_workaround enabled
23:20:12.621 -> fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 34, base_baud = 0) is a PL011 rev2
23:20:12.621 -> console [ttyAMA0] enabled
23:20:12.621 -> fe215040.serial: ttyS0 at MMIO 0x0 (irq = 36, base_baud = 62500000) is a 16550
23:20:12.654 -> bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
23:20:12.654 -> brcmstb_thermal fd5d2200.thermal: registered AVS TMON of-sensor driver
23:20:12.654 -> mmc-bcm2835 fe300000.mmcnr: mmc_debug:0 mmc_debug2:0
23:20:12.654 -> mmc-bcm2835 fe300000.mmcnr: DMA channel allocated
23:20:12.687 -> sdhci-iproc fe340000.emmc2: Linked as a consumer to regulator.1
23:20:12.720 -> mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
23:20:12.720 -> mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
23:20:12.720 -> mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
23:20:12.754 -> mmc0: SDHCI controller on fe340000.emmc2 [fe340000.emmc2] using ADMA
23:20:12.754 -> of_cfs_init
23:20:12.754 -> of_cfs_init: OK
23:20:12.754 -> mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
23:20:12.754 -> uart-pl011 fe201000.serial: no DMA platform data
23:20:12.754 -> mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
23:20:12.754 -> Waiting for root device /dev/mmcblk0p2...
23:20:12.820 -> random: fast init done
23:20:12.820 -> mmc1: new high speed SDIO card at address 0001
23:20:12.886 -> mmc0: new ultra high speed DDR50 SDHC card at address aaaa
23:20:12.886 -> mmcblk0: mmc0:aaaa SC16G 14.8 GiB
23:20:12.886 -> mmcblk0: p1 p2 p3
23:20:12.919 -> VFS: Mounted root (squashfs filesystem) readonly on device 179:2.
23:20:12.952 -> devtmpfs: mounted
23:20:12.985 -> Freeing unused kernel memory: 1024K
23:20:12.985 -> Run /sbin/init as init process
23:20:13.184 -> rcS: applet not found
23:20:13.283 ->
23:20:13.283 -> Welcome to RPI4
23:20:13.283 -> root login:
config.txt:
# Please note that this is only a sample, we recommend you to change it to fit
# your needs.
# You should override this file using a post-build script.
# See http://buildroot.org/manual.html#rootfs-custom
# and http://elinux.org/RPiconfig for a description of config.txt syntax
kernel=zImage
start_file=start4.elf
fixup_file=fixup4.dat
# Disable overscan assuming the display supports displaying the full resolution
# If the text shown on the screen disappears off the edge, comment this out
disable_overscan=1
# fixes rpi3 ttyAMA0 serial console
dtoverlay=pi3-miniuart-bt
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=off
dtparam=i2s=off
dtparam=spi=off
# Disable audio (loads snd_bcm2835)
dtparam=audio=off
# Disable DPI interface
enable_dpi_lcd=0
# Disable LCD on I2C bus
ignore_lcd=1
# Disable camera module
start_x=0
# Disable rainbow splash
disable_splash=1
# Remove possible bootloader delay
boot_delay_ms=0
bootcode_delay=0
boot_delay=0
# Set VideoCore memory
gpu_mem=96
cmdline.txt:
root=/dev/mmcblk0p2 rootfstype=squashfs rootwait console=tty1 console=ttyAMA0,115200
Is this supposed to be normal?
Related
Does anyone have any ideas on why these logs are giving these errors - Out of memory: kill process ... nginx invoked oom-killer?
Lately, our cms has been going down and we have to manually restart the server in AWS and we're not sure what is happening to cause this behavior. log errors
Here are the exact lines of code that repeated 33 times while the server was down:
Out of memory: kill process 15654 (ruby) score 338490 or a child
Killed process 15654 (ruby) vsz:1353960kB, anon-rss:210704kB, file-rss:0kB
nginx invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
nginx cpuset=/ mems_allowed=0
Pid: 8729, comm: nginx Tainted: G W 2.6.35.14-97.44.amzn1.x86_64 #1
Call Trace:
[<ffffffff8108e638>] ? cpuset_print_task_mems_allowed+0x98/0xa0
[<ffffffff810bb157>] dump_header.clone.1+0x77/0x1a0
[<ffffffff81318d49>] ? _raw_spin_unlock_irqrestore+0x19/0x20
[<ffffffff811ab3af>] ? ___ratelimit+0x9f/0x120
[<ffffffff810bb2f6>] oom_kill_process.clone.0+0x76/0x140
[<ffffffff810bb4d8>] __out_of_memory+0x118/0x190
[<ffffffff810bb5d2>] out_of_memory+0x82/0x1c0
[<ffffffff810beb89>] __alloc_pages_nodemask+0x689/0x6a0
[<ffffffff810e7864>] alloc_pages_current+0x94/0xf0
[<ffffffff810b87ef>] __page_cache_alloc+0x7f/0x90
[<ffffffff810c15e0>] __do_page_cache_readahead+0xc0/0x200
[<ffffffff810c173c>] ra_submit+0x1c/0x20
[<ffffffff810b9f63>] filemap_fault+0x3e3/0x430
[<ffffffff810d023f>] __do_fault+0x4f/0x4b0
[<ffffffff810d2774>] handle_mm_fault+0x1b4/0xb40
[<ffffffff81007682>] ? check_events+0x12/0x20
[<ffffffff81006f1d>] ? xen_force_evtchn_callback+0xd/0x10
[<ffffffff81007682>] ? check_events+0x12/0x20
[<ffffffff8131c752>] do_page_fault+0x112/0x310
[<ffffffff813194b5>] page_fault+0x25/0x30
Mem-Info:
Node 0 DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
CPU 2: hi: 0, btch: 1 usd: 0
CPU 3: hi: 0, btch: 1 usd: 0
Node 0 DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 35
CPU 1: hi: 186, btch: 31 usd: 0
CPU 2: hi: 186, btch: 31 usd: 30
CPU 3: hi: 186, btch: 31 usd: 0
Node 0 Normal per-cpu:
CPU 0: hi: 186, btch: 31 usd: 202
CPU 1: hi: 186, btch: 31 usd: 30
CPU 2: hi: 186, btch: 31 usd: 59
CPU 3: hi: 186, btch: 31 usd: 140
active_anon:3438873 inactive_anon:284496 isolated_anon:0
active_file:0 inactive_file:62 isolated_file:64
unevictable:0 dirty:0 writeback:0 unstable:0
free:16763 slab_reclaimable:1340 slab_unreclaimable:2956
mapped:29 shmem:12 pagetables:11130 bounce:0
Node 0 DMA free:7892kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15772kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 4024 14836 14836
Node 0 DMA32 free:47464kB min:4224kB low:5280kB high:6336kB active_anon:3848564kB inactive_anon:147080kB active_file:0kB inactive_file:8kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4120800kB mlocked:0kB dirty:0kB writeback:0kB mapped:60kB shmem:0kB slab_reclaimable:28kB slab_unreclaimable:268kB kernel_stack:48kB pagetables:8604kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:82 all_unreclaimable? yes
lowmem_reserve[]: 0 0 10811 10811
Node 0 Normal free:11184kB min:11352kB low:14188kB high:17028kB active_anon:9906928kB inactive_anon:990904kB active_file:0kB inactive_file:1116kB unevictable:0kB isolated(anon):0kB isolated(file):256kB present:11071436kB mlocked:0kB dirty:0kB writeback:0kB mapped:56kB shmem:48kB slab_reclaimable:5332kB slab_unreclaimable:11556kB kernel_stack:2400kB pagetables:35916kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 3*4kB 1*8kB 2*16kB 1*32kB 0*64kB 3*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 1*4096kB = 7892kB
Node 0 DMA32: 62*4kB 104*8kB 53*16kB 29*32kB 27*64kB 7*128kB 2*256kB 3*512kB 1*1024kB 3*2048kB 8*4096kB = 47464kB
Node 0 Normal: 963*4kB 0*8kB 5*16kB 4*32kB 7*64kB 5*128kB 6*256kB 1*512kB 2*1024kB 1*2048kB 0*4096kB = 11292kB
318 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 0kB
Total swap = 0kB
3854801 pages RAM
86406 pages reserved
14574 pages shared
3738264 pages non-shared
It's happening because your server is running out of memory. To solve this problem you have 2 options.
Update your Server's Ram or use SWAP (But upgrading Physical ram is recommended instead of using SWAP)
Limit Nginx ram use.
To limit nginx ram use open the /etc/nginx/nginx.conf file and add client_max_body_size <your_value_here> under the http configuration block. For example:
worker_processes 1;
http {
client_max_body_size 10M;
...
}
Note: use M for MB, G for GB and T for TB
we have num 0x1234
In bigEndian:
low address -----------------> high address
0x12 | 0x34
In littleEndian:
low address -----------------> high address
0x34 | 0x12
we can see function below in binary.go:
func (bigEndian) PutUint16(b []byte, v uint16) {
_ = b[1] // early bounds check to guarantee safety of writes below
b[0] = byte(v >> 8)
b[1] = byte(v)
}
I download golang code of x86 and powpc arch and find the same definition.
https://golang.org/dl/
go1.12.7.linux-ppc64le.tar.gz Archive Linux ppc64le 99MB 8eda20600d90247efbfa70d116d80056e11192d62592240975b2a8c53caa5bf3
Now let's see what happen in this function.
If cpu is little endian, we store 0x1234 in memory like this:
low address -----------------> high address
0x34 | 0x12
v >> 8 means shift 8 bits right, means /2^8, so we get this in memory:
low address -----------------> high address
0x12 | 0x00
byte(v>>8), we get byte 0x12 which is in low address -> b[0]
byte(v), we get byte 0x34 -> b[1]
so we get the result which i think it's right:
[0x12,0x34]
=====================================
If cpu is big endian, we store 0x1234 in memory like this:
low address -----------------> high address
0x12 | 0x34
v >> 8 means shift 8 bits right, means /2^8, so we get this in memory:
low address -----------------> high address
0x00 | 0x12
byte(v>>8), we get byte 0x00 which is in low address -> b[0]
byte(v), we get byte 0x12 -> b[1]
so we get the result which i think it's not right:
[0x00,0x12]
I find in web how to check your cpu bigendian or little endian, and i write function below:
func IsBigEndian() bool {
test16 := uint16(0x1234)
test8 := *(*uint8)(unsafe.Pointer(&test16))
if test8 == 0x12{
return true
}else{
fmt.Printf("little")
return false
}
}
According to this function, I think byte() means get low address byte, am I right?
If right, why i get wrong result in analysis of "if cpu is big endian ..." ?
thanks a lot #Volker, I found this post Does bit-shift depend on endianness? . And know "byte(xxx)" operate in processor's register which not depend on the endianness in memory, so byte(0x1234) always get 0x34.
When I execute:
root#imx6slzbha:~# iw wlan0 scan
I receive the following as output, it gives me multiple nearby SSID data.
How can I fetch Signal strength based on a specific SSID Name?
Currently, I am fetching based on BSS using this command:
iw wlan0 scan | sed -n '/bc:d1:1f:16:55:c7/,/WMM/p' | grep signal | sed 's/.*-//' | awk '{print $1}' | cut -d . -f 1
But I may not know the BSS each time so need a generic answer to this requirement.enter image description here
BSS c8:00:84:85:41:b1 (on wlan0)
TSF: 4138861160471 usec (47d, 21:41:01)
freq: 2462
beacon interval: 102
capability: ESS ShortPreamble ShortSlotTime (0x1421)
signal: -80.00 dBm
last seen: 90 ms ago
SSID: Swarovski_Guest
Supported rates: 1.0* 2.0* 5.5* 6.0 9.0 11.0* 12.0 18.0
DS Parameter set: channel 11
Country: IN Environment: Indoor/Outdoor
Channels [1 - 11] # 30 dBm
ERP: <no flags>
HT capabilities:
Capabilities: 0x19ac
HT20
SM Power Save disabled
RX HT20 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT RX MCS rate indexes supported: 0-23
HT TX MCS rate indexes are undefined
Extended supported rates: 24.0 36.0 48.0 54.0
HT operation:
* primary channel: 11
* secondary channel offset: no secondary
* STA channel width: 20 MHz
* RIFS: 0
* HT protection: nonmember
* non-GF present: 1
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
Extended capabilities: 4, 6
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
BSS a0:ab:1b:cf:28:ae (on wlan0)
TSF: 3196211626 usec (0d, 00:53:16)
freq: 2462
beacon interval: 100
capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
signal: -74.00 dBm
last seen: 80 ms ago
Information elements from Probe Response frame:
SSID: FOTA_Rashmi_2.4G
Supported rates: 1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0
DS Parameter set: channel 11
Extended supported rates: 6.0 12.0 24.0 48.0
Country: EU Environment: Indoor/Outdoor
Channels [1 - 13] # 20 dBm
TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x2
WPS: * Version: 1.0
* Wi-Fi Protected Setup State: 2 (Configured)
* UUID: 28802880-2880-1880-a880-a0ab1bcf28ae
* RF Bands: 0x1
* Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20
ERP: <no flags>
HT capabilities:
Capabilities: 0x11ee
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT RX MCS rate indexes supported: 0-15, 32
HT TX MCS rate indexes are undefined
HT operation:
* primary channel: 11
* secondary channel offset: no secondary
* STA channel width: 20 MHz
* RIFS: 0
* HT protection: nonmember
* non-GF present: 0
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
Extended capabilities: HT Information Exchange Supported
WPA: * Version: 1
* Group cipher: TKIP
* Pairwise ciphers: TKIP CCMP
* Authentication suites: PSK
RSN: * Version: 1
* Group cipher: TKIP
* Pairwise ciphers: TKIP CCMP
* Authentication suites: PSK
* Capabilities: (0x0000)
WMM: * Parameter version 1
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
In order use a given SSID, e.g. "Swarovski_Guest" you can:
sed -n '/signal/h;/SSID: Swarovski_Guest/{x;s/^.*: -\(.*\) dBm$/\1/;p}'
look for signal strength /signal/
store it in history h;
look for specific SSID name /SSID: Swarovski_Guest/
retrieve the signal strength x;
trim anything but the value number s/^.*: -\(.*\) dBm$/\1/;
print it p
Output for sample input:
80.00
I am new to Go and trying to figure out how it manages memory consumption.
I have trouble with memory in one of my test projects. I don't understand why Go uses more and more memory (never freeing it) when my program runs for a long time.
I am running the test case provided below. After the first allocation, program uses nearly 350 MB of memory (according to ActivityMonitor). Then I try to free it and ActivityMonitor shows that memory consumption doubles. Why?
I am running this code on OS X using Go 1.0.3.
What is wrong with this code? And what is the right way to manage large variables in Go programs?
I had another memory-management-related problem when implementing an algorithm that uses a lot of time and memory; after running it for some time it throws an "out of memory" exception.
package main
import ("fmt"
"time"
)
func main() {
fmt.Println("getting memory")
tmp := make([]uint32, 100000000)
for kk, _ := range tmp {
tmp[kk] = 0
}
time.Sleep(5 * time.Second)
fmt.Println("returning memory")
tmp = make([]uint32, 1)
tmp = nil
time.Sleep(5 * time.Second)
fmt.Println("getting memory")
tmp = make([]uint32, 100000000)
for kk, _ := range tmp {
tmp[kk] = 0
}
time.Sleep(5 * time.Second)
fmt.Println("returning memory")
tmp = make([]uint32, 1)
tmp = nil
time.Sleep(5 * time.Second)
return
}
Currently, go uses a mark-and-sweep garbage collector, which in general does not define when the object is thrown away.
However, if you look closely, there is a go routine called sysmon which essentially runs as long as your program does and calls the GC periodically:
// forcegcperiod is the maximum time in nanoseconds between garbage
// collections. If we go this long without a garbage collection, one
// is forced to run.
//
// This is a variable for testing purposes. It normally doesn't change.
var forcegcperiod int64 = 2 * 60 * 1e9
(...)
// If a heap span goes unused for 5 minutes after a garbage collection,
// we hand it back to the operating system.
scavengelimit := int64(5 * 60 * 1e9)
forcegcperiod determines the period after which the GC is called by force. scavengelimit determines when spans are returned to the operating system. Spans are a number of memory pages which can hold several objects. They're kept for scavengelimit time and are freed if no object is on them and scavengelimit is exceeded.
Further down in the code you can see that there is a trace option. You can use this to see, whenever the
scavenger thinks he needs to clean up:
$ GOGCTRACE=1 go run gc.go
gc1(1): 0+0+0 ms 0 -> 0 MB 423 -> 350 (424-74) objects 0 handoff
gc2(1): 0+0+0 ms 1 -> 0 MB 2664 -> 1437 (2880-1443) objects 0 handoff
gc3(1): 0+0+0 ms 1 -> 0 MB 4117 -> 2213 (5712-3499) objects 0 handoff
gc4(1): 0+0+0 ms 2 -> 1 MB 3128 -> 2257 (6761-4504) objects 0 handoff
gc5(1): 0+0+0 ms 2 -> 0 MB 8892 -> 2531 (13734-11203) objects 0 handoff
gc6(1): 0+0+0 ms 1 -> 1 MB 8715 -> 2689 (20173-17484) objects 0 handoff
gc7(1): 0+0+0 ms 2 -> 1 MB 5231 -> 2406 (22878-20472) objects 0 handoff
gc1(1): 0+0+0 ms 0 -> 0 MB 172 -> 137 (173-36) objects 0 handoff
getting memory
gc2(1): 0+0+0 ms 381 -> 381 MB 203 -> 202 (248-46) objects 0 handoff
returning memory
getting memory
returning memory
As you can see, no gc invoke is done between getting and returning. However, if you change
the delay from 5 seconds to 3 minutes (more than the 2 minutes from forcegcperiod),
the objects are removed by the gc:
returning memory
scvg0: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
scvg0: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
scvg1: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
scvg1: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
gc9(1): 1+0+0 ms 1 -> 1 MB 4485 -> 2562 (26531-23969) objects 0 handoff
gc10(1): 1+0+0 ms 1 -> 1 MB 2563 -> 2561 (26532-23971) objects 0 handoff
scvg2: GC forced // forcegc (2 minutes) exceeded
scvg2: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
gc3(1): 0+0+0 ms 381 -> 381 MB 206 -> 206 (252-46) objects 0 handoff
scvg2: GC forced
scvg2: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
getting memory
The memory is still not freed, but the GC marked the memory region as unused. Freeing will begin when
the used span is unused and older than limit. From scavenger code:
if(s->unusedsince != 0 && (now - s->unusedsince) > limit) {
// ...
runtime·SysUnused((void*)(s->start << PageShift), s->npages << PageShift);
}
This behavior may of course change over time, but I hope you now get a bit of a feel when objects
are thrown away by force and when not.
As pointed out by zupa, releasing objects may not return the memory to the operating system, so on
certain systems you may not see a change in memory usage. This seems to be the case for Plan 9
and Windows according to this thread on golang-nuts.
To eventually (force) collect unused memory you must call runtime.GC().
variable = nil may make things unreachable and thus eligible for collection, but it per se doesn't free anything.
Based on following output of !address -summary command, I think I have got a native memory leak. In order to deterine the callstack on where these allocations are happening, I am following article at http://www.codeproject.com/KB/cpp/MemoryLeak.aspx
0:000> !address -summary
TEB 7efdd000 in range 7efdb000 7efde000
TEB 7efda000 in range 7efd8000 7efdb000
TEB 7efd7000 in range 7efd5000 7efd8000
TEB 7efaf000 in range 7efad000 7efb0000
TEB 7efac000 in range 7efaa000 7efad000
ProcessParametrs 00441b78 in range 00440000 00540000
Environment 004407f0 in range 00440000 00540000
-------------------- Usage SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Pct(Busy) Usage
551a000 ( 87144) : 04.16% 14.59% : RegionUsageIsVAD
5b8d3000 ( 1499980) : 71.53% 00.00% : RegionUsageFree
2cc3000 ( 45836) : 02.19% 07.68% : RegionUsageImage
4ff000 ( 5116) : 00.24% 00.86% : RegionUsageStack
0 ( 0) : 00.00% 00.00% : RegionUsageTeb
1c040000 ( 459008) : 21.89% 76.87% : RegionUsageHeap
0 ( 0) : 00.00% 00.00% : RegionUsagePageHeap
1000 ( 4) : 00.00% 00.00% : RegionUsagePeb
0 ( 0) : 00.00% 00.00% : RegionUsageProcessParametrs
0 ( 0) : 00.00% 00.00% : RegionUsageEnvironmentBlock
Tot: 7fff0000 (2097088 KB) Busy: 2471d000 (597108 KB)
0:000> !heap -s
LFH Key : 0x7fdcf95f
Termination on corruption : DISABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
00440000 00000002 453568 436656 453568 62 54 32 0 0 LFH
006b0000 00001002 64 16 64 4 2 1 0 0
002b0000 00041002 256 4 256 2 1 1 0 0
00620000 00001002 64 16 64 5 2 1 0 0
00250000 00001002 64 16 64 4 2 1 0 0
007d0000 00041002 256 4 256 0 1 1 0 0
005c0000 00001002 1088 388 1088 7 17 2 0 0 LFH
02070000 00041002 256 4 256 1 1 1 0 0
02270000 00041002 256 144 256 0 1 1 0 0 LFH
04e10000 00001002 3136 1764 3136 384 36 3 0 0 LFH
External fragmentation 21 % (36 free blocks)
-----------------------------------------------------------------------------
But when I run !heap -p –a command, I don’t get any callstack, just the following. Any ideas how to get callstack of allocations source?
0:000> !heap -p -a 0218e008
address 0218e008 found in
_HEAP # 4e10000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0218e000 001c 0000 [00] 0218e008 000d4 - (busy)
You should use deleaker. It's powerful tool for debuging.
use valgrind for linux and deleaker for windows.
If you don't get a call stack from !heap -p -a
The reason can be that you have not used gflags correctly
Remeber to use correct name including .exe
Try to start it inteactivly and go to the image tab, might be easier
Try with page heap, that also gives call stack
I know nothing about Windows, but at least on Unix systems a debugger (like gdb on Linux) is useful to understand callstacks.
And you could also circumvent some of your issues by using e.g. Boehm's conservative garbage collector. On many systems you can also hunt memory leaks with the help of valgrind