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 back to the very first commit that
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 back to the very first commit that
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 back to the very first commit that went astray for me, 2db1f95
> (which is the only one actually panicking),
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 back to the very first commit that went astray for me, 2db1f95
> (which is the only one actually panicking),
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 is the only one
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 is the only one
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 is the only one actually panicking), and tried to move from its
parent 90ad9e2 (that boots fine)
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 is the only one actually panicking), and tried to move from its
parent 90ad9e2 (that boots fine)
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> 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
> > >
>
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> 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
> > >
>
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_read_vpd: read failed:
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_read_vpd: read failed:
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_read_vpd: read failed: Input/output error
>
> I can find bugs filed for various distros to this same
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_read_vpd: read failed: Input/output error
>
> I can find bugs filed for various distros to this same
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: read failed: Input/output error
> >
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: read failed: Input/output error
> >
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: read failed: Input/output error
>
> I can find bugs filed for various distros to this same effect, but
>
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: read failed: Input/output error
>
> I can find bugs filed for various distros to this same effect, but
>
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: read failed: Input/output error
I can find bugs filed for various distros to this same effect, but
haven't tracked down any explanations.
On Fri, Dec 29, 2017 at
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: read failed: Input/output error
I can find bugs filed for various distros to this same effect, but
haven't tracked down any explanations.
On Fri, Dec 29, 2017 at
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
> > machine. What I'm attaching comes from the 4.13 one I was playing with
> > yesterday, what with kexec and
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
> > machine. What I'm attaching comes from the 4.13 one I was playing with
> > yesterday, what with kexec and
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> Attached.
>
> I don't have a 4.14 family kernel available at the moment on that
> machine. What I'm attaching comes from the 4.13 one I was playing with
> yesterday, what with kexec and all.
Good enough. Thanks !
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> Attached.
>
> I don't have a 4.14 family kernel available at the moment on that
> machine. What I'm attaching comes from the 4.13 one I was playing with
> yesterday, what with kexec and all.
Good enough. Thanks !
Attached.
I don't have a 4.14 family kernel available at the moment on that
machine. What I'm attaching comes from the 4.13 one I was playing with
yesterday, what with kexec and all.
On Thu, Dec 28, 2017 at 10:54:25PM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Thomas Gleixner wrote:
>
Attached.
I don't have a 4.14 family kernel available at the moment on that
machine. What I'm attaching comes from the 4.13 one I was playing with
yesterday, what with kexec and all.
On Thu, Dec 28, 2017 at 10:54:25PM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Thomas Gleixner wrote:
>
On Thu, 28 Dec 2017, Thomas Gleixner wrote:
> 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.
> >
> > But no, I've never
On Thu, 28 Dec 2017, Thomas Gleixner wrote:
> 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.
> >
> > But no, I've never
On Thu, 28 Dec 2017, Dexuan Cui wrote:
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > Sent: Thursday, December 28, 2017 03:03
> > > > On Wed, Dec 20, 2017 at 02:12:05AM +, Dexuan Cui wrote:
> >
> > > > For Linux VM running on Hyper-V, we did get "spurious APIC interrupt
> > > >
On Thu, 28 Dec 2017, Dexuan Cui wrote:
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > Sent: Thursday, December 28, 2017 03:03
> > > > On Wed, Dec 20, 2017 at 02:12:05AM +, Dexuan Cui wrote:
> >
> > > > For Linux VM running on Hyper-V, we did get "spurious APIC interrupt
> > > >
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Thursday, December 28, 2017 03:03
> > > On Wed, Dec 20, 2017 at 02:12:05AM +, Dexuan Cui wrote:
>
> > > For Linux VM running on Hyper-V, we did get "spurious APIC interrupt
> > > through vector " and a patchset, which included the
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Thursday, December 28, 2017 03:03
> > > On Wed, Dec 20, 2017 at 02:12:05AM +, Dexuan Cui wrote:
>
> > > For Linux VM running on Hyper-V, we did get "spurious APIC interrupt
> > > through vector " and a patchset, which included the
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.
>
> But no, I've never seen that in any other logs, or on any other
> screens
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.
>
> But no, I've never seen that in any other logs, or on any other
> screens
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.
But no, I've never seen that in any other logs, or on any other
screens outside of those popping up in relation to this problem.
On Thu,
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.
But no, I've never seen that in any other logs, or on any other
screens outside of those popping up in relation to this problem.
On Thu,
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 cooperate for just long enough for me to get
> > > the dmesg out. Attached.
> > >
> > > This is
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 cooperate for just long enough for me to get
> > > the dmesg out. Attached.
> > >
> > > This is
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> Actually, it decided to cooperate for just long enough for me to get
> the dmesg out. Attached.
>
> This is from the kernel you asked about: Dou's patch + yours, i.e. the
> latest one in that git log I just sent, booted up with 'apic=debug'.
Ok.
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> Actually, it decided to cooperate for just long enough for me to get
> the dmesg out. Attached.
>
> This is from the kernel you asked about: Dou's patch + yours, i.e. the
> latest one in that git log I just sent, booted up with 'apic=debug'.
Ok.
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:
> > > > Ok, lets take a step back.
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:
> > > > Ok, lets take a step back.
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
> > > initial problem which is
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
> > > initial problem which is
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
> > initial problem which is the machine locking up after login, right?
> >
>
> Yes; sorry about that..
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
> > initial problem which is the machine locking up after login, right?
> >
>
> Yes; sorry about that..
On Wed, 20 Dec 2017, Alexandru Chirvasitu wrote:
> Merging the contents of another exchange spawned from the original
> > On Wed, Dec 20, 2017 at 02:12:05AM +, Dexuan Cui wrote:
> > For Linux VM running on Hyper-V, we did get "spurious APIC interrupt
> > through vector " and a patchset,
On Wed, 20 Dec 2017, Alexandru Chirvasitu wrote:
> Merging the contents of another exchange spawned from the original
> > On Wed, Dec 20, 2017 at 02:12:05AM +, Dexuan Cui wrote:
> > For Linux VM running on Hyper-V, we did get "spurious APIC interrupt
> > through vector " and a patchset,
On Wed, 20 Dec 2017, Alexandru Chirvasitu wrote:
> On Wed, Dec 20, 2017 at 11:58:57AM +0800, Dou Liyang wrote:
> > At 12/20/2017 08:31 AM, Thomas Gleixner wrote:
> > > > I had never heard of 'bisect' before this casual mention (you might tell
> > > > I am a bit out of my depth). I've since applied
On Wed, 20 Dec 2017, Alexandru Chirvasitu wrote:
> On Wed, Dec 20, 2017 at 11:58:57AM +0800, Dou Liyang wrote:
> > At 12/20/2017 08:31 AM, Thomas Gleixner wrote:
> > > > I had never heard of 'bisect' before this casual mention (you might tell
> > > > I am a bit out of my depth). I've since applied
Hi Alexandru,
At 12/28/2017 10:51 AM, Alexandru Chirvasitu wrote:
Ah, of course. Attached is the output of `journalctl --boot=-1` after
booting, getting locked up, and then rebooting a good kernel.
For the Hard lockups on both CPUs after login:
Please try the patch in the attachment by
git
Hi Alexandru,
At 12/28/2017 10:51 AM, Alexandru Chirvasitu wrote:
Ah, of course. Attached is the output of `journalctl --boot=-1` after
booting, getting locked up, and then rebooting a good kernel.
For the Hard lockups on both CPUs after login:
Please try the patch in the attachment by
git
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
> >
> > 464e1d5 Linux 4.15-rc5
> >
> > (after getting my
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
> >
> > 464e1d5 Linux 4.15-rc5
> >
> > (after getting my
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
464e1d5 Linux 4.15-rc5
(after getting my copy up to date, fetching, pulling ,etc.) and
compiled it as-is. Config attached (the one labeled 'np'
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
464e1d5 Linux 4.15-rc5
(after getting my copy up to date, fetching, pulling ,etc.) and
compiled it as-is. Config attached (the one labeled 'np'
Hi Alexandru,
At 12/24/2017 04:01 AM, Alexandru Chirvasitu wrote:
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
Hi Alexandru,
At 12/24/2017 04:01 AM, Alexandru Chirvasitu wrote:
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
Hi Thomas,
At 12/23/2017 09:32 PM, Thomas Gleixner wrote:
[...]
The BUG_ON panic happens at line 147:
BUG_ON(!test_and_clear_bit(bit, cm->alloc_map));
I'm sure Thomas and Dou know it better than me.
I'll have a look after the holidays.
Merry Christmas! :-)
I am
Hi Thomas,
At 12/23/2017 09:32 PM, Thomas Gleixner wrote:
[...]
The BUG_ON panic happens at line 147:
BUG_ON(!test_and_clear_bit(bit, cm->alloc_map));
I'm sure Thomas and Dou know it better than me.
I'll have a look after the holidays.
Merry Christmas! :-)
I am
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 command run just now on a freshly-compiled
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 command run just now on a freshly-compiled
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 command run just now on a freshly-compiled
> > copy of that commit is attached.
> >
> > On Fri, Dec 22, 2017 at
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 command run just now on a freshly-compiled
> > copy of that commit is attached.
> >
> > On Fri, Dec 22, 2017 at
I was just now trying to track down my other issue, whereby somewhere
along the tree kexec stops working properly. In the process of doing
that I realized I had initially made one change to the original 4.9
config beyond oldconfig: I'd turned off WX debugging.
I've now compiled a bunch of
I was just now trying to track down my other issue, whereby somewhere
along the tree kexec stops working properly. In the process of doing
that I realized I had initially made one change to the original 4.9
config beyond oldconfig: I'd turned off WX debugging.
I've now compiled a bunch of
> 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 freshly-compiled
> copy of that commit is attached.
>
> On Fri, Dec 22, 2017 at 09:31:28PM +, Dexuan Cui wrote:
> > > From: Alexandru
> 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 freshly-compiled
> copy of that commit is attached.
>
> On Fri, Dec 22, 2017 at 09:31:28PM +, Dexuan Cui wrote:
> > > From: Alexandru
> From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> Sent: Friday, December 22, 2017 06:21
>
> In the absence of logs, the best I can do at the moment is attach a
> picture of the screen I am presented with on the apic=debug boot
> attempt.
> Alex
The panic happens in
> From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> Sent: Friday, December 22, 2017 06:21
>
> In the absence of logs, the best I can do at the moment is attach a
> picture of the screen I am presented with on the apic=debug boot
> attempt.
> Alex
The panic happens in
Hi Alexandru,
At 12/21/2017 10:23 AM, Alexandru Chirvasitu wrote:
This might be more helpful. I ran another bisect with the following
final log:
---
git bisect start
# bad: [d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c] x86/vector: Respect affinity
mask in irq descriptor
git bisect bad
Hi Alexandru,
At 12/21/2017 10:23 AM, Alexandru Chirvasitu wrote:
This might be more helpful. I ran another bisect with the following
final log:
---
git bisect start
# bad: [d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c] x86/vector: Respect affinity
mask in irq descriptor
git bisect bad
Hi Thomas,
At 12/20/2017 08:31 AM, Thomas Gleixner wrote:
On Tue, 19 Dec 2017, Alexandru Chirvasitu wrote:
I had never heard of 'bisect' before this casual mention (you might tell
I am a bit out of my depth). I've since applied it to Linus' tree between
bebc608 Linux 4.14 (good)
and
Hi Thomas,
At 12/20/2017 08:31 AM, Thomas Gleixner wrote:
On Tue, 19 Dec 2017, Alexandru Chirvasitu wrote:
I had never heard of 'bisect' before this casual mention (you might tell
I am a bit out of my depth). I've since applied it to Linus' tree between
bebc608 Linux 4.14 (good)
and
On Tue, 19 Dec 2017, Alexandru Chirvasitu wrote:
> I had never heard of 'bisect' before this casual mention (you might tell
> I am a bit out of my depth). I've since applied it to Linus' tree between
> bebc608 Linux 4.14 (good)
>
> and
>
> 4fbd8d1 Linux 4.15-rc1 (bad)
Is Linus current head
On Tue, 19 Dec 2017, Alexandru Chirvasitu wrote:
> I had never heard of 'bisect' before this casual mention (you might tell
> I am a bit out of my depth). I've since applied it to Linus' tree between
> bebc608 Linux 4.14 (good)
>
> and
>
> 4fbd8d1 Linux 4.15-rc1 (bad)
Is Linus current head
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 works fine.
> >
> > I
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 works fine.
> >
> > I
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 works fine.
>
> I have an old ASUS F5RL laptop with an Intel Core 2 Duo CPU T5450 @1.66GHz.
> It is
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 works fine.
>
> I have an old ASUS F5RL laptop with an Intel Core 2 Duo CPU T5450 @1.66GHz.
> It is
80 matches
Mail list logo
