Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1350514 > unrolled thread

Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-03-04 19:40 +0100
    Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-04 22:30 +0100
      Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-03-07 01:40 +0100
        Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-07 16:20 +0100
          Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-07 23:50 +0100
            Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-03-08 01:00 +0100
              Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-08 01:10 +0100
                Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-08 01:50 +0100
                  Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-03-08 04:30 +0100
                    Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-08 16:50 +0100
                  Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-03-10 15:50 +0100
                    Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-10 17:00 +0100
                      Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Borislav Petkov <bp@suse.de> - 2016-03-10 18:30 +0100
                        Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-03-10 20:10 +0100
                          Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-10 20:20 +0100
                          Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Borislav Petkov <bp@suse.de> - 2016-03-10 20:30 +0100
                            Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-03-11 14:30 +0100
                              Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Borislav Petkov <bp@suse.de> - 2016-03-11 14:50 +0100
                                Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paolo Bonzini <pbonzini@redhat.com> - 2016-03-11 20:20 +0100
                                  Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Borislav Petkov <bp@suse.de> - 2016-03-11 23:20 +0100
                                    Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Bruce Ashfield <bruce.ashfield@windriver.com> - 2016-03-11 23:30 +0100
                                      Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Richard Purdie <richard.purdie@linuxfoundation.org> - 2016-03-12 00:50 +0100
                                        Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Borislav Petkov <bp@suse.de> - 2016-03-12 13:10 +0100
                        Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-10 20:20 +0100
                          Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Borislav Petkov <bp@suse.de> - 2016-03-10 20:30 +0100
                            Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-10 20:40 +0100
                              Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Borislav Petkov <bp@suse.de> - 2016-03-10 22:10 +0100
                                Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-10 23:30 +0100
                Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-03-08 04:20 +0100
                  Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-08 16:30 +0100
                    Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Toshi Kani <toshi.kani@hpe.com> - 2016-03-08 17:10 +0100
                    Re: runtime regression with "x86/mm/pat: Emulate PAT when it is  disabled" Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-03-08 17:10 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1356238

On 2016-03-11 5:16 PM, Borislav Petkov wrote:
> On Fri, Mar 11, 2016 at 08:18:23PM +0100, Paolo Bonzini wrote:
>> Somebody got it wrong 10-ish years ago, and nobody has ever checked since.
>>
>> But, don't use qemu32 or qemu64.  Use kvm32 and kvm64, or better
>> something like the host you run on ("-cpu Nehalem", "-cpu SandyBridge",
>> "-cpu Haswell-noTSX" etc.).
>
> Paul, Richard, how about it?

I'm not Paul/Richard, but I can answer :)

We want a more generic cpu for these qemu references. Something that
doesn't vary, since it runs on any number of hosts. There are some
horrible issues we've had to solve with -cpu host in the past.

Switching to the kvm cpu type should work, plus we can add cpu
extensions on the fly as necessary.

That's definitely a valid outcome from this discussion .. a cpu
type that doesn't shoot through the middle of the expected
capabilities .. and a bonus if the kernel or qemu can be tweaked
to survive a similar mix up in the flags in the future.

Cheers,

Bruce

>
>> I really, really should fix those defaults...
>
> Here's a start, while I have everything fresh in my head.
>
> ---
> From: Borislav Petkov <bp@suse.de>
> Date: Fri, 11 Mar 2016 23:11:05 +0100
> Subject: [PATCH] target-i386/cpu: Correct MTRR and PAT feature bits
>
> Pentium Pro had MTRRs but not PAT, PAT support appeared in Pentium III.
> Fix all defines.
>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> ---
>   target-i386/cpu.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index 0f38d1eae317..fa7ea4a8c229 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -308,12 +308,12 @@ static const char *cpuid_6_feature_name[] = {
>   #define PENTIUM_FEATURES (I486_FEATURES | CPUID_DE | CPUID_TSC | \
>             CPUID_MSR | CPUID_MCE | CPUID_CX8 | CPUID_MMX | CPUID_APIC)
>   #define PENTIUM2_FEATURES (PENTIUM_FEATURES | CPUID_PAE | CPUID_SEP | \
> -          CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT | \
> +          CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | \
>             CPUID_PSE36 | CPUID_FXSR)
> -#define PENTIUM3_FEATURES (PENTIUM2_FEATURES | CPUID_SSE)
> +#define PENTIUM3_FEATURES (PENTIUM2_FEATURES | CPUID_SSE | CPUID_PAT)
>   #define PPRO_FEATURES (CPUID_FP87 | CPUID_DE | CPUID_PSE | CPUID_TSC | \
>             CPUID_MSR | CPUID_MCE | CPUID_CX8 | CPUID_PGE | CPUID_CMOV | \
> -          CPUID_PAT | CPUID_FXSR | CPUID_MMX | CPUID_SSE | CPUID_SSE2 | \
> +          CPUID_MTRR | CPUID_FXSR | CPUID_MMX | CPUID_SSE | CPUID_SSE2 | \
>             CPUID_PAE | CPUID_SEP | CPUID_APIC)
>
>   #define TCG_FEATURES (CPUID_FP87 | CPUID_PSE | CPUID_TSC | CPUID_MSR | \
>

[toc] | [prev] | [next] | [standalone]

#1356290

On Fri, 2016-03-11 at 17:28 -0500, Bruce Ashfield wrote:
> On 2016-03-11 5:16 PM, Borislav Petkov wrote:
> > On Fri, Mar 11, 2016 at 08:18:23PM +0100, Paolo Bonzini wrote:
> > > Somebody got it wrong 10-ish years ago, and nobody has ever
> > > checked since.
> > > 
> > > But, don't use qemu32 or qemu64.  Use kvm32 and kvm64, or better
> > > something like the host you run on ("-cpu Nehalem", "-cpu
> > > SandyBridge",
> > > "-cpu Haswell-noTSX" etc.).
> > 
> > Paul, Richard, how about it?
> 
> I'm not Paul/Richard, but I can answer :)
> 
> We want a more generic cpu for these qemu references. Something that
> doesn't vary, since it runs on any number of hosts. There are some
> horrible issues we've had to solve with -cpu host in the past.
> 
> Switching to the kvm cpu type should work, plus we can add cpu
> extensions on the fly as necessary.
> 
> That's definitely a valid outcome from this discussion .. a cpu
> type that doesn't shoot through the middle of the expected
> capabilities .. and a bonus if the kernel or qemu can be tweaked
> to survive a similar mix up in the flags in the future.

We'll have to go and trawl our commit logs to figure out how we ended
up with choosing qemuXX, I do remember everything else we tried
previously broke in some way. We do need something which works on quite
a wide variety of systems and if I remember rightly, the CPU features
the kvm* options provide vary quite widely and wasn't consistent. The
qemu* ones at least consistently broke everywhere! :)

Tweaking the kernel to only enable PAT with MTRR sounds like a good
fix, as does fixing the qemu cpu feature bits and I'd like to get those
patches into our builds once they're heading into the upstreams.
Meanwhile we'll see if we can find a better cpu option as well.

Cheers,

Richard

[toc] | [prev] | [next] | [standalone]

#1356411

On Fri, Mar 11, 2016 at 11:29:54PM +0000, Richard Purdie wrote:
> ... and if I remember rightly, the CPU features the kvm* options
> provide vary quite widely and wasn't consistent.

How so? Please elaborate so that we can fix those.

Btw, your reproducer works fine with -cpu kvm32 - only vncviewer's
window gets killed after a "Rect too large: 640x480 at (0, 0)" but
when I reconnect again right after it I see an X window asking me to
calibrate my touch screen and I'm at a loss as to where my touch screen
is... :-P

> Tweaking the kernel to only enable PAT with MTRR sounds like a good
> fix,

Yeah, the idea is to basically switch to uncacheable memtype as when
MTRRs are disabled.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1355335

On Thu, 2016-03-10 at 18:20 +0100, Borislav Petkov wrote:
> On Thu, Mar 10, 2016 at 09:49:51AM -0700, Toshi Kani wrote:
> > This confirms the issue - QEMU's virtual Intel CPU does not support
> > MTRR. 
> > 
> > When MTRR is disabled, the kernel does not call pat_init().
> >  pat_enabled() is still set to true when CONFIG_X86_PAT is set.
> >  CONFIG_X86_PAT depends on CONFIG_MTRR, and assumes that MTRR is
> > enabled. 
> 
> Aha, so "qemu32" model doesn't support MTRRs but "kvm32" does, for
> example. And so do the majority of the other CPU types.
> 
> Paul, can you guys run with something else besides "qemu32"? You can
> even take a 64-bit one and run a 32-bit guest on it.
> 
> :-)
> 

I will send a patch that sets PAT disabled when MTRR is disabled.  This
will solve the Paul's issue.  His qemu32 model does not support PAT,
either.

Ideally, PAT and MTRR features should be managed independently, but this
will require much more effort and will not be easily applied to stable.

Thanks,
-Toshi

[toc] | [prev] | [next] | [standalone]

#1355341

On Thu, Mar 10, 2016 at 01:04:21PM -0700, Toshi Kani wrote:
> I will send a patch that sets PAT disabled when MTRR is disabled.  This
> will solve the Paul's issue.  His qemu32 model does not support PAT,
> either.

It does, see my other mail. We need to figure out first why is
pat_init() being called as part of MTRR setup.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1355348

On Thu, 2016-03-10 at 20:20 +0100, Borislav Petkov wrote:
> On Thu, Mar 10, 2016 at 01:04:21PM -0700, Toshi Kani wrote:
> > I will send a patch that sets PAT disabled when MTRR is disabled.  This
> > will solve the Paul's issue.  His qemu32 model does not support PAT,
> > either.
> 
> It does, see my other mail. We need to figure out first why is
> pat_init() being called as part of MTRR setup.

I am not familiar with PPRO_FEATURES, but shouldn't 'flags' in
/proc/cpuinfo show "pat" when X86_FEATURE_PAT is set?

pat_init() is being called as part of MTRR setup because PAT initialization
requires the same CPU rendezvous operation implemented in the MTRR code.

Thanks,
-Toshi

[toc] | [prev] | [next] | [standalone]

#1355383

On Thu, Mar 10, 2016 at 01:24:11PM -0700, Toshi Kani wrote:
> I am not familiar with PPRO_FEATURES,

That's the feature bits of the "qemu32" model, and others, in qemu.

> but shouldn't 'flags' in /proc/cpuinfo show "pat" when X86_FEATURE_PAT is set?

static void early_init_intel(struct cpuinfo_x86 *c)
...

        /*
         * There is a known erratum on Pentium III and Core Solo
         * and Core Duo CPUs.
         * " Page with PAT set to WC while associated MTRR is UC
         *   may consolidate to UC "
         * Because of this erratum, it is better to stick with
         * setting WC in MTRR rather than using PAT on these CPUs.
         *
         * Enable PAT WC only on P4, Core 2 or later CPUs.
         */
        if (c->x86 == 6 && c->x86_model < 15)
                clear_cpu_cap(c, X86_FEATURE_PAT);
---

which also gives a hint as to how we should fix this: pat_enabled()
needs to look at that feature bit too:

---
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index faec01e7a17d..359c30d9a78c 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -56,7 +56,7 @@ early_param("nopat", nopat);
 
 bool pat_enabled(void)
 {
-	return !!__pat_enabled;
+	return !!__pat_enabled && static_cpu_has(X86_FEATURE_PAT);
 }
 EXPORT_SYMBOL_GPL(pat_enabled);
---

Makes sense?

> pat_init() is being called as part of MTRR setup because PAT
> initialization requires the same CPU rendezvous operation implemented
> in the MTRR code.

... which means, PAT depends on MTRR being present.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1355429

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2016-03-10 at 22:07 +0100, Borislav Petkov wrote:
> On Thu, Mar 10, 2016 at 01:24:11PM -0700, Toshi Kani wrote:
> > I am not familiar with PPRO_FEATURES,
> 
> That's the feature bits of the "qemu32" model, and others, in qemu.
> 
> > but shouldn't 'flags' in /proc/cpuinfo show "pat" when X86_FEATURE_PAT
> > is set?
> 
> static void early_init_intel(struct cpuinfo_x86 *c)
> ...
> 
>         /*
>          * There is a known erratum on Pentium III and Core Solo
>          * and Core Duo CPUs.
>          * " Page with PAT set to WC while associated MTRR is UC
>          *   may consolidate to UC "
>          * Because of this erratum, it is better to stick with
>          * setting WC in MTRR rather than using PAT on these CPUs.
>          *
>          * Enable PAT WC only on P4, Core 2 or later CPUs.
>          */
>         if (c->x86 == 6 && c->x86_model < 15)
>                 clear_cpu_cap(c, X86_FEATURE_PAT);
> ---
> 
> which also gives a hint as to how we should fix this: pat_enabled()
> needs to look at that feature bit too:

