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

Hi list,
there was a bug report on ohci1394 which seems to be related to the
platform-specific code in the driver. Additional details were posted on
linux1394-user:
http://thread.gmane.org/gmane.linux.kernel.firewire.user/focus=2120
Subject: "strange interaction: ohci1394 and backlight on iBook"
Any ideas? Thanks,
-- 
Stefan Richter
-=====-=-==- =-== --=-=
http://arcgraph.de/sr/

On Sun, 2006-11-05 at 11:41 +0100, Stefan Richter wrote:

Hi list,
there was a bug report on ohci1394 which seems to be related to the
platform-specific code in the driver. Additional details were posted on
linux1394-user:
http://thread.gmane.org/gmane.linux.kernel.firewire.user/focus=2120
Subject: "strange interaction: ohci1394 and backlight on iBook"
Any ideas? Thanks,

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. 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.

Cheers,
Ben.

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/

I wrote:

Benjamin Herrenschmidt wrote:

quoted

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.

[...]

[...]

Hm. There is the following comment in ohci1394_pci_remove():

	/* On UniNorth, power down the cable and turn off the chip
	 * clock when the module is removed to save power on
	 * laptops. Turning it back ON is done by the arch code when
	 * pci_enable_device() is called */

Is this true or wrong in current kernels?
-- 
Stefan Richter
-=====-=-==- =-== --=-=
http://arcgraph.de/sr/

Hm. There is the following comment in ohci1394_pci_remove():

	/* On UniNorth, power down the cable and turn off the chip
	 * clock when the module is removed to save power on
	 * laptops. Turning it back ON is done by the arch code when
	 * pci_enable_device() is called */

Is this true or wrong in current kernels?

Might have bitrotted.... I'll have a look.

Ben.

On Sun, Nov 05, Stefan Richter wrote:

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

This patch does not help. Doing an ip link set dev eth0 up makes no
difference.

On Mon, 2006-11-06 at 17:58 +0100, Olaf Hering wrote:

On Sun, Nov 05, Stefan Richter wrote:

quoted

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

This patch does not help. Doing an ip link set dev eth0 up makes no
difference.

What about trying to add a delay between the pmac clock code and the
init of the controller ? does that help ?

(You need to have a cable plug and the interface up for the power
management bits not to get in the way btw)

Ben.

On Tue, Nov 07, Benjamin Herrenschmidt wrote:

On Mon, 2006-11-06 at 17:58 +0100, Olaf Hering wrote:

quoted

On Sun, Nov 05, Stefan Richter wrote:

quoted

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

This patch does not help. Doing an ip link set dev eth0 up makes no
difference.

What about trying to add a delay between the pmac clock code and the
init of the controller ? does that help ?

no. and it is the rmmod, not the insmod, that hangs the pismo.
Adding some mdelay to the remove function doesnt help either.

On Tue, 2006-11-07 at 08:08 +0100, Olaf Hering wrote:

On Tue, Nov 07, Benjamin Herrenschmidt wrote:

quoted

On Mon, 2006-11-06 at 17:58 +0100, Olaf Hering wrote:

quoted

On Sun, Nov 05, Stefan Richter wrote:

quoted

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

This patch does not help. Doing an ip link set dev eth0 up makes no
difference.

What about trying to add a delay between the pmac clock code and the
init of the controller ? does that help ?

no. and it is the rmmod, not the insmod, that hangs the pismo.
Adding some mdelay to the remove function doesnt help either.

Tried not calling the pmac feature stuff at all in the rmmod ?

I reckon there might be a problem with the cable power control on some
old models like... the pismo :-)

Ben.

On  7 Nov, Benjamin Herrenschmidt wrote:

On Tue, 2006-11-07 at 08:08 +0100, Olaf Hering wrote:

[...]

quoted

and it is the rmmod, not the insmod, that hangs the pismo.
Adding some mdelay to the remove function doesnt help either.

Tried not calling the pmac feature stuff at all in the rmmod ?

Olaf?

I reckon there might be a problem with the cable power control on some
old models like... the pismo :-)

