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
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
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
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 upper
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
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
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 check
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
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"
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 not
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 but
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,
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
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
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, it
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
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, in a
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 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, i
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
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
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
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
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
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 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
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 up until
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 an
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 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
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
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
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
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
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
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
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
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
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 which
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
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 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 a
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
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 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
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
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
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 ...
> > >
> > >
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=118809338631160=2
> >
> > (I believe it's now queued in
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
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
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
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
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, PCI
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-kernelm=118809338631160w=2
(I believe it's now queued in Greg's
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 ...
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 worse.
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 fine up
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
68 matches
Mail list logo
