[PATCH][RESEND] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF

From: Kuninori Morimoto commit 93c667ca2598bd84f1bd3f2fa176af69707699fe ("of: *node argument to of_parse_phandle_with_args should be const") changed to const for struct device node *np, but it cares CONFIG_OF case only, !CONFIG_OF case need it too.

[PATCH][RESEND] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF

From: Kuninori Morimoto commit 93c667ca2598bd84f1bd3f2fa176af69707699fe ("of: *node argument to of_parse_phandle_with_args should be const") changed to const for struct device node *np, but it cares CONFIG_OF case only, !CONFIG_OF case need it too. Signed-off-by: Kuninori Morimoto ---

Re: [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points

Hi Brian, Eduardo, Sascha 在 2016年04月21日 09:12, Brian Norris 写道: + Sascha On Wed, Apr 20, 2016 at 04:48:18PM -0700, Eduardo Valentin wrote: On Mon, Apr 18, 2016 at 11:35:59AM +0800, Caesar Wang wrote: From: Mikko Perttunen This adds support for hardware-tracked trip

Re: [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points

Hi Brian, Eduardo, Sascha 在 2016年04月21日 09:12, Brian Norris 写道: + Sascha On Wed, Apr 20, 2016 at 04:48:18PM -0700, Eduardo Valentin wrote: On Mon, Apr 18, 2016 at 11:35:59AM +0800, Caesar Wang wrote: From: Mikko Perttunen This adds support for hardware-tracked trip points to the device

Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

Hi Marc: On 2016年04月22日 05:12, Marc Zyngier wrote: On Thu, 21 Apr 2016 22:24:09 +0200 Heiko Stübner wrote: Am Donnerstag, 21. April 2016, 12:30:18 schrieb Marc Zyngier: On Thu, 21 Apr 2016 18:47:20 +0800 "Huang, Tao" wrote: Hi, Mark: On

[PATCH] dma: rcar-dmac: use list_add() on rcar_dmac_desc_put()

From: Kuninori Morimoto Current rcar_dmac_desc_put() is using list_add_tail() in order to push used descriptor to list of free descriptors, and next DMA transfer try to reuse it from this list. But because it is using *_tail(), this reuse effect can't be

[PATCH] dma: rcar-dmac: use list_add() on rcar_dmac_desc_put()

From: Kuninori Morimoto Current rcar_dmac_desc_put() is using list_add_tail() in order to push used descriptor to list of free descriptors, and next DMA transfer try to reuse it from this list. But because it is using *_tail(), this reuse effect can't be obtained without using all of them. For

Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

Hi Marc: On 2016年04月22日 05:12, Marc Zyngier wrote: On Thu, 21 Apr 2016 22:24:09 +0200 Heiko Stübner wrote: Am Donnerstag, 21. April 2016, 12:30:18 schrieb Marc Zyngier: On Thu, 21 Apr 2016 18:47:20 +0800 "Huang, Tao" wrote: Hi, Mark: On 2016年04月21日 18:19, Mark Rutland wrote: On Thu,

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

2016-04-21 23:29 GMT+08:00 Radim Krčmář : > 2016-04-21 13:29+0200, Greg Kurz: >> On Wed, 20 Apr 2016 20:29:09 +0200 >> Radim Krčmář wrote: >>> 2016-04-20 17:44+0200, Greg Kurz: >>> > Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)")

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

2016-04-21 23:29 GMT+08:00 Radim Krčmář : > 2016-04-21 13:29+0200, Greg Kurz: >> On Wed, 20 Apr 2016 20:29:09 +0200 >> Radim Krčmář wrote: >>> 2016-04-20 17:44+0200, Greg Kurz: >>> > Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)") >>> > introduced a check to prevent

RE: [PATCH kernel 1/2] mm: add the related functions to build the free page bitmap

> On Wed, Apr 20, 2016 at 01:41:24AM +, Li, Liang Z wrote: > > > Cc: Rik van Riel; v...@zeniv.linux.org.uk; > > > linux-kernel@vger.kernel.org; quint...@redhat.com; > > > amit.s...@redhat.com; pbonz...@redhat.com; dgilb...@redhat.com; > > > linux...@kvack.org; k...@vger.kernel.org; qemu-

RE: [PATCH kernel 1/2] mm: add the related functions to build the free page bitmap

