All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Egorenkov <egorenar@linux.ibm.com>
To: linux@rasmusvillemoes.dk
Cc: akpm@linux-foundation.org, bp@alien8.de, corbet@lwn.net,
	gregkh@linuxfoundation.org, jeyu@kernel.org,
	linux-kernel@vger.kernel.org, mcgrof@kernel.org,
	ndesaulniers@google.com, torvalds@linux-foundation.org
Subject: Re: [PATCH v3 1/2] init/initramfs.c: do unpacking asynchronously
Date: Sat, 24 Jul 2021 09:46:46 +0200	[thread overview]
Message-ID: <87sg04p315.fsf@oc8242746057.ibm.com> (raw)
In-Reply-To: <20210313212528.2956377-2-linux@rasmusvillemoes.dk>
In-Reply-To: 

Hello,

since e7cb072eb988 ("init/initramfs.c: do unpacking asynchronously"), we
started seeing the following problem on s390 arch regularly:

[    5.039734] wait_for_initramfs() called before rootfs_initcalls
[    5.042003] cryptomgr_test (155) used greatest stack depth: 11952 bytes left
[    5.214115] raid6: vx128x8  gen() 21961 MB/s
[    5.384073] raid6: vx128x8  xor() 14882 MB/s
[    5.384090] raid6: using algorithm vx128x8 gen() 21961 MB/s
[    5.384094] raid6: .... xor() 14882 MB/s, rmw enabled
[    5.384098] raid6: using s390xc recovery algorithm
[    5.386338] iommu: Default domain type: Translated·
[    5.387724] SCSI subsystem initialized
[    5.393858] cio: Partition identifier 4.9
[    6.361599] VFS: Disk quotas dquot_6.6.0
[    6.361852] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    6.374790] NET: Registered PF_INET protocol family
[    6.375187] IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    6.381935] tcp_listen_portaddr_hash hash table entries: 8192 (order: 7, 720896 bytes, linear)
[    6.382234] TCP established hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    6.383133] TCP bind hash table entries: 65536 (order: 10, 5242880 bytes, vmalloc)
[    6.385373] TCP: Hash tables configured (established 131072 bind 65536)
[    6.394770] MPTCP token hash table entries: 16384 (order: 8, 1572864 bytes, linear)
[    6.395586] UDP hash table entries: 8192 (order: 8, 1572864 bytes, linear)
[    6.396531] UDP-Lite hash table entries: 8192 (order: 8, 1572864 bytes, linear)
[    6.405284] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    6.405821] Trying to unpack rootfs image as initramfs...
[    6.407794] alg: No test for crc32be (crc32be-vx)
[    6.436676] Initialise system trusted keyrings
[    6.436980] workingset: timestamp_bits=45 max_order=22 bucket_order=0
[    6.500365] zbud: loaded
[    6.516137] fuse: init (API version 7.34)
[    6.517210] SGI XFS with ACLs, security attributes, realtime, quota, fatal assert, debug enabled
[    6.544339] xor: automatically using best checksumming function   xc········
[    6.544363] Key type asymmetric registered
[    6.544389] Asymmetric key parser 'x509' registered
[    6.544448] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    6.545893] io scheduler mq-deadline registered
[    6.545927] io scheduler kyber registered
[    6.545933] blkcg_policy_register: BLKCG_MAX_POLS too small
[    6.599433] rootfs image is not initramfs (broken padding); looks like an initrd
[    6.669373] Freeing initrd memory: 24828K

It is very hard to reproduce, i haven't managed to do it yet and working
on it, but it occurs regularly, nearly every day once but only on a particular
test machine with our nightly s390 CI test runs.

Although the initramfs corruption is hard to reproduce,
the message 'wait_for_initramfs() called before rootfs_initcalls'
appears regularly on each boot at least since 2021-06-24 which we just
noticed a couple of days ago.

Appending 'initramfs_async=0' to the kernel command-line doesn't seem to
help with the 'wait_for_initramfs' message and i can still see it.

[    0.890962] wait_for_initramfs() called before rootfs_initcalls
[    1.060846] raid6: vx128x8  gen() 22394 MB/s
[    1.230783] raid6: vx128x8  xor() 14998 MB/s
[    1.230795] raid6: using algorithm vx128x8 gen() 22394 MB/s
[    1.230797] raid6: .... xor() 14998 MB/s, rmw enabled
[    1.230799] raid6: using s390xc recovery algorithm
[    1.231122] iommu: Default domain type: Translated
[    1.231331] SCSI subsystem initialized
[    1.231804] cio: Partition identifier 3.4
[    1.355331] PCI host bridge to bus 0000:00
[    1.355340] pci_bus 0000:00: root bus resource [bus 00]
[    1.355363] PCI host bridge to bus 0001:00
[    1.355364] pci_bus 0001:00: root bus resource [bus 00]
[    1.355490] pci 0000:00:00.0: [8086:0a54] type 00 class 0x010802
[    1.355541] pci 0000:00:00.0: reg 0x10: [mem 0xffffc00000000000-0xffffc00000003fff 64bit]
[    1.355611] pci 0000:00:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[    1.355625] pci 0000:00:00.0: enabling Extended Tags
[    1.355921] pci 0000:00:00.0: Adding to iommu group 0
[    1.632566] VFS: Disk quotas dquot_6.6.0
[    1.632624] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.634327] NET: Registered PF_INET protocol family
[    1.634395] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    1.635112] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
[    1.635129] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    1.635296] TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear)
[    1.635498] TCP: Hash tables configured (established 32768 bind 32768)
[    1.635834] MPTCP token hash table entries: 4096 (order: 4, 98304 bytes, linear)
[    1.635852] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    1.635882] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    1.636249] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    1.636419] Trying to unpack rootfs image as initramfs...
[    1.676907] Freeing initrd memory: 26056K

Regards
Alex

  parent reply	other threads:[~2021-07-24  7:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-13 21:25 [PATCH v3 0/2] background initramfs unpacking, and CONFIG_MODPROBE_PATH Rasmus Villemoes
2021-03-13 21:25 ` [PATCH v3 1/2] init/initramfs.c: do unpacking asynchronously Rasmus Villemoes
2021-03-15 20:21   ` Luis Chamberlain
2021-03-15 21:33   ` Andrew Morton
2021-03-15 21:59     ` Rasmus Villemoes
2021-07-24  7:46   ` Alexander Egorenkov [this message]
2021-07-26 11:46     ` Rasmus Villemoes
2021-07-27  7:31       ` Bruno Goncalves
2021-07-27 13:54         ` Luis Chamberlain
2021-07-27 14:12           ` Bruno Goncalves
2021-07-27 14:21             ` Luis Chamberlain
2021-07-27 14:27               ` Bruno Goncalves
2021-07-27 14:42                 ` Luis Chamberlain
2021-07-27 14:48                   ` Bruno Goncalves
2021-07-28 10:44                   ` Alexander Egorenkov
2021-07-28 10:38           ` Alexander Egorenkov
2021-07-28 10:36       ` Alexander Egorenkov
2021-07-28 11:49         ` Rasmus Villemoes
2021-03-13 21:25 ` [PATCH v3 2/2] modules: add CONFIG_MODPROBE_PATH Rasmus Villemoes
2021-03-15 20:06   ` Luis Chamberlain
2021-03-15 20:23 ` [PATCH v3 0/2] background initramfs unpacking, and CONFIG_MODPROBE_PATH Luis Chamberlain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sg04p315.fsf@oc8242746057.ibm.com \
    --to=egorenar@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mcgrof@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.