Re: [regression] Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14

On 2017.12.25 at 10:54 +0100, Pavel Machek wrote: > On Mon 2017-12-25 09:47:48, Markus Trippelsdorf wrote: > > On 2017.12.24 at 23:37 +0100, Pavel Machek wrote: > > > Hi! > > > > > > > > > > > 4.15-rcX is

Re: [regression] Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14

On 2017.12.25 at 10:54 +0100, Pavel Machek wrote: > On Mon 2017-12-25 09:47:48, Markus Trippelsdorf wrote: > > On 2017.12.24 at 23:37 +0100, Pavel Machek wrote: > > > Hi! > > > > > > > > > > > 4.15-rcX is

Re: [regression] Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14

On 2017.12.24 at 23:37 +0100, Pavel Machek wrote: > Hi! > > > > > > > 4.15-rcX is broken, but that had other problems so lets not go > > > > > > there. > > > > > > > > > > > > 4.14 is broken. > > > > > > > > > > And what exactly does happen? > > > > > > > > Suspend looks ok. I believe there's

Re: [regression] Re: Thinkpad T40p: suspend to ram stopped working sometime before 4.14

On 2017.12.24 at 23:37 +0100, Pavel Machek wrote: > Hi! > > > > > > > 4.15-rcX is broken, but that had other problems so lets not go > > > > > > there. > > > > > > > > > > > > 4.14 is broken. > > > > > > > > > > And what exactly does happen? > > > > > > > > Suspend looks ok. I believe there's

Re: [PATCH] perf tools: Add reject option for parse-events.l

On 2017.11.09 at 10:22 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 09, 2017 at 09:17:49AM +0100, Jiri Olsa escreveu: > > Reply-To: > > In-Reply-To: <20171109081319.GB236@x4> > > > > On Thu, Nov 09, 2017 at 09:13:19AM +0100, Markus Trippelsdorf wrote: &

Re: [PATCH] perf tools: Add reject option for parse-events.l

On 2017.11.09 at 10:22 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 09, 2017 at 09:17:49AM +0100, Jiri Olsa escreveu: > > Reply-To: > > In-Reply-To: <20171109081319.GB236@x4> > > > > On Thu, Nov 09, 2017 at 09:13:19AM +0100, Markus Trippelsdorf wrote: &

Re: [GIT PULL] perf fixes

On 2017.11.05 at 15:40 +0100, Ingo Molnar wrote: > Linus, > > Please pull the latest perf-urgent-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > perf-urgent-for-linus > > Jiri Olsa (1): > perf tools: Unwind properly location after REJECT The

Re: [GIT PULL] perf fixes

On 2017.11.05 at 15:40 +0100, Ingo Molnar wrote: > Linus, > > Please pull the latest perf-urgent-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > perf-urgent-for-linus > > Jiri Olsa (1): > perf tools: Unwind properly location after REJECT The

Re: [PATCH] um: Use common error handling code in port_listen_fd()

On 2017.10.23 at 11:48 +0300, Dan Carpenter wrote: > This business of moving the error code to the bottom of the function > just makes the code less readable. I know you never listen to anyone, > but you should stop doing it. How long have we to put up with this? He just keeps sending these crap

Re: [PATCH] um: Use common error handling code in port_listen_fd()

On 2017.10.23 at 11:48 +0300, Dan Carpenter wrote: > This business of moving the error code to the bottom of the function > just makes the code less readable. I know you never listen to anyone, > but you should stop doing it. How long have we to put up with this? He just keeps sending these crap

Re: [lkp-robot] [x86/mm] c4c3c3c2d0: will-it-scale.per_process_ops -61.0% regression

On 2017.10.16 at 18:06 -0700, Andy Lutomirski wrote: > On Mon, Oct 16, 2017 at 3:15 AM, Borislav Petkov wrote: > > On Mon, Oct 16, 2017 at 10:39:17AM +0800, kernel test robot wrote: > >> > >> Greeting, > >> > >> FYI, we noticed a -61.0% regression of will-it-scale.per_process_ops

Re: [lkp-robot] [x86/mm] c4c3c3c2d0: will-it-scale.per_process_ops -61.0% regression

On 2017.10.16 at 18:06 -0700, Andy Lutomirski wrote: > On Mon, Oct 16, 2017 at 3:15 AM, Borislav Petkov wrote: > > On Mon, Oct 16, 2017 at 10:39:17AM +0800, kernel test robot wrote: > >> > >> Greeting, > >> > >> FYI, we noticed a -61.0% regression of will-it-scale.per_process_ops due > >> to

Re: hard lock-up with 4.14 git

On 2017.10.13 at 13:39 +0200, Prakash Punnoor wrote: > after some use (eg. compiling packages) the machine locks up hard. Magic > SysRq doesn't work. > > I had trouble bisecting the offending commit. This is my third try. And > it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework

Re: hard lock-up with 4.14 git

On 2017.10.13 at 13:39 +0200, Prakash Punnoor wrote: > after some use (eg. compiling packages) the machine locks up hard. Magic > SysRq doesn't work. > > I had trouble bisecting the offending commit. This is my third try. And > it points to 94b1b03b519b81c494900cb112aa00ed205cc2d9 "x86/mm: Rework

[PATCH] VFS: Handle lazytime in do_mount()

Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from internal superblock flags") the lazytime mount option doesn't get passed on anymore. Fix the issue by handling the option in do_mount(). Reviewed-by: Lukas Czerner <lczer...@redhat.com> Signed-off-by: Mar

[PATCH] VFS: Handle lazytime in do_mount()

Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from internal superblock flags") the lazytime mount option doesn't get passed on anymore. Fix the issue by handling the option in do_mount(). Reviewed-by: Lukas Czerner Signed-off-by: Markus Trippelsdorf --- fs/names

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On 2017.10.09 at 09:50 -0700, Andy Lutomirski wrote: > Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way > lazy: when running a kernel thread (including the idle thread), the > kernel keeps using the last user mm's page tables without attempting > to maintain user TLB coherence

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On 2017.10.09 at 09:50 -0700, Andy Lutomirski wrote: > Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way > lazy: when running a kernel thread (including the idle thread), the > kernel keeps using the last user mm's page tables without attempting > to maintain user TLB coherence

Re: random insta-reboots on AMD Phenom II

On 2017.09.30 at 10:20 -0400, Brian Gerst wrote: > On Sat, Sep 30, 2017 at 8:47 AM, Markus Trippelsdorf > <mar...@trippelsdorf.de> wrote: > > On 2017.09.30 at 13:53 +0200, Borislav Petkov wrote: > >> On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote: > &

Re: random insta-reboots on AMD Phenom II

On 2017.09.30 at 10:20 -0400, Brian Gerst wrote: > On Sat, Sep 30, 2017 at 8:47 AM, Markus Trippelsdorf > wrote: > > On 2017.09.30 at 13:53 +0200, Borislav Petkov wrote: > >> On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote: > >> > On Sat, Sep 30, 2

Re: random insta-reboots on AMD Phenom II

On 2017.09.30 at 13:53 +0200, Borislav Petkov wrote: > On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote: > > On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote: > > > On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote: > > > > Any hints how to debug this? > > >

Re: random insta-reboots on AMD Phenom II

On 2017.09.30 at 13:53 +0200, Borislav Petkov wrote: > On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote: > > On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote: > > > On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote: > > > > Any hints how to debug this? > > >

Re: [PATCH v2] VFS: Handle lazytime in do_mount()

On 2017.09.19 at 17:25 +0200, Lukas Czerner wrote: > On Tue, Sep 19, 2017 at 12:37:24PM +0200, Markus Trippelsdorf wrote: > > Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from > > internal superblock flags") the lazytime mount option didn't

Re: [PATCH v2] VFS: Handle lazytime in do_mount()