> On Wed, Apr 20, 2016 at 01:41:24AM +, Li, Liang Z wrote: > > > Cc: Rik van Riel; v...@zeniv.linux.org.uk; > > > linux-kernel@vger.kernel.org; quint...@redhat.com; > > > amit.s...@redhat.com; pbonz...@redhat.com; dgilb...@redhat.com; > > > linux...@kvack.org; k...@vger.kernel.org; qemu-

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote: > Hi, > > > From: Yoshihiro Shimoda > > Sent: Friday, April 15, 2016 6:59 PM > > > > Hi, > > > > > From: Roger Quadros > > > Sent: Thursday, April 14, 2016 8:32 PM > > > > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote: > > > >

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote: > Hi, > > > From: Yoshihiro Shimoda > > Sent: Friday, April 15, 2016 6:59 PM > > > > Hi, > > > > > From: Roger Quadros > > > Sent: Thursday, April 14, 2016 8:32 PM > > > > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote: > > > >

Re: [PATCH V4] audit: add tty field to LOGIN event

On Thu, Apr 21, 2016 at 2:14 PM, Richard Guy Briggs wrote: > The tty field was missing from AUDIT_LOGIN events. > > Refactor code to create a new function audit_get_tty(), using it to > replace the call in audit_log_task_info() and to add it to > audit_log_set_loginuid(). Lock

Re: [PATCH V4] audit: add tty field to LOGIN event

On Thu, Apr 21, 2016 at 2:14 PM, Richard Guy Briggs wrote: > The tty field was missing from AUDIT_LOGIN events. > > Refactor code to create a new function audit_get_tty(), using it to > replace the call in audit_log_task_info() and to add it to > audit_log_set_loginuid(). Lock and bump the kref

Re: [PATCH v11 3/3] printk: make printk.synchronous param rw

command line: BOOT_IMAGE=/vmlinuz-4.6.0-rc4-next-20160421 ... printk.synchronous=0 [..] [0.00] [] printk_sync_set+0x12/0x52 [0.00] [] parse_args+0x1ad/0x2bb [0.00] [] ? vprintk_default+0x18/0x1a [0.00] [] start_kernel+0x175/0x378 [0.00] [] ? set_init_ar

Re: [PATCH v11 3/3] printk: make printk.synchronous param rw

command line: BOOT_IMAGE=/vmlinuz-4.6.0-rc4-next-20160421 ... printk.synchronous=0 [..] [0.00] [] printk_sync_set+0x12/0x52 [0.00] [] parse_args+0x1ad/0x2bb [0.00] [] ? vprintk_default+0x18/0x1a [0.00] [] start_kernel+0x175/0x378 [0.00] [] ? set_init_ar

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

On Wed, 20 Apr 2016, Jiri Kosina wrote: > On Tue, 19 Apr 2016, Eric Wheeler wrote: > > > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > > expensive no-op given the fact that the thread is not marked freezable. > > > > > > I/O helper kthreads, exactly such as the

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

On Wed, 20 Apr 2016, Jiri Kosina wrote: > On Tue, 19 Apr 2016, Eric Wheeler wrote: > > > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > > expensive no-op given the fact that the thread is not marked freezable. > > > > > > I/O helper kthreads, exactly such as the

Re: [PATCH 2/3] ASoC: simple-card: Add support jack detection via codec

On 2016年04月21日 22:19, Rob Herring wrote: On Mon, Apr 18, 2016 at 04:17:31PM +0800, Xing Zheng wrote: In most cases, many codecs already supports jack detection, previouslly, we need to create a customized machine driver every time. Hence, the simple-card need to support use them dynamically

Re: [PATCH 2/3] ASoC: simple-card: Add support jack detection via codec

On 2016年04月21日 22:19, Rob Herring wrote: On Mon, Apr 18, 2016 at 04:17:31PM +0800, Xing Zheng wrote: In most cases, many codecs already supports jack detection, previouslly, we need to create a customized machine driver every time. Hence, the simple-card need to support use them dynamically

RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

On Tue, 19 Apr 2016, Matthew Fortune wrote: > > I have a fix in the works and to have it integrated upstream I just > > need to accompany it with suitable cases -- like the fragment above -- > > for the GAS testsuite. I'll send an update when it's ready. > > I do not think the change in

RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

On Tue, 19 Apr 2016, Matthew Fortune wrote: > > I have a fix in the works and to have it integrated upstream I just > > need to accompany it with suitable cases -- like the fragment above -- > > for the GAS testsuite. I'll send an update when it's ready. > > I do not think the change in

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On 4/21/2016 8:22 PM, Matthew Wilcox wrote: On Thu, Apr 21, 2016 at 07:43:39PM -0400, Toshi Kani wrote: On 4/21/2016 4:21 PM, Mike Kravetz wrote: Might want to keep the future possibility of PUD_SIZE THP in mind? Yes, this is why the func name does not say 'pmd'. It can be extended to

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On 4/21/2016 8:22 PM, Matthew Wilcox wrote: On Thu, Apr 21, 2016 at 07:43:39PM -0400, Toshi Kani wrote: On 4/21/2016 4:21 PM, Mike Kravetz wrote: Might want to keep the future possibility of PUD_SIZE THP in mind? Yes, this is why the func name does not say 'pmd'. It can be extended to

