Re: Proper way to allocate DMA buffer within a single 4GB block?

On Wed, 20 Sep 2017 17:18:09 -0500 Timur Tabi wrote: > I have a device that requires I allocated a few buffers for DMA. The > problem is that this device has only one register for the upper 32 > bits of all of the buffers. That is, all of buffers must reside > within the

Re: Proper way to allocate DMA buffer within a single 4GB block?

On Wed, 20 Sep 2017 17:18:09 -0500 Timur Tabi wrote: > I have a device that requires I allocated a few buffers for DMA. The > problem is that this device has only one register for the upper 32 > bits of all of the buffers. That is, all of buffers must reside > within the same 4GB block of

Re: [regression 4.14rc] 74def747bcd0 (genirq: Restrict effective affinity to interrupts actually using it)

On Tue, 19 Sep 2017 16:51:06 +0100 Marc Zyngier wrote: > On 19/09/17 16:40, Yanko Kaneti wrote: > > On Tue, 2017-09-19 at 16:33 +0100, Marc Zyngier wrote: > >> On 19/09/17 16:12, Yanko Kaneti wrote: > >>> Hello, > >>> > >>> Fedora rawhide config here. > >>> AMD

Re: [regression 4.14rc] 74def747bcd0 (genirq: Restrict effective affinity to interrupts actually using it)

On Tue, 19 Sep 2017 16:51:06 +0100 Marc Zyngier wrote: > On 19/09/17 16:40, Yanko Kaneti wrote: > > On Tue, 2017-09-19 at 16:33 +0100, Marc Zyngier wrote: > >> On 19/09/17 16:12, Yanko Kaneti wrote: > >>> Hello, > >>> > >>> Fedora rawhide config here. > >>> AMD FX-8370E > >>> > >>>

Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression

On Wed, 13 Sep 2017 17:28:25 + Josef Bacik wrote: > Sorry I thought I had made this other fix, can you apply this on top > of the other one and try that? I have more things to try if this > doesn’t work, sorry you are playing go between, but I want to make > sure I know

Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression

On Wed, 13 Sep 2017 17:28:25 + Josef Bacik wrote: > Sorry I thought I had made this other fix, can you apply this on top > of the other one and try that? I have more things to try if this > doesn’t work, sorry you are playing go between, but I want to make > sure I know _which_ fix actually

[tip:sched/core] sched/x86: Fix typo in __switch_to() comments

Commit-ID: 558a65bc31a0c7811b34dad32f51f47c55a4 Gitweb: http://git.kernel.org/tip/558a65bc31a0c7811b34dad32f51f47c55a4 Author: Chuck Ebbert AuthorDate: Wed, 14 Oct 2015 14:31:19 -0400 Committer: Ingo Molnar CommitDate: Mon, 19 Oct 2015 10:18:53 +0200 sched/x86: Fix typo

[tip:sched/core] sched/x86: Fix typo in __switch_to() comments

Commit-ID: 558a65bc31a0c7811b34dad32f51f47c55a4 Gitweb: http://git.kernel.org/tip/558a65bc31a0c7811b34dad32f51f47c55a4 Author: Chuck Ebbert <cebbert.l...@gmail.com> AuthorDate: Wed, 14 Oct 2015 14:31:19 -0400 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon,

[PATCH] sched, x86: Fix typo in comments in __switch_to()

