On 14.04.2005, at 19:25, Ross Biro wrote:
Just to be clear, we can have two users A and B with the exact same
hardware. A setting of =y will screw user A and a setting of =n will
screw user B. Ideally, they would both get better hardware, but that
is not always an option.
You tell me a better[1]
On Thu, Apr 14, 2005 at 08:02:02PM +0200, Andi Kleen wrote:
> > What if it was always on, except when the commandlien was passed
> > (eliminate the CONFIG option)? Really 'leet hacks could tweak a #define
> > if they don't like the command line option..
>
> That is basically what I suggested
> What if it was always on, except when the commandlien was passed
> (eliminate the CONFIG option)? Really 'leet hacks could tweak a #define
> if they don't like the command line option..
That is basically what I suggested. But test it for a month
in -mm* first and figure out if it needs more bla
On 4/13/05, Dave Jones <[EMAIL PROTECTED]> wrote:
> If we have a situation where we screw a subset of users with the
> config option =y and a different subset with =n, how is this improving
> the situation any over what we have today ?
Dave,
What's a good alternative? Do we need to keep a white
On 4/13/05, Dave Jones <[EMAIL PROTECTED]> wrote:
> If we have a situation where we screw a subset of users with the
> config option =y and a different subset with =n, how is this improving
> the situation any over what we have today ?
This is exactly the case and this is better than what we have
On Wed, Apr 13, 2005 at 07:00:06PM -0400, Ross Biro wrote:
> > If you take a look at quirks.c and DMI options you will see we have quite
> > a lot
> > of workarounds for various hardware bug. Just imagine there were
> > CONFIG options for all of this. It would be a big mess!
>
> The confi
On 13 Apr 2005 20:37:25 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> \>
> > You're argument that no one can make sense of such options is totally off
> > base. Once you are having a problem, it's pretty easy to see if it's related
>
> I dont think it is in any way help to put suche highly obscur
On Tue, Apr 12, 2005 at 10:52:55AM -0400, Ross Biro wrote:
> On Apr 10, 2005 9:29 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> >
> > 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 t
Ross Biro <[EMAIL PROTECTED]> 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
On 05.04.2005, at 21:33, Ross Biro wrote:
The problem with always setting the bit is that some PCI hardware,
notably some Intel E-1000 chips (Ethernet controller: Intel
Corporation: Unknown device 1076) cannot properly handle the target
abort bit. In the case of the E-1000 chip, the driver must
Randy.Dunlap wrote:
Is this related (or could it be -- or should it be) at all to the
current discussion on the linux-pci mailing list
[EMAIL PROTECTED]) about "PCI Error Recovery
API Proposal" ?
I'm not familiar with the proposal, but this is not related to error
recovery since master aborts ar
Ross Biro wrote:
Currently Linux 2.6 assumes the BIOS (or firmware) sets the master abort
mode flag on PCI bridge chips in a coherent fashion. This is not always
the case and the consequences of getting this flag incorrect can cause
hardware to fail or silent data corruption. This patch lets t
Currently Linux 2.6 assumes the BIOS (or firmware) sets the master abort
mode flag on PCI bridge chips in a coherent fashion. This is not always
the case and the consequences of getting this flag incorrect can cause
hardware to fail or silent data corruption. This patch lets the user
override
13 matches
Mail list logo
