[PATCH] powerpc/64: get rid of MIN_HUGEPTE_SHIFT

MIN_HUGEPTE_SHIFT hasn't been used since commit d1837cba5d5d5 ("powerpc/mm: Cleanup initialization of hugepages on powerpc") Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/book3s/64/hash-4k.h | 3 --- arch/powerpc/include/asm/book3s/64/hash-64k.h|

[PATCH] powerpc/64: get rid of MIN_HUGEPTE_SHIFT

MIN_HUGEPTE_SHIFT hasn't been used since commit d1837cba5d5d5 ("powerpc/mm: Cleanup initialization of hugepages on powerpc") Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/book3s/64/hash-4k.h | 3 --- arch/powerpc/include/asm/book3s/64/hash-64k.h| 3 ---

Re: [PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc

Reza Arbab writes: > On Wed, Sep 21, 2016 at 12:39:51PM +0530, Aneesh Kumar K.V wrote: >>What I was checking was how will one mark a node movable in ppc64 ? I >>don't see ppc64 code doing the equivalent of memblock_mark_hotplug(). > > Post boot, the marking mechanism is

Re: [PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc

Reza Arbab writes: > On Wed, Sep 21, 2016 at 12:39:51PM +0530, Aneesh Kumar K.V wrote: >>What I was checking was how will one mark a node movable in ppc64 ? I >>don't see ppc64 code doing the equivalent of memblock_mark_hotplug(). > > Post boot, the marking mechanism is not necessary. You can

Re: [PATCH v2 02/46] mtd: nand: Provide nand_cleanup() function to free NAND related resources

On Wed, 21 Sep 2016 16:38:28 +0200 Daniel Walter wrote: > Boris, > > On 09/21/2016 04:25 PM, Boris Brezillon wrote: > > Daniel, Richard, > > > > On Wed, 21 Sep 2016 11:44:41 +0200 > > Daniel Walter wrote: > > > >> From: Richard Weinberger

Re: [PATCH v2 02/46] mtd: nand: Provide nand_cleanup() function to free NAND related resources

On Wed, 21 Sep 2016 16:38:28 +0200 Daniel Walter wrote: > Boris, > > On 09/21/2016 04:25 PM, Boris Brezillon wrote: > > Daniel, Richard, > > > > On Wed, 21 Sep 2016 11:44:41 +0200 > > Daniel Walter wrote: > > > >> From: Richard Weinberger > >> > >> Provide a nand_cleanup() function to

Re: [PATCH] ovl: Fix info leak in ovl_lookup_temp()

On Fri, Sep 16, 2016 at 10:36 PM, Kees Cook wrote: > On Fri, Sep 16, 2016 at 2:45 AM, Richard Weinberger wrote: >> The function uses the memory address of a struct dentry as unique id. >> While the address-based directory entry is only visible to root >> it

Re: [PATCH] ovl: Fix info leak in ovl_lookup_temp()

On Fri, Sep 16, 2016 at 10:36 PM, Kees Cook wrote: > On Fri, Sep 16, 2016 at 2:45 AM, Richard Weinberger wrote: >> The function uses the memory address of a struct dentry as unique id. >> While the address-based directory entry is only visible to root >> it is IMHO still worth fixing since the

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

Hi Geert, On 21/09/16 09:53, Geert Uytterhoeven wrote: > Hi Jon, > > On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter wrote: >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

Hi Geert, On 21/09/16 09:53, Geert Uytterhoeven wrote: > Hi Jon, > > On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter wrote: >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux >> 'device' structure

Re: [PATCH v2] clocksource/fsl: Fix errata A-007728 for flextimer

On Sun, Sep 18, 2016 at 02:46:01PM +0800, Meng Yi wrote: > If the FTM counter reaches the FTM_MOD value between the reading of the > TOF bit and the writing of 0 to the TOF bit, the process of clearing the > TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the > current TOF count

Re: [PATCH v2] clocksource/fsl: Fix errata A-007728 for flextimer

On Sun, Sep 18, 2016 at 02:46:01PM +0800, Meng Yi wrote: > If the FTM counter reaches the FTM_MOD value between the reading of the > TOF bit and the writing of 0 to the TOF bit, the process of clearing the > TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the > current TOF count

Re: dm crypt: fix crash on exit

On Wed, Sep 21 2016 at 10:22am -0400, Rabin Vincent wrote: > From: Rabin Vincent > > As the documentation for kthread_stop() says, "if threadfn() may call > do_exit() itself, the caller must ensure task_struct can't go away". > dm-crypt does not ensure

Re: dm crypt: fix crash on exit

On Wed, Sep 21 2016 at 10:22am -0400, Rabin Vincent wrote: > From: Rabin Vincent > > As the documentation for kthread_stop() says, "if threadfn() may call > do_exit() itself, the caller must ensure task_struct can't go away". > dm-crypt does not ensure this and therefore crashes when

Re: [PATCH v2 03/46] mtd: Don't unconditionally unregister reboot notifier

On 09/21/2016 04:31 PM, Boris Brezillon wrote: > On Wed, 21 Sep 2016 11:45:12 +0200 > Daniel Walter wrote: > >> From: Richard Weinberger >> >> del_mtd_device() is allowed to fail. >> i.e. when the MTD is busy. >> Unregister the reboot notifier only when

Re: [PATCH v2 03/46] mtd: Don't unconditionally unregister reboot notifier

On 09/21/2016 04:31 PM, Boris Brezillon wrote: > On Wed, 21 Sep 2016 11:45:12 +0200 > Daniel Walter wrote: > >> From: Richard Weinberger >> >> del_mtd_device() is allowed to fail. >> i.e. when the MTD is busy. >> Unregister the reboot notifier only when we're really >> about to delete the MTD.

Re: Address already in use problem

Hi we are using redhat 2.6.32-642.4.2.el6.x86_64 On Wed, Sep 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner wrote: > Hi, > > On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: >> Hi >> >> we have an SCTP application running in JAVA. and we found that there >> is

Re: Address already in use problem

Hi we are using redhat 2.6.32-642.4.2.el6.x86_64 On Wed, Sep 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner wrote: > Hi, > > On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: >> Hi >> >> we have an SCTP application running in JAVA. and we found that there >> is a problem when we as a

[PATCH] dm crypt: fix crash on exit

From: Rabin Vincent As the documentation for kthread_stop() says, "if threadfn() may call do_exit() itself, the caller must ensure task_struct can't go away". dm-crypt does not ensure this and therefore crashes when crypt_dtr() calls kthread_stop(). The crash is trivially

[PATCH] dm crypt: fix crash on exit

From: Rabin Vincent As the documentation for kthread_stop() says, "if threadfn() may call do_exit() itself, the caller must ensure task_struct can't go away". dm-crypt does not ensure this and therefore crashes when crypt_dtr() calls kthread_stop(). The crash is trivially reproducible by adding

Re: [PATCH v2 03/46] mtd: Don't unconditionally unregister reboot notifier

On Wed, 21 Sep 2016 11:45:12 +0200 Daniel Walter wrote: > From: Richard Weinberger > > del_mtd_device() is allowed to fail. > i.e. when the MTD is busy. > Unregister the reboot notifier only when we're really > about to delete the MTD. > > Signed-off-by:

Re: [PATCH v2 03/46] mtd: Don't unconditionally unregister reboot notifier

On Wed, 21 Sep 2016 11:45:12 +0200 Daniel Walter wrote: > From: Richard Weinberger > > del_mtd_device() is allowed to fail. > i.e. when the MTD is busy. > Unregister the reboot notifier only when we're really > about to delete the MTD. > > Signed-off-by: Richard Weinberger > --- >

Re: [PATCH] percpu: improve generic percpu modify-return implementation

Hello, Nick. How have you been? :) On Wed, Sep 21, 2016 at 08:57:11PM +1000, Nicholas Piggin wrote: > On Wed, 21 Sep 2016 18:51:37 +1000 > Nicholas Piggin wrote: > > > Some architectures require an additional load to find the address of > > percpu pointers. In some

Re: [PATCH] percpu: improve generic percpu modify-return implementation

Hello, Nick. How have you been? :) On Wed, Sep 21, 2016 at 08:57:11PM +1000, Nicholas Piggin wrote: > On Wed, 21 Sep 2016 18:51:37 +1000 > Nicholas Piggin wrote: > > > Some architectures require an additional load to find the address of > > percpu pointers. In some implemenatations, the C

