Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Daniel Egger
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Dave Jones
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Andi Kleen
> 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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Tim Hockin
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Ross Biro
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Ross Biro
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Tim Hockin
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Andi Kleen
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Dave Jones
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-14 Thread Daniel Egger
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-13 Thread Dave Jones
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-13 Thread Ross Biro
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-13 Thread Andi Kleen
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-13 Thread Andi Kleen
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-13 Thread Ross Biro
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-13 Thread Dave Jones
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-10 Thread Andi Kleen
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-10 Thread Andi Kleen
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-06 Thread Daniel Egger
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-06 Thread Ross Biro
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-06 Thread Ross Biro
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-06 Thread Daniel Egger
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-05 Thread Randy.Dunlap
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

[RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-05 Thread Ross Biro
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

[RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-05 Thread Ross Biro
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

Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-05 Thread Randy.Dunlap
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