The Other Linux Thread

[ChaosNicro]

+

=

Post output of 'vmstat -sSM' & 'ps -u | grep KSP' while KSP is running.

You are running a 64bit kernel, right?

Swapping is normal, even if there is free ram. Provided that which is being swapped out is not going to be needed anytime soon.

'cat /proc/$(pidof KSP.x86_64)/status' will give you detailed memory usage (including swap) for the KSP.x86_64 process.

Sorry it took me so long.

I am running a 64-bit processor and system and the outputs in order are:

vmstat

7952 M total memory
         7138 M used memory
         3270 M active memory
         1420 M inactive memory
          813 M free memory
           41 M buffer memory
         2137 M swap cache
        25461 M total swap
            0 M used swap
        25461 M free swap
        37227 non-nice user cpu ticks
          421 nice user cpu ticks
        12315 system cpu ticks
       493819 idle cpu ticks
        12818 IO-wait cpu ticks
            1 IRQ cpu ticks
           68 softirq cpu ticks
            0 stolen cpu ticks
      2689813 pages paged in
        87814 pages paged out
            0 pages swapped in
            0 pages swapped out
      3632672 interrupts
     10434409 CPU context switches
   1417700784 boot time
         5580 forks

ps:

nicolai   5336 36.3 24.1 4986112 1966940 pts/2 Rsl+ 15:07   2:37 ./KSP.x86_64
nicolai   5755  0.0  0.0  12580  1016 pts/3    S+   15:14   0:00 grep --color=auto KSP

proc status:

Name:   KSP.x86_64
State:  S (sleeping)
Tgid:   5336
Pid:    5336
PPid:   4760
TracerPid:      0
Uid:    1000    1000    1000    1000
Gid:    100     100     100     100
FDSize: 256
Groups: 100 482 
VmPeak:  4987452 kB
VmSize:  4986112 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:   1966940 kB
VmRSS:   1966940 kB
VmData:  4588720 kB
VmStk:       472 kB
VmExe:     19392 kB
VmLib:     35556 kB
VmPTE:      4984 kB
VmSwap:        0 kB
Threads:        18
SigQ:   0/63405
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000381000
SigCgt: 00000005a08004ec
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
Seccomp:        0
Cpus_allowed:   c
Cpus_allowed_list:      2-3                                                     
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 
Mems_allowed_list:      0                                                       
voluntary_ctxt_switches:        132109
nonvoluntary_ctxt_switches:     512561

Additionally here is the mod loaders output:

KSP: 0.25 (Unix) - Unity: 4.5.2f1 - OS: Linux 3.11 openSUSE project 13.1 64bit
USI Tools - 0.2.4
B9 Aerospace - 5.2.6
CIT - CIT_Util - 1.1
CIT - KERT - 1.2.1
Community Resource Pack - 0.2.3
Ferram Aerospace Research - 0.14.4
Firespitter - 6.3.5
RasterPropMonitor - 0.18.3
KSP-AVC Plugin - 1.1.5
Kerbal Engineer Redux 1.0 - 1.0.11.3
KineTechAnimation - 1.1.1
ORSX - 0.1.3
ResGen - 0.28.2
TAC Fuel Balancer - 2.4.1.5
TAC Life Support - 0.10.1.13
MKS - 0.21.3

When swap does activate, it does so with no actual memory left slowing down KSP as well as my system by an unbearable amount.

The Firespitter mod is far outdated,it came packaged with two 0.25 mods claiming that it works though.

Edited December 4, 2014 by ChaosNicro

[steve_v]

I'm having this weird problem where inputting values in a mod UI, like MechJeb or Crew Manifest, triggers action groups and other functions bound to that key. Is that a known Linux issue?

Remap your action groups to the numberpad keys, since they don't work for entering numbers anyway (yes, that's a bug).

[lodestar]

Remap your action groups to the numberpad keys, since they don't work for entering numbers anyway (yes, that's a bug).

I did that as a workaround, but it's still annoying. For instance, I can't prevent the del key from switching to docking mode without reassigning it.

[steve_v]

@ChaosNicro:

I don't really see anything wrong with this picture, No swap being used, ~800MB free RAM & ~2.1GB cache, which should be freed as needed.

KSP is only using ~2GB at this point: 'VmRSS: 1966940 kB'

Mine, for reference (at the menu, more mods than you're running): 'VmRSS: 4825008 kB'

If the system is actually running out of RAM, what's using the rest of it? I find it hard to believe that that mod list would push KSP over ~4GB.

Do you have any other large processes running?

Do you have any ramdisks? i.e. /tmp mounted as tmpfs? tmpfs will use up to 50% of your physical RAM by default, if you have large files in /tmp it could be eating 4GB...

May be more illuminating to look at memory usage when it's actually swapping.

Firespitter hasn't caused any problems for me, despite the warning.

Edited December 4, 2014 by steve_v

[ChaosNicro]

@ChaosNicro:

I don't really see anything wrong with this picture, No swap being used, ~800MB free RAM & ~2.1GB cache, which should be freed as needed.

KSP is only using ~2GB at this point: 'VmRSS: 1966940 kB'

Mine, for reference (at the menu, more mods than you're running): 'VmRSS: 4825008 kB'

If the system is actually running out of RAM, what's using the rest of it? I find it hard to believe that that mod list would push KSP over ~4GB.

Do you have any other large processes running?

Do you have any ramdisks? i.e. /tmp mounted as tmpfs? tmpfs will use up to 50% of your physical RAM by default, if you have large files in /tmp it could be eating 4GB...

May be more illuminating to look at memory usage when it's actually swapping.

Firespitter hasn't caused any problems for me, despite the warning.

You're completely right, KSPs RAM usage is theoretically fine.

The mystery is that more than 2GB disappear upon startup. (not being used as cache or for KSP.).

The same amount is returned immediately after closing KSP and I have not the slightest of an idea what it is being used for.

According to my system I start out with pretty much 6GB (a tiny bit more) of free Ram before launching KSP. (with the script from OP)

I have a total of 8GB installed.

[gsarducci]

Hmm. @lodestar: You're not running FAR? That's a difference I can see right of the bat. Also, I recall that was an undocumented feature, but I don't offhand remember the workaround for it. I think it had to do with reassigning the function key since Linux OS keymapping to functions is obviously different from Windoze.

@gfurst: Your system is radically different from mine hardware wise. I'm off after the weekend so I'll have some time to really dig into this and test. I was a little off. My i5-2500K is OC'd to 4.4GHz. I Prime95-ed it for about 16 hours on mixed and it never missed a beat (though it did get hotter then I remember, with temps topping out around 69C), so I'm as convinced as I can be that the Proc/memory/IO/PS are stable.

I know this is somewhat thread derailing since it's clearly gone in another direction, but I wanted to update my progress.

This is SOLVED.

I disabled the Intel on-die video and also allowed Ubuntu to run its updates and was able to completely load my RSS modded KSP. Bolstered with this, I copied my gamedata and save game from the Windows partition over to another clean copy of KSP and it loaded up with zero issues. RAM usage is comparable to the Windows side at around 2.8GB at the VAB. I put Texture replacer in and it bumped up to 3.1GB with no issues, so I think I'm there.

With the open source AMD driver the performance was wildly varying. At the VAB it was very smooth, at the Mun base that has a heavy part count it went down to about 8 FPS. I installed the latest proprietary drivers (Catalyst 14.9) and that didn't improve the frame rate, though it did give me AA/AF so it looks better. I'm assuming at this point the deficient performance in comparison to Windows is due to the OpenGL rendering not being the best on the AMD card. Guess this will just force me to keep part counts low!

Anyway, after much experimentation I'm cooking with gas. Thanks guys for the help! I'll be around!

[Fail-Man 3D]

I wrote another shell script!

This one cleans up all but the latest version of ModuleManager (at least in the test cases I threw at it).

It assumes GNU coreutils + GNU parallel (because xargs is poorly documented on my system), and it deletes all but the most recent ModuleManager version, you have been warned!'

Usage: cd $KSPDIR && /path/to/fixmm.sh

#!/bin/bash
# fixmm.sh, released into the public domain by fm3d. Do whatever the heck you want with it.
# You don't even need to give me credit; in my (non-lawyer) opinion, it's not complex or creative enough to be copyrightable.
find . -type f -iname 'ModuleManager*.dll' -print0 \
	| sort -z -r \
	| tr '\0\n' '\n\0' \
	| tail -n +2 \
	| tr '\0\n' '\n\0' \
	| parallel --no-notice -0 rm {}

[pina_coladas]

Hi everyone

I decided to jump in feet first with manjaro (xfce edition) and everything seems to work fine with a stock KSP install. But when I start installing mods I come upon this problem:

That's the distant objects mod window there. If I install a bunch of mods, all mod windows look like that. I tried installing just FAR to see what would happen and that window displays just fine. So I installed distant object enhancement alongside FAR and now the DAE window doesnt work, while FAR still does. If I install more mods, all windows are broken. Strange.

Has anyone seen this before?

Edit: And what was voidi's script from that other thread supposed to do? I think it might be broken for .90 because the launcher it gives me with the pretty icon does nothing when I execute it.

Edit2: if this is something as simple as a missing fonts issue that would be really frustrating because I'm banging my head against a wall trying to install the fonts suggested in the other linux thread. Isn't there some package I can just install and be done with it? I basically need my hand held to do everyday things in linux :S

Edit3: Yes, it was the fonts...

Edited January 21, 2015 by pina_coladas

[Disco Pete]

Hi.

I've spent the better part of the last week trying to play KSP on linux. I got a distro installed on a HDD partition (Manjaro 0.8.12, with Xfce 4.10). Got KSP installed, found out how to run it. su and sudo'd enough to drive a man mad. Figured out how to get the fonts to work. Though I could just take my save from the windows version and copy/paste it to the linux version. Nope. New game. Install the mods. Something's wrong. Re-install KSP. Re-re-install mods. And... it starts. And that's it. I don't even know what info to give anyone, or who to give it to. All I got is this screenshot:

Screenshot_2015-02-24_19-09-26

Is this common? has this happened to someone else? How did you fix it?

I'm sorry I don't have specifics, but I don't even know where to start.

EDIT: On re-reading my post, I can imagine that the issue is not clear from this screenshot. None of the menu options are accessable, and are all dark colored.

Edited February 25, 2015 by Disco Pete

[micha]

It looks like the window isn't getting focus. Tried alt-tabbing to it? Tried running it full-screen instead?

Afraid I've never had that issue; for me KSP just installed and ran without issue on Debian x64, initially using KDE but now in WindowMaker.

[Svm420]

Got a crash that I believe is telling me i am using all 16gb of my ram which while I run a heavy mod setup is not possible I monitor my ram and it never exceeds 10gb here is my log if anyone can help. Let me know if you need more info.

[UnanimousCoward]

Got a crash that I believe is telling me i am using all 16gb of my ram which while I run a heavy mod setup is not possible I monitor my ram and it never exceeds 10gb here is my log if anyone can help. Let me know if you need more info.

You ain't the only one, mate. At least me and 2 others have the same problem.

http://forum.kerbalspaceprogram.com/threads/109908-Frequent-crashes-during-modded-KSP-startup

[shrx]

Has anyone managed to run KSP over SSH? What command should I use?

If I try ./KSP.x86_64 I only get a brief flash of a black window which quickly disappears and nothing else happens.

The output in the console is

Set current directory to /home/shrx/.steam/steam/steamapps/common/Kerbal Space Program

Found path: /home/shrx/.steam/steam/steamapps/common/Kerbal Space Program/KSP.x86_64

Mono path[0] = '/home/shrx/.steam/steam/steamapps/common/Kerbal Space Program/KSP_Data/Managed'

Mono path[1] = '/home/shrx/.steam/steam/steamapps/common/Kerbal Space Program/KSP_Data/Mono'

Mono config path = '/home/shrx/.steam/steam/steamapps/common/Kerbal Space Program/KSP_Data/Mono/etc'

[cantab]

I really don't think that will work. While X forwarding over SSH does work, I don't think it's at all made to work with 3D acceleration.

[Insanitic]

This rig is a couple of years old and has been used almost exclusively as a platform for iRacing, though I have appropriated it for other tasks (like for instance, playing KSC!).

Anyway, Specifics if it helps are:

MB: Gigabyte GA-Z77-D3H

Proc: Intel i5-2500K Sandy Bridge (3.3GHz default, overclocked to 3.8GHz), cooled by a CORSAIR H60 water cooler

Memory: G.Skill Super Sniper blah blah blah DDR3 1866, 8GB (2x4GB)

Vid: XFX Radeon 7950 3GB

Associated case with enough airflow to start a CF56 turbofan engine. (CM Storm Enforcer, if you care)

As for proc temps, I have a windows app that monitors real time and trends (with alarm since I'm watercooling and if that turds itself things get real hot, real fast). Under load testing when new (to determine stable overclock), at present speed MAXIMUM ever attained temperature on any core was 49C. Under typical heavy use (running iRacing and associated ancillary programs, temps are around 41C. While playing KSC32 in Windows temps are about 38C. Idle baseline is between 26C and 30C once coolant is stabilized, depending on ambient temps.

In short, I seriously doubt I'm running into thermal related problems with Linux, though I haven't attempted to monitor temps within that OS. The fact that the game freezes at effectively the same place also makes me think this isn't a processor related issue. My general experience is with overclocked systems failures are a bit more "random" due to instability. There might be some credence to a memory issue, though again I've never had an issue in Windows and I would think if I had flaky memory it would have at some point started freaking out once I filled up the registers doing things other then KSP, regardless of platform. Also, using HTOP to monitor resources, I see that when KSP freezes it's at about 3.3GB of memory usage. Also, worth noting that it seems it's locking Unity, not Linux. Previously I had mentioned that I tried (and failed due to my stupidity) to SSH into the system from another computer, and it responded to me (told me to get bent, but it's a response) and it responded to pings, which tells me the OS is alive.

Just brainstorming, here are some things I am guessing about having potential issues. Please feel free to correct me, educate me and otherwise point me and punt me in directions you feel might be useful. Hell, if you're particularly masochistic, let me know if you want to shell into the damn thing and take a look see under the hood! Anyway, here goes.

The 7950 is feeding 3 screens. All three screens are identical. Two are being fed by the display ports via Startech MDP2DVIS display port to DVI active adapters. The third is connected directly via the DVI port on card. There is a 4th screen that is connected via the mainboard DVI adapter served by the Intel video adapter that is on the die of the i5 processor. I have DISABLED this screen in Ubuntu as it was causing all sorts of display issues. I have NOT disabled this adapter in BIOS (since Windows is using it, I don't want to have to go back and forth into BIOS to turn it on and off). I have not modified or changed the default video driver that Ubuntu installed. At present, Unity seems very happy serving these three screens and is having no apparent issues. When I ran stock KSP (In a window, not full screen. I've never run KSP full screen) I had no complaints about performance or smoothness. Is it conceivable that even though I have Linux ignoring the 4th screen on the Intel adapter that it is still somehow effecting the system?

In the realm of trying to do things that won't require me materially altering the system, I'll test the memory and back the clock down to stock speeds, just to eliminate those things from the equation. After that, I was toying with loading up xfce to see if maybe it's Unity puking on this...

If you have any other things you want me to try, I'm totally game. All I ask is that you explain what you're doing. I'm here to learn above all else, and trying to get this to work is an excellent opportunity to gain understanding!

And, thank you all! I'm amazed how much I've forgotten!

Seeing as you have the exact same AMD card as me, can you give me insight of KSP's FPS performance on your system? I have an identitical system to you, except using Ubuntu and have a Core i7 2700k, and I noticed that my performance is significantly lower than even Opengl on Windows.

[Esme]

I'd just like to comment, if I may, that Linux can be - has been on my PC - a case of 'install KSP and start playing'. The only thing I had to do was to turn the graphics quality ad aerodynamic effects down, and that only because my PC is an old second hand Dell box. And trust me - KSP still look splenty good enough even with the graphics texture settings on 1/4.

Also, I'm happy to report that CKAN on Linux is working perfectly, and makes mods that support CKAN an utter doddle to install.

My advice to any linux newbies would be to keep it simple - stick to one of the newbie-friendly distros the OP mentions, install KSP direct, rather than via Steam*, and if things run slow, crank the graphics settings down until things run OK. If you can't get KSP running acceptably well even on low graphics settings and you;re sure that your hardware is up to the job, that's the time to start looking into why and asking here for help. It used to be teh case that most distros would pretty much gurantee to get you a working desktop straight from install, but working 3D graphics might be another matter. These days, though, the newbie-friendly distros seem to do a grand job of auto-detecting graphcs cards (always remembering that bleeding-edge hardware may be unknown to the software) and installing the necessary 3D gubbins as well. You might be able to get better performance out of your kit if you;re prepared to do the research, ask in forums and tweak stuff; but that;s true no matter what operating system you;re using. It certaily isn't the case that using Linux requires that kind of fiddling, any more. (In fact, I left Windows for Linux at home simply because I found Linux gave me far fewer problems, and 'just worked' more often. Your mileage may vary, etc.)

*I've nothing against Steam, it does a good job of what it's for, but because it stuffs everything into its own sub-directory, it just means that if you like messing with mods, you've got even more folders and sub-folders to have to trawl through to get to where you want to be. And, Steam does add another layer of stuff that isn't strictly needed to play KSP. More stuff = more potential for things to go wrong. That said, I didn;t experience any problems during the period I was running KSP on Steam - I stopped playing it via Steam simply because of the added mucking about when adding/removing mods.

[Green Baron]

@esme:

I totally agree with every one of your words and am glad that someone points it out !

Running over smallband network (ssh), running in vm, installing arbitrary and undocumentet third party libraries (steam), overclocking the hardware out ... sure there'll be problems, thats no miracle. In many cases that's using the wrong tools for the job, expecting the super-cow.

I believe that many problems could simply be solved by installing the os (i'd recommend ubuntu or derivatives or plain debian for the connaisseurs) and setting up the correct graphics-driver and nothing else that's not fully documentet or can have unforeseen sideeffects.

Another thing probably is that that the 64bit version just runs under linux and the linux version has less memory problems (is that so ?) which could seduce people to play ksp in linux but on the other hand want to keep the windows environment. But you can't have everything. If you like the 64bit merits (which are probably smaller than one might think) get a second computer or install a dual boot system, which is pretty straightforward, just click "yes" when asked ... linux is not a beast (less then i'l better shut up :-))

Please let me add that the open source graphics driver for nvidia cards (called nouveau) isn't as sophisticated as the proprietary nvidia driver, downloaded from the nvidia site. I've heard (but no experience) that for the amd driver the same is applicable.

Risking all my rep

K

btw: i play ksp on a notebook with i3, intel hd4400 and 4gb ram. Modded with b9, kw, and a few others. Runs nicely on low graphics settings even for a station with several 100 parts (that i built on another pc i must admit, wouldn't want to dock with that station on this one ....)

Edited April 7, 2015 by kemde

[cantab]

If you bought KSP through Steam, you're quite welcome to copy the entire KSP folder out of Steam and somewhere else and run it directly. Just poke around in the Steam folder, usually under /home/yourusername/.steam , to find it. (A file or folder name starting with a dot is how Linux does hidden files, so you may need to enable showing them.)

As for graphics drivers, if you have an nVidia card you'll almost surely want the proprietary nVidia drivers, if you have an AMD card you might want the proprietary AMD drivers. In general to install programs on Linux you should get out of the Windows habit of downloading installers from websites, and use the package manager or software centre which is similar to the app stores on mobiles.

[Shurikeeen]

The start-up scrips does not do anything :/

[steve_v]

Uh huh, and what is one supposed to do with that scant information?

I assume the 'scrips' you refer to is in fact the bash script in the OP? Works fine for me.

Does it produce anything on STDOUT?

Do you have taskset? 'which taskset' in a terminal will tell you.

- - - Updated - - -

Has anyone managed to run KSP over SSH? What command should I use?

If I try ./KSP.x86_64 I only get a brief flash of a black window which quickly disappears and nothing else happens.

The output in the console is

KSP needs OpenGL with shaders, which you won't get with remote X, over ssh or otherwise.

KSP will run with VirtualGL, but bandwidth constraints and the performance of your graphical transport will limit framerate. VGL transport or TurboVNC over a LAN is your best bet in that regard, probably best to exclude the SSH overhead if you can too.

No promises on playability, but it does run.

isn't KSP, but it's a reasonable comparison of X11/GLX vs VGL. Performance can be surprisingly good

KSP even runs with VGL + X2go, but the only testing I have done is over a rather pathetic ADSL connection, so no comment on the performance of this configuration.

Edited May 22, 2015 by steve_v

[Gfurst]

Hey guys, can you help me out figuring this [thread=122529]weird graphical corruption issue[/thread]?

[TaintedLion]

I tried installing the re-entry bug workaround from the unmodded thread, but it still won't work.

[steve_v]

I tried installing the re-entry bug workaround from the unmodded thread, but it still won't work.

More information required.

[theersink]

Handled in the CKAN thread.

Edited October 30, 2015 by theersink

[politas]

A couple of notes for things I have discovered recently.

Having hard lockups, especially when trying to use Environmental Visual Enhancements? Running on an AMD graphics card? Try loading up the BoulderCo/Clouds PNG files in an image viewer. If you get a lock up on one or more of them, you've hit the same AMD Kernel driver bug I did. The only solution I could find was to replace my graphics with NVidia, since both the Catalyst and open source drivers use it. Now I have no issues. Fixed up Cities: Skyline, too.

Trying to run a heavily modded KSP under Steam, and find that you can load KSP fine if you navigate to the folder and run KSP.x86_64, but you run out of memory or fail to load when launching from Steam? Steam launches the 32 bit KSP.x86 instead of KSP.x86_64. Rename it and make a link KSP.x86 -> KSP.x86_64, and you'll get the 64 bit version we all love so much.