FS#27940 - [nvidia] terminal flashing caused by temperature logging script
Attached to Project:
Arch Linux
Opened by Logan Dam (biltong) - Saturday, 14 January 2012, 19:11 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Saturday, 17 November 2012, 02:57 GMT
Opened by Logan Dam (biltong) - Saturday, 14 January 2012, 19:11 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Saturday, 17 November 2012, 02:57 GMT
|
Details
Description:
I have created a bash script that logs the output of lm-sensors and nvidia-smi to a file every 5 seconds, and have set that to start at boot time via rc.local. I background the script simply by adding & after the script path. The script itself works perfecrtly, but every time the script logs to the file, the terminal switches from the current one (usually the one that's logged in) to what looks to be what Arch outputs when it boots (where it shows the status of daemons as they start etc.), and then back to the original terminal. It all does this very quickly, and it leaves whatever you were typing in the terminal at first to have invisible characters making it difficult to use. So for example if I typed /path/to/application and a flash happened while typing it, it would appear as follows after the flash: /path/ application or similar depending on when the flash occurred. The characters are still there, and pressing enter will run the command correctly, but it makes it difficult to work with as you don't know if you've made a mistake in the command. What I've tried to fix the problem: -Change the way the script logs to file -Change the way the script starts in rc.local (ie. adding > /dev/null, > /dev/null & and all the others) -Use daemon from the AUR to start the script -Delay the script startup until the login prompt has opened None of the above has made any impact on the problem. I discovered this "bug" in making an Arch ISO, designed specifically for folding@home run by Stanford. www.overclock.net/t/1156650/ On that page is an ISO which allows you to install arch and the necessary packages and my script which causes the problem, but it is a 550MB download. What's interesting about this bug though, is that when the GPU application opens and starts running through WINE, the screen flashing goes away, which leads me to believe this is an nvidia issue. The moment the application stops, however, the problem comes back. Killing the script that was started at boot and then running it after logging in also fixes it, which I find particularly strange. Note that there is no X server running, only barebones terminal. Additional info: * package version(s) (I'll only list the ones I think are involved, tell me if you need other packages) bash 4.2.020-1 daemon 0.6.4-1 foldingathome-gpu-nvidia 6.41-1 (AUR) foldingathome-smp 6.34-3 (AUR) glib2 2.30.2-1 glibc 2.14.1-4 initscripts 2011.12.1-1 lib32-cuda-toolkit 3.0-1 (AUR) lib32-gcc-libs 4.6.2-3 lib32-glibc 2.14.1-4 lib32-nvcuda 3.0-4 (AUR) lib32-nvidia-utils 290.10-1 linux 3.1.5-1 linux-api-headers 3.1.4-1 linux-firmware 20111101-1 lm_sensors 3.3.1-2 nvidia 290.10-1 nvidia-utils 290.10-1 samba 3.6.1-1 wine-git 20111218-1 (AUR, compiled with mtune=core2 with only 32bit wine prefixes enabled and no X support) * config and/or log files etc. "daemon -U usr/bin/sensorlog.sh" >> rc.local Steps to reproduce: Run the attached script via rc.local, backgrounded Log in, the problem manifests. I have another person who uses my ISO confirm that they too have the issue, http://www.overclock.net/t/1156650/archlinux-based-smp-and-gpu-folding-distro/40_40#post_16184863 The script that causes the problem: #!/bin/bash _logname="sensors.log" _logdir="/tmp/sensors" test -d ${_logdir} || mkdir -p ${_logdir} while : do echo -e "Sensor log as of: $(date)\n" > ${_logdir}/${_logname} sensors >> ${_logdir}/${_logname} nvidia-smi >> ${_logdir}/${_logname} sleep 5 done |
This task depends upon
Closed by Gerardo Exequiel Pozzi (djgera)
Saturday, 17 November 2012, 02:57 GMT
Reason for closing: Upstream
Saturday, 17 November 2012, 02:57 GMT
Reason for closing: Upstream
Comment by
Alexander F. Rødseth (xyproto) -
Monday, 10 September 2012, 09:48 GMT
Comment by Logan Dam (biltong) -
Monday, 10 September 2012, 10:54 GMT
Comment by Greg (dolby) - Tuesday,
06 November 2012, 21:03 GMT
Thanks for reporting. Does this problem only occur when using
nvidia-smi?
From my use yes. I can't really test anything else for it though
as there is no X server running on the machine, and almost all
nvidia's tools rely on X.
Is this still a problem?