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

Groups > linux.kernel > #1496209 > unrolled thread

[PATCH 4.8 00/10] 4.8.1-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 4.8 00/10] 4.8.1-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-06 10:20 +0200
    [PATCH 4.8 07/10] Revert "usbtmc: convert to devm_kzalloc" Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-06 10:20 +0200
    [PATCH 4.8 03/10] usb: misc: legousbtower: Fix NULL pointer deference Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-06 10:20 +0200
    [PATCH 4.8 08/10] ALSA: hda - Adding one more ALC255 pin definition for headset problem Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-06 10:20 +0200
    [PATCH 4.8 05/10] usb: usbip: vudc: fix left shift overflow Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-06 10:20 +0200
    [PATCH 4.8 04/10] Staging: fbtft: Fix bug in fbtft-core Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-06 10:20 +0200
    [PATCH 4.8 09/10] ALSA: hda - Fix headset mic detection problem for several Dell laptops Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-06 10:30 +0200
    Re: [PATCH 4.8 00/10] 4.8.1-stable review Guenter Roeck <linux@roeck-us.net> - 2016-10-06 21:00 +0200
      Re: [PATCH 4.8 00/10] 4.8.1-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-07 06:10 +0200
    Re: [PATCH 4.8 00/10] 4.8.1-stable review Shuah Khan <shuah.kh@samsung.com> - 2016-10-06 22:00 +0200
      Re: [PATCH 4.8 00/10] 4.8.1-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-07 06:10 +0200
    Re: [PATCH 4.8 00/10] 4.8.1-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-08 16:10 +0200
      Re: [PATCH 4.8 00/10] 4.8.1-stable review Kevin Hilman <khilman@baylibre.com> - 2016-10-08 18:20 +0200
        Re: [PATCH 4.8 00/10] 4.8.1-stable review Guenter Roeck <linux@roeck-us.net> - 2016-10-08 19:30 +0200
          Re: [PATCH 4.8 00/10] 4.8.1-stable review Mark Brown <broonie@kernel.org> - 2016-10-10 11:40 +0200
            Re: [PATCH 4.8 00/10] 4.8.1-stable review Guenter Roeck <linux@roeck-us.net> - 2016-10-10 15:00 +0200
              Re: [PATCH 4.8 00/10] 4.8.1-stable review Mark Brown <broonie@kernel.org> - 2016-10-10 21:20 +0200
                Re: [PATCH 4.8 00/10] 4.8.1-stable review Guenter Roeck <linux@roeck-us.net> - 2016-10-10 21:50 +0200
                  Re: [PATCH 4.8 00/10] 4.8.1-stable review Mark Brown <broonie@kernel.org> - 2016-10-11 09:30 +0200
                  Re: [PATCH 4.8 00/10] 4.8.1-stable review Mark Brown <broonie@kernel.org> - 2016-10-11 12:30 +0200
                    Re: [PATCH 4.8 00/10] 4.8.1-stable review Guenter Roeck <linux@roeck-us.net> - 2016-10-11 15:50 +0200

Page 1 of 2  [1] 2  Next page →

#1496209 — [PATCH 4.8 00/10] 4.8.1-stable review

This is the start of the stable review cycle for the 4.8.1 release.
There are 10 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 Sat Oct  8 07:47:33 UTC 2016.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.1-rc1.gz
or in the git tree and branch at:
  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.8.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.8.1-rc1

Takashi Iwai <tiwai@suse.de>
    ALSA: hda - Add the top speaker pin config for HP Spectre x360

Hui Wang <hui.wang@canonical.com>
    ALSA: hda - Fix headset mic detection problem for several Dell laptops

Hui Wang <hui.wang@canonical.com>
    ALSA: hda - Adding one more ALC255 pin definition for headset problem

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Revert "usbtmc: convert to devm_kzalloc"

Kyle Jones <kyle@kf5jwc.us>
    USB: serial: cp210x: Add ID for a Juniper console

