there is a long boot delay on F19 on VMware Workstation with acpi=off boot is hyperfast but the guest will no longer poweroff after shutdown and "clocksource=hpet" not working and the same kernel version on F18 on the same machine has o delay 3.11.6-200.fc19.x86_64: Startup finished in 7.526s (kernel) + 816ms (initrd) + 5.517s (userspace) = 13.859s 3.11.6-100.fc18.x86_64: Startup finished in 559ms (kernel) + 1.051s (initrd) + 5.922s (userspace) = 7.533s __________________________________ [ 0.326419] ACPI: EC: Look up EC in DSDT [ 0.333404] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 0.631291] ACPI: Interpreter enabled [ 0.631587] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130517/hwxface-571) [ 0.632044] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20130517/hwxface-571) [ 0.632460] ACPI: (supports S0 S1 S4 S5) [ 0.632624] ACPI: Using PIC for interrupt routing [ 0.633391] ACPI: No dock devices found. [ 7.255595] ACPI: Enabled 2 GPEs in block 00 to 0F [ 7.255740] ACPI: \_SB_.PCI0: notify handler is installed [ 7.256030] Found 1 acpi root devices [ 7.256271] vgaarb: loaded __________________________________ in the meantime i tried to disable as muc as possible with no success anyhting i can do to help debug this? pnpacpi=off pci=noacpi acpi=noirq audit=0 rd.plymouth=0 plymouth.enable=0 nodmraid raid=noautodetect nomodeset selinux=0 net.ifnames=0 biosdevname=0 elevator=deadline divider=20 clocksource=hpet noswapaccount nousb noisapnp noresume nodomains nobar norom thermal.off=1 consoleblank=0 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 vconsole.font=latarcyrheb-sun16 vconsole.keymap=de-latin1-nodeadkeys locale.LANG=de_DE.UTF-8 LANG=de_DE.UTF-8
*********** 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