On 25.03.20 16:00, Tom Rini wrote:
On Wed, Mar 25, 2020 at 07:32:30AM +0100, Jan Kiszka wrote:
On 20.03.20 19:21, Tom Rini wrote:
On Mon, Mar 16, 2020 at 08:09:53PM +0100, Jan Kiszka wrote:
Hi all,
=> ls mmc 0:1 /usr/lib/linux-image-4.9.11-1.3.0-dirty
CACHE: Misaligned operation at range [bdfff998, bdfffd98]
CACHE: Misaligned operation at range [bdfff998, bdfffd98]
CACHE: Misaligned operation at range [bdfff998, bdfffd98]
CACHE: Misaligned operation at range [bdfff998, bdfffd98]
invalid extent block
I'm using master (50be9f0e1ccc) on the MCIMX7SABRE, defconfig.
What could this be? The filesystem is fine from Linux POV.
Use tune2fs -l and see if there's any new'ish features enabled that we
need some sort of check-and-reject for would be my first guess.
Here are the reported feature flags:
has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg
sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Of that, only metadata_csum means that you can't write to that image,
but you're just trying to read and that should be fine. Can you go back
in time a little and see if this problem persists or if it's been
introduced of late? Or recreate it on other platforms/SoCs? Thanks!
Bisected, regression of d5aee659f217 ("fs: ext4: cache extent data").
Reverting this commit over master resolves the issue.
Any idea what could be wrong? What I noticed is that the extent has a
zeroed magic when things go wrong, so maybe it is falsely considered to
be cached?
Jan
Anything too fancy in here? But the method of creating this filesystem does
not deviate from many other setups we have for U-Boot (on other boards).
Yes, but for some time now e2fsprogs has introduced new default features
that require compatibility checks.
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
