[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH+k93Fgk2yZ3OzBOL2uxSVuOqEJB5wS1Zfny8bDkbuQ3sM6Jw@mail.gmail.com>
Date: Thu, 6 Sep 2018 15:13:23 +0100
From: Matt Hart <matthew.hart@...aro.org>
To: "Theodore Y. Ts'o" <tytso@....edu>,
Guenter Roeck <linux@...ck-us.net>,
David Howells <dhowells@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Widespread crashes in next-20180906
On 6 September 2018 at 15:04, Theodore Y. Ts'o <tytso@....edu> wrote:
> On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote:
>> Build results:
>> total: 134 pass: 133 fail: 1
Do you build arm64? Because KernelCI is seeing build failures in arm64
defconfig for next-20180906
Clearly it's a module build problem for sunxi but I'm not sure who to
CC about this.
https://kernelci.org/build/next/branch/master/kernel/next-20180906/
https://storage.kernelci.org/next/master/next-20180906/arm64/defconfig/build.log
ERROR: "sun8i_tcon_top_de_config"
[drivers/gpu/drm/sun4i/sun4i-tcon.ko] undefined!
ERROR: "sun8i_tcon_top_set_hdmi_src"
[drivers/gpu/drm/sun4i/sun4i-tcon.ko] undefined!
ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
undefined!
../scripts/Makefile.modpost:92: recipe for target '__modpost' failed
make[2]: *** [__modpost] Error 1
make[2]: Target '_modpost' not remade because of errors.
/home/buildslave/workspace/kernel-build/linux/Makefile:1223: recipe
for target 'modules' failed
make[1]: *** [modules] Error 2
make[1]: Target '_all' not remade because of errors.
Makefile:146: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Target '_all' not remade because of errors.
>> Failed builds:
>> sparc32:allmodconfig
>> Qemu test results:
>> total: 311 pass: 76 fail: 235
>> Failed builds:
>> <pretty much everything trying to boot from disk>
>>
>> Error message is always something like
>>
>> Filesystem requires source device
>> VFS: Cannot open root device "hda" or unknown-block(3,0): error -2
>>
>> The only variance is the boot device. Logs in full glory are available
>> at https://kerneltests.org/builders/, in the "next" column.
>>
>> I did not run bisect, but the recent filesystem changes are a definite suspect.
>
> Yes, this is the vm_fault_t changes. See the other thread on LKML.
> The guilty commit was: 83c0adddcc6e: fs: convert return type int to
> vm_fault_t
>
> This is the *second* time vm_fault_t patches have broken things. The
> first time it went through the ext4 tree, and I NACK'ed it after
> running a 60 second smoke test showed it was broken. The seocnd time
> the problem was supposedly fixed, but it went through the mm tree, and
> so I didn't have a chance regression test or stop it...
>
> - Ted
Powered by blists - more mailing lists