To: Ross Biro <rossb@google.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode
References: <4252E827.4080807@google.com>
From: Andi Kleen <ak@muc.de>
Date: Sun, 10 Apr 2005 15:29:10 +0200
In-Reply-To: <4252E827.4080807@google.com> (Ross Biro's message of "Tue, 05
 Apr 2005 12:33:59 -0700")
Message-ID: <m14qee221l.fsf@muc.de>
User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1227
Lines: 26

Ross Biro <rossb@google.com> writes:
>
> I even have a single motherboard with both a device that cannot handle
> the target abort and an IDE controller that can handle the target
> abort behind the same bridge.  For this motherboard, I have to choose
> the lesser of two evils, network hiccups or potential data corruption.
> For the record, I have seen both occur.  Other people may make wish to
> make a different choice than we did, hence this patch allows the user
> to choose the mode at runtime.

I think it is totally wrong to make this Configs and boot options.
Nobody can do anything with such obscure boot configurations
and it is bad to require kernel recompiles for such things.

The right way to do this would be to have sysfs knobs that allow
to change these bits, and then let a user space tool change
it depending on PCI-ID. If the issue is critical enough
that it happens very often then it should be added to kernel
pci quirks - but again be unconditional.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/