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
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
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,
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, 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
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
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.
> &
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.
> &
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
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
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
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
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
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
-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
-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
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..
> &
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..
> &
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
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
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
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
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
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
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
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
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
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
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
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
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 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 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 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
= 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
= 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 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
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
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 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
: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
> > >
: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
> > >
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.
> > >
&
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.
> > >
&
, 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
, 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
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 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 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 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: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 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
> >
>
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
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 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.
> >&
> 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()
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:
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'
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
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
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:
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:
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
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
.
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!
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
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
68 matches
Mail list logo