[git pull] drm fixes

Hi Linus, i915, nouveau and amdgpu/radeon fixes in this. Two nouveau fixes, one for a regression with dithering and one for a bug hit by the userspace drivers. i915 has a few fixes, mostly things heading for stable, two important skylake GT3/4 hangs. radeon/amdgpu has some audio,

[git pull] drm fixes

Hi Linus, i915, nouveau and amdgpu/radeon fixes in this. Two nouveau fixes, one for a regression with dithering and one for a bug hit by the userspace drivers. i915 has a few fixes, mostly things heading for stable, two important skylake GT3/4 hangs. radeon/amdgpu has some audio,

linux-next: build failure after merge of the pci tree

ode; ^ Caused by commit 7be92716c1aa ("PCI: keystone: Add error IRQ handler") I have used the pci tree from next-20160421 for today. -- Cheers, Stephen Rothwell

linux-next: build failure after merge of the pci tree

ode; ^ Caused by commit 7be92716c1aa ("PCI: keystone: Add error IRQ handler") I have used the pci tree from next-20160421 for today. -- Cheers, Stephen Rothwell

Re: [PATCH 1/3] mfd: add Cypress FM33256B Processor Companion driver

Hi, [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.6-rc4 next-20160421] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Jeppe-Ledet-Pedersen/Cypress-FM33256B

Re: [PATCH 1/3] mfd: add Cypress FM33256B Processor Companion driver

Hi, [auto build test ERROR on ljones-mfd/for-mfd-next] [also build test ERROR on v4.6-rc4 next-20160421] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Jeppe-Ledet-Pedersen/Cypress-FM33256B

[BUG linux-next] kernel NULL pointer dereference on linux-next-20160420

Hi folks, I did the below test with huge tmpfs on linux-next-20160420: # mount -t tmpfs huge=1 tmpfs /mnt # cd /mnt Then clone linux kernel Then I got the below bug, such test works well on non-huge tmpfs. BUG: unable to handle kernel NULL pointer dereference at (null) IP: []

Re: [PATCH] cpufreq: mt8173: use list_for_each_entry*()

On Tuesday, April 05, 2016 08:35:57 AM Viresh Kumar wrote: > On 05-04-16, 10:38, Geliang Tang wrote: > > Use list_for_each_entry*() instead of list_for_each*() to simplify > > the code. > > > > Signed-off-by: Geliang Tang > > --- > > drivers/cpufreq/mt8173-cpufreq.c | 14

[BUG linux-next] kernel NULL pointer dereference on linux-next-20160420

Hi folks, I did the below test with huge tmpfs on linux-next-20160420: # mount -t tmpfs huge=1 tmpfs /mnt # cd /mnt Then clone linux kernel Then I got the below bug, such test works well on non-huge tmpfs. BUG: unable to handle kernel NULL pointer dereference at (null) IP: []

Re: [PATCH] cpufreq: mt8173: use list_for_each_entry*()

On Tuesday, April 05, 2016 08:35:57 AM Viresh Kumar wrote: > On 05-04-16, 10:38, Geliang Tang wrote: > > Use list_for_each_entry*() instead of list_for_each*() to simplify > > the code. > > > > Signed-off-by: Geliang Tang > > --- > > drivers/cpufreq/mt8173-cpufreq.c | 14 -- > > 1

Re: [PATCH] cpuidle: Indicate when a device has been unregistered

On Wednesday, April 06, 2016 12:00:48 PM Daniel Lezcano wrote: > On Tue, Apr 05, 2016 at 02:05:38PM -0500, Dave Gerlach wrote: > > Currently the 'registered' member of the cpuidle_device struct is set > > to 1 during cpuidle_register_device. In this same function there are > > checks to see if the

Re: [PATCH] cpuidle: Indicate when a device has been unregistered

On Wednesday, April 06, 2016 12:00:48 PM Daniel Lezcano wrote: > On Tue, Apr 05, 2016 at 02:05:38PM -0500, Dave Gerlach wrote: > > Currently the 'registered' member of the cpuidle_device struct is set > > to 1 during cpuidle_register_device. In this same function there are > > checks to see if the

Re: [PATCH 0/3] cpufreq: logging consistency changes

On Tuesday, April 05, 2016 01:28:22 PM Joe Perches wrote: > Trivial consistency changes. > > Joe Perches (3): > intel_pstate: Use pr_fmt > cpufreq: Convert printk(KERN_ to pr_ > cpufreq: Use consistent prefixing via pr_fmt > > drivers/cpufreq/acpi-cpufreq.c| 16 +++--- >

Re: [PATCH 0/3] cpufreq: logging consistency changes

On Tuesday, April 05, 2016 01:28:22 PM Joe Perches wrote: > Trivial consistency changes. > > Joe Perches (3): > intel_pstate: Use pr_fmt > cpufreq: Convert printk(KERN_ to pr_ > cpufreq: Use consistent prefixing via pr_fmt > > drivers/cpufreq/acpi-cpufreq.c| 16 +++--- >

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On Thu, Apr 21, 2016 at 07:43:39PM -0400, Toshi Kani wrote: > On 4/21/2016 4:21 PM, Mike Kravetz wrote: > >Might want to keep the future possibility of PUD_SIZE THP in mind? > > Yes, this is why the func name does not say 'pmd'. It can be extended to > support > PUD_SIZE in future. Sure ... but

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On Thu, Apr 21, 2016 at 07:43:39PM -0400, Toshi Kani wrote: > On 4/21/2016 4:21 PM, Mike Kravetz wrote: > >Might want to keep the future possibility of PUD_SIZE THP in mind? > > Yes, this is why the func name does not say 'pmd'. It can be extended to > support > PUD_SIZE in future. Sure ... but

Re: [PATCH] mm: make fault_around_bytes configurable

On Mon, 18 Apr 2016 20:47:16 +0530 Vinayak Menon wrote: > Mapping pages around fault is found to cause performance degradation > in certain use cases. The test performed here is launch of 10 apps > one by one, doing something with the app each time, and then repeating >

Re: [PATCH] mm: make fault_around_bytes configurable

On Mon, 18 Apr 2016 20:47:16 +0530 Vinayak Menon wrote: > Mapping pages around fault is found to cause performance degradation > in certain use cases. The test performed here is launch of 10 apps > one by one, doing something with the app each time, and then repeating > the same sequence once

Re: linux-next: manual merge of the net-next tree with the net tree

Hi David, Stephen Rothwell writes: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > drivers/net/dsa/mv88e6xxx.c > > between commit: > > 207afda1b503 ("net: dsa: mv88e6xxx: share the same default FDB") > > from the net tree and commit:

Re: linux-next: manual merge of the net-next tree with the net tree

Hi David, Stephen Rothwell writes: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > drivers/net/dsa/mv88e6xxx.c > > between commit: > > 207afda1b503 ("net: dsa: mv88e6xxx: share the same default FDB") > > from the net tree and commit: > > 009a2b9843bf

Re: [PATCH 2/3] misc: eeprom: add Cypress FM33256B FRAM driver

Hi, On 20/04/2016 at 13:07:50 +0200, Jeppe Ledet-Pedersen wrote : > Signed-off-by: Jeppe Ledet-Pedersen > --- > MAINTAINERS | 1 + > drivers/misc/eeprom/Kconfig | 12 > drivers/misc/eeprom/Makefile| 1 + >

Re: [PATCH 2/3] misc: eeprom: add Cypress FM33256B FRAM driver

Hi, On 20/04/2016 at 13:07:50 +0200, Jeppe Ledet-Pedersen wrote : > Signed-off-by: Jeppe Ledet-Pedersen > --- > MAINTAINERS | 1 + > drivers/misc/eeprom/Kconfig | 12 > drivers/misc/eeprom/Makefile| 1 + > drivers/misc/eeprom/fm33256b-fram.c |

Re: [PATCH resend 0/3] mm: allow arch to override lowmem_page_address

On Mon, 18 Apr 2016 18:04:54 +0200 Ard Biesheuvel wrote: > These patches allow the arch to define the page_to_virt() conversion that > is used in lowmem_page_address(). This is desirable for arm64, where this > conversion is trivial when CONFIG_SPARSEMEM_VMEMMAP is

Re: [PATCH resend 0/3] mm: allow arch to override lowmem_page_address

On Mon, 18 Apr 2016 18:04:54 +0200 Ard Biesheuvel wrote: > These patches allow the arch to define the page_to_virt() conversion that > is used in lowmem_page_address(). This is desirable for arm64, where this > conversion is trivial when CONFIG_SPARSEMEM_VMEMMAP is enabled, while > breaking it

Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to change compatible mode

On Thu, Apr 21, 2016 at 4:27 PM, Andy Lutomirski wrote: > On Thu, Apr 21, 2016 at 1:12 PM, Peter Zijlstra wrote: >> On Thu, Apr 21, 2016 at 12:39:42PM -0700, Andy Lutomirski wrote: >>> On Wed, Apr 20, 2016 at 12:05 PM, Peter Zijlstra

Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to change compatible mode

On Thu, Apr 21, 2016 at 4:27 PM, Andy Lutomirski wrote: > On Thu, Apr 21, 2016 at 1:12 PM, Peter Zijlstra wrote: >> On Thu, Apr 21, 2016 at 12:39:42PM -0700, Andy Lutomirski wrote: >>> On Wed, Apr 20, 2016 at 12:05 PM, Peter Zijlstra >>> wrote: >>> > On Wed, Apr 20, 2016 at 08:40:23AM -0700,

Re: [PATCH] mm/memory-failure: fix race with compound page split/merge

On Mon, 18 Apr 2016 23:15:52 + Naoya Horiguchi wrote: > # CCed Andrew, Thanks. > On Mon, Apr 18, 2016 at 02:43:45PM +0300, Konstantin Khlebnikov wrote: > > Get_hwpoison_page() must recheck relation between head and tail pages. > > > > Signed-off-by: Konstantin

Re: [PATCH] mm/memory-failure: fix race with compound page split/merge

On Mon, 18 Apr 2016 23:15:52 + Naoya Horiguchi wrote: > # CCed Andrew, Thanks. > On Mon, Apr 18, 2016 at 02:43:45PM +0300, Konstantin Khlebnikov wrote: > > Get_hwpoison_page() must recheck relation between head and tail pages. > > > > Signed-off-by: Konstantin Khlebnikov > > Looks good

Re: [PATCH 3/3] rtc: add Cypress FM33256B RTC driver

Hi, Looks mostly good, a few comments below On 20/04/2016 at 13:07:51 +0200, Jeppe Ledet-Pedersen wrote : Please always include a commit message. > Signed-off-by: Jeppe Ledet-Pedersen > --- [...] > +static int fm33256b_rtc_readtime(struct device *dev, struct rtc_time *tm)

Re: [PATCH 3/3] rtc: add Cypress FM33256B RTC driver

Hi, Looks mostly good, a few comments below On 20/04/2016 at 13:07:51 +0200, Jeppe Ledet-Pedersen wrote : Please always include a commit message. > Signed-off-by: Jeppe Ledet-Pedersen > --- [...] > +static int fm33256b_rtc_readtime(struct device *dev, struct rtc_time *tm) > +{ > + int

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On 4/21/2016 4:21 PM, Mike Kravetz wrote: On 04/21/2016 12:06 AM, Matthew Wilcox wrote: On Wed, Apr 20, 2016 at 11:10:25PM -0400, Toshi Kani wrote: How about moving the function (as is) to mm/huge_memory.c, rename it to get_hugepage_unmapped_area(), which is defined to NULL in huge_mm.h when

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On 4/21/2016 4:21 PM, Mike Kravetz wrote: On 04/21/2016 12:06 AM, Matthew Wilcox wrote: On Wed, Apr 20, 2016 at 11:10:25PM -0400, Toshi Kani wrote: How about moving the function (as is) to mm/huge_memory.c, rename it to get_hugepage_unmapped_area(), which is defined to NULL in huge_mm.h when

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On 4/21/2016 3:06 AM, Matthew Wilcox wrote: On Wed, Apr 20, 2016 at 11:10:25PM -0400, Toshi Kani wrote: How about moving the function (as is) to mm/huge_memory.c, rename it to get_hugepage_unmapped_area(), which is defined to NULL in huge_mm.h when TRANSPARENT_HUGEPAGE is unset? Great idea.

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On 4/21/2016 3:06 AM, Matthew Wilcox wrote: On Wed, Apr 20, 2016 at 11:10:25PM -0400, Toshi Kani wrote: How about moving the function (as is) to mm/huge_memory.c, rename it to get_hugepage_unmapped_area(), which is defined to NULL in huge_mm.h when TRANSPARENT_HUGEPAGE is unset? Great idea.

[BUG] 4.4.8 hard-lockup after ~12h

I just experienced a weird hang on 4.4.8. Unfortunately, the logs are sparse. They do show an issue with either the GPU, or whatever is required for it to talk to the driver (PCIe MSI ?). Refer to the attached kernel log for a large number of >10ms GPU ring 0 stalls/GPU lockups back-to-back,

[BUG] 4.4.8 hard-lockup after ~12h

I just experienced a weird hang on 4.4.8. Unfortunately, the logs are sparse. They do show an issue with either the GPU, or whatever is required for it to talk to the driver (PCIe MSI ?). Refer to the attached kernel log for a large number of >10ms GPU ring 0 stalls/GPU lockups back-to-back,

Re: [PATCH] watchdog: core: Fix circular locking dependency

On Thu, Apr 21, 2016 at 03:50:55PM +0100, One Thousand Gnomes wrote: > > Turns out the call to cancel_delayed_work_sync() in watchdog_release() > > is not necessary and can be dropped. If the worker is no longer necessary, > > the subsequent call to watchdog_update_worker() will cancel it. If it

Re: [PATCH] watchdog: core: Fix circular locking dependency

On Thu, Apr 21, 2016 at 03:50:55PM +0100, One Thousand Gnomes wrote: > > Turns out the call to cancel_delayed_work_sync() in watchdog_release() > > is not necessary and can be dropped. If the worker is no longer necessary, > > the subsequent call to watchdog_update_worker() will cancel it. If it

Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to change compatible mode

On Thu, Apr 21, 2016 at 1:12 PM, Peter Zijlstra wrote: > On Thu, Apr 21, 2016 at 12:39:42PM -0700, Andy Lutomirski wrote: >> On Wed, Apr 20, 2016 at 12:05 PM, Peter Zijlstra >> wrote: >> > On Wed, Apr 20, 2016 at 08:40:23AM -0700, Andy Lutomirski

Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to change compatible mode

On Thu, Apr 21, 2016 at 1:12 PM, Peter Zijlstra wrote: > On Thu, Apr 21, 2016 at 12:39:42PM -0700, Andy Lutomirski wrote: >> On Wed, Apr 20, 2016 at 12:05 PM, Peter Zijlstra >> wrote: >> > On Wed, Apr 20, 2016 at 08:40:23AM -0700, Andy Lutomirski wrote: > >> >> >> Peter, I got lost in the code

Re: [PATCH v2] z3fold: the 3-fold allocator for compressed pages

On Tue, 19 Apr 2016 11:48:45 +0200 Vitaly Wool wrote: > This patch introduces z3fold, a special purpose allocator for storing > compressed pages. It is designed to store up to three compressed pages per > physical page. It is a ZBUD derivative which allows for higher

Re: [PATCH] rtc: snvs: return error in case enable_irq_wake fails

On 20/04/2016 at 16:09:57 -0700, Stefan Agner wrote : > If enable_irq_wake fails, we should return that error code so that > entering suspend fails. Otherwise we will get a WARNING along with > the hint of a unbalanced wake disable: > Unbalanced IRQ 37 wake disable > > Signed-off-by: Stefan Agner

Re: [PATCH v2] z3fold: the 3-fold allocator for compressed pages

On Tue, 19 Apr 2016 11:48:45 +0200 Vitaly Wool wrote: > This patch introduces z3fold, a special purpose allocator for storing > compressed pages. It is designed to store up to three compressed pages per > physical page. It is a ZBUD derivative which allows for higher compression > ratio keeping

Re: [PATCH] rtc: snvs: return error in case enable_irq_wake fails

On 20/04/2016 at 16:09:57 -0700, Stefan Agner wrote : > If enable_irq_wake fails, we should return that error code so that > entering suspend fails. Otherwise we will get a WARNING along with > the hint of a unbalanced wake disable: > Unbalanced IRQ 37 wake disable > > Signed-off-by: Stefan Agner

Re: [PATCH V4] rtc: zynqmp: Update seconds time programming logic

On 20/04/2016 at 21:17:35 +0530, Anurag Kumar Vulisha wrote : > We programe RTC time using SET_TIME_WRITE register and read the RTC > current time using CURRENT_TIME register. When we set the time by > writing into SET_TIME_WRITE Register and immediately try to read the > rtc time from

Re: [PATCH V4] rtc: zynqmp: Update seconds time programming logic

On 20/04/2016 at 21:17:35 +0530, Anurag Kumar Vulisha wrote : > We programe RTC time using SET_TIME_WRITE register and read the RTC > current time using CURRENT_TIME register. When we set the time by > writing into SET_TIME_WRITE Register and immediately try to read the > rtc time from

Re: [PATCH 2/7] mfd: lp8788: Use devm_mfd_add_devices and devm_regmap_add_irq_chip

Hi Laxman, On 4/21/2016 9:25 PM, Laxman Dewangan wrote: Use devm_mfd_add_devices() for adding MFD child devices and devm_regmap_add_irq_chip() for IRQ chip registration. This patch doesn't include the code regarding devm_mfd_add_devices(). Could you check it again? Or am I missing any

Re: [PATCH 2/7] mfd: lp8788: Use devm_mfd_add_devices and devm_regmap_add_irq_chip

Hi Laxman, On 4/21/2016 9:25 PM, Laxman Dewangan wrote: Use devm_mfd_add_devices() for adding MFD child devices and devm_regmap_add_irq_chip() for IRQ chip registration. This patch doesn't include the code regarding devm_mfd_add_devices(). Could you check it again? Or am I missing any

Re: [PATCH] scripts: kconfig: implement a sort method

On 04/21/16 13:07, Felipe Balbi wrote: > With a growing amount of Kernel configuration, it's > getting ever more difficult to find anything on > menuconfig. Because of that, implement mergesort for > kconfig to make it a little easier for anybody > building kernels. Hi, Please explain the

Re: [PATCH] scripts: kconfig: implement a sort method

On 04/21/16 13:07, Felipe Balbi wrote: > With a growing amount of Kernel configuration, it's > getting ever more difficult to find anything on > menuconfig. Because of that, implement mergesort for > kconfig to make it a little easier for anybody > building kernels. Hi, Please explain the

Re: [PATCH] kvm: x86: make lapic hrtimer pinned

2016-04-05 20:40 GMT+08:00 Luiz Capitulino : > On Tue, 5 Apr 2016 14:18:01 +0800 > Yang Zhang wrote: > >> On 2016/4/5 5:00, Rik van Riel wrote: >> > On Mon, 2016-04-04 at 16:46 -0400, Luiz Capitulino wrote: >> >> When a vCPU runs on a nohz_full

Re: [PATCH] kvm: x86: make lapic hrtimer pinned

2016-04-05 20:40 GMT+08:00 Luiz Capitulino : > On Tue, 5 Apr 2016 14:18:01 +0800 > Yang Zhang wrote: > >> On 2016/4/5 5:00, Rik van Riel wrote: >> > On Mon, 2016-04-04 at 16:46 -0400, Luiz Capitulino wrote: >> >> When a vCPU runs on a nohz_full core, the hrtimer used by >> >> the lapic emulation

Re: [PATCH 1/2] cgroup, cpuset: replace cpuset_post_attach_flush() with cgroup_subsys->post_attach callback

BTW, I just got a permanent delivery failure. The mail was sent out through gmail. Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the server for the recipient domain suse.com by prv3-mx.novell.com. [130.57.1.17]. The error that the other

Re: [PATCH 1/2] cgroup, cpuset: replace cpuset_post_attach_flush() with cgroup_subsys->post_attach callback

BTW, I just got a permanent delivery failure. The mail was sent out through gmail. Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the server for the recipient domain suse.com by prv3-mx.novell.com. [130.57.1.17]. The error that the other

Re: [PATCH] asus-laptop: correct error handling in asus_read_brightness()

On Sat, Apr 16, 2016 at 3:27 AM, Giedrius Statkevičius wrote: > It is possible that acpi_evaluate_integer might fail and value would not be > set to any value so correct this defect by returning 0 in case of an > error. This is also the correct thing to return

Re: [PATCH] asus-laptop: correct error handling in asus_read_brightness()

On Sat, Apr 16, 2016 at 3:27 AM, Giedrius Statkevičius wrote: > It is possible that acpi_evaluate_integer might fail and value would not be > set to any value so correct this defect by returning 0 in case of an > error. This is also the correct thing to return because the backlight > subsystem

[PATCH 2/2] memcg: relocate charge moving from ->attach to ->post_attach

Hello, So, this ended up a lot simpler than I originally expected. I tested it lightly and it seems to work fine. Petr, can you please test these two patches w/o the lru drain drop patch and see whether the problem is gone? Thanks. -- 8< -- If charge moving is used, memcg performs

[PATCH 2/2] memcg: relocate charge moving from ->attach to ->post_attach

Hello, So, this ended up a lot simpler than I originally expected. I tested it lightly and it seems to work fine. Petr, can you please test these two patches w/o the lru drain drop patch and see whether the problem is gone? Thanks. -- 8< -- If charge moving is used, memcg performs

[PATCH 1/2] cgroup, cpuset: replace cpuset_post_attach_flush() with cgroup_subsys->post_attach callback

Since e93ad19d0564 ("cpuset: make mm migration asynchronous"), cpuset kicks off asynchronous NUMA node migration if necessary during task migration and flushes it from cpuset_post_attach_flush() which is called at the end of __cgroup_procs_write(). This is to avoid performing migration with

[PATCH 1/2] cgroup, cpuset: replace cpuset_post_attach_flush() with cgroup_subsys->post_attach callback

Since e93ad19d0564 ("cpuset: make mm migration asynchronous"), cpuset kicks off asynchronous NUMA node migration if necessary during task migration and flushes it from cpuset_post_attach_flush() which is called at the end of __cgroup_procs_write(). This is to avoid performing migration with

Re: [PATCH] of: document refcount incrementation of of_get_cpu_node()

On 4/19/2016 6:18 PM, Masahiro Yamada wrote: > This function increments refcount. This is worth noting. > > Signed-off-by: Masahiro Yamada > --- > > drivers/of/base.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/of/base.c

Re: [PATCH] of: document refcount incrementation of of_get_cpu_node()

On 4/19/2016 6:18 PM, Masahiro Yamada wrote: > This function increments refcount. This is worth noting. > > Signed-off-by: Masahiro Yamada > --- > > drivers/of/base.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/of/base.c b/drivers/of/base.c > index

Re: [PATCH v2 1/2] asus-laptop: remove redundant initializers

On Sat, Apr 16, 2016 at 3:01 AM, Giedrius Statkevičius wrote: > Initializing rv to AE_OK is pointless because later function results are > assigned to them and only then the variable is used > > Signed-off-by: Giedrius Statkevičius

Re: [PATCH v2 1/2] asus-laptop: remove redundant initializers

On Sat, Apr 16, 2016 at 3:01 AM, Giedrius Statkevičius wrote: > Initializing rv to AE_OK is pointless because later function results are > assigned to them and only then the variable is used > > Signed-off-by: Giedrius Statkevičius Fine to me: Acked-by: Andy Shevchenko > --- >

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/21/2016 2:15 AM, Hugh Dickins wrote: On Wed, 20 Apr 2016, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures code, I want to check if

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/21/2016 2:15 AM, Hugh Dickins wrote: On Wed, 20 Apr 2016, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures code, I want to check if

[PATCH v2] ixgbevf: Change the relaxed order settings in VF driver for sparc

We noticed performance issues with VF interface on sparc compared to PF. Setting the RX to IXGBE_DCA_RXCTRL_DATA_WRO_EN brings it on far with PF. Also this matches to the default sparc setting in PF driver. Signed-off-by: Babu Moger Acked-by: Sowmini Varadhan

[PATCH v2] ixgbevf: Change the relaxed order settings in VF driver for sparc

We noticed performance issues with VF interface on sparc compared to PF. Setting the RX to IXGBE_DCA_RXCTRL_DATA_WRO_EN brings it on far with PF. Also this matches to the default sparc setting in PF driver. Signed-off-by: Babu Moger Acked-by: Sowmini Varadhan --- v2: Alexander had concerns

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/21/2016 12:30 AM, Kirill A. Shutemov wrote: On Wed, Apr 20, 2016 at 02:00:11PM -0700, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/21/2016 12:30 AM, Kirill A. Shutemov wrote: On Wed, Apr 20, 2016 at 02:00:11PM -0700, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures

Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

Am Donnerstag, 21. April 2016, 15:38:22 schrieb Doug Anderson: > Hi, > > I didn't look as deeply as Heiko, but a few comments... > > On Thu, Apr 21, 2016 at 3:02 PM, Heiko Stübner wrote: > > Hi Jay, > > > > Am Donnerstag, 21. April 2016, 11:58:12 schrieb Jianqun Xu: > >> This

Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

Am Donnerstag, 21. April 2016, 15:38:22 schrieb Doug Anderson: > Hi, > > I didn't look as deeply as Heiko, but a few comments... > > On Thu, Apr 21, 2016 at 3:02 PM, Heiko Stübner wrote: > > Hi Jay, > > > > Am Donnerstag, 21. April 2016, 11:58:12 schrieb Jianqun Xu: > >> This patch adds

Re: [RFC PATCH 09/11] drivers: acpi: implement acpi_dma_configure

On Thu, Apr 14, 2016 at 8:25 PM, Lorenzo Pieralisi wrote: > On DT based systems, the of_dma_configure() API implements DMA configuration > for a given device. On ACPI systems an API equivalent to of_dma_configure() > is missing which implies that it is currently not

Re: [RFC PATCH 09/11] drivers: acpi: implement acpi_dma_configure

On Thu, Apr 14, 2016 at 8:25 PM, Lorenzo Pieralisi wrote: > On DT based systems, the of_dma_configure() API implements DMA configuration > for a given device. On ACPI systems an API equivalent to of_dma_configure() > is missing which implies that it is currently not possible to set-up DMA >

<    1   2   3   4   5   6   7   8   9   10   >