I did a little profiling, and it seems that the call that gpu-manager
does to drm to get the connected outputs is quite expensive, and I think
there are better ways to check the connector status.
While certainly relevant to boot time, this is a separate problem (the
original one being caused by an
CPU - no gaming.
~$ uname -a
Linux Hal 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
:~$ lspci -vvv
00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC
Transaction Register (rev 0e)
Subsystem: Acer Incorporated [A
@Jeremy @Bill - what is your system configuration (CPU/GPU)? Can you
attach the output of lspci -vvv and your /var/log/gpu-manager.log
please?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Tit
I installed 16.04 and am now getting:
$ systemd-analyze
Startup finished in 7.329s (firmware) + 9.417s (loader) + 4.224s (kernel) +
15.292s (userspace) = 36.264s
$ systemd-analyze blame
7.911s dev-sda6.device
6.276s ufw.service
5.863s systemd-journald.service
This seems to still be present in 16.04. I'm experiencing very slow boot
because of gpu-manager - from systemd-analyze:
gpu-manager.service (50.583s)
Any thoughts?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpa
** Changed in: ubuntu-drivers-common (Ubuntu Trusty)
Assignee: (unassigned) => Alberto Milone (albertomilone)
** Changed in: ubuntu-drivers-common (Ubuntu Wily)
Assignee: (unassigned) => Alberto Milone (albertomilone)
** Changed in: ubuntu-drivers-common (Ubuntu Trusty)
Importance: U
** Also affects: ubuntu-drivers-common (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: ubuntu-drivers-common (Ubuntu Wily)
Importance: Undecided
Status: New
** Changed in: ubuntu-drivers-common (Ubuntu Trusty)
Status: New => Triaged
** Changed in: ub
Related is bug 1565436.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Title:
gpu-manager causing long startup delays
To manage notifications about this bug go to:
https://bugs.launchpad.net
No prob. I will be going 16.04 LTS anyway.
Bill
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Title:
gpu-manager causing long startup delays
To manage notifications about this bug go to:
h
@William
Nope, the fix never made it back to Wily (and I'm not sure we're going to push
for it to go there). It was a relatively big change. It will be in 16.04
though.. Sorry!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
Is the fix available for Ubuntu 15.10? My bootup takes about 1 min from grub
to when my desktop appears. Gpu-manager.service consumes about 18 seconds
(from systemd-analyze). Based on the output of systemd-analyze plot, it looks
like gpu-manager is on the critical path, altho it isn't listed
This bug was fixed in the package ubuntu-drivers-common - 1:0.4.14
---
ubuntu-drivers-common (1:0.4.14) xenial; urgency=medium
* gpu-manager.{c|py}:
- Rely on udev for card detection. This helps detecting if a module
was unloaded or if a card was disabled on a hybrid syste
** Changed in: ubuntu-drivers-common (Ubuntu)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Title:
gpu-manager causing long startup delays
To manage no
On 29-10-15 07:52:37, Martin Pitt wrote:
> The PCI device will exist whether or not the module was loaded; so you
> can just iterate over /sys/bus/pci/devices/* (* expands to the PCI bus
> IDs) and check the attributes in each directory; e. g. you probably want
> to pick out the ones with class ==
The PCI device will exist whether or not the module was loaded; so you
can just iterate over /sys/bus/pci/devices/* (* expands to the PCI bus
IDs) and check the attributes in each directory; e. g. you probably want
to pick out the ones with class == 0x03 (graphics card), and perhaps
vendor == 1
On 28-10-15 13:56:42, Martin Pitt wrote:
> > The module can be loaded on boot and then it can (automatically) be
> unloaded (at some point) if the GPU is disabled in a hybrid system.
>
> Then I suggest to install an udev rule like
>
> ACTION=="remove", SUBSYSTEM=="module", DEVPATH=="*/nvidia",
>
> The module can be loaded on boot and then it can (automatically) be
unloaded (at some point) if the GPU is disabled in a hybrid system.
Then I suggest to install an udev rule like
ACTION=="remove", SUBSYSTEM=="module", DEVPATH=="*/nvidia",
RUN+="/bin/touch /run/nvidia_unloaded"
(this assume
On 28-10-15 06:31:17, Martin Pitt wrote:
> So, let's try this again: What is this grepping of syslogs trying to do?
> Can we replace this with checking for presence/absence of
> /sys/module/?
>
The module can be loaded on boot and then it can (automatically) be
unloaded (at some point) if the GPU
Another thing: grepping /var/log/syslog does not tell you much because
that can span multiple boots. If you ask journalctl anything in this
context, you should call it with "-b" so that it only shows the current
boot, not all boots (if you enabled persistent journal). But still, this
is very expens
-snprintf(command, sizeof(command), "grep -q \"%s: module\"
/var/log/syslog",
> +snprintf(command, sizeof(command), "journalctl -p 4 -k -o cat
> --no-pager | grep -q \"%s: module\"",
Sorry to be blunt here, but this makes me weep, and this kind of code is
absolutely wrong. What o
Sorry, I apologize for the tone, that wasn't appropriate.
So, let's try this again: What is this grepping of syslogs trying to do?
Can we replace this with checking for presence/absence of
/sys/module/?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subsc
Also, please keep in mind that there is no journalctl in 14.04. It's
probably worth adding a check for it in the code.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Title:
gpu-manager causin
On 27-10-15 15:19:39, Bryan Quigley wrote:
> I tried to moving some of the syslogs to journalctl again.. much better
> results. - http://pastebin.ubuntu.com/12980242/
>
> Should I just propose merges to the wily branch or is there an upstream
> for this project?
>
Please use our git branch:
https:
I tried to moving some of the syslogs to journalctl again.. much better
results. - http://pastebin.ubuntu.com/12980242/
Should I just propose merges to the wily branch or is there an upstream
for this project?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
I'm reopening the bug report, as more can definitely be done to solve
the problem.
** Changed in: ubuntu-drivers-common (Ubuntu)
Status: Fix Released => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launc
On 20-10-15 15:01:27, Bryan Quigley wrote:
> Find seems to be the other big time culprit:
> - "find /lib/modules/$(uname -r) -name '%s*.ko' -print",
> + "find /lib/modules/$(uname -r)/updates/dkms -name '%s*.ko'
> -print",
>
> Do we always know that the modules will be unde
Unfortunately on rotational HDD this may have made things worse...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Title:
gpu-manager causing long startup delays
To manage notifications about
This bug was fixed in the package ubuntu-drivers-common - 1:0.4.11
---
ubuntu-drivers-common (1:0.4.11) wily; urgency=medium
* gpu-manager.c:
- Rely on /var/log/syslog to get information about unloaded modules.
This should minimise the current slowdown on boot (LP: #130706
Awesome, the simple change dmesg | grep, to grep syslog saves me about 1
second in gpu-manager, and possibly 2 in total boot time (from 7 seconds
to 5). If the changes are proportional for a rotational HDD this will
be a major speed improvement there..
I was thinking about using the journalctl i
** Branch linked: lp:ubuntu/wily-proposed/ubuntu-drivers-common
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Title:
gpu-manager causing long startup delays
To manage notifications about th
** Changed in: ubuntu-drivers-common (Ubuntu)
Status: Triaged => In Progress
** Changed in: ubuntu-drivers-common (Ubuntu)
Importance: Medium => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net
** Changed in: ubuntu-drivers-common (Ubuntu)
Assignee: (unassigned) => Alberto Milone (albertomilone)
** Changed in: ubuntu-drivers-common (Ubuntu)
Importance: Undecided => Medium
** Changed in: ubuntu-drivers-common (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug
This looks like it might be caused by the 2 calls to dmesg.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Title:
gpu-manager causing long startup delays
To manage notifications about this b
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: ubuntu-drivers-common (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/130706
** Summary changed:
- Ubuntu 14.04 takes long start up.
+ gpu-manager causing long startup delays
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307069
Title:
gpu-manager causing long startup delay
35 matches
Mail list logo
