[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86802c440804131119m1c43497bg1864ce9751438e85@mail.gmail.com>
Date: Sun, 13 Apr 2008 11:19:06 -0700
From: "Yinghai Lu" <yhlu.kernel@...il.com>
To: "Andi Kleen" <andi@...stfloor.org>
Cc: "Ingo Molnar" <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>,
"Andrew Morton" <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"Pavel Machek" <pavel@....cz>,
"Thomas Gleixner" <tglx@...utronix.de>, "H. Anvin" <hpa@...or.com>,
"Arjan van de Ven" <arjan@...radead.org>,
"Greg Kroah-Hartman" <gregkh@...e.de>
Subject: Re: [rfc] hw resource debugging checks
On Sun, Apr 13, 2008 at 2:39 AM, Andi Kleen <andi@...stfloor.org> wrote:
> Ingo Molnar <mingo@...e.hu> writes:
>
> This whole problem just shows that it was a mistake in the first place
> to try to redo the BIOS work in Linux. If BIOS doesn't supply MCFG
> Linux trying to create one (or in general having generalized resource
> allocation) is just a big mess and will cause endless problems. The
> standard resource code is just not up to the task and it needs very
> intimate knowledge of the hardware that the kernel shouldn't have.
>
> Again the real fix I think is to just drop all that code in git-x86
> again and finally fix LinuxBIOS to do its job properly and pass a
> proper MCFG (or just forget about using mmconfig with LinuxBIOS - it
> is not that Type1 suddently doesn't work anymore). Then this code
> wouldn't be needed at all
It has nothing to LinuxBIOS.
we would trust HW pci conf/msr than BIOS. even I could talk to BIOS
engineers everyday and tell them how to fix the problem in BIOS, some
still can not be fixed because of the legacy BIOS framework or big
mess.
the patchset from me in x86.git is in two folders
1. MCFG fix up for AMD cpu.
2. BUS numa support for AMD cpu with several sockets with muliti ht
links aka. multi peer root buses.
it will try to split root resource (iomem_resource, io_resource)
to different ht links. so when kernel try to assign resource to some
unassigned devices, it can use correct values.
these two patches will not hurt intel platform too.
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists