From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Adrian Bunk <bunk@stusta.de>,
Jeff Chua <jeff.chua.linux@gmail.com>,
Matthew Wilcox <matthew@wil.cx>,
Aaron Durbin <adurbin@google.com>, Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
gregkh@suse.de, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3)
Date: Fri, 10 Nov 2006 07:56:59 +0100 [thread overview]
Message-ID: <200611100757.00203.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0611080951040.3667@g5.osdl.org>
> What a piece of crap.
>
> Andi, I'm getting really upset about this kind of thing. You've been very
> much not careful about MMCFG in general, and are allowing total crap to go
> into the kernel, without any thought. Just "testing" something isn't good
> enough, it needs to be thought out.
Sorry, probably should have read the patch more carefully.
I think I agreed with the high level idea but didn't double check
the details.
>
> I'm going to revert that totally bogus commit that added that broken
> "pci_mmcfg_insert_resources()" function. It could be done right, but doing
> it right would require that the function
Ok fine by me.
> We really should stop using MMCONFIG entirely, until we have a
Hmm, for .19 at least you mean?
Entirely stopping it would break the x86 macs minis again I think.
But we can make it "only use if type 1 doesn't work"
I'm sure some people will be upset again if we don't use it.
Perhaps there are really users who want to use the PCI-E error handling
for example.
> per-southbridge true knowledge of what the real decoding is. The BIOS
> tables for this are simply too damn unreliable.
My hopes for that are on Vista. Perhaps use a DMI year test again
(>= 2007) and only white lists for older boards.
-Andi
next prev parent reply other threads:[~2006-11-10 6:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.64.0611080056480.12828@silvia.corp.fedex.com>
[not found] ` <20061107171143.GU27140@parisc-linux.org>
[not found] ` <200611080839.46670.ak@suse.de>
[not found] ` <20061108122237.GF27140@parisc-linux.org>
[not found] ` <Pine.LNX.4.64.0611080803280.3667@g5.osdl.org>
2006-11-08 17:26 ` [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3) Adrian Bunk
2006-11-08 17:49 ` Linus Torvalds
2006-11-08 18:08 ` Linus Torvalds
2006-11-08 18:36 ` Linus Torvalds
2006-11-10 6:25 ` Jeff Chua
2006-11-10 6:43 ` Andrew Morton
2006-11-10 9:21 ` Jeff Chua
2006-11-10 6:56 ` Andi Kleen [this message]
2006-11-10 10:16 ` Alan Cox
2006-11-10 14:02 ` Jeff Garzik
2006-11-10 13:56 ` Jeff Garzik
2006-11-08 18:17 ` Aaron Durbin
2006-11-10 5:53 Jeff Chua
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=200611100757.00203.ak@suse.de \
--to=ak@suse.de \
--cc=adurbin@google.com \
--cc=akpm@osdl.org \
--cc=bunk@stusta.de \
--cc=gregkh@suse.de \
--cc=jeff.chua.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
--cc=torvalds@osdl.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