On 2017.09.19 at 17:25 +0200, Lukas Czerner wrote: > On Tue, Sep 19, 2017 at 12:37:24PM +0200, Markus Trippelsdorf wrote: > > Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from > > internal superblock flags") the lazytime mount option didn't

Re: [RFC][PATCH] sched: Cleanup task->state printing

On 2017.09.22 at 13:54 +0200, Peter Zijlstra wrote: > On Fri, Sep 22, 2017 at 11:35:33AM +0200, Markus Trippelsdorf wrote: > > > It seems to work. Simply returning "I (idle)" from get_task_state() in > > > fs/proc/array.c when the state is TASK_IDLE does the tri

Re: [RFC][PATCH] sched: Cleanup task->state printing

On 2017.09.22 at 13:54 +0200, Peter Zijlstra wrote: > On Fri, Sep 22, 2017 at 11:35:33AM +0200, Markus Trippelsdorf wrote: > > > It seems to work. Simply returning "I (idle)" from get_task_state() in > > > fs/proc/array.c when the state is TASK_IDLE does the tri

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

On 2017.09.21 at 16:41 +0200, Markus Trippelsdorf wrote: > On 2017.09.21 at 14:30 +0200, Peter Zijlstra wrote: > > On Thu, Sep 21, 2017 at 01:08:42PM +0200, Markus Trippelsdorf wrote: > > > On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote: > > > > On 2017.0

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

On 2017.09.21 at 16:41 +0200, Markus Trippelsdorf wrote: > On 2017.09.21 at 14:30 +0200, Peter Zijlstra wrote: > > On Thu, Sep 21, 2017 at 01:08:42PM +0200, Markus Trippelsdorf wrote: > > > On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote: > > > > On 2017.0

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

On 2017.09.21 at 14:30 +0200, Peter Zijlstra wrote: > On Thu, Sep 21, 2017 at 01:08:42PM +0200, Markus Trippelsdorf wrote: > > On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote: > > > On 2017.09.11 at 06:11 -0700, Tejun Heo wrote: > > > > Hello, > > >

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

On 2017.09.21 at 14:30 +0200, Peter Zijlstra wrote: > On Thu, Sep 21, 2017 at 01:08:42PM +0200, Markus Trippelsdorf wrote: > > On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote: > > > On 2017.09.11 at 06:11 -0700, Tejun Heo wrote: > > > > Hello, > > >

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote: > On 2017.09.11 at 06:11 -0700, Tejun Heo wrote: > > Hello, > > > > On Sun, Sep 10, 2017 at 09:36:53AM +0200, Markus Trippelsdorf wrote: > > > Since: > > > > > > commit c5a94a618e7ac86b20f53d

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

On 2017.09.11 at 16:21 +0200, Markus Trippelsdorf wrote: > On 2017.09.11 at 06:11 -0700, Tejun Heo wrote: > > Hello, > > > > On Sun, Sep 10, 2017 at 09:36:53AM +0200, Markus Trippelsdorf wrote: > > > Since: > > > > > > commit c5a94a618e7ac86b20f53d

[PATCH v2] VFS: Handle lazytime in do_mount()

Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from internal superblock flags") the lazytime mount option didn't get passed on anymore. Fix the issue by handling the option in do_mount(). Signed-off-by: Markus Trippelsdorf <mar...@trippelsdorf.de> --- fs

[PATCH v2] VFS: Handle lazytime in do_mount()

Since commit e462ec50cb5fa ("VFS: Differentiate mount flags (MS_*) from internal superblock flags") the lazytime mount option didn't get passed on anymore. Fix the issue by handling the option in do_mount(). Signed-off-by: Markus Trippelsdorf --- fs/namespace.c | 3 ++- 1 file

[PATCH] VFS: Handle lazytime in do_mount()

The lazytime option didn't get passed on when using current util-linux, which passes MS_LAZYTIME in the mountflags directly. Fix the issue by handling the option in do_mount(). Signed-off-by: Markus Trippelsdorf <mar...@trippelsdorf.de> --- fs/namespace.c | 3 ++- 1 file changed, 2 inse

