AMD states the following
"Some PCI cards generate peer-to-peer posted-write traffic targetting
the AGP bridge (from the PCI bus, through the graphics tunnel to the AGP
bus). The combination of such cards and some AGP cards can generate
traffic patters that result in a system deadlock."
As AMD don't say *which* video cards we need to flag this up to the
graphics capture devices that may be affected by this errata so that
they fall back to slower/safer methods.
This only affects AGP although the rarity of PCI video cards on an AMD64
box means that the quick "treat like PCIPCI_FAIL" approach will be fine
for a starter in the capture card drivers.
Signed-off-by: Alan Cox <[email protected]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/media/video/bt8xx/bttv-cards.c linux-2.6.18-rc6-mm1/drivers/media/video/bt8xx/bttv-cards.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/media/video/bt8xx/bttv-cards.c 2006-09-11 11:02:17.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/media/video/bt8xx/bttv-cards.c 2006-09-11 17:20:16.000000000 +0100
@@ -4993,6 +4993,8 @@
if (pci_pci_problems & PCIPCI_FAIL)
pcipci_fail = 1;
+ if (pci_pci_problems & PCIAGP_FAIL)
+ pcipci_fail = 1; /* should check if target is AGP */
if (pci_pci_problems & (PCIPCI_TRITON|PCIPCI_NATOMA|PCIPCI_VIAETBF))
triton1 = 1;
if (pci_pci_problems & PCIPCI_VSFX)
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/media/video/saa7134/saa7134-core.c linux-2.6.18-rc6-mm1/drivers/media/video/saa7134/saa7134-core.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/media/video/saa7134/saa7134-core.c 2006-09-11 11:02:17.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/media/video/saa7134/saa7134-core.c 2006-09-11 17:20:16.000000000 +0100
@@ -843,7 +843,7 @@
latency = 0x0A;
}
#endif
- if (pci_pci_problems & PCIPCI_FAIL) {
+ if (pci_pci_problems & (PCIPCI_FAIL|PCIAGP_FAIL)) {
printk(KERN_INFO "%s: quirk: this driver and your "
"chipset may not work together"
" in overlay mode.\n",dev->name);
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/media/video/zoran_card.c linux-2.6.18-rc6-mm1/drivers/media/video/zoran_card.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/media/video/zoran_card.c 2006-09-11 17:00:12.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/media/video/zoran_card.c 2006-09-11 17:20:16.000000000 +0100
@@ -1620,7 +1620,7 @@
dprintk(5, KERN_DEBUG "Jotti is een held!\n");
/* some mainboards might not do PCI-PCI data transfer well */
- if (pci_pci_problems & PCIPCI_FAIL) {
+ if (pci_pci_problems & (PCIPCI_FAIL|PCIAGP_FAIL)) {
dprintk(1,
KERN_WARNING
"%s: chipset may not support reliable PCI-PCI DMA\n",
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/drivers/pci/quirks.c linux-2.6.18-rc6-mm1/drivers/pci/quirks.c
--- linux.vanilla-2.6.18-rc6-mm1/drivers/pci/quirks.c 2006-09-11 17:00:17.000000000 +0100
+++ linux-2.6.18-rc6-mm1/drivers/pci/quirks.c 2006-09-11 17:20:16.000000000 +0100
@@ -93,8 +93,21 @@
pci_pci_problems |= PCIPCI_FAIL;
}
}
+
+static void __devinit quirk_nopciamd(struct pci_dev *dev)
+{
+ u8 rev;
+ pci_read_config_byte(dev, 0x08, &rev);
+ if (rev == 0x13) {
+ /* Errata 24 */
+ printk(KERN_INFO "Disabling direct PCI/AGP transfers.\n");
+ pci_pci_problems |= PCIAGP_FAIL;
+ }
+}
+
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_5597, quirk_nopcipci );
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_496, quirk_nopcipci );
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8151_0, quirk_nopciamd );
/*
* Triton requires workarounds to be used by the drivers
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.18-rc6-mm1/include/linux/pci.h linux-2.6.18-rc6-mm1/include/linux/pci.h
--- linux.vanilla-2.6.18-rc6-mm1/include/linux/pci.h 2006-09-11 17:00:24.000000000 +0100
+++ linux-2.6.18-rc6-mm1/include/linux/pci.h 2006-09-11 17:21:16.000000000 +0100
@@ -875,12 +875,13 @@
void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
extern int pci_pci_problems;
-#define PCIPCI_FAIL 1
+#define PCIPCI_FAIL 1 /* No PCI PCI DMA */
#define PCIPCI_TRITON 2
#define PCIPCI_NATOMA 4
#define PCIPCI_VIAETBF 8
#define PCIPCI_VSFX 16
#define PCIPCI_ALIMAGIK 32
+#define PCIAGP_FAIL 64 /* No PCI to AGP DMA */
#endif /* __KERNEL__ */
#endif /* LINUX_PCI_H */
On Tue, Sep 12, 2006 at 05:29:00PM +0100, Alan Cox wrote:
> + printk(KERN_INFO "Disabling direct PCI/AGP transfers.\n");
Can we add the reason here too? I get quite a lot of bizarre emails already
because someone read "AGP" somewhere so it's obviously my fault..
Something along the lines of
"CPU errata detected: Disabling direct PCI/AGP transfers.\n"
perhaps ?
Dave
Ar Maw, 2006-09-12 am 12:29 -0400, ysgrifennodd Dave Jones:
> On Tue, Sep 12, 2006 at 05:29:00PM +0100, Alan Cox wrote:
> > + printk(KERN_INFO "Disabling direct PCI/AGP transfers.\n");
>
> Can we add the reason here too? I get quite a lot of bizarre emails already
> because someone read "AGP" somewhere so it's obviously my fault..
>
> Something along the lines of
> "CPU errata detected: Disabling direct PCI/AGP transfers.\n"
Chipset errata in this case but yes sure. I'll send an update to the
change if its accepted/merged and nothing else needs fixing on it.
I'm sure it is your fault really though 8)
Alan
On Tuesday 12 September 2006 18:29, Alan Cox wrote:
> AMD states the following
>
> "Some PCI cards generate peer-to-peer posted-write traffic targetting
> the AGP bridge (from the PCI bus, through the graphics tunnel to the AGP
> bus). The combination of such cards and some AGP cards can generate
> traffic patters that result in a system deadlock."
Hmm, you add all that code just to trigger printks? Looks like overkill
to me.
-Andi
Ar Maw, 2006-09-12 am 17:10 +0200, ysgrifennodd Andi Kleen:
> On Tuesday 12 September 2006 18:29, Alan Cox wrote:
> > AMD states the following
> >
> > "Some PCI cards generate peer-to-peer posted-write traffic targetting
> > the AGP bridge (from the PCI bus, through the graphics tunnel to the AGP
> > bus). The combination of such cards and some AGP cards can generate
> > traffic patters that result in a system deadlock."
>
> Hmm, you add all that code just to trigger printks? Looks like overkill
> to me.
Firstly it's important users get the correct messages about hardware
problems and don't just assume Linux sucks. Secondly at least some of
the capture drivers do the right thing and fall back to other methods.
Those that don't I intend to take up further because the default
behaviour should be the safe behaviour.
And "all that code" is a single quirk (which I think can be __init as
you can't get a hotplug bridge) and updated logic checks which my gcc
generates the same amount of code for as it did previously.
All what code ?
Alan
On Tuesday 12 September 2006 19:13, Alan Cox wrote:
> Ar Maw, 2006-09-12 am 17:10 +0200, ysgrifennodd Andi Kleen:
> > On Tuesday 12 September 2006 18:29, Alan Cox wrote:
> > > AMD states the following
> > >
> > > "Some PCI cards generate peer-to-peer posted-write traffic targetting
> > > the AGP bridge (from the PCI bus, through the graphics tunnel to the
> > > AGP bus). The combination of such cards and some AGP cards can generate
> > > traffic patters that result in a system deadlock."
> >
> > Hmm, you add all that code just to trigger printks? Looks like overkill
> > to me.
>
> Firstly it's important users get the correct messages about hardware
> problems and don't just assume Linux sucks.
If the system really locks up afterwards they will likely never see it though?
I just don't think the printk will that useful and if it locks up people will
blame Linux anyways even with printk.
> And "all that code" is a single quirk (which I think can be __init as
> you can't get a hotplug bridge) and updated logic checks which my gcc
> generates the same amount of code for as it did previously.
>
> All what code ?
Well it was a large change.
-Andi
Ar Maw, 2006-09-12 am 17:29 +0200, ysgrifennodd Andi Kleen:
> If the system really locks up afterwards they will likely never see it though?
They'll see it at boot.
> I just don't think the printk will that useful and if it locks up people will
> blame Linux anyways even with printk.
Which is why I also intend to make sure the drivers aren't defaulting to
ignore but all do it properly and require a force flag. PCIPCI_FAIL
means it doesn't work. No driver should be ignoring that flag.
>
> > And "all that code" is a single quirk (which I think can be __init as
> > you can't get a hotplug bridge) and updated logic checks which my gcc
> > generates the same amount of code for as it did previously.
> >
> > All what code ?
>
> Well it was a large change.
You must use a bigger font than I do ;)
Alan
On Tue, 2006-09-12 at 12:29 -0400, Dave Jones wrote:
> On Tue, Sep 12, 2006 at 05:29:00PM +0100, Alan Cox wrote:
> > + printk(KERN_INFO "Disabling direct PCI/AGP transfers.\n");
>
> Can we add the reason here too? I get quite a lot of bizarre emails already
> because someone read "AGP" somewhere so it's obviously my fault..
>
> Something along the lines of
> "CPU errata detected: Disabling direct PCI/AGP transfers.\n"
Especially when it's user-visible, please make sure you spell 'erratum'
correctly.
--
dwmw2
On Tuesday 12 September 2006 20:45, Alan Cox wrote:
> Ar Maw, 2006-09-12 am 17:29 +0200, ysgrifennodd Andi Kleen:
> > If the system really locks up afterwards they will likely never see it
> > though?
>
> They'll see it at boot.
>
> > I just don't think the printk will that useful and if it locks up people
> > will blame Linux anyways even with printk.
>
> Which is why I also intend to make sure the drivers aren't defaulting to
> ignore but all do it properly and require a force flag. PCIPCI_FAIL
> means it doesn't work. No driver should be ignoring that flag.
Ok that would be more reasonable. Just the printk alone seems to be fairly
pointless to me.
-Andi