I see.  I will take a look.

> ---
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index faec01e7a17d..359c30d9a78c 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -56,7 +56,7 @@ early_param("nopat", nopat);
>  
>  bool pat_enabled(void)
>  {
> -	return !!__pat_enabled;
> +	return !!__pat_enabled && static_cpu_has(X86_FEATURE_PAT);
>  }
>  EXPORT_SYMBOL_GPL(pat_enabled);
> ---
> 
> Makes sense?

Yes, I agree that pat_enable() needs to check the PAT feature bit.  In some
reason, static_cpu_has(X86_FEATURE_PAT) returns 0 while cpu_has_pat returns
1 in my testing...  I need to check this.

> > pat_init() is being called as part of MTRR setup because PAT
> > initialization requires the same CPU rendezvous operation implemented
> > in the MTRR code.
> 
> ... which means, PAT depends on MTRR being present.

Yes, and we need more changes to handle this dependency since MTRR does not
call pat_init() when it is disabled.

Attached is the changes I am working now.  I will include your changes, and
send them out once I finished testing.  Let me know if you have any
suggestion.

Thanks,
-Toshi

[toc] | [prev] | [next] | [standalone]

#1352594

[Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"] On 07/03/2016 (Mon 17:56) Toshi Kani wrote:

[..]


> > > It may have seemed working before, but you did not have WC configured
> > > to PAT without calling pat_init().  There was not a proper check in
> > > place to detect this error before.  Can you please check your code to
> > > see what caused this skip of pat_init()?  If you have a git tree, I can
> > > take a look as well. 
> > 
> > You already have git copies of what I'm running, since it is vanilla
> > mainline commits.  No code changes at this end whatsoever.  I did the
> > bisect on vanilla mainline.  All I took from yocto was their ".config"
> > 
> > To recap, v4.1-rc5-21-g9dac62909451 works,  v4.1-rc5-22-g9cd25aac1f44
> > fails, and v4.5-rc6 also fails.  If pat_init() isn't called then this
> > is a bug in current mainline.  I'll have a look later myself and see
> > if I can trace out how we expect to get to pat_init() and how that
> > might be skipped inadvertently unless someone beats me to it.
> 
> Oh, I see.  Can you send me the ".config" file?

I packaged the .config file for every bisect point in the original
reproducer tarball.  Let me know if you can't find them.  It should
look like this:

paul@dell760-paul:~/qemu-fail$ ls -al 00-configs/
total 92
drwxrwxr-x 23 paul paul 4096 Mar  3 10:59 .
drwxrwxr-x  5 paul paul 4096 Mar  3 11:01 ..
-rw-rw-r--  1 paul paul    0 Mar  3 10:59 00-all-dot-configs-are-in-here
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-1281-g43224b96af31
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-1625-g44d21c3f3a2e
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-3251-g4e241557fc1c
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-6547-g4570a37169d4
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-912-ge75c73ad6447
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc4-85-gd4688bdc6335
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-21-g9dac62909451
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-22-g9cd25aac1f44
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-23-g7202fdb1b329
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-27-gd838270e2516
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-35-g7ea402d01cb6
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc6-256-g9dda1658a9bd
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc6-296-g7ef3d7d58d9d
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.2
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.2-rc1
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.3
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4.1
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4.1-348-g0194c7658611
drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.5-rc6
paul@dell760-paul:~/qemu-fail$ 

Please check if they are present in the reproducer you downloaded.
Maybe somehow I uploaded a version without the config files.

Thanks,
Paul.
--

> 
> Thanks,
> -Toshi

[toc] | [prev] | [next] | [standalone]

#1353141

On Mon, 2016-03-07 at 22:16 -0500, Paul Gortmaker wrote:
> [Re: runtime regression with "x86/mm/pat: Emulate PAT when it is
> disabled"] On 07/03/2016 (Mon 17:56) Toshi Kani wrote:
> 
> [..]
> 
> 
> > > > It may have seemed working before, but you did not have WC
> > > > configured
> > > > to PAT without calling pat_init().  There was not a proper check in
> > > > place to detect this error before.  Can you please check your code
> > > > to
> > > > see what caused this skip of pat_init()?  If you have a git tree, I
> > > > can
> > > > take a look as well. 
> > > 
> > > You already have git copies of what I'm running, since it is vanilla
> > > mainline commits.  No code changes at this end whatsoever.  I did the
> > > bisect on vanilla mainline.  All I took from yocto was their
> > > ".config"
> > > 
> > > To recap, v4.1-rc5-21-g9dac62909451 works,  v4.1-rc5-22-g9cd25aac1f44
> > > fails, and v4.5-rc6 also fails.  If pat_init() isn't called then this
> > > is a bug in current mainline.  I'll have a look later myself and see
> > > if I can trace out how we expect to get to pat_init() and how that
> > > might be skipped inadvertently unless someone beats me to it.
> > 
> > Oh, I see.  Can you send me the ".config" file?
> 
> I packaged the .config file for every bisect point in the original
> reproducer tarball.  Let me know if you can't find them.  It should
> look like this:
> 
> paul@dell760-paul:~/qemu-fail$ ls -al 00-configs/
> total 92
> drwxrwxr-x 23 paul paul 4096 Mar  3 10:59 .
> drwxrwxr-x  5 paul paul 4096 Mar  3 11:01 ..
> -rw-rw-r--  1 paul paul    0 Mar  3 10:59 00-all-dot-configs-are-in-here
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-1281-g43224b96af31
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-1625-g44d21c3f3a2e
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-3251-g4e241557fc1c
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-6547-g4570a37169d4
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-912-ge75c73ad6447
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc4-85-gd4688bdc6335
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-21-g9dac62909451
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-22-g9cd25aac1f44
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-23-g7202fdb1b329
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-27-gd838270e2516
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-35-g7ea402d01cb6
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc6-256-g9dda1658a9bd
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc6-296-g7ef3d7d58d9d
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.2
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.2-rc1
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.3
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4.1
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4.1-348-g0194c7658611
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.5-rc6
> paul@dell760-paul:~/qemu-fail$ 
> 
> Please check if they are present in the reproducer you downloaded.
> Maybe somehow I uploaded a version without the config files.

Yes, I have these directories, but I do not see anything under them...  Now
that I do not think there is anything unique in your .config file, but it'd
be still good to check.  Please send me .config file for v4.5-rc6 (if you
do not have it now, .config for other ver is OK as well).

$ ls -Rl
.:
total 84
-rw-rw-r--. 1 toshi toshi    0 Mar  3 08:59 00-all-dot-configs-are-in-here
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-1281-g43224b96af31
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-1625-g44d21c3f3a2e
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-3251-g4e241557fc1c
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-6547-g4570a37169d4
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-912-ge75c73ad6447
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc4-85-gd4688bdc6335
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-21-g9dac62909451
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-22-g9cd25aac1f44
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-23-g7202fdb1b329
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-27-gd838270e2516
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-35-g7ea402d01cb6
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc6-256-g9dda1658a9bd
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc6-296-g7ef3d7d58d9d
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.2
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.2-rc1
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.3
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4.1
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4.1-348-g0194c7658611
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.5-rc6

./v4.1:
total 0

./v4.1-1281-g43224b96af31:
total 0

./v4.1-1625-g44d21c3f3a2e:
total 0

./v4.1-3251-g4e241557fc1c:
total 0
./v4.1-6547-g4570a37169d4:
total 0

./v4.1-912-ge75c73ad6447:
total 0

./v4.1-rc4-85-gd4688bdc6335:
total 0

./v4.1-rc5-21-g9dac62909451:
total 0

./v4.1-rc5-22-g9cd25aac1f44:
total 0

./v4.1-rc5-23-g7202fdb1b329:
total 0

./v4.1-rc5-27-gd838270e2516:
total 0
./v4.1-rc5-35-g7ea402d01cb6:
total 0

./v4.1-rc6-256-g9dda1658a9bd:
total 0

./v4.1-rc6-296-g7ef3d7d58d9d:
total 0

./v4.2:
total 0

./v4.2-rc1:
total 0

./v4.3:
total 0

./v4.4:
total 0
./v4.4.1:
total 0

./v4.4.1-348-g0194c7658611:
total 0

./v4.5-rc6:
total 0

Thanks,
-Toshi

[toc] | [prev] | [next] | [standalone]

#1353177

On Tue, 2016-03-08 at 11:03 -0500, Paul Gortmaker wrote:
> [Re: runtime regression with "x86/mm/pat: Emulate PAT when it is
> disabled"] On 08/03/2016 (Tue 09:13) Toshi Kani wrote:
> 
> [...]
> 
> > 
> > Yes, I have these directories, but I do not see anything under them...
> >  Now
> > that I do not think there is anything unique in your .config file, but
> > it'd
> > be still good to check.  Please send me .config file for v4.5-rc6 (if
> > you
> > do not have it now, .config for other ver is OK as well).
> > 
> > $ ls -Rl
> 
> Try "ls -aRl" -- they are _dot_ config files.  I did not rename them.

Ah! Thanks, I see them now. :-)
-Toshi

[toc] | [prev] | [next] | [standalone]

#1353181

[Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"] On 08/03/2016 (Tue 09:13) Toshi Kani wrote:

[...]

> 
> Yes, I have these directories, but I do not see anything under them...  Now
> that I do not think there is anything unique in your .config file, but it'd
> be still good to check.  Please send me .config file for v4.5-rc6 (if you
> do not have it now, .config for other ver is OK as well).
> 
> $ ls -Rl

Try "ls -aRl" -- they are _dot_ config files.  I did not rename them.

Paul.
--

> .:
> total 84
> -rw-rw-r--. 1 toshi toshi    0 Mar  3 08:59 00-all-dot-configs-are-in-here
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-1281-g43224b96af31
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-1625-g44d21c3f3a2e
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-3251-g4e241557fc1c
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-6547-g4570a37169d4
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-912-ge75c73ad6447
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc4-85-gd4688bdc6335
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-21-g9dac62909451
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-22-g9cd25aac1f44
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-23-g7202fdb1b329
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-27-gd838270e2516
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-35-g7ea402d01cb6
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc6-256-g9dda1658a9bd
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc6-296-g7ef3d7d58d9d
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.2
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.2-rc1
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.3
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4.1
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4.1-348-g0194c7658611
> drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.5-rc6
> 
> ./v4.1:
> total 0
> 
> ./v4.1-1281-g43224b96af31:
> total 0
> 
> ./v4.1-1625-g44d21c3f3a2e:
> total 0
> 
> ./v4.1-3251-g4e241557fc1c:
> total 0
> ./v4.1-6547-g4570a37169d4:
> total 0
> 
> ./v4.1-912-ge75c73ad6447:
> total 0
> 
> ./v4.1-rc4-85-gd4688bdc6335:
> total 0
> 
> ./v4.1-rc5-21-g9dac62909451:
> total 0
> 
> ./v4.1-rc5-22-g9cd25aac1f44:
> total 0
> 
> ./v4.1-rc5-23-g7202fdb1b329:
> total 0
> 
> ./v4.1-rc5-27-gd838270e2516:
> total 0
> ./v4.1-rc5-35-g7ea402d01cb6:
> total 0
> 
> ./v4.1-rc6-256-g9dda1658a9bd:
> total 0
> 
> ./v4.1-rc6-296-g7ef3d7d58d9d:
> total 0
> 
> ./v4.2:
> total 0
> 
> ./v4.2-rc1:
> total 0
> 
> ./v4.3:
> total 0
> 
> ./v4.4:
> total 0
> ./v4.4.1:
> total 0
> 
> ./v4.4.1-348-g0194c7658611:
> total 0
> 
> ./v4.5-rc6:
> total 0
> 
> Thanks,
> -Toshi
> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web