ext4: invalid extent block on imx7

[Tom Rini <trini@konsulko.com>]

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!

> 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200325/b2f178b0/attachment.sig>