On Sun, 4 Nov 2007, Eric W. Biederman wrote:
>
> I do seem to recall etherboot having a far jump in that spot and it
> working on everything from a 386 on up. So I'm not certain if the
> kind of jump matters. Still the kernel has a lot more exposure.
I actually suspect you could have just
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Linus Torvalds wrote:
>>
>> And Linux always did it correctly. I don't understand why you disagree, and
>> why Jeremy says
>>
>> "Having successfully broken the rules for a long time so far,maybe
>> we can get away with still cutting
H. Peter Anvin wrote:
Apparently because the Intel documentation disagrees with itself. That's
all.
Just to be perfectly clear: I much prefer the code with the short (near)
jump, because it keeps the code cleaner. I have sent a patch to Mikael
to test out.
-hpa
-
To
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Hi Linus; please pull:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
> for-linus
>
> H. Peter Anvin (1):
> x86 setup: correct booting on 486DX4
>
> arch/x86/boot/pmjump.S | 32 +---
Linus Torvalds wrote:
And Linux always did it correctly. I don't understand why you disagree,
and why Jeremy says
"Having successfully broken the rules for a long time so far,
maybe we can get away with still cutting corners..."
when the fact is, we used to *not* cut corners, we used
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
>
> It's not an instruction-decoding issue at all (that's a 16- vs 32-bit issue,
> which can only be changed by a ljmp). Apparently the 486DX4 mis-executes the
> load to segment register, which is an EU function in that context. (And yes,
> it's
Linus Torvalds wrote:
On Sun, 4 Nov 2007, Linus Torvalds wrote:
I'm not entirely sure that it needs to be a long-jump, btw. I think any
regular branch is sufficient. You obviously *do* need to make the long
jump later (to reload %cs in protected mode), but I'm not sure it's needed
in that
Linus Torvalds wrote:
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so
we really do need the far jump immediately afterwards.
Hmm. I'm not sure I agree with the commit message.
This is documented behaviour on i386
Linus Torvalds wrote:
> I'm not entirely sure that it needs to be a long-jump, btw. I think any
> regular branch is sufficient. You obviously *do* need to make the long
> jump later (to reload %cs in protected mode), but I'm not sure it's needed
> in that place. I forget the exact rules (but
On Sun, 4 Nov 2007, Linus Torvalds wrote:
>
> I'm not entirely sure that it needs to be a long-jump, btw. I think any
> regular branch is sufficient. You obviously *do* need to make the long
> jump later (to reload %cs in protected mode), but I'm not sure it's needed
> in that place. I forget
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
>
> Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so
> we really do need the far jump immediately afterwards.
Hmm. I'm not sure I agree with the commit message.
This is documented behaviour on i386 and i486:
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so
we really do need the far jump immediately afterwards.
Hmm. I'm not sure I agree with the commit message.
This is documented behaviour on i386 and i486: instruction
On Sun, 4 Nov 2007, Linus Torvalds wrote:
I'm not entirely sure that it needs to be a long-jump, btw. I think any
regular branch is sufficient. You obviously *do* need to make the long
jump later (to reload %cs in protected mode), but I'm not sure it's needed
in that place. I forget the
Linus Torvalds wrote:
I'm not entirely sure that it needs to be a long-jump, btw. I think any
regular branch is sufficient. You obviously *do* need to make the long
jump later (to reload %cs in protected mode), but I'm not sure it's needed
in that place. I forget the exact rules (but they
Linus Torvalds wrote:
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so
we really do need the far jump immediately afterwards.
Hmm. I'm not sure I agree with the commit message.
This is documented behaviour on i386
Linus Torvalds wrote:
On Sun, 4 Nov 2007, Linus Torvalds wrote:
I'm not entirely sure that it needs to be a long-jump, btw. I think any
regular branch is sufficient. You obviously *do* need to make the long
jump later (to reload %cs in protected mode), but I'm not sure it's needed
in that
On Sun, 4 Nov 2007, H. Peter Anvin wrote:
It's not an instruction-decoding issue at all (that's a 16- vs 32-bit issue,
which can only be changed by a ljmp). Apparently the 486DX4 mis-executes the
load to segment register, which is an EU function in that context. (And yes,
it's
Linus Torvalds wrote:
And Linux always did it correctly. I don't understand why you disagree,
and why Jeremy says
Having successfully broken the rules for a long time so far,
maybe we can get away with still cutting corners...
when the fact is, we used to *not* cut corners, we used to
H. Peter Anvin [EMAIL PROTECTED] writes:
Hi Linus; please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (1):
x86 setup: correct booting on 486DX4
arch/x86/boot/pmjump.S | 32 +---
1 files
H. Peter Anvin wrote:
Apparently because the Intel documentation disagrees with itself. That's
all.
Just to be perfectly clear: I much prefer the code with the short (near)
jump, because it keeps the code cleaner. I have sent a patch to Mikael
to test out.
-hpa
-
To
H. Peter Anvin [EMAIL PROTECTED] writes:
Linus Torvalds wrote:
And Linux always did it correctly. I don't understand why you disagree, and
why Jeremy says
Having successfully broken the rules for a long time so far,maybe
we can get away with still cutting corners...
when the
On Sun, 4 Nov 2007, Eric W. Biederman wrote:
I do seem to recall etherboot having a far jump in that spot and it
working on everything from a 386 on up. So I'm not certain if the
kind of jump matters. Still the kernel has a lot more exposure.
I actually suspect you could have just about
22 matches
Mail list logo
