The Linux Thread!

[steve_v]

1 hour ago, sal_vager said:

Guys, if you update to kernel 4.4 do not remove your previous kernel.

Curious. I'm running 4.5, and don't see this, I was running 4.4 (prior to 2016-05-03)... and didn't see it there either.

1 hour ago, sal_vager said:

I don't know how this is even possible

Indeed, most peculiar. SSHing into the machine to see what's going on (or kill KSP) might be worth a look.

[sal_vager]

Yeah I'll have to set up my laptop, though it's over 10 years old now.

Ubuntu hasn't updated to 4.5 yet but it's good to hear you're not seeing this, I may just be unlucky today.

[ThomasOnLinux]

@sal_vager What Gnu/Linux distribution do you use? Ubuntu?

[sal_vager]

On 09/05/2016 at 10:47 AM, ThomasOnLinux said:

@sal_vager What Gnu/Linux distribution do you use? Ubuntu?

Currently Xubuntu 16.04 64bit, though I had performed a distribution update from 15.10 and I still had the 4.2 kernel, but after the update I ran apt-get autoremove.

I currently have both the 4.4.0-21 and 4.4.0-22 kernel images installed.

Now every time I'm in the VAB or SPH it's like Russian roulette, most of the time the input stops working but the animations and the system clock keeps going, but twice the entire PC has frozen.

Attempts to SSH into the PC have not been successful so far.

 

Update:

As suddenly as it started, it stopped, there was another kernel update though...

[cantab]

For what it's worth, KSP 1.1.2 "works for me" on Debian. (Mixed system, mostly stable but with some packages from testing and backports.) 4.5 kernel, running 64-bit KSP 'directly' (ie not through Steam). It's a bit crash happy, compared to 1.0.5 which was rock stable, but playable enough.

sal_vager I wonder if your issue isn't just KSP being a mega CPU hog. Though it's a bit odd for REISUB to not work, unless it's actually been disabled. You could try the 4.5 kernel from Debian perhaps.

[Badsector]

9 hours ago, sal_vager said:

Currently Xubuntu 16.04 64bit, though I had performed a distribution update from 15.10 and I still had the 4.2 kernel, but after the update I ran apt-get autoremove.

I currently have both the 4.4.0-21 and 4.4.0-22 kernel images installed.

Now every time I'm in the VAB or SPH it's like Russian roulette, most of the time the input stops working but the animations and the system clock keeps going, but twice the entire PC has frozen.

Attempts to SSH into the PC have not been successful so far.

Can be some ACPI compatibility issues, try to update your bios or add "pcie_aspm=off usbcore.autosuspend=-1 noapic" at "GRUB_CMDLINE_LINUX_DEFAULT=" for see if you get again the issue

[sal_vager]

I actually updated the bios the other day due to a keyboard issue, I get "USB_Submit_URB(ctrl) failed: -1" from the bios during boot, it was causing a long delay in boot time until the bios update, it still occurs but the delay is gone.

Not sure if the Debian kernel will work, but I'll try the other suggestions, thanks guys

Edit:

Still locking up in KSP, now in Pulsar Lost Colony beta 8, which uses Unity5.2.3f1

[l0k0]

Hello penguins!

don't know if it has been asked but... since 1.1.0 came out I'm experiencing some weird problems with texture/rendering. I run KSP on my laptop acer travelmate (i915 chipset) with 8GB RAM and ubuntu 14.04. Usually I play a modded installation of KSP but I tested the stock one and the issues are still there.

As you can see in the pictures there's sometingh strange in the VAB and the SPH (very annoying...).

Then I discovered that asteroids look like black holes...

Suggestions?

[waterlubber]

Kind of looks like artifacting, what are your temps?

[sal_vager]

Looks like a rendering issue to me, rather than temperature.

You could try starting KSP with -force-glcore and/or -force-gfx-direct, they seem to be the LC_ALL=C of KSP on Unity5.

[azander]

Semi-random (may not be random?) Issue during start up here.  I see many people with the same issue. 

During startup the screen size starts out normal sized, then changes to some unusual size making the game unplayable.  It resized just as unity hands off to KSP from the looks of things. 

To test,  I have removed all config files and logs file.  Then started a clean steam-based, stock copy of KSP using "./KSP.x86_64 -force-gfx-direct" as suggested many times above and elsewhere. 

The Player.log file is here and the KSP.log is below.

 

Spoiler

~/.steam/steam/steamapps/common/Kerbal Space Program> cat KSP.log
Kerbal Space Program - 1.1.3.1289 (LinuxPlayer)

