diff mbox

[RFT,3.0] ssb: fix PCI(e) driver regression causing oops on PCI cards

Message ID 1306918871-16965-1-git-send-email-zajec5@gmail.com (mailing list archive)
State Not Applicable
Headers show

Commit Message

Rafał Miłecki June 1, 2011, 9:01 a.m. UTC
We were incorrectly executing PCIe specific workarounds on PCI cards.
This resulted in:
Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]

Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
 drivers/ssb/driver_pcicore.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

Comments

Rafał Miłecki June 1, 2011, 7:14 p.m. UTC | #1
2011/6/1 Rafał Miłecki <zajec5@gmail.com>:
> We were incorrectly executing PCIe specific workarounds on PCI cards.
> This resulted in:
> Machine check in kernel mode.
> Caused by (from SRR1=149030): Transfer error ack signal
> Oops: Machine check, sig: 7 [#1]

John, I've tested this patch myself on my PCI BCM4318, including
checking for 0xFFFFFFFF reads in MMIO dumps.

The patch is correct, please take it for 3.0.
Rafał Miłecki June 2, 2011, 6:13 a.m. UTC | #2
2011/6/1 Rafał Miłecki <zajec5@gmail.com>:
> 2011/6/1 Rafał Miłecki <zajec5@gmail.com>:
>> We were incorrectly executing PCIe specific workarounds on PCI cards.
>> This resulted in:
>> Machine check in kernel mode.
>> Caused by (from SRR1=149030): Transfer error ack signal
>> Oops: Machine check, sig: 7 [#1]
>
> John, I've tested this patch myself on my PCI BCM4318, including
> checking for 0xFFFFFFFF reads in MMIO dumps.
>
> The patch is correct, please take it for 3.0.

John, I'm afraid more and more people get angry at me because of this ;)

Christian Kujau confirmed this problem and fix.
Christian Kujau June 2, 2011, 6:20 a.m. UTC | #3
On Thu, 2 Jun 2011 at 08:13, Rafał Miłecki wrote:
> John, I'm afraid more and more people get angry at me because of this ;)

Erm, I'm not angry at anyone :-) On the contrary, I'm happy about the fix 
so quickly available!

Though I'm a bit afraid of the next git bisect session, as it might not be 
so straightforward than this one...

Thanks to all involved,
Christian.
Rafał Miłecki June 3, 2011, 9:24 p.m. UTC | #4
On Jun 1, 2011 9:14 PM, "Rafał Miłecki" <zajec5@gmail.com> wrote:
>
> 2011/6/1 Rafał Miłecki <zajec5@gmail.com>:
> > We were incorrectly executing PCIe specific workarounds on PCI cards.
> > This resulted in:
> > Machine check in kernel mode.
> > Caused by (from SRR1=149030): Transfer error ack signal
> > Oops: Machine check, sig: 7 [#1]
>
> John, I've tested this patch myself on my PCI BCM4318, including
> checking for 0xFFFFFFFF reads in MMIO dumps.
>
> The patch is correct, please take it for 3.0.

Ping, ping, ping John.
diff mbox

Patch

diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index 82feb34..2a20dab 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -539,10 +539,12 @@  void ssb_pcicore_init(struct ssb_pcicore *pc)
 	if (!pc->hostmode)
 		ssb_pcicore_init_clientmode(pc);
 
-	/* Additional always once-executed workarounds */
-	ssb_pcicore_serdes_workaround(pc);
-	/* TODO: ASPM */
-	/* TODO: Clock Request Update */
+	/* Additional PCIe always once-executed workarounds */
+	if (dev->id.coreid == SSB_DEV_PCIE) {
+		ssb_pcicore_serdes_workaround(pc);
+		/* TODO: ASPM */
+		/* TODO: Clock Request Update */
+	}
 }
 
 static u32 ssb_pcie_read(struct ssb_pcicore *pc, u32 address)