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
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
> 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
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
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
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 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 whitelist
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
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. But
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
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
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
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
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 the issue is
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 obscure
things
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 config option
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
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
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
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 are
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
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
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
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
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
26 matches
Mail list logo