Thank you!
On Mon, Dec 18, 2017 at 11:11:31AM +0100, Pavel Machek wrote:
> Hi!
> On Mon 2017-12-18 03:20:11, Alexandru Chirvasitu wrote:
> > Short description of the problem: latest rc kernel results in seemingly
> > APIC-caused hard lockups, whereas latest stable kernel work
On Fri, Dec 29, 2017 at 02:09:40PM +0100, Thomas Gleixner wrote:
> On Fri, 29 Dec 2017, Alexandru Chirvasitu wrote:
> > All right, I tried to do some more digging around, in the hope of
> > getting as close to the source of the problem as I can.
> >
> > I went ba
> On Mon, Dec 25, 2017 at 1:29 PM, Alexandru Chirvasitu
> <achirva...@gmail.com> wrote:
> >
> > On Mon, Dec 25, 2017 at 06:40:14AM -0800, Andy Lutomirski wrote:
> >>
> >> This is presumably the same call-tracing-without-TLS-working problem.
> >&
= x86_vector_debug_show,
#endif
all is well.
On Fri, Dec 29, 2017 at 09:07:45AM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > On Fri, Dec 29, 2017 at 12:36:37AM +0100, Thomas Gleix
On Fri, Dec 29, 2017 at 06:49:15AM -0500, Alexandru Chirvasitu wrote:
> All right, I tried to do some more digging around, in the hope of
> getting as close to the source of the problem as I can.
>
> I went back to the very first commit that went astray for me, 2db1f95
> (which
ote:
> Quoting Alexandru Chirvasitu (2017-12-31 16:52:36)
> > I see lockdep is configured (though I'm not familiar with the feature;
> > the config came with it, and I made oldconfig), but I'll need to
> > recompile for kasan.
> >
> > I'll do that over the next few d
I'll try. I need a bit of clarification:
On Fri, Jan 05, 2018 at 05:52:25PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-03 21:53:15)
> > All right, here's the dmesg from the kernel compiled from drm-tip (in
> > sync with upstream at the time of the compilatio
Will do.
On Fri, Jan 05, 2018 at 08:02:48PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-05 19:58:42)
> > OK, I then plan to try with the previous config, plus these
> > modifications:
> >
> > CONFIG_PAGE_POISONING not set
> > CONFIG_S
Thank you!
I'll apply that more elaborate patch you sent in the longer message to
my clone of the repo and see if it still freezes.
On Sat, Jan 06, 2018 at 10:43:20AM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-05 22:05:18)
> > Here we go.
> &
On Sat, Jan 06, 2018 at 08:24:43AM -0500, Alexandru Chirvasitu wrote:
> Thank you!
>
> I'll apply that more elaborate patch you sent in the longer message to
> my clone of the repo and see if it still freezes.
>
I'm on it now with no freezes yet, despite trying my best :).
I
vs. stacking makes a difference?
The one pattern I noticed to the crashes was that they occurred upon
opening a new window.
On Sat, Jan 06, 2018 at 05:34:51PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-06 16:38:35)
> > On Sat, Jan 06, 2018 at 08:24:43AM -0500,
On Sat, Dec 23, 2017 at 02:32:52PM +0100, Thomas Gleixner wrote:
> On Sat, 23 Dec 2017, Dexuan Cui wrote:
>
> > > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > > Sent: Friday, December 22, 2017 14:29
> > >
> > > The output of that precise
.
The trace bears the 23:24:09 timestamp.
On Sat, Dec 23, 2017 at 01:35:12AM +, Dexuan Cui wrote:
> > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > Sent: Friday, December 22, 2017 14:29
> >
> > The output of that precise command run just now on a f
Thank you for the swift reply!
On Sat, Dec 23, 2017 at 07:30:21PM -0800, Linus Torvalds wrote:
> On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu
> <achirva...@gmail.com> wrote:
> >
> > For testing purposes, I've altered machine_kexec_32.c making the
> > fo
Short description: loading a crash kernel with (a) kexec -l [..] or
(b) kexec -p [..] and then testing it with (a) kexec -e or (b) echo c
> /proc/sysrq-trigger results in a regular reboot (going through BIOS,
etc.).
The commit that starts exhibiting this behaviour for me is
e802a51: x86/idt:
commit I can try to build so it will still
include the config options you mention?
I'm sure I'm just missing something obvious..
On Wed, Jan 03, 2018 at 12:49:10PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-03 00:14:38)
> > For comparison, here's another one produced by
OK, I then plan to try with the previous config, plus these
modifications:
CONFIG_PAGE_POISONING not set
CONFIG_SLUB_STATS=y
I'm a little puzzled about this:
On Fri, Jan 05, 2018 at 07:51:01PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-05 19:37:24)
> > I'll tr
ing Alexandru Chirvasitu (2018-01-06 18:44:29)
> > Thanks!
> >
> > It's also a mystery to me why I never had any crashes on any of the
> > other systems running on this machine running the same (unpatched)
> > kernels.
> >
> > I'm assuming the window manage
Thanks for that!
On Mon, Dec 25, 2017 at 06:40:14AM -0800, Andy Lutomirski wrote:
> On Sat, Dec 23, 2017 at 7:30 PM, Linus Torvalds
> <torva...@linux-foundation.org> wrote:
> > On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu
> > <achirva...@gmail.com> wrote:
, Dec 28, 2017 at 06:29:05PM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > On Thu, Dec 28, 2017 at 05:10:28PM +0100, Thomas Gleixner wrote:
> > > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > > > Actually, it decided to
ote:
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> >
> > > No; it seems to be tied to this specific issue, and I was seeing even
> > > before getting logs just now, whenever I'd start one of the bad
> > > kernels in recovery mode.
> > >
&
:19AM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Thomas Gleixner wrote:
>
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> >
> > > Attached.
> > >
> > > I don't have a 4.14 family kernel available at the moment on that
> > >
On Fri, Dec 29, 2017 at 12:36:37AM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
>
> > Attached, but heads up on this: when redirecting the output of lspci
> > -vvv to a text file as root I get
> >
> > pcilib: sysfs_read_vpd: r
On Thu, Dec 28, 2017 at 03:48:15PM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > On Thu, Dec 28, 2017 at 12:00:47PM +0100, Thomas Gleixner wrote:
> > > Ok, lets take a step back. The bisect/kexec attempts led us away from the
> >
On Thu, Dec 28, 2017 at 10:48:35AM -0500, Alexandru Chirvasitu wrote:
> On Thu, Dec 28, 2017 at 03:48:15PM +0100, Thomas Gleixner wrote:
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > > On Thu, Dec 28, 2017 at 12:00:47PM +0100, Thomas Gleixner wrote:
> > >
On Thu, Dec 28, 2017 at 06:15:19PM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 28, 2017 at 06:30:58PM -0500, Alexandru Chirvasitu wrote:
> > Attached, but heads up on this: when redirecting the output of lspci
> > -vvv to a text file as root I get
> >
> > pcilib: sysfs_r
else stayed the same, and booting the same kernel resulted
in the same type of freeze.
On Tue, Jan 02, 2018 at 04:39:22PM -0500, Alexandru Chirvasitu wrote:
> Attached. Crashed quite a bit faster than before this time.
>
> It always seems to have something to do with opening and al
Sounds like it's been pinned down then. Just confirming this:
On Tue, Dec 26, 2017 at 06:16:37PM -0800, Linus Torvalds wrote:
> On Tue, Dec 26, 2017 at 3:19 PM, Alexandru Chirvasitu
> <achirva...@gmail.com> wrote:
> >
> > I went back to the initial problematic com
On Thu, Dec 28, 2017 at 10:06:25AM +0800, Dou Liyang wrote:
> Hi Alexandru,
>
> Thanks for testing !
> At 12/28/2017 12:18 AM, Alexandru Chirvasitu wrote:
> > As per instructions, I did the following:
> >
> > (1)
> >
> > Checked out
> >
>
Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-03 14:48:26)
> > Here's the log for the make bzImage and modules without ccache.
> >
> > I ran it with j8 still because otherwise it would take very long, but
> > if I run out of options I'll try plain too..
> &
-0500, Alexandru Chirvasitu wrote:
> Thank you for that!
>
> I'd been getting used to seeing warnings to that effect, so got
> complacent and stopped checking for errors..
>
> In any case, it's now compiled and installed, and I will report back
> with any new logs if / whe
All right, we're in business with the new dmesg: It hung again, with a
4.15-rc6 kernel with kasan support.
The new dmesg is attached; the trace is longer now, as you expected.
And thanks!
On Sun, Dec 31, 2017 at 04:54:14PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2017-12-31
the focus had time to switch to the newly-opened terminal window.
Still unable to crash it reliably though, so there's no telling how
promptly I can produce these.
On Tue, Jan 02, 2018 at 04:53:45PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-01 21:13:57)
> > All rig
On Wed, Jan 03, 2018 at 01:47:56PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-03 13:46:42)
> > I've cloned your
> >
> > https://anongit.freedesktop.org/git/drm-tip.git
> >
> > and am now trying to build it (just the master; I h
vs. stacking makes a difference?
The one pattern I noticed to the crashes was that they occurred upon
opening a new window.
On Sat, Jan 06, 2018 at 05:34:51PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-06 16:38:35)
> > On Sat, Jan 06, 2018 at 08:24:43AM -0500,
ing Alexandru Chirvasitu (2018-01-06 18:44:29)
> > Thanks!
> >
> > It's also a mystery to me why I never had any crashes on any of the
> > other systems running on this machine running the same (unpatched)
> > kernels.
> >
> > I'm assuming the window manage
Thank you!
On Mon, Dec 18, 2017 at 11:11:31AM +0100, Pavel Machek wrote:
> Hi!
> On Mon 2017-12-18 03:20:11, Alexandru Chirvasitu wrote:
> > Short description of the problem: latest rc kernel results in seemingly
> > APIC-caused hard lockups, whereas latest stable kernel work
commit I can try to build so it will still
include the config options you mention?
I'm sure I'm just missing something obvious..
On Wed, Jan 03, 2018 at 12:49:10PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-03 00:14:38)
> > For comparison, here's another one produced by
On Wed, Jan 03, 2018 at 01:47:56PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-03 13:46:42)
> > I've cloned your
> >
> > https://anongit.freedesktop.org/git/drm-tip.git
> >
> > and am now trying to build it (just the master; I h
Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-03 14:48:26)
> > Here's the log for the make bzImage and modules without ccache.
> >
> > I ran it with j8 still because otherwise it would take very long, but
> > if I run out of options I'll try plain too..
> &
-0500, Alexandru Chirvasitu wrote:
> Thank you for that!
>
> I'd been getting used to seeing warnings to that effect, so got
> complacent and stopped checking for errors..
>
> In any case, it's now compiled and installed, and I will report back
> with any new logs if / whe
I'll try. I need a bit of clarification:
On Fri, Jan 05, 2018 at 05:52:25PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-03 21:53:15)
> > All right, here's the dmesg from the kernel compiled from drm-tip (in
> > sync with upstream at the time of the compilatio
OK, I then plan to try with the previous config, plus these
modifications:
CONFIG_PAGE_POISONING not set
CONFIG_SLUB_STATS=y
I'm a little puzzled about this:
On Fri, Jan 05, 2018 at 07:51:01PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-05 19:37:24)
> > I'll tr
Will do.
On Fri, Jan 05, 2018 at 08:02:48PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-05 19:58:42)
> > OK, I then plan to try with the previous config, plus these
> > modifications:
> >
> > CONFIG_PAGE_POISONING not set
> > CONFIG_S
Thank you!
I'll apply that more elaborate patch you sent in the longer message to
my clone of the repo and see if it still freezes.
On Sat, Jan 06, 2018 at 10:43:20AM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-05 22:05:18)
> > Here we go.
> &
On Sat, Jan 06, 2018 at 08:24:43AM -0500, Alexandru Chirvasitu wrote:
> Thank you!
>
> I'll apply that more elaborate patch you sent in the longer message to
> my clone of the repo and see if it still freezes.
>
I'm on it now with no freezes yet, despite trying my best :).
I
.
The trace bears the 23:24:09 timestamp.
On Sat, Dec 23, 2017 at 01:35:12AM +, Dexuan Cui wrote:
> > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > Sent: Friday, December 22, 2017 14:29
> >
> > The output of that precise command run just now on a f
On Sat, Dec 23, 2017 at 02:32:52PM +0100, Thomas Gleixner wrote:
> On Sat, 23 Dec 2017, Dexuan Cui wrote:
>
> > > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > > Sent: Friday, December 22, 2017 14:29
> > >
> > > The output of that precise
Short description: loading a crash kernel with (a) kexec -l [..] or
(b) kexec -p [..] and then testing it with (a) kexec -e or (b) echo c
> /proc/sysrq-trigger results in a regular reboot (going through BIOS,
etc.).
The commit that starts exhibiting this behaviour for me is
e802a51: x86/idt:
Thank you for the swift reply!
On Sat, Dec 23, 2017 at 07:30:21PM -0800, Linus Torvalds wrote:
> On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu
> wrote:
> >
> > For testing purposes, I've altered machine_kexec_32.c making the
> > following toy commit. It naivel
Thanks for that!
On Mon, Dec 25, 2017 at 06:40:14AM -0800, Andy Lutomirski wrote:
> On Sat, Dec 23, 2017 at 7:30 PM, Linus Torvalds
> wrote:
> > On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu
> > wrote:
> >>
> >> For testing purposes, I'
> On Mon, Dec 25, 2017 at 1:29 PM, Alexandru Chirvasitu
> wrote:
> >
> > On Mon, Dec 25, 2017 at 06:40:14AM -0800, Andy Lutomirski wrote:
> >>
> >> This is presumably the same call-tracing-without-TLS-working problem.
> >> idt_invalidate()
Sounds like it's been pinned down then. Just confirming this:
On Tue, Dec 26, 2017 at 06:16:37PM -0800, Linus Torvalds wrote:
> On Tue, Dec 26, 2017 at 3:19 PM, Alexandru Chirvasitu
> wrote:
> >
> > I went back to the initial problematic commit e802a51 and modified it a
On Thu, Dec 28, 2017 at 10:06:25AM +0800, Dou Liyang wrote:
> Hi Alexandru,
>
> Thanks for testing !
> At 12/28/2017 12:18 AM, Alexandru Chirvasitu wrote:
> > As per instructions, I did the following:
> >
> > (1)
> >
> > Checked out
> >
>
On Thu, Dec 28, 2017 at 03:48:15PM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > On Thu, Dec 28, 2017 at 12:00:47PM +0100, Thomas Gleixner wrote:
> > > Ok, lets take a step back. The bisect/kexec attempts led us away from the
> >
On Thu, Dec 28, 2017 at 10:48:35AM -0500, Alexandru Chirvasitu wrote:
> On Thu, Dec 28, 2017 at 03:48:15PM +0100, Thomas Gleixner wrote:
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > > On Thu, Dec 28, 2017 at 12:00:47PM +0100, Thomas Gleixner wrote:
> > >
, Dec 28, 2017 at 06:29:05PM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > On Thu, Dec 28, 2017 at 05:10:28PM +0100, Thomas Gleixner wrote:
> > > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > > > Actually, it decided to
ote:
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> >
> > > No; it seems to be tied to this specific issue, and I was seeing even
> > > before getting logs just now, whenever I'd start one of the bad
> > > kernels in recovery mode.
> > >
&
:19AM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Thomas Gleixner wrote:
>
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> >
> > > Attached.
> > >
> > > I don't have a 4.14 family kernel available at the moment on that
> > >
On Fri, Dec 29, 2017 at 12:36:37AM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
>
> > Attached, but heads up on this: when redirecting the output of lspci
> > -vvv to a text file as root I get
> >
> > pcilib: sysfs_read_vpd: r
On Thu, Dec 28, 2017 at 06:15:19PM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 28, 2017 at 06:30:58PM -0500, Alexandru Chirvasitu wrote:
> > Attached, but heads up on this: when redirecting the output of lspci
> > -vvv to a text file as root I get
> >
> > pcilib: sysfs_r
= x86_vector_debug_show,
#endif
all is well.
On Fri, Dec 29, 2017 at 09:07:45AM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > On Fri, Dec 29, 2017 at 12:36:37AM +0100, Thomas Gleix
On Fri, Dec 29, 2017 at 06:49:15AM -0500, Alexandru Chirvasitu wrote:
> All right, I tried to do some more digging around, in the hope of
> getting as close to the source of the problem as I can.
>
> I went back to the very first commit that went astray for me, 2db1f95
> (which
On Fri, Dec 29, 2017 at 02:09:40PM +0100, Thomas Gleixner wrote:
> On Fri, 29 Dec 2017, Alexandru Chirvasitu wrote:
> > All right, I tried to do some more digging around, in the hope of
> > getting as close to the source of the problem as I can.
> >
> > I went ba
ote:
> Quoting Alexandru Chirvasitu (2017-12-31 16:52:36)
> > I see lockdep is configured (though I'm not familiar with the feature;
> > the config came with it, and I made oldconfig), but I'll need to
> > recompile for kasan.
> >
> > I'll do that over the next few d
All right, we're in business with the new dmesg: It hung again, with a
4.15-rc6 kernel with kasan support.
The new dmesg is attached; the trace is longer now, as you expected.
And thanks!
On Sun, Dec 31, 2017 at 04:54:14PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2017-12-31
the focus had time to switch to the newly-opened terminal window.
Still unable to crash it reliably though, so there's no telling how
promptly I can produce these.
On Tue, Jan 02, 2018 at 04:53:45PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-01 21:13:57)
> > All rig
else stayed the same, and booting the same kernel resulted
in the same type of freeze.
On Tue, Jan 02, 2018 at 04:39:22PM -0500, Alexandru Chirvasitu wrote:
> Attached. Crashed quite a bit faster than before this time.
>
> It always seems to have something to do with opening and al
68 matches
Mail list logo