OS: Linux 3.16 openSUSE project 13.2 64bit
CPU: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz (2)
RAM: 5980
GPU: GeForce 8400GS/PCIe/SSE2 (1024MB)
SM: 30 (OpenGL 3.3 [3.3.0 NVIDIA 340.96])
RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8

Log started: Sat, Jul 23, 2016 10:46:30

 

 

I have tried forcing the prefs file, removing the pref file, getting a good startup, then setting hte prefs file to read-only.  I have tried 64 bit, 32 bit, 64bit with options, etc.

This is making the game unplayable for me. 

What else can I do?

[ImaSpaceJunk]

Chiming in to say that Ubuntu 16.04 + SVE 1.0.4 + padoka's ppa + launching with MESA_GL_VERSION_OVERRIDE=4.2COMPAT DRI_PRIME=1 ./KSP.x86_64 -force-glcore42 has fixed for me a long standing "blue band" issue when leaving the atmosphere.

City light textures still bug out as described in some older threads, that seems to be something with the texture loading, and ActiveTextureManager is not updated for 1.1.3 on CKAN. Green sky issue seems to go away when gl compat is 4.2 instead of 3.x, but it's kinda sporadic.

Edited July 25, 2016 by ImaSpaceJunk

[sal_vager]

@azander, did you try -force-glcore instead of or in addition to -force-gfx-direct? It forces correct detection of your version of OpenGL and may prevent the misidentified resolutions many people are getting in their prefs file.

[JoelleEmmily]

I realize one's not really supposed to ask for help regarding mods on this thread, however, I believe this fault is unique to linux, and it seems the developer doesn't have a lot of experience with it.

The problem is a graphics bug while using scatterer, original post to the dev is here: https://github.com/LGhassen/Scatterer/issues/18 , which results in hard "terrain" and "navigational" lines on planet and sky textures. Also, and I didn't notice this before, no clouds appear while in orbit.

I can't try his anisotropic filtering suggestion, as I haven't found a way to change the setting without recompiling mesa. I have tried changing in game setting, but that has resulted in no change to the bug. If run KSP without the force-glcore switch, the game appears to no longer be affected by the bug, but all the other problems, such as missing buttons and misaligned shadows, come back.

[azander]

On 7/26/2016 at 11:50 AM, sal_vager said:

@azander, did you try -force-glcore instead of or in addition to -force-gfx-direct? It forces correct detection of your version of OpenGL and may prevent the misidentified resolutions many people are getting in their prefs file.

Yes, same issue.  This is really getting annoying.

[sal_vager]

4 minutes ago, azander said:

Yes, same issue.  This is really getting annoying.

Okay how about changing the prefs file to the res you want then making it read only.

@JoelleEmmily I'm not really sure when it comes to bugs with mods, the best place for that would be the scatterer thread but someone here might know.

[JoelleEmmily]

@sal_vager Already done, LGhassen isn't familiar enough with Linux drivers to give many suggestions. I think the problem might be with mesa's implementation of OpenGL, maybe even its 3.3 calls specifically.

[sal_vager]

Depending on your distro there might be newer drivers available, for *buntu it's worth checking the Oibaf or Edgers repositories.

[azander]

I have the most "up to date" drivers for my distro.  (OpenSuse 13.2, Opengl 3.3 via NVIDIA propriety drivers)

@sal_vager I tried that.  works properly more often, but still sometimes glitches out to strange resolutions, even though the prefs file never gets updated with the wierdness.

 

 

[sal_vager]

What desktop are you using? Some like Gnome are freaking out with KSP, and there's a workaround using OOM killer.

[azander]

OpenSuse 13.2 64-bit, KDE install.

I'll try the OOM killer too.  What do I need to do?

[sal_vager]

Erm actually that may not help, as it is about x.org crashing, not resolutions, sorry.

Quote

 

"Gnome/UnityDE/IceWM/lxde/Xserver crashes when I start/change resolution in KSP!" (New for 1.1)

This appears to be OOM killer killing Xorg, see @Psycho_zs's fix here

 

On 27/04/2016 at 2:45 AM, Psycho_zs said:

My two cents:

Sometimes KSP managed to freeze and crash my X server upon start. This happens because of some rare instant memory leak, so Xorg gets killed by OOM killer. To give it some other target (KSP), I've added a line to my launcher script before KSP exec, like so:

sh -c 'sleep 1 ; echo 15 > "/proc/$(pgrep KSP.x86_64)/oom_adj"' &
exec ./KSP.x86_64 ...

This should make KSP a priority target for OOM killer. Funny thing, no such freak leak happened ever since, so I do not yet know if this can really help X to walk away from it in working order.

What resolutions are you trying @azander?

[azander]

