On Tuesday 29 January 2008 05:19:55 am Greg KH wrote:
> Hahahaha, oh, that's a good one...
>
> But what about the thousands of implementations out there that are
> buggy?
>
> I'm with Arjan here, I'm very skeptical.
Ugg, let's look at the actual data (again); I'm really not sure why people
are ju
On Wed, Jan 30, 2008 at 07:42:49AM -0800, Arjan van de Ven wrote:
> Xorg doesn't do pci express ..
Xorg core provides a set of PCI config access functions (via sysfs) for
the graphics drivers. These functions do work correctly with offsets > 256
bytes. Can you guarantee that none of PCI-E video dr
On Wed, 30 Jan 2008 18:15:39 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 29, 2008 at 08:45:55PM -0700, Matthew Wilcox wrote:
> > On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
> > > Matthew, with Arjan's patch, is anything that currently works now
> > > broken? Why do
On Tue, Jan 29, 2008 at 08:45:55PM -0700, Matthew Wilcox wrote:
> On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
> > Matthew, with Arjan's patch, is anything that currently works now
> > broken? Why do you feel it is somehow "wrong"?
>
> lspci is broken. It used to be able to access ex
On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
> On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
> > I'm more optimistic because we've so severely restricted the use of
> > mmconf after these patches that it's unlikely to cause problems. I also
> > hear Vista is now using
Matthew Wilcox wrote:
On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote:
Right now, that isn't a lot of people in x86 land, but your patch
encumbers drivers for non-x86 archs with an additional call to access
space that they've never had a problem with.
lets say s/x86/x86, IA64 a
On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote:
> > Right now, that isn't a lot of people in x86 land, but your patch
> > encumbers drivers for non-x86 archs with an additional call to access
> > space that they've never had a problem with.
>
> lets say s/x86/x86, IA64 and archit
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 10:15:45 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
specific to legacy x86 hardware is, IMNSHO, a kludge.
in addition to pci_enable(), pci_enable_msi(), pci_enable_busmaster() they
already need to do
to enable various features?
These calls a
On Tue, 29 Jan 2008 10:15:45 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Tue, 29 Jan 2008 09:15:02 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >
> >> Greg,
> >>
> >> The problem with Arjan's patch, if I understand it correctly, is
> >> that it requires dri
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 09:15:02 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
Greg,
The problem with Arjan's patch, if I understand it correctly, is that
it requires drivers to make a call to access extended PCI config
space.
And, IIRC, Arjan's patch encumbers drivers for
On Tue, 29 Jan 2008 09:15:02 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Greg KH wrote:
> > On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
> >> I'm more optimistic because we've so severely restricted the use of
> >> mmconf after these patches that it's unlikely to cause proble
Greg KH wrote:
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
I'm more optimistic because we've so severely restricted the use of
mmconf after these patches that it's unlikely to cause problems. I also
hear Vista is now using mmconf, so fewer implementations are going to
be bug
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
> On Mon, Jan 28, 2008 at 07:05:05PM -0800, Arjan van de Ven wrote:
> > I think there's only one fundamental disagreement; and that is:
> > do we think that things are now totally fixed and no new major issues
> > will arrive after the
On Mon, Jan 28, 2008 at 07:05:05PM -0800, Arjan van de Ven wrote:
> I think there's only one fundamental disagreement; and that is:
> do we think that things are now totally fixed and no new major issues
> will arrive after the "fix yet another mmconfig thing" patches are merged.
>
> If the answer
On Mon, 28 Jan 2008 12:44:31 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> > Greg,
> >
> > Have you given Grant's suggestion any further consideration?
> >
> > I'd like to know how the MMCONFIG issues discussed in this thread
> > are goin
On Mon, Jan 28, 2008 at 02:53:34PM -0800, Greg KH wrote:
> Please send me patches, in a form that can be merged, along with a
> proper changelog entry, in the order in which you wish them to be
> applied, so I know exactly what changes you are referring to.
I'll send each patch as a reply to this
On Mon, Jan 28, 2008 at 03:31:42PM -0700, Matthew Wilcox wrote:
> On Mon, Jan 28, 2008 at 12:44:31PM -0800, Greg KH wrote:
> > On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> > > Greg,
> > >
> > > Have you given Grant's suggestion any further consideration?
> > >
> > > I'd like to kn
On Mon, Jan 28, 2008 at 12:44:31PM -0800, Greg KH wrote:
> On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> > Greg,
> >
> > Have you given Grant's suggestion any further consideration?
> >
> > I'd like to know how the MMCONFIG issues discussed in this thread are going
> > to be handle
On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> Greg,
>
> Have you given Grant's suggestion any further consideration?
>
> I'd like to know how the MMCONFIG issues discussed in this thread are going
> to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
> rathe
Greg,
Have you given Grant's suggestion any further consideration?
I'd like to know how the MMCONFIG issues discussed in this thread are going
to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
rather have the upstream patch implemented, whatever it is.
Grant Grundler
On Tue, Jan 15, 2008 at 10:56:41AM -0700, Matthew Wilcox wrote:
> On Tue, Jan 15, 2008 at 09:46:43AM -0800, Greg KH wrote:
> > But so far, we have a zillion patches floating around, claiming
> > different things, some with signed-off-bys and others without, so for
> > now, I'll just stick with Arja
On 1/15/2008 2:38 PM, Linus Torvalds wrote:
On Tue, 15 Jan 2008, Tony Camuso wrote:
Linus is confident that conf1 is not going away for at least the
next five years.
Not on PC's. Small birds tell me that there can be all these non-PC x86
subarchitectures that may or may not have con
On Tue, Jan 15, 2008 at 11:38:42AM -0800, Linus Torvalds wrote:
> On Tue, 15 Jan 2008, Tony Camuso wrote:
> > Linus is confident that conf1 is not going away for at least the
> > next five years.
>
> Not on PC's. Small birds tell me that there can be all these non-PC x86
> subarchitectures that m
On Tue, 15 Jan 2008, Tony Camuso wrote:
>
> Linus is confident that conf1 is not going away for at least the
> next five years.
Not on PC's. Small birds tell me that there can be all these non-PC x86
subarchitectures that may or may not have conf1.
Linus
--
To unsubscribe from
I agree with Matthew.
My preference is Ivan's patch using Loic's proposal.
My patch would have tested MMCONFIG before using it, but it didn't
fix the problem where the decode of large displacement devices can
overlap the MMCONFIG region.
Ivan's patch fixes that, and the problem of Northbridges
On Tue, Jan 15, 2008 at 09:46:43AM -0800, Greg KH wrote:
> But so far, we have a zillion patches floating around, claiming
> different things, some with signed-off-bys and others without, so for
> now, I'll just stick with Arjan's patch in -mm and see if anyone
> complains about those releases...
On Tue, Jan 15, 2008 at 11:00:37AM -0500, Loic Prylli wrote:
>
>
> On 1/14/2008 6:04 PM, Adrian Bunk wrote:
>>> I thought so, but due to the way that things are initialised, mmconfig
>>> happens before conf1. conf1 is known to be usable, but hasn't set
>>> raw_pci_ops at this point. Confusing, an
On 1/14/2008 6:04 PM, Adrian Bunk wrote:
I thought so, but due to the way that things are initialised, mmconfig
happens before conf1. conf1 is known to be usable, but hasn't set
raw_pci_ops at this point. Confusing, and not ideal, but fixing this
isn't in scope for 2.6.24.
...
*ahem*
I just thought this might be interesting to the discussion.
I recently bought another 2 GB memory for my computer.
My hardware is as following:
Asus Commando (Intel P965 chipset)
Intel Core2 Q6600
4x1 GB Geil PC6400 memory
nVidia 8800 gts (old g80 core, 640 mb mem)
Without booting with pci=nomme
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the devic
On Mon, Jan 14, 2008 at 03:52:26PM -0700, Matthew Wilcox wrote:
> On Sun, Jan 13, 2008 at 09:01:08AM -0800, Arjan van de Ven wrote:
>...
> > > - pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0xce, 2, &win);
> > > + pci_direct_conf1.read(0, 0, PCI_DEVFN(0,0), 0xce, 2, &win);
> >
> > couldn't this (at le
On Sun, Jan 13, 2008 at 09:01:08AM -0800, Arjan van de Ven wrote:
> would be nice the "reg > 256 && raw_pci_Ext_ops==NULL" case would just
> call the raw_pci_ops-> pointer, to give that a chance of refusal
> (but I guess that shouldn't really happen)
We don't have a situation where that can happen
Arjan van de Ven wrote:
it's not pci_enable_mmconf(), it's pci_enable_extended_config_space... it's
independent of the mechanism!
Arjan, you would be foisting this call on device drivers running on
arches that don't need any such distinction between extended config
space and < 256 bytes.
I s
On Mon, 14 Jan 2008 10:23:14 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Mon, 14 Jan 2008 08:01:01 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >>
> >> If we're going to differentiate MMCONFIG from
> >> some other access mechanism, it only needs to be done
Arjan van de Ven wrote:
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
>>
If we're going to differentiate MMCONFIG from
some other access mechanism, it only needs to be done at the
Northbridge level. Devices are electrically ignorant of the protocol
used between CPU a
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Sun, 13 Jan 2008 22:29:23 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >
> >> . There is no need to provide different PCI config access
> >>mechanisms at device granularity, since
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the devic
> > even when designed for Redmond products.
>
> I find it hard to believe that even they have their drivers do PCI config
> access via ports directly from the drivers,
> and especially in driver reference code...
Microsoft may not but the standard of Taiwanese driver code (and by
reference I me
On Mon, 14 Jan 2008, Alan Cox wrote:
> >
> > As someone gently pointed out to me, you are in a position to know this,
> > so I probably am wrong.
>
> I suspect Arjan is wrong. It might be some Intel agenda but I still see
> fairly new driver reference code that is hardcoding port accesses even
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> . There is no need to provide different PCI config access
>mechanisms at device granularity, since the PCI config access
>mechanism between the CPU and the Northbridge is opaque to
>the devices. PCI config mech
To all ...
Well, here is what I perceive we've got so far.
. Some PCI Northbridges do not work with MMCONFIG.
. Some PCI BARs can overlap the MMCONFIG area during bus sizing.
It is hoped that new BIOSes will locate MMCONFIG in an area
safely out of the way of bus sizing code, but there can
On Mon, 14 Jan 2008 00:54:34 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jan 2008 16:28:08 -0500
> Tony Camuso <[EMAIL PROTECTED]> wrote:
>
> > Arjan van de Ven wrote:
> >
> > >> The PCI spec provides for conf1 as an architected solution. It's
> > >> not going away, and especially not
On Sun, 13 Jan 2008 16:28:08 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
>
> >> The PCI spec provides for conf1 as an architected solution. It's not
> >> going away, and especially not in x86 land where Port IO is built-in
> >> to the CPU.
> >
> > again sadly you're wr
Arjan van de Ven wrote:
The PCI spec provides for conf1 as an architected solution. It's not
going away, and especially not in x86 land where Port IO is built-in
to the CPU.
again sadly you're wrong.
As someone gently pointed out to me, you are in a position to know this,
so I probably am
On 1/13/2008 3:43 PM, Matthew Wilcox wrote:
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
Note: There is not a 100% overlap between "need" and "will not be used in
the patches that use legacy for < 256". In the other patches posted,
extended config space will be used in
On 1/13/2008 1:41 PM, Arjan van de Ven wrote:
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli <[EMAIL PROTECTED]> wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
2) the pci_enable_ext_config() function and dev->ext_cfg_s
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
> Note: There is not a 100% overlap between "need" and "will not be used in
> the patches that use legacy for < 256". In the other patches posted,
> extended config space will be used in cases where it won't be with my
> patch. (M
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli <[EMAIL PROTECTED]> wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
>
> 2) the pci_enable_ext_config() function and dev->ext_cfg_space field,
> sysfs interface should be removed
On 1/12/2008 12:45 PM, Arjan van de Ven wrote:
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
+ if (reg < 256)
+ return pci_conf1_read(seg,bus,devfn,reg,len,value);
+
btw this is my main objection to your patch; it intertwines the conf1
On Sun, 13 Jan 2008 07:43:11 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Sat, 12 Jan 2008 20:36:59 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >
> >
> > Just about NOBODY has devices that need the extended config space.
> > At all.
>
> The PCI express spe
as a general thing I like where this patch is going
On Sun, 13 Jan 2008 00:24:15 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> +
> +int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int
> devfn,
> + int reg, int len,
> u32 *val) +{
> +
Arjan van de Ven wrote:
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
Just about NOBODY has devices that need the extended config space. At all.
The PCI express spec requires the platform to provide access to this space
for express-compliance. More devices will be
On Sun, Jan 13, 2008 at 12:24:15AM -0700, Matthew Wilcox wrote:
> Here's a patch (on top of Ivan's) to improve things further.
Oops. I forgot to check the ordering of mmconfig vs direct probing, so
that patch would end up just using mmconfig for everything. Not what we
want. Also, there's three
On Sun, Jan 13, 2008 at 06:08:05PM +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2008-01-12 at 17:40 +0300, Ivan Kokshaysky wrote:
> > Actually I'm strongly against Arjan's patch. First, it's based on
> > assumption that the MMCONFIG thing is sort of fundamentally broken
> > on some systems, but n
On 1/13/2008 1:01 AM, Matthew Wilcox wrote:
On Sat, Dec 29, 2007 at 12:12:19AM +0300, Ivan Kokshaysky wrote:
On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
One thing that could be changed in pci_cfg_space_size() is to avoid
making a special case for PCI-X 266MHz/533Mhz (
On Sat, 2008-01-12 at 17:40 +0300, Ivan Kokshaysky wrote:
>
> Actually I'm strongly against Arjan's patch. First, it's based on
> assumption that the MMCONFIG thing is sort of fundamentally broken
> on some systems, but none of the facts we have so far does confirm
> that.
> And second, I really
Matthew Wilcox wrote:
On Sat, Jan 12, 2008 at 08:42:48PM -0800, Arjan van de Ven wrote:
Wanne bet there'll be devices that screw this up? THere's devices that even
screwed
up the 64-256 region after all.
I don't know if they 'screwed it up'. There are devices that misbehave
when registers ar
On Sat, Dec 29, 2007 at 12:12:19AM +0300, Ivan Kokshaysky wrote:
> On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
> > One thing that could be changed in pci_cfg_space_size() is to avoid
> > making a special case for PCI-X 266MHz/533Mhz (assume cfg_size == 256
> > for such devices too,
On Sat, Jan 12, 2008 at 08:42:48PM -0800, Arjan van de Ven wrote:
> Wanne bet there'll be devices that screw this up? THere's devices that even
> screwed
> up the 64-256 region after all.
I don't know if they 'screwed it up'. There are devices that misbehave
when registers are read from pci conf
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Thanks, Arjan.
>
> The problem we have been experiencing has to do with Northbridges,
> not with devices.
correct for now.
HOWEVER, and this is the point Linus has made several times:
Just about NOBODY has devices that n
Linus Torvalds wrote:
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
Did I miss a bug report? The only problems I'm currently aware of are
the ones where using MMCONFIG during BAR probing causes a hard lockup on
some Intel machines, and the ones where we get bad config data on some
AMD machines du
Thanks, Arjan.
The problem we have been experiencing has to do with Northbridges,
not with devices.
As far as the device is concerned, after the Northbridge translates
the config access into PCI bus cycles, the device has no idea what
mechanism drove the Northbridge to the translation.
That is
On Sat, 12 Jan 2008 19:12:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan,
>
> I have not seen your MMCONFIG patch.
>
> Would you mind sending me a copy?
>
sure
On PCs, PCI extended configuration space (4Kb) is riddled with problems
associated with the memory mapped access met
Arjan,
I have not seen your MMCONFIG patch.
Would you mind sending me a copy?
Thanks.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read th
On Sun, 13 Jan 2008 00:49:11 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:
> > btw this is my main objection to your patch; it intertwines the
> > conf1 and mmconfig code even more.
>
> There is nothing wrong with it; please r
On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:
> btw this is my main objection to your patch; it intertwines the conf1
> and mmconfig code even more.
There is nothing wrong with it; please realize that mmconf and conf1 are
just different cpu-side interfaces. Both produce precise
On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote:
> btw this is my main objection to your patch; it intertwines the conf1 and
> mmconfig code even more.
> When (and I'm saying "when" not "if") systems arrive that only have MMCONFIG
> for some of the devices,
> we'll have to detang
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> --- a/arch/x86/pci/mmconfig_32.c
> +++ b/arch/x86/pci/mmconfig_32.c
> @@ -30,10 +30,6 @@ static u32 get_base_addr(unsigned int seg, int
> bus, unsigned devfn) struct acpi_mcfg_allocation *cfg;
> int cfg_num;
>
>
On Sat, Jan 12, 2008 at 07:46:32AM -0800, Arjan van de Ven wrote:
> Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> > Actually I'm strongly against Arjan's patch. First, it's based on
> > assumption that the MMCONFIG thing is sort of fundamentally broken
> > on some systems, but none of the facts we h
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
e.
>
> > Ivan, you posted one a while ago, but never seemed to get any
> > confirmation if it helped or not. Should I use that and drop
> > Arjan's?
>
> Actually I'm strongly against Arjan's patch. First, it's based on
On Fri, Jan 11, 2008 at 04:26:38PM -0800, Greg KH wrote:
> > One typical problem is that on "Intel(r) 3 Series Experss Chipset Family"
> > MMCONFIG probing of the BAR #2 (frame buffer address) of integrated graphics
> > device locks up the machine (depending on BIOS settings, of course).
> > This h
Sorry,
Meant to press reply/all.
Forwarded Message
From: Tony Camuso <[EMAIL PROTECTED]>
To: Greg KH <[EMAIL PROTECTED]>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a
driver opt-in
Date: Fri, 11 Jan 2008 20:58:52 -0500
Greg KH wrote:
> I
On Friday, January 11, 2008 3:58 Ivan Kokshaysky wrote:
> On Fri, Jan 11, 2008 at 02:38:03PM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote:
> > > Hmm. Were all those reports root-caused to just that BAR probing?
> > > If so, we may be in better shap
On Sat, Jan 12, 2008 at 02:58:56AM +0300, Ivan Kokshaysky wrote:
> On Fri, Jan 11, 2008 at 02:38:03PM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote:
> > > Hmm. Were all those reports root-caused to just that BAR probing? If so,
> > > we may be in b
On Fri, Jan 11, 2008 at 02:38:03PM -0700, Matthew Wilcox wrote:
> On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote:
> > Hmm. Were all those reports root-caused to just that BAR probing? If so,
> > we may be in better shape than I worried.
>
> I believe so.
Ditto.
One typical probl
On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 11 Jan 2008, Matthew Wilcox wrote:
> >
> > Did I miss a bug report? The only problems I'm currently aware of are
> > the ones where using MMCONFIG during BAR probing causes a hard lockup on
> > some Intel machines, an
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
>
> Did I miss a bug report? The only problems I'm currently aware of are
> the ones where using MMCONFIG during BAR probing causes a hard lockup on
> some Intel machines, and the ones where we get bad config data on some
> AMD machines due to the conf
On Fri, Jan 11, 2008 at 01:12:12PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 11 Jan 2008, Matthew Wilcox wrote:
> >
> > But they can't. We limit the size they can access to 256 bytes, unless
> > the kernel probed address 256 and it worked.
>
> Umm. Probing address 256 (or *any* address) using
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
>
> But they can't. We limit the size they can access to 256 bytes, unless
> the kernel probed address 256 and it worked.
Umm. Probing address 256 (or *any* address) using MMCONFIG will simply
lock up the machine. HARD.
What's so hard to understand
On Fri, Jan 11, 2008 at 11:54:56AM -0800, Arjan van de Ven wrote:
> On Fri, 11 Jan 2008 11:02:29 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
> > >
> > > This patch also adds a sysfs property for each device into which
> > > ro
On Fri, Jan 11, 2008 at 12:27:06PM -0800, Linus Torvalds wrote:
> On Fri, 11 Jan 2008, Matthew Wilcox wrote:
> >
> > Ivan's patch doesn't start enabling MMCONFIG in more places than we
> > currently do. It makes us use conf1 accesses for all accesses below
> > 256 bytes. That fixes all known pro
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
>
> Ivan's patch doesn't start enabling MMCONFIG in more places than we
> currently do. It makes us use conf1 accesses for all accesses below
> 256 bytes. That fixes all known problems to date.
.. and I agree with that patch. But there will be people
On Fri, Jan 11, 2008 at 11:58:23AM -0800, Linus Torvalds wrote:
> On Fri, 11 Jan 2008, Matthew Wilcox wrote:
> >
> > So your argument is that MMCONFIG sucks, therefore Linux has to have a
> > horrible interface to extended PCI config space?
>
> What's *your* point?
>
> MMCONFIG is known broken.
On Fri, 11 Jan 2008, Matthew Wilcox wrote:
>
> So your argument is that MMCONFIG sucks, therefore Linux has to have a
> horrible interface to extended PCI config space?
What's *your* point?
MMCONFIG is known broken. If we ever start enabling it more (ie start
using it even if it's not reserve
On Fri, 11 Jan 2008 11:02:29 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
> >
> > This patch also adds a sysfs property for each device into which
> > root can write a '1' to enable extended configuration space. The
> > kernel will p
On Fri, Jan 11, 2008 at 11:45:24AM -0800, Greg KH wrote:
> On Fri, Jan 11, 2008 at 11:40:02AM -0800, Arjan van de Ven wrote:
> > Personally I absolutely don't agree with that.
> > Ivan's patch is another attempt to make MMCONFIG work somewhat better,
> > but does not provide the explicit opt-in tha
On Fri, Jan 11, 2008 at 11:40:02AM -0800, Arjan van de Ven wrote:
> On Fri, 11 Jan 2008 12:28:20 -0700
> Matthew Wilcox <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Jan 11, 2008 at 11:02:29AM -0800, Greg KH wrote:
> > > Can you send me a follow-on patch that documents this in
> > > Documentation/ABI p
On Fri, 11 Jan 2008 12:28:20 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 11, 2008 at 11:02:29AM -0800, Greg KH wrote:
> > Can you send me a follow-on patch that documents this in
> > Documentation/ABI please.
>
> Greg, if you integrate Ivan's patch, you don't need Arjan's patch.
On Fri, Jan 11, 2008 at 11:02:29AM -0800, Greg KH wrote:
> Can you send me a follow-on patch that documents this in
> Documentation/ABI please.
Greg, if you integrate Ivan's patch, you don't need Arjan's patch.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we
On Fri, Jan 11, 2008 at 11:09:31AM -0800, Arjan van de Ven wrote:
> On Fri, 11 Jan 2008 11:02:29 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
> > >
> > > This patch also adds a sysfs property for each device into which
> > > ro
On Fri, 11 Jan 2008 11:02:29 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
> >
> > This patch also adds a sysfs property for each device into which
> > root can write a '1' to enable extended configuration space. The
> > kernel will p
On Tue, Dec 25, 2007 at 03:26:05AM -0800, Arjan van de Ven wrote:
>
> This patch also adds a sysfs property for each device into which root can
> write a '1' to enable extended configuration space. The kernel will print
> a notice into dmesg when this happens (including the name of the app) so tha
On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
> The only quirk I see removed is a bitmap with an arbitrary size (that we
> don't really know is sufficient for every system), and that is only
> built using comparison between mmconf and type1 accesses. IMHO, there
> is zero knowledge
On Fri, 2007-12-28 at 14:14 -0500, Loic Prylli wrote:
>
> Not knowing whether there is any chipset with the visibility feature,
> but without the retry capability, and given that CRS is irrelevant for
> most Linux platforms (it only matters just after power-on, long before
> Linux is started in t
On 12/28/2007 1:06 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2007-12-27 at 21:37 -0800, Linus Torvalds wrote:
>
>> On Fri, 28 Dec 2007, Benjamin Herrenschmidt wrote:
>>
>>> I have embedded boards where proper CRS operations is critical since the
>>> kernel brings the PCIe link up itself
On 12/28/2007 11:38 AM, Ivan Kokshaysky wrote:
> On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote:
>
>> it removes code by removing quirks / known not working stuff..
>>
>
>
The only quirk I see removed is a bitmap with an arbitrary size (that we
don't really know i
On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote:
> it removes code by removing quirks / known not working stuff..
This not working stuff gets detected at probe time - see
drivers/pci/probe.c:pci_cfg_space_size().
Ivan.
--
To unsubscribe from this list: send the line "unsubscribe
On Fri, 28 Dec 2007 13:34:51 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 28, 2007 at 01:07:09AM -0500, Daniel Barkalow wrote:
> > So would always using conf1 for the non-extended space (unless the
> > platform only uses mmconfig), or at least for the first 64 bytes.
> > I'd bet
On Fri, Dec 28, 2007 at 01:07:09AM -0500, Daniel Barkalow wrote:
> So would always using conf1 for the non-extended space (unless the
> platform only uses mmconfig), or at least for the first 64 bytes. I'd bet
> all the subtle bugs are in the first few words, anyway. (With blatant bugs
> in the
On Thu, 2007-12-27 at 21:37 -0800, Linus Torvalds wrote:
>
> On Fri, 28 Dec 2007, Benjamin Herrenschmidt wrote:
> >
> > I have embedded boards where proper CRS operations is critical since the
> > kernel brings the PCIe link up itself, and thus is likely to hit devices
> > still in the middle of
1 - 100 of 123 matches
Mail list logo
