* Widespread crashes in next-20180906 @ 2018-09-06 13:45 Guenter Roeck 2018-09-06 14:04 ` Theodore Y. Ts'o 0 siblings, 1 reply; 8+ messages in thread From: Guenter Roeck @ 2018-09-06 13:45 UTC (permalink / raw) To: David Howells, linux-kernel Build results: total: 134 pass: 133 fail: 1 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. Guenter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Widespread crashes in next-20180906 2018-09-06 13:45 Widespread crashes in next-20180906 Guenter Roeck @ 2018-09-06 14:04 ` Theodore Y. Ts'o 2018-09-06 14:13 ` Matt Hart 2018-09-06 15:41 ` Guenter Roeck 0 siblings, 2 replies; 8+ messages in thread From: Theodore Y. Ts'o @ 2018-09-06 14:04 UTC (permalink / raw) To: Guenter Roeck; +Cc: David Howells, linux-kernel On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote: > Build results: > total: 134 pass: 133 fail: 1 > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Widespread crashes in next-20180906 2018-09-06 14:04 ` Theodore Y. Ts'o @ 2018-09-06 14:13 ` Matt Hart 2018-09-06 15:23 ` Guenter Roeck 2018-09-06 19:43 ` Theodore Y. Ts'o 2018-09-06 15:41 ` Guenter Roeck 1 sibling, 2 replies; 8+ messages in thread From: Matt Hart @ 2018-09-06 14:13 UTC (permalink / raw) To: Theodore Y. Ts'o, Guenter Roeck, David Howells, linux-kernel On 6 September 2018 at 15:04, Theodore Y. Ts'o <tytso@mit.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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Widespread crashes in next-20180906 2018-09-06 14:13 ` Matt Hart @ 2018-09-06 15:23 ` Guenter Roeck 2018-09-06 19:14 ` Matt Hart 2018-09-06 19:43 ` Theodore Y. Ts'o 1 sibling, 1 reply; 8+ messages in thread From: Guenter Roeck @ 2018-09-06 15:23 UTC (permalink / raw) To: Matt Hart; +Cc: Theodore Y. Ts'o, David Howells, linux-kernel On Thu, Sep 06, 2018 at 03:13:23PM +0100, Matt Hart wrote: > On 6 September 2018 at 15:04, Theodore Y. Ts'o <tytso@mit.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. > I do, but as part of the boot tests, not as explicit build test, to save a bit of time. Maybe I should run a build test as well. > 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! Same error here, in the boot tests. Sorry, there are just too many failures there, and I didn't go through all the logs. Do you have bisect results ? Otherwise I can run bisect later today; that should hopefully identify the culprit. Thanks, Guenter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Widespread crashes in next-20180906 2018-09-06 15:23 ` Guenter Roeck @ 2018-09-06 19:14 ` Matt Hart 0 siblings, 0 replies; 8+ messages in thread From: Matt Hart @ 2018-09-06 19:14 UTC (permalink / raw) To: Guenter Roeck; +Cc: Theodore Y. Ts'o, David Howells, linux-kernel On 6 September 2018 at 16:23, Guenter Roeck <linux@roeck-us.net> wrote: > On Thu, Sep 06, 2018 at 03:13:23PM +0100, Matt Hart wrote: >> On 6 September 2018 at 15:04, Theodore Y. Ts'o <tytso@mit.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. >> > I do, but as part of the boot tests, not as explicit build test, > to save a bit of time. Maybe I should run a build test as well. > >> 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! > > Same error here, in the boot tests. Sorry, there are just too many > failures there, and I didn't go through all the logs. > > Do you have bisect results ? Otherwise I can run bisect later today; > that should hopefully identify the culprit. Bisecting it now, though it might finish after I'm done for the night. > > Thanks, > Guenter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Widespread crashes in next-20180906 2018-09-06 14:13 ` Matt Hart 2018-09-06 15:23 ` Guenter Roeck @ 2018-09-06 19:43 ` Theodore Y. Ts'o 2018-09-07 14:49 ` Matt Hart 1 sibling, 1 reply; 8+ messages in thread From: Theodore Y. Ts'o @ 2018-09-06 19:43 UTC (permalink / raw) To: Matt Hart; +Cc: Guenter Roeck, David Howells, linux-kernel On Thu, Sep 06, 2018 at 03:13:23PM +0100, Matt Hart wrote: > On 6 September 2018 at 15:04, Theodore Y. Ts'o <tytso@mit.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 At a guess, from the MAINTAINERS file ARM/Allwinner sunXi SoC support M: Maxime Ripard <maxime.ripard@bootlin.com> M: Chen-Yu Tsai <wens@csie.org> - Ted ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Widespread crashes in next-20180906 2018-09-06 19:43 ` Theodore Y. Ts'o @ 2018-09-07 14:49 ` Matt Hart 0 siblings, 0 replies; 8+ messages in thread From: Matt Hart @ 2018-09-07 14:49 UTC (permalink / raw) To: Theodore Y. Ts'o, Matt Hart, Guenter Roeck, David Howells, linux-kernel On 6 September 2018 at 20:43, Theodore Y. Ts'o <tytso@mit.edu> wrote: > On Thu, Sep 06, 2018 at 03:13:23PM +0100, Matt Hart wrote: >> On 6 September 2018 at 15:04, Theodore Y. Ts'o <tytso@mit.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 > > At a guess, from the MAINTAINERS file > > ARM/Allwinner sunXi SoC support > M: Maxime Ripard <maxime.ripard@bootlin.com> > M: Chen-Yu Tsai <wens@csie.org> Seems they are already on the case https://www.spinics.net/lists/arm-kernel/msg675227.html > > - Ted ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Widespread crashes in next-20180906 2018-09-06 14:04 ` Theodore Y. Ts'o 2018-09-06 14:13 ` Matt Hart @ 2018-09-06 15:41 ` Guenter Roeck 1 sibling, 0 replies; 8+ messages in thread From: Guenter Roeck @ 2018-09-06 15:41 UTC (permalink / raw) To: Theodore Y. Ts'o, David Howells, linux-kernel On Thu, Sep 06, 2018 at 10:04:13AM -0400, Theodore Y. Ts'o wrote: > On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote: > > Build results: > > total: 134 pass: 133 fail: 1 > > 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 > That thing is just asking for trouble. Why not leave return type and value alone and add vm_fault_t * (assuming it really adds value) as another parameter ? Is it really a good idea to deviate from "return well defined error as integer" as used everywhere else in the kernel ? Do we really need "my_favored_error_return_t" in every subsystem going forward ? Oh well, I guess (hope) that is all discussed in the other thread. > 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... > Looking at the patch, NACK seems like the proper response to me, maybe augmented with "please refrain from shooting yourself (and everyone else) in the foot". Guenter ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-09-07 14:49 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-06 13:45 Widespread crashes in next-20180906 Guenter Roeck 2018-09-06 14:04 ` Theodore Y. Ts'o 2018-09-06 14:13 ` Matt Hart 2018-09-06 15:23 ` Guenter Roeck 2018-09-06 19:14 ` Matt Hart 2018-09-06 19:43 ` Theodore Y. Ts'o 2018-09-07 14:49 ` Matt Hart 2018-09-06 15:41 ` Guenter Roeck
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.