Nicolas Iooss <nicolas.iooss_linux@m4x.org>
    usb: usbip: vudc: fix left shift overflow

Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
    Staging: fbtft: Fix bug in fbtft-core

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    usb: misc: legousbtower: Fix NULL pointer deference

Linus Torvalds <torvalds@linux-foundation.org>
    Using BUG_ON() as an assert() is _never_ acceptable

Will Deacon <will.deacon@arm.com>
    arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP


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

Diffstat:

 Makefile                           |  4 ++--
 arch/arm64/kernel/debug-monitors.c |  6 ++++--
 drivers/staging/fbtft/fbtft-core.c |  4 ++--
 drivers/usb/class/usbtmc.c         |  3 ++-
 drivers/usb/misc/legousbtower.c    | 35 +++++++++++++++++------------------
 drivers/usb/serial/cp210x.c        |  1 +
 drivers/usb/usbip/vudc_rx.c        |  2 +-
 include/linux/swap.h               |  4 ++--
 sound/pci/hda/patch_conexant.c     | 10 ++++++++++
 sound/pci/hda/patch_realtek.c      | 17 +++++++++++++++++
 10 files changed, 58 insertions(+), 28 deletions(-)

[toc] | [next] | [standalone]

#1496211 — [PATCH 4.8 07/10] Revert "usbtmc: convert to devm_kzalloc"

4.8-stable review patch.  If anyone has any objections, please let me know.

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

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab21b63e8aedfc73565dd9cdd51eb338341177cb upstream.

This reverts commit e6c7efdcb76f11b04e3d3f71c8d764ab75c9423b.

Turns out it was totally wrong.  The memory is supposed to be bound to
the kref, as the original code was doing correctly, not the
device/driver binding as the devm_kzalloc() would cause.

This fixes an oops when read would be called after the device was
unbound from the driver.

Reported-by: Ladislav Michl <ladis@linux-mips.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/class/usbtmc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -141,6 +141,7 @@ static void usbtmc_delete(struct kref *k
 	struct usbtmc_device_data *data = to_usbtmc_data(kref);
 
 	usb_put_dev(data->usb_dev);
+	kfree(data);
 }
 
 static int usbtmc_open(struct inode *inode, struct file *filp)
