Messages in this thread Patch in this message | | | Subject | maybe: kexec + e100 + CONFIG_PM != working | From | Andy Pfiffer <> | Date | 02 Jul 2003 14:06:38 -0700 |
| |
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; }
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |