Re: [Fwd: [Bug 7431] New: ohci1394 Oops after a rmmod/modprobe cycle]

Benjamin Herrenschmidt wrote:

The machine check means basically that the chip didn't respond on the
PCI bus. The most probable cause is that something is wrong with the
platform code that switches the chip clock on/off or with the PCI D
state change.

One thing you can check is wether that's always called properly,
especially when starting the chip.

Actually, we have platform code in ohci1394's pci_driver.suspend(),
.resume(), and .remove(), but not in .probe().

.suspend() has:
	pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
.resume() has:
	pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 1);
.remove() has:
	pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
	pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, of_node, 0, 0);

How about this patch:

--- linux.orig/drivers/ieee1394/ohci1394.c	2006-11-02 22:35:16.000000000 +0100
+++ linux/drivers/ieee1394/ohci1394.c	2006-11-05 12:19:52.000000000 +0100

@@ -3215,6 +3215,18 @@ static int __devinit ohci1394_pci_probe(
 	struct ti_ohci *ohci;	/* shortcut to currently handled device */
 	resource_size_t ohci_base;

+#ifdef CONFIG_PPC_PMAC
+	/* Necessary if ohci1394 was loaded and unloaded before */
+	if (machine_is(powermac)) {
+		struct device_node *of_node = pci_device_to_OF_node(dev);
+
+		if (of_node)
+			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, of_node,
+					  0, 1);
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 1);
+	}
+#endif /* CONFIG_PPC_PMAC */
+
         if (pci_enable_device(dev))
 		FAIL(-ENXIO, "Failed to enable OHCI hardware");
         pci_set_master(dev);

(Diff is against linux1394-2.6.git or the patchsets at
http://me.in-berlin.de/~s5r6/linux1394/updates/. But perhaps it applies
to stock ohci1394 of recent kernels too.)

Another possibly might be that the
chip needs some time after the clocks are restored to be back online,
thus you might need a delay after the platform code and/or the PCI D
state change before you start poking at registers.

A couple of thing to make sure of:

 - On init, call platform code first to bring clocks back up, then only
do the PCI D state transition to D0 (maybe with a delay)

 - On rmmod or suspend, call the platform code last, after the D3 state
transition (if any), and make sure the chip's been properly stopped
first.

It might also be useful if there isn't some sort of bad interaction with
sungem which on the same PCI bus and has similar clock control as I've
heard about possible issues on some older chips. Thus, the user could
verify that sungem is allways up and running (link on) during the test
and check if that makes any difference.

Yes, PowerBook G3 Pismo seems affected.
https://bugzilla.novell.com/show_bug.cgi?id=115228

Thanks for the help.
-- 
Stefan Richter
-=====-=-==- =-== --=-=
http://arcgraph.de/sr/