2018-03-10 12:41 GMT+03:00 Alexander Graf <ag...@suse.de>: > > >> Am 10.03.2018 um 10:05 schrieb Matwey V. Kornilov >> <matwey.korni...@gmail.com>: >> >> 2018-03-10 3:03 GMT+03:00 Alexander Graf <ag...@suse.de>: >>> >>> >>>> On 09.03.18 19:22, Matwey V. Kornilov wrote: >>>> Well, something strange happens at pre-init stage at Rock64: >>>> >>>> ===> Calling pre-init stage in system image >>>> [ 130.501368] systemd-udevd[1848]: starting version 234 >>>> [ 130.751693] device-mapper: uevent: version 1.0.3 >>>> [ 130.752483] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) >>>> initialised: dm-de...@redhat.com >>>> [ 133.143024] Internal error: Oops - SP/PC alignment exception: >>>> 8a000000 [#1] SMP >>>> [ 133.143029] Kernel panic - not syncing: corrupted stack end >>>> detected inside scheduler >>>> [ 133.143029] >>>> [ 133.143040] SMP: stopping secondary CPUs >>>> [ 133.144886] Modules linked in: dm_mod btrfs xor zstd_compress >>>> zlib_deflate raid6_pq fuse squashfs zstd_decompress xxhash loop >>>> virtio_blk mmc_block brd rk808_regulator rk808 aes_ce_blk >>>> aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64 >>>> sha1_ce dwc2 ohci_platform ohci_hcd ehci_platform ehci_hcd udc_core >>>> usbcore fixed dw_mmc_rockchip dw_mmc_pltfm dw_mmc >>>> phy_rockchip_inno_usb2 mmc_core rockchip_thermal i2c_rk3x aes_neon_bs >>>> aes_neon_blk crypto_simd cryptd aes_arm64 >>>> [ 133.148752] CPU: 2 PID: 1868 Comm: depmod Not tainted 4.15.7-1-default >>>> #1 >>>> [ 133.149360] Hardware name: rockchip rock64_rk3328/rock64_rk3328, >>>> BIOS 2018.01-rc2-02249-g19e31fac0d-dirty 02/01/2018 >>>> [ 133.150300] pstate: 20000005 (nzCv daif -PAN -UAO) >>>> [ 133.150738] pc : 0x6d6d61675f7465 >>> >>> localhost:~ # echo 6d6d61675f7465 | xxd -ps -r ; echo >>> mmag_te >>> >> >> No idea >> >>> Do you have any idea what that string could be? Maybe some memory that >>> really is in use by EL3 isn't declared as such in the EFI memory map? >> >> Well, the issue is gone when I reduced initial initrd size to reasonable >> value. > > Can you try some memory tester in user space then? I‘m not sure the issue is > actually gone, it might just not get exposed on boot anymore. >
Indeed. stress-ng --vm 1 --vm-bytes 75% --vm-method all --verify -t 10m -v hungs the system, but unfortunately there is no output on console, even with loglevel=8 > Alex > >> >>> >>> >>> Alex >> >> >> >> -- >> With best regards, >> Matwey V. Kornilov > -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