@@ -1379,7 +1380,7 @@ static int usbtmc_probe(struct usb_inter
 
 	dev_dbg(&intf->dev, "%s called\n", __func__);
 
-	data = devm_kzalloc(&intf->dev, sizeof(*data), GFP_KERNEL);
+	data = kmalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;
 

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

#1496212 — [PATCH 4.8 03/10] usb: misc: legousbtower: Fix NULL pointer deference

4.8-stable review patch.  If anyone has any objections, please let me know.

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

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fae9e5a7babada041e2e161699ade2447a01989 upstream.

This patch fixes a NULL pointer dereference caused by a race codition in
the probe function of the legousbtower driver. It re-structures the
probe function to only register the interface after successfully reading
the board's firmware ID.

The probe function does not deregister the usb interface after an error
receiving the devices firmware ID. The device file registered
(/dev/usb/legousbtower%d) may be read/written globally before the probe
function returns. When tower_delete is called in the probe function
(after an r/w has been initiated), core dev structures are deleted while
the file operation functions are still running. If the 0 address is
mappable on the machine, this vulnerability can be used to create a
Local Priviege Escalation exploit via a write-what-where condition by
remapping dev->interrupt_out_buffer in tower_write. A forged USB device
and local program execution would be required for LPE. The USB device
would have to delay the control message in tower_probe and accept
the control urb in tower_open whilst guest code initiated a write to the
device file as tower_delete is called from the error in tower_probe.

This bug has existed since 2003. Patch tested by emulated device.

Reported-by: James Patrick-Evans <james@jmp-e.com>
Tested-by: James Patrick-Evans <james@jmp-e.com>
Signed-off-by: James Patrick-Evans <james@jmp-e.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/misc/legousbtower.c |   35 +++++++++++++++++------------------
 1 file changed, 17 insertions(+), 18 deletions(-)

--- a/drivers/usb/misc/legousbtower.c
+++ b/drivers/usb/misc/legousbtower.c
@@ -898,24 +898,6 @@ static int tower_probe (struct usb_inter
 	dev->interrupt_in_interval = interrupt_in_interval ? interrupt_in_interval : dev->interrupt_in_endpoint->bInterval;
 	dev->interrupt_out_interval = interrupt_out_interval ? interrupt_out_interval : dev->interrupt_out_endpoint->bInterval;
 
-	/* we can register the device now, as it is ready */
-	usb_set_intfdata (interface, dev);
-
-	retval = usb_register_dev (interface, &tower_class);
-
-	if (retval) {
-		/* something prevented us from registering this driver */
-		dev_err(idev, "Not able to get a minor for this device.\n");
-		usb_set_intfdata (interface, NULL);
-		goto error;
-	}
-	dev->minor = interface->minor;
-
-	/* let the user know what node this device is now attached to */
-	dev_info(&interface->dev, "LEGO USB Tower #%d now attached to major "
-		 "%d minor %d\n", (dev->minor - LEGO_USB_TOWER_MINOR_BASE),
-		 USB_MAJOR, dev->minor);
-
 	/* get the firmware version and log it */
 	result = usb_control_msg (udev,
 				  usb_rcvctrlpipe(udev, 0),
@@ -936,6 +918,23 @@ static int tower_probe (struct usb_inter
 		 get_version_reply.minor,
 		 le16_to_cpu(get_version_reply.build_no));
 
+	/* we can register the device now, as it is ready */
+	usb_set_intfdata (interface, dev);
+
+	retval = usb_register_dev (interface, &tower_class);
+
+	if (retval) {
+		/* something prevented us from registering this driver */
+		dev_err(idev, "Not able to get a minor for this device.\n");
+		usb_set_intfdata (interface, NULL);
+		goto error;
+	}
+	dev->minor = interface->minor;
+
+	/* let the user know what node this device is now attached to */
+	dev_info(&interface->dev, "LEGO USB Tower #%d now attached to major "
+		 "%d minor %d\n", (dev->minor - LEGO_USB_TOWER_MINOR_BASE),
+		 USB_MAJOR, dev->minor);
 
 exit:
 	return retval;

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

#1496213 — [PATCH 4.8 08/10] ALSA: hda - Adding one more ALC255 pin definition for headset problem

4.8-stable review patch.  If anyone has any objections, please let me know.

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

From: Hui Wang <hui.wang@canonical.com>

commit 392c9da24a994f238c5d7ea611c6245be4617014 upstream.

We have two new Dell laptop models, they have the same ALC255 pin
definition, but not in the pin quirk table yet, as a result, the
headset microphone can't work. After adding the definition in the
table, the headset microphone works well.

Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/pci/hda/patch_realtek.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5846,6 +5846,10 @@ static const struct snd_hda_pin_quirk al
 		{0x14, 0x90170120},
 		{0x21, 0x02211030}),
 	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+		{0x14, 0x90170110},
+		{0x1b, 0x02011020},
+		{0x21, 0x0221101f}),
+	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
 		{0x14, 0x90170130},
 		{0x1b, 0x01014020},
 		{0x21, 0x0221103f}),

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

#1496214 — [PATCH 4.8 05/10] usb: usbip: vudc: fix left shift overflow

4.8-stable review patch.  If anyone has any objections, please let me know.

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

From: Nicolas Iooss <nicolas.iooss_linux@m4x.org>

commit 238b7bd91b16d5a08326f858db42229b212e53d8 upstream.

