[lkml]   [2019]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28
>>>> The result of the bisection is
>>>> [88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for blkdev pages
>>>> Is that result relevant for the problem or should I continue bisecting between 4.20.0 and the so far first bad commit?
>>> Can you try reverting the commit and see if it makes the problem go away?
>> Tried reverting it on top of 5.0.0-rc6-00153-g5ded5871030e and it seems
>> to make the kernel work - emerge --sync succeeded.
There is more to it.

After running 5.0.0-rc6-00153-g5ded5871030e-dirty (with the revert of that patch)
successfully for Gentoo update, I upgraded the kernel to
5.0.0-rc7-00011-gb5372fe5dc84-dirty (todays git + revert of this patch) and it broke on rsync again:

RepoStorageException: command exited with status -6: rsync -a --link-dest /usr/portage --exclude=/distfiles --exclude=/local --exclude=/lost+found --exclude=/packages --exclude /.tmp-unverified-download-quarantine /usr/portage/ /usr/portage/.tmp-unverified-download-quarantine/

Nothing in dmesg.

This means the real root reason is somewhere deeper and reverting this commit just made
it less likely to happen.

Meelis Roos <>

 \ /
  Last update: 2019-02-19 13:17    [W:0.053 / U:3.496 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site