I believe is is using 1280x720 or something close to that.  xrandr shows this:

 

Spoiler

> xrandr
Screen 0: minimum 8 x 8, current 1600 x 900, maximum 8192 x 8192
DVI-I-0 disconnected (normal left inverted right x axis y axis)
VGA-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 1600x900+0+0 (normal left inverted right x axis y axis) 443mm x 249mm
   1600x900      60.00*+
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
HDMI-0 disconnected (normal left inverted right x axis y axis)

 

Player.log shows:

Default vsync count 0
requesting resize 1280 x 720
resizing window to 1280 x 720
Desktop is 1600 x 900 @ 60 Hz

 

[Psycho_zs]

Here is my latest launcher script. Memory leak happens when KSP window gets random window size of really cosmic proportions, so I've added a background function that monitors window size and kills KSP right away if window gets weird. Much faster than waiting for it to eat through memory. OOM score bumper is still in place.

#!/bin/bash

WINWIDTH=1366
WINHEIGHT=768


# change dir to script location
cd "$(dirname "$(readlink -f "$0")")"

printf "Fixing weird permissions from game archive.\n"
find . -type f -exec chmod 644 "{}" \;
find . -type d -exec chmod 755 "{}" \;
chmod 755 KSP.x86  KSP.x86_64  Launcher.x86  Launcher.x86_64 "$(basename "$0")"

if [ -z "$(pidof pulseaudio)" ]
then
	printf "No pulseaudio? Avoiding crash by linking pulseaudio lib to /dev/null.\n"
	[ "$(readlink -f libpulse-simple.so.0)" != "/dev/null" ] && ln -sf /dev/null libpulse-simple.so.0
	export LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH"
else
	if [ "$(readlink -f libpulse-simple.so.0)" = "/dev/null" ]
	then
		printf "Decided to switch to pulseaudio? removing workaround link...\n"
		rm libpulse-simple.so.0
	fi
fi

if [ -d "${XDG_CONFIG_HOME:-$HOME/.config}/unity3d" ]
then
    printf "removing \"${XDG_CONFIG_HOME:-$HOME/.config}/unity3d\" because it breaks things!\n"
    rm "${XDG_CONFIG_HOME:-$HOME/.config}/unity3d" -rf
fi

printf "Still can not learn languages? setting LC_ALL=C\n"
export LC_ALL=C
unset LANGUAGE

{
	COUNT=0
	printf "Starting window geometry guard...\n"
	while [ "$COUNT" -lt "180" ] && pidof KSP.x86_64 > /dev/null
	do
		sleep 1
		WIDTH=$(xwininfo -name "Kerbal Space Program" | grep -o 'Width:[[:space:]]*[0-9]\+' | grep -o '[0-9]\+')
		HEIGHT=$(xwininfo -name "Kerbal Space Program" | grep -o 'Height:[[:space:]]*[0-9]\+' | grep -o '[0-9]\+')
		[ "$WIDTH" -gt "$(( $WINWIDTH * 2 ))" ] && { printf "Window geometry is freaky (${WIDTH}x${HEIGHT}), killing KSP!\n" >&2 ; killall KSP.x86_64 ; exit 0 ; }
		[ "$HEIGHT" -gt "$(( $WINHEIGHT * 2 ))" ] && { printf "Window geometry is freaky (${WIDTH}x${HEIGHT}), killing KSP!\n" >&2 ; killall KSP.x86_64 ; exit 0 ; }
		COUNT=$(( $COUNT + 1 ))
	done
	printf "Window geometry guard no longer needed.\n"
} &

sh -c 'sleep 1 ; printf "Bumping KSP OOM killer score in case it goes berserk and chews up all the memory at once.\n" ; echo 15 > "/proc/$(pgrep KSP.x86_64)/oom_adj" ; printf "KSP OOM score: " ; cat "/proc/$(pgrep KSP.x86_64)/oom_score"' &

printf "Launching. Hold on to yer helmets and pray the Kraken!\n"
# glcore versions: 32, 33, 40, 41, 42, 43, 44, 45.
# if running pre-broadwell intel choose 33
# if running any intel and it is still 2016, choose 33
# check driver news, i.e. on phoronix.com
exec ./KSP.x86_64 -force-glcore33 -force-gfx-direct -screen-fullscreen 0 -screen-width $WINWIDTH -screen-height $WINHEIGHT

 

[azander]

Nice Script @psycho_zs though it doesn't fix my problem. 

I still get the screen size wierdness... and on top of that xwininfo -name "Kerbal Space Program" outputs the original starting resolution, and not the current one, so your checker never sees that it resized after opening and is unplayable.