[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fyb6n86a.fsf@duaron.myhome.or.jp>
Date: Sat, 23 Dec 2006 20:49:49 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: Arjan van de Ven <arjan@...radead.org>
Cc: OGAWA Hirofumi <hogawa@...aclelinux.com>,
Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address
Hi,
Arjan van de Ven <arjan@...radead.org> writes:
> On Sat, 2006-12-23 at 10:02 +0900, OGAWA Hirofumi wrote:
>> Current -mm's mmconfig has some problems of remapped range.
>>
>> a) In the case of broken MCFG tables on Asus etc., we need to remap
>> 256M range, but currently only remap 1M.
>
> I respectfully disagree. If the MCFG table is broken, we should not use
> it AT ALL. It's either a correct table, and we can use it, or it's so
> broken that we know it never has been tested etc etc, we're just better
> of to not trust it in that case.
Hm.. I see. Sounds sane to me. Well, my patch didn't add the new
workaround of broken table, it just fixes the oops of existence workaround.
Current workaround is the following (both of linus and -mm),
if (pci_mmcfg_config_num == 1 &&
cfg->pci_segment_group_number == 0 &&
(cfg->start_bus_number | cfg->end_bus_number) == 0)
/* Assume it can access 256M range */
But, if the system has bus number 0 only, it's a correct table.
We may need to detect the broken system. blacklist?
--
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
-
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