On Thu, 27 Dec 2007 06:46:22 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Linus Torvalds wrote:
> > Well, the *current* behaviour as far as setup is concerned is
> > unacceptable. But yes, longer term, we should be able to just have
> > quirk entries for saying "enable mmconfig because I know
Linus Torvalds wrote:
Well, the *current* behaviour as far as setup is concerned is
unacceptable. But yes, longer term, we should be able to just have quirk
entries for saying "enable mmconfig because I know it's safe", except we
should not enable them until after the core PCI probing has
Linus Torvalds wrote:
Well, the *current* behaviour as far as setup is concerned is
unacceptable. But yes, longer term, we should be able to just have quirk
entries for saying enable mmconfig because I know it's safe, except we
should not enable them until after the core PCI probing has
On Thu, 27 Dec 2007 06:46:22 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
Well, the *current* behaviour as far as setup is concerned is
unacceptable. But yes, longer term, we should be able to just have
quirk entries for saying enable mmconfig because I know it's
> Reading past the first 256 bytes of the sysfs file should be enough
> -- only root can do that (other users get only 64 bytes anyway) and
> problems with reading random registers have hopefully taught programs
> not to read blindly a long time ago.
... except for lspci itself which reads the
Hello!
> (and yes I realize this needs lspci to be expanded some to set the
> flag if the admin really asks for it, but such is life)
Reading past the first 256 bytes of the sysfs file should be enough
-- only root can do that (other users get only 64 bytes anyway) and
problems with reading
Hello!
(and yes I realize this needs lspci to be expanded some to set the
flag if the admin really asks for it, but such is life)
Reading past the first 256 bytes of the sysfs file should be enough
-- only root can do that (other users get only 64 bytes anyway) and
problems with reading random
Reading past the first 256 bytes of the sysfs file should be enough
-- only root can do that (other users get only 64 bytes anyway) and
problems with reading random registers have hopefully taught programs
not to read blindly a long time ago.
... except for lspci itself which reads the first
On Mon, Dec 24, 2007 at 10:51:22AM -0800, Linus Torvalds wrote:
> The *second* problem is entirely a kernel internal issue. It's the one
> that causes us the biggest issues right now, but it's also the one that
> will not impact user space at all once if is fixed. So once we do the
> *early*
On Mon, 24 Dec 2007, Jeff Garzik wrote:
>
> Definitely. So, two questions:
>
> What's the preferred way to deal with the desire to view extended config space
> with "lspci -vvvxxx"?
Well, there's two issues right now with MMCONFIG
- we've hit various bugs in it. The bugs are admittedly
On Mon, Dec 24, 2007 at 02:22:10AM -0500, Jeff Garzik wrote:
> The phrase "all or none" specifically describes the current practice in
> arch/x86/pci/mmconfig_{32,64}.c whereby a PCI bus always has one, and only
> one, access method.
>
> So the problems you describe are unrelated to "all or
On Mon, 24 Dec 2007 06:54:30 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > I can see the point of having a sysfs attribute to enable MMCONF
> > from userspace, so that userland diagnostics tools can turn it on
> > if they really really want to. (I'd make that printk a
Arjan van de Ven wrote:
I can see the point of having a sysfs attribute to enable MMCONF from
userspace, so
that userland diagnostics tools can turn it on if they really really want to.
(I'd make that printk a nice warning "application XYZ is enabling extended config
space for devize ABC" so
On Mon, 24 Dec 2007 02:04:41 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> >> 3) mmconfig might or might not be enabled, depending on which
> >> driver is loaded, whether it called an API or not.
> >>
> >>Even LESS testing by hw vendors than #2. Maybe even
> >>
On Mon, 24 Dec 2007 02:04:41 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
3) mmconfig might or might not be enabled, depending on which
driver is loaded, whether it called an API or not.
Even LESS testing by hw vendors than #2. Maybe even
never
Arjan van de Ven wrote:
I can see the point of having a sysfs attribute to enable MMCONF from
userspace, so
that userland diagnostics tools can turn it on if they really really want to.
(I'd make that printk a nice warning application XYZ is enabling extended config
space for devize ABC so
On Mon, 24 Dec 2007 06:54:30 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
I can see the point of having a sysfs attribute to enable MMCONF
from userspace, so that userland diagnostics tools can turn it on
if they really really want to. (I'd make that printk a nice
On Mon, Dec 24, 2007 at 02:22:10AM -0500, Jeff Garzik wrote:
The phrase all or none specifically describes the current practice in
arch/x86/pci/mmconfig_{32,64}.c whereby a PCI bus always has one, and only
one, access method.
So the problems you describe are unrelated to all or none as I
On Mon, 24 Dec 2007, Jeff Garzik wrote:
Definitely. So, two questions:
What's the preferred way to deal with the desire to view extended config space
with lspci -vvvxxx?
Well, there's two issues right now with MMCONFIG
- we've hit various bugs in it. The bugs are admittedly very rare,
On Mon, Dec 24, 2007 at 10:51:22AM -0800, Linus Torvalds wrote:
The *second* problem is entirely a kernel internal issue. It's the one
that causes us the biggest issues right now, but it's also the one that
will not impact user space at all once if is fixed. So once we do the
*early*
Linus Torvalds wrote:
(For example: I have three machines that I know have working MMCONF. On
only one of theose does Linux actually even enable MMCONF accesses,
because on the two other ones the BIOSes do the crazy "put it in some
space that is reserved by PnP crap later", so we actually
Ivan Kokshaysky wrote:
On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
Failures are more predictable and more consistent with an all-or-none
scenario. The all-or-none solutions are the least complex on the software
side, and far more widely tested than any mixed config access
Arjan van de Ven wrote:
3) mmconfig might or might not be enabled, depending on which driver
is loaded, whether it called an API or not.
Even LESS testing by hw vendors than #2. Maybe even "never"
Inconsistent (config access depends on device)
the "depends on device" is even
> I've occasionally wondered if that spinlock needs to get split up, but
> for the amount of pain that could ensue, I can't imagine it ever being
> worthwhile.
Wondered the same thing and decided against it. I do have every now and
then some really crazy cases to deal with. One of them is the
On Mon, 2007-12-24 at 10:06 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2007-12-23 at 22:15 +0100, Martin Mares wrote:
> > Hello!
> >
> > > - During that probe, you set a flag if any device has capabilities that
> > > extend beyond 0xff.
> >
> > Can this work? The extended capabilities are
On Sun, 2007-12-23 at 22:15 +0100, Martin Mares wrote:
> Hello!
>
> > - During that probe, you set a flag if any device has capabilities that
> > extend beyond 0xff.
>
> Can this work? The extended capabilities are not linked to the normal
> ones in any way.
Yeah, well, you set a flag if you
On Sun, Dec 23, 2007 at 10:15:10PM +0100, Martin Mares wrote:
> > - During that probe, you set a flag if any device has capabilities that
> > extend beyond 0xff.
>
> Can this work? The extended capabilities are not linked to the normal
> ones in any way.
Good point.
OTOH, we *do* have a flag
Hello!
> - During that probe, you set a flag if any device has capabilities that
> extend beyond 0xff.
Can this work? The extended capabilities are not linked to the normal
ones in any way.
Have a nice fortnight
--
Martin `MJ' Mares
> Are you prepared to guarantee that freely mixing mmconfig and type1
> config accesses at runtime will always work, on all chipsets? I'm
> talking about silicon here, not kernel software.
We spinlock config space accesses. So the silicon will never see
simultaneous accesses, which is what I
On Sat, 2007-12-22 at 21:00 -0800, Linus Torvalds wrote:
>
> On Sat, 22 Dec 2007, Jeff Garzik wrote:
> >
> > But regardless of problems, enabling should be done globally, not per
> > device...
>
> I'm ok with trying the "globally" idea, but it has to be "globally but
> only if absolutely
On Sun, 23 Dec 2007, Ivan Kokshaysky wrote:
>
> This is a result of all-or-none approach, as mmconfig is fundamentally
> unsafe until after PCI init is done.
Yes. One of the things I want to have happen (and which
"pci_enable_mmconf()" would do automatically) is that we always probe
using
On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
> Failures are more predictable and more consistent with an all-or-none
> scenario. The all-or-none solutions are the least complex on the software
> side, and far more widely tested than any mixed config access scheme.
Nope. The
>
> 3) mmconfig might or might not be enabled, depending on which driver
> is loaded, whether it called an API or not.
>
> Even LESS testing by hw vendors than #2. Maybe even "never"
>
> Inconsistent (config access depends on device)
the "depends on device" is even true for Linux
Hi!
> The fact is, 99% of the hardware you buy *today* has absolutely zero need
> for extended PCI config access. In fact, I would not be surprised at all
> if most hardware sold today generally doesn't have *any* devices that even
> have config registers in the 0x100+ range.
Most PCI Express
On 12/23/2007 12:44 AM, Jeff Garzik wrote:
>>
>> By possibly using different implementations for the two ranges you avoid
>> introducing a new API, you avoid taking risks with mmconf when you don't
>> need it. That doesn't preclude using mmconf for everything either if the
>> user requests it or
On 12/23/2007 12:44 AM, Jeff Garzik wrote:
By possibly using different implementations for the two ranges you avoid
introducing a new API, you avoid taking risks with mmconf when you don't
need it. That doesn't preclude using mmconf for everything either if the
user requests it or based on
Hi!
The fact is, 99% of the hardware you buy *today* has absolutely zero need
for extended PCI config access. In fact, I would not be surprised at all
if most hardware sold today generally doesn't have *any* devices that even
have config registers in the 0x100+ range.
Most PCI Express
3) mmconfig might or might not be enabled, depending on which driver
is loaded, whether it called an API or not.
Even LESS testing by hw vendors than #2. Maybe even never
Inconsistent (config access depends on device)
the depends on device is even true for Linux today. For
On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
Failures are more predictable and more consistent with an all-or-none
scenario. The all-or-none solutions are the least complex on the software
side, and far more widely tested than any mixed config access scheme.
Nope. The vast
On Sun, 23 Dec 2007, Ivan Kokshaysky wrote:
This is a result of all-or-none approach, as mmconfig is fundamentally
unsafe until after PCI init is done.
Yes. One of the things I want to have happen (and which
pci_enable_mmconf() would do automatically) is that we always probe
using conf1
On Sat, 2007-12-22 at 21:00 -0800, Linus Torvalds wrote:
On Sat, 22 Dec 2007, Jeff Garzik wrote:
But regardless of problems, enabling should be done globally, not per
device...
I'm ok with trying the globally idea, but it has to be globally but
only if absolutely required.
And
Are you prepared to guarantee that freely mixing mmconfig and type1
config accesses at runtime will always work, on all chipsets? I'm
talking about silicon here, not kernel software.
We spinlock config space accesses. So the silicon will never see
simultaneous accesses, which is what I
Hello!
- During that probe, you set a flag if any device has capabilities that
extend beyond 0xff.
Can this work? The extended capabilities are not linked to the normal
ones in any way.
Have a nice fortnight
--
Martin `MJ' Mares
On Sun, Dec 23, 2007 at 10:15:10PM +0100, Martin Mares wrote:
- During that probe, you set a flag if any device has capabilities that
extend beyond 0xff.
Can this work? The extended capabilities are not linked to the normal
ones in any way.
Good point.
OTOH, we *do* have a flag for the
On Sun, 2007-12-23 at 22:15 +0100, Martin Mares wrote:
Hello!
- During that probe, you set a flag if any device has capabilities that
extend beyond 0xff.
Can this work? The extended capabilities are not linked to the normal
ones in any way.
Yeah, well, you set a flag if you have
On Mon, 2007-12-24 at 10:06 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2007-12-23 at 22:15 +0100, Martin Mares wrote:
Hello!
- During that probe, you set a flag if any device has capabilities that
extend beyond 0xff.
Can this work? The extended capabilities are not linked to
I've occasionally wondered if that spinlock needs to get split up, but
for the amount of pain that could ensue, I can't imagine it ever being
worthwhile.
Wondered the same thing and decided against it. I do have every now and
then some really crazy cases to deal with. One of them is the need
Arjan van de Ven wrote:
3) mmconfig might or might not be enabled, depending on which driver
is loaded, whether it called an API or not.
Even LESS testing by hw vendors than #2. Maybe even never
Inconsistent (config access depends on device)
the depends on device is even
Ivan Kokshaysky wrote:
On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
Failures are more predictable and more consistent with an all-or-none
scenario. The all-or-none solutions are the least complex on the software
side, and far more widely tested than any mixed config access
Linus Torvalds wrote:
(For example: I have three machines that I know have working MMCONF. On
only one of theose does Linux actually even enable MMCONF accesses,
because on the two other ones the BIOSes do the crazy put it in some
space that is reserved by PnP crap later, so we actually refuse
Jeff Garzik wrote:
2) It is legal for PCI-Express to put capabilities anywhere in PCI
config space, including extended config space. (I hope our PCI cap
walking code checks for overruns...)
Uh, not really. The classical capability format only has 8-bit
addresses, and the spec requires
Loic Prylli wrote:
Supporting extended-conf-space is independant of the issue of using
mmconf for legacy conf-space.
True.
There is no real reason to use the same
method to access both. I have seen several arguments used that were
implying that, and they all seem really bogus to me. Not
On 12/22/2007 11:52 PM, Jeff Garzik wrote:
>
> Absolutely.
>
> But regardless of problems, enabling should be done globally, not per
> device...
The "enabling globally" requirement, i.e. not per-device, neither
depending on reg >= 256 seems a very debatable assumption (IMHO a big
mistake)
Linus Torvalds wrote:
On Sun, 23 Dec 2007, Jeff Garzik wrote:
And yes, if you want the capability following to notice automatically when
capabilities really do go into the 0x100+ range, that's fine. I suspect
Yes, we /must/ do this checking, if we don't already.
Hell no. If the user asked
On Sun, 23 Dec 2007, Jeff Garzik wrote:
>
> Then let's do it right: disable mmconfig by default on x86, and enable it
> when passed "pci=mmconfig".
I'm certainly ok with that, but then you say:
> > And yes, if you want the capability following to notice automatically when
> > capabilities
On 12/22/2007 11:13 PM, Jeff Garzik wrote:
>
> The facts as they exist today:
>
> 1) Existing 256-byte config space devices have been known put
> capabilities in the high end (>= 0xc8) of config space.
>
> 2) It is legal for PCI-Express to put capabilities anywhere in PCI
> config space, including
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Jeff Garzik wrote:
But regardless of problems, enabling should be done globally, not per
device...
I'm ok with trying the "globally" idea, but it has to be "globally but
only if absolutely required".
And quite frankly, how do you tell whether
Linus Torvalds wrote:
I want to limit that downside. Right now, the easiest way to limit it
seems to be to say that those (very very few) drivers that actually care
could enable it. That way, we automatically limit it to only those
machines that have hardware that cares.
Then let's do it
On Sat, 22 Dec 2007, Jeff Garzik wrote:
>
> But regardless of problems, enabling should be done globally, not per
> device...
I'm ok with trying the "globally" idea, but it has to be "globally but
only if absolutely required".
And quite frankly, how do you tell whether it's absolutely
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Jeff Garzik wrote:
My core assertion: the present situation -- turning off MMCONFIG aggressively
-- is greatly preferable to adding pci_enable_mmconfig_accesses(pdev).
Well, you do realize that right now we have to have _users_ just doing
On Sat, 22 Dec 2007, Jeff Garzik wrote:
>
> Jeff Garzik wrote:
> > Maybe that day will never come, but it is nonetheless quite possible without
> > today's PCI Express spec for this to happen.
>
> er, s/without/within/
You're talking specs. I'm talking machines.
I agree with you 100% that as
On Sat, 22 Dec 2007, Jeff Garzik wrote:
>
> It should be self-evident that mmconfig doesn't work on old hardware, is not
> needed on old hardware, should not be turned on for old hardware, and in
> general should never disturb old hardware.
.. but it does. How do you figure out when to turn it
On Sat, 22 Dec 2007, Jeff Garzik wrote:
> My core assertion: the present situation -- turning off MMCONFIG aggressively
> -- is greatly preferable to adding pci_enable_mmconfig_accesses(pdev).
Well, you do realize that right now we have to have _users_ just doing
"pci=nommconf" on the kernel
Jeff Garzik wrote:
Maybe that day will never come, but it is nonetheless quite possible
without today's PCI Express spec for this to happen.
er, s/without/within/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Jeff Garzik wrote:
Regardless of whether a driver is loaded or not, you may NEED to see extended
capabilities. The system may NEED to see those capabilities just to parse
them for sane operation.
And that's just not true.
I don't know why you even
Linus Torvalds wrote:
The problem is that it isn't enough that it works on common machines with
good hardware. The problem is that we end up chasing insane bugs, wasting
peoples valuable time and effort, on those *few* - out of *millions* - of
machines that then surprisingly don't work.
And
On Sat, 22 Dec 2007, Jeff Garzik wrote:
>
> I forcibly turn on mmconfig on all my machines, and monitor lkml, to make sure
> I'm aware of the extent of the problem -- and the extent of peoples'
> exaggeration of this problem.
Bullshit.
You have how many machines? Ten?
The problem is that it
Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space
(using MCFG acpi table etc) to be opt-in, since there's many issues
with it and most drivers don't even
Arjan van de Ven wrote:
On Sat, 22 Dec 2007 20:30:58 +0100
Martin Mares <[EMAIL PROTECTED]> wrote:
Hello!
Just make it so. The name is fine, the concept is unavoidable. The
people who complain are whiners that haven't ever had to deal with
the fact that there are broken machines around.
I
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Yuck. And, Linus is just being silly. Wait a year then turn on
MMCONFIG :) It took PCI MSI a while to mature, but is finally
getting there.
That
Greg KH wrote:
But it is that device, and the driver that controls this device that
cares about the extended config space. So it's fair to push this onto
the driver if needed, instead of forcing the pci core to just blindly
guess for all devices, and getting it wrong...
Nothing is being
On Sat, Dec 22, 2007 at 08:02:49AM -0800, Arjan van de Ven wrote:
> even then.. it's technically not correct; you're not supposed to mix access
> types for the same device..
> Just doing opt-in also allows us to do quirks (forbid access) as well.
I think what this specification means is that you
On Sat, 2007-12-22 at 04:31 -0800, Arjan van de Ven wrote:
> Hi,
>
> Linus really wants the extended (4Kb) PCI configuration space (using MCFG
> acpi table etc) to be opt-in, since there's many issues with it and most
> drivers don't even use/need it. The idea behind opt-in is that if you
Hello!
> it's not "just a couple of chipsets", it's actually
> * a whole lot of bioses
> * at least one whole CPU generation
> * ..
> * ..
>
> Do you really want to code all of that into your userspace access code as
> well?
No, I certainly don't. But I expect this to be handled reasonably in
On Sat, 22 Dec 2007 20:30:58 +0100
Martin Mares <[EMAIL PROTECTED]> wrote:
> Hello!
>
> > Just make it so. The name is fine, the concept is unavoidable. The
> > people who complain are whiners that haven't ever had to deal with
> > the fact that there are broken machines around.
>
> I complain
Hello!
> Just make it so. The name is fine, the concept is unavoidable. The people
> who complain are whiners that haven't ever had to deal with the fact that
> there are broken machines around.
I complain as well as the maintainer of the pciutils. Breaking all userspace
accesses to extended
On Sat, Dec 22, 2007 at 10:22:29AM -0600, Robert Hancock wrote:
> Arjan van de Ven wrote:
>> Hi,
>> Linus really wants the extended (4Kb) PCI configuration space (using MCFG
>> acpi table etc) to be opt-in, since there's many issues with it and most
>> drivers don't even use/need it. The idea
On Sat, 22 Dec 2007, Arjan van de Ven wrote:
> On Sat, 22 Dec 2007 09:20:06 -0500
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > Yuck. And, Linus is just being silly. Wait a year then turn on
> > MMCONFIG :) It took PCI MSI a while to mature, but is finally
> > getting there.
That
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space (using MCFG acpi
table etc) to be opt-in, since there's many issues with it and most drivers
don't even use/need it. The idea behind opt-in is that if you don't use it, you
don't get to suffer the
On Sat, 22 Dec 2007 08:54:37 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 22, 2007 at 06:47:19AM -0800, Arjan van de Ven wrote:
> > Do you hate the name or the concept? I'm certainly open for a
> > better name
>
> I hate the concept. We should just fall back to type1
On Sat, Dec 22, 2007 at 06:47:19AM -0800, Arjan van de Ven wrote:
> Do you hate the name or the concept? I'm certainly open for a better name
I hate the concept. We should just fall back to type1 accesses on
mmconfig machines for all accesses below 64 bytes, as Ivan suggested.
--
Intel
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > Hi,
> >
> > Linus really wants the extended (4Kb) PCI configuration space
> > (using MCFG acpi table etc) to be opt-in, since there's many issues
> > with it and most drivers don't even
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space (using MCFG acpi
table etc) to be opt-in, since there's many issues with it and most drivers
don't even use/need it. The idea behind opt-in is that if you don't use it, you
don't get to suffer the
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space (using MCFG acpi
table etc) to be opt-in, since there's many issues with it and most drivers
don't even use/need it. The idea behind opt-in is that if you don't use it, you
don't get to suffer the
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space
(using MCFG acpi table etc) to be opt-in, since there's many issues
with it and most drivers don't even use/need it. The
On Sat, Dec 22, 2007 at 06:47:19AM -0800, Arjan van de Ven wrote:
Do you hate the name or the concept? I'm certainly open for a better name
I hate the concept. We should just fall back to type1 accesses on
mmconfig machines for all accesses below 64 bytes, as Ivan suggested.
--
Intel are
On Sat, 22 Dec 2007 08:54:37 -0700
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Sat, Dec 22, 2007 at 06:47:19AM -0800, Arjan van de Ven wrote:
Do you hate the name or the concept? I'm certainly open for a
better name
I hate the concept. We should just fall back to type1 accesses on
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space (using MCFG acpi
table etc) to be opt-in, since there's many issues with it and most drivers
don't even use/need it. The idea behind opt-in is that if you don't use it, you
don't get to suffer the
On Sat, 22 Dec 2007, Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Yuck. And, Linus is just being silly. Wait a year then turn on
MMCONFIG :) It took PCI MSI a while to mature, but is finally
getting there.
That _really_ doesn't
On Sat, Dec 22, 2007 at 10:22:29AM -0600, Robert Hancock wrote:
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space (using MCFG
acpi table etc) to be opt-in, since there's many issues with it and most
drivers don't even use/need it. The idea behind
Hello!
Just make it so. The name is fine, the concept is unavoidable. The people
who complain are whiners that haven't ever had to deal with the fact that
there are broken machines around.
I complain as well as the maintainer of the pciutils. Breaking all userspace
accesses to extended
On Sat, 22 Dec 2007 20:30:58 +0100
Martin Mares [EMAIL PROTECTED] wrote:
Hello!
Just make it so. The name is fine, the concept is unavoidable. The
people who complain are whiners that haven't ever had to deal with
the fact that there are broken machines around.
I complain as well as
Hello!
it's not just a couple of chipsets, it's actually
* a whole lot of bioses
* at least one whole CPU generation
* ..
* ..
Do you really want to code all of that into your userspace access code as
well?
No, I certainly don't. But I expect this to be handled reasonably in the
On Sat, 2007-12-22 at 04:31 -0800, Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space (using MCFG
acpi table etc) to be opt-in, since there's many issues with it and most
drivers don't even use/need it. The idea behind opt-in is that if you don't
On Sat, Dec 22, 2007 at 08:02:49AM -0800, Arjan van de Ven wrote:
even then.. it's technically not correct; you're not supposed to mix access
types for the same device..
Just doing opt-in also allows us to do quirks (forbid access) as well.
I think what this specification means is that you
Greg KH wrote:
But it is that device, and the driver that controls this device that
cares about the extended config space. So it's fair to push this onto
the driver if needed, instead of forcing the pci core to just blindly
guess for all devices, and getting it wrong...
Nothing is being
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Yuck. And, Linus is just being silly. Wait a year then turn on
MMCONFIG :) It took PCI MSI a while to mature, but is finally
getting there.
That
Arjan van de Ven wrote:
On Sat, 22 Dec 2007 20:30:58 +0100
Martin Mares [EMAIL PROTECTED] wrote:
Hello!
Just make it so. The name is fine, the concept is unavoidable. The
people who complain are whiners that haven't ever had to deal with
the fact that there are broken machines around.
I
Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space
(using MCFG acpi table etc) to be opt-in, since there's many issues
with it and most drivers don't even
On Sat, 22 Dec 2007, Jeff Garzik wrote:
I forcibly turn on mmconfig on all my machines, and monitor lkml, to make sure
I'm aware of the extent of the problem -- and the extent of peoples'
exaggeration of this problem.
Bullshit.
You have how many machines? Ten?
The problem is that it isn't
1 - 100 of 116 matches
Mail list logo
