On Tuesday, 28 February 2023 04:13:18 CET Daniel Black wrote: > Source: linux > Version: 5.10.0-21-powerpc64le > Severity: grave > Justification: causes non-serious data loss > X-Debbugs-Cc: daniel@mariadb.org > > >From https://jira.mariadb.org/browse/MDEV-30728 > > MariaDB's mtr tests on a number of specific tests depend on the correct > kernel operation. > > As observed in these tests, there is a ~1/5 chance the > encryption.innodb_encryption test will read zeros on the later part of > the 16k pages that InnoDB uses by default. > > This affects MariaDB-10.6+ packages where there is a liburing in the > distribution. > > I tested on tmpfs. This is a different fault from bug #1020831 as: > * there is no iouring error, just a bunch of zeros where data was > expected. > * this is ppc64le only. What was the last kernel where this problem did NOT occur? It's probably needed to pinpoint the (upstream) commit that caused this error/ issue and the best start is normally finding the closest range with Debian kernel releases where it did not and did occur. > -- System Information: > Debian Release: bullseye > APT prefers jammy-updates > APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, > 'jammy'), (100, 'jammy-backports') Architecture: ppc64el (ppc64le) > > Kernel: Linux 5.10.0-21-powerpc64le (SMP w/128 CPU threads) > Init: unable to detect Why is there no 'bullseye' in APT policy's output? Mixing distrubutions (aka FrankenDebian) isn't recommended, but seeing no bullseye in there is odd, especially since the kernel version very much does look like Debian.
Attachment:
signature.asc
Description: This is a digitally signed message part.