On Thu, Sep 27, 2007 at 10:40:33AM +1000, Benjamin Herrenschmidt wrote:
>
> > How is this a change in behavior as far as this device is concerned? If
> > we are doing BAR sizing and moving the base address around, it's going
> > to cause problems if you try to access the device during this time
> How is this a change in behavior as far as this device is concerned? If
> we are doing BAR sizing and moving the base address around, it's going
> to cause problems if you try to access the device during this time
> whether we disable decode or not.
True. The window is smaller tho if the upp
Benjamin Herrenschmidt wrote:
On Mon, 2007-09-17 at 14:22 +0400, Ivan Kokshaysky wrote:
On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote:
Agreed. I have a similar problem on ppc where it's common to have things
like the main PIC on a PCI device. Note that another problem i
On Tuesday, September 18, 2007 2:53 am Ivan Kokshaysky wrote:
> On Mon, Sep 17, 2007 at 09:21:47AM +0800, Shaohua Li wrote:
> > I can confirm this is an add-in graphics card. the bfd is 00:02.0,
> > so it's not behind any AGP/PCI-E bridge.
>
> AFAIKS, 00:02.0 is *integrated* controller. Can you che
On Tue, Sep 18, 2007 at 06:30:23AM +1000, Benjamin Herrenschmidt wrote:
> At this stage (but we are getting a bit OT), ppc has something like 3
> different PCI code implementations :-) I do have some plans to fix that
> by switching everybody to use pci_assign_unassigned_resources() and
> friends b
On Mon, Sep 17, 2007 at 09:21:47AM +0800, Shaohua Li wrote:
> I can confirm this is an add-in graphics card. the bfd is 00:02.0, so
> it's not behind any AGP/PCI-E bridge.
AFAIKS, 00:02.0 is *integrated* controller. Can you check that "graphic
adapter priority" setting in BIOS is "PCI Express" and
On Mon, 2007-09-17 at 14:22 +0400, Ivan Kokshaysky wrote:
> On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote:
> > Agreed. I have a similar problem on ppc where it's common to have things
> > like the main PIC on a PCI device. Note that another problem is (or at
> > least was,
Ivan Kokshaysky wrote:
On Sun, Sep 16, 2007 at 01:52:59PM -0600, Matthew Wilcox wrote:
I don't think it would be that complicated. We could just delay probing
for mmconfig until after the pci bus probes are done. No changes to
other architectures needed.
Indeed. Seems like it's a way to go.
On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote:
> Agreed. I have a similar problem on ppc where it's common to have things
> like the main PIC on a PCI device. Note that another problem is (or at
> least was, i haven't checked recently) the P2P bridge scanning code
> that, i
On Sun, Sep 16, 2007 at 01:52:59PM -0600, Matthew Wilcox wrote:
> I don't think it would be that complicated. We could just delay probing
> for mmconfig until after the pci bus probes are done. No changes to
> other architectures needed.
Indeed. Seems like it's a way to go.
> I'm really disappo
On Sun, Sep 16, 2007 at 11:34:35AM -0600, Robert Hancock wrote:
> > The most interesting fact there is that windows *does not* clear
> > PCI_COMMAND_MEMORY bits during PCI bus enumeration, so BIOS writers
> > have to rely on that. Yet another reason why your patch is unsafe.
>
> Windows 98 doesn't
On Sun, 2007-09-16 at 15:13 +0400, Ivan Kokshaysky wrote:
> On Fri, Sep 14, 2007 at 05:53:58PM -0600, Robert Hancock wrote:
> > In the first one, Linus talks about a USB controller whose SMM code
> > chokes on the BAR being disabled. That explanation seems odd to me. If
> > it chokes on the BAR d
On Sun, 2007-09-16 at 17:37 -0600, Robert Hancock wrote:
> We would already have this problem, though. If it causes problems to
> disable decode on the BAR because we try to access it in interrupt
> context, we would already have problems because we move the thing to
> 0x during probing
Benjamin Herrenschmidt wrote:
On Thu, 2007-09-13 at 21:32 -0600, Robert Hancock wrote:
If we do encounter other devices that choke on having the BAR
disabled
during probing then we can add additional quirk logic, but we haven't
run into anything like that yet.
Well... if the device needs to
On Thu, 2007-09-13 at 21:32 -0600, Robert Hancock wrote:
>
> If we do encounter other devices that choke on having the BAR
> disabled
> during probing then we can add additional quirk logic, but we haven't
> run into anything like that yet.
Well... if the device needs to be accessed to service
On Thu, 2007-09-13 at 15:16 +0400, Ivan Kokshaysky wrote:
> On Thu, Sep 13, 2007 at 02:53:13AM -0700, Greg KH wrote:
> > On Thu, Sep 13, 2007 at 01:55:36AM -0600, Matthew Wilcox wrote:
> > > Unfortunately if this patch does cause any machine to break, these will
> > > be machines that worked fine u
On Sun, Sep 16, 2007 at 03:13:55PM +0400, Ivan Kokshaysky wrote:
> Another possible solution is not to use mmconfig for bar sizing at all,
> if it's *that* broken. It would be more complicated though, since it
> probably requires changes to all architectures.
I don't think it would be that complic
Ivan Kokshaysky wrote:
On Fri, Sep 14, 2007 at 05:53:58PM -0600, Robert Hancock wrote:
In the first one, Linus talks about a USB controller whose SMM code
chokes on the BAR being disabled. That explanation seems odd to me. If
it chokes on the BAR disabled, how doesn't it choke on the BAR being
On Fri, Sep 14, 2007 at 05:53:58PM -0600, Robert Hancock wrote:
> In the first one, Linus talks about a USB controller whose SMM code
> chokes on the BAR being disabled. That explanation seems odd to me. If
> it chokes on the BAR disabled, how doesn't it choke on the BAR being
> moved to a diffe
Yinghai Lu wrote:
On 9/14/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
It's not impossible at all. In fact I'm quite sure (Jesse can confirm)
that in the case of the board he was using, it was an add-in graphics
card where he saw this problem.
The fact is that in the case of MMCONFIG overlap w
On 9/14/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> It's not impossible at all. In fact I'm quite sure (Jesse can confirm)
> that in the case of the board he was using, it was an add-in graphics
> card where he saw this problem.
>
> The fact is that in the case of MMCONFIG overlap with PCI BARs
Ivan Kokshaysky wrote:
On Fri, Sep 14, 2007 at 08:30:59AM -0600, Robert Hancock wrote:
Do you have an example of specific hardware that exhibits this problem?
Well, first two results of google search for "disable bar when sizing":
http://lkml.org/lkml/2002/12/21/95
http://lkml.org/lkml/2002/
On Fri, Sep 14, 2007 at 08:30:59AM -0600, Robert Hancock wrote:
> Do you have an example of specific hardware that exhibits this problem?
Well, first two results of google search for "disable bar when sizing":
http://lkml.org/lkml/2002/12/21/95
http://lkml.org/lkml/2002/12/20/110
> So far after
Ivan Kokshaysky wrote:
On Thu, Sep 13, 2007 at 09:32:42PM -0600, Robert Hancock wrote:
Disabling the BAR decoding does not mean disabling the device (aside
from the one group of host bridge that apparently disables CPU to RAM
access, whose designers were apparently on crack when they read the
On Fri, Sep 14, 2007 at 03:14:01PM +0400, Ivan Kokshaysky wrote:
> whippets doesn't look sane either. ;-)
It's not me, it's a spellchecker :-) I meant "chipsets" of course, sorry.
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Thu, Sep 13, 2007 at 09:32:42PM -0600, Robert Hancock wrote:
> Disabling the BAR decoding does not mean disabling the device (aside
> from the one group of host bridge that apparently disables CPU to RAM
> access, whose designers were apparently on crack when they read the PCI
> spec and whi
Ivan Kokshaysky wrote:
On Thu, Sep 13, 2007 at 02:53:13AM -0700, Greg KH wrote:
On Thu, Sep 13, 2007 at 01:55:36AM -0600, Matthew Wilcox wrote:
Unfortunately if this patch does cause any machine to break, these will
be machines that worked fine up until this point, so that would be a
regression
On Thu, Sep 13, 2007 at 03:16:37PM +0400, Ivan Kokshaysky wrote:
> On Thu, Sep 13, 2007 at 02:53:13AM -0700, Greg KH wrote:
> > On Thu, Sep 13, 2007 at 01:55:36AM -0600, Matthew Wilcox wrote:
> > > Unfortunately if this patch does cause any machine to break, these will
> > > be machines that worked
On Thu, Sep 13, 2007 at 02:53:13AM -0700, Greg KH wrote:
> On Thu, Sep 13, 2007 at 01:55:36AM -0600, Matthew Wilcox wrote:
> > Unfortunately if this patch does cause any machine to break, these will
> > be machines that worked fine up until this point, so that would be a
> > regression, which is wo
On Thu, Sep 13, 2007 at 01:55:36AM -0600, Matthew Wilcox wrote:
> On Thu, Sep 13, 2007 at 03:24:46PM +0800, Shaohua Li wrote:
> > On Thu, 2007-09-13 at 01:31 -0600, Matthew Wilcox wrote:
> > > You missed the part where we have to avoid doing this for host bridges ...
> > >
> > > http://marc.info/?
On Thu, Sep 13, 2007 at 03:24:46PM +0800, Shaohua Li wrote:
> On Thu, 2007-09-13 at 01:31 -0600, Matthew Wilcox wrote:
> > You missed the part where we have to avoid doing this for host bridges ...
> >
> > http://marc.info/?l=linux-kernel&m=118809338631160&w=2
> >
> > (I believe it's now queued i
On Thu, 2007-09-13 at 01:31 -0600, Matthew Wilcox wrote:
> On Thu, Sep 13, 2007 at 02:21:07PM +0800, Shaohua Li wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=8833
> > We write 0x to BARs to detect BAR size, this will change BAR
> > base to 0xfxx depends on BAR size. In the bug,
On Thu, Sep 13, 2007 at 02:21:07PM +0800, Shaohua Li wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8833
> We write 0x to BARs to detect BAR size, this will change BAR
> base to 0xfxx depends on BAR size. In the bug, PCI MCFG base address
> is 0xf400. One PCI device (gfx) has a
http://bugzilla.kernel.org/show_bug.cgi?id=8833
We write 0x to BARs to detect BAR size, this will change BAR
base to 0xfxx depends on BAR size. In the bug, PCI MCFG base address
is 0xf400. One PCI device (gfx) has a 256M BAR, the detection code
will temprarily change it to 0xf00
34 matches
Mail list logo