[PATCH] VFS: Handle lazytime in do_mount()

The lazytime option didn't get passed on when using current util-linux, which passes MS_LAZYTIME in the mountflags directly. Fix the issue by handling the option in do_mount(). Signed-off-by: Markus Trippelsdorf --- fs/namespace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

Re: [GIT PULL] Firmware files removal for 4.14-rc1

On 2017.09.16 at 09:55 -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 08:25:03AM +0200, Markus Trippelsdorf wrote: > > On 2017.09.16 at 06:51 +0200, Markus Trippelsdorf wrote: > > > On 2017.09.15 at 11:56 -0700, Greg KH wrote: > > > > The

Re: [GIT PULL] Firmware files removal for 4.14-rc1

On 2017.09.16 at 09:55 -0700, Greg KH wrote: > On Sat, Sep 16, 2017 at 08:25:03AM +0200, Markus Trippelsdorf wrote: > > On 2017.09.16 at 06:51 +0200, Markus Trippelsdorf wrote: > > > On 2017.09.15 at 11:56 -0700, Greg KH wrote: > > > > The

[PATCH] firmware: Restore support for built-in firmware

ry minimum. The default for EXTRA_FIRMWARE_DIR is now the standard directory /lib/firmware/. Fixes: 5620a0d1aac ("firmware: delete in-kernel firmware") Signed-off-by: Markus Trippelsdorf <mar...@trippelsdorf.de> --- Makefile | 2 +- drivers/base/Kconfig | 5 +

[PATCH] firmware: Restore support for built-in firmware

ry minimum. The default for EXTRA_FIRMWARE_DIR is now the standard directory /lib/firmware/. Fixes: 5620a0d1aac ("firmware: delete in-kernel firmware") Signed-off-by: Markus Trippelsdorf --- Makefile | 2 +- drivers/base/Kconfig | 5 + firmware/.gitignore | 6

Re: [GIT PULL] Firmware files removal for 4.14-rc1

On 2017.09.16 at 06:51 +0200, Markus Trippelsdorf wrote: > On 2017.09.15 at 11:56 -0700, Greg KH wrote: > > The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261: > > > > Linux 4.13 (2017-09-03 13:56:17 -0700) > > > > are available in the

Re: [GIT PULL] Firmware files removal for 4.14-rc1

On 2017.09.16 at 06:51 +0200, Markus Trippelsdorf wrote: > On 2017.09.15 at 11:56 -0700, Greg KH wrote: > > The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261: > > > > Linux 4.13 (2017-09-03 13:56:17 -0700) > > > > are available in the

Re: [GIT PULL] Firmware files removal for 4.14-rc1

