12-01-2014
For the record, the upgrade from Centos 6.5 to Centos 7 was performed again and we have been experiencing no higher temperature than 45C, routinely lower than 40C. This is the case for the last two months, so problem seems solved.
6 More Discussions You Might Find Interesting
1. Solaris
Hello,
Can give me some tips to trace the GPU usage on a solaris8 update7 box?
I try to understand why a Cadcam app is so slow on my Solaris box compared to a win$ box. I guess it comes from the poor graphic card I have but i would like to emphasize it.
My bench is 150sec long on a Solaris... (0 Replies)
Discussion started by: solea
0 Replies
2. UNIX for Advanced & Expert Users
Hi ,
i want begin programming using CUDA
which enviroment can i get .I don't have desktop to buy GPU graphics card.
what should to do to get CUDA enviroment.
i'm thinking to buy desktop has this card or laptop (1 Reply)
Discussion started by: Scotch
1 Replies
3. Hardware
Dear all,
I set up a external Gforce GPU using the PE4H (Pcie passive adapter) from HWTOOLS.NET.
I'm able to add and remove the device doing
and
The point is the kernel does not initialized the device correctly.
Here is what dmesg gives after the scan:
lspci -t gives
and lspci... (2 Replies)
Discussion started by: aihake
2 Replies
4. Hardware
I am trying to start troubleshooting an error on a virtual server that uses the ubuntu 14.04 OS. Basically what happens (seeming random) is that the GPU stops processing and terminates. What Imean by seeming random is that for 3 runs there is no error then on run 4 the error appears. It has... (2 Replies)
Discussion started by: cmccabe
2 Replies
5. Hardware
Hi All
I'm find out a way to disable the DGD: AMD Radeon HD 7470M on my Ubutu 16.04.2 LTS because radeon open source module is not capable to support this GPU and consequence the boot is very slow.
I have tried serveral way with pci-stub.ids in the grub menu but not work.
In general how... (11 Replies)
Discussion started by: _Fabio_79
11 Replies
6. Linux
The situation
videocard n°1 Nvidia Ge-force(used on host linux)
videocard n°2 Ati radeon(used on guest windows 7)
host is Slackware 14.2,kernel 4.18.15
I had set vfio to pass a ati card to windows7 guest
Configure /etc/modprobe.d/vfio.conf
options vfio-pci... (1 Reply)
Discussion started by: Linusolaradm1
1 Replies
LEARN ABOUT XFREE86
dh_systemd_start
DH_SYSTEMD_START(1) Debhelper DH_SYSTEMD_START(1)
NAME
dh_systemd_start - start/stop/restart systemd unit files
SYNOPSIS
dh_systemd_start [debhelperoptions] [--restart-after-upgrade] [--no-stop-on-upgrade] [unitfile...]
DESCRIPTION
dh_systemd_start is a debhelper program that is responsible for starting/stopping or restarting systemd unit files in case no corresponding
sysv init script is available.
As with dh_installinit, the unit file is stopped before upgrades and started afterwards (unless --restart-after-upgrade is specified, in
which case it will only be restarted after the upgrade). This logic is not used when there is a corresponding SysV init script because
invoke-rc.d performs the stop/start/restart in that case.
OPTIONS
--restart-after-upgrade
Do not stop the unit file until after the package upgrade has been completed. This is the default behaviour in compat 10.
In earlier compat levels the default was to stop the unit file in the prerm, and start it again in the postinst.
This can be useful for daemons that should not have a possibly long downtime during upgrade. But you should make sure that the daemon
will not get confused by the package being upgraded while it's running before using this option.
--no-restart-after-upgrade
Undo a previous --restart-after-upgrade (or the default of compat 10). If no other options are given, this will cause the service to
be stopped in the prerm script and started again in the postinst script.
-r, --no-stop-on-upgrade, --no-restart-on-upgrade
Do not stop service on upgrade.
--no-start
Do not start the unit file after upgrades and after initial installation (the latter is only relevant for services without a
corresponding init script).
NOTES
Note that this command is not idempotent. dh_prep(1) should be called between invocations of this command (with the same arguments).
Otherwise, it may cause multiple instances of the same text to be added to maintainer scripts.
Note that dh_systemd_start should be run after dh_installinit so that it can detect corresponding SysV init scripts. The default sequence
in dh does the right thing, this note is only relevant when you are calling dh_systemd_start manually.
SEE ALSO
debhelper(7)
AUTHORS
pkg-systemd-maintainers@lists.alioth.debian.org
11.1.6ubuntu2 2018-05-10 DH_SYSTEMD_START(1)