public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andreas Herrmann <aherrman@arcor.de>
Cc: Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org, dean gaudet <dean@arctic.org>
Subject: Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG
Date: Fri, 14 Sep 2007 07:08:33 -0700	[thread overview]
Message-ID: <46EA95E1.4000308@zytor.com> (raw)
In-Reply-To: <20070914112154.GB6727@devil>

Andreas Herrmann wrote:
>>>
>> I'm not talking about Linux here.  I'm talking about any random system
>> software (which may or may not be Vista, and may nor may not even be an
>> OS.)
> 
> Are you serious? You are worried about Vista compatibility issues for
> new hardware? Here on LKML? I thought this is a Linux mailing list.
> 

No, I'm not concerned about Vista.  Read: MAY OR MAY NOT EVEN BE AN OS.
 In fact, non-OS system software, such as bootloaders or diagnostic
systems, are in fact much more difficult in this than OSes.

>>  If they advertise MCFG, then a random OS could try to use it, in
>> accordance with the spec, without the workaround, with serious
>> malfunction as a result.
> 
> Have you looked into the BKDG of that CPU?
> You can download it here
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf
> 
> BTW, in this version it is even recommended to set up MCFG. So why should a
> BIOS vendor drop it?

They probably won't, which is highly unfortunate.  AMD is unlikely to
admit that they have a serious bug in their compliance, and BIOS vendors
are unlikely to catch on.  It's still broken.

> Because I am not as standards-compliant as you are, I should say: "To err is human".
> So I've done my best to verify that config space stuff with real code on real hardware
> last week. But as always, it is possible that I am wrong with certain statements.

To err is human (and, in silicon manufacturing, both common and
extremely expensive.)  It's now you deal with the fallout that matters,
and it's quite unforgiving, because we're dealing with computer
protocols here.  You MUST NOT advertise compliance with a protocol that
you don't actually have (MCFG).  You then SHOULD promulgate workarounds
that say "oh, I'm on chip X, that means that I can enable mmconfig as
long as I play within these chip-specific rules."

> Do you think it is a good idea to discuss that MMCONFIG topic with
> some designers at AMD? I could print out that mail or forward it to them.
> Do you think they will be happy to listen to your words if you say that
> they are "fucking up" stuff and come up with "braindamaged" ideas?
> I appreciate the code you write, but not the communication style you chose.

Uhm, it's hardware.  Bugs happen.  What gets ugly is when marketing gets
involved, and says "we can't afford to say we don't have <feature X>, so
let's advertise it anyway."

	-hpa


  reply	other threads:[~2007-09-14 14:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-13  2:21 [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used Yinghai Lu
2007-09-13  2:17 ` Andrew Morton
2007-09-13  9:47 ` Andi Kleen
2007-09-13 10:47   ` Greg KH
2007-09-13 11:53     ` Andi Kleen
2007-09-13 17:01       ` Yinghai Lu
2007-09-13 17:20         ` H. Peter Anvin
2007-09-13 19:22           ` Yinghai Lu
2007-09-13 19:31             ` H. Peter Anvin
2007-09-13 20:15           ` Andreas Herrmann
2007-09-13 20:54             ` H. Peter Anvin
2007-09-14 11:21               ` [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG Andreas Herrmann
2007-09-14 14:08                 ` H. Peter Anvin [this message]
2007-09-14 17:28                 ` Yinghai Lu
2007-09-14 18:09                 ` Yinghai Lu
2007-09-16  3:18           ` [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used Andi Kleen
2007-09-13 19:52       ` Andreas Herrmann
2007-09-13 20:14         ` Yinghai Lu

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=46EA95E1.4000308@zytor.com \
    --to=hpa@zytor.com \
    --cc=aherrman@arcor.de \
    --cc=ak@suse.de \
    --cc=dean@arctic.org \
    --cc=linux-kernel@vger.kernel.org \
    /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