From: Tejun Heo <tj@kernel.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
pgnet.trash@gmail.com
Subject: Re: [PATCH 2.6.29-rc7 2/2] x86: disallow DAC for MCP51 PCI bridge
Date: Wed, 04 Mar 2009 22:36:38 +0900 [thread overview]
Message-ID: <49AE83E6.4040608@kernel.org> (raw)
In-Reply-To: <20090304132945.2b242e63@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>> x86 is blacklisting DAC for everything VIA. :-)
>
> I'd assume that comes from published docs given VIA actually publish
> stuff if you ask nicely.
Dunno the history but it's from the time before VIA begins publishing.
It's probably worthwhile to refine the blacklisting.
>> * MCP51 is a very old chipset at this point (it's circa 2005). Not
>> many machine would be running with >4GB memory to begin with.
>>
>> * Given the above and scarcity of DAC on most end user machines
>> (nothing on MCP51 does DAC by default), lack of reports isn't too
>> surprising.
>>
>> * The board doesn't have a 64bit connector. It can't be dodgy
>> connector and sil24 is known to behave well with DAC. The failure
>> being specific to the particular machine doesn't seem likely.
>>
>> I'll ping nvidia about it but I think your bar is too high.
>
> I don't think wanting to see *two* examples is a high bar.
I don't think it's an easy combination. Circa 2005 desktop machine
with >4GB ram + DAC capable controller running Linux with owner who
will report seemingly random data corruption which will end up in the
correct hands and given that non-working DAC isn't too surprising of
the machines of that time and isn't very likely caused by random
component or connection failure, I think we'll be better off just
blacklisting it. That said, I admit I'm more trigger happy with
blacklists than some people (I think it's generally better to have
working systems than chasing performance on not-so-common cases).
Anyways, I pinged Peer Chen on the issue. Let's see whether he can
confirm it.
Thanks.
--
tejun
prev parent reply other threads:[~2009-03-04 13:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 2:32 [PATCH 2.6.29-rc7 1/2] x86: fix iommu=nodac parameter handling Tejun Heo
2009-03-04 2:39 ` [PATCH 2.6.29-rc7 2/2] x86: disallow DAC for MCP51 PCI bridge Tejun Heo
2009-03-04 9:57 ` Alan Cox
2009-03-04 10:11 ` Tejun Heo
2009-03-04 13:29 ` Alan Cox
2009-03-04 13:36 ` Tejun Heo [this message]
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=49AE83E6.4040608@kernel.org \
--to=tj@kernel.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pgnet.trash@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.