| View previous topic :: View next topic |
| Author |
Message |
jhon987
Guru
Joined: 18 Nov 2013
Posts: 302
|
 Posted: Thu Mar 27, 2014 10:26 pm Post subject: Boot delays |
 |
|
Hi, am not sure whether this is the right place but I was just looking at my /var/log/Xorg.0.log file and noticed there are 2 main delay points in it:
[ 20.357] (**) Microsoft Microsoft Basic Optical Mouse v2.0 : (accel) acceleration threshold: 4
[ 20.357] (II) config/udev: Adding input device Microsoft Microsoft Basic Optical Mouse v2.0 (/dev/input/mouse0)
[ 20.357] (II) No input driver specified, ignoring this device.
[ 20.357] (II) This device may have been added with another device file.
[ 28.156] (II) NVIDIA(GPU-0): Display (LG Electronics W2486 (DFP-0)) does not support NVIDIA
[ 28.156] (II) NVIDIA(GPU-0): 3D Vision stereo.
[ 31.889] (II) NVIDIA(GPU-0): Display (LG Electronics W2486 (DFP-0)) does not support NVIDIA
[ 41.690] (II) NVIDIA(GPU-0): Display (LG Electronics W2486 (DFP-0)) does not support NVIDIA
[ 41.690] (II) NVIDIA(GPU-0): 3D Vision stereo.
[ 42.457] (II) NVIDIA(GPU-0): Display (LG Electronics W2486 (DFP-0)) does not support NVIDIA
[ 42.457] (II) NVIDIA(GPU-0): 3D Vision stereo.
I was wondering, is there something I can do to about it? does anyone knows?
thanks... |
|
| Back to top |
|
 |
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Fri Mar 28, 2014 10:15 am Post subject: |
|
|
Given one of those doesn't end in 3D Vision stereo, I am under the impression that you have cut parts away from the log; based on that, I think X.org is proceeding just fine and you perceive that these errors might be the cause. However, this is just a notice that 3D Vision stereo is not supported; it seems as if tries to initialize this a few times, this might be at moments that the resolution changes and/or you switch between graphical contexts (eg. from TTY to DM, from DM to DE, from DM to TTY ...).
For a more thorough inspection I suggest you to look at the output of `dmesg`, as well as /var/log/messages (or `journalctl -rb` on systemd), as well as consider to run profiling tools like bootchart to get your boot plotted. The former relies more on trusting the output, as well as noticing the delay in it; whereas the latter relies more on being able to see what stalls it, it can for instance point out one or another service that is delaying or gets delayed. |
|
| Back to top |
|
|
jhon987
Guru
Joined: 18 Nov 2013
Posts: 302
|
| Posted: Fri Mar 28, 2014 2:45 pm Post subject: |
|
|
| TomWij wrote: | Given one of those doesn't end in 3D Vision stereo, I am under the impression that you have cut parts away from the log; based on that, I think X.org is proceeding just fine and you perceive that these errors might be the cause. However, this is just a notice that 3D Vision stereo is not supported; it seems as if tries to initialize this a few times, this might be at moments that the resolution changes and/or you switch between graphical contexts (eg. from TTY to DM, from DM to DE, from DM to TTY ...).
For a more thorough inspection I suggest you to look at the output of `dmesg`, as well as /var/log/messages (or `journalctl -rb` on systemd), as well as consider to run profiling tools like bootchart to get your boot plotted. The former relies more on trusting the output, as well as noticing the delay in it; whereas the latter relies more on being able to see what stalls it, it can for instance point out one or another service that is delaying or gets delayed. |
Hi, first of all - thanks for your help, I appreciate it very much. second, when you say I've "cut parts away from the log" if you mean that there's a line space between the two bold parts, then that's for separating what I think is the places of delays. The separation itself relies upon the biggest time lapses inside the log, i.e. the first time gap is from 20.357 seconds to 28.156 sec, and the second one is from 28.156 to 41.690, which is what I refer to as the "2 main delay points". (to clarify, I didn't cut any line in between, just created a space for emphasizing purposes)
anyways, what I was thinking is that perhaps those big gaps are caused by a missing driver for the Microsoft Basic Optical Mouse v2.0 and the second delay is due to non supported 3D Vision stereo (as you said)
So actually, what I was hoping is that maybe you or someone else who reads this thread could point me to where I can get the missing drivers or maybe a way to stop the boot process from looking for them instead...
Now by what you're saying I understand that these are probably not the real main causes for my slow boot and the answer might lie inside a 'dmesg' report? if so then maybe you can advise me what I should do given the following dmesg excerpt:
| Code: | [ 6.722241] Adding 1022972k swap on /dev/sda4. Priority:-1 extents:1 across:1022972k
[ 7.814250] systemd-journald[117]: Received request to flush runtime journal from PID 1
[ 21.491891] r8169 0000:07:00.0 enp7s0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-2)
[ 21.502059] r8169 0000:07:00.0 enp7s0: link down
[ 21.502170] r8169 0000:07:00.0 enp7s0: link down
[ 21.502281] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready
[ 22.352973] nvidia 0000:01:00.0: irq 66 for MSI/MSI-X
[ 23.086223] usb 2-1.6: link qh8-0601/ffff880214a43200 start 3 [1/2 us]
[ 23.113158] r8169 0000:07:00.0 enp7s0: link up
[ 23.113166] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
[ 70.522931] gnome-keyring-d (452) used greatest stack depth: 4216 bytes left |
see, there are 2 long jumps between 7.814 to 21.491 and another at 23.113 to 70.522, about the first one I think know what to do (https://forums.gentoo.org/viewtopic-t-899002-postdays-0-postorder-asc-start-25.html)
about the second one, perhaps you know? (I'll investigate more in the meanwhile...) |
|
| Back to top |
|
|
jhon987
Guru
Joined: 18 Nov 2013
Posts: 302
|
| Posted: Fri Mar 28, 2014 9:01 pm Post subject: |
|
|
So, I've emerged sys-kernel/linux-firmware rebuilt my kernel using /lib/firmware/rtl_nic/rtl8168e-3.fw as a CONFIG_EXTRA_FIRMWARE but this didn't changed boot timing much, then I changed /var/log/journal to /var/log/journal.org as I suggested in another thread [I didn't do it till now because I was (and still am) afraid it's an "ugly" workaround..??] and now dmesg looks like this:
| Code: | [ 6.850416] nvidia-smi (190) used greatest stack depth: 4376 bytes left
[ 7.629283] systemd-journald[117]: Received request to flush runtime journal from PID 1
[ 8.108298] Adding 1022972k swap on /dev/sda4. Priority:-1 extents:1 across:1022972k
[ 11.860322] r8169 0000:07:00.0 enp7s0: link down
[ 11.860434] r8169 0000:07:00.0 enp7s0: link down
[ 11.860552] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready
[ 12.571936] nvidia 0000:01:00.0: irq 66 for MSI/MSI-X
[ 13.270923] usb 2-1.6: link qh8-0601/ffff88021116af80 start 3 [1/2 us]
[ 13.576756] r8169 0000:07:00.0 enp7s0: link up
[ 13.576766] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
[ 45.162798] pool (643) used greatest stack depth: 4360 bytes left |
now, to figure out what are these ..."used greatest stack depth:"... suppose to be??? |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sat Mar 29, 2014 2:38 pm Post subject: |
|
|
CONFIG_DEBUG_STACK_USAGE in the kernel hacking menu enables a debug check that *warns* about greater usage of the stack; however, with 4K stack left, there's no need to worry about that at all. Fixing up the firmware seems to have cut 10 seconds in your boot time; as the middle messages are around 11 seconds instead of 21 seconds. The missing drivers don't seem like a problem to me; and if they are, you could try to manually set up a /etc/X11/Xorg.conf such that it doesn't check for it. The 3D Vision stereo messages are there for me too; so, I can confirm those aren't the problem.
Do you have a /var/log/messages (or on systemd, run `journalctl -rb`)? As that might still contain more details; if not, setting up bootchart to chart your boot can help pinpoint the cause. |
|
| Back to top |
|
|
jhon987
Guru
Joined: 18 Nov 2013
Posts: 302
|
| Posted: Sat Mar 29, 2014 5:08 pm Post subject: |
|
|
| TomWij wrote: | CONFIG_DEBUG_STACK_USAGE in the kernel hacking menu enables a debug check that *warns* about greater usage of the stack; however, with 4K stack left, there's no need to worry about that at all. Fixing up the firmware seems to have cut 10 seconds in your boot time; as the middle messages are around 11 seconds instead of 21 seconds. The missing drivers don't seem like a problem to me; and if they are, you could try to manually set up a /etc/X11/Xorg.conf such that it doesn't check for it. The 3D Vision stereo messages are there for me too; so, I can confirm those aren't the problem.
Do you have a /var/log/messages (or on systemd, run `journalctl -rb`)? As that might still contain more details; if not, setting up bootchart to chart your boot can help pinpoint the cause. |
Thanks again for your help and of course, for the info too, I'm using systemd, so journalctl -rb it is. Just a small correction: fixing up the firmware didn't cut off 10 secs of my boot, i.e. it was still going from 7 to 21 even after I fixed it and the "unable to load firmware patch.." line wasn't there anymore. So what I did then was to rename /var/log/journal to journal.org and that's what really cut the 10 seconds off. regarding bootchart, it seems that app-benchmarks/bootchart2 is currently masked so I think I'll pass it for now (since I don't want to mix non-stable packages unless I feel I really have to). after booting my PC a few times already since my last reply I feel that booting is back to its normal speed, although logging in to Gnome is still slower than what I'd expect it to be, but that's a different matter I'll attend to later... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
