lkml.org 
[lkml]   [2018]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4.17 00/67] 4.17.7-stable review
On Mon, Jul 16, 2018 at 09:40:33AM -0700, Nathan Chancellor wrote:
> On Mon, Jul 16, 2018 at 09:33:38AM -0700, Guenter Roeck wrote:
> > On Mon, Jul 16, 2018 at 09:34:29AM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.17.7 release.
> > > There are 67 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Wed Jul 18 07:34:11 UTC 2018.
> > > Anything received after that time might be too late.
> > >
> >
> > Build results:
> > total: 134 pass: 134 fail: 0
> > Qemu test results:
> > total: 171 pass: 159 fail: 12
> > Failed tests:
> > i386:Broadwell:q35:defconfig:smp:rootfs
> > i386:Skylake-Client:q35:defconfig:smp:rootfs
> > i386:SandyBridge:q35:defconfig:smp:rootfs
> > i386:Haswell:pc:defconfig:smp:rootfs
> > i386:Nehalem:q35:defconfig:smp:rootfs
> > i386:phenom:pc:defconfig:smp:rootfs
> > i386:Opteron_G5:q35:defconfig:smp:initrd
> > i386:Westmere:q35:defconfig:smp:initrd
> > i386:core2duo:q35:defconfig:nosmp:rootfs
> > i386:Conroe:pc:defconfig:nosmp:rootfs
> > i386:Opteron_G1:pc:defconfig:nosmp:initrd
> > i386:n270:q35:defconfig:nosmp:rootfs
> >
> > All 32-bit i386 boot tests crash.
> >
> > [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at 00000000
> > [ 0.000000] *pde = 00000000
> > [ 0.000000] Oops: 0002 [#1] SMP
> > [ 0.000000] Modules linked in:
> > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.7-rc1+ #1
> > [ 0.000000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/24
> > [ 0.000000] EIP: zero_resv_unavail+0x9b/0x103
> > [ 0.000000] EFLAGS: 00200002 CPU: 0
> > [ 0.000000] EAX: 00000000 EBX: 00000000 ECX: 00000008 EDX: 00000000
> > [ 0.000000] ESI: c6bc5e90 EDI: 00000000 EBP: c6bc5eac ESP: c6bc5e80
> > [ 0.000000] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > [ 0.000000] CR0: 80050033 CR2: 00000000 CR3: 06d67000 CR4: 00040690
> > [ 0.000000] Call Trace:
> > [ 0.000000] free_area_init_nodes+0x407/0x44c
> > [ 0.000000] zone_sizes_init+0x45/0x5c
> > [ 0.000000] paging_init+0xac/0xaf
> > [ 0.000000] native_pagetable_init+0xc6/0xce
> > [ 0.000000] setup_arch+0x9c6/0xb18
> > [ 0.000000] start_kernel+0x4f/0x3d2
> > [ 0.000000] ? idt_setup_early_handler+0x2b/0x3e
> > [ 0.000000] i386_start_kernel+0x95/0x99
> > [ 0.000000] startup_32_smp+0x164/0x168
> >
> > Guenter
>
> I think this is caused by 3e3eda67092b ("mm: zero available pages before
> memmap init"). A fix for it was posted to the mailing list this morning:
> https://lore.kernel.org/lkml/20180716151630.770-1-pasha.tatashin@oracle.com/
>

Yes, it looks like this was inherited from upstream. The same failure is seen
in in v4.17-rc5 and next-20180716.

Guenter

\
 
 \ /
  Last update: 2018-07-16 18:48    [W:0.127 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site