Re: Address already in use problem

On Wed, Sep 21, 2016 at 10:15:43PM +0800, Sun Paul wrote: > Hi > > we are using redhat 2.6.32-642.4.2.el6.x86_64 > > On Wed, Sep 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner > wrote: > > Hi, > > > > On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: > >> Hi >

Re: Address already in use problem

On Wed, Sep 21, 2016 at 10:15:43PM +0800, Sun Paul wrote: > Hi > > we are using redhat 2.6.32-642.4.2.el6.x86_64 > > On Wed, Sep 21, 2016 at 10:04 PM, Marcelo Ricardo Leitner > wrote: > > Hi, > > > > On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: > >> Hi > >> > >> we have an SCTP

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

Hello, Parav. On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote: > We have completed review from Tejun, Christoph. > HFI driver folks also provided feedback for Intel drivers. > Matan's also doesn't have any more comments. > > If possible, if you can also review, it will be helpful. >

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

Hello, Parav. On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote: > We have completed review from Tejun, Christoph. > HFI driver folks also provided feedback for Intel drivers. > Matan's also doesn't have any more comments. > > If possible, if you can also review, it will be helpful. >

Re: [PATCH v2 02/46] mtd: nand: Provide nand_cleanup() function to free NAND related resources

Daniel, Richard, On Wed, 21 Sep 2016 11:44:41 +0200 Daniel Walter wrote: > From: Richard Weinberger > > Provide a nand_cleanup() function to free all nand related resources > without unregistering the mtd device. > This should allow drivers to call