On 2017.09.15 at 11:56 -0700, Greg KH wrote: > The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261: > > Linux 4.13 (2017-09-03 13:56:17 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ >

Re: [GIT PULL] Firmware files removal for 4.14-rc1

On 2017.09.15 at 11:56 -0700, Greg KH wrote: > The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261: > > Linux 4.13 (2017-09-03 13:56:17 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 11:26 -0700, Linus Torvalds wrote: > On Sat, Sep 9, 2017 at 11:14 AM, Markus Trippelsdorf > <mar...@trippelsdorf.de> wrote: > > > > I think the issue gets fixed by: > > > > # wrmsr -a 0xc0010015 0x118 > > > > Setting b

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 11:26 -0700, Linus Torvalds wrote: > On Sat, Sep 9, 2017 at 11:14 AM, Markus Trippelsdorf > wrote: > > > > I think the issue gets fixed by: > > > > # wrmsr -a 0xc0010015 0x118 > > > > Setting bit 3 of the Hardware Configuration

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

On 2017.09.11 at 06:11 -0700, Tejun Heo wrote: > Hello, > > On Sun, Sep 10, 2017 at 09:36:53AM +0200, Markus Trippelsdorf wrote: > > Since: > > > > commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc > > Author: Peter Zijlstra <pet...@infradead.org> >

Re: Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

On 2017.09.11 at 06:11 -0700, Tejun Heo wrote: > Hello, > > On Sun, Sep 10, 2017 at 09:36:53AM +0200, Markus Trippelsdorf wrote: > > Since: > > > > commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc > > Author: Peter Zijlstra > > Date: Wed Aug 23 13:58:44

Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

Since: commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc Author: Peter Zijlstra Date: Wed Aug 23 13:58:44 2017 +0200 workqueue: Use TASK_IDLE all worker threads are in D state. They all show up when using "magic SysRq w". In htop they all have big fat red 'D' in

Worker threads in D state since c5a94a618e7ac86 (workqueue: Use TASK_IDLE)

Since: commit c5a94a618e7ac86b20f53d947f68d7cee6a4c6bc Author: Peter Zijlstra Date: Wed Aug 23 13:58:44 2017 +0200 workqueue: Use TASK_IDLE all worker threads are in D state. They all show up when using "magic SysRq w". In htop they all have big fat red 'D' in the state column. Is

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 20:26 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 08:14:45PM +0200, Markus Trippelsdorf wrote: > > # wrmsr -a 0xc0010015 0x118 > > I know but I'd still like to see the exact error signature. > > So please clear that bit 3 and try to ca

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 20:26 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 08:14:45PM +0200, Markus Trippelsdorf wrote: > > # wrmsr -a 0xc0010015 0x118 > > I know but I'd still like to see the exact error signature. > > So please clear that bit 3 and try to ca

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 19:36 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 07:23:52PM +0200, Markus Trippelsdorf wrote: > > Hmm, the output is exactly the same as before your patch. > > Bah, that patch doesn't account for the fact that we're rereading the >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 19:36 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 07:23:52PM +0200, Markus Trippelsdorf wrote: > > Hmm, the output is exactly the same as before your patch. > > Bah, that patch doesn't account for the fact that we're rereading the >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 19:05 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 06:32:25PM +0200, Markus Trippelsdorf wrote: > > Also tried the following patch. It does not help. > > Ok, another theory. This one still needs to be fixed properly but that > for later. &g

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 19:05 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 06:32:25PM +0200, Markus Trippelsdorf wrote: > > Also tried the following patch. It does not help. > > Ok, another theory. This one still needs to be fixed properly but that > for later. &g

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 16:43 +0200, Markus Trippelsdorf wrote: > On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote: > > On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote: > > > > # rdmsr -a 0x0410 > > > > > > 3fff > > > 0 >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 16:43 +0200, Markus Trippelsdorf wrote: > On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote: > > On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote: > > > > # rdmsr -a 0x0410 > > > > > > 3fff > > > 0 >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote: > > > # rdmsr -a 0x0410 > > > > 3fff > > 0 > > 0 > > 0 > > WTF?! Those should be equal on every CPU. Yi

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote: > > > # rdmsr -a 0x0410 > > > > 3fff > > 0 > > 0 > > 0 > > WTF?! Those should be equal on every CPU. Yi

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 16:07 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 03:39:54PM +0200, Markus Trippelsdorf wrote: > > > mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4: > > > fa1b0c0f > > > mce: [Hardware Error]: TSC b75d6ef4ad

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 16:07 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 03:39:54PM +0200, Markus Trippelsdorf wrote: > > > mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4: > > > fa1b0c0f > > > mce: [Hardware Error]: TSC b75d6ef4ad

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 15:37 +0200, Markus Trippelsdorf wrote: > On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote: > > On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote: > > > It doesn't work. Compiling in a text console just freezes the machine > > >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 15:37 +0200, Markus Trippelsdorf wrote: > On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote: > > On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote: > > > It doesn't work. Compiling in a text console just freezes the machine > > >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote: > > It doesn't work. Compiling in a text console just freezes the machine > > before any MCE gets printed. > > Ok, let's turn off all syncflood

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote: > > It doesn't work. Compiling in a text console just freezes the machine > > before any MCE gets printed. > > Ok, let's turn off all syncflood

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 12:18 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 08:39:08AM +0200, Markus Trippelsdorf wrote: > > Unfortunately the machine hangs in the BIOS after the first warm-reset. > > Probably when it encounters an MCE it doesn't expect. I have to > > war

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.09 at 12:18 +0200, Borislav Petkov wrote: > On Sat, Sep 09, 2017 at 08:39:08AM +0200, Markus Trippelsdorf wrote: > > Unfortunately the machine hangs in the BIOS after the first warm-reset. > > Probably when it encounters an MCE it doesn't expect. I have to > > war

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 14:47 -0700, Andy Lutomirski wrote: > On Fri, Sep 8, 2017 at 10:16 AM, Markus Trippelsdorf > <mar...@trippelsdorf.de> wrote: > > On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote: > >> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf > >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 14:47 -0700, Andy Lutomirski wrote: > On Fri, Sep 8, 2017 at 10:16 AM, Markus Trippelsdorf > wrote: > > On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote: > >> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf > >> wrote: > >>

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 23:56 +0200, Borislav Petkov wrote: > On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote: > > Any chance you could test with CONFIG_DEBUG_VM=y? There are lots of > > potentially useful assertions in that code. > > > > Can you also post your /proc/cpuinfo? And can

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 23:56 +0200, Borislav Petkov wrote: > On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote: > > Any chance you could test with CONFIG_DEBUG_VM=y? There are lots of > > potentially useful assertions in that code. > > > > Can you also post your /proc/cpuinfo? And can

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote: > On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf > <mar...@trippelsdorf.de> wrote: > > On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote: > >> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote: > >>

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote: > On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf > wrote: > > On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote: > >> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote: > >> > &g

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote: > On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote: > > > > * Markus Trippelsdorf <mar...@trippelsdorf.de> wrote: > > > > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote: > > > > On

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote: > On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote: > > > > * Markus Trippelsdorf wrote: > > > > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote: > > > > On Fri, Sep 08, 2017

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote: > > * Markus Trippelsdorf <mar...@trippelsdorf.de> wrote: > > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote: > > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote: > > > > On Fri

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote: > > * Markus Trippelsdorf wrote: > > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote: > > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote: > > > > On Fri, Sep 08, 2017 at 08:

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote: > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote: > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote: > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote: > > > > > >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote: > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote: > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote: > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote: > > > > > >

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.07 at 08:28 +0200, Markus Trippelsdorf wrote: > On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote: > > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote: > > > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote: > > > > On 2017.09.05 at 10:

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.07 at 08:28 +0200, Markus Trippelsdorf wrote: > On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote: > > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote: > > > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote: > > > > On 2017.09.05 at 10:

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote: > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote: > > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote: > > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote: > > > > > Any ideas on how to debug this

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote: > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote: > > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote: > > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote: > > > > > Any ideas on how to debug this

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote: > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote: > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote: > > > > Any ideas on how to debug this further? > > > > > > So you have a (real) serial line on that

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote: > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote: > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote: > > > > Any ideas on how to debug this further? > > > > > > So you have a (real) serial line on that

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 09:27:38AM +0200, Markus Trippelsdorf wrote: > > Current mainline git (24e700e291d52bd2) hangs when building software > > concurrently (for example perf). > > The issue is not 100% reproducible (so

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 09:27:38AM +0200, Markus Trippelsdorf wrote: > > Current mainline git (24e700e291d52bd2) hangs when building software > > concurrently (for example perf). > > The issue is not 100% reproducible (so

Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

Current mainline git (24e700e291d52bd2) hangs when building software concurrently (for example perf). The issue is not 100% reproducible (sometimes building perf succeeds), so bisecting will not work. Magic SysRq key doesn't work and there is nothing in the logs. Enabling CONFIG_PROVE_LOCKING

Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

Current mainline git (24e700e291d52bd2) hangs when building software concurrently (for example perf). The issue is not 100% reproducible (sometimes building perf succeeds), so bisecting will not work. Magic SysRq key doesn't work and there is nothing in the logs. Enabling CONFIG_PROVE_LOCKING

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On 2017.07.31 at 13:04 +0100, Alan Cox wrote: > On Wed, 26 Jul 2017 06:54:01 +0900 > Satoru Takeuchi wrote: > > > # I'm a LKML subscriber, but not a x86 list subscriber > > > > I found the following new linux kernel bugzilla about Ryzen related problem. > > Since many

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

On 2017.07.31 at 13:04 +0100, Alan Cox wrote: > On Wed, 26 Jul 2017 06:54:01 +0900 > Satoru Takeuchi wrote: > > > # I'm a LKML subscriber, but not a x86 list subscriber > > > > I found the following new linux kernel bugzilla about Ryzen related problem. > > Since many developers don't check

Re: commit 67d7ddded32 (waitid(2): leave copyout of siginfo to syscall itself) breaks glibc posix/tst-waitid

On 2017.07.08 at 14:12 +0100, Al Viro wrote: > On Sat, Jul 08, 2017 at 11:56:44AM +0200, Markus Trippelsdorf wrote: > > Since: > > commit 67d7ddded322db99f451a7959d56ed6c70a6c4aa > > Author: Al Viro <v...@zeniv.linux.org.uk> > > Date: Sun May 14 20:53:13

Re: commit 67d7ddded32 (waitid(2): leave copyout of siginfo to syscall itself) breaks glibc posix/tst-waitid

On 2017.07.08 at 14:12 +0100, Al Viro wrote: > On Sat, Jul 08, 2017 at 11:56:44AM +0200, Markus Trippelsdorf wrote: > > Since: > > commit 67d7ddded322db99f451a7959d56ed6c70a6c4aa > > Author: Al Viro > > Date: Sun May 14 20:53:13 2017 -0400 > > > >

commit 67d7ddded32 (waitid(2): leave copyout of siginfo to syscall itself) breaks glibc posix/tst-waitid

Since: commit 67d7ddded322db99f451a7959d56ed6c70a6c4aa Author: Al Viro Date: Sun May 14 20:53:13 2017 -0400 waitid(2): leave copyout of siginfo to syscall itself the glibc posix/tst-waitid.c testcase fails: markus@x4 glibc-build % ./posix/tst-waitid waitid

commit 67d7ddded32 (waitid(2): leave copyout of siginfo to syscall itself) breaks glibc posix/tst-waitid

Since: commit 67d7ddded322db99f451a7959d56ed6c70a6c4aa Author: Al Viro Date: Sun May 14 20:53:13 2017 -0400 waitid(2): leave copyout of siginfo to syscall itself the glibc posix/tst-waitid.c testcase fails: markus@x4 glibc-build % ./posix/tst-waitid waitid WNOHANG on stopped status 0

Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

On 2017.07.04 at 10:31 -0500, Goldwyn Rodrigues wrote: > > > On 07/04/2017 02:45 AM, Markus Trippelsdorf wrote: > > On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote: > >> commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad) > >>

Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

On 2017.07.04 at 10:31 -0500, Goldwyn Rodrigues wrote: > > > On 07/04/2017 02:45 AM, Markus Trippelsdorf wrote: > > On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote: > >> commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad) > >> Aut

Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote: > commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad) > Author: Goldwyn Rodrigues <rgold...@suse.com> > Date: Tue Jun 20 07:05:49 2017 -0500 > > btrfs: nowait aio support > > appa

Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells

On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote: > commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad) > Author: Goldwyn Rodrigues > Date: Tue Jun 20 07:05:49 2017 -0500 > > btrfs: nowait aio support > > apparently breaks several shell r

  1   2   3   4   5   6   7   8   >