Bug 1021747
| Summary: | F19/VMware long ACPI delay at early boot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, marcelo.barbosa, michele, michele |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-04 16:08:38 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Harald Reindl
2013-10-22 01:04:27 UTC
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those. Hi Harald,
A) "[ 0.633391] ACPI: No dock devices found" comes from:
acpi_dock_init()
B) "[ 7.255595] ACPI: Enabled 2 GPEs in block 00 to 0F" comes from:
acpi_ev_initialize_gpe_block()
the ACPI scan code looks like the following:
int __init acpi_scan_init(void)
{
int result;
result = bus_register(&acpi_bus_type);
if (result) {
/* We don't want to quit even if we failed to add suspend/resume */
printk(KERN_ERR PREFIX "Could not register bus type\n");
}
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
acpi_platform_init();
acpi_lpss_init();
acpi_cmos_rtc_init();
acpi_container_init();
acpi_memory_hotplug_init();
acpi_dock_init(); <-- A)
mutex_lock(&acpi_scan_lock);
/*
* Enumerate devices in the ACPI namespace.
*/
result = acpi_bus_scan(ACPI_ROOT_OBJECT);
if (result)
goto out;
result = acpi_bus_get_device(ACPI_ROOT_OBJECT, &acpi_root);
if (result)
goto out;
result = acpi_bus_scan_fixed();
if (result) {
acpi_device_unregister(acpi_root);
goto out;
}
acpi_update_all_gpes(); <-- B)
acpi_pci_root_hp_init();
out:
mutex_unlock(&acpi_scan_lock);
return result;
}
You will need to try and activate some ACPI logging and see where it is taking
longer. You can start with booting with:
acpi.debug_layer=0xffffffff acpi.debug_level=0xffffffff
That will likely be too much info but maybe it will reveal something.
You can reduce the output via https://www.kernel.org/doc/Documentation/acpi/debug.txt
It'll require some trial and error I guess
hth,
Michele
a later kernel update has fixed this - looks like a temporary regression fixed with following updates Closing then |