On Friday 11 May 2007 8:23 pm, H. Peter Anvin wrote:
> Kevin Winchester wrote:
> > Not sure if you were looking for testing, but I fuzzed it to apply to
> > 2.6.21-git and gave it a spin. Worked just like a normal boot (which I
> > assume was the point).
>
> That would be the point, yes :)
On Friday 11 May 2007 8:23 pm, H. Peter Anvin wrote:
Kevin Winchester wrote:
Not sure if you were looking for testing, but I fuzzed it to apply to
2.6.21-git and gave it a spin. Worked just like a normal boot (which I
assume was the point).
That would be the point, yes :) Looking for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
> Kevin Winchester wrote:
>> Not sure if you were looking for testing, but I fuzzed it to apply to
>> 2.6.21-git and gave it a spin. Worked just like a normal boot (which I
>> assume was the point).
>
> That would be the point,
Eric W. Biederman wrote:
> Ok. If you have tested on a wide variety of machines then I won't
> worry about it.
>
> I guess if a cr0 write has always been synchronizing things should be
> a safe practice. The practical danger is if you write to cr0 and the
> pipeline is not flushed and the
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> Even on 386 and 486 class cpus?
>>
>
> Yes, even on 386 and 486 class CPUs. I have personally tested this on
> machines as old as the original "double sigma" 386-16.
Ok. If you have tested on a wide variety of
Eric W. Biederman wrote:
>
> Even on 386 and 486 class cpus?
>
Yes, even on 386 and 486 class CPUs. I have personally tested this on
machines as old as the original "double sigma" 386-16.
> To some extent if the rules don't change it makes sense for them to
> copy the information from one
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> HPA is both right and wrong on this. The safe sequence for entering
>> protected mode requires a jump immediately after setting PE in %cr0.
>> To serialize the instruction stream and to be on an execution that
>> is
Eric W. Biederman wrote:
>
> HPA is both right and wrong on this. The safe sequence for entering
> protected mode requires a jump immediately after setting PE in %cr0.
> To serialize the instruction stream and to be on an execution that
> is tested and guaranteed to work in cpus.
>
Eric,
Alexander van Heukelum <[EMAIL PROTECTED]> writes:
> On Thu, May 10, 2007 at 03:48:08PM -0700, H. Peter Anvin wrote:
> I can confirm that it works for at least one computer over here (a six
> months old x86_64 machine with ATI ES1000-based on-board graphics). Some
> non-vesa modes including a
On Thu, May 10, 2007 at 03:48:08PM -0700, H. Peter Anvin wrote:
> > It doesn't probe the hardware in dangerous ways. (Search for mode_scan
> > in video.S) It works by trying to set a mode via the normal
> > AH=0/AL=mode/int 0x10 method for all possible values of mode. It then
> > checks if the
On Thu, May 10, 2007 at 03:48:08PM -0700, H. Peter Anvin wrote:
It doesn't probe the hardware in dangerous ways. (Search for mode_scan
in video.S) It works by trying to set a mode via the normal
AH=0/AL=mode/int 0x10 method for all possible values of mode. It then
checks if the bios
Alexander van Heukelum [EMAIL PROTECTED] writes:
On Thu, May 10, 2007 at 03:48:08PM -0700, H. Peter Anvin wrote:
I can confirm that it works for at least one computer over here (a six
months old x86_64 machine with ATI ES1000-based on-board graphics). Some
non-vesa modes including a nice
Eric W. Biederman wrote:
HPA is both right and wrong on this. The safe sequence for entering
protected mode requires a jump immediately after setting PE in %cr0.
To serialize the instruction stream and to be on an execution that
is tested and guaranteed to work in cpus.
Eric, that's
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
HPA is both right and wrong on this. The safe sequence for entering
protected mode requires a jump immediately after setting PE in %cr0.
To serialize the instruction stream and to be on an execution that
is tested and
Eric W. Biederman wrote:
Even on 386 and 486 class cpus?
Yes, even on 386 and 486 class CPUs. I have personally tested this on
machines as old as the original double sigma 386-16.
To some extent if the rules don't change it makes sense for them to
copy the information from one generation
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Even on 386 and 486 class cpus?
Yes, even on 386 and 486 class CPUs. I have personally tested this on
machines as old as the original double sigma 386-16.
Ok. If you have tested on a wide variety of machines then I
Eric W. Biederman wrote:
Ok. If you have tested on a wide variety of machines then I won't
worry about it.
I guess if a cr0 write has always been synchronizing things should be
a safe practice. The practical danger is if you write to cr0 and the
pipeline is not flushed and the segment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
Kevin Winchester wrote:
Not sure if you were looking for testing, but I fuzzed it to apply to
2.6.21-git and gave it a spin. Worked just like a normal boot (which I
assume was the point).
That would be the point, yes :)
Kevin Winchester wrote:
> Not sure if you were looking for testing, but I fuzzed it to apply to
> 2.6.21-git and gave it a spin. Worked just like a normal boot (which I
> assume was the point).
That would be the point, yes :) Looking for breakage in video mode
detection, memory detection, and
H. Peter Anvin wrote:
> Hello all,
>
> I believe the x86 setup tree is now finished. I will turn it into a
> "clean patchset" later this week, but I wanted to get flamed^W feedback
> on it first.
>
> The git tree is at:
>
>
H. Peter Anvin wrote:
Hello all,
I believe the x86 setup tree is now finished. I will turn it into a
clean patchset later this week, but I wanted to get flamed^W feedback
on it first.
The git tree is at:
http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary
Kevin Winchester wrote:
Not sure if you were looking for testing, but I fuzzed it to apply to
2.6.21-git and gave it a spin. Worked just like a normal boot (which I
assume was the point).
That would be the point, yes :) Looking for breakage in video mode
detection, memory detection, and APM
On Tue, May 08, 2007 at 10:15:21PM -0700, H. Peter Anvin wrote:
> Hello all,
>
> I believe the x86 setup tree is now finished. I will turn it into a
> "clean patchset" later this week, but I wanted to get flamed^W feedback
> on it first.
>
> The git tree is at:
>
>
Martin Mares wrote:
> Hello!
>
>> As far as I could tell, "scan" simply caused the nonstandard video
>> driver scan modules (unsafe probes) to be invoked. Since those modules
>> are no longer present, there appeared to be no need for them. The VGA
>> and VESA probes are safe.
>
> "scan" is
Alexander van Heukelum wrote:
> On Thu, May 10, 2007 at 11:08:10AM -0700, H. Peter Anvin wrote:
>> As far as I could tell, "scan" simply caused the nonstandard video
>> driver scan modules (unsafe probes) to be invoked. Since those modules
>> are no longer present, there appeared to be no need
On Thu, May 10, 2007 at 11:08:10AM -0700, H. Peter Anvin wrote:
> As far as I could tell, "scan" simply caused the nonstandard video
> driver scan modules (unsafe probes) to be invoked. Since those modules
> are no longer present, there appeared to be no need for them. The VGA
> and VESA probes
Hello!
> As far as I could tell, "scan" simply caused the nonstandard video
> driver scan modules (unsafe probes) to be invoked. Since those modules
> are no longer present, there appeared to be no need for them. The VGA
> and VESA probes are safe.
"scan" is still useful, because it is able to
Alexander van Heukelum wrote:
> Hi!
>
> Only tiny sparks^Wremarks, I'm afraid. ;)
>
> I've briefly looked at the new code in arch/i386/boot and as far
> as I can determine in a short amount of time all functionality is
> basically there, with the exception of the 'scan' functionality for
>
On Tue, 08 May 2007 22:15:21 -0700, "H. Peter Anvin" <[EMAIL PROTECTED]>
said:
> I believe the x86 setup tree is now finished. I will turn it into a
> "clean patchset" later this week, but I wanted to get flamed^W feedback
> on it first.
Hi!
Only tiny sparks^Wremarks, I'm afraid. ;)
I've
On Tue, 08 May 2007 22:15:21 -0700, H. Peter Anvin [EMAIL PROTECTED]
said:
I believe the x86 setup tree is now finished. I will turn it into a
clean patchset later this week, but I wanted to get flamed^W feedback
on it first.
Hi!
Only tiny sparks^Wremarks, I'm afraid. ;)
I've briefly looked
Alexander van Heukelum wrote:
Hi!
Only tiny sparks^Wremarks, I'm afraid. ;)
I've briefly looked at the new code in arch/i386/boot and as far
as I can determine in a short amount of time all functionality is
basically there, with the exception of the 'scan' functionality for
bios
Hello!
As far as I could tell, scan simply caused the nonstandard video
driver scan modules (unsafe probes) to be invoked. Since those modules
are no longer present, there appeared to be no need for them. The VGA
and VESA probes are safe.
scan is still useful, because it is able to find
On Thu, May 10, 2007 at 11:08:10AM -0700, H. Peter Anvin wrote:
As far as I could tell, scan simply caused the nonstandard video
driver scan modules (unsafe probes) to be invoked. Since those modules
are no longer present, there appeared to be no need for them. The VGA
and VESA probes are
Alexander van Heukelum wrote:
On Thu, May 10, 2007 at 11:08:10AM -0700, H. Peter Anvin wrote:
As far as I could tell, scan simply caused the nonstandard video
driver scan modules (unsafe probes) to be invoked. Since those modules
are no longer present, there appeared to be no need for them.
Martin Mares wrote:
Hello!
As far as I could tell, scan simply caused the nonstandard video
driver scan modules (unsafe probes) to be invoked. Since those modules
are no longer present, there appeared to be no need for them. The VGA
and VESA probes are safe.
scan is still useful,
On Tue, May 08, 2007 at 10:15:21PM -0700, H. Peter Anvin wrote:
Hello all,
I believe the x86 setup tree is now finished. I will turn it into a
clean patchset later this week, but I wanted to get flamed^W feedback
on it first.
The git tree is at:
On Wed, May 09, 2007 at 12:02:45AM -0700, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> >> http://www.kernel.org/pub/linux/kernel/people/hpa/newsetup-36f021b5.patch
> >
> > Are you planning to rebase to -linus and then let
> > arch/x86_64/boot/Makefile be a reference to i386/boot/Makefile?
> >
>
Sam Ravnborg wrote:
>> http://www.kernel.org/pub/linux/kernel/people/hpa/newsetup-36f021b5.patch
>
> Are you planning to rebase to -linus and then let
> arch/x86_64/boot/Makefile be a reference to i386/boot/Makefile?
>
> The patch for kbuild to enable this is in -linus now.
>
> As for the
On Tue, May 08, 2007 at 10:15:21PM -0700, H. Peter Anvin wrote:
> Hello all,
>
> I believe the x86 setup tree is now finished. I will turn it into a
> "clean patchset" later this week, but I wanted to get flamed^W feedback
> on it first.
>
> The git tree is at:
>
>
On Tue, May 08, 2007 at 10:15:21PM -0700, H. Peter Anvin wrote:
Hello all,
I believe the x86 setup tree is now finished. I will turn it into a
clean patchset later this week, but I wanted to get flamed^W feedback
on it first.
The git tree is at:
Sam Ravnborg wrote:
http://www.kernel.org/pub/linux/kernel/people/hpa/newsetup-36f021b5.patch
Are you planning to rebase to -linus and then let
arch/x86_64/boot/Makefile be a reference to i386/boot/Makefile?
The patch for kbuild to enable this is in -linus now.
As for the important part
On Wed, May 09, 2007 at 12:02:45AM -0700, H. Peter Anvin wrote:
Sam Ravnborg wrote:
http://www.kernel.org/pub/linux/kernel/people/hpa/newsetup-36f021b5.patch
Are you planning to rebase to -linus and then let
arch/x86_64/boot/Makefile be a reference to i386/boot/Makefile?
The patch
Hello all,
I believe the x86 setup tree is now finished. I will turn it into a
"clean patchset" later this week, but I wanted to get flamed^W feedback
on it first.
The git tree is at:
http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary
Hello all,
I believe the x86 setup tree is now finished. I will turn it into a
clean patchset later this week, but I wanted to get flamed^W feedback
on it first.
The git tree is at:
http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary
44 matches
Mail list logo
