Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

On (03/22/16 11:13), Byungchul Park wrote: [..] what about a "normal" case, when things are not going to explode printk(), but we have several lockups on the same lock (which is probably more likely than printk recursion)? suppose: - there are 8 CPUs on the system - 1 cpus owns the spin_lock for

Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

On (03/22/16 11:13), Byungchul Park wrote: [..] what about a "normal" case, when things are not going to explode printk(), but we have several lockups on the same lock (which is probably more likely than printk recursion)? suppose: - there are 8 CPUs on the system - 1 cpus owns the spin_lock for

Re: [PATCH v2 13/18] mm/compaction: support non-lru movable page migration

On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote: > We have allowed migration for only LRU pages until now and it was > enough to make high-order pages. But recently, embedded system(e.g., > webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) > so we have seen several

Re: [PATCH v2 13/18] mm/compaction: support non-lru movable page migration

On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote: > We have allowed migration for only LRU pages until now and it was > enough to make high-order pages. But recently, embedded system(e.g., > webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) > so we have seen several

Re: Nonterministic hang during bootconsole/console handover on ath79

On Tue, 22 Mar 2016 00:02:57 +0100 Matthias Schiffer wrote: > Hi, > we're experiencing weird nondeterministic hangs during bootconsole/console > handover on some ath79 systems on OpenWrt. I've seen this issue myself on > kernel 3.18.23~3.18.27 on a AR7241-based

Re: Nonterministic hang during bootconsole/console handover on ath79

On Tue, 22 Mar 2016 00:02:57 +0100 Matthias Schiffer wrote: > Hi, > we're experiencing weird nondeterministic hangs during bootconsole/console > handover on some ath79 systems on OpenWrt. I've seen this issue myself on > kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other >

Re: [BUG] packet loss with PROVE_LOCKING, bisected to EDAC fix

On Mon, Mar 21, 2016 at 09:42:09PM +, Chris Bainbridge wrote: > Hi, > > I was testing something on an old server (Dell T105 opteron) and noticed > packet loss after updating the kernel from 3.10 to 4.5. The test was: > > On Dell run: iperf -s > On another system: iperf3 -c dell -u -b 20M -l

Re: [BUG] packet loss with PROVE_LOCKING, bisected to EDAC fix

On Mon, Mar 21, 2016 at 09:42:09PM +, Chris Bainbridge wrote: > Hi, > > I was testing something on an old server (Dell T105 opteron) and noticed > packet loss after updating the kernel from 3.10 to 4.5. The test was: > > On Dell run: iperf -s > On another system: iperf3 -c dell -u -b 20M -l

Re: [PATCH 31/71] exofs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros

On 03/20/2016 08:40 PM, Kirill A. Shutemov wrote: > PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago > with promise that one day it will be possible to implement page cache with > bigger chunks than PAGE_SIZE. > > This promise never materialized. And unlikely will. > >

Re: [PATCH 31/71] exofs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros

On 03/20/2016 08:40 PM, Kirill A. Shutemov wrote: > PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago > with promise that one day it will be possible to implement page cache with > bigger chunks than PAGE_SIZE. > > This promise never materialized. And unlikely will. > >

RE: [f2fs-dev] [PATCH v2] f2fs: fix to convert inline directory correctly

Ping, Any problem in this patch? Thanks, > -Original Message- > From: Chao Yu [mailto:chao2...@samsung.com] > Sent: Monday, February 22, 2016 6:29 PM > To: Jaegeuk Kim > Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net > Subject: [f2fs-dev] [PATCH v2] f2fs: fix

RE: [f2fs-dev] [PATCH v2] f2fs: fix to convert inline directory correctly

Ping, Any problem in this patch? Thanks, > -Original Message- > From: Chao Yu [mailto:chao2...@samsung.com] > Sent: Monday, February 22, 2016 6:29 PM > To: Jaegeuk Kim > Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net > Subject: [f2fs-dev] [PATCH v2] f2fs: fix

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

> -Original Message- > From: Mathias Nyman [mailto:mathias.ny...@intel.com] > Sent: Monday, March 21, 2016 2:46 PM > To: Rajesh Bhagat ; Mathias Nyman > ; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc:

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

