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
= 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 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
> > >
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
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 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 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!
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
14 matches
Mail list logo