In v_recv_cmd_submit(), urb_p->urb->pipe has the type unsigned int
(which is 32-bit long on x86_64) but 11<<30 results in a 34-bit integer.
Therefore the 2 leading bits are truncated and

    urb_p->urb->pipe &= ~(11 << 30);

has the same meaning as

    urb_p->urb->pipe &= ~(3 << 30);

This second statement seems to be how the code was intended to be
written, as PIPE_ constants have values between 0 and 3.

The overflow has been detected with a clang warning:

    drivers/usb/usbip/vudc_rx.c:145:27: warning: signed shift result
    (0x2C0000000) requires 35 bits to represent, but 'int' only has 32
    bits [-Wshift-overflow]
            urb_p->urb->pipe &= ~(11 << 30);
                                  ~~ ^  ~~

Fixes: 79c02cb1fd5c ("usbip: vudc: Add vudc_rx")
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/usbip/vudc_rx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/usbip/vudc_rx.c
+++ b/drivers/usb/usbip/vudc_rx.c
@@ -142,7 +142,7 @@ static int v_recv_cmd_submit(struct vudc
 	urb_p->urb->status = -EINPROGRESS;
 
 	/* FIXME: more pipe setup to please usbip_common */
-	urb_p->urb->pipe &= ~(11 << 30);
+	urb_p->urb->pipe &= ~(3 << 30);
 	switch (urb_p->ep->type) {
 	case USB_ENDPOINT_XFER_BULK:
 		urb_p->urb->pipe |= (PIPE_BULK << 30);

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

#1496215 — [PATCH 4.8 04/10] Staging: fbtft: Fix bug in fbtft-core

4.8-stable review patch.  If anyone has any objections, please let me know.

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

From: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>

commit fc1e2c8ea85e109acf09e74789e9b852f6eed251 upstream.

Commit 367e8560e8d7a62d96e9b1d644028a3816e04206 introduced a bug
in fbtft-core where fps is always 0, this is because variable
update_time is not assigned correctly.

Signed-off-by: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
Fixes: 367e8560e8d7 ("Staging: fbtbt: Replace timespec with ktime_t")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/fbtft/fbtft-core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -391,11 +391,11 @@ static void fbtft_update_display(struct
 
 	if (unlikely(timeit)) {
 		ts_end = ktime_get();
-		if (ktime_to_ns(par->update_time))
+		if (!ktime_to_ns(par->update_time))
 			par->update_time = ts_start;
 
-		par->update_time = ts_start;
 		fps = ktime_us_delta(ts_start, par->update_time);
+		par->update_time = ts_start;
 		fps = fps ? 1000000 / fps : 0;
 
 		throughput = ktime_us_delta(ts_end, ts_start);

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

#1496218 — [PATCH 4.8 09/10] ALSA: hda - Fix headset mic detection problem for several Dell laptops

4.8-stable review patch.  If anyone has any objections, please let me know.

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

From: Hui Wang <hui.wang@canonical.com>

commit 3f640970a41429f0a076c01270bbd014c9eae61c upstream.

One of the laptops has the codec ALC256 on it, applying the
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem, the rest
of laptops have the codec ALC295 on them, they are similar to machines
with ALC225, applying the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE can fix
the problem.

Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/pci/hda/patch_realtek.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5806,6 +5806,13 @@ static const struct hda_model_fixup alc2
 	{0x14, 0x90170110}, \
 	{0x15, 0x0221401f}
 
+#define ALC295_STANDARD_PINS \
+	{0x12, 0xb7a60130}, \
+	{0x14, 0x90170110}, \
+	{0x17, 0x21014020}, \
+	{0x18, 0x21a19030}, \
+	{0x21, 0x04211020}
+
 #define ALC298_STANDARD_PINS \
 	{0x12, 0x90a60130}, \
 	{0x21, 0x03211020}
@@ -5915,6 +5922,10 @@ static const struct snd_hda_pin_quirk al
 		{0x14, 0x90170120},
 		{0x21, 0x02211030}),
 	SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+		{0x12, 0xb7a60130},
+		{0x14, 0x90170110},
+		{0x21, 0x02211020}),
+	SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
 		ALC256_STANDARD_PINS),
 	SND_HDA_PIN_QUIRK(0x10ec0280, 0x103c, "HP", ALC280_FIXUP_HP_GPIO4,
 		{0x12, 0x90a60130},
@@ -6025,6 +6036,8 @@ static const struct snd_hda_pin_quirk al
 	SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
 		ALC292_STANDARD_PINS,
 		{0x13, 0x90a60140}),
+	SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
+		ALC295_STANDARD_PINS),
 	SND_HDA_PIN_QUIRK(0x10ec0298, 0x1028, "Dell", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
 		ALC298_STANDARD_PINS,
 		{0x17, 0x90170110}),

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

