Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds wrote: > On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote: >> >> $ objdump -S clang-eflag.o >> >> Does this now look good? > > Looks fine to me. The instruction choice is still pretty odd: > > 1a: f

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 3:28 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: > On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds > <torva...@linux-foundation.org> wrote: >> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: >>> >&

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 3:28 PM, Sedat Dilek wrote: > On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds > wrote: >> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote: >>> >>> $ objdump -S clang-eflag.o >>> >>> clang-eflag.o: file format elf64

Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> >> $ objdump -S clang-eflag.o >> >> clang-eflag.o: file format elf64-x86-6

Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds wrote: > On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote: >> >> $ objdump -S clang-eflag.o >> >> clang-eflag.o: file format elf64-x86-64 >> >> >> Disassembly of section

[PATCH] Makefile: Fix typo s/HOST_LOADLIBES/HOST_LOADLIBS

Signed-off-by: Sedat Dilek <sedat.di...@credativ.de> --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 83b6c541565a..e1869dc08288 100644 --- a/Makefile +++ b/Makefile @@ -366,7 +366,7 @@ HOSTCFLAGS := -Wall -Wmissing-prot

[PATCH] Makefile: Fix typo s/HOST_LOADLIBES/HOST_LOADLIBS

Signed-off-by: Sedat Dilek --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 83b6c541565a..e1869dc08288 100644 --- a/Makefile +++ b/Makefile @@ -366,7 +366,7 @@ HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2

Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[ CC Nick ] [ CC Arnd ] [ CC JF ] Hi Matthias, I was following [1] a bit and fell over your original posting in [2]. I wrote some early documentation (wiki) and tested/booted a clang-compiled kernel on x86-64 bare metal. The project was called "lll-project" these days. The followup - LLVMlinux

Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[ CC Nick ] [ CC Arnd ] [ CC JF ] Hi Matthias, I was following [1] a bit and fell over your original posting in [2]. I wrote some early documentation (wiki) and tested/booted a clang-compiled kernel on x86-64 bare metal. The project was called "lll-project" these days. The followup - LLVMlinux

Re: [PATCH] MAINTAINERS: greybus: Fix typo s/LOOBACK/LOOPBACK

On Tue, Jul 25, 2017 at 2:53 PM, Sedat Dilek <sedat.di...@credativ.de> wrote: > From: Sedat Dilek <sedat.di...@gmail.com> > > Fixes: f47e07bc5f1a5c48 ("Fix up MAINTAINERS file problems") > Cc: Joe Perches <j...@perches.com> > Cc: Linus Torvalds <tor

Re: [PATCH] MAINTAINERS: greybus: Fix typo s/LOOBACK/LOOPBACK

