On 4 March 2014 17:44, Borislav Petkov wrote:
> On Tue, Mar 04, 2014 at 01:06:03PM +0700, Chris Bainbridge wrote:
>> On Mon, Mar 03, 2014 at 09:04:19PM -0800, H. Peter Anvin wrote:
>> > forcepae is descriptive.
>>
>> Back to forcepae.
>
> Ok, it looks ok to me after a quick look. Now you only
On Tue, Mar 04, 2014 at 01:06:03PM +0700, Chris Bainbridge wrote:
> On Mon, Mar 03, 2014 at 09:04:19PM -0800, H. Peter Anvin wrote:
> > forcepae is descriptive.
>
> Back to forcepae.
Ok, it looks ok to me after a quick look. Now you only have to ask
Dave whether he's fine with you merging his
On Tue, Mar 04, 2014 at 01:06:03PM +0700, Chris Bainbridge wrote:
On Mon, Mar 03, 2014 at 09:04:19PM -0800, H. Peter Anvin wrote:
forcepae is descriptive.
Back to forcepae.
Ok, it looks ok to me after a quick look. Now you only have to ask
Dave whether he's fine with you merging his patch
On 4 March 2014 17:44, Borislav Petkov b...@alien8.de wrote:
On Tue, Mar 04, 2014 at 01:06:03PM +0700, Chris Bainbridge wrote:
On Mon, Mar 03, 2014 at 09:04:19PM -0800, H. Peter Anvin wrote:
forcepae is descriptive.
Back to forcepae.
Ok, it looks ok to me after a quick look. Now you only
On Mon, Mar 03, 2014 at 09:04:19PM -0800, H. Peter Anvin wrote:
> forcepae is descriptive.
Back to forcepae.
Signed-off-by: Chris Bainbridge
---
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 580a60c..67755ea 100644
---
forcepae is descriptive.
On March 3, 2014 9:01:30 PM PST, Chris Bainbridge
wrote:
>On Mon, Mar 03, 2014 at 08:29:39PM +0100, Borislav Petkov wrote:
>> On Mon, Mar 03, 2014 at 03:04:35PM +0700, Chris Bainbridge wrote:
>> > On 3 March 2014 02:05, Roland Kletzing wrote:
>> > > i would recommend
On Mon, Mar 03, 2014 at 08:29:39PM +0100, Borislav Petkov wrote:
> On Mon, Mar 03, 2014 at 03:04:35PM +0700, Chris Bainbridge wrote:
> > On 3 March 2014 02:05, Roland Kletzing wrote:
> > > i would recommend adding the newly introduced param to
> > > Documentation/kernel-
> > > parameters.txt ,
On Mon, Mar 03, 2014 at 03:04:35PM +0700, Chris Bainbridge wrote:
> On 3 March 2014 02:05, Roland Kletzing wrote:
> > i would recommend adding the newly introduced param to
> > Documentation/kernel-
> > parameters.txt , though.
>
> Done.
>
> Signed-off-by: Chris Bainbridge
> ---
> diff --git
> We routinely expect 2 to 3 u-s jitters on an Atom board running a 32 bit,
> RTAI enhanced build of what is by now a 5 year old kernel. This is
> extremely board sensitive, and that same kernel running on this 4 core
> phenom, cannot stay inside of 40 u-s. A case of more horsepower not being
On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:
> Hi,
>
> > /*
> > +* PAE CPUID bug: Pentium M reports no PAE but has PAE
> > +*/
>
> Ain't that a tad strongly/incorrectly worded?
I've updated the wording.
On 3 March 2014 02:05, Roland Kletzing wrote:
> i would
On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:
Hi,
/*
+* PAE CPUID bug: Pentium M reports no PAE but has PAE
+*/
Ain't that a tad strongly/incorrectly worded?
I've updated the wording.
On 3 March 2014 02:05, Roland Kletzing devz...@web.de wrote:
i would
We routinely expect 2 to 3 u-s jitters on an Atom board running a 32 bit,
RTAI enhanced build of what is by now a 5 year old kernel. This is
extremely board sensitive, and that same kernel running on this 4 core
phenom, cannot stay inside of 40 u-s. A case of more horsepower not being
a
On Mon, Mar 03, 2014 at 03:04:35PM +0700, Chris Bainbridge wrote:
On 3 March 2014 02:05, Roland Kletzing devz...@web.de wrote:
i would recommend adding the newly introduced param to
Documentation/kernel-
parameters.txt , though.
Done.
Signed-off-by: Chris Bainbridge
On Mon, Mar 03, 2014 at 08:29:39PM +0100, Borislav Petkov wrote:
On Mon, Mar 03, 2014 at 03:04:35PM +0700, Chris Bainbridge wrote:
On 3 March 2014 02:05, Roland Kletzing devz...@web.de wrote:
i would recommend adding the newly introduced param to
Documentation/kernel-
parameters.txt ,
forcepae is descriptive.
On March 3, 2014 9:01:30 PM PST, Chris Bainbridge chris.bainbri...@gmail.com
wrote:
On Mon, Mar 03, 2014 at 08:29:39PM +0100, Borislav Petkov wrote:
On Mon, Mar 03, 2014 at 03:04:35PM +0700, Chris Bainbridge wrote:
On 3 March 2014 02:05, Roland Kletzing devz...@web.de
On Mon, Mar 03, 2014 at 09:04:19PM -0800, H. Peter Anvin wrote:
forcepae is descriptive.
Back to forcepae.
Signed-off-by: Chris Bainbridge chris.bainbri...@gmail.com
---
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 580a60c..67755ea 100644
---
On 02/26/2014 09:57 AM, H. Peter Anvin wrote:
> On 02/26/2014 09:10 AM, Matthew Garrett wrote:
>> On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:
>>
>>> Yes. Grub can be made to behave sanely by using "linux16" and
>>> "initrd16", but of course none of the distros do it that way.
On Sunday 02 March 2014, Dave Jones wrote:
>On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:
> > (BTW, would it be possible to transform Linux's PAE support into
> > boot-config or even fully runtime-detectable boot switching to
> > (non-)PAE, similar to or exceeding what XP offers
On Sun, Mar 02, 2014 at 10:04:19PM +0100, Borislav Petkov wrote:
> On Sun, Mar 02, 2014 at 04:02:01PM -0500, Dave Jones wrote:
> > It would be a considerable amount of work to make it a runtime thing.
> > Ten years ago, maybe it would be worth the effort perhaps, but I'd
> > suggest just letting
On Sun, Mar 02, 2014 at 04:02:01PM -0500, Dave Jones wrote:
> It would be a considerable amount of work to make it a runtime thing.
> Ten years ago, maybe it would be worth the effort perhaps, but I'd
> suggest just letting 32-bit slowly die instead of doing dramatic
> overhauls that will no doubt
On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:
> (BTW, would it be possible to transform Linux's PAE support into
> boot-config or even fully runtime-detectable boot switching to
> (non-)PAE, similar to or exceeding what XP offers with its static
> boot-time flag?
> Last time
On 03/02/2014 12:56 PM, Andreas Mohr wrote:
>
> (BTW, would it be possible to transform Linux's PAE support into
> boot-config or even fully runtime-detectable boot switching to
> (non-)PAE, similar to or exceeding what XP offers with its static
> boot-time flag?
> Last time I checked PAE support
Hi,
> /*
> + * PAE CPUID bug: Pentium M reports no PAE but has PAE
> + */
Ain't that a tad strongly/incorrectly worded?
It's probably not certain whether that's a "bug".
Prior content in this discussion suggested that the flag might have been
intentionally not advertised, due to
great to see that we have an enhaced version of the initial quick`n`dirty patch
now. i just tested it on ubuntu 13.10 with kernel from 14.04 repository
(complete
package build).
works as expected ! hopefully ubuntu #930447 can now be closed soon and the
patch
will quickly find it´s way into
great to see that we have an enhaced version of the initial quick`n`dirty patch
now. i just tested it on ubuntu 13.10 with kernel from 14.04 repository
(complete
package build).
works as expected ! hopefully ubuntu #930447 can now be closed soon and the
patch
will quickly find it´s way into
Hi,
/*
+ * PAE CPUID bug: Pentium M reports no PAE but has PAE
+ */
Ain't that a tad strongly/incorrectly worded?
It's probably not certain whether that's a bug.
Prior content in this discussion suggested that the flag might have been
intentionally not advertised, due to not
On 03/02/2014 12:56 PM, Andreas Mohr wrote:
(BTW, would it be possible to transform Linux's PAE support into
boot-config or even fully runtime-detectable boot switching to
(non-)PAE, similar to or exceeding what XP offers with its static
boot-time flag?
Last time I checked PAE support
On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:
(BTW, would it be possible to transform Linux's PAE support into
boot-config or even fully runtime-detectable boot switching to
(non-)PAE, similar to or exceeding what XP offers with its static
boot-time flag?
Last time I
On Sun, Mar 02, 2014 at 04:02:01PM -0500, Dave Jones wrote:
It would be a considerable amount of work to make it a runtime thing.
Ten years ago, maybe it would be worth the effort perhaps, but I'd
suggest just letting 32-bit slowly die instead of doing dramatic
overhauls that will no doubt
On Sun, Mar 02, 2014 at 10:04:19PM +0100, Borislav Petkov wrote:
On Sun, Mar 02, 2014 at 04:02:01PM -0500, Dave Jones wrote:
It would be a considerable amount of work to make it a runtime thing.
Ten years ago, maybe it would be worth the effort perhaps, but I'd
suggest just letting 32-bit
On Sunday 02 March 2014, Dave Jones wrote:
On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:
(BTW, would it be possible to transform Linux's PAE support into
boot-config or even fully runtime-detectable boot switching to
(non-)PAE, similar to or exceeding what XP offers with its
On 02/26/2014 09:57 AM, H. Peter Anvin wrote:
On 02/26/2014 09:10 AM, Matthew Garrett wrote:
On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:
Yes. Grub can be made to behave sanely by using linux16 and
initrd16, but of course none of the distros do it that way.
Fedora does
On Fri, Feb 28, 2014 at 03:27:50PM +0300, Dennis Mungai wrote:
> Hello people,
>
> Note that revisions of the Dothan core were released in the first quarter
> of 2005 with the *Sonoma* chipsets and supported a 533 MT/s FSB and NX-bit
> (and PAE support required for it was enabled, unlike earlier
On Fri, Feb 28, 2014 at 03:27:50PM +0300, Dennis Mungai wrote:
Hello people,
Note that revisions of the Dothan core were released in the first quarter
of 2005 with the *Sonoma* chipsets and supported a 533 MT/s FSB and NX-bit
(and PAE support required for it was enabled, unlike earlier
On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
> On Wed, Feb 26, 2014 at 02:18:52PM +0100, Borislav Petkov wrote:
> > On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
> > > @@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
> > >
On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
On Wed, Feb 26, 2014 at 02:18:52PM +0100, Borislav Petkov wrote:
On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
On 02/26/2014 09:10 AM, Matthew Garrett wrote:
> On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:
>
>> Yes. Grub can be made to behave sanely by using "linux16" and
>> "initrd16", but of course none of the distros do it that way.
>
> Fedora does as of F20, but yeah, point taken.
On Wed, Feb 26, 2014 at 12:20:10PM -0500, Dave Jones wrote:
> Then it's definitely a good idea :-)
LOL!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Wed, Feb 26, 2014 at 06:18:17PM +0100, Borislav Petkov wrote:
> On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
> > I'd suggest repurposing 'S'. Instead of 'unsafe smp', it could mean
> > "out of Spec". We currently only use that flag on some ancient athlon
> > xp, so there's
On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
> I'd suggest repurposing 'S'. Instead of 'unsafe smp', it could mean
> "out of Spec". We currently only use that flag on some ancient athlon
> xp, so there's not going to be any kind of collision.
Hahaa, I said that yesterday already:
On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:
> Yes. Grub can be made to behave sanely by using "linux16" and
> "initrd16", but of course none of the distros do it that way.
Fedora does as of F20, but yeah, point taken.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To
On Wed, Feb 26, 2014 at 02:18:52PM +0100, Borislav Petkov wrote:
> On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
> > @@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
> >clear_cpu_cap(c, X86_FEATURE_SEP);
> >
> >/*
> > + * PAE
On 02/26/2014 05:18 AM, Borislav Petkov wrote:
> On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
>> @@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
>> clear_cpu_cap(c, X86_FEATURE_SEP);
>>
>> /*
>> + * PAE CPUID bug: Pentium M
On 02/26/2014 08:44 AM, Matthew Garrett wrote:
> On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
>
>> The basic findings of the bug discussion is that people are successfully
>> running PAE kernels on Pentium M (for some unknown reason Grub skips the
>> validate_cpu code in the
On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
> The basic findings of the bug discussion is that people are successfully
> running PAE kernels on Pentium M (for some unknown reason Grub skips the
> validate_cpu code in the kernel, so existing PAE kernels will run
> unmodified,
On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
> @@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
> clear_cpu_cap(c, X86_FEATURE_SEP);
>
> /*
> + * PAE CPUID bug: Pentium M reports no PAE but has PAE
> + */
> + if
On Tue, Feb 25, 2014 at 09:16:02AM -0800, H. Peter Anvin wrote:
> On 02/25/2014 08:26 AM, Dave Jones wrote:
> > On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
> > > On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> > > > Pentium M is PAE capable but does not indicate so in the
On Tue, Feb 25, 2014 at 09:16:02AM -0800, H. Peter Anvin wrote:
On 02/25/2014 08:26 AM, Dave Jones wrote:
On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID
On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
clear_cpu_cap(c, X86_FEATURE_SEP);
/*
+ * PAE CPUID bug: Pentium M reports no PAE but has PAE
+ */
+ if (forcepae)
On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
The basic findings of the bug discussion is that people are successfully
running PAE kernels on Pentium M (for some unknown reason Grub skips the
validate_cpu code in the kernel, so existing PAE kernels will run
unmodified,
On 02/26/2014 08:44 AM, Matthew Garrett wrote:
On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
The basic findings of the bug discussion is that people are successfully
running PAE kernels on Pentium M (for some unknown reason Grub skips the
validate_cpu code in the kernel,
On 02/26/2014 05:18 AM, Borislav Petkov wrote:
On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
clear_cpu_cap(c, X86_FEATURE_SEP);
/*
+ * PAE CPUID bug: Pentium M reports no PAE
On Wed, Feb 26, 2014 at 02:18:52PM +0100, Borislav Petkov wrote:
On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
clear_cpu_cap(c, X86_FEATURE_SEP);
/*
+ * PAE CPUID bug:
On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:
Yes. Grub can be made to behave sanely by using linux16 and
initrd16, but of course none of the distros do it that way.
Fedora does as of F20, but yeah, point taken.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe
On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
I'd suggest repurposing 'S'. Instead of 'unsafe smp', it could mean
out of Spec. We currently only use that flag on some ancient athlon
xp, so there's not going to be any kind of collision.
Hahaa, I said that yesterday already:
On Wed, Feb 26, 2014 at 06:18:17PM +0100, Borislav Petkov wrote:
On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
I'd suggest repurposing 'S'. Instead of 'unsafe smp', it could mean
out of Spec. We currently only use that flag on some ancient athlon
xp, so there's not going
On Wed, Feb 26, 2014 at 12:20:10PM -0500, Dave Jones wrote:
Then it's definitely a good idea :-)
LOL!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On 02/26/2014 09:10 AM, Matthew Garrett wrote:
On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:
Yes. Grub can be made to behave sanely by using linux16 and
initrd16, but of course none of the distros do it that way.
Fedora does as of F20, but yeah, point taken.
Oh, good
On 02/25/2014 08:26 AM, Dave Jones wrote:
> On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
> > On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> > > Pentium M is PAE capable but does not indicate so in the CPUID response.
> > > This is an issue now that some distributions are
On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
> On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> > Pentium M is PAE capable but does not indicate so in the CPUID response.
> > This is an issue now that some distributions are no longer shipping
> > non-PAE kernels (those
On Tue, 25 Feb 2014 02:45:57 -0800
"H. Peter Anvin" wrote:
> On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> > Pentium M is PAE capable but does not indicate so in the CPUID response.
> > This is an issue now that some distributions are no longer shipping
> > non-PAE kernels (those
On 02/25/2014 05:45 AM, H. Peter Anvin wrote:
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those distributions no longer boot on
On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
> On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> >Pentium M is PAE capable but does not indicate so in the CPUID response.
> >This is an issue now that some distributions are no longer shipping
> >non-PAE kernels (those
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those distributions no longer boot on Pentium M). This
small patch fixes the issue by
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those distributions no longer boot on Pentium M). This
small patch fixes the issue by
On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those distributions no
On 02/25/2014 05:45 AM, H. Peter Anvin wrote:
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those distributions no longer boot on
On Tue, 25 Feb 2014 02:45:57 -0800
H. Peter Anvin h...@zytor.com wrote:
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those
On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those
On 02/25/2014 08:26 AM, Dave Jones wrote:
On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer
70 matches
Mail list logo