#1496813

On Thu, Oct 06, 2016 at 10:18:23AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.8.1 release.
> There are 10 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 Sat Oct  8 07:47:33 UTC 2016.
> Anything received after that time might be too late.
> 

Build results:
	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 108 pass: 108 fail: 0

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

Guenter

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

#1496983

On Thu, Oct 06, 2016 at 11:51:01AM -0700, Guenter Roeck wrote:
> On Thu, Oct 06, 2016 at 10:18:23AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.8.1 release.
> > There are 10 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 Sat Oct  8 07:47:33 UTC 2016.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 149 pass: 149 fail: 0
> Qemu test results:
> 	total: 108 pass: 108 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Great, thanks for testing all of these and letting me know.

greg k-h

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

#1496834

On 10/06/2016 02:18 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.8.1 release.
> There are 10 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 Sat Oct  8 07:47:33 UTC 2016.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.1-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.8.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com

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

#1496981

On Thu, Oct 06, 2016 at 01:56:28PM -0600, Shuah Khan wrote:
> On 10/06/2016 02:18 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.8.1 release.
> > There are 10 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 Sat Oct  8 07:47:33 UTC 2016.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.1-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.8.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

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

#1497750

On Fri, Oct 07, 2016 at 03:26:04PM -0700, kernelci.org bot wrote:
> stable-rc boot: 479 boots: 4 failed, 183 passed with 292 offline (v4.8-11-ge141008f62ab)
> 
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.8-11-ge141008f62ab/
> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.8-11-ge141008f62ab/
> 
> Tree: stable-rc
> Branch: local/linux-4.8.y
> Git Describe: v4.8-11-ge141008f62ab
> Git Commit: e141008f62abab72c15b093d97a88f37c8cd7096
> Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 86 unique boards, 23 SoC families, 33 builds out of 206
> 
> Boot Failures Detected: https://kernelci.org/boot/?v4.8-11-ge141008f62ab&fail
> 
> arm:
> 
>     mxs_defconfig:
>         imx23-olinuxino: 1 failed lab
> 
>     multi_v7_defconfig+CONFIG_SMP=n:
>         imx6q-sabrelite: 1 failed lab
> 
>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>         vexpress-v2p-ca15-tc1: 1 failed lab
>         vexpress-v2p-ca15_a7: 1 failed lab

How does this compare to 4.8.0?

thanks,

greg k-h

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

#1497771

Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> On Fri, Oct 07, 2016 at 03:26:04PM -0700, kernelci.org bot wrote:
>> stable-rc boot: 479 boots: 4 failed, 183 passed with 292 offline (v4.8-11-ge141008f62ab)
>> 
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.8-11-ge141008f62ab/
>> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.8-11-ge141008f62ab/
>> 
>> Tree: stable-rc
>> Branch: local/linux-4.8.y
>> Git Describe: v4.8-11-ge141008f62ab
>> Git Commit: e141008f62abab72c15b093d97a88f37c8cd7096
>> Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 86 unique boards, 23 SoC families, 33 builds out of 206
>> 
>> Boot Failures Detected: https://kernelci.org/boot/?v4.8-11-ge141008f62ab&fail
>> 
>> arm:
>> 
>>     mxs_defconfig:
>>         imx23-olinuxino: 1 failed lab