On Tue, Jul 25, 2017 at 2:53 PM, Sedat Dilek wrote: > From: Sedat Dilek > > Fixes: f47e07bc5f1a5c48 ("Fix up MAINTAINERS file problems") > Cc: Joe Perches > Cc: Linus Torvalds > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Sedat Dilek > --- > [ di

Re: [PATCH] kbuild: Update example for ccflags-y usage

On Mon, Aug 7, 2017 at 10:24 PM, Jonathan Corbet <cor...@lwn.net> wrote: > On Mon, 24 Jul 2017 17:27:05 +0200 > Sedat Dilek <sedat.di...@credativ.de> wrote: > >> The old example to describe ccflags-y usage is no more valid. >> >> Signed-off-by: Sedat Dilek &

Re: [PATCH] kbuild: Update example for ccflags-y usage

On Mon, Aug 7, 2017 at 10:24 PM, Jonathan Corbet wrote: > On Mon, 24 Jul 2017 17:27:05 +0200 > Sedat Dilek wrote: > >> The old example to describe ccflags-y usage is no more valid. >> >> Signed-off-by: Sedat Dilek > > I've applied this; had to clean up som

[PATCH] MAINTAINERS: greybus: Fix typo s/LOOBACK/LOOPBACK

From: Sedat Dilek <sedat.di...@gmail.com> Fixes: f47e07bc5f1a5c48 ("Fix up MAINTAINERS file problems") Cc: Joe Perches <j...@perches.com> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Sedat Dilek <sedat.di...@

[PATCH] MAINTAINERS: greybus: Fix typo s/LOOBACK/LOOPBACK

From: Sedat Dilek Fixes: f47e07bc5f1a5c48 ("Fix up MAINTAINERS file problems") Cc: Joe Perches Cc: Linus Torvalds Cc: linux-kernel@vger.kernel.org Signed-off-by: Sedat Dilek --- [ dileks: v2: CC LKML (Thanks Joe Perches) ] MAINTAINERS | 2 +- 1 file changed, 1 insertion(+),

[PATCH] kbuild: Update example for ccflags-y usage

From: Sedat Dilek <sedat.di...@gmail.com> The old example to describe ccflags-y usage is no more valid. Signed-off-by: Sedat Dilek <sedat.di...@gmail.com> --- Documentation/kbuild/makefiles.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Document

[PATCH] kbuild: Update example for ccflags-y usage

From: Sedat Dilek The old example to describe ccflags-y usage is no more valid. Signed-off-by: Sedat Dilek --- Documentation/kbuild/makefiles.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt

Re: [GIT PULL] sysctl fixes for v4.13-rc1

On Thu, Jul 13, 2017 at 2:45 AM, Eric W. Biederman wrote: > > Linus, > > Please pull the for-linus branch from the git tree: > >git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > for-linus > >HEAD: 2fd1d2c4ceb2248a727696962cf3370dc9f5a0a4

Re: [GIT PULL] sysctl fixes for v4.13-rc1

On Thu, Jul 13, 2017 at 2:45 AM, Eric W. Biederman wrote: > > Linus, > > Please pull the for-linus branch from the git tree: > >git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > for-linus > >HEAD: 2fd1d2c4ceb2248a727696962cf3370dc9f5a0a4 proc: Fix >

Re: Linux 4.10-rc7

Hi Linus, here in my environment I hit a pm/runtime problem. For people seeing this too, [1] has the fix "PM / runtime: Avoid false-positive warnings from might_sleep_if()". Just for the records. Regards, - Sedat - [1]

Re: Linux 4.10-rc7

Hi Linus, here in my environment I hit a pm/runtime problem. For people seeing this too, [1] has the fix "PM / runtime: Avoid false-positive warnings from might_sleep_if()". Just for the records. Regards, - Sedat - [1]

Re: [PATCH] PM / runtime: Avoid false-positive warnings from might_sleep_if()

On Sat, Feb 4, 2017 at 12:58 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Thursday, February 02, 2017 02:34:42 PM Sedat Dilek wrote: >> On Wed, Feb 1, 2017 at 1:22 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: >> > On Mon, Jan 30, 2017

Re: [PATCH] PM / runtime: Avoid false-positive warnings from might_sleep_if()

On Sat, Feb 4, 2017 at 12:58 AM, Rafael J. Wysocki wrote: > On Thursday, February 02, 2017 02:34:42 PM Sedat Dilek wrote: >> On Wed, Feb 1, 2017 at 1:22 AM, Rafael J. Wysocki wrote: >> > On Mon, Jan 30, 2017 at 11:44 PM, Rafael J. Wysocki >> > wrote: >> >

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On Fri, May 27, 2016 at 10:19 AM, Chris Bainbridge <chris.bainbri...@gmail.com> wrote: > On 25 May 2016 at 08:31, Sedat Dilek <sedat.di...@gmail.com> wrote: >> Hi Daniel, >> >> with latest Linus Git I see this with my Intel Sandy

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On Fri, May 27, 2016 at 10:19 AM, Chris Bainbridge wrote: > On 25 May 2016 at 08:31, Sedat Dilek wrote: >> Hi Daniel, >> >> with latest Linus Git I see this with my Intel SandyBridge GPU... >> >> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] &g