Re: [PATCH v2 02/46] mtd: nand: Provide nand_cleanup() function to free NAND related resources

Daniel, Richard, On Wed, 21 Sep 2016 11:44:41 +0200 Daniel Walter wrote: > From: Richard Weinberger > > Provide a nand_cleanup() function to free all nand related resources > without unregistering the mtd device. > This should allow drivers to call mtd_device_unregister() and handle > its

[PATCH] ARC: CONFIG_NODES_SHIFT fix default values

From: Noam Camus Seem like values assigned as absolute number and not and shift value, i.e. should be 0 for one node (2^0) and 1 for couple of nodes (2^1) Signed-off-by: Noam Camus --- arch/arc/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2

[PATCH] ARC: CONFIG_NODES_SHIFT fix default values

From: Noam Camus Seem like values assigned as absolute number and not and shift value, i.e. should be 0 for one node (2^0) and 1 for couple of nodes (2^1) Signed-off-by: Noam Camus --- arch/arc/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] power: max17040: Change register transaction length from 8 bits to 16 bits

According to the datasheet, MAX17040 has six 16-bit registers. Register reads and writes are only valid if all 16 bits are transferred. Any write command that is terminated early is ignored. So it's better to change register transacton length from 8 bits to 16 bits. Signed-off-by: Liu Xiang

[PATCH] power: max17040: Change register transaction length from 8 bits to 16 bits

According to the datasheet, MAX17040 has six 16-bit registers. Register reads and writes are only valid if all 16 bits are transferred. Any write command that is terminated early is ignored. So it's better to change register transacton length from 8 bits to 16 bits. Signed-off-by: Liu Xiang ---

Re: BUG: aio/direct-io data corruption in 4.7

Hi Jonathan, please keep linux-fsdevel on the Cc list for something like, and if you already track down a commit the author of that commit. > Description: "fs: simplify the generic_write_sync prototype" > Committed: Apr 7, 2016 > Hash: e259221763a40403d5bb232209998e8c45804ab8 > Affects: 4.7-rc1

Re: BUG: aio/direct-io data corruption in 4.7

Hi Jonathan, please keep linux-fsdevel on the Cc list for something like, and if you already track down a commit the author of that commit. > Description: "fs: simplify the generic_write_sync prototype" > Committed: Apr 7, 2016 > Hash: e259221763a40403d5bb232209998e8c45804ab8 > Affects: 4.7-rc1

Re: [GIT PULL 0/7] LightNVM pull request for 4.9

On 09/16/2016 06:25 AM, Matias Bjørling wrote: Hi Jens, A couple of patches for 4.9. We are preparing the pblk target for upstream, but it will have to wait for at least a cycle before it is ready. Geert and Arnd sent two fixes. One check for DMA and another for missing a device_add check.

