Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1648658 > unrolled thread

[PATCH 4.4 000/103] 4.4.70-stable review

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2017-05-23 23:00 +0200
Last post2017-05-24 22:30 +0200
Articles 15 on this page of 35 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 099/103] PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 098/103] tracing/kprobes: Enforce kprobes teardown after testing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 097/103] osf_wait4(): fix infoleak Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 095/103] uwb: fix device quirk on big-endian hosts Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 012/103] dm bufio: avoid a possible ABBA deadlock Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 037/103] proc: Fix unbalanced hard link numbers Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 029/103] drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations. Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 034/103] drm/nouveau/tmr: avoid processing completed alarms when adding a new one Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 078/103] [media] cx231xx-cards: fix NULL-deref at probe Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 014/103] dm cache metadata: fail operations if fail_io mode has been established Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:00 +0200
    [PATCH 4.4 077/103] [media] cx231xx-audio: fix NULL-deref at probe Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:10 +0200
    [PATCH 4.4 080/103] powerpc/pseries: Fix of_node_put() underflow during DLPAR remove Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:10 +0200
    [PATCH 4.4 073/103] [media] dib0700: fix NULL-deref at probe Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:20 +0200
    [PATCH 4.4 082/103] ARM: dts: at91: sama5d3_xplained: fix ADC vref Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:20 +0200
    [PATCH 4.4 081/103] powerpc/64e: Fix hang when debugging programs with relocated kernel Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:20 +0200
    [PATCH 4.4 079/103] powerpc/book3s/mce: Move add_taint() later in virtual mode Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:20 +0200
    [PATCH 4.4 102/103] nfsd: encoders mustnt use unitialized values in error cases Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:30 +0200
    [PATCH 4.4 103/103] drivers: char: mem: Check for address space wraparound with mmap() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:30 +0200
    [PATCH 4.4 101/103] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-23 23:30 +0200
    Re: [PATCH 4.4 000/103] 4.4.70-stable review Guenter Roeck <linux@roeck-us.net> - 2017-05-24 06:10 +0200
      Re: [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-24 09:00 +0200
        Re: [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-24 09:00 +0200
    Re: [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-24 09:10 +0200
      Re: [PATCH 4.4 000/103] 4.4.70-stable review Thomas Voegtle <tv@lio96.de> - 2017-05-24 11:40 +0200
        Re: [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-24 13:40 +0200
          Re: [PATCH 4.4 000/103] 4.4.70-stable review Thomas Voegtle <tv@lio96.de> - 2017-05-24 14:10 +0200
            Re: [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-24 15:00 +0200
      Re: [PATCH 4.4 000/103] 4.4.70-stable review Guenter Roeck <linux@roeck-us.net> - 2017-05-24 14:50 +0200
        Re: [PATCH 4.4 000/103] 4.4.70-stable review Mark Brown <broonie@kernel.org> - 2017-05-24 15:10 +0200
          Re: [PATCH 4.4 000/103] 4.4.70-stable review Guenter Roeck <linux@roeck-us.net> - 2017-05-24 15:20 +0200
            Re: [PATCH 4.4 000/103] 4.4.70-stable review Mark Brown <broonie@kernel.org> - 2017-05-24 17:10 +0200
          Re: [PATCH 4.4 000/103] 4.4.70-stable review Guenter Roeck <linux@roeck-us.net> - 2017-05-24 15:40 +0200
    Re: [PATCH 4.4 000/103] 4.4.70-stable review Guenter Roeck <linux@roeck-us.net> - 2017-05-24 22:30 +0200

Page 2 of 2 — ← Prev page 1 [2]


#1648783 — [PATCH 4.4 101/103] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-05-23 23:30 +0200
Subject[PATCH 4.4 101/103] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2
Message-ID<tKpxp-AI-61@gated-at.bofh.it>
In reply to#1648658
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Mario Kleiner <mario.kleiner.de@gmail.com>

commit e345da82bd6bdfa8492f80b3ce4370acfd868d95 upstream.

The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.

Add a quirk to get the full 10 bpc.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1492787108-23959-1-git-send-email-mario.kleiner.de@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/drm_edid.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -75,6 +75,8 @@
 #define EDID_QUIRK_FORCE_12BPC			(1 << 9)
 /* Force 6bpc */
 #define EDID_QUIRK_FORCE_6BPC			(1 << 10)
+/* Force 10bpc */
+#define EDID_QUIRK_FORCE_10BPC			(1 << 11)
 
 struct detailed_mode_closure {
 	struct drm_connector *connector;
@@ -117,6 +119,9 @@ static struct edid_quirk {
 	{ "FCM", 13600, EDID_QUIRK_PREFER_LARGE_75 |
 	  EDID_QUIRK_DETAILED_IN_CM },
 
+	/* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
+	{ "LGD", 764, EDID_QUIRK_FORCE_10BPC },
+
 	/* LG Philips LCD LP154W01-A5 */
 	{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
 	{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
@@ -3834,6 +3839,9 @@ int drm_add_edid_modes(struct drm_connec
 	if (quirks & EDID_QUIRK_FORCE_8BPC)
 		connector->display_info.bpc = 8;
 
+	if (quirks & EDID_QUIRK_FORCE_10BPC)
+		connector->display_info.bpc = 10;
+
 	if (quirks & EDID_QUIRK_FORCE_12BPC)
 		connector->display_info.bpc = 12;
 

[toc] | [prev] | [next] | [standalone]


#1649082

FromGuenter Roeck <linux@roeck-us.net>
Date2017-05-24 06:10 +0200
Message-ID<tKvMt-5sv-1@gated-at.bofh.it>
In reply to#1648658
On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.70 release.
> There are 103 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 Thu May 25 20:08:25 UTC 2017.
> Anything received after that time might be too late.
> 

Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.

Guenter

---

...
EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
BUG: unable to handle kernel paging request at 0000000000002280
IP: [<ffffffff81451115>] process_echoes+0x15/0x70
PGD da68067 PUD d991067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
RIP: 0010:[<ffffffff81451115>]  [<ffffffff81451115>] process_echoes+0x15/0x70
RSP: 0018:ffff88000d233d50  EFLAGS: 00000202
RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
FS:  00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
Stack:
  ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
  ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
  ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
Call Trace:
  [<ffffffff814515b7>] n_tty_write+0x97/0x4e0
  [<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
  [<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
  [<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
  [<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
  [<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
  [<ffffffff81199abe>] ? __fd_install+0x5e/0x110
  [<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
  [<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
  [<ffffffff8117df3a>] vfs_write+0x9a/0x170
  [<ffffffff8117ea96>] SyS_write+0x46/0xb0
  [<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
RIP  [<ffffffff81451115>] process_echoes+0x15/0x70
  RSP <ffff88000d233d50>
CR2: 0000000000002280
---[ end trace cec672c0d4b54e81 ]---
Kernel panic - not syncing: Fatal exception
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception

[toc] | [prev] | [next] | [standalone]


#1649160

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-05-24 09:00 +0200
Message-ID<tKyr0-7d2-5@gated-at.bofh.it>
In reply to#1649082
On Tue, May 23, 2017 at 09:01:05PM -0700, Guenter Roeck wrote:
> On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.70 release.
> > There are 103 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 Thu May 25 20:08:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.
> 
> Guenter
> 
> ---
> 
> ...
> EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
> BUG: unable to handle kernel paging request at 0000000000002280
> IP: [<ffffffff81451115>] process_echoes+0x15/0x70
> PGD da68067 PUD d991067 PMD 0
> Oops: 0000 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
> RIP: 0010:[<ffffffff81451115>]  [<ffffffff81451115>] process_echoes+0x15/0x70
> RSP: 0018:ffff88000d233d50  EFLAGS: 00000202
> RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
> RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
> RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
> R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
> R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
> FS:  00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
> Stack:
>  ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
>  ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
>  ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
> Call Trace:
>  [<ffffffff814515b7>] n_tty_write+0x97/0x4e0
>  [<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
>  [<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
>  [<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
>  [<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
>  [<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
>  [<ffffffff81199abe>] ? __fd_install+0x5e/0x110
>  [<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
>  [<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
>  [<ffffffff8117df3a>] vfs_write+0x9a/0x170
>  [<ffffffff8117ea96>] SyS_write+0x46/0xb0
>  [<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
> Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
> RIP  [<ffffffff81451115>] process_echoes+0x15/0x70
>  RSP <ffff88000d233d50>
> CR2: 0000000000002280
> ---[ end trace cec672c0d4b54e81 ]---
> Kernel panic - not syncing: Fatal exception
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: Fatal exception

Yes, bisection would be great, if you can do it.  I would blame the only
tty patch in the release,
tty-prevent-ldisc-drivers-from-re-using-stale-tty-fields.patch, but that
would be odd.

Oops, nope, that would be it, the merge happened badly, I applied a
chunk in the wrong place, ugh.  Let me go fix that patch up now...

greg k-h

[toc] | [prev] | [next] | [standalone]


#1649164

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-05-24 09:00 +0200
Message-ID<tKyr0-7d2-15@gated-at.bofh.it>
In reply to#1649160
On Wed, May 24, 2017 at 08:50:39AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 23, 2017 at 09:01:05PM -0700, Guenter Roeck wrote:
> > On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.70 release.
> > > There are 103 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 Thu May 25 20:08:25 UTC 2017.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.
> > 
> > Guenter
> > 
> > ---
> > 
> > ...
> > EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
> > BUG: unable to handle kernel paging request at 0000000000002280
> > IP: [<ffffffff81451115>] process_echoes+0x15/0x70
> > PGD da68067 PUD d991067 PMD 0
> > Oops: 0000 [#1] PREEMPT SMP
> > Modules linked in:
> > CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> > task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
> > RIP: 0010:[<ffffffff81451115>]  [<ffffffff81451115>] process_echoes+0x15/0x70
> > RSP: 0018:ffff88000d233d50  EFLAGS: 00000202
> > RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
> > RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
> > RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
> > R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
> > R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
> > FS:  00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
> > Stack:
> >  ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
> >  ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
> >  ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
> > Call Trace:
> >  [<ffffffff814515b7>] n_tty_write+0x97/0x4e0
> >  [<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
> >  [<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
> >  [<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
> >  [<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
> >  [<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
> >  [<ffffffff81199abe>] ? __fd_install+0x5e/0x110
> >  [<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
> >  [<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
> >  [<ffffffff8117df3a>] vfs_write+0x9a/0x170
> >  [<ffffffff8117ea96>] SyS_write+0x46/0xb0
> >  [<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
> > Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
> > RIP  [<ffffffff81451115>] process_echoes+0x15/0x70
> >  RSP <ffff88000d233d50>
> > CR2: 0000000000002280
> > ---[ end trace cec672c0d4b54e81 ]---
> > Kernel panic - not syncing: Fatal exception
> > Kernel Offset: disabled
> > ---[ end Kernel panic - not syncing: Fatal exception
> 
> Yes, bisection would be great, if you can do it.  I would blame the only
> tty patch in the release,
> tty-prevent-ldisc-drivers-from-re-using-stale-tty-fields.patch, but that
> would be odd.
> 
> Oops, nope, that would be it, the merge happened badly, I applied a
> chunk in the wrong place, ugh.  Let me go fix that patch up now...

And that was because this patch was already merged in an older release,
my fault.  I've dropped it now, and pushed out an update, this should
fix the problem.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]


#1649166

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-05-24 09:10 +0200
Message-ID<tKyAF-7wq-5@gated-at.bofh.it>
In reply to#1648658
On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
> 
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> 
> Tree: stable-rc
> Branch: linux-4.4.y
> Git Describe: v4.4.69-104-g2ebff3b7590b
> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199

54 passed?  I had a bug here such that all x86 builds were crashing, in
the core tty layer, which seems odd that anything would be able to boot
with this tree...

I've pushed out an update, can you all verify that it also works?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]


#1649373

FromThomas Voegtle <tv@lio96.de>
Date2017-05-24 11:40 +0200
Message-ID<tKAVP-wS-7@gated-at.bofh.it>
In reply to#1649166
On Wed, 24 May 2017, Greg Kroah-Hartman wrote:

> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>
>> Tree: stable-rc
>> Branch: linux-4.4.y
>> Git Describe: v4.4.69-104-g2ebff3b7590b
>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
>
> 54 passed?  I had a bug here such that all x86 builds were crashing, in
> the core tty layer, which seems odd that anything would be able to boot
> with this tree...
>
> I've pushed out an update, can you all verify that it also works?


I got this:

   CALL    scripts/checksyscalls.sh
   CHK     include/generated/compile.h
   CC      kernel/fork.o
kernel/fork.c: In function 'dup_task_struct':
kernel/fork.c:371:2: error: implicit declaration of function
'get_random_long' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [kernel/fork.o] Error 1
make: *** [kernel] Error 2


This is 
stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch

[toc] | [prev] | [next] | [standalone]


#1649511

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-05-24 13:40 +0200
Message-ID<tKCNY-1KT-21@gated-at.bofh.it>
In reply to#1649373
On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> 
> > On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> > > stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
> > > 
> > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > 
> > > Tree: stable-rc
> > > Branch: linux-4.4.y
> > > Git Describe: v4.4.69-104-g2ebff3b7590b
> > > Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
> > 
> > 54 passed?  I had a bug here such that all x86 builds were crashing, in
> > the core tty layer, which seems odd that anything would be able to boot
> > with this tree...
> > 
> > I've pushed out an update, can you all verify that it also works?
> 
> 
> I got this:
> 
>   CALL    scripts/checksyscalls.sh
>   CHK     include/generated/compile.h
>   CC      kernel/fork.o
> kernel/fork.c: In function 'dup_task_struct':
> kernel/fork.c:371:2: error: implicit declaration of function
> 'get_random_long' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[1]: *** [kernel/fork.o] Error 1
> make: *** [kernel] Error 2
> 
> 
> This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch

What arch/.config are you building for that causes this?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]


#1649549

FromThomas Voegtle <tv@lio96.de>
Date2017-05-24 14:10 +0200
Message-ID<tKDh0-2cD-15@gated-at.bofh.it>
In reply to#1649511
On Wed, 24 May 2017, Greg Kroah-Hartman wrote:

> On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
>> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
>>
>>> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>>>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>>>
>>>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>>>
>>>> Tree: stable-rc
>>>> Branch: linux-4.4.y
>>>> Git Describe: v4.4.69-104-g2ebff3b7590b
>>>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>>>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>>>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
>>>
>>> 54 passed?  I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
>>>
>>> I've pushed out an update, can you all verify that it also works?
>>
>>
>> I got this:
>>
>>   CALL    scripts/checksyscalls.sh
>>   CHK     include/generated/compile.h
>>   CC      kernel/fork.o
>> kernel/fork.c: In function 'dup_task_struct':
>> kernel/fork.c:371:2: error: implicit declaration of function
>> 'get_random_long' [-Werror=implicit-function-declaration]
>> cc1: some warnings being treated as errors
>> make[1]: *** [kernel/fork.o] Error 1
>> make: *** [kernel] Error 2
>>
>>
>> This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
>
> What arch/.config are you building for that causes this?


x86_64 and CONFIG_CC_STACKPROTECTOR=y

The rest of my kernel config is SuSE's kernel-default config.

get_random_long came with v4.5 as far as I know

I have a running 4.4.70-rc1, Without that mentioned patch and using the 
latest rc patch.

[toc] | [prev] | [next] | [standalone]


#1649592

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-05-24 15:00 +0200
Message-ID<tKE3n-2t8-7@gated-at.bofh.it>
In reply to#1649549
On Wed, May 24, 2017 at 02:04:32PM +0200, Thomas Voegtle wrote:
> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> 
> > On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
> > > On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> > > 
> > > > On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> > > > > stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
> > > > > 
> > > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > > > 
> > > > > Tree: stable-rc
> > > > > Branch: linux-4.4.y
> > > > > Git Describe: v4.4.69-104-g2ebff3b7590b
> > > > > Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> > > > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > > Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
> > > > 
> > > > 54 passed?  I had a bug here such that all x86 builds were crashing, in
> > > > the core tty layer, which seems odd that anything would be able to boot
> > > > with this tree...
> > > > 
> > > > I've pushed out an update, can you all verify that it also works?
> > > 
> > > 
> > > I got this:
> > > 
> > >   CALL    scripts/checksyscalls.sh
> > >   CHK     include/generated/compile.h
> > >   CC      kernel/fork.o
> > > kernel/fork.c: In function 'dup_task_struct':
> > > kernel/fork.c:371:2: error: implicit declaration of function
> > > 'get_random_long' [-Werror=implicit-function-declaration]
> > > cc1: some warnings being treated as errors
> > > make[1]: *** [kernel/fork.o] Error 1
> > > make: *** [kernel] Error 2
> > > 
> > > 
> > > This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
> > 
> > What arch/.config are you building for that causes this?
> 
> 
> x86_64 and CONFIG_CC_STACKPROTECTOR=y
> 
> The rest of my kernel config is SuSE's kernel-default config.
> 
> get_random_long came with v4.5 as far as I know
> 
> I have a running 4.4.70-rc1, Without that mentioned patch and using the
> latest rc patch.

You are right, this shouldn't have gone to the 4.4-stable tree, thanks
for catching it.  I've now dropped it.

thanks again,

greg k-h

[toc] | [prev] | [next] | [standalone]


#1649586

FromGuenter Roeck <linux@roeck-us.net>
Date2017-05-24 14:50 +0200
Message-ID<tKDTI-2pQ-13@gated-at.bofh.it>
In reply to#1649166
On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>
>> Tree: stable-rc
>> Branch: linux-4.4.y
>> Git Describe: v4.4.69-104-g2ebff3b7590b
>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
> 
> 54 passed?  I had a bug here such that all x86 builds were crashing, in
> the core tty layer, which seems odd that anything would be able to boot
> with this tree...
> 
Final qemu test result was
	total: 115 pass: 89 fail: 26
with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
assuming kernelci does not (yet) run any x86/x86_64 qemu tests.

Guenter

[toc] | [prev] | [next] | [standalone]


#1649606

FromMark Brown <broonie@kernel.org>
Date2017-05-24 15:10 +0200
Message-ID<tKEd4-2Lr-23@gated-at.bofh.it>
In reply to#1649586

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:

> > 54 passed?  I had a bug here such that all x86 builds were crashing, in
> > the core tty layer, which seems odd that anything would be able to boot
> > with this tree...

> Final qemu test result was
> 	total: 115 pass: 89 fail: 26
> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.

Not qemu but it has some physical x86 tests like:

    https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html

which seem to have managed to boot somehow.  It's a minnowboard with no
video and it's booting to a ramdisk, I don't know if either of those
helped avoid the issue.

[toc] | [prev] | [next] | [standalone]


#1649609

FromGuenter Roeck <linux@roeck-us.net>
Date2017-05-24 15:20 +0200
Message-ID<tKEmJ-2OP-1@gated-at.bofh.it>
In reply to#1649606
On 05/24/2017 05:58 AM, Mark Brown wrote:
> On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
>> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
> 
>>> 54 passed?  I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
> 
>> Final qemu test result was
>> 	total: 115 pass: 89 fail: 26
>> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
>> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
> 
> Not qemu but it has some physical x86 tests like:
> 
>      https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html
> 
> which seem to have managed to boot somehow.  It's a minnowboard with no
> video and it's booting to a ramdisk, I don't know if either of those
> helped avoid the issue.
> 

Either that or it is related to the kernel configuration (which, in my case,
was picked from an old yocto version).

Guenter

[toc] | [prev] | [next] | [standalone]


#1649698

FromMark Brown <broonie@kernel.org>
Date2017-05-24 17:10 +0200
Message-ID<tKG5c-3Wx-35@gated-at.bofh.it>
In reply to#1649609

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 24, 2017 at 06:18:00AM -0700, Guenter Roeck wrote:
> On 05/24/2017 05:58 AM, Mark Brown wrote:

> > which seem to have managed to boot somehow.  It's a minnowboard with no
> > video and it's booting to a ramdisk, I don't know if either of those
> > helped avoid the issue.

> Either that or it is related to the kernel configuration (which, in my case,
> was picked from an old yocto version).

Yeah, kernelci is using upstream defconfigs plus a couple of defconfig+X
things.  What's the config you're using, perhaps there's some options
that we ought to be adding somewhere for coverage?

[toc] | [prev] | [next] | [standalone]


#1649619

FromGuenter Roeck <linux@roeck-us.net>
Date2017-05-24 15:40 +0200
Message-ID<tKEG6-2V1-13@gated-at.bofh.it>
In reply to#1649606
On 05/24/2017 05:58 AM, Mark Brown wrote:
> On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
>> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
> 
>>> 54 passed?  I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
> 
>> Final qemu test result was
>> 	total: 115 pass: 89 fail: 26
>> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
>> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
> 
> Not qemu but it has some physical x86 tests like:
> 
>      https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html
> 
> which seem to have managed to boot somehow.  It's a minnowboard with no
> video and it's booting to a ramdisk, I don't know if either of those
> helped avoid the issue.
> 
I had another look; it may be related to the configuration. Turns out
I also had crashes in some mips64 and ppc/ppc64 tests, but not all of
them. For example, mips64 big endian crashed, but the same configuration
little endian passed.

I think I'll add some config file variations to my x86 tests.

Guenter

[toc] | [prev] | [next] | [standalone]


#1649927

FromGuenter Roeck <linux@roeck-us.net>
Date2017-05-24 22:30 +0200
Message-ID<tKL4S-6ZL-5@gated-at.bofh.it>
In reply to#1648658
On Tue, May 23, 2017 at 10:08:26PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.70 release.
> There are 103 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 Thu May 25 20:08:25 UTC 2017.
> Anything received after that time might be too late.
> 

Note: This set of results is for v4.4.69-102-g3a21698.

Build results:
	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel


csiph-web