maybe: kexec + e100 + CONFIG_PM != working

[Andy Pfiffer <andyp@osdl.org>]

On Tue, 2003-07-01 at 15:03, Ed L Cashin wrote:
> Ed L Cashin <ecashin@uga.edu> writes:
> 
> ...
> > I haven't tried the experiment you suggested where I disable e100 in
> > the kernel configuration.
> 
> OK, I just tried taking out the intel e100 driver and building in
> Becker's eepro100 driver.  This kernel can do kexec fine.

I just had lunch with someone that knows a lot more about the e100
driver than I do.

I would be curious to know what happens if you disable CONFIG_PM (as
seen in your .config), disable the eepro100 driver, re-enable the e100
driver, and then try kexec again.

The hint I received is that the e100_suspend() routine could call
pci_set_power_state() on the way down during a kexec, and that could
leave the card in a state that is difficult to resurrect when the new
kernel starts initializing devices.

You might also try commenting out the pci_set_power_state() lines in
e100_suspend() and leave CONFIG_PM enabled (untested diff for
illustration):

--- e100_main.c.orig	Wed Jul  2 14:00:59 2003
+++ e100_main.c	Wed Jul  2 14:02:22 2003
@@ -4305,11 +4305,11 @@
 	/* If wol is enabled */
 	if (bdp->wolopts || e100_asf_enabled(bdp)) {
 		pci_enable_wake(pcid, 3, 1);	/* Enable PME for power state D3 */
-		pci_set_power_state(pcid, 3);	/* Set power state to D3.        */
+		/*pci_set_power_state(pcid, 3);*/	/* Set power state to D3.        */
 	} else {
 		/* Disable bus mastering */
 		pci_disable_device(pcid);
-		pci_set_power_state(pcid, state);
+		/*pci_set_power_state(pcid, state);*/
 	}
 	return 0;
 }