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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by Alexander F. Rødseth (xyproto) - Monday, 10 September 2012, 09:48 GMT
Thanks for reporting. Does this problem only occur when using nvidia-smi?
Comment by Logan Dam (biltong) - Monday, 10 September 2012, 10:54 GMT
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.
Comment by Greg (dolby) - Tuesday, 06 November 2012, 21:03 GMT
Is this still a problem?

Loading...