This one looks like lab-specific intermittent failures, not related to
the this kernel.

>>     multi_v7_defconfig+CONFIG_SMP=n:
>>         imx6q-sabrelite: 1 failed lab

The CONFIG_SMP=n boots for this board have been failing for awhile, so
this isn't related to stable-rc

>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>>         vexpress-v2p-ca15-tc1: 1 failed lab
>>         vexpress-v2p-ca15_a7: 1 failed lab

These builds are known broken an QEMU need to be blacklisted until we
find out what's going on.

Kevin

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

#1497795

On 10/08/2016 09:11 AM, Kevin Hilman wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>
>> On Fri, Oct 07, 2016 at 03:26:04PM -0700, kernelci.org bot wrote:
>>> stable-rc boot: 479 boots: 4 failed, 183 passed with 292 offline (v4.8-11-ge141008f62ab)
>>>
>>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.8-11-ge141008f62ab/
>>> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.8-11-ge141008f62ab/
>>>
>>> Tree: stable-rc
>>> Branch: local/linux-4.8.y
>>> Git Describe: v4.8-11-ge141008f62ab
>>> Git Commit: e141008f62abab72c15b093d97a88f37c8cd7096
>>> Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>>> Tested: 86 unique boards, 23 SoC families, 33 builds out of 206
>>>
>>> Boot Failures Detected: https://kernelci.org/boot/?v4.8-11-ge141008f62ab&fail
>>>
>>> arm:
>>>
>>>     mxs_defconfig:
>>>         imx23-olinuxino: 1 failed lab
>
> This one looks like lab-specific intermittent failures, not related to
> the this kernel.
>
>>>     multi_v7_defconfig+CONFIG_SMP=n:
>>>         imx6q-sabrelite: 1 failed lab
>
> The CONFIG_SMP=n boots for this board have been failing for awhile, so
> this isn't related to stable-rc
>
>>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>>>         vexpress-v2p-ca15-tc1: 1 failed lab
>>>         vexpress-v2p-ca15_a7: 1 failed lab
>
> These builds are known broken an QEMU need to be blacklisted until we
> find out what's going on.
>
Is this with qemu or on a real board ?

If with qemu, what is your qemu version ?

Thanks,
Guenter

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

#1498198

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

On Sat, Oct 08, 2016 at 10:22:41AM -0700, Guenter Roeck wrote:
> On 10/08/2016 09:11 AM, Kevin Hilman wrote:

> > > >         vexpress-v2p-ca15-tc1: 1 failed lab
> > > >         vexpress-v2p-ca15_a7: 1 failed lab

> > These builds are known broken an QEMU need to be blacklisted until we
> > find out what's going on.

> Is this with qemu or on a real board ?

> If with qemu, what is your qemu version ?

qemu 2.5

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

#1498284

On 10/10/2016 02:38 AM, Mark Brown wrote:
> On Sat, Oct 08, 2016 at 10:22:41AM -0700, Guenter Roeck wrote:
>> On 10/08/2016 09:11 AM, Kevin Hilman wrote:
>
>>>>>         vexpress-v2p-ca15-tc1: 1 failed lab
>>>>>         vexpress-v2p-ca15_a7: 1 failed lab
>
>>> These builds are known broken an QEMU need to be blacklisted until we
>>> find out what's going on.
>
>> Is this with qemu or on a real board ?
>
>> If with qemu, what is your qemu version ?
>
> qemu 2.5
>

Can I find the qemu command line somewhere ? The following work fine
for me.

Building arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 ... running ..... passed
Building arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 ... running ..... passed

Thanks,
Guenter

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

#1498489

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

On Mon, Oct 10, 2016 at 05:54:22AM -0700, Guenter Roeck wrote:

> Can I find the qemu command line somewhere ? The following work fine
> for me.

> Building arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 ... running ..... passed
> Building arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 ... running ..... passed

Note that most of the failures my lab saw are with extra configs, the
only vanilla config that failed was vexpress-v2p-ca15_a7 with the
multi_v7_defconfig.

My connection doesn't have IPv6 and is a bit spotty right now so it's a
bit difficult for me to check by lab but today's -next jobs are working
for me as well...  looking at the log for the failed stable boots:

https://storage.kernelci.org/stable/v4.8.1/arm-multi_v7_defconfig/lab-broonie/boot-vexpress-v2p-ca15_a7.html

looks like it's some interaction with the test image causing udevadm
settle to not run quickly enough - there's also a big delay before the
UART comes up.  I'm wondering if it's just that the host machine is just
too slow here.

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

#1498495

On Mon, Oct 10, 2016 at 09:11:23PM +0200, Mark Brown wrote:
> On Mon, Oct 10, 2016 at 05:54:22AM -0700, Guenter Roeck wrote:
> 
> > Can I find the qemu command line somewhere ? The following work fine
> > for me.
> 
> > Building arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 ... running ..... passed
> > Building arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 ... running ..... passed
> 
> Note that most of the failures my lab saw are with extra configs, the
> only vanilla config that failed was vexpress-v2p-ca15_a7 with the
> multi_v7_defconfig.
> 
> My connection doesn't have IPv6 and is a bit spotty right now so it's a
> bit difficult for me to check by lab but today's -next jobs are working
> for me as well...  looking at the log for the failed stable boots:
> 
> https://storage.kernelci.org/stable/v4.8.1/arm-multi_v7_defconfig/lab-broonie/boot-vexpress-v2p-ca15_a7.html
> 
> looks like it's some interaction with the test image causing udevadm
> settle to not run quickly enough - there's also a big delay before the
> UART comes up.  I'm wondering if it's just that the host machine is just
> too slow here.

Can you send me (or point me to) the qemu command lines you are using ?
Even better would the complete setup describing how you connect to kernelci.

Thanks,
Guenter

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

#1498633

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

On Mon, Oct 10, 2016 at 12:47:43PM -0700, Guenter Roeck wrote:
> On Mon, Oct 10, 2016 at 09:11:23PM +0200, Mark Brown wrote:

> > My connection doesn't have IPv6 and is a bit spotty right now so it's a
> > bit difficult for me to check by lab but today's -next jobs are working
> > for me as well...  looking at the log for the failed stable boots:

> Can you send me (or point me to) the qemu command lines you are using ?

See above.

> Even better would the complete setup describing how you connect to kernelci.

It's an off the shelf install of LAVA.

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

#1498740

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

On Mon, Oct 10, 2016 at 12:47:43PM -0700, Guenter Roeck wrote:
> On Mon, Oct 10, 2016 at 09:11:23PM +0200, Mark Brown wrote:

> > My connection doesn't have IPv6 and is a bit spotty right now so it's a
> > bit difficult for me to check by lab but today's -next jobs are working
> > for me as well...  looking at the log for the failed stable boots:

> Can you send me (or point me to) the qemu command lines you are using ?

Managed to get things running long enough to pull the log:

qemu-system-arm -M vexpress-a15 -no-reboot -show-cursor -no-reboot -nographic -m 256 -net user -kernel /var/lib/lava/dispatcher/tmp/tmpZBxic8/.zImage -append "root=/dev/ram0 rw console=ttyAMA0 115200 ip=dhcp mem=256M" -initrd /var/lib/lava/dispatcher/tmp/tmpxoFsPn/ramdisk.cpio.gz -dtb /var/lib/lava/dispatcher/tmp/tmpMN1a1R/vexpress-v2p-ca15_a7.dtb

> Even better would the complete setup describing how you connect to kernelci.

Like I say it's just a standard LAVA install.

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web