Re: [PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

On 2016年07月26日 21:39, Guenter Roeck wrote: static int rockchip_saradc_probe(struct platform_device *pdev) { struct rockchip_saradc *info = NULL; @@ -218,6 +231,21 @@ static int rockchip_saradc_probe(struct platform_device *pdev) if (IS_ERR(info->regs)) return PTR_ERR(info->regs); + /* + *

Re: [PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

On 2016年07月26日 21:39, Guenter Roeck wrote: static int rockchip_saradc_probe(struct platform_device *pdev) { struct rockchip_saradc *info = NULL; @@ -218,6 +231,21 @@ static int rockchip_saradc_probe(struct platform_device *pdev) if (IS_ERR(info->regs)) return PTR_ERR(info->regs); + /* + *

Re: [PATCH] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hi, [auto build test ERROR on tip/sched/core] [also build test ERROR on v4.7 next-20160726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Giovanni-Gherdovich/sched-cputime-Mitigate-performance

Re: [PATCH] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hi, [auto build test ERROR on tip/sched/core] [also build test ERROR on v4.7 next-20160726] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Giovanni-Gherdovich/sched-cputime-Mitigate-performance

Re: [patch 61/66] timers: Convert to hotplug state machine

Jon, On Tue, Jul 26, 2016 at 10:20:58AM +0100, Jon Hunter wrote: > Thanks. I have not tried another ARM based device, but I would be > curious if another ARM device sees this or not. I do see this stall on socfpga and on zynq, but in both cases the suspend mechanism is flakey in other ways, too.

Re: master build: 2 failures 3 warnings (v4.7-1605-ge658052)

On Tue, Jul 26, 2016 at 02:38:00PM +0200, Arnd Bergmann wrote: > The build report doesn't actually show the error unfortunately, but > I'm pretty sure it's this one: > drivers/staging/built-in.o: In function `nbu2ss_drv_probe': > (.text+0x2428): undefined reference to

Re: [patch 61/66] timers: Convert to hotplug state machine

Jon, On Tue, Jul 26, 2016 at 10:20:58AM +0100, Jon Hunter wrote: > Thanks. I have not tried another ARM based device, but I would be > curious if another ARM device sees this or not. I do see this stall on socfpga and on zynq, but in both cases the suspend mechanism is flakey in other ways, too.

Re: master build: 2 failures 3 warnings (v4.7-1605-ge658052)

On Tue, Jul 26, 2016 at 02:38:00PM +0200, Arnd Bergmann wrote: > The build report doesn't actually show the error unfortunately, but > I'm pretty sure it's this one: > drivers/staging/built-in.o: In function `nbu2ss_drv_probe': > (.text+0x2428): undefined reference to

RE: [PATCH] ACPICA: cleanup method properly on error

We'll look at this. Thanks. > -Original Message- > From: Vegard Nossum [mailto:vegard.nos...@oracle.com] > Sent: Friday, July 22, 2016 8:35 AM > To: Moore, Robert ; Zheng, Lv > ; Wysocki, Rafael J > Cc:

RE: [PATCH] ACPICA: cleanup method properly on error

We'll look at this. Thanks. > -Original Message- > From: Vegard Nossum [mailto:vegard.nos...@oracle.com] > Sent: Friday, July 22, 2016 8:35 AM > To: Moore, Robert ; Zheng, Lv > ; Wysocki, Rafael J > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org;

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote: > Hi, > > The following commit: > > commit 13523309495cdbd57a0d344c0d5d574987af007f > Author: Josh Poimboeuf > Date: Thu Jan 21 16:49:21 2016 -0600 > > x86/asm/acpi: Create a stack frame in

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote: > Hi, > > The following commit: > > commit 13523309495cdbd57a0d344c0d5d574987af007f > Author: Josh Poimboeuf > Date: Thu Jan 21 16:49:21 2016 -0600 > > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel() > >

Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed

Hi Eric, Sorry for the delay! On Mon, Jul 25, 2016 at 01:57:00PM -0500, Eric W. Biederman wrote: kernel test robot writes: FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing commit

Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed

Hi Eric, Sorry for the delay! On Mon, Jul 25, 2016 at 01:57:00PM -0500, Eric W. Biederman wrote: kernel test robot writes: FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing commit

Re: [PATCH] mmc: sdhci-esdhc-imx: avoid unused function warnings

On Tuesday, July 26, 2016 9:41:50 PM CEST Dong Aisheng wrote: > > On Tue, Jul 26, 2016 at 8:32 PM, Arnd Bergmann wrote: > > The driver has just gained a slightly incorrect pm-sleep implementation > > that causes > > warnings when CONFIG_PM is set but CONFIG_PM_SLEEP is not: > > >

Re: [PATCH] mmc: sdhci-esdhc-imx: avoid unused function warnings

On Tuesday, July 26, 2016 9:41:50 PM CEST Dong Aisheng wrote: > > On Tue, Jul 26, 2016 at 8:32 PM, Arnd Bergmann wrote: > > The driver has just gained a slightly incorrect pm-sleep implementation > > that causes > > warnings when CONFIG_PM is set but CONFIG_PM_SLEEP is not: > > > >

Re: [STLinux Kernel] [PATCH 1/1] drm/sti: use new Reset API

On Mon, Jul 25, 2016 at 6:40 AM, Lee Jones wrote: > On Mon, 25 Jul 2016, Peter Griffin wrote: >> On Mon, 25 Jul 2016, Lee Jones wrote: >> >> > Since 0b52297f228 ("reset: Add support for shared reset controls") the >> > new Reset API now demands consumers choose either an

Re: [STLinux Kernel] [PATCH 1/1] drm/sti: use new Reset API

On Mon, Jul 25, 2016 at 6:40 AM, Lee Jones wrote: > On Mon, 25 Jul 2016, Peter Griffin wrote: >> On Mon, 25 Jul 2016, Lee Jones wrote: >> >> > Since 0b52297f228 ("reset: Add support for shared reset controls") the >> > new Reset API now demands consumers choose either an *_exclusive or a >> >

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On 26.07.16 17:06, Thomas Gleixner wrote: > On Tue, 26 Jul 2016, Foster Snowhill wrote: >> On 26.07.16 16:49, Thomas Gleixner wrote: >>> On Mon, 25 Jul 2016, Foster Snowhill wrote: On 25.07.16 13:56, Thomas Gleixner wrote: > Could you please give the patch below a try? It might be

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On 26.07.16 17:06, Thomas Gleixner wrote: > On Tue, 26 Jul 2016, Foster Snowhill wrote: >> On 26.07.16 16:49, Thomas Gleixner wrote: >>> On Mon, 25 Jul 2016, Foster Snowhill wrote: On 25.07.16 13:56, Thomas Gleixner wrote: > Could you please give the patch below a try? It might be

[PATCH RESEND] genirq: Machine-parsable version of /proc/interrupts

From: Craig Gallek Add struct kobject to struct irq_desc to allow for easy export to sysfs. This allows for much simpler userspace-parsing of the information contained in struct irq_desc. Note that sysfs is not available at the time of early irq initialization. These

[PATCH RESEND] genirq: Machine-parsable version of /proc/interrupts

From: Craig Gallek Add struct kobject to struct irq_desc to allow for easy export to sysfs. This allows for much simpler userspace-parsing of the information contained in struct irq_desc. Note that sysfs is not available at the time of early irq initialization. These interrupts are accounted

Re: master build: 2 failures 3 warnings (v4.7-1605-ge658052)

On Tue, Jul 26, 2016 at 02:38:00PM +0200, Arnd Bergmann wrote: > On Tuesday, July 26, 2016 1:29:55 PM CEST Build bot for Mark Brown wrote: > > Tree/Branch: master > > Git describe: v4.7-1605-ge658052 > > Commit: e65805251f Merge branch 'irq-core-for-linus' of > >

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On Tue, Jul 26, 2016 at 06:53:48AM -0700, Guenter Roeck wrote: > On 07/25/2016 01:53 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.6.5 release. > > There are 203 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: master build: 2 failures 3 warnings (v4.7-1605-ge658052)

On Tue, Jul 26, 2016 at 02:38:00PM +0200, Arnd Bergmann wrote: > On Tuesday, July 26, 2016 1:29:55 PM CEST Build bot for Mark Brown wrote: > > Tree/Branch: master > > Git describe: v4.7-1605-ge658052 > > Commit: e65805251f Merge branch 'irq-core-for-linus' of > >

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On Tue, Jul 26, 2016 at 06:53:48AM -0700, Guenter Roeck wrote: > On 07/25/2016 01:53 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.6.5 release. > > There are 203 patches in this series, all will be posted as a response > > to this one. If anyone has any

[lkp] [vfs] db8c57ac59: WARNING: CPU: 0 PID: 1 at lib/list_debug.c:62 __list_del_entry+0xc1/0xd0

64-randconfig-s2-07251540/gcc-4.4/db8c57ac59a4fe06b79073306bcb1ce131c2c07a/vmlinuz-4.7.0-rc7-4-gdb8c57a -append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-kbuild-yocto-x86_64-23/boot-1-yocto-minimal-x86_64.cgz-db8c57ac59a4fe06b79073306bcb1ce131c2c07a-20160726-23625-esavg0-0.yaml ARCH=x

[lkp] [vfs] db8c57ac59: WARNING: CPU: 0 PID: 1 at lib/list_debug.c:62 __list_del_entry+0xc1/0xd0

64-randconfig-s2-07251540/gcc-4.4/db8c57ac59a4fe06b79073306bcb1ce131c2c07a/vmlinuz-4.7.0-rc7-4-gdb8c57a -append 'root=/dev/ram0 user=lkp job=/lkp/scheduled/vm-kbuild-yocto-x86_64-23/boot-1-yocto-minimal-x86_64.cgz-db8c57ac59a4fe06b79073306bcb1ce131c2c07a-20160726-23625-esavg0-0.yaml ARCH=x

Re: [PATCH v2 1/4] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

Op 21-07-16 om 21:23 schreef Lyude: > From: Matt Roper > > When we write watermark values to the hardware, those values are stored > in dev_priv->wm.skl_hw. However with recent watermark changes, the > results structure we're copying from only contains valid watermark

Re: [PATCH v2 1/4] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

Op 21-07-16 om 21:23 schreef Lyude: > From: Matt Roper > > When we write watermark values to the hardware, those values are stored > in dev_priv->wm.skl_hw. However with recent watermark changes, the > results structure we're copying from only contains valid watermark and > DDB values for the

Re: [patch 61/66] timers: Convert to hotplug state machine

Jon, On Tue, 26 Jul 2016, Jon Hunter wrote: > On 25/07/16 16:35, rcoch...@linutronix.de wrote: > > Just to be sure, this problem didn't exist before the HP rework, that > > is, suspend worked fine with and without CONFIG_PREEMPT, right? > > Correct. I test suspend on Tegra with both

Re: [patch 61/66] timers: Convert to hotplug state machine

Jon, On Tue, 26 Jul 2016, Jon Hunter wrote: > On 25/07/16 16:35, rcoch...@linutronix.de wrote: > > Just to be sure, this problem didn't exist before the HP rework, that > > is, suspend worked fine with and without CONFIG_PREEMPT, right? > > Correct. I test suspend on Tegra with both

Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT

Will Deacon wrote: The kernel really needs to support both of those platforms :/ For the memory-mapped counter registers, the architecture says: `If the implementation supports 64-bit atomic accesses, then the CNTV_CVAL register must be accessible as an atomic 64-bit value.' which is

Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT

Will Deacon wrote: The kernel really needs to support both of those platforms :/ For the memory-mapped counter registers, the architecture says: `If the implementation supports 64-bit atomic accesses, then the CNTV_CVAL register must be accessible as an atomic 64-bit value.' which is

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On Tue, 26 Jul 2016, Foster Snowhill wrote: > On 26.07.16 16:49, Thomas Gleixner wrote: > > On Mon, 25 Jul 2016, Foster Snowhill wrote: > >> On 25.07.16 13:56, Thomas Gleixner wrote: > >>> Could you please give the patch below a try? It might be related, but I'm > >>> not > >>> sure whether it

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On Tue, 26 Jul 2016, Foster Snowhill wrote: > On 26.07.16 16:49, Thomas Gleixner wrote: > > On Mon, 25 Jul 2016, Foster Snowhill wrote: > >> On 25.07.16 13:56, Thomas Gleixner wrote: > >>> Could you please give the patch below a try? It might be related, but I'm > >>> not > >>> sure whether it

Re: [PATCH] genirq/msi: Make sure PCI MSIs are activated early

On Tue, 26 Jul 2016, Thomas Gleixner wrote: > On Tue, 26 Jul 2016, Thomas Gleixner wrote: > > On Mon, 25 Jul 2016, Bjorn Helgaas wrote: > > > On Mon, Jul 25, 2016 at 09:45:13AM +0200, Thomas Gleixner wrote: > > > I thought the original issue [1] was that PCI_MSI_FLAGS_ENABLE was being > > >

Re: [PATCH] genirq/msi: Make sure PCI MSIs are activated early

On Tue, 26 Jul 2016, Thomas Gleixner wrote: > On Tue, 26 Jul 2016, Thomas Gleixner wrote: > > On Mon, 25 Jul 2016, Bjorn Helgaas wrote: > > > On Mon, Jul 25, 2016 at 09:45:13AM +0200, Thomas Gleixner wrote: > > > I thought the original issue [1] was that PCI_MSI_FLAGS_ENABLE was being > > >

[PATCH] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Commit 6e998916dfe3 ("sched/cputime: Fix clock_nanosleep()/clock_gettime() inconsistency") fixed a problem whereby clock_nanosleep() followed by clock_gettime() could allow a task to wake early. It addressed the problem by calling the scheduling classes update_curr when the cputimer starts. Said

[PATCH] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Commit 6e998916dfe3 ("sched/cputime: Fix clock_nanosleep()/clock_gettime() inconsistency") fixed a problem whereby clock_nanosleep() followed by clock_gettime() could allow a task to wake early. It addressed the problem by calling the scheduling classes update_curr when the cputimer starts. Said

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote: > Hi, > > The following commit: > > commit 13523309495cdbd57a0d344c0d5d574987af007f > Author: Josh Poimboeuf > Date: Thu Jan 21 16:49:21 2016 -0600 > > x86/asm/acpi: Create a stack frame in

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

On Tue, Jul 26, 2016 at 01:32:28PM +0200, Rafael J. Wysocki wrote: > Hi, > > The following commit: > > commit 13523309495cdbd57a0d344c0d5d574987af007f > Author: Josh Poimboeuf > Date: Thu Jan 21 16:49:21 2016 -0600 > > x86/asm/acpi: Create a stack frame in do_suspend_lowlevel() > >

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On 26.07.16 16:49, Thomas Gleixner wrote: > On Mon, 25 Jul 2016, Foster Snowhill wrote: >> On 25.07.16 13:56, Thomas Gleixner wrote: >>> Could you please give the patch below a try? It might be related, but I'm >>> not >>> sure whether it will cure that particular vmware oddity. >> >> Patch fixed

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On 26.07.16 16:49, Thomas Gleixner wrote: > On Mon, 25 Jul 2016, Foster Snowhill wrote: >> On 25.07.16 13:56, Thomas Gleixner wrote: >>> Could you please give the patch below a try? It might be related, but I'm >>> not >>> sure whether it will cure that particular vmware oddity. >> >> Patch fixed

Re: linux-next: manual merge of the xen-tip tree with the tip tree

On 07/26/2016 12:01 AM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the xen-tip tree got a conflict in: > > arch/x86/xen/enlighten.c > > between commit: > > 4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()") > > from the tip tree and commit: > >

Re: linux-next: manual merge of the xen-tip tree with the tip tree

On 07/26/2016 12:01 AM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the xen-tip tree got a conflict in: > > arch/x86/xen/enlighten.c > > between commit: > > 4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()") > > from the tip tree and commit: > >

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

On Tuesday, July 26, 2016 4:57:03 AM CEST Alan Curry wrote: > Al Viro wrote: > > On Sun, Jul 24, 2016 at 07:45:13PM +0200, Christian Lamparter wrote: > > > > > > The symptom is that downloaded files (http, ftp, and probably other > > > > protocols) have small corrupted segments (about 1-2

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

On Tuesday, July 26, 2016 4:57:03 AM CEST Alan Curry wrote: > Al Viro wrote: > > On Sun, Jul 24, 2016 at 07:45:13PM +0200, Christian Lamparter wrote: > > > > > > The symptom is that downloaded files (http, ftp, and probably other > > > > protocols) have small corrupted segments (about 1-2

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On 07/25/2016 01:53 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.6.5 release. There are 203 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

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On 07/25/2016 01:53 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.6.5 release. There are 203 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

Re: [PATCH 4.4 000/146] 4.4.16-stable review

On 07/25/2016 01:54 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.16 release. There are 146 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

Re: [PATCH 4.4 000/146] 4.4.16-stable review

On 07/25/2016 01:54 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.16 release. There are 146 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

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On Mon, 25 Jul 2016, Foster Snowhill wrote: > On 25.07.16 13:56, Thomas Gleixner wrote: > > On Sat, 23 Jul 2016, Foster Snowhill wrote: > >> [1.] One line summary of the problem: > >> > >> Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) > > > > That has been reported

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On Mon, 25 Jul 2016, Foster Snowhill wrote: > On 25.07.16 13:56, Thomas Gleixner wrote: > > On Sat, 23 Jul 2016, Foster Snowhill wrote: > >> [1.] One line summary of the problem: > >> > >> Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) > > > > That has been reported

Re: [PATCH 3.14 00/53] 3.14.74-stable review

On 07/25/2016 01:54 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.74 release. There are 53 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

Re: [PATCH 3.14 00/53] 3.14.74-stable review

On 07/25/2016 01:54 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.74 release. There are 53 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

Re: [PATCH] mmc: sdhci-esdhc-imx: avoid unused function warnings

Hi Arnd, On Tue, Jul 26, 2016 at 8:32 PM, Arnd Bergmann wrote: > The driver has just gained a slightly incorrect pm-sleep implementation that > causes > warnings when CONFIG_PM is set but CONFIG_PM_SLEEP is not: > > drivers/mmc/host/sdhci-esdhc-imx.c:1302:12: error:

Re: [PATCH] mmc: sdhci-esdhc-imx: avoid unused function warnings

Hi Arnd, On Tue, Jul 26, 2016 at 8:32 PM, Arnd Bergmann wrote: > The driver has just gained a slightly incorrect pm-sleep implementation that > causes > warnings when CONFIG_PM is set but CONFIG_PM_SLEEP is not: > > drivers/mmc/host/sdhci-esdhc-imx.c:1302:12: error: 'sdhci_esdhc_resume' >

Re: [PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

On 07/26/2016 05:13 AM, Caesar Wang wrote: SARADC controller needs to be reset before programming it, otherwise it will not function properly. Signed-off-by: Caesar Wang Cc: Jonathan Cameron Cc: Heiko Stuebner Cc: Rob Herring

Re: [PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

On 07/26/2016 05:13 AM, Caesar Wang wrote: SARADC controller needs to be reset before programming it, otherwise it will not function properly. Signed-off-by: Caesar Wang Cc: Jonathan Cameron Cc: Heiko Stuebner Cc: Rob Herring Cc: linux-...@vger.kernel.org Cc:

RE: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: Michal Kubecek [mailto:mkube...@suse.cz] > Sent: Tuesday, July 26, 2016 17:57 > ... > On Tue, Jul 26, 2016 at 07:09:41AM +, Dexuan Cui wrote: > > ... I don't think Michal > > Kubecek was suggesting I build my code using the existing AF_VSOCK > > code(?) I think he was only asking me

RE: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: Michal Kubecek [mailto:mkube...@suse.cz] > Sent: Tuesday, July 26, 2016 17:57 > ... > On Tue, Jul 26, 2016 at 07:09:41AM +, Dexuan Cui wrote: > > ... I don't think Michal > > Kubecek was suggesting I build my code using the existing AF_VSOCK > > code(?) I think he was only asking me

[PATCH v2] README: Delete obsolete i386 info + update arch/i386/ paths

Support for i386 was removed in v3.8, delete the paragraph that says processor types above 386 won't work on that architecture. It's obsolete information and potentially confusing. Also change a couple of "arch/i386/" paths to one that exists now, using "arch/x86/" instead. Signed-off-by: Øyvind

[PATCH v2] README: Delete obsolete i386 info + update arch/i386/ paths

Support for i386 was removed in v3.8, delete the paragraph that says processor types above 386 won't work on that architecture. It's obsolete information and potentially confusing. Also change a couple of "arch/i386/" paths to one that exists now, using "arch/x86/" instead. Signed-off-by: Øyvind

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

David Vrabel writes: > On 26/07/16 13:30, Vitaly Kuznetsov wrote: >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In >> particular, when we crash on a secondary vCPU we may want to do kdump >> and unlike plain kexec where we do migrate_to_reboot_cpu()

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

David Vrabel writes: > On 26/07/16 13:30, Vitaly Kuznetsov wrote: >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In >> particular, when we crash on a secondary vCPU we may want to do kdump >> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting >> on the

Re: [PATCH V7 1/8] ACPI: I/O Remapping Table (IORT) initial support

Hi Marc, On 06/22/2016 09:34 PM, Hanjun Guo wrote: > On 2016/6/22 22:51, Marc Zyngier wrote: >> On 22/06/16 14:52, Tomasz Nowicki wrote: >>> On 22.06.2016 15:25, Marc Zyngier wrote: On 22/06/16 13:35, Tomasz Nowicki wrote: > IORT shows representation of IO topology for ARM based systems.

Re: [PATCH V7 1/8] ACPI: I/O Remapping Table (IORT) initial support

Hi Marc, On 06/22/2016 09:34 PM, Hanjun Guo wrote: > On 2016/6/22 22:51, Marc Zyngier wrote: >> On 22/06/16 14:52, Tomasz Nowicki wrote: >>> On 22.06.2016 15:25, Marc Zyngier wrote: On 22/06/16 13:35, Tomasz Nowicki wrote: > IORT shows representation of IO topology for ARM based systems.

Re: [PATCHv5 wl-drv-next 0/2] register-field manipulation macros

On Tue, 26 Jul 2016 16:00:04 +0300, Kalle Valo wrote: > Jakub Kicinski writes: > > > On Wed, 6 Jul 2016 17:19:35 +0100, Jakub Kicinski wrote: > >> Hi! > >> > >> I've added few lines about the compilation problems in > >> the commit message of patch 1. I would

Re: [PATCHv5 wl-drv-next 0/2] register-field manipulation macros

On Tue, 26 Jul 2016 16:00:04 +0300, Kalle Valo wrote: > Jakub Kicinski writes: > > > On Wed, 6 Jul 2016 17:19:35 +0100, Jakub Kicinski wrote: > >> Hi! > >> > >> I've added few lines about the compilation problems in > >> the commit message of patch 1. I would prefer the mass > >> rename of

Re: [PATCH] genirq/msi: Make sure PCI MSIs are activated early

On Tue, 26 Jul 2016, Thomas Gleixner wrote: > On Mon, 25 Jul 2016, Bjorn Helgaas wrote: > > On Mon, Jul 25, 2016 at 09:45:13AM +0200, Thomas Gleixner wrote: > > I thought the original issue [1] was that PCI_MSI_FLAGS_ENABLE was being > > written before PCI_MSI_ADDRESS_LO. That doesn't sound like

Re: [PATCH] genirq/msi: Make sure PCI MSIs are activated early

On Tue, 26 Jul 2016, Thomas Gleixner wrote: > On Mon, 25 Jul 2016, Bjorn Helgaas wrote: > > On Mon, Jul 25, 2016 at 09:45:13AM +0200, Thomas Gleixner wrote: > > I thought the original issue [1] was that PCI_MSI_FLAGS_ENABLE was being > > written before PCI_MSI_ADDRESS_LO. That doesn't sound like

Re: [PATCH] power:bq27xxx: 27000/10 read FLAGS register as single

On 07/18/2016 11:12 AM, H. Nikolaus Schaller wrote: > The bq27000 and bq27010 have a single byte FLAGS register. > Other gauges have 16 bit FLAGS registers. > > For reading the FLAGS register it is sufficient to read the single > register instead of reading RSOC at the next higher address as >

Re: [PATCH] power:bq27xxx: 27000/10 read FLAGS register as single

On 07/18/2016 11:12 AM, H. Nikolaus Schaller wrote: > The bq27000 and bq27010 have a single byte FLAGS register. > Other gauges have 16 bit FLAGS registers. > > For reading the FLAGS register it is sufficient to read the single > register instead of reading RSOC at the next higher address as >

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 26/07/16 13:30, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 26/07/16 13:30, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On Tue, 26 Jul 2016, Foster Snowhill wrote: > On 26.07.16 14:46, Thomas Gleixner wrote: > > Can you please try whether the replacement patch below fixes your issue as > > well? > This one doesn't fix the issue, getting resets again. Patch applied to HEAD > (commit

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On Tue, 26 Jul 2016, Foster Snowhill wrote: > On 26.07.16 14:46, Thomas Gleixner wrote: > > Can you please try whether the replacement patch below fixes your issue as > > well? > This one doesn't fix the issue, getting resets again. Patch applied to HEAD > (commit

Re: [PATCHv5 wl-drv-next 0/2] register-field manipulation macros

Jakub Kicinski writes: > On Wed, 6 Jul 2016 17:19:35 +0100, Jakub Kicinski wrote: >> Hi! >> >> I've added few lines about the compilation problems in >> the commit message of patch 1. I would prefer the mass >> rename of macros in mt7601u not to be part of this

Re: [PATCHv5 wl-drv-next 0/2] register-field manipulation macros

Jakub Kicinski writes: > On Wed, 6 Jul 2016 17:19:35 +0100, Jakub Kicinski wrote: >> Hi! >> >> I've added few lines about the compilation problems in >> the commit message of patch 1. I would prefer the mass >> rename of macros in mt7601u not to be part of this series >> so patch 2 is left

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On 26.07.16 14:46, Thomas Gleixner wrote: > Can you please try whether the replacement patch below fixes your issue as > well? This one doesn't fix the issue, getting resets again. Patch applied to HEAD (commit e65805251f2db69c9f67ed8062ab82526be5a374). [4.377316] igb: Intel(R) Gigabit

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On 26.07.16 14:46, Thomas Gleixner wrote: > Can you please try whether the replacement patch below fixes your issue as > well? This one doesn't fix the issue, getting resets again. Patch applied to HEAD (commit e65805251f2db69c9f67ed8062ab82526be5a374). [4.377316] igb: Intel(R) Gigabit

Re: [PATCH] README: Mention when 386 support ended + update obsolete 386 paths

On 26 July 2016 at 14:12, Jonathan Corbet wrote: > On Tue, 26 Jul 2016 09:45:43 +0200 Øyvind A. Holm > wrote: > > - Compiling the kernel with "Processor type" set higher than 386 > > will result in a kernel that does NOT work on a 386. The > > - kernel will

Re: [PATCH] README: Mention when 386 support ended + update obsolete 386 paths

On 26 July 2016 at 14:12, Jonathan Corbet wrote: > On Tue, 26 Jul 2016 09:45:43 +0200 Øyvind A. Holm > wrote: > > - Compiling the kernel with "Processor type" set higher than 386 > > will result in a kernel that does NOT work on a 386. The > > - kernel will detect this on bootup, and give up.

Re: [PATCH 0/5] Candidate fixes for premature OOM kills with node-lru v2

On Tue, Jul 26, 2016 at 05:11:30PM +0900, Joonsoo Kim wrote: > > These patches did not OOM for me on a 2G 32-bit KVM instance while running > > a stress test for an hour. Preliminary tests on a 64-bit system using a > > parallel dd workload did not show anything alarming. > > > > If an OOM is

Re: [PATCH 0/5] Candidate fixes for premature OOM kills with node-lru v2

On Tue, Jul 26, 2016 at 05:11:30PM +0900, Joonsoo Kim wrote: > > These patches did not OOM for me on a 2G 32-bit KVM instance while running > > a stress test for an hour. Preliminary tests on a 64-bit system using a > > parallel dd workload did not show anything alarming. > > > > If an OOM is

Re: bcache super block corruption with non 4k pages

On Tue, Jul 26, 2016 at 02:32:31PM +0200, Stefan Bader wrote: > On 26.07.2016 12:21, Kent Overstreet wrote: > > On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: > >> On 21.07.2016 10:58, Stefan Bader wrote: > >>> I was pointed at the thread which seems to address the same after > >>>

Re: bcache super block corruption with non 4k pages

On Tue, Jul 26, 2016 at 02:32:31PM +0200, Stefan Bader wrote: > On 26.07.2016 12:21, Kent Overstreet wrote: > > On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: > >> On 21.07.2016 10:58, Stefan Bader wrote: > >>> I was pointed at the thread which seems to address the same after > >>>

Is reading from /proc/self/smaps thread-safe?

Hey I have a simple program that mmaps 8MB of anonymous memory, spawns 16 threads, reads /proc/self/smaps in each thread and looks up whether mapped address can be found in smaps. From time to time it's not there. Is this supposed to work reliably? My guess is that libc functions allocate

Is reading from /proc/self/smaps thread-safe?

Hey I have a simple program that mmaps 8MB of anonymous memory, spawns 16 threads, reads /proc/self/smaps in each thread and looks up whether mapped address can be found in smaps. From time to time it's not there. Is this supposed to work reliably? My guess is that libc functions allocate

Re: next build: 74 warnings 0 failures (next/next-20160726)

On Tuesday, July 26, 2016 2:08:21 AM CEST Olof's autobuilder wrote: > Warnings: > 1 drivers/infiniband/core/cma.c:1242:12: warning: > 'src_addr_storage.sin_addr.s_addr' may be used uninitialized in this function > [-Wmaybe-uninitialized] > 1

Re: next build: 74 warnings 0 failures (next/next-20160726)

On Tuesday, July 26, 2016 2:08:21 AM CEST Olof's autobuilder wrote: > Warnings: > 1 drivers/infiniband/core/cma.c:1242:12: warning: > 'src_addr_storage.sin_addr.s_addr' may be used uninitialized in this function > [-Wmaybe-uninitialized] > 1

Re: [PATCH v9 5/9] acpi/arm64: Add GTDT table parse driver

Hi Rafael, On 26 July 2016 at 19:50, Rafael J. Wysocki wrote: > On Monday, July 25, 2016 11:27:03 PM fu@linaro.org wrote: >> From: Fu Wei >> >> This patch adds support for parsing arch timer in GTDT, >> provides some kernel APIs to parse all the PPIs

Re: [PATCH v9 5/9] acpi/arm64: Add GTDT table parse driver

Hi Rafael, On 26 July 2016 at 19:50, Rafael J. Wysocki wrote: > On Monday, July 25, 2016 11:27:03 PM fu@linaro.org wrote: >> From: Fu Wei >> >> This patch adds support for parsing arch timer in GTDT, >> provides some kernel APIs to parse all the PPIs and >> always-on info in GTDT and export

Re: master build: 2 failures 3 warnings (v4.7-1605-ge658052)

On Tuesday, July 26, 2016 1:29:55 PM CEST Build bot for Mark Brown wrote: > Tree/Branch: master > Git describe: v4.7-1605-ge658052 > Commit: e65805251f Merge branch 'irq-core-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > > Build Time: 106 min 43 sec > > Passed:7 /

Re: master build: 2 failures 3 warnings (v4.7-1605-ge658052)

On Tuesday, July 26, 2016 1:29:55 PM CEST Build bot for Mark Brown wrote: > Tree/Branch: master > Git describe: v4.7-1605-ge658052 > Commit: e65805251f Merge branch 'irq-core-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > > Build Time: 106 min 43 sec > > Passed:7 /

Re: bcache super block corruption with non 4k pages

On 26.07.2016 12:21, Kent Overstreet wrote: > On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: >> On 21.07.2016 10:58, Stefan Bader wrote: >>> I was pointed at the thread which seems to address the same after >>> I wrote most of below text. Did not want to re-write this so please >>>

Re: bcache super block corruption with non 4k pages

On 26.07.2016 12:21, Kent Overstreet wrote: > On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote: >> On 21.07.2016 10:58, Stefan Bader wrote: >>> I was pointed at the thread which seems to address the same after >>> I wrote most of below text. Did not want to re-write this so please >>>

[PATCH linux v3 4/9] x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op

HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter while Xen's idea is expected. In some cases these ideas diverge so we need to do remapping. Convert all callers of HYPERVISOR_vcpu_op() to use xen_vcpu_nr(). Leave xen_fill_possible_map() and xen_filter_cpu_maps() intact as they're

[PATCH] mmc: sdhci-esdhc-imx: avoid unused function warnings

The driver has just gained a slightly incorrect pm-sleep implementation that causes warnings when CONFIG_PM is set but CONFIG_PM_SLEEP is not: drivers/mmc/host/sdhci-esdhc-imx.c:1302:12: error: 'sdhci_esdhc_resume' defined but not used [-Werror=unused-function] static int

<    5   6   7   8   9   10   11   12   13   14   >