linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Pavel Machek <pavel@suse.cz>
Cc: David Fries <david@fries.net>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH] Fix i486 suspend to disk CR4 oops
Date: Mon, 18 Aug 2008 15:10:51 -0700	[thread overview]
Message-ID: <48A9F36B.8090509@zytor.com> (raw)
In-Reply-To: <20080818220419.GB2053@elf.ucw.cz>

Pavel Machek wrote:
> 
> Okay, can it happen that that cr4 is zero legitimately? If newer 486SX
> chips support cr4 but not coprocessor...?
> 									Pavel

Theoretically it can, but that means no features are enabled, so there 
is no need to enable the features.

The real question is if the following can happen: can it be such that we 
want CR4 to be zero in a situation where CR4 is nonzero to start out with?

The main bit in CR4 that could be set that we wouldn't want set would be 
CR4.PAE, so this could happen if there is a CPU with CR4.PAE but none of 
the other CR4 bits that we would normally set unconditionally.

I'm pretty sure this can't happen on any physical CPUs, since all 
physical CPUs supporting PAE would also support DE, MCE, and PGE.  It 
could possibly happen on a virtual CPU, although it is of course 
extremely unlikely we'd get there with CR4 not zero to start out with.

Still, it is at least theoretically wrong.

	-hpa

  reply	other threads:[~2008-08-18 22:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-18  4:03 [PATCH] Fix i486 suspend to disk CR4 oops David Fries
2008-08-18  4:14 ` Maciej W. Rozycki
2008-08-18  4:35   ` H. Peter Anvin
2008-08-18  6:04     ` Andi Kleen
2008-08-18  6:34       ` H. Peter Anvin
2008-08-18  6:42         ` Andi Kleen
2008-08-18  6:41 ` Ingo Molnar
2008-08-18  6:45   ` H. Peter Anvin
2008-08-18  9:15   ` Pavel Machek
2008-08-18 10:16   ` Rafael J. Wysocki
2008-08-18 12:58   ` David Fries
2008-08-18 13:25     ` Ingo Molnar
2008-08-18 14:41       ` Maciej W. Rozycki
2008-08-18 14:38     ` Maciej W. Rozycki
2008-08-18 22:04     ` Pavel Machek
2008-08-18 22:10       ` H. Peter Anvin [this message]
2008-08-18 15:24   ` Dave Jones
2008-08-18 16:04     ` Lennart Sorensen
2008-08-18 17:17       ` Dave Jones
2008-08-18 17:32     ` H. Peter Anvin
2008-08-18 22:02       ` Pavel Machek
2008-08-19  3:37   ` [PATCH] i486 CR4 oops, no_console_suspend David Fries
2008-08-19  9:34     ` Ingo Molnar
2008-08-19 16:07       ` H. Peter Anvin
2008-08-21  4:17         ` David Fries
2008-08-21  5:37           ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48A9F36B.8090509@zytor.com \
    --to=hpa@zytor.com \
    --cc=david@fries.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=mingo@elte.hu \
    --cc=pavel@suse.cz \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).