Re: [GIT PULL 0/7] LightNVM pull request for 4.9

On 09/16/2016 06:25 AM, Matias Bjørling wrote: Hi Jens, A couple of patches for 4.9. We are preparing the pblk target for upstream, but it will have to wait for at least a cycle before it is ready. Geert and Arnd sent two fixes. One check for DMA and another for missing a device_add check.

Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1

On Wed, Sep 21, 2016 at 02:02:10PM +0100, Mark Rutland wrote: > > As for the drivers all living under drivers/greybus/ I understand, but > > we need the greybus core present first before we can get the drivers in. > > How about we do what happened with IIO, we take the greybus core code in > >

Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1

On Wed, Sep 21, 2016 at 02:02:10PM +0100, Mark Rutland wrote: > > As for the drivers all living under drivers/greybus/ I understand, but > > we need the greybus core present first before we can get the drivers in. > > How about we do what happened with IIO, we take the greybus core code in > >

Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote: > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote: [...] > > None of these platforms can be fixed entirely in software, and given > > that we will not be adding quirks for new broken hardware, we should > > ask

Re: [RFC v7 00/23] adapt clockevents frequencies to mono clock

Thomas Gleixner writes: > On Wed, 21 Sep 2016, Nicolai Stange wrote: >> Thomas Gleixner writes: >> > Have you ever measured the overhead of the extra work which has to be done >> > in clockevents_adjust_all_freqs() ? >> >> Not exactly, I had a look at

Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote: > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote: [...] > > None of these platforms can be fixed entirely in software, and given > > that we will not be adding quirks for new broken hardware, we should > > ask

Re: [RFC v7 00/23] adapt clockevents frequencies to mono clock

Thomas Gleixner writes: > On Wed, 21 Sep 2016, Nicolai Stange wrote: >> Thomas Gleixner writes: >> > Have you ever measured the overhead of the extra work which has to be done >> > in clockevents_adjust_all_freqs() ? >> >> Not exactly, I had a look at its invocation frequency which seems to >>

RE: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

Hi Bjorn [...] > > If future hardware is completely ECAM-compliant and we don't need any > more MCFG quirks, that would be great. > > But we'll still need to describe that memory-mapped config space > somewhere. If that's done with PNP0C02 or similar devices (as is done > on my x86 laptop),

RE: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

Hi Bjorn [...] > > If future hardware is completely ECAM-compliant and we don't need any > more MCFG quirks, that would be great. > > But we'll still need to describe that memory-mapped config space > somewhere. If that's done with PNP0C02 or similar devices (as is done > on my x86 laptop),

Re: [PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc

On Wed, Sep 21, 2016 at 12:39:51PM +0530, Aneesh Kumar K.V wrote: What I was checking was how will one mark a node movable in ppc64 ? I don't see ppc64 code doing the equivalent of memblock_mark_hotplug(). Post boot, the marking mechanism is not necessary. You can create a movable node by

Re: [PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc

On Wed, Sep 21, 2016 at 12:39:51PM +0530, Aneesh Kumar K.V wrote: What I was checking was how will one mark a node movable in ppc64 ? I don't see ppc64 code doing the equivalent of memblock_mark_hotplug(). Post boot, the marking mechanism is not necessary. You can create a movable node by

Re: Address already in use problem

Hi, On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: > Hi > > we have an SCTP application running in JAVA. and we found that there > is a problem when we as a client trying to connect to a remote IP > address. > > If the remote IP address is not accessible, our application will keep >

Re: Address already in use problem

Hi, On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: > Hi > > we have an SCTP application running in JAVA. and we found that there > is a problem when we as a client trying to connect to a remote IP > address. > > If the remote IP address is not accessible, our application will keep >

Re: [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms

On 9/21/2016 9:11 AM, Bjorn Helgaas wrote: > On Tue, Sep 20, 2016 at 09:15:14PM -0400, c...@codeaurora.org wrote: >> Hi Bjorn, Thomasz, >> >> >> Did you delete this because there were no current users, because you'd >> prefer users just use "-1", or for some other reason? > > I removed it

Re: [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms

On 9/21/2016 9:11 AM, Bjorn Helgaas wrote: > On Tue, Sep 20, 2016 at 09:15:14PM -0400, c...@codeaurora.org wrote: >> Hi Bjorn, Thomasz, >> >> >> Did you delete this because there were no current users, because you'd >> prefer users just use "-1", or for some other reason? > > I removed it

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On Wed, Sep 21, 2016 at 09:32:47AM -0400, Prarit Bhargava wrote: > This is not the right thing to do [1]. The topology directory should exist as > long as the thread is present in the system. The thread (and its core) are > still physically there, it's just that the thread is not available to

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On Wed, Sep 21, 2016 at 09:32:47AM -0400, Prarit Bhargava wrote: > This is not the right thing to do [1]. The topology directory should exist as > long as the thread is present in the system. The thread (and its core) are > still physically there, it's just that the thread is not available to

Re: [PATCH 1/2] mtd: nand: mxc: Test CONFIG_OF instead of CONFIG_OF_MTD

On Sat, 17 Sep 2016 19:57:10 +0200 Boris Brezillon wrote: > We are about to drop the OF_MTD Kconfig option. Test CONFIG_OF > activation instead of CONFIG_OF_MTD. Applied both. > > Signed-off-by: Boris Brezillon > --- >

Re: [PATCH 1/2] mtd: nand: mxc: Test CONFIG_OF instead of CONFIG_OF_MTD

On Sat, 17 Sep 2016 19:57:10 +0200 Boris Brezillon wrote: > We are about to drop the OF_MTD Kconfig option. Test CONFIG_OF > activation instead of CONFIG_OF_MTD. Applied both. > > Signed-off-by: Boris Brezillon > --- > drivers/mtd/nand/mxc_nand.c | 2 +- > 1 file changed, 1 insertion(+), 1

[PATCH] perf powerpc: Don't call perf_event_disable from atomic context

The trinity syscall fuzzer triggered following WARN on powerpc: WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278 ... NIP [c093aedc] .hw_breakpoint_handler+0x28c/0x2b0 LR [c093aed8] .hw_breakpoint_handler+0x288/0x2b0 Call Trace: [c002f7933580]

[PATCH] perf powerpc: Don't call perf_event_disable from atomic context

The trinity syscall fuzzer triggered following WARN on powerpc: WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278 ... NIP [c093aedc] .hw_breakpoint_handler+0x28c/0x2b0 LR [c093aed8] .hw_breakpoint_handler+0x288/0x2b0 Call Trace: [c002f7933580]

Re: [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer

Den 20.09.2016 13:29, skrev ker...@martin.sperl.org: On 20.09.2016, at 12:56, Noralf Trønnes wrote: Den 20.09.2016 12:15, skrev Martin Sperl: On 20.09.2016 10:41, Noralf Trønnes wrote: Den 20.09.2016 09:19, skrev Martin Sperl: Hi Noralf! On 19.09.2016 17:26, Noralf

Re: [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer

Den 20.09.2016 13:29, skrev ker...@martin.sperl.org: On 20.09.2016, at 12:56, Noralf Trønnes wrote: Den 20.09.2016 12:15, skrev Martin Sperl: On 20.09.2016 10:41, Noralf Trønnes wrote: Den 20.09.2016 09:19, skrev Martin Sperl: Hi Noralf! On 19.09.2016 17:26, Noralf Trønnes wrote: Some

Re: [PATCH] btrfs: squash lines for simple wrapper functions

On Tue, Sep 13, 2016 at 04:35:52AM +0900, Masahiro Yamada wrote: > Remove unneeded variables and assignments. > > Signed-off-by: Masahiro Yamada Reviewed-by: David Sterba

Re: [PATCH] btrfs: squash lines for simple wrapper functions

On Tue, Sep 13, 2016 at 04:35:52AM +0900, Masahiro Yamada wrote: > Remove unneeded variables and assignments. > > Signed-off-by: Masahiro Yamada Reviewed-by: David Sterba

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

On Wed, Sep 21, 2016 at 03:16:57PM +0200, Krzysztof Hałasa wrote: > Hans Verkuil writes: > > > That was probably the reason for the pci_read_config_word in the reg_write > > code. Try putting that back (and just that). > > Yes. I guess a single pci_read_config_word() would

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

On Wed, Sep 21, 2016 at 03:16:57PM +0200, Krzysztof Hałasa wrote: > Hans Verkuil writes: > > > That was probably the reason for the pci_read_config_word in the reg_write > > code. Try putting that back (and just that). > > Yes. I guess a single pci_read_config_word() would suffice. > > Though

Re: ftrace function_graph causes system crash

On Wed, 21 Sep 2016 07:50:58 + "Bean Huo (beanhuo)" wrote: > > Hi, Steve > Thanks very much! This is a very useful trace tool, I now know the problem > function, > It is gt_counter_read, if not trace this function, ftrace function_graph work > well. > Do you know now

Re: ftrace function_graph causes system crash

On Wed, 21 Sep 2016 07:50:58 + "Bean Huo (beanhuo)" wrote: > > Hi, Steve > Thanks very much! This is a very useful trace tool, I now know the problem > function, > It is gt_counter_read, if not trace this function, ftrace function_graph work > well. > Do you know now how to deeply debug

Address already in use problem

Hi we have an SCTP application running in JAVA. and we found that there is a problem when we as a client trying to connect to a remote IP address. If the remote IP address is not accessible, our application will keep retrying to connect using a self-defined local port address, says 51001, We

Address already in use problem

Hi we have an SCTP application running in JAVA. and we found that there is a problem when we as a client trying to connect to a remote IP address. If the remote IP address is not accessible, our application will keep retrying to connect using a self-defined local port address, says 51001, We

[PATCH v2 4/7] sched: Add wrappers for lockdep_(un)pin_lock()

In preparation for adding diagnostic checks to catch missing calls to update_rq_clock(), provide wrappers for (re)pinning and unpinning rq->lock. Because the pending diagnostic checks allow state to be maintained in rq_flags across pin contexts, swap the 'struct pin_cookie' arguments for 'struct

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/21/2016 09:04 AM, Borislav Petkov wrote: > On Wed, Sep 21, 2016 at 07:39:31AM -0400, Prarit Bhargava wrote: >> The information in /sys/devices/system/cpu/cpuX/topology >> directory is useful for userspace monitoring applications and in-tree >> utilities like cpupower & turbostat. >> >>

[PATCH v2 6/7] sched/fair: Push rq lock pin/unpin into idle_balance()

Future patches will emit warnings if rq_clock() is called before update_rq_clock() inside a rq_pin_lock()/rq_unpin_lock() pair. Since there is only one caller of idle_balance() we can push the unpin/repin there. Cc: Peter Zijlstra Cc: Ingo Molnar Cc:

[PATCH v2 1/7] sched/fair: Update the rq clock before detaching tasks

detach_task_cfs_rq() may indirectly call rq_clock() to inform the cpufreq code that the rq utilisation has changed. In which case, we need to update the rq clock. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike

[PATCH v2 4/7] sched: Add wrappers for lockdep_(un)pin_lock()

In preparation for adding diagnostic checks to catch missing calls to update_rq_clock(), provide wrappers for (re)pinning and unpinning rq->lock. Because the pending diagnostic checks allow state to be maintained in rq_flags across pin contexts, swap the 'struct pin_cookie' arguments for 'struct

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/21/2016 09:04 AM, Borislav Petkov wrote: > On Wed, Sep 21, 2016 at 07:39:31AM -0400, Prarit Bhargava wrote: >> The information in /sys/devices/system/cpu/cpuX/topology >> directory is useful for userspace monitoring applications and in-tree >> utilities like cpupower & turbostat. >> >>

[PATCH v2 6/7] sched/fair: Push rq lock pin/unpin into idle_balance()

Future patches will emit warnings if rq_clock() is called before update_rq_clock() inside a rq_pin_lock()/rq_unpin_lock() pair. Since there is only one caller of idle_balance() we can push the unpin/repin there. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mike Galbraith Cc: Mel Gorman

[PATCH v2 1/7] sched/fair: Update the rq clock before detaching tasks

detach_task_cfs_rq() may indirectly call rq_clock() to inform the cpufreq code that the rq utilisation has changed. In which case, we need to update the rq clock. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike Galbraith Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 5

[PATCH v2 5/7] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

rq_clock() is called from sched_info_{depart,arrive}() after resetting RQCF_ACT_SKIP but prior to a call to update_rq_clock(). In preparation for pending patches that check whether the rq clock has been updated inside of a pin context before rq_clock() is called, move the reset of

[PATCH v2 5/7] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

rq_clock() is called from sched_info_{depart,arrive}() after resetting RQCF_ACT_SKIP but prior to a call to update_rq_clock(). In preparation for pending patches that check whether the rq clock has been updated inside of a pin context before rq_clock() is called, move the reset of

[PATCH v2 2/7] sched/fair: Update rq clock before waking up new task

When initialising an entity's util and load averages we need an up to date runqueue clock. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike Galbraith Signed-off-by: Matt Fleming

[PATCH v2 2/7] sched/fair: Update rq clock before waking up new task

When initialising an entity's util and load averages we need an up to date runqueue clock. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike Galbraith Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH v2 3/7] sched/fair: Update rq clock in task_hot()

When determining whether or not a task is likely to be cache hot based on its execution start time, we need to ensure the runqueue task clock is accurate and up to date. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc:

[PATCH v2 3/7] sched/fair: Update rq clock in task_hot()

When determining whether or not a task is likely to be cache hot based on its execution start time, we need to ensure the runqueue task clock is accurate and up to date. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike Galbraith Signed-off-by: Matt Fleming --- kernel/sched/fair.c

[PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

There's no diagnostic checks for figuring out when we've accidentally missed update_rq_clock() calls. Let's add some by piggybacking on the rq_*pin_lock() wrappers. The idea behind the diagnostic checks is that upon pining rq lock the rq clock should be updated, via update_rq_clock(), before

[PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

There's no diagnostic checks for figuring out when we've accidentally missed update_rq_clock() calls. Let's add some by piggybacking on the rq_*pin_lock() wrappers. The idea behind the diagnostic checks is that upon pining rq lock the rq clock should be updated, via update_rq_clock(), before

[PATCH v2 0/7] sched: Diagnostic checks for missing rq clock updates

There are currently no runtime diagnostic checks for detecting when we have inadvertently missed a call to update_rq_clock() before accessing rq_clock() or rq_clock_task(). The idea in these patches, which came from Peter, is to piggyback on the rq->lock pin/unpin context to detect when we

[PATCH v2 0/7] sched: Diagnostic checks for missing rq clock updates

There are currently no runtime diagnostic checks for detecting when we have inadvertently missed a call to update_rq_clock() before accessing rq_clock() or rq_clock_task(). The idea in these patches, which came from Peter, is to piggyback on the rq->lock pin/unpin context to detect when we

Re: [PATCH 2/2] time: alarmtimer: Add the trcepoints for alarmtimer

On Wed, 21 Sep 2016 14:36:23 +0200 (CEST) Thomas Gleixner wrote: > On Wed, 21 Sep 2016, Steven Rostedt wrote: > > On Wed, 21 Sep 2016 09:26:20 +0200 (CEST) > > Thomas Gleixner wrote: > > > A single u64 does not take more storage space than this and it's

Re: [PATCH 2/2] time: alarmtimer: Add the trcepoints for alarmtimer

On Wed, 21 Sep 2016 14:36:23 +0200 (CEST) Thomas Gleixner wrote: > On Wed, 21 Sep 2016, Steven Rostedt wrote: > > On Wed, 21 Sep 2016 09:26:20 +0200 (CEST) > > Thomas Gleixner wrote: > > > A single u64 does not take more storage space than this and it's a single > > > store. > > > > So to

Re: [PATCH] ALSA: snd-usb-line6 depends on CONFIG_SND_HWDEP

On Wed, 21 Sep 2016 15:25:43 +0200, Takashi Sakamoto wrote: > > On Sep 21 2016 21:37, Takashi Iwai wrote: > > On Wed, 21 Sep 2016 03:56:05 +0200, > > Takashi Sakamoto wrote: > >> > >> On Sep 21 2016 07:14, Valdis Kletnieks wrote: > >>> ALSA - snd-usb-line6 depends on CONFIG_SND_HWDEP > >>> > >>>

Re: [PATCH] ALSA: snd-usb-line6 depends on CONFIG_SND_HWDEP

On Wed, 21 Sep 2016 15:25:43 +0200, Takashi Sakamoto wrote: > > On Sep 21 2016 21:37, Takashi Iwai wrote: > > On Wed, 21 Sep 2016 03:56:05 +0200, > > Takashi Sakamoto wrote: > >> > >> On Sep 21 2016 07:14, Valdis Kletnieks wrote: > >>> ALSA - snd-usb-line6 depends on CONFIG_SND_HWDEP > >>> > >>>

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Hans Verkuil writes: > That was probably the reason for the pci_read_config_word in the reg_write > code. Try putting that back (and just that). Yes. I guess a single pci_read_config_word() would suffice. Though it would obviously be much better to identify the place in the

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Hans Verkuil writes: > That was probably the reason for the pci_read_config_word in the reg_write > code. Try putting that back (and just that). Yes. I guess a single pci_read_config_word() would suffice. Though it would obviously be much better to identify the place in the driver which needs

Re: [PATCH] ALSA: snd-usb-line6 depends on CONFIG_SND_HWDEP

On Sep 21 2016 21:37, Takashi Iwai wrote: > On Wed, 21 Sep 2016 03:56:05 +0200, > Takashi Sakamoto wrote: >> >> On Sep 21 2016 07:14, Valdis Kletnieks wrote: >>> ALSA - snd-usb-line6 depends on CONFIG_SND_HWDEP >>> >>> ERROR: "snd_hwdep_new" [sound/usb/line6/snd-usb-line6.ko] undefined! >>>

Re: [PATCH] ALSA: snd-usb-line6 depends on CONFIG_SND_HWDEP

On Sep 21 2016 21:37, Takashi Iwai wrote: > On Wed, 21 Sep 2016 03:56:05 +0200, > Takashi Sakamoto wrote: >> >> On Sep 21 2016 07:14, Valdis Kletnieks wrote: >>> ALSA - snd-usb-line6 depends on CONFIG_SND_HWDEP >>> >>> ERROR: "snd_hwdep_new" [sound/usb/line6/snd-usb-line6.ko] undefined! >>>

Re: iTCO_wdt watchdog on Asus P10S-WS motherboard FREEZES MOTHERBOARD COMPLETELY

On Wed, 21 Sep 2016, David Madore wrote: > On Tue, Sep 20, 2016 at 03:50:09PM +0300, Mika Westerberg wrote: > > Does the machine have WDAT ACPI table (see /sys/firmware/acpi/tables/*)? > > If it does, you can try the new WDAT watchdog driver instead [1]. It > > still uses the same hardware, though

Re: iTCO_wdt watchdog on Asus P10S-WS motherboard FREEZES MOTHERBOARD COMPLETELY

On Wed, 21 Sep 2016, David Madore wrote: > On Tue, Sep 20, 2016 at 03:50:09PM +0300, Mika Westerberg wrote: > > Does the machine have WDAT ACPI table (see /sys/firmware/acpi/tables/*)? > > If it does, you can try the new WDAT watchdog driver instead [1]. It > > still uses the same hardware, though

Re: GPU-DRM-nouveau: Delete unnecessary braces

> The original style was correct, the new style is wrong. I find your feedback interesting for further clarifications. > Multi-line indents get curly braces for readability. How do you think about to transform such an information into an official specification for the the document

Re: [PATCH v5 7/8] iommu/amd: Don't update domain info to dte entry at iommu init stage

On 09/21/16 at 06:26pm, Baoquan He wrote: > On 09/20/16 at 02:50pm, Joerg Roedel wrote: > > On Thu, Sep 15, 2016 at 11:03:25PM +0800, Baoquan He wrote: > > > AMD iommu creates protection domain and assign each device to it during > > > iommu driver initialization stage. This happened just after

Re: GPU-DRM-nouveau: Delete unnecessary braces

> The original style was correct, the new style is wrong. I find your feedback interesting for further clarifications. > Multi-line indents get curly braces for readability. How do you think about to transform such an information into an official specification for the the document

Re: [PATCH v5 7/8] iommu/amd: Don't update domain info to dte entry at iommu init stage

On 09/21/16 at 06:26pm, Baoquan He wrote: > On 09/20/16 at 02:50pm, Joerg Roedel wrote: > > On Thu, Sep 15, 2016 at 11:03:25PM +0800, Baoquan He wrote: > > > AMD iommu creates protection domain and assign each device to it during > > > iommu driver initialization stage. This happened just after

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