Re: [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> Hi, >> >> I have already reported this issue in [1]. >> One of the issue was solved. >>

Re: [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki wrote: > On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote: >> Hi, >> >> I have already reported this issue in [1]. >> One of the issue was solved. >> Unfortunately, it looks like there is still a differen

Re: [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> Hi, >> >> I have already reported this issue in [1]. >> One of the issue was solved. >>

Re: [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki wrote: > On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote: >> Hi, >> >> I have already reported this issue in [1]. >> One of the issue was solved. >> Unfortunately, it looks like there is still a differen

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Thu, Dec 29, 2016 at 12:58 PM, Mika Kuoppala <mika.kuopp...@linux.intel.com> wrote: > Sedat Dilek <sedat.di...@gmail.com> writes: > >> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki <raf...@kernel.org> >> wrote: >>> On Wed, Dec 28, 2016 at

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Thu, Dec 29, 2016 at 12:58 PM, Mika Kuoppala wrote: > Sedat Dilek writes: > >> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki >> wrote: >>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek wrote: >>>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula <jani.nik...@intel.com> wrote: >>> On Wed, 28 Dec 2016

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki wrote: > On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek wrote: >> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula wrote: >>> On Wed, 28 Dec 2016, Sedat Dilek wrote: >>>> On Tue, Dec 27, 2016 at 10:13 PM,

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula <jani.nik...@intel.com> wrote: > On Wed, 28 Dec 2016, Sedat Dilek <sedat.di...@gmail.com> wrote: >> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek <pa...@ucw.cz> wrote: >>> Hi! >>> >>>> [ Add so

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula wrote: > On Wed, 28 Dec 2016, Sedat Dilek wrote: >> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote: >>> Hi! >>> >>>> [ Add some pm | i915 | x86 folks ] >>>> >>>> Hi, >>>>

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote: > Hi! > >> [ Add some pm | i915 | x86 folks ] >> >> Hi, >> >> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system >> and I see some call-traces. >> It is reproducible on suspend and resume. >> >> I cannot say

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote: > Hi! > >> [ Add some pm | i915 | x86 folks ] >> >> Hi, >> >> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system >> and I see some call-traces. >> It is reproducible on suspend and resume. >> >> I cannot say which area

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Tue, Dec 27, 2016 at 4:55 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: > On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter <dan...@ffwll.ch> wrote: >> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote: >>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Tue, Dec 27, 2016 at 4:55 PM, Sedat Dilek wrote: > On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter wrote: >> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote: >>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote: >>> > [ Add some pm | i91

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote: >> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote: >> > [ Add some pm | i915 | x86 folks ] >> > >> > Hi, &g

Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter wrote: > On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote: >> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote: >> > [ Add some pm | i915 | x86 folks ] >> > >> > Hi, >> > >>

[tip:smp/urgent] perf/x86/amd/ibs: Fix typo after cleanup state names in cpu/hotplug

Commit-ID: 7e164ce4e8ecd7e9a58a83750bd3ee03125df154 Gitweb: http://git.kernel.org/tip/7e164ce4e8ecd7e9a58a83750bd3ee03125df154 Author: Sedat Dilek <sedat.di...@gmail.com> AuthorDate: Mon, 26 Dec 2016 11:05:11 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:smp/urgent] perf/x86/amd/ibs: Fix typo after cleanup state names in cpu/hotplug

Commit-ID: 7e164ce4e8ecd7e9a58a83750bd3ee03125df154 Gitweb: http://git.kernel.org/tip/7e164ce4e8ecd7e9a58a83750bd3ee03125df154 Author: Sedat Dilek AuthorDate: Mon, 26 Dec 2016 11:05:11 +0100 Committer: Thomas Gleixner CommitDate: Tue, 27 Dec 2016 11:42:12 +0100 perf/x86/amd/ibs: Fix

[PATCH] perf/x86/amd/ibs: Fix typo after cleanup state names in cpu/hotplug

x.de> CC: Ingo Molnar <mi...@redhat.com> CC: "H. Peter Anvin" <h...@zytor.com> CC: x...@kernel.org CC: Peter Zijlstra <pet...@infradead.org> CC: Borislav Petkov <b...@suse.de> CC: Paul Gortmaker <paul.gortma...@windriver.com> CC: linux-kernel@vger.kernel.org

[PATCH] perf/x86/amd/ibs: Fix typo after cleanup state names in cpu/hotplug

C: "H. Peter Anvin" CC: x...@kernel.org CC: Peter Zijlstra CC: Borislav Petkov CC: Paul Gortmaker CC: linux-kernel@vger.kernel.org Signed-off-by: Sedat Dilek --- arch/x86/events/amd/ibs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/amd/ib

Re: [4.9-rc1] Build-time 2x slower

On Thu, Oct 20, 2016 at 4:32 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Thursday, October 20, 2016 04:20:44 PM Sedat Dilek wrote: >> On Thu, Oct 20, 2016 at 1:15 PM, Rafael J. Wysocki <r...@rjwysocki.net> >> wrote: >> > On Thursday, October 20

Re: [4.9-rc1] Build-time 2x slower

On Thu, Oct 20, 2016 at 4:32 PM, Rafael J. Wysocki wrote: > On Thursday, October 20, 2016 04:20:44 PM Sedat Dilek wrote: >> On Thu, Oct 20, 2016 at 1:15 PM, Rafael J. Wysocki >> wrote: >> > On Thursday, October 20, 2016 09:41:34 AM Sedat Dilek wrote: >> >&

Re: [4.9-rc1] Build-time 2x slower

On Thu, Oct 20, 2016 at 4:32 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Thursday, October 20, 2016 04:20:44 PM Sedat Dilek wrote: >> On Thu, Oct 20, 2016 at 1:15 PM, Rafael J. Wysocki <r...@rjwysocki.net> >> wrote: >> > On Thursday, October 20

Re: [4.9-rc1] Build-time 2x slower

On Thu, Oct 20, 2016 at 4:32 PM, Rafael J. Wysocki wrote: > On Thursday, October 20, 2016 04:20:44 PM Sedat Dilek wrote: >> On Thu, Oct 20, 2016 at 1:15 PM, Rafael J. Wysocki >> wrote: >> > On Thursday, October 20, 2016 09:41:34 AM Sedat Dilek wrote: >> >&

Re: [4.9-rc1] Build-time 2x slower

On Thu, Oct 20, 2016 at 1:15 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Thursday, October 20, 2016 09:41:34 AM Sedat Dilek wrote: >> On Wed, Oct 19, 2016 at 10:55 PM, Rafael J. Wysocki <r...@rjwysocki.net> >> wrote: >> > On Wednesday, October

Re: [4.9-rc1] Build-time 2x slower

On Thu, Oct 20, 2016 at 1:15 PM, Rafael J. Wysocki wrote: > On Thursday, October 20, 2016 09:41:34 AM Sedat Dilek wrote: >> On Wed, Oct 19, 2016 at 10:55 PM, Rafael J. Wysocki >> wrote: >> > On Wednesday, October 19, 2016 06:59:35 PM Jörg Otte wrote: >> >&

Re: [4.9-rc1] Build-time 2x slower

On Thu, Oct 20, 2016 at 9:57 AM, Jörg Otte wrote: > 2016-10-19 22:55 GMT+02:00 Rafael J. Wysocki : >> On Wednesday, October 19, 2016 06:59:35 PM Jörg Otte wrote: >>> 2016-10-19 17:29 GMT+02:00 Linus Torvalds : >>> > On Wed,

Re: [4.9-rc1] Build-time 2x slower

On Thu, Oct 20, 2016 at 9:57 AM, Jörg Otte wrote: > 2016-10-19 22:55 GMT+02:00 Rafael J. Wysocki : >> On Wednesday, October 19, 2016 06:59:35 PM Jörg Otte wrote: >>> 2016-10-19 17:29 GMT+02:00 Linus Torvalds : >>> > On Wed, Oct 19, 2016 at 4:07 AM, Jörg Otte wrote: >>> >> >>> >> Additional info:

Re: [4.9-rc1] Build-time 2x slower

On Wed, Oct 19, 2016 at 5:29 PM, Linus Torvalds wrote: > On Wed, Oct 19, 2016 at 4:07 AM, Jörg Otte wrote: >> >> Additional info: I usally use schedutil governor. >> If I switch to performance governor problems go away. >> Maybe a cpufreq

Re: [4.9-rc1] Build-time 2x slower

On Wed, Oct 19, 2016 at 5:29 PM, Linus Torvalds wrote: > On Wed, Oct 19, 2016 at 4:07 AM, Jörg Otte wrote: >> >> Additional info: I usally use schedutil governor. >> If I switch to performance governor problems go away. >> Maybe a cpufreq problem? > > Oh, I completely misread the original bug

Re: [4.9-rc1] Build-time 2x slower

On Wed, Oct 19, 2016 at 10:55 PM, Rafael J. Wysocki wrote: > On Wednesday, October 19, 2016 06:59:35 PM Jörg Otte wrote: >> 2016-10-19 17:29 GMT+02:00 Linus Torvalds : >> > On Wed, Oct 19, 2016 at 4:07 AM, Jörg Otte wrote: >>

Re: [4.9-rc1] Build-time 2x slower

On Wed, Oct 19, 2016 at 10:55 PM, Rafael J. Wysocki wrote: > On Wednesday, October 19, 2016 06:59:35 PM Jörg Otte wrote: >> 2016-10-19 17:29 GMT+02:00 Linus Torvalds : >> > On Wed, Oct 19, 2016 at 4:07 AM, Jörg Otte wrote: >> >> >> >> Additional info: I usally use schedutil governor. >> >> If I

Re: [4.9-rc1] Build-time 2x slower

On Wed, Oct 19, 2016 at 6:59 PM, Jörg Otte wrote: > 2016-10-19 17:29 GMT+02:00 Linus Torvalds : >> On Wed, Oct 19, 2016 at 4:07 AM, Jörg Otte wrote: >>> >>> Additional info: I usally use schedutil governor. >>> If I switch to

Re: [4.9-rc1] Build-time 2x slower

On Wed, Oct 19, 2016 at 6:59 PM, Jörg Otte wrote: > 2016-10-19 17:29 GMT+02:00 Linus Torvalds : >> On Wed, Oct 19, 2016 at 4:07 AM, Jörg Otte wrote: >>> >>> Additional info: I usally use schedutil governor. >>> If I switch to performance governor problems go away. >>> Maybe a cpufreq problem? >>

Re: [4.9-rc1] Build-time 2x slower

On Tue, Oct 18, 2016 at 3:38 AM, Ming Lei <tom.leim...@gmail.com> wrote: > On Tue, Oct 18, 2016 at 12:04 AM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> Hi Linus, >> >> not sure whom to address on this issue. >> >> I have built Linux v4.9-rc1,

Re: [4.9-rc1] Build-time 2x slower

On Tue, Oct 18, 2016 at 3:38 AM, Ming Lei wrote: > On Tue, Oct 18, 2016 at 12:04 AM, Sedat Dilek wrote: >> Hi Linus, >> >> not sure whom to address on this issue. >> >> I have built Linux v4.9-rc1, v4.8.2 and v4.4.25 kernels (in this >> order) this morni

Re: [4.9-rc1] Build-time 2x slower

On Mon, Oct 17, 2016 at 6:46 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Oct 17, 2016 at 9:04 AM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> >> not sure whom to address on this issue. >> >> I have built Linux v4.9-rc1, v4.8.

Re: [4.9-rc1] Build-time 2x slower

On Mon, Oct 17, 2016 at 6:46 PM, Linus Torvalds wrote: > On Mon, Oct 17, 2016 at 9:04 AM, Sedat Dilek wrote: >> >> not sure whom to address on this issue. >> >> I have built Linux v4.9-rc1, v4.8.2 and v4.4.25 kernels (in this >> order) this morning. >> >

[4.9-rc1] Build-time 2x slower

Hi Linus, not sure whom to address on this issue. I have built Linux v4.9-rc1, v4.8.2 and v4.4.25 kernels (in this order) this morning. Building a Linux v4.8.2 under Linux v4.9-rc1 took two times longer. As usually I build with 2 parallel-make-jobs. This takes approx. 30mins. Under Linux

[4.9-rc1] Build-time 2x slower

Hi Linus, not sure whom to address on this issue. I have built Linux v4.9-rc1, v4.8.2 and v4.4.25 kernels (in this order) this morning. Building a Linux v4.8.2 under Linux v4.9-rc1 took two times longer. As usually I build with 2 parallel-make-jobs. This takes approx. 30mins. Under Linux

Re: [GIT PULL] overlayfs update for 4.9

On Fri, Oct 14, 2016 at 6:03 AM, Linus Torvalds wrote: > On Thu, Oct 13, 2016 at 7:37 AM, Miklos Szeredi wrote: >> >> Please pull from: > > No. [...] > It's too late in the merge window for this to be fixed up any more. > This has been a painful

Re: [GIT PULL] overlayfs update for 4.9

On Fri, Oct 14, 2016 at 6:03 AM, Linus Torvalds wrote: > On Thu, Oct 13, 2016 at 7:37 AM, Miklos Szeredi wrote: >> >> Please pull from: > > No. [...] > It's too late in the merge window for this to be fixed up any more. > This has been a painful enough merge window for me that I'm not going > to

Re: [v4.7-6816-g797cee982eef] Call-trace: modprobe | asymmetric-keys?

On Sat, Jul 30, 2016 at 4:25 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Sat, Jul 30, 2016 at 02:55:12PM +0200, Sedat Dilek wrote: >> [ CC "MODULE SUPPORT" | "ASYMMETRIC KEYS" | "CRYPTO API" maintainers ] >> >> Hi, &g

Re: [v4.7-6816-g797cee982eef] Call-trace: modprobe | asymmetric-keys?

On Sat, Jul 30, 2016 at 4:25 PM, Herbert Xu wrote: > On Sat, Jul 30, 2016 at 02:55:12PM +0200, Sedat Dilek wrote: >> [ CC "MODULE SUPPORT" | "ASYMMETRIC KEYS" | "CRYPTO API" maintainers ] >> >> Hi, >> >> with latest Linus Git (v

Re: linux-next: build failure after merge of the drm tree

On 7/15/16, Stephen Rothwell wrote: > Hi Dave, > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0: > drivers/gpu/drm/i915/intel_opregion.c: In function >

Re: linux-next: build failure after merge of the drm tree

On 7/15/16, Stephen Rothwell wrote: > Hi Dave, > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0: > drivers/gpu/drm/i915/intel_opregion.c: In function >

Re: [4.4.y] llvmlinux: Backport "x86/hweight: Get rid of the special calling convention"

> The patch I had in series is now obsolete. > That's the correct one. - Sedat - From 5a10fe05cb0b8169b7616f79471e50751f3222f5 Mon Sep 17 00:00:00 2001 From: Sedat Dilek <sedat.di...@gmail.com> Date: Mon, 12 Oct 2015 09:39:28 +0200 Subject: [PATCH] x86/hweight: boot: llvmlinux: Wor

Re: [4.4.y] llvmlinux: Backport "x86/hweight: Get rid of the special calling convention"

> The patch I had in series is now obsolete. > That's the correct one. - Sedat - From 5a10fe05cb0b8169b7616f79471e50751f3222f5 Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Mon, 12 Oct 2015 09:39:28 +0200 Subject: [PATCH] x86/hweight: boot: llvmlinux: Workaround LLVM Bug

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> >> $ objdump -S clang-eflag.o >> >> clang-eflag.o: file format elf64-x86-6

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds wrote: > On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote: >> >> $ objdump -S clang-eflag.o >> >> clang-eflag.o: file format elf64-x86-64 >> >> >> Disassembly of section

[4.4.y] llvmlinux: Backport "x86/hweight: Get rid of the special calling convention"

/tip.git/commit/?id=f5967101e9de12addcda4510dfbac66d7c5779c3 From 0319f2601355d8a8d5635e9a195845ea340c8ae1 Mon Sep 17 00:00:00 2001 From: Sedat Dilek <sedat.di...@gmail.com> Date: Sun, 20 Sep 2015 20:33:19 +0200 Subject: [PATCH] x86: boot: llvmlinux: Workaround LLVM Bug PR3997 For more details

[4.4.y] llvmlinux: Backport "x86/hweight: Get rid of the special calling convention"

/tip.git/commit/?id=f5967101e9de12addcda4510dfbac66d7c5779c3 From 0319f2601355d8a8d5635e9a195845ea340c8ae1 Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Sun, 20 Sep 2015 20:33:19 +0200 Subject: [PATCH] x86: boot: llvmlinux: Workaround LLVM Bug PR3997 For more details see [1]. [1] https://llvm.org

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Jun 27, 2016 at 9:50 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: > On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds > <torva...@linux-foundation.org> wrote: >> On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern <st...@rowland.harvard.edu> >> wrote: >

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Jun 27, 2016 at 9:50 PM, Sedat Dilek wrote: > On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds > wrote: >> On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern >> wrote: >>> >>> Of course, there are other ways to save a single flag value (such as >>&g

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds wrote: > On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern wrote: >> >> Of course, there are other ways to save a single flag value (such as >> setz). It's up to the compiler developers to decide

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds wrote: > On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern wrote: >> >> Of course, there are other ways to save a single flag value (such as >> setz). It's up to the compiler developers to decide what they think is >> best. > > Using 'setcc' to save

[v4.7-rc5] i915: *ERROR* (CPU pipe|PCH transcoder) A FIFO underrun

Hi Daniel, I had already reported this issue in a email-thread called "[v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun". This is still happening here on Sandybridge (and Ivybridge GPU reported by Chris Bainbridge). I have updated the bug-report in [1]. Chris

[v4.7-rc5] i915: *ERROR* (CPU pipe|PCH transcoder) A FIFO underrun

Hi Daniel, I had already reported this issue in a email-thread called "[v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun". This is still happening here on Sandybridge (and Ivybridge GPU reported by Chris Bainbridge). I have updated the bug-report in [1]. Chris

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

On Thu, Jun 16, 2016 at 2:36 PM, Miklos Szeredi <mik...@szeredi.hu> wrote: > On Thu, Jun 16, 2016 at 2:22 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: > >> Can you point me to - preferable - a Git repo of libfuse? > > https://github.com/libfuse >

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

On Thu, Jun 16, 2016 at 2:36 PM, Miklos Szeredi wrote: > On Thu, Jun 16, 2016 at 2:22 PM, Sedat Dilek wrote: > >> Can you point me to - preferable - a Git repo of libfuse? > > https://github.com/libfuse > >> And the commit for backporting? > > 8bb62

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

On Thu, Jun 16, 2016 at 2:01 PM, Miklos Szeredi <mik...@szeredi.hu> wrote: > On Thu, Jun 16, 2016 at 1:51 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: >> On Thu, Jun 16, 2016 at 1:25 PM, Miklos Szeredi <mik...@szeredi.hu> wrote: >>> On Thu, Apr 7, 2016 at

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

On Thu, Jun 16, 2016 at 2:01 PM, Miklos Szeredi wrote: > On Thu, Jun 16, 2016 at 1:51 PM, Sedat Dilek wrote: >> On Thu, Jun 16, 2016 at 1:25 PM, Miklos Szeredi wrote: >>> On Thu, Apr 7, 2016 at 1:48 PM, Ashish Sangwan >>> wrote: >>>> While sending t

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

On Thu, Jun 16, 2016 at 1:25 PM, Miklos Szeredi wrote: > On Thu, Apr 7, 2016 at 1:48 PM, Ashish Sangwan > wrote: >> While sending the blocking directIO in fuse, the write request is broken >> into sub-requests, each of default size 128k and all the

Re: [PATCH] FUSE: Improve aio directIO write performance for size extending writes.

On Thu, Jun 16, 2016 at 1:25 PM, Miklos Szeredi wrote: > On Thu, Apr 7, 2016 at 1:48 PM, Ashish Sangwan > wrote: >> While sending the blocking directIO in fuse, the write request is broken >> into sub-requests, each of default size 128k and all the requests are sent >> in non-blocking

Re: [PATCH] gcc-plugins: disable under COMPILE_TEST

On Sat, Jun 11, 2016 at 6:12 PM, Kees Cook wrote: > Since adding the gcc plugin development headers is required for the > gcc plugin support, we should ease into this new kernel build dependency > more slowly. For now, disable the gcc plugins under COMPILE_TEST so that >

Re: [PATCH] gcc-plugins: disable under COMPILE_TEST

On Sat, Jun 11, 2016 at 6:12 PM, Kees Cook wrote: > Since adding the gcc plugin development headers is required for the > gcc plugin support, we should ease into this new kernel build dependency > more slowly. For now, disable the gcc plugins under COMPILE_TEST so that > all*config builds will

Re: [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260

On 3/30/16, Peter Zijlstra wrote: > On Wed, Mar 30, 2016 at 11:36:59AM +0200, Peter Zijlstra wrote: >> Furthermore, our hash function has definite room for improvement. > > After a bit of reading, using a 'strong' PRNG as base for a hash > function seems generally suggested.

Re: [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260

On 3/30/16, Peter Zijlstra wrote: > On Wed, Mar 30, 2016 at 11:36:59AM +0200, Peter Zijlstra wrote: >> Furthermore, our hash function has definite room for improvement. > > After a bit of reading, using a 'strong' PRNG as base for a hash > function seems generally suggested. > > --- >

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On 5/28/16, Sedat Dilek <sedat.di...@gmail.com> wrote: > On 5/27/16, Chris Bainbridge <chris.bainbri...@gmail.com> wrote: >> On 25 May 2016 at 08:31, Sedat Dilek <sedat.di...@gmail.com> wrote: >>> Hi Daniel, >>> >>> with lat

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On 5/28/16, Sedat Dilek wrote: > On 5/27/16, Chris Bainbridge wrote: >> On 25 May 2016 at 08:31, Sedat Dilek wrote: >>> Hi Daniel, >>> >>> with latest Linus Git I see this with my Intel SandyBridge GPU... >>> >>> [ 17.629014] [drm:intel

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On 5/27/16, Chris Bainbridge <chris.bainbri...@gmail.com> wrote: > On 25 May 2016 at 08:31, Sedat Dilek <sedat.di...@gmail.com> wrote: >> Hi Daniel, >> >> with latest Linus Git I see this with my Intel SandyBridge GPU... >> >> [ 17.629014] [

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On 5/27/16, Chris Bainbridge wrote: > On 25 May 2016 at 08:31, Sedat Dilek wrote: >> Hi Daniel, >> >> with latest Linus Git I see this with my Intel SandyBridge GPU... >> >> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] >> *ERROR* CP

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On 5/25/16, Jani Nikula <jani.nik...@linux.intel.com> wrote: > On Wed, 25 May 2016, Sedat Dilek <sedat.di...@gmail.com> wrote: >> Hi Daniel, >> >> with latest Linus Git I see this with my Intel SandyBridge GPU... >> >> [ 17.629014] [drm:intel_cpu_fif

Re: [Intel-gfx] [v4.6-10530-g28165ec7a99b] i915: *ERROR* "CPU pipe/PCH transcoder" A FIFO underrun

On 5/25/16, Jani Nikula wrote: > On Wed, 25 May 2016, Sedat Dilek wrote: >> Hi Daniel, >> >> with latest Linus Git I see this with my Intel SandyBridge GPU... >> >> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] >> *ERROR* CP

Re: [v4.6-rc7-183-g1410b74e4061]

On 5/16/16, Sedat Dilek <sedat.di...@gmail.com> wrote: > On 5/16/16, Peter Zijlstra <pet...@infradead.org> wrote: >> On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote: >> >>> Unfortunately, I could not reproduce this again with none of my &

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