Is there a way to detect affected machines or at least to blacklist
known broken machines?
-- 
Stefan Richter
-=====-=-==- =-== -=-=-
http://arcgraph.de/sr/

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7431 :
iBook G3 threw a machine check exception and put the display backlight
to full brightness after ohci1394 was unloaded and reloaded.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/ieee1394/ohci1394.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

Index: linux/drivers/ieee1394/ohci1394.c
===================================================================

--- linux.orig/drivers/ieee1394/ohci1394.c	2006-11-08 18:19:56.000000000 +0100
+++ linux/drivers/ieee1394/ohci1394.c	2006-11-10 23:25:04.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 on some machines if ohci1394 was loaded/ 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);

@@ -3503,10 +3515,8 @@ static void ohci1394_pci_remove(struct p
 #endif
 
 #ifdef CONFIG_PPC_PMAC
-	/* On UniNorth, power down the cable and turn off the chip
-	 * clock when the module is removed to save power on
-	 * laptops. Turning it back ON is done by the arch code when
-	 * pci_enable_device() is called */
+	/* On UniNorth, power down the cable and turn off the chip clock
+	 * to save power on laptops */
 	{
 		struct device_node* of_node;
 

Adjust whitespace and line lengths

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/ieee1394/ohci1394.c |   34 ++++++++++++++--------------------
 1 files changed, 14 insertions(+), 20 deletions(-)

Index: linux/drivers/ieee1394/ohci1394.c
===================================================================

--- linux.orig/drivers/ieee1394/ohci1394.c	2006-11-10 23:25:04.000000000 +0100
+++ linux/drivers/ieee1394/ohci1394.c	2006-11-10 23:26:12.000000000 +0100

@@ -3218,12 +3218,11 @@ static int __devinit ohci1394_pci_probe(
 #ifdef CONFIG_PPC_PMAC
 	/* Necessary on some machines if ohci1394 was loaded/ unloaded before */
 	if (machine_is(powermac)) {
-		struct device_node *of_node = pci_device_to_OF_node(dev);
+		struct device_node *ofn = 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);
+		if (ofn)
+			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
 	}
 #endif /* CONFIG_PPC_PMAC */
 

@@ -3518,12 +3517,11 @@ static void ohci1394_pci_remove(struct p
 	/* On UniNorth, power down the cable and turn off the chip clock
 	 * to save power on laptops */
 	{
-		struct device_node* of_node;
+		struct device_node* ofn = pci_device_to_OF_node(ohci->dev);
 
-		of_node = pci_device_to_OF_node(ohci->dev);
-		if (of_node) {
-			pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
-			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, of_node, 0, 0);
+		if (ofn) {
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
 		}
 	}
 #endif /* CONFIG_PPC_PMAC */

@@ -3583,12 +3581,10 @@ static int ohci1394_pci_suspend(struct p
 /* PowerMac suspend code comes last */
 #ifdef CONFIG_PPC_PMAC
 	if (machine_is(powermac)) {
-		struct device_node *of_node;
+		struct device_node *ofn = pci_device_to_OF_node(pdev);
 
-		/* Disable 1394 */
-		of_node = pci_device_to_OF_node (pdev);
-		if (of_node)
-			pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
+		if (ofn)
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
 	}
 #endif /* CONFIG_PPC_PMAC */
 

@@ -3610,12 +3606,10 @@ static int ohci1394_pci_resume(struct pc
 /* PowerMac resume code comes first */
 #ifdef CONFIG_PPC_PMAC
 	if (machine_is(powermac)) {
-		struct device_node *of_node;
+		struct device_node *ofn = pci_device_to_OF_node(pdev);
 
-		/* Re-enable 1394 */
-		of_node = pci_device_to_OF_node (pdev);
-		if (of_node)
-			pmac_call_feature (PMAC_FTR_1394_ENABLE, of_node, 0, 1);
+		if (ofn)
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
 	}
 #endif /* CONFIG_PPC_PMAC */
 

I wrote:

On  7 Nov, Benjamin Herrenschmidt wrote:

quoted

On Tue, 2006-11-07 at 08:08 +0100, Olaf Hering wrote:

[...]

quoted

quoted

and it is the rmmod, not the insmod, that hangs the pismo.
Adding some mdelay to the remove function doesnt help either.

Tried not calling the pmac feature stuff at all in the rmmod ?

Olaf?

quoted

I reckon there might be a problem with the cable power control on some
old models like... the pismo :-)

Is there a way to detect affected machines or at least to blacklist
known broken machines?

Actually, shouldn't ohci1394_pci_remove enlcose the platform code into

	if (machine_is(powermac)) {
		...
	}

like ohci1394_pci_suspend and ohci1394_pci_resume do?
-- 
Stefan Richter
-=====-=-==- =-== -=-==
http://arcgraph.de/sr/

On Sat, 2006-11-11 at 00:07 +0100, Stefan Richter wrote:

I wrote:

quoted

On  7 Nov, Benjamin Herrenschmidt wrote:

quoted

On Tue, 2006-11-07 at 08:08 +0100, Olaf Hering wrote:

[...]

quoted

quoted

and it is the rmmod, not the insmod, that hangs the pismo.
Adding some mdelay to the remove function doesnt help either.

Tried not calling the pmac feature stuff at all in the rmmod ?

Olaf?

quoted

I reckon there might be a problem with the cable power control on some
old models like... the pismo :-)

Is there a way to detect affected machines or at least to blacklist
known broken machines?

Actually, shouldn't ohci1394_pci_remove enlcose the platform code into

	if (machine_is(powermac)) {
		...
	}

like ohci1394_pci_suspend and ohci1394_pci_resume do?

Yes.

Ben.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7431
iBook G3 threw a machine check exception and put the display backlight
to full brightness after ohci1394 was unloaded and reloaded.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Patch update:  There were braces missing.  Thanks to Jens Maurer.

 drivers/ieee1394/ohci1394.c |   19 +++++++++++++++----
 1 files changed, 15 insertions(+), 4 deletions(-)

Index: linux/drivers/ieee1394/ohci1394.c
===================================================================

--- linux.orig/drivers/ieee1394/ohci1394.c	2006-11-08 18:19:56.000000000 +0100
+++ linux/drivers/ieee1394/ohci1394.c	2006-11-11 00:12:31.000000000 +0100

@@ -3215,6 +3215,19 @@ 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 on some machines if ohci1394 was loaded/ 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);

@@ -3503,10 +3516,8 @@ static void ohci1394_pci_remove(struct p
 #endif
 
 #ifdef CONFIG_PPC_PMAC
-	/* On UniNorth, power down the cable and turn off the chip
-	 * clock when the module is removed to save power on
-	 * laptops. Turning it back ON is done by the arch code when
-	 * pci_enable_device() is called */
+	/* On UniNorth, power down the cable and turn off the chip clock
+	 * to save power on laptops */
 	{
 		struct device_node* of_node;
 

Adjust whitespace and line lengths

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/ieee1394/ohci1394.c |   34 ++++++++++++++--------------------
 1 files changed, 14 insertions(+), 20 deletions(-)

Index: linux/drivers/ieee1394/ohci1394.c
===================================================================

--- linux.orig/drivers/ieee1394/ohci1394.c	2006-11-11 00:12:31.000000000 +0100
+++ linux/drivers/ieee1394/ohci1394.c	2006-11-11 00:13:45.000000000 +0100

@@ -3218,12 +3218,11 @@ static int __devinit ohci1394_pci_probe(
 #ifdef CONFIG_PPC_PMAC
 	/* Necessary on some machines if ohci1394 was loaded/ unloaded before */
 	if (machine_is(powermac)) {
-		struct device_node *of_node = pci_device_to_OF_node(dev);
+		struct device_node *ofn = 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);
+		if (ofn) {
+			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
 		}
 	}
 #endif /* CONFIG_PPC_PMAC */

@@ -3519,12 +3518,11 @@ static void ohci1394_pci_remove(struct p
 	/* On UniNorth, power down the cable and turn off the chip clock
 	 * to save power on laptops */
 	{
-		struct device_node* of_node;
+		struct device_node* ofn = pci_device_to_OF_node(ohci->dev);
 
-		of_node = pci_device_to_OF_node(ohci->dev);
-		if (of_node) {
-			pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
-			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, of_node, 0, 0);
+		if (ofn) {
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+			pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
 		}
 	}
 #endif /* CONFIG_PPC_PMAC */

@@ -3584,12 +3582,10 @@ static int ohci1394_pci_suspend(struct p
 /* PowerMac suspend code comes last */
 #ifdef CONFIG_PPC_PMAC
 	if (machine_is(powermac)) {
-		struct device_node *of_node;
+		struct device_node *ofn = pci_device_to_OF_node(pdev);
 
-		/* Disable 1394 */
-		of_node = pci_device_to_OF_node (pdev);
-		if (of_node)
-			pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
+		if (ofn)
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
 	}
 #endif /* CONFIG_PPC_PMAC */
 

@@ -3611,12 +3607,10 @@ static int ohci1394_pci_resume(struct pc
 /* PowerMac resume code comes first */
 #ifdef CONFIG_PPC_PMAC
 	if (machine_is(powermac)) {
-		struct device_node *of_node;
+		struct device_node *ofn = pci_device_to_OF_node(pdev);
 
-		/* Re-enable 1394 */
-		of_node = pci_device_to_OF_node (pdev);
-		if (of_node)
-			pmac_call_feature (PMAC_FTR_1394_ENABLE, of_node, 0, 1);
+		if (ofn)
+			pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
 	}
 #endif /* CONFIG_PPC_PMAC */
 

There has been an if(...) missing, for ages.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/ieee1394/ohci1394.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux/drivers/ieee1394/ohci1394.c
===================================================================

--- linux.orig/drivers/ieee1394/ohci1394.c	2006-11-11 00:13:45.000000000 +0100
+++ linux/drivers/ieee1394/ohci1394.c	2006-11-11 00:16:37.000000000 +0100

@@ -3517,7 +3517,7 @@ static void ohci1394_pci_remove(struct p
 #ifdef CONFIG_PPC_PMAC
 	/* On UniNorth, power down the cable and turn off the chip clock
 	 * to save power on laptops */
-	{
+	if (machine_is(powermac)) {
 		struct device_node* ofn = pci_device_to_OF_node(ohci->dev);
 
 		if (ofn) {

Benjamin Herrenschmidt wrote:

On Sat, 2006-11-11 at 00:07 +0100, Stefan Richter wrote:

quoted

Actually, shouldn't ohci1394_pci_remove enlcose the platform code into

	if (machine_is(powermac)) {

Yes.

And how does this expression evaluate on PowerBook G3 "Pismo"?
-- 
Stefan Richter
-=====-=-==- =-== -=-==
http://arcgraph.de/sr/

On Sat, 2006-11-11 at 00:55 +0100, Stefan Richter wrote:

Benjamin Herrenschmidt wrote:

quoted

On Sat, 2006-11-11 at 00:07 +0100, Stefan Richter wrote:

quoted

Actually, shouldn't ohci1394_pci_remove enlcose the platform code into

	if (machine_is(powermac)) {

quoted

Yes.

And how does this expression evaluate on PowerBook G3 "Pismo"?

This will be true on all powerpc based apple machines, so it will be
true there too.

Ben.

On Fri, Nov 10, Stefan Richter wrote:

On  7 Nov, Benjamin Herrenschmidt wrote:

quoted

On Tue, 2006-11-07 at 08:08 +0100, Olaf Hering wrote:

[...]

quoted

quoted

and it is the rmmod, not the insmod, that hangs the pismo.
Adding some mdelay to the remove function doesnt help either.

Tried not calling the pmac feature stuff at all in the rmmod ?

Olaf?

The pismo usually locks up after the fist rmmod. With a few delays
around the feature calls, a few more modprobe/rmmod cycles are possible.
But it still locks up after a while.

Olaf Hering wrote:

quoted

On  7 Nov, Benjamin Herrenschmidt wrote:

quoted

Tried not calling the pmac feature stuff at all in the rmmod ?

The pismo usually locks up after the fist rmmod. With a few delays
around the feature calls, a few more modprobe/rmmod cycles are possible.
But it still locks up after a while.

But what if you delete the feature calls from ohci1394_pci_remove?
-- 
Stefan Richter
-=====-=-==- =-== -==-=
http://arcgraph.de/sr/

The pismo usually locks up after the fist rmmod. With a few delays
around the feature calls, a few more modprobe/rmmod cycles are possible.
But it still locks up after a while.

What if you just remove all the feature calls ?

Ben.