View previous topic :: View next topic |
Author |
Message |
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Tue Jun 20, 2017 10:26 pm Post subject: Boot process gets stuck for ~3 min |
|
|
Hi everybody! I have a problem with my boot process - it stops on this line:
Code: | clocksource: Switched to clocksource tsc |
Here's the whole output of dmesg:
http://sprunge.us/OUOG
and here's my .config:
http://sprunge.us/XUDK
This started occurring after I uninstalled my nvidia proprietary drivers after getting enough of their s**t.
I removed them using `emerge -C`, recompiled my kernel with anything nvidia-related disabled (except for nouveau, of course), and re-emerged @world with `nouveau` in my make.conf in place of nvidia.
Where can I even start looking for the solution? $search_engine_of_choice returns nothing useful... |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Tue Jun 20, 2017 10:43 pm Post subject: |
|
|
Quote: | Code: | [ 0.727207] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored |
|
It's not usually a good idea, but you could try booting with acpi_osi=Linux and see if anything changes. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21619
|
Posted: Wed Jun 21, 2017 12:52 am Post subject: |
|
|
Usually, a stall right after the clocksource message is because the kernel pauses 60 seconds waiting for firmware files to be returned by user space. If they are returned, it should continue almost instantly. If a timeout is required, it will take about 60 seconds per missing firmware file. |
|
Back to top |
|
|
theotherjoe Guru
Joined: 22 Nov 2003 Posts: 393
|
|
Back to top |
|
|
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Wed Jun 21, 2017 9:19 pm Post subject: |
|
|
Ant P. wrote: | Quote: | Code: | [ 0.727207] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored |
|
It's not usually a good idea, but you could try booting with acpi_osi=Linux and see if anything changes. |
Something changed - now it says
Code: | [ 0.725226] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query honored via cmdline |
but for the rest everything stays the same
Hu wrote: | Quote: |
Usually, a stall right after the clocksource message is because the kernel pauses 60 seconds waiting for firmware files to be returned by user space. If they are returned, it should continue almost instantly. If a timeout is required, it will take about 60 seconds per missing firmware file. |
|
My linux-firmware package is at its most recent version, and, according to my make.conf (http://sprunge.us/eNAX) my VIDEO_CARDS has nouveau among the settings, so on that side it should be OK. Here is what eix -e says about it:
Code: | # eix -e linux-firmware
[I] sys-kernel/linux-firmware
Available versions: 20160331 20161205 (~)20170113 20170314 (~)20170519 **99999999 {savedconfig}
Installed versions: 20170519(23:02:01 21/06/17)(-savedconfig)
Homepage: https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git
Description: Linux firmware files
|
|
|
Back to top |
|
|
Josef.95 Advocate
Joined: 03 Sep 2007 Posts: 4553 Location: Germany
|
Posted: Sat Jun 24, 2017 12:04 pm Post subject: |
|
|
Vandr0iy Kernel .config wrote: | Code: | CONFIG_DRM_NOUVEAU=y |
| Try it (for better firmware loading) with a module (not build-in). |
|
Back to top |
|
|
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Tue Jun 27, 2017 1:42 pm Post subject: |
|
|
Josef.95 wrote: | Vandr0iy Kernel .config wrote: | Code: | CONFIG_DRM_NOUVEAU=y |
| Try it (for better firmware loading) with a module (not build-in). |
tried that, same as before.
How am I supposed to proceed when I encounter this kind of issues? |
|
Back to top |
|
|
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Fri Jul 07, 2017 9:36 pm Post subject: |
|
|
Bumpity
anybody? |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54232 Location: 56N 3W
|
Posted: Fri Jul 07, 2017 10:18 pm Post subject: |
|
|
Vandr0iy,
nouveau normally needs firmware, which you are not providing. Code: | CONFIG_EXTRA_FIRMWARE="" | should not be blank.
Firmware not loading usually has a timeout and a message in dmesg.
To solve this, we need to change something and see what happens.
Turn off Code: | CONFIG_VGA_SWITCHEROO=y | Its not needed for your Optimus.
Set CONFIG_DRM_NOUVEAU=y to <M>
CONFIG_DRM_I915=y to <M>
Make the changes with
Rebuild and reinstall your kernel.
After reboot, check the timestamp in Thats the build time of the running kernel.
Code: | emerge linux-firmware | if you don't already have it.
Have you ever used a text editor on the .config file?
That causes obscure hard to diagnose issues. If you have, throw away the .config and start again.
From dmesg, the problem happens before most of the hardware is enumerated.
The above changes will delay the video drivers loading until after root is mounted, so you will be using the efifb console for longer. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Mon Jul 17, 2017 7:21 am Post subject: |
|
|
NeddySeagoon wrote: | Vandr0iy,
nouveau normally needs firmware, which you are not providing. Code: | CONFIG_EXTRA_FIRMWARE="" | should not be blank.
Firmware not loading usually has a timeout and a message in dmesg.
To solve this, we need to change something and see what happens.
Turn off Code: | CONFIG_VGA_SWITCHEROO=y | Its not needed for your Optimus.
Set CONFIG_DRM_NOUVEAU=y to <M>
CONFIG_DRM_I915=y to <M>
Make the changes with
Rebuild and reinstall your kernel.
After reboot, check the timestamp in Thats the build time of the running kernel.
Code: | emerge linux-firmware | if you don't already have it.
Have you ever used a text editor on the .config file?
That causes obscure hard to diagnose issues. If you have, throw away the .config and start again.
From dmesg, the problem happens before most of the hardware is enumerated.
The above changes will delay the video drivers loading until after root is mounted, so you will be using the efifb console for longer. |
OK, so I turned off the SWITCHEROO thingy, and put both the nouveau and I915 DRMs to modules for gentoo-sources-4.12 . Then I rebooted in order to load the new kernel, and reemerged linux-firmware.
This helped a lot, as during the boot my waiting time is now ~30secs instead of ~3mins. Which is not so bad, but still not good as it should be. Maybe there's something else I may be still missing?
My current dmesg: http://sprunge.us/ePaG
My current kernel's config: http://sprunge.us/TVeV |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54232 Location: 56N 3W
|
Posted: Mon Jul 17, 2017 8:10 am Post subject: |
|
|
Vandr0iy,
You have several DEBUG options on. They are intended for kernel maintainers.
Unless you know you need them, turn them all off.
Some do extra tests at initialisation, some generate logspam. Some even interfere with normal kernel operation. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Vandr0iy n00b
Joined: 30 May 2015 Posts: 35
|
Posted: Sun Aug 06, 2017 2:04 pm Post subject: |
|
|
NeddySeagoon wrote: | Vandr0iy,
You have several DEBUG options on. They are intended for kernel maintainers.
Unless you know you need them, turn them all off.
Some do extra tests at initialisation, some generate logspam. Some even interfere with normal kernel operation. |
Thank you a lot for the tip, - that was exactly what caused the issue. The boot delay was solved by turning off quite a lot of options in the kernel hacking settings branch, especially the ones related to debugfs, which I didn't even notice being turned on. Here is my current .config on the gentoo-sources-4.12.4:
Code: | http://sprunge.us/TMSa |
Thanks to everybody for the help! |
|
Back to top |
|
|
|