> -Original Message- > From: Mathias Nyman [mailto:mathias.ny...@intel.com] > Sent: Monday, March 21, 2016 2:46 PM > To: Rajesh Bhagat ; Mathias Nyman > ; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: gre...@linuxfoundation.org; Sriram Dash > Subject: Re: [PATCH] usb:

Re: Build error due to commit 458aa76d132dc ("mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range")

Guenter Roeck writes: > [ text/plain ] > Hi, > > Your commit 458aa76d132dc1 ("mm/thp/migration: switch from flush_tlb_range > to flush_pmd_tlb_range") causes a build error when building > arcv2:vdk_hs38_smp_defconfig. > > include/asm-generic/pgtable.h:799:45: note: in

Re: Build error due to commit 458aa76d132dc ("mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range")

Guenter Roeck writes: > [ text/plain ] > Hi, > > Your commit 458aa76d132dc1 ("mm/thp/migration: switch from flush_tlb_range > to flush_pmd_tlb_range") causes a build error when building > arcv2:vdk_hs38_smp_defconfig. > > include/asm-generic/pgtable.h:799:45: note: in expansion of macro

Re: [PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.

On Tue, 2016-03-15 at 13:17 +0700, Viresh Kumar wrote: > On 15-03-16, 12:53, dawei chien wrote: > > On Thu, 2015-12-17 at 09:52 +0800, Viresh Kumar wrote: > > > On 16-12-15, 21:29, Dawei Chien wrote: > > > > Use Intelligent Power Allocation (IPA) technical to add dynamic power > > > > model > > >

Re: [PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.

On Tue, 2016-03-15 at 13:17 +0700, Viresh Kumar wrote: > On 15-03-16, 12:53, dawei chien wrote: > > On Thu, 2015-12-17 at 09:52 +0800, Viresh Kumar wrote: > > > On 16-12-15, 21:29, Dawei Chien wrote: > > > > Use Intelligent Power Allocation (IPA) technical to add dynamic power > > > > model > > >

Re: [PATCH] zram: revive swap_slot_free_notify

On Fri, Mar 18, 2016 at 04:58:31PM +0900, Minchan Kim wrote: > "remove compressed copy from zram in-memory" > applied swap_slot_free_notify call in *end_swap_bio_read* to > remove duplicated memory between zram and memory. > > However, with introducing rw_page in zram <8c7f01025f7b> > "zram:

Re: [PATCH] zram: revive swap_slot_free_notify

On Fri, Mar 18, 2016 at 04:58:31PM +0900, Minchan Kim wrote: > "remove compressed copy from zram in-memory" > applied swap_slot_free_notify call in *end_swap_bio_read* to > remove duplicated memory between zram and memory. > > However, with introducing rw_page in zram <8c7f01025f7b> > "zram:

Re: [PATCH 1/6] mm/page_alloc: fix same zone check in __pageblock_pfn_to_page()

On Mon, Mar 21, 2016 at 11:37:19AM +, Mel Gorman wrote: > On Mon, Mar 14, 2016 at 04:31:32PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > There is a system that node's pfn are overlapped like as following. > > > > -pfn> > > N0 N1 N2 N0 N1

Re: [PATCH 1/6] mm/page_alloc: fix same zone check in __pageblock_pfn_to_page()

On Mon, Mar 21, 2016 at 11:37:19AM +, Mel Gorman wrote: > On Mon, Mar 14, 2016 at 04:31:32PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > There is a system that node's pfn are overlapped like as following. > > > > -pfn> > > N0 N1 N2 N0 N1 N2 > > > > Therefore,

Re: [PATCH RESEND v2 00/14] lib/mpi: bug fixes and cleanup

Hi Nicolai, On 03/21/2016 06:26 AM, Nicolai Stange wrote: > This is a resend of v2 with the crypto people properly CC'd. > > The original v1 can be found here: > > > http://lkml.kernel.org/g/1458237606-4954-1-git-send-email-nicsta...@gmail.com > > > While v1 (hopefully) fixed some issues in

Re: [PATCH RESEND v2 00/14] lib/mpi: bug fixes and cleanup

Hi Nicolai, On 03/21/2016 06:26 AM, Nicolai Stange wrote: > This is a resend of v2 with the crypto people properly CC'd. > > The original v1 can be found here: > > > http://lkml.kernel.org/g/1458237606-4954-1-git-send-email-nicsta...@gmail.com > > > While v1 (hopefully) fixed some issues in

Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update

On Tue, 2016-03-22 at 08:21 +0530, Viresh Kumar wrote: > On 22-03-16, 01:17, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Modify dbs_irq_work() to always schedule the process-context work > > on the current CPU which also ran the

Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update

On Tue, 2016-03-22 at 08:21 +0530, Viresh Kumar wrote: > On 22-03-16, 01:17, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Modify dbs_irq_work() to always schedule the process-context work > > on the current CPU which also ran the dbs_update_util_handler() > > that the irq_work

[PATCH] tpm: drop int_queue from tpm_vendor_specific

Drop field int_queue from tpm_vendor_specific as it is used only by tpm_tis. Probably all of the fields should be eventually dropped and moved to the private structures of different drivers but it is better to do this one step at a time in order not to break anything. Signed-off-by: Jarkko

[PATCH] tpm: drop int_queue from tpm_vendor_specific

Drop field int_queue from tpm_vendor_specific as it is used only by tpm_tis. Probably all of the fields should be eventually dropped and moved to the private structures of different drivers but it is better to do this one step at a time in order not to break anything. Signed-off-by: Jarkko

Re: [PATCH v2] mwifiex: advertise low priority scan feature

Tested-by: Wei-Ning Huang On Tue, Mar 22, 2016 at 12:09 PM, Wei-Ning Huang wrote: > From: Amitkumar Karwar > > Low priority scan handling code which delays or aborts scan > operation based on Tx traffic is removed recently. The

Re: [PATCH v2] mwifiex: advertise low priority scan feature

Tested-by: Wei-Ning Huang On Tue, Mar 22, 2016 at 12:09 PM, Wei-Ning Huang wrote: > From: Amitkumar Karwar > > Low priority scan handling code which delays or aborts scan > operation based on Tx traffic is removed recently. The reason > is firmware already takes care of it in our new feature

Re: [PATCH] mwifiex: advertise low priority scan feature

Hi Kalle, Thanks for the review. I accidentally removed the s-o-b line from akarwar in this version. The original patch can be found at: https://chromium-review.googlesource.com/#/c/246052/ I've resent a new one. Wei-Ning On Mon, Mar 21, 2016 at 6:28 PM, Kalle Valo wrote:

Re: [PATCH] mwifiex: advertise low priority scan feature

Hi Kalle, Thanks for the review. I accidentally removed the s-o-b line from akarwar in this version. The original patch can be found at: https://chromium-review.googlesource.com/#/c/246052/ I've resent a new one. Wei-Ning On Mon, Mar 21, 2016 at 6:28 PM, Kalle Valo wrote: > Wei-Ning Huang

[PATCH v2] mwifiex: advertise low priority scan feature

From: Amitkumar Karwar Low priority scan handling code which delays or aborts scan operation based on Tx traffic is removed recently. The reason is firmware already takes care of it in our new feature scan channel gap. Hence we should advertise low priority scan support to

[PATCH v2] mwifiex: advertise low priority scan feature

From: Amitkumar Karwar Low priority scan handling code which delays or aborts scan operation based on Tx traffic is removed recently. The reason is firmware already takes care of it in our new feature scan channel gap. Hence we should advertise low priority scan support to cfg80211. This patch

[PATCH] media: au0828 fix au0828_v4l2_close() dev_state race condition

au0828_v4l2_close() check for dev_state == DEV_DISCONNECTED will fail to detect the device disconnected state correctly, if au0828_v4l2_open() runs to set the DEV_INITIALIZED bit. A loop test of bind/unbind found this bug by increasing the likelihood of au0828_v4l2_open() occurring while unbind is

[PATCH] media: au0828 fix au0828_v4l2_close() dev_state race condition

au0828_v4l2_close() check for dev_state == DEV_DISCONNECTED will fail to detect the device disconnected state correctly, if au0828_v4l2_open() runs to set the DEV_INITIALIZED bit. A loop test of bind/unbind found this bug by increasing the likelihood of au0828_v4l2_open() occurring while unbind is

Re: [PATCH] sound/usb: fix to release stream resources from media_snd_device_delete()

On 03/19/2016 07:31 AM, Shuah Khan wrote: > On 03/19/2016 06:10 AM, Mauro Carvalho Chehab wrote: >> Em Fri, 18 Mar 2016 20:50:31 -0600 >> Shuah Khan escreveu: >> >>> Fix to release stream resources from media_snd_device_delete() before >>> media device is unregistered.

Re: [PATCH] sound/usb: fix to release stream resources from media_snd_device_delete()

On 03/19/2016 07:31 AM, Shuah Khan wrote: > On 03/19/2016 06:10 AM, Mauro Carvalho Chehab wrote: >> Em Fri, 18 Mar 2016 20:50:31 -0600 >> Shuah Khan escreveu: >> >>> Fix to release stream resources from media_snd_device_delete() before >>> media device is unregistered. Without this change, stream

Re: [PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU

On 03/22/2016 10:41 AM, Rob Herring wrote: On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot wrote: On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring wrote: On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote: GM20B's definition is mostly similar

Re: [PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU

On 03/22/2016 10:41 AM, Rob Herring wrote: On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot wrote: On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring wrote: On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote: GM20B's definition is mostly similar to GK20A's, but requires an

RE: [f2fs-dev] [PATCH 1/2] f2fs: cover large section in sanity check of super

Hi Jaegeuk, > -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Tuesday, March 22, 2016 2:56 AM > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Cc: Jaegeuk Kim; stable 4 . 5+ > Subject: [f2fs-dev]

RE: [f2fs-dev] [PATCH 1/2] f2fs: cover large section in sanity check of super

Hi Jaegeuk, > -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Tuesday, March 22, 2016 2:56 AM > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Cc: Jaegeuk Kim; stable 4 . 5+ > Subject: [f2fs-dev]

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

Shawn, On Mon, Mar 21, 2016 at 7:53 PM, Shawn Lin wrote: > + Vinod > > > On 2016/3/22 10:33, Doug Anderson wrote: >> >> Shawn, >> >> On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin >> wrote: ...but, looking at this, presumably before

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

Shawn, On Mon, Mar 21, 2016 at 7:53 PM, Shawn Lin wrote: > + Vinod > > > On 2016/3/22 10:33, Doug Anderson wrote: >> >> Shawn, >> >> On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin >> wrote: ...but, looking at this, presumably before landing any patch that made

Re: [PATCH 3/3] cpufreq: Always update current frequency before startig governor

On 21-03-16, 15:47, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Make policy->cur match the current frequency returned by the driver's > ->get() callback before starting the governor in case they went out of > sync in the meantime and drop the piece of code

Re: [PATCH 3/3] cpufreq: Always update current frequency before startig governor

On 21-03-16, 15:47, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Make policy->cur match the current frequency returned by the driver's > ->get() callback before starting the governor in case they went out of > sync in the meantime and drop the piece of code attempting to > resync

linux-next: Tree for Mar 22

Hi all, Please do not add any v4.7 related material to your linux-next included trees until after v4.6-rc1 is released. Changes since 20160321: The arm64 tree gained a conflict against Linus' tree. The rdma tree gained conflicts against Linus' tree. The drm tree lost its build failure. Non

linux-next: Tree for Mar 22

Hi all, Please do not add any v4.7 related material to your linux-next included trees until after v4.6-rc1 is released. Changes since 20160321: The arm64 tree gained a conflict against Linus' tree. The rdma tree gained conflicts against Linus' tree. The drm tree lost its build failure. Non

Re: [PATCH v2 0/4] locking/mutex: Enable optimistic spinning of lock waiter

On 02/16/2016 03:51 AM, Peter Zijlstra wrote: On Fri, Feb 12, 2016 at 12:32:11PM -0500, Waiman Long wrote: My own test on a 4-socket E7-4820 v3 system showed a regression of about 4% in the high_systime workload with Peter's patch which this new patch effectively eliminates. Testing on an

Re: [PATCH v2 0/4] locking/mutex: Enable optimistic spinning of lock waiter

On 02/16/2016 03:51 AM, Peter Zijlstra wrote: On Fri, Feb 12, 2016 at 12:32:11PM -0500, Waiman Long wrote: My own test on a 4-socket E7-4820 v3 system showed a regression of about 4% in the high_systime workload with Peter's patch which this new patch effectively eliminates. Testing on an

[PATCH v3 1/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

1.For coherent DMA In swiotlb_alloc_coherent, it directly return vaddr on success, and pass vaddr to free_pages on failure. So, we can directly transparent pass vaddr from __dma_free to swiotlb_free_coherent. According to my testing, it can save 8 clock cycles. 2.For non-coherent DMA. Keep

[PATCH v3 1/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

1.For coherent DMA In swiotlb_alloc_coherent, it directly return vaddr on success, and pass vaddr to free_pages on failure. So, we can directly transparent pass vaddr from __dma_free to swiotlb_free_coherent. According to my testing, it can save 8 clock cycles. 2.For non-coherent DMA. Keep

[PATCH v3 0/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

Changelog: v2 -> v3: 1. Just add some description for this patch. v1 -> v2: 1. Give up removing the conversion, because of thoughtless, instead moved it into branch if (!is_device_dma_coherent(dev)). Thanks for Catalin's detailed explanation, I directly take some relies as comment in the code.

[PATCH v3 0/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA

Changelog: v2 -> v3: 1. Just add some description for this patch. v1 -> v2: 1. Give up removing the conversion, because of thoughtless, instead moved it into branch if (!is_device_dma_coherent(dev)). Thanks for Catalin's detailed explanation, I directly take some relies as comment in the code.

Re: [PATCH 2/3] cpufreq: Introduce cpufreq_update_current_freq()

On 21-03-16, 15:46, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Move the part of cpufreq_update_policy() that obtains the current > frequency from the driver and updates policy->cur if necessary to > a separate function, cpufreq_get_current_freq(). > >

Re: [PATCH 2/3] cpufreq: Introduce cpufreq_update_current_freq()

On 21-03-16, 15:46, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Move the part of cpufreq_update_policy() that obtains the current > frequency from the driver and updates policy->cur if necessary to > a separate function, cpufreq_get_current_freq(). > > That should not introduce

Re: [PATCH 1/3] cpufreq: Introduce cpufreq_start_governor()

On 21-03-16, 15:45, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Starting a governor in cpufreq always follows the same pattern > involving two calls to cpufreq_governor(), one with the event > argument set to CPUFREQ_GOV_START and one with that argument set

Re: [PATCH 1/3] cpufreq: Introduce cpufreq_start_governor()

On 21-03-16, 15:45, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Starting a governor in cpufreq always follows the same pattern > involving two calls to cpufreq_governor(), one with the event > argument set to CPUFREQ_GOV_START and one with that argument set to > CPUFREQ_GOV_LIMITS. >

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

在 2016/3/21 18:29, Thomas Gleixner 写道: > On Thu, 17 Mar 2016, MaJun wrote: >> This patch set is used to fix the problem of remap a set of registers >> repeatedly in current mbigen driver. >> >> irqchip/mbigen:Change the mbigen node definition in dt binding file >> irqchip/mbigen:Change the

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

在 2016/3/21 18:29, Thomas Gleixner 写道: > On Thu, 17 Mar 2016, MaJun wrote: >> This patch set is used to fix the problem of remap a set of registers >> repeatedly in current mbigen driver. >> >> irqchip/mbigen:Change the mbigen node definition in dt binding file >> irqchip/mbigen:Change the

Linux 3.4.111

I'm announcing the release of the 3.4.111 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser:

Linux 3.4.111

I'm announcing the release of the 3.4.111 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser:

[lkp] [cpuidle] b67bb65b9d: No primary result change, -33.1% turbostat.%Busy

30cca6c6790a7/0" job_file: "/lkp/scheduled/lkp-hsx04/bisect_vm-scalability-performance-300s-1T-msync-mt-debian-x86_64-2015-02-07.cgz-x86_64-rhel-b67bb65b9de2d3c070073028aeb30cca6c6790a7-20160321-79544-wxo1vq-0.yaml" max_uptime: 1500 initrd: "/osimage/debian/debian-x86_64-2015-0

[lkp] [cpuidle] b67bb65b9d: No primary result change, -33.1% turbostat.%Busy

30cca6c6790a7/0" job_file: "/lkp/scheduled/lkp-hsx04/bisect_vm-scalability-performance-300s-1T-msync-mt-debian-x86_64-2015-02-07.cgz-x86_64-rhel-b67bb65b9de2d3c070073028aeb30cca6c6790a7-20160321-79544-wxo1vq-0.yaml" max_uptime: 1500 initrd: "/osimage/debian/debian-x86_64-2015-0

Re: [PATCH v2] net: add missing descriptions in net_device_priv_flags

From: Luis de Bethencourt Date: Mon, 21 Mar 2016 20:58:28 + > The flags IFF_XMIT_DST_RELEASE_PERM, IFF_IPVLAN_MASTER and > IFF_IPVLAN_SLAVE are missing descriptions for the Documentation. Adding > them. > > Signed-off-by: Luis de Bethencourt

Re: [PATCH v2] net: add missing descriptions in net_device_priv_flags

From: Luis de Bethencourt Date: Mon, 21 Mar 2016 20:58:28 + > The flags IFF_XMIT_DST_RELEASE_PERM, IFF_IPVLAN_MASTER and > IFF_IPVLAN_SLAVE are missing descriptions for the Documentation. Adding > them. > > Signed-off-by: Luis de Bethencourt > Suggested-by: Benjamin Poirier Applied.

arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (240) for 'rur240'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 968f3e374faf41e5e6049399eb7302777a09a1e8 commit: 2c684d892bb2ee31cc48f4a8b91e86a0f15e82f9 xtensa: add Three Core HiFi-2 MX Variant. date: 4 days ago config: xtensa-smp_lx200_defconfig (attached as

arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (240) for 'rur240'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 968f3e374faf41e5e6049399eb7302777a09a1e8 commit: 2c684d892bb2ee31cc48f4a8b91e86a0f15e82f9 xtensa: add Three Core HiFi-2 MX Variant. date: 4 days ago config: xtensa-smp_lx200_defconfig (attached as

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

+ Vinod On 2016/3/22 10:33, Doug Anderson wrote: Shawn, On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin wrote: ...but, looking at this, presumably before landing any patch that made dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify _all_ users of

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

+ Vinod On 2016/3/22 10:33, Doug Anderson wrote: Shawn, On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin wrote: ...but, looking at this, presumably before landing any patch that made dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify _all_ users of dma_request_slave_channel to

Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update

On 22-03-16, 01:17, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Modify dbs_irq_work() to always schedule the process-context work > on the current CPU which also ran the dbs_update_util_handler() > that the irq_work being handled came from. > > This causes

Re: Nonterministic hang during bootconsole/console handover on ath79

On 03/21/2016 05:52 PM, Matthias Schiffer wrote: > On 03/22/2016 12:08 AM, Greg KH wrote: >> On Tue, Mar 22, 2016 at 12:02:57AM +0100, Matthias Schiffer wrote: >>> Hi, >>> we're experiencing weird nondeterministic hangs during bootconsole/console >>> handover on some ath79 systems on OpenWrt. I've

[lkp] [drm/i915] 97f9010af0: No primary result change, -36.2% piglit.time.percent_of_cpu_this_job_got

FYI, we noticed that piglit.time.percent_of_cpu_this_job_got -36.2% change with your commit. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715 ("drm/i915: mdelay(10) considered harmful")

Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update

On 22-03-16, 01:17, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Modify dbs_irq_work() to always schedule the process-context work > on the current CPU which also ran the dbs_update_util_handler() > that the irq_work being handled came from. > > This causes the entire frequency update

Re: Nonterministic hang during bootconsole/console handover on ath79

On 03/21/2016 05:52 PM, Matthias Schiffer wrote: > On 03/22/2016 12:08 AM, Greg KH wrote: >> On Tue, Mar 22, 2016 at 12:02:57AM +0100, Matthias Schiffer wrote: >>> Hi, >>> we're experiencing weird nondeterministic hangs during bootconsole/console >>> handover on some ath79 systems on OpenWrt. I've

[lkp] [drm/i915] 97f9010af0: No primary result change, -36.2% piglit.time.percent_of_cpu_this_job_got

FYI, we noticed that piglit.time.percent_of_cpu_this_job_got -36.2% change with your commit. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715 ("drm/i915: mdelay(10) considered harmful")

Re: [PATCH v11] cpufreq: powernv: Add sysfs attributes to show throttle stats

On 21-03-16, 22:29, Shilpasri G Bhat wrote: > + create_throttle_sysfs = kcalloc(cpu_nr_cores(), sizeof(bool), > + GFP_KERNEL); > + if (!create_throttle_sysfs) { > + kfree(chips); > + return -ENOMEM; > + } > + > for (i =

Re: [PATCH v11] cpufreq: powernv: Add sysfs attributes to show throttle stats

On 21-03-16, 22:29, Shilpasri G Bhat wrote: > + create_throttle_sysfs = kcalloc(cpu_nr_cores(), sizeof(bool), > + GFP_KERNEL); > + if (!create_throttle_sysfs) { > + kfree(chips); > + return -ENOMEM; > + } > + > for (i =

Re: Nonterministic hang during bootconsole/console handover on ath79

Hi Matthias, On 03/21/2016 04:02 PM, Matthias Schiffer wrote: > Hi, > we're experiencing weird nondeterministic hangs during bootconsole/console > handover on some ath79 systems on OpenWrt. I've seen this issue myself on > kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other >

Re: Nonterministic hang during bootconsole/console handover on ath79

Hi Matthias, On 03/21/2016 04:02 PM, Matthias Schiffer wrote: > Hi, > we're experiencing weird nondeterministic hangs during bootconsole/console > handover on some ath79 systems on OpenWrt. I've seen this issue myself on > kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other >

Re: [GIT PULL] Btrfs

On Mon, Mar 21, 2016 at 7:24 PM, Chris Mason wrote: > > Hmmm, rereading my answer I realized I didn't actually answer. I really > think this is fixed. I left the warning only because I originally > expected something much more exotic. Ok. It's more that you said the top commit

Re: [GIT PULL] Btrfs

On Mon, Mar 21, 2016 at 7:24 PM, Chris Mason wrote: > > Hmmm, rereading my answer I realized I didn't actually answer. I really > think this is fixed. I left the warning only because I originally > expected something much more exotic. Ok. It's more that you said the top commit fixes a problem,

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

Shawn, On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin wrote: >> ...but, looking at this, presumably before landing any patch that made >> dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify >> _all_ users of dma_request_slave_channel to handle error

Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER

Shawn, On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin wrote: >> ...but, looking at this, presumably before landing any patch that made >> dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify >> _all_ users of dma_request_slave_channel to handle error pointers >> being returned.

Re: [PATCH v6 1/4] lib/percpu-list: Per-cpu list with associated per-cpu locks

On 03/21/2016 05:49 AM, Jan Kara wrote: On Fri 18-03-16 15:44:01, Waiman Long wrote: +static __always_inline bool +__pcpu_list_next_cpu(struct pcpu_list_head *head, struct pcpu_list_state *state) +{ + if (state->lock) + spin_unlock(state->lock); +next_cpu: + /* +

Re: [PATCH v6 1/4] lib/percpu-list: Per-cpu list with associated per-cpu locks

On 03/21/2016 05:49 AM, Jan Kara wrote: On Fri 18-03-16 15:44:01, Waiman Long wrote: +static __always_inline bool +__pcpu_list_next_cpu(struct pcpu_list_head *head, struct pcpu_list_state *state) +{ + if (state->lock) + spin_unlock(state->lock); +next_cpu: + /* +

Re: [PATCH] staging: rts5208: coding style clean-ups

On Tue, Mar 22, 2016 at 07:45:25AM +0530, Sohom Bhattacharjee wrote: > On Mon, Mar 21, 2016 at 05:29:24PM -0400, Greg KH wrote: > > On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote: > > > fixed *only* comments that did not follow kernel coding style. > > > the errors were caught

Re: [PATCH] staging: rts5208: coding style clean-ups

On Tue, Mar 22, 2016 at 07:45:25AM +0530, Sohom Bhattacharjee wrote: > On Mon, Mar 21, 2016 at 05:29:24PM -0400, Greg KH wrote: > > On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote: > > > fixed *only* comments that did not follow kernel coding style. > > > the errors were caught

Re: [GIT PULL] Btrfs

On Mon, Mar 21, 2016 at 10:15:33PM -0400, Chris Mason wrote: > On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote: > > On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason wrote: > > > > > > I waited an extra day to send this one out because I hit a crash late > > > last week

Re: [GIT PULL] Btrfs

On Mon, Mar 21, 2016 at 10:15:33PM -0400, Chris Mason wrote: > On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote: > > On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason wrote: > > > > > > I waited an extra day to send this one out because I hit a crash late > > > last week with

Re: [PATCH] zsmalloc: fix semicolon.cocci warnings

On Mon, Mar 21, 2016 at 05:48:25PM +0800, kbuild test robot wrote: > mm/zsmalloc.c:1103:2-3: Unneeded semicolon > > > Remove unneeded semicolon. > > Generated by: scripts/coccinelle/misc/semicolon.cocci > > CC: Minchan Kim > Signed-off-by: Fengguang Wu

Re: [PATCH] zsmalloc: fix semicolon.cocci warnings

On Mon, Mar 21, 2016 at 05:48:25PM +0800, kbuild test robot wrote: > mm/zsmalloc.c:1103:2-3: Unneeded semicolon > > > Remove unneeded semicolon. > > Generated by: scripts/coccinelle/misc/semicolon.cocci > > CC: Minchan Kim > Signed-off-by: Fengguang Wu > --- > > zsmalloc.c |2 +- > 1

Re: [PATCH] locking/qrwlock: Allow multiple spinning readers

On 03/20/2016 06:43 AM, Peter Zijlstra wrote: We still have that starvation case in mutex, I would think that is far more important to fix. Peter, I am sorry that I let the mutex patch languish for a while. I will work on that next. Cheers, Longman

Re: [PATCH] locking/qrwlock: Allow multiple spinning readers

On 03/20/2016 06:43 AM, Peter Zijlstra wrote: We still have that starvation case in mutex, I would think that is far more important to fix. Peter, I am sorry that I let the mutex patch languish for a while. I will work on that next. Cheers, Longman

Re: [PATCH v2 14/18] mm/balloon: use general movable page feature into balloon

e system] > > url: > https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339 > config: x86_64-randconfig-x000-201612 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=x8

Re: [PATCH v2 14/18] mm/balloon: use general movable page feature into balloon

e system] > > url: > https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339 > config: x86_64-randconfig-x000-201612 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=x8

Re: [PATCH] x86: Avoid undefined behavior in macro expansion

On Fri, Mar 18, 2016 at 11:15 PM, Al Viro wrote: > On Wed, Mar 16, 2016 at 11:48:49PM -0300, Vinicius Tinti wrote: >> C11 standard (at 6.10.3.3) says that ## operator (paste) has undefined >> behavior when one of the result operands is not a valid preprocessing >> token.

Re: [PATCH] x86: Avoid undefined behavior in macro expansion

On Fri, Mar 18, 2016 at 11:15 PM, Al Viro wrote: > On Wed, Mar 16, 2016 at 11:48:49PM -0300, Vinicius Tinti wrote: >> C11 standard (at 6.10.3.3) says that ## operator (paste) has undefined >> behavior when one of the result operands is not a valid preprocessing >> token. >> >> Therefore the macro

Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

On Tue, Mar 22, 2016 at 02:11:05AM +0900, Sergey Senozhatsky wrote: > On (03/21/16 16:33), Jan Kara wrote: > [..] > > > > And by calling wake_up_process() under logbuf_lock, you actually > > > > introduce > > > > recursion issues for printk_deferred() messages which are supposed to be > > > >

Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async

On Tue, Mar 22, 2016 at 02:11:05AM +0900, Sergey Senozhatsky wrote: > On (03/21/16 16:33), Jan Kara wrote: > [..] > > > > And by calling wake_up_process() under logbuf_lock, you actually > > > > introduce > > > > recursion issues for printk_deferred() messages which are supposed to be > > > >

  1   2   3   4   5   6   7   8   9   10   >