lkml.org 
[lkml]   [2018]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Regression: x86/tsc: Fix mark_tsc_unstable()
From
Date


On 06/11/2018 03:23 PM, Diego Viola wrote:
> On Mon, Jun 11, 2018 at 3:11 PM, Jeremy Cline <jeremy@jcline.org> wrote:
>> On 06/11/2018 01:56 PM, Jeremy Cline wrote:
>>> On 06/11/2018 11:30 AM, Peter Zijlstra wrote:
>>>> On Mon, Jun 11, 2018 at 04:38:01PM +0200, Peter Zijlstra wrote:
>>>>> On Mon, Jun 11, 2018 at 04:17:42PM +0200, Peter Zijlstra wrote:
>>>>>> On Mon, Jun 11, 2018 at 01:59:15PM +0000, Jeremy Cline wrote:
>>>>>>> A user has bisected the problem to the v4.16 commit 1ab4ca7c59d4
>>>>>>> ("x86/tsc: Fix mark_tsc_unstable()"). According to the reporter,
>>>>>>> explicitly setting "tsc=" on the kernel command line causes the boot to
>>>>>>> always succeed. All the users have Thinkpad T500s or T400s (Core 2 Duos)
>>>>>>
>>>>>> Weird. So Core2 typically triggers mark_tsc_unstable() in either
>>>>>> intel_idle or processor_idle. ISTR testing that when I did the patches.
>>>>>>
>>>>>> When I make that mark_tsc_unstable() in the idle drivers unconditional
>>>>>> and boot my ivb with that, it doesn't want to fail. I've booted the
>>>>>> machine 5 consequctive times without issue.
>>>>>>
>>>>>> Let me try and checkout -stable, maybe something's up with that.
>>>>>
>>>>> Nope -stable seems to be working as well on the IVB (with modification).
>>>>> I just dug up my T500 and that's actually still running the test kernel.
>>>>> Let me try and build the -stable kernel for that.
>>>>
>>>> 4.16.8 works without issue on my T500 with a debian/ubuntu like distro
>>>> config.
>>>>
>>>
>>> Adding mmarget (who bisected the problem) to the CC.
>>>
>>> It might well be something Fedora-specific, then. I just noticed mmarget
>>> commented over the weekend noting that they couldn't reproduce the
>>> problem without using the initramfs generated during the RPM install of
>>> the kernel. mmarget's theory was that it's a race condition that doesn't
>>> occur when the initramfs takes long enough to unpack, but I don't know
>>> enough about the early boot process *or* how Fedora's generating the
>>> initramfs for RPM installs vs "make install" yet to know how likely that
>>> is. I'm going to have to do some research.
>>>
>>> Thanks for looking into this so quickly and also sorry if this turns out
>>> to be a Fedora problem :(
>>
>> Attached is the Fedora configuration for 4.16.8, as well, in case you'd
>> like to test it with that.
>>
>> Thanks,
>> Jeremy
>
> Hi Jeremy,
>
> I've compiled 4.16.8 with your config and booted my machine about 10
> times with this kernel, and I'm unable to reproduce the issue.

Thanks for confirming.

>
> Maybe it's an issue with the Fedora initramfs?

Indeed, I'll dig into what exactly is different about the RPM-created
initramfs and the one created with "make install" to see if we can
narrow this down some more.

Thanks,
Jeremy

\
 
 \ /
  Last update: 2018-06-11 23:31    [W:0.050 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site