Phil Endecott wrote: >>> I've found that pciehp is taking a lot of time. It is better removing >>> it before the suspend, and loading it afterwards. It goes from 14.5 >>> sec to 8.5. I have this in /etc/pm/config.d/local: >>> >>> SUSPEND_MODULES="ath-pci pciehp" >> >> Adding SUSPEND_MODULES="pciehp" improves resume time on 901 too. Since >> 901s don't have ath-pci, adding that too won't have any ill effects on >> them. >> >> Any objections against adding a /etc/pm/config.d/eeepc file to >> eeepc-acpi-scripts? > > Well I'm sure the kernel devs would prefer us to work out why it's > slow, rather than "papering over" the problem.... > > Looking at my dmesg output, the messages related to pciehp during boot > and resume come out with delays that are suspiciously close to exactly > 1 second. This makes me think that there's some deliberate delay or > timeout of 1 second in there somewhere. For example, there's a 1 > second timeout in pcie_write_cmd() in > /drivers/pci/hotplug/pciehp_hpc.c. Turning on pciehp_debug would > surely reveal some more details.
The culprits turn out to be two of the three msleep(1000) calls in drivers/pci/hotplug/pciehp_ctrl.c. I've reduced them all to msleep(100) and the system still works, though this might not be an acceptable fix for machines with the more physical type of hotplugging. It's probably safe for a kernel that's only going to run on an Eee. So that's another 3.6 seconds off the boot time.... Also, I've been using Arjan's bootgraph.pl script to look at what takes time while the kernel boots (this is probably only interesting once you have a non-modular or less-modular kernel). So far I've saved another half second by disabling CONFIG_ISAPNP. I'm still confused as to why initialising the speaker takes 2 seconds - maybe that's a measurement problem.... Phil. _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