Fix obvious mistake: FS/GS should be DS/ES. Signed-off-by: Chuck Ebbert diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index d7f1d5c..e835d26 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -332,7 +332,7 @@ __switch_to(struct task_struct

[PATCH] sched, x86: Fix typo in comments in __switch_to()

Fix obvious mistake: FS/GS should be DS/ES. Signed-off-by: Chuck Ebbert <cebbert.l...@gmail.com> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index d7f1d5c..e835d26 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -332,7

Re: [PATCH] locking/static_keys: fix a silly typo

On Tue, 08 Sep 2015 12:05:04 -0400 Jason Baron wrote: > > > On 09/07/2015 03:18 PM, Jonathan Corbet wrote: > > 412758cb2670 (jump label, locking/static_keys: Update docs) introduced a > > typo that might as well get fixed. > > > > Signed-off-by: Jonathan Corbet > > --- > >

Re: [PATCH] locking/static_keys: fix a silly typo

On Tue, 08 Sep 2015 12:05:04 -0400 Jason Baron wrote: > > > On 09/07/2015 03:18 PM, Jonathan Corbet wrote: > > 412758cb2670 (jump label, locking/static_keys: Update docs) introduced a > > typo that might as well get fixed. > > > > Signed-off-by: Jonathan Corbet

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

On Fri, 4 Sep 2015 00:28:04 +0300 Stas Sergeev wrote: > 03.09.2015 21:51, Austin S Hemmelgarn пишет: > > There are servers out there that have this enabled and _never_ use it > > at all, > Unless I am mistaken, servers usually use special flavour of the > distro (different from desktop

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

On Fri, 4 Sep 2015 00:28:04 +0300 Stas Sergeev wrote: > 03.09.2015 21:51, Austin S Hemmelgarn пишет: > > There are servers out there that have this enabled and _never_ use it > > at all, > Unless I am mistaken, servers usually use special flavour of the > distro (different from

Re: [GIT PULL] Ext3 removal, quota & udf fixes

On Tue, 1 Sep 2015 15:39:45 -0400 Austin S Hemmelgarn wrote: > On 2015-09-01 06:29, Albino B Neto wrote: > > 2015-08-31 19:31 GMT-03:00 Raymond Jennings : > >> I think also that we should remove the ext2 driver before we remove the > >> ext3 > >> driver. > > > > Yes. It is logical to remove the

Re: [GIT PULL] Ext3 removal, quota & udf fixes

On Tue, 1 Sep 2015 15:39:45 -0400 Austin S Hemmelgarn wrote: > On 2015-09-01 06:29, Albino B Neto wrote: > > 2015-08-31 19:31 GMT-03:00 Raymond Jennings : > >> I think also that we should remove the ext2 driver before we remove the > >> ext3 > >>

[BUG 4.2-rc8] Interrupt occurs while apply_alternatives() is patching the handler

This is from https://bugzilla.redhat.com/show_bug.cgi?id=1258223 [0.036000] BUG: unable to handle kernel paging request at 55501e06 [0.036000] IP: [] common_interrupt+0xb/0x38 [0.036000] *pde = [0.036000] Oops: [#1] SMP [0.036000] Modules linked in: [

[BUG 4.2-rc8] Interrupt occurs while apply_alternatives() is patching the handler

This is from https://bugzilla.redhat.com/show_bug.cgi?id=1258223 [0.036000] BUG: unable to handle kernel paging request at 55501e06 [0.036000] IP: [c0aae48b] common_interrupt+0xb/0x38 [0.036000] *pde = [0.036000] Oops: [#1] SMP [0.036000] Modules linked in: [

[PATCH -next] static-keys: Better error checking for static_key_enable/disable

be smaller too. Signed-off-by: Chuck Ebbert diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h index 7f653e8..ba9ca0c 100644 --- a/include/linux/jump_label.h +++ b/include/linux/jump_label.h @@ -225,7 +225,7 @@ static inline void static_key_enable(struct static_key *key

[PATCH -next] static-keys: Better error checking for static_key_enable/disable

be smaller too. Signed-off-by: Chuck Ebbert cebbert.l...@gmail.com diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h index 7f653e8..ba9ca0c 100644 --- a/include/linux/jump_label.h +++ b/include/linux/jump_label.h @@ -225,7 +225,7 @@ static inline void static_key_enable(struct

Re: ip_rcv_finish() NULL pointer and possibly related Oopses

On Wed, 26 Aug 2015 08:46:59 + Shaun Crampton wrote: > Testing our app at scale on Google¹s GCE, running ~1000 CoreOS hosts: over > approximately 1 hour, I see about 1 in 50 hosts hit one of the Oopses > below and then reboot (I¹m not sure if the different oopses are related to > each

Re: ip_rcv_finish() NULL pointer and possibly related Oopses

On Wed, 26 Aug 2015 08:46:59 + Shaun Crampton shaun.cramp...@metaswitch.com wrote: Testing our app at scale on Google¹s GCE, running ~1000 CoreOS hosts: over approximately 1 hour, I see about 1 in 50 hosts hit one of the Oopses below and then reboot (I¹m not sure if the different oopses

[PATCH -next] static-keys: Fix documentation

Fix some mistakes and typos, clean up text a bit. Signed-off-by: Chuck Ebbert diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt index f4cb0b2..127391c 100644 --- a/Documentation/static-keys.txt +++ b/Documentation/static-keys.txt @@ -3,8 +3,8 @@ DEPRECATED API

[PATCH -next] static-keys: Fix documentation

Fix some mistakes and typos, clean up text a bit. Signed-off-by: Chuck Ebbert cebbert.l...@gmail.com diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt index f4cb0b2..127391c 100644 --- a/Documentation/static-keys.txt +++ b/Documentation/static-keys.txt @@ -3,8 +3,8

Re: Hello everyone <3

On Sun, 16 Aug 2015 02:00:34 +0200 noi...@a6.25u.com wrote: > Question: Wouldn't it be a good idea to enforce the Linux trademark > (somewhen) in a way that all these streamlined operating systems use the > word "Linux" more carefully (or not at all) in their promotional > material? To make

Re: fs: out of bounds on stack in iov_iter_advance

On Wed, 12 Aug 2015 10:13:24 -0400 Sasha Levin wrote: > While fuzzing with trinity inside a KVM tools guest running -next I've > stumbled on the following: > > [64092.216447] > == > [64092.217840] BUG: KASan: out of bounds on

Re: Hello everyone 3

On Sun, 16 Aug 2015 02:00:34 +0200 noi...@a6.25u.com wrote: Question: Wouldn't it be a good idea to enforce the Linux trademark (somewhen) in a way that all these streamlined operating systems use the word Linux more carefully (or not at all) in their promotional material? To make sure

Re: fs: out of bounds on stack in iov_iter_advance

On Wed, 12 Aug 2015 10:13:24 -0400 Sasha Levin sasha.le...@oracle.com wrote: While fuzzing with trinity inside a KVM tools guest running -next I've stumbled on the following: [64092.216447] == [64092.217840] BUG: KASan: out

Re: Disable input device

On Sat, 29 Nov 2014 18:24:03 +0100 Pali Rohár wrote: > What do you think about adding new sysfs file "disable" (accept > values 1 or 0) for every input device? With "1" it cause that > kernel will drop all events from specific input device and if > driver provide some function is can be

Re: frequent lockups in 3.18rc4

On Fri, 5 Dec 2014 13:48:08 -0500 Dave Jones wrote: > [ 1611.749570] [] do_nmi+0xb8/0xf0 > [ 1611.750438] [] end_repeat_nmi+0x1e/0x2e > [ 1611.751312] [] ? preempt_count_add+0x18/0xb0 > [ 1611.752177] [] ? preempt_count_add+0x18/0xb0 > [ 1611.753025] [] ? preempt_count_add+0x18/0xb0 > [

Re: frequent lockups in 3.18rc4

On Fri, 5 Dec 2014 13:48:08 -0500 Dave Jones da...@redhat.com wrote: [ 1611.749570] [81007948] do_nmi+0xb8/0xf0 [ 1611.750438] [8179dd2a] end_repeat_nmi+0x1e/0x2e [ 1611.751312] [810a12c8] ? preempt_count_add+0x18/0xb0 [ 1611.752177] [810a12c8] ?

Re: Disable input device

On Sat, 29 Nov 2014 18:24:03 +0100 Pali Rohár pali.ro...@gmail.com wrote: What do you think about adding new sysfs file disable (accept values 1 or 0) for every input device? With 1 it cause that kernel will drop all events from specific input device and if driver provide some function is

Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct

Should the completely pointless supervisor_stack[] be removed as well? I had a patch to do that but I never sent it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct

Should the completely pointless supervisor_stack[] be removed as well? I had a patch to do that but I never sent it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH] x86: fix disabling XSAVE feature when CPUID level is capped

Signed-off-by: Chuck Ebbert --- Compile tested only. I don't have an AVX-capable machine to test on. diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index cfa9b5b..f668e09 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -144,

[PATCH] x86: fix disabling XSAVE feature when CPUID level is capped

-by: Chuck Ebbert cebbert.l...@gmail.com --- Compile tested only. I don't have an AVX-capable machine to test on. diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index cfa9b5b..f668e09 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -144,15

Re: [PATCH 3.17 00/25] 3.17.1-stable review

On Mon, 13 Oct 2014 08:28:35 -0300 Henrique de Moraes Holschuh wrote: > On Mon, 13 Oct 2014, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.17.1 > > release. There are 25 patches in this series, all will be posted > > as a response to this one. If anyone

Re: CRASH during boot 3.16.3+

On Mon, 13 Oct 2014 12:14:40 +0200 Udo van den Heuvel wrote: > On 2014-10-12 19:42, Peter Hurley wrote: > > On 10/12/2014 09:57 AM, Udo van den Heuvel wrote: > >> The problem: > >> During the first few seconds of bootup the kernel gets into some sort of > >> loop and rapidly prints loads of

Re: CRASH during boot 3.16.3+

On Mon, 13 Oct 2014 12:14:40 +0200 Udo van den Heuvel udo...@xs4all.nl wrote: On 2014-10-12 19:42, Peter Hurley wrote: On 10/12/2014 09:57 AM, Udo van den Heuvel wrote: The problem: During the first few seconds of bootup the kernel gets into some sort of loop and rapidly prints loads of

Re: [PATCH 3.17 00/25] 3.17.1-stable review

On Mon, 13 Oct 2014 08:28:35 -0300 Henrique de Moraes Holschuh h...@hmh.eng.br wrote: On Mon, 13 Oct 2014, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.17.1 release. There are 25 patches in this series, all will be posted as a response to this one. If

Re: [PATCH] x86: Clean up stack access code in irq_32.c

enough better to do different macros for gcc and other compilers though. clang actually moves %esp to memory and then into another register instead of moving it directly when using the current macro. Their optimizer really needs some work... > On October 12, 2014 9:53:32 AM PDT, Chuck Ebbert

Re: [PATCH] x86: Clean up stack access code in irq_32.c

On Sun, 12 Oct 2014 12:00:03 -0500 Jeff Epler wrote: > It looks like the proposed variant still miscompiles in clang 3.4 and 3.5, the > two versions I had handy to test. > > I extracted your code to a simple standalone C translation unit and > inspected various compilers' results via objdump. >

Re: [PATCH] x86: Clean up stack access code in irq_32.c

This is a local one, which the clang documentation says is supported. And I compiled it with clang with no problem. > On October 12, 2014 9:43:53 AM PDT, Chuck Ebbert > wrote: > >Use C instead of asm for accessing the stack pointer. And define some > >macros to make the code easier

[PATCH] x86: Clean up stack access code in irq_32.c

Use C instead of asm for accessing the stack pointer. And define some macros to make the code easier to understand. Signed-off-by: Chuck Ebbert diff --git a/arch/x86/include/asm/page_32_types.h b/arch/x86/include/asm/page_32_types.h index f48b17d..a8ca0cb 100644 --- a/arch/x86/include/asm

[PATCH] x86: Clean up stack access code in irq_32.c

Use C instead of asm for accessing the stack pointer. And define some macros to make the code easier to understand. Signed-off-by: Chuck Ebbert cebbert.l...@gmail.com diff --git a/arch/x86/include/asm/page_32_types.h b/arch/x86/include/asm/page_32_types.h index f48b17d..a8ca0cb 100644

Re: [PATCH] x86: Clean up stack access code in irq_32.c

. This is a local one, which the clang documentation says is supported. And I compiled it with clang with no problem. On October 12, 2014 9:43:53 AM PDT, Chuck Ebbert cebbert.l...@gmail.com wrote: Use C instead of asm for accessing the stack pointer. And define some macros to make the code easier

Re: [PATCH] x86: Clean up stack access code in irq_32.c

On Sun, 12 Oct 2014 12:00:03 -0500 Jeff Epler jep...@unpythonic.net wrote: It looks like the proposed variant still miscompiles in clang 3.4 and 3.5, the two versions I had handy to test. I extracted your code to a simple standalone C translation unit and inspected various compilers'

Re: [PATCH] x86: Clean up stack access code in irq_32.c

better to do different macros for gcc and other compilers though. clang actually moves %esp to memory and then into another register instead of moving it directly when using the current macro. Their optimizer really needs some work... On October 12, 2014 9:53:32 AM PDT, Chuck Ebbert cebbert.l

Re: [sched] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

On Sat, 11 Oct 2014 13:15:30 +0800 Fengguang Wu wrote: > FYI, we noticed the below changes on commit > > 445d95d7c384741d133251a9adac935866591c92 ("sched: Remove > update_rq_runnable_avg") > > [ 67.303839] BUG: unable to handle kernel NULL pointer dereference at > 0040 > [

Re: [sched] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

On Sat, 11 Oct 2014 13:15:30 +0800 Fengguang Wu fengguang...@intel.com wrote: FYI, we noticed the below changes on commit 445d95d7c384741d133251a9adac935866591c92 (sched: Remove update_rq_runnable_avg) [ 67.303839] BUG: unable to handle kernel NULL pointer dereference at

Re: [PATCH 4/4] x86: Use the page tables to look up kernel addresses in backtrace

On Fri, 10 Oct 2014 16:25:17 -0700 Andi Kleen wrote: > From: Andi Kleen > > On my workstation which has a lot of modules loaded: > > $ lsmod | wc -l > 80 > > backtrace from the NMI for perf record -g can take a quite long time. > > This leads to frequent messages like: > perf interrupt took

Re: [PATCH 4/4] x86: Use the page tables to look up kernel addresses in backtrace

On Fri, 10 Oct 2014 16:25:17 -0700 Andi Kleen a...@firstfloor.org wrote: From: Andi Kleen a...@linux.intel.com On my workstation which has a lot of modules loaded: $ lsmod | wc -l 80 backtrace from the NMI for perf record -g can take a quite long time. This leads to frequent

Re: acpitool - /proc/acpi/wakeup

On Thu, 9 Oct 2014 22:16:11 +0200 Frans Klaver wrote: > On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt wrote: > > > > > >>On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt > >>wrote: > >>> I upgraded from 3.10 on that machine. 3.12 didn't work for me due to > >>a hibernation bug. The rest was

Re: i915.ko WC writes are slow after ea8596bb2d8d379

On Thu, 9 Oct 2014 14:00:47 +0100 Chris Wilson wrote: > On Thu, Oct 09, 2014 at 07:44:16AM -0500, Chuck Ebbert wrote: > > Could you try installing x86info and running "x86info --mtrr > > --all-cpus" while running the broken kernel? > > # /opt/xorg/src/intel-gpu-t

Re: i915.ko WC writes are slow after ea8596bb2d8d379

On Thu, 9 Oct 2014 07:53:31 +0100 Chris Wilson wrote: > # cat /proc/mtrr > reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back > reg01: base=0x08000 ( 2048MB), size= 256MB, count=1: write-back > reg02: base=0x08e00 ( 2272MB), size= 32MB, count=1: uncachable > reg03:

Re: i915.ko WC writes are slow after ea8596bb2d8d379

On Thu, 9 Oct 2014 07:53:31 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: # cat /proc/mtrr reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 256MB, count=1: write-back reg02: base=0x08e00 ( 2272MB), size= 32MB, count=1:

Re: i915.ko WC writes are slow after ea8596bb2d8d379

On Thu, 9 Oct 2014 14:00:47 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On Thu, Oct 09, 2014 at 07:44:16AM -0500, Chuck Ebbert wrote: Could you try installing x86info and running x86info --mtrr --all-cpus while running the broken kernel? # /opt/xorg/src/intel-gpu-tools/tests

Re: acpitool - /proc/acpi/wakeup

On Thu, 9 Oct 2014 22:16:11 +0200 Frans Klaver franskla...@gmail.com wrote: On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt m...@osknowledge.org wrote: On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt m...@osknowledge.org wrote: I upgraded from 3.10 on that machine. 3.12 didn't work for me

Re: vdso_standalone_test_x86.c build failure on Linus' tree

On Wed, 08 Oct 2014 14:21:00 -0700 "H. Peter Anvin" wrote: > On 10/08/2014 02:09 PM, Chuck Ebbert wrote: > >> > >> Breaking cross-compilation is not okay, though, regardless of what > >> Fedora does. It should be okay to, for example, build an i386 ke

Re: vdso_standalone_test_x86.c build failure on Linus' tree

On Wed, 08 Oct 2014 13:55:00 -0700 "H. Peter Anvin" wrote: > On 10/08/2014 01:46 PM, Chuck Ebbert wrote: > > > > Fedora doesn't cross-compile i686 builds because of problems like > > this. It sets up an i386 chroot and runs all native tools inside of > > it.

Re: vdso_standalone_test_x86.c build failure on Linus' tree

On Wed, 8 Oct 2014 12:16:11 -0700 Andy Lutomirski wrote: > On Wed, Oct 8, 2014 at 11:52 AM, Josh Boyer wrote: > > I'm seeing the following build failure on a 32-bit x86 build in Fedora > > based on Linux v3.17-2860-gef0625b70dac: > > > > Documentation/vDSO/vdso_standalone_test_x86.o: In

Re: i915.ko WC writes are slow after ea8596bb2d8d379

On Wed, 8 Oct 2014 10:03:36 +0100 Chris Wilson wrote: > and adding that back into the current build, e.g. > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 3632743..48a8a69 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -87,6 +87,7 @@ config X86 > select

Re: i915.ko WC writes are slow after ea8596bb2d8d379

On Wed, 8 Oct 2014 10:03:36 +0100 Chris Wilson wrote: > > I ran into a problem on a Sandybridge i5-2500s whilst measuring the > performance of GTT write-combining access. I found subsequent runs were > about 10-40x slower than the first. For example, > > igt/gem_gtt_speed: > > Time to read

Re: i915.ko WC writes are slow after ea8596bb2d8d379

On Wed, 8 Oct 2014 10:03:36 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: I ran into a problem on a Sandybridge i5-2500s whilst measuring the performance of GTT write-combining access. I found subsequent runs were about 10-40x slower than the first. For example, igt/gem_gtt_speed:

Re: i915.ko WC writes are slow after ea8596bb2d8d379

On Wed, 8 Oct 2014 10:03:36 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: and adding that back into the current build, e.g. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3632743..48a8a69 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -87,6 +87,7 @@ config X86

Re: vdso_standalone_test_x86.c build failure on Linus' tree

On Wed, 8 Oct 2014 12:16:11 -0700 Andy Lutomirski l...@amacapital.net wrote: On Wed, Oct 8, 2014 at 11:52 AM, Josh Boyer jwbo...@fedoraproject.org wrote: I'm seeing the following build failure on a 32-bit x86 build in Fedora based on Linux v3.17-2860-gef0625b70dac:

Re: vdso_standalone_test_x86.c build failure on Linus' tree

On Wed, 08 Oct 2014 13:55:00 -0700 H. Peter Anvin h...@zytor.com wrote: On 10/08/2014 01:46 PM, Chuck Ebbert wrote: Fedora doesn't cross-compile i686 builds because of problems like this. It sets up an i386 chroot and runs all native tools inside of it. Breaking cross-compilation

Re: vdso_standalone_test_x86.c build failure on Linus' tree

On Wed, 08 Oct 2014 14:21:00 -0700 H. Peter Anvin h...@zytor.com wrote: On 10/08/2014 02:09 PM, Chuck Ebbert wrote: Breaking cross-compilation is not okay, though, regardless of what Fedora does. It should be okay to, for example, build an i386 kernel on an ARM box. I think

Re: [GIT PULL] ring-buffer: Fix infinite spin in reading buffer

On Sun, 5 Oct 2014 16:49:43 -0700 Greg Kroah-Hartman wrote: > On Fri, Oct 03, 2014 at 04:20:43PM -0400, Steven Rostedt wrote: ... > > Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page" > > Signed-off-by: Steven Rostedt > > Next time, please also add a Cc:

Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

On Tue, 7 Oct 2014 16:59:03 -0700 David Daney wrote: > On 10/07/2014 04:20 PM, Ralf Baechle wrote: > > On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote: > > > >>> As an alternative, if the space of possible instruction with a delay > >>> slot is sufficiently small, all such

Re: Linux 3.17

On Tue, 7 Oct 2014 23:45:20 +0300 (EEST) Meelis Roos wrote: > > Anyway, back to 3.17. Nothing major happened during the last week, as > > you can see from the appended shortlog. Mostly drivers (i915, nouveau, > > ethernet, scsi, sound) and some networking fixes. With some misc > > noise all

Re: [PATCH v2] perf tools: fix off-by-one error in maps

On Tue, 7 Oct 2014 11:00:50 -0300 Arnaldo Carvalho de Melo wrote: > I keep thinking that this change is making things unclear. > > I.e. the _start_ of a map (map->start) is _in_ the map, and the _end_ > of a map (map->end) is _in_ the map as well. > > if (addr > m->end) > > is shorter

Re: [PATCH v2] perf tools: fix off-by-one error in maps

On Tue, 7 Oct 2014 11:00:50 -0300 Arnaldo Carvalho de Melo a...@redhat.com wrote: I keep thinking that this change is making things unclear. I.e. the _start_ of a map (map-start) is _in_ the map, and the _end_ of a map (map-end) is _in_ the map as well. if (addr m-end) is

Re: Linux 3.17

On Tue, 7 Oct 2014 23:45:20 +0300 (EEST) Meelis Roos mr...@ut.ee wrote: Anyway, back to 3.17. Nothing major happened during the last week, as you can see from the appended shortlog. Mostly drivers (i915, nouveau, ethernet, scsi, sound) and some networking fixes. With some misc noise all

Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

On Tue, 7 Oct 2014 16:59:03 -0700 David Daney dda...@caviumnetworks.com wrote: On 10/07/2014 04:20 PM, Ralf Baechle wrote: On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote: As an alternative, if the space of possible instruction with a delay slot is sufficiently small, all

Re: [GIT PULL] ring-buffer: Fix infinite spin in reading buffer

On Sun, 5 Oct 2014 16:49:43 -0700 Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Oct 03, 2014 at 04:20:43PM -0400, Steven Rostedt wrote: ... Fixes: 651e22f2701b ring-buffer: Always reset iterator to reader page Signed-off-by: Steven Rostedt rost...@goodmis.org Next

Re: perf: 3.17 another perf_fuzzer lockup

On Mon, 6 Oct 2014 11:55:11 -0400 (EDT) Vince Weaver wrote: > On Mon, 6 Oct 2014, Vince Weaver wrote: > > > [ 843.700042] general protection fault: [#1] SMP > > ... > > [ 843.704001] task: 88011a874000 ti: 8800bc0ec000 task.ti: > > 8800bc0ec000 > > [ 843.704001] RIP:

Re: perf: 3.17 another perf_fuzzer lockup

On Mon, 6 Oct 2014 11:55:11 -0400 (EDT) Vince Weaver vincent.wea...@maine.edu wrote: On Mon, 6 Oct 2014, Vince Weaver wrote: [ 843.700042] general protection fault: [#1] SMP ... [ 843.704001] task: 88011a874000 ti: 8800bc0ec000 task.ti: 8800bc0ec000 [

Re: [PATCH 3.16 000/357] 3.16.4-stable review

On Sun, 5 Oct 2014 13:39:14 -0700 Greg Kroah-Hartman wrote: > On Sat, Oct 04, 2014 at 07:38:39AM -0500, Chuck Ebbert wrote: > > On Fri, 3 Oct 2014 14:26:26 -0700 > > Greg Kroah-Hartman wrote: > > > > > - > > > Note: T

Re: perf & rasd integration plan

On Sun, 5 Oct 2014 20:24:42 +0200 Jiri Olsa wrote: > On Sun, Oct 05, 2014 at 07:48:01PM +0200, Borislav Petkov wrote: > > Top-posting on purpose: > > > > Btw, jolsa, if you get your LCE proposal for the perf splitting > > approved, please post the time here so people can come. > > yep, it got

Re: (Song) Fk SystemD

On Sun, 5 Oct 2014 10:29:24 + Gregory Smith wrote: > Fuck you. > > This is what you systemd shitheads say to everything. > It's either your way or the highway. > Did you even *read* Al's reply? He's objecting to the tactics, not the underlying message that systemd is crap. Sheesh. > >

Re: [PATCH] cma: make default CMA area size zero for x86

> Reported-by: Peter Hurley > Cc: Peter Hurley > Cc: Chuck Ebbert > Cc: Marek Szyprowski > Cc: Konrad Rzeszutek Wilk > Cc: David Woodhouse > Cc: Don Dutile > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Andi Kleen &g

Re: [PATCH] fs: use kfree_rcu instead of i_callback

On Sat, 4 Oct 2014 23:00:42 -0400 John de la Garza wrote: > Since the callback is doing nothing more than calling kfree() we can > use kfree_rcu() instead of having to use a callback. > > Signed-off-by: John de la Garza > --- > fs/inode.c | 8 +--- > 1 file changed, 1 insertion(+), 7

Re: [PATCH] fs: use kfree_rcu instead of i_callback

On Sat, 4 Oct 2014 23:00:42 -0400 John de la Garza j...@jjdev.com wrote: Since the callback is doing nothing more than calling kfree() we can use kfree_rcu() instead of having to use a callback. Signed-off-by: John de la Garza j...@jjdev.com --- fs/inode.c | 8 +--- 1 file changed, 1

Re: [PATCH] cma: make default CMA area size zero for x86

Reported-by: Peter Hurley pe...@hurleysoftware.com Cc: Peter Hurley pe...@hurleysoftware.com Cc: Chuck Ebbert cebbert.l...@gmail.com Cc: Marek Szyprowski m.szyprow...@samsung.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: David Woodhouse dw...@infradead.org Cc: Don Dutile ddut

Re: (Song) Fk SystemD

On Sun, 5 Oct 2014 10:29:24 + Gregory Smith gregorysmith19...@gmail.com wrote: Fuck you. This is what you systemd shitheads say to everything. It's either your way or the highway. Did you even *read* Al's reply? He's objecting to the tactics, not the underlying message that systemd is

Re: perf rasd integration plan

On Sun, 5 Oct 2014 20:24:42 +0200 Jiri Olsa jo...@redhat.com wrote: On Sun, Oct 05, 2014 at 07:48:01PM +0200, Borislav Petkov wrote: Top-posting on purpose: Btw, jolsa, if you get your LCE proposal for the perf splitting approved, please post the time here so people can come. yep, it

Re: [PATCH 3.16 000/357] 3.16.4-stable review

On Sun, 5 Oct 2014 13:39:14 -0700 Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Sat, Oct 04, 2014 at 07:38:39AM -0500, Chuck Ebbert wrote: On Fri, 3 Oct 2014 14:26:26 -0700 Greg Kroah-Hartman gre...@linuxfoundation.org wrote: - Note

Re: Slowdown due to threads bouncing between HT cores

On Fri, 3 Oct 2014 21:44:29 +0200 "Steinar H. Gunderson" wrote: > Hi, > > I did a chess benchmark of my new machine (2x E5-2650v3, so 20x2.3GHz > Haswell-EP), and it performed a bit worse than comparable Windows setups. > It looks like the scheduler somehow doesn't perform as well with >

Re: [PATCH 3.16 000/357] 3.16.4-stable review

On Fri, 3 Oct 2014 14:26:26 -0700 Greg Kroah-Hartman wrote: > - > Note: This is a big stable release. Mostly my fault for being on the > road last week, combined with an unusually large number of patches being > tagged for the stable tree. Anyway, I've caught

Re: [x86, locking/rwlocks, btrfs] INFO: rcu_sched self-detected stall on CPU

On Fri, 03 Oct 2014 23:27:58 -0400 Waiman Long wrote: > On 10/03/2014 09:33 AM, Fengguang Wu wrote: > > Hi Waiman, > > > > FYI, we noticed the below changes on commit > > > > bd01ec1a13f9a327950c8e3080096446c7804753 ("x86, locking/rwlocks: Enable > > qrwlocks on x86") > > > >

Re: [x86, locking/rwlocks, btrfs] INFO: rcu_sched self-detected stall on CPU

On Fri, 03 Oct 2014 23:27:58 -0400 Waiman Long waiman.l...@hp.com wrote: On 10/03/2014 09:33 AM, Fengguang Wu wrote: Hi Waiman, FYI, we noticed the below changes on commit bd01ec1a13f9a327950c8e3080096446c7804753 (x86, locking/rwlocks: Enable qrwlocks on x86)

Re: [PATCH 3.16 000/357] 3.16.4-stable review

On Fri, 3 Oct 2014 14:26:26 -0700 Greg Kroah-Hartman gre...@linuxfoundation.org wrote: - Note: This is a big stable release. Mostly my fault for being on the road last week, combined with an unusually large number of patches being tagged for the stable tree.

Re: Slowdown due to threads bouncing between HT cores

On Fri, 3 Oct 2014 21:44:29 +0200 Steinar H. Gunderson sgunder...@bigfoot.com wrote: Hi, I did a chess benchmark of my new machine (2x E5-2650v3, so 20x2.3GHz Haswell-EP), and it performed a bit worse than comparable Windows setups. It looks like the scheduler somehow doesn't perform as

Re: [tip:x86/asm] x86: Speed up ___preempt_schedule*() by using THUNK helpers

On Fri, 3 Oct 2014 23:41:24 +0200 Oleg Nesterov wrote: > On 10/03, Chuck Ebbert wrote: > > > > > [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) > > > [ 921.917752] ? preempt_schedule_context (kernel/context_tracking

Re: [tip:x86/asm] x86: Speed up ___preempt_schedule*() by using THUNK helpers

On Fri, 03 Oct 2014 00:50:13 -0400 Sasha Levin wrote: > On 09/24/2014 11:02 AM, tip-bot for Oleg Nesterov wrote: > > Commit-ID: 0ad6e3c5199be12c9745da8f8b9e3c9f8066c235 > > Gitweb: > > http://git.kernel.org/tip/0ad6e3c5199be12c9745da8f8b9e3c9f8066c235 > > Author: Oleg Nesterov > >

Re: [tip:x86/asm] x86: Speed up ___preempt_schedule*() by using THUNK helpers

On Fri, 03 Oct 2014 00:50:13 -0400 Sasha Levin sasha.le...@oracle.com wrote: On 09/24/2014 11:02 AM, tip-bot for Oleg Nesterov wrote: Commit-ID: 0ad6e3c5199be12c9745da8f8b9e3c9f8066c235 Gitweb: http://git.kernel.org/tip/0ad6e3c5199be12c9745da8f8b9e3c9f8066c235 Author: Oleg

Re: [tip:x86/asm] x86: Speed up ___preempt_schedule*() by using THUNK helpers

On Fri, 3 Oct 2014 23:41:24 +0200 Oleg Nesterov o...@redhat.com wrote: On 10/03, Chuck Ebbert wrote: [ 921.917752] ? ___preempt_schedule_context (arch/x86/lib/thunk_64.S:44) [ 921.917752] ? preempt_schedule_context (kernel/context_tracking.c:145) [ 921.917752

Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.

On Wed, 1 Oct 2014 01:16:15 +0100 Al Viro wrote: Can we get the below added somewhere in Documentation/filesystems/ ? I don't see anything there that covers all this. > > Huh? copy_name() does copy a _reference_, not the name itself. All the > copying involved is source->d_name.name =

Re: pipe/page fault oddness.

On Wed, 01 Oct 2014 23:32:15 -0400 Sasha Levin wrote: > On 10/01/2014 06:28 PM, Chuck Ebbert wrote: > > On Wed, 01 Oct 2014 18:08:30 -0400 > > Sasha Levin wrote: > > > >> > On 10/01/2014 04:20 PM, Linus Torvalds wrote: > >>> > > So I'm really

  1   2   3   4   5   6   7   8   9   10   >