Hello!
> > Maybe we should do all bus scanning with conf1 and then try if
> > MMCONFIG returns the same values?
>
> that is already in the code today but not nearly enough; there's a ton
> of cases where it's "touch mmconfig and the box is dead"...
Argh. However I still do not think it is an
Hello!
Maybe we should do all bus scanning with conf1 and then try if
MMCONFIG returns the same values?
that is already in the code today but not nearly enough; there's a ton
of cases where it's touch mmconfig and the box is dead...
Argh. However I still do not think it is an acceptable
On Thu, 1 Nov 2007 09:31:40 +0100
Martin Mares <[EMAIL PROTECTED]> wrote:
> Hello!
>
> > something like
> > int pci_enable_mmconfig(struct pci_dev *pdev) ?
> > sounds like a very solid plan to me...
>
> Please remember that the driver is not the sole user of the PCI config
> space -- user-space
Hello!
> something like
> int pci_enable_mmconfig(struct pci_dev *pdev) ?
> sounds like a very solid plan to me...
Please remember that the driver is not the sole user of the PCI config
space -- user-space programs (e.g., lspci) can access it via sysfs, too.
Should we force users of such
Hello!
something like
int pci_enable_mmconfig(struct pci_dev *pdev) ?
sounds like a very solid plan to me...
Please remember that the driver is not the sole user of the PCI config
space -- user-space programs (e.g., lspci) can access it via sysfs, too.
Should we force users of such programs
On Thu, 1 Nov 2007 09:31:40 +0100
Martin Mares [EMAIL PROTECTED] wrote:
Hello!
something like
int pci_enable_mmconfig(struct pci_dev *pdev) ?
sounds like a very solid plan to me...
Please remember that the driver is not the sole user of the PCI config
space -- user-space programs
On Tuesday, October 30, 2007 4:59 pm Linus Torvalds wrote:
> Also, there are several devices that don't show up in the MMCFG
> things, or just otherwise get it wrong.
>
> So just take a look at arch/x86/pci/mmconfig-shared.c and look for
> "conf1".
>
> Really. Damn, I'm nervous taking any MMCFG
Linus Torvalds wrote:
On Tue, 30 Oct 2007, Robert Hancock wrote:
You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
startup.
If it does, it's not by necessity. As soon as you read the table location out
of the ACPI tables you can start using it, and that shouldn't require
On Tue, 30 Oct 2007, Arjan van de Ven wrote:
>
> it's per device so that if you have have no users for this stuff,
> you'll never ever get bitten by bugs (be it linux or the bios).
Exactly. It's not that we care about trying to protect a system that
really needs to use MMCFG - once you really
On Tue, 30 Oct 2007, Robert Hancock wrote:
> >
> > You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
> > startup.
>
> If it does, it's not by necessity. As soon as you read the table location out
> of the ACPI tables you can start using it, and that shouldn't require any
>
On Tue, 30 Oct 2007 17:41:26 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> > I could easily see device driver writers probing to see if
> > something works, and I absolutely don't think we should just
> > automatically enable MMCONFIG from then on.
>
> Why per device? It's not like the MSI
Linus Torvalds wrote:
On Tue, 30 Oct 2007, Arjan van de Ven wrote:
the problem is... you're not supposed to mix both types of accesses.
You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
startup.
If it does, it's not by necessity. As soon as you read the table
> Actually, I guess the bad case wasn't "not listed at all", but incorrectly
> listed - so the probing would go to the wrong address, not find any
> devices, and then promptly result in an unusable machine with no hardware
> attached.
iirc they tended to hang for whatever reason when the mcfg
On Tue, 30 Oct 2007, Jesse Barnes wrote:
>
> Yeah, that's definitely a problem, and would be a firmware bug. There's
> no doubt that firmwares have had trouble with this in the past, but
> given that Vista now relies on this stuff working, it's a lot more
> likely to be reliable in current
From: Jesse Barnes <[EMAIL PROTECTED]>
Date: Tue, 30 Oct 2007 15:31:57 -0700
> I don't disagree there. I'm just saying the actual mechanism is fine
> (as illustrated by the numerous non-PC ports of Linux), and this
> particular problem, at least, isn't really specific to how MMCONFIG is
>
On Tuesday, October 30, 2007 3:38 pm Linus Torvalds wrote:
> On Tue, 30 Oct 2007, Linus Torvalds wrote:
> > No. You really don't see the big picture. There's been tons of
> > problems with MMCONFIG. Like the fact that other devices have their
> > IO regions registered on top of it, because the
On Tue, 30 Oct 2007, Linus Torvalds wrote:
>
> No. You really don't see the big picture. There's been tons of problems
> with MMCONFIG. Like the fact that other devices have their IO regions
> registered on top of it, because the MMCONFIG thing was done as a hidden
> resource. Or the fact
On Tuesday, October 30, 2007 3:22 pm Linus Torvalds wrote:
> On Tue, 30 Oct 2007, Jesse Barnes wrote:
> > The per-device flag is fine with me, but I should make something
> > clear:
> >
> > MMCONFIG IS NOT BROKEN!
>
> Trust me, it is.
>
> The particular problem _you_ had with it is only a small
On Tue, 30 Oct 2007, Jesse Barnes wrote:
>
> The per-device flag is fine with me, but I should make something clear:
>
> MMCONFIG IS NOT BROKEN!
Trust me, it is.
The particular problem _you_ had with it is only a small small part of the
bugs we have had.
> What's broken is our PCI probing
On Tuesday, October 30, 2007 10:07 am Linus Torvalds wrote:
> (Where "screwed up badly" is the usual "left it to firmware people"
> thing, of course. Dammit, Intel *could* have just made it a real PCI
> BAR in the Northbridge, and specified it as such, and we wouldn't
> have these problems! But
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 30 Oct 2007 19:50:58 +0100
> I believe the tigon3 driver also does config space access frequently
> on some chips.
This case is not worth optimizing for at all.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Tuesday 30 October 2007 20:06:12 Linus Torvalds wrote:
>
> On Tue, 30 Oct 2007, Andi Kleen wrote:
> >
> > Also there are still the old x86 Macs where conf1 doesn't work.
>
> I don't think that was ever true. That was a made-up rumor by the EFI
> people who were just confused.
> There's no
On Tue, 30 Oct 2007, Andi Kleen wrote:
>
> Also there are still the old x86 Macs where conf1 doesn't work.
I don't think that was ever true. That was a made-up rumor by the EFI
people who were just confused.
There's no way to disable conf1 accesses on any known chipset, afaik.
> At that point, almost all the issues with mmconfig just go away, BECAUSE
> NOBODY USES IT, so it doesn't matter if it's broken?
We seem to slowly grow more uses of registers > 256, but yes it's still mostly
non critical stuff.
> The fact is, CONF1 style accesses are just safer, and *work*.
On Tue, 30 Oct 2007, Arjan van de Ven wrote:
>
> something like
> int pci_enable_mmconfig(struct pci_dev *pdev) ?
Yes, that looks fine. It also matches the kinds of things drivers already
have to do (ie enable DMA, MSI etc), both conceptually and from a purely
syntactic/practical standpoint.
On Tue, 30 Oct 2007 10:07:48 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > > The fact is, CONF1 style accesses are just safer, and *work*.
> >
> > I would suggest a slight twist then: use CONF1 *until* you're using
> > something above 256, and then and only then switch to MMCONFIG
On Tue, 30 Oct 2007, Arjan van de Ven wrote:
>
> the problem is... you're not supposed to mix both types of accesses.
You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
startup.
Also, there's reason to believe that mixing things up _has_ to work
anyway, and if the issue
On Tue, 30 Oct 2007 08:15:46 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Oct 2007, Robert Hancock wrote:
> >
> > The other possible workaround would be to avoid using MMCONFIG
> > until the BAR sizing is done.
>
> The only sane solution is the one that people
On Mon, 29 Oct 2007, Robert Hancock wrote:
>
> The other possible workaround would be to avoid using MMCONFIG until the BAR
> sizing is done.
The only sane solution is the one that people constantly seem to ignore:
- only use MMCONFIG if absolutely required by the access itself
In other
On Mon, 29 Oct 2007, Robert Hancock wrote:
The other possible workaround would be to avoid using MMCONFIG until the BAR
sizing is done.
The only sane solution is the one that people constantly seem to ignore:
- only use MMCONFIG if absolutely required by the access itself
In other
On Tue, 30 Oct 2007 08:15:46 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Mon, 29 Oct 2007, Robert Hancock wrote:
The other possible workaround would be to avoid using MMCONFIG
until the BAR sizing is done.
The only sane solution is the one that people constantly seem to
On Tue, 30 Oct 2007, Arjan van de Ven wrote:
the problem is... you're not supposed to mix both types of accesses.
You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
startup.
Also, there's reason to believe that mixing things up _has_ to work
anyway, and if the issue is
On Tue, 30 Oct 2007 10:07:48 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
The fact is, CONF1 style accesses are just safer, and *work*.
I would suggest a slight twist then: use CONF1 *until* you're using
something above 256, and then and only then switch to MMCONFIG from
then
On Tue, 30 Oct 2007, Arjan van de Ven wrote:
something like
int pci_enable_mmconfig(struct pci_dev *pdev) ?
Yes, that looks fine. It also matches the kinds of things drivers already
have to do (ie enable DMA, MSI etc), both conceptually and from a purely
syntactic/practical standpoint.
I
At that point, almost all the issues with mmconfig just go away, BECAUSE
NOBODY USES IT, so it doesn't matter if it's broken?
We seem to slowly grow more uses of registers 256, but yes it's still mostly
non critical stuff.
The fact is, CONF1 style accesses are just safer, and *work*.
On Tue, 30 Oct 2007, Andi Kleen wrote:
Also there are still the old x86 Macs where conf1 doesn't work.
I don't think that was ever true. That was a made-up rumor by the EFI
people who were just confused.
There's no way to disable conf1 accesses on any known chipset, afaik.
On Tuesday 30 October 2007 20:06:12 Linus Torvalds wrote:
On Tue, 30 Oct 2007, Andi Kleen wrote:
Also there are still the old x86 Macs where conf1 doesn't work.
I don't think that was ever true. That was a made-up rumor by the EFI
people who were just confused.
There's no way to
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 30 Oct 2007 19:50:58 +0100
I believe the tigon3 driver also does config space access frequently
on some chips.
This case is not worth optimizing for at all.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Tuesday, October 30, 2007 10:07 am Linus Torvalds wrote:
(Where screwed up badly is the usual left it to firmware people
thing, of course. Dammit, Intel *could* have just made it a real PCI
BAR in the Northbridge, and specified it as such, and we wouldn't
have these problems! But no, it had
On Tue, 30 Oct 2007, Jesse Barnes wrote:
The per-device flag is fine with me, but I should make something clear:
MMCONFIG IS NOT BROKEN!
Trust me, it is.
The particular problem _you_ had with it is only a small small part of the
bugs we have had.
What's broken is our PCI probing with
On Tuesday, October 30, 2007 3:22 pm Linus Torvalds wrote:
On Tue, 30 Oct 2007, Jesse Barnes wrote:
The per-device flag is fine with me, but I should make something
clear:
MMCONFIG IS NOT BROKEN!
Trust me, it is.
The particular problem _you_ had with it is only a small small part
of
On Tue, 30 Oct 2007, Linus Torvalds wrote:
No. You really don't see the big picture. There's been tons of problems
with MMCONFIG. Like the fact that other devices have their IO regions
registered on top of it, because the MMCONFIG thing was done as a hidden
resource. Or the fact that the
On Tuesday, October 30, 2007 3:38 pm Linus Torvalds wrote:
On Tue, 30 Oct 2007, Linus Torvalds wrote:
No. You really don't see the big picture. There's been tons of
problems with MMCONFIG. Like the fact that other devices have their
IO regions registered on top of it, because the MMCONFIG
From: Jesse Barnes [EMAIL PROTECTED]
Date: Tue, 30 Oct 2007 15:31:57 -0700
I don't disagree there. I'm just saying the actual mechanism is fine
(as illustrated by the numerous non-PC ports of Linux), and this
particular problem, at least, isn't really specific to how MMCONFIG is
described
On Tue, 30 Oct 2007, Jesse Barnes wrote:
Yeah, that's definitely a problem, and would be a firmware bug. There's
no doubt that firmwares have had trouble with this in the past, but
given that Vista now relies on this stuff working, it's a lot more
likely to be reliable in current and
Actually, I guess the bad case wasn't not listed at all, but incorrectly
listed - so the probing would go to the wrong address, not find any
devices, and then promptly result in an unusable machine with no hardware
attached.
iirc they tended to hang for whatever reason when the mcfg
area was
Linus Torvalds wrote:
On Tue, 30 Oct 2007, Arjan van de Ven wrote:
the problem is... you're not supposed to mix both types of accesses.
You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
startup.
If it does, it's not by necessity. As soon as you read the table
On Tue, 30 Oct 2007 17:41:26 -0600
Robert Hancock [EMAIL PROTECTED] wrote:
I could easily see device driver writers probing to see if
something works, and I absolutely don't think we should just
automatically enable MMCONFIG from then on.
Why per device? It's not like the MSI case where
On Tue, 30 Oct 2007, Robert Hancock wrote:
You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
startup.
If it does, it's not by necessity. As soon as you read the table location out
of the ACPI tables you can start using it, and that shouldn't require any
config
On Tue, 30 Oct 2007, Arjan van de Ven wrote:
it's per device so that if you have have no users for this stuff,
you'll never ever get bitten by bugs (be it linux or the bios).
Exactly. It's not that we care about trying to protect a system that
really needs to use MMCFG - once you really
Linus Torvalds wrote:
On Tue, 30 Oct 2007, Robert Hancock wrote:
You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
startup.
If it does, it's not by necessity. As soon as you read the table location out
of the ACPI tables you can start using it, and that shouldn't require
On Tuesday, October 30, 2007 4:59 pm Linus Torvalds wrote:
Also, there are several devices that don't show up in the MMCFG
things, or just otherwise get it wrong.
So just take a look at arch/x86/pci/mmconfig-shared.c and look for
conf1.
Really. Damn, I'm nervous taking any MMCFG patches
Greg KH wrote:
On Fri, Oct 26, 2007 at 09:59:45AM -0700, Jesse Barnes wrote:
On Thursday, October 25, 2007 7:54 pm Greg KH wrote:
On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
I think Greg doesn't like it, even though we don't have an
alternative at this point...
Yes, I
Greg KH wrote:
On Fri, Oct 26, 2007 at 09:59:45AM -0700, Jesse Barnes wrote:
On Thursday, October 25, 2007 7:54 pm Greg KH wrote:
On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
I think Greg doesn't like it, even though we don't have an
alternative at this point...
Yes, I
On Fri, Oct 26, 2007 at 09:59:45AM -0700, Jesse Barnes wrote:
> On Thursday, October 25, 2007 7:54 pm Greg KH wrote:
> > On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
> > > I think Greg doesn't like it, even though we don't have an
> > > alternative at this point...
> >
> > Yes, I
On Thursday, October 25, 2007 7:54 pm Greg KH wrote:
> On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
> > I think Greg doesn't like it, even though we don't have an
> > alternative at this point...
>
> Yes, I didn't like it, Ivan didn't like it, and I got reports that it
> wasn't
On Thursday, October 25, 2007 7:54 pm Greg KH wrote:
On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
I think Greg doesn't like it, even though we don't have an
alternative at this point...
Yes, I didn't like it, Ivan didn't like it, and I got reports that it
wasn't even
On Fri, Oct 26, 2007 at 09:59:45AM -0700, Jesse Barnes wrote:
On Thursday, October 25, 2007 7:54 pm Greg KH wrote:
On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
I think Greg doesn't like it, even though we don't have an
alternative at this point...
Yes, I didn't like
58 matches
Mail list logo
