Results 1 to 9 of 9

Thread: Problem with greb lspci, and serious sam3

  1. #1

    Default Problem with greb lspci, and serious sam3

    I installed on openSUSE 12.2 64 bit, through steam, the game Serious Sam 3.

    The problem, the in game vids and the sound stutter when a vid starts, and when the camera view changes.
    (same hardware under windows, no problem)

    Amd phenom II X4 @3.2 ghz, 4 gig of ram, HD5750 ( 1 gig of ram)

    So I went to the steam forums, were one of the developers of Croteam, helps you with problems.

    Sound problems on Linux in cutscenes :: Serious Sam 3: BFE General Discussions

    AlenL [developer]
    Hm, seems either something is wrong with the lspci command, or the hardware is not recognized correctly. If you just this:

    lspci -nn | less

    it should dump a ton of text for you to scroll through. You should be able to find _something_ about your GPU there. The first issue here is that for some reason the game doesn't find your GPU in that output so it cannot adjust the graphics accordingly. Please let us know if you can find it.


    I then found out two things.
    I need sudo for lspci, and it needs the full path.

    AlenL replied:
    Then, there is something wrong with the files in /sys/ folder For example, the game runs this command:

    grep '' /sys/devices/system/cpu/cpu0/cpufreq/scaling_*

    (that after grep is two single quotes)

    This is supposed to print contents of those files, which are supposed to be text files with current config settings for performance options of the CPU. However, for some reason grep seems to think those files are binary on your system. This is either a problem with grep, or something seriously strange on the system.

    And finally, the fact that lspci requires sudo for you sounds like something is wrong there. It is problematic for programs trying to auto-configure themselves (like games) depending on hardware.


    Questions:
    I assume he is right, can some one confirm this?
    Is there for me a way to solve this?

  2. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,853

    Default Re: Problem with greb lspci, and serious sam3

    Hello,

    First, please always post computer text between CODE tags. You get them by using the # button in the toolbar above the post editor. This is the most secure way that computer text comes out as it should be. E.g. the "two single quotes" you mention do show then as such and need no comment, as does white space.

    In the manpage of lspci:
    Code:
    man lspci
    you will find
    Access to some parts of the PCI configuration space is restricted to root on many operating systems, so the features of lspci available to normal users are limited. However, lspci tries its best to display as much as available and mark all other information with <access denied> text.
    Thus it depends very much on what your application wants to find there. I guess (and hope) that your application does not nead to be run as root (in which case you better do not run it at all), in which case there is no need to use root for it. But you need the full path as end-user (as it says).

    When you want to run it as root (as a test, like here), you better use
    Code:
    henk@boven:~> su -
    Password: 
    boven:~ # lspci -nn
    00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02)
    00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)
    ........
    .......
    boven:~ # exit
    logout
    henk@boven:~>
    Then about
    Code:
    grep '' /sys/devices/system/cpu/cpu0/cpufreq/scaling_*
    Now the files inside /sys are no real files. They are information made available by the kernel to the outside world through a file methaphore interface. For some reason (I guess there is no line structure in the info given) grep thinks they are binary:
    Code:
    henk@boven:/sys/devices/system/cpu/cpu0/cpufreq> grep '' scaling_*
    Binary file scaling_available_frequencies matches
    Binary file scaling_available_governors matches
    Binary file scaling_cur_freq matches
    Binary file scaling_driver matches
    Binary file scaling_governor matches
    Binary file scaling_max_freq matches
    Binary file scaling_min_freq matches
    Binary file scaling_setspeed matches
    henk@boven:/sys/devices/system/cpu/cpu0/cpufreq>
    But file thinks different:
    Code:
    henk@boven:/sys/devices/system/cpu/cpu0/cpufreq> file scaling_*
    scaling_available_frequencies: ASCII text
    scaling_available_governors:   ASCII text
    scaling_cur_freq:              ASCII text
    scaling_driver:                ASCII text
    scaling_governor:              ASCII text
    scaling_max_freq:              ASCII text
    scaling_min_freq:              ASCII text
    scaling_setspeed:              ASCII text
    henk@boven:/sys/devices/system/cpu/cpu0/cpufreq>
    Now when you look in grep's man page to see if you can force grep into believing it is text, I find:
    -a, - -text
    Process a binary file as if it were text; this is equivalent to the - -binary-files=text option.
    Thus I tried that:
    Code:
    henk@boven:/sys/devices/system/cpu/cpu0/cpufreq> grep -a '' scaling_*
    scaling_available_frequencies:1600000 1200000 
    scaling_available_governors:conservative userspace powersave ondemand performance 
    scaling_cur_freq:1600000
    scaling_driver:acpi-cpufreq
    scaling_governor:ondemand
    scaling_max_freq:1600000
    scaling_min_freq:1200000
    scaling_setspeed:<unsupported>
    henk@boven:/sys/devices/system/cpu/cpu0/cpufreq>
    Hope this helps.
    Henk van Velden

  3. #3

    Default Re: Problem with greb lspci, and serious sam3

    Thank you that did help allot, although this might not solve the problem, I am learning more about openSUSE (Linux), which is always a good thing

    The file showed no strange things, according, to the developer.

    The only thing I could try according to him, use alsa instead of pulse audio.

    I am not sure yet what I will do.
    In 6 days there is 12.3, which might solve the problem too.

    I will use quote the next time, but the computer text is literately as the dev posted it.

    The game does not require root privileges to run.
    I could try to start it ones as root though, this has solved problems with games on other distro's and pc's too.
    Don't need to play as root, just start it, and let it search for the hardware.
    Then quit the game, log out as root, and start the game as normal user.

  4. #4
    Join Date
    May 2010
    Location
    Space Colony Lagrange Point 22° à, 77° Ƅ, 56° ɤ, 99° ɜ
    Posts
    3,166

    Default Re: Problem with greb lspci, and serious sam3

    Quote Originally Posted by Gps2010 View Post
    I could try to start it ones as root though, this has solved problems with games on other distro's and pc's too.
    Don't need to play as root, just start it, and let it search for the hardware.
    Then quit the game, log out as root, and start the game as normal user.
    The game software may write into some config files and root permissions would be applied to these files and normal user mode may not be able to read this file.
    You may need to do a recursive chown on the config folders. Then again i might be wrong
    GNOME Version 3.20.2
    openSUSE Leap 42.3 64-bit

    www.vazhavandan.blogspot.com

  5. #5
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,853

    Default Re: Problem with greb lspci, and serious sam3

    First and for all, you should NOT try to start any end-user application as root!

    I repeat, you do NOT need to be root to run lspci (except that maybe not everything that can be listed will be there), you only need to use the full path. Did you now try what AlenL advised you:
    Code:
    /sbin/lspci -nn | less
    to look at that GPU information?
    Now if the application also uses this lspci command (without the /sbin/) there are basicaly two options:
    a) change the application (which is easy when the command is in a script, but requires a rebuild when it is in the source of a binary executable);
    b) add /sbin to your PATH variable. This is easy to do. One way to do this:
    Code:
    echo 'PATH="${PATH}:/sbin"' >> ${HOME}/.profile
    Please do copy/paste this, because any typo can create strange things.
    After you have done this, login anew and check if you now can run lspci without typing the path.

    The second problem, grep categorizing the files as "binary" is a problem that can ve solved by using the -a option. Like above, that is easy to change if that grep statement is in a script of the application. When it is compiled into a binary executable of the application, the source must be changed and the application must be rebuild.
    Henk van Velden

  6. #6

    Default Re: Problem with greb lspci, and serious sam3

    Henk is mijn held ( Henk is my hero )

    After I copy paste the command you gave me, into the commandline, I rebooted,
    Then tried

    Code:
    lspci -nn | less
    It works ! thank you. Don't need the full path any more. ( nor sudo )

    About what AlenL advised me.
    Although I used sudo, I was able to provide him with the info he needed.

    I did
    Code:
    guus@linux-0iwr:~> sudo /sbin/lspci -nn 
    root's password:
    The -nn adds the number at the end a line like [1022:9601]

    Which gives
    Code:
    00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS880 Host Bridge [1022:9601] 
    00:02.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (ext gfx port 0) [1022:9603] 
    00:0a.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 5) [1022:9609] 
    00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] [1002:4390] (rev 40) 
    00:12.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] 
    00:12.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] 
    00:13.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] 
    00:13.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] 
    00:14.0 SMBus [0c05]: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller [1002:4385] (rev 41) 
    00:14.1 IDE interface [0101]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE Controller [1002:439c] (rev 40)
    00:14.2 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) [1002:4383] (rev 40)
    00:14.3 ISA bridge [0601]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40)
    00:14.4 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge [1002:4384] (rev 40)
    00:14.5 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399]
    00:15.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) [1002:43a0]
    00:16.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
    00:16.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
    00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration [1022:1200]
    00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor Address Map [1022:1201]
    00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller [1022:1202]
    00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control [1022:1203]
    00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor Link Control [1022:1204]
    01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Juniper [Radeon HD 5700 Series] [1002:68be]
    01:00.1 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series] [1002:aa58]
    02:00.0 SATA controller [0106]: JMicron Technology Corp. JMB361 AHCI/IDE [197b:2361] (rev 02)
    02:00.1 IDE interface [0101]: JMicron Technology Corp. JMB361 AHCI/IDE [197b:2361] (rev 02)
    03:07.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0)
    04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06)
    guus@linux-0iwr:~>
    AlenL, then replied, this was what he wanted, but did not see anything wrong with it.

    Thanks for the output. It seems ok. But if it requires sudo, I guess it is logical that the game doesn't get it.

    Anyway, your original problem seems to be related to sound, so while this GPU driver might be related, there is still one other thing you can do. You can maybe try to change openal config to use alsa instead of pulseaudio. It helped for some people.

  7. #7

    Default Re: Problem with greb lspci, and serious sam3

    Good and bad news.

    Lets start with the good news.
    The in game vids have improved. ( in the game I have clicked detect hardware or something like that )
    There is still some minor stutter in the vid, but the sound stutter is almost or totally gone.
    I am not missing parts of the text spoken anymore.

    The bad news

    When I start the game I now have when the company logo's are displayed, some weird graphic problem.
    Some blue trapezoid, which was not there before, and some parts of the picture are not being erased but stay there.

    But far worse in game now the grass, and trees flickers.
    I will talk to AlanL again first, but I am afraid I already know his answer.

    I remember someone asking about the grass flickering, and if my memory serves me right, his answer was, that's amd (vid card) for you....
    Of course I will see what he says first.

    If it is my vid card driver, thanks to Valve we have a place to report these problems.

    ( currently using catalyst 13.2 beta 6 )
    There is a beta 7 ....

    [cynical] Don't we love the proprietary amd drivers? [/cynical]

    Reinstall the game and the amd drivers is something I could try.

    To end positive, I still very happy with the help I get here.
    The graphic issues have nothing to do with the command Henk gave me.
    (although wack a mole comes to mind)

  8. #8

    Default Re: Problem with greb lspci, and serious sam3

    Hello,

    Did you make sure you had disabled CPU scaling in bios (and CoolNQuiet or powerNow)?

    The Serious Sam 3 release notes mention this as a key performance issue. The commands to grep for settings in

    /sys/devices/system/cpu/cpu0/cpufreq/

    do not actually change anything, they merely report the current setting which can be changed, however this typically requires changing multiple settings (such as the governor being used, etc.)

    There is also:

    /etc/init.d/cpufreq

    An easier approach is to disable in BIOS.

    Of course, your video drives also also key. In my case I found that until I had completely disabled scaling in BIOS SS3 ran very poorly indeed.

    For other general trouble shooting, SS3 in steam logs to:

    ~/.local/share/Steam/SteamApps/common/Serious Sam 3/Log/Sam3.log

    Happy alien hunting.

    Lews Therin

  9. #9

    Default Re: Problem with greb lspci, and serious sam3

    The first problem I had with SS3 was in game. In some areas the fps would take a dive.

    This was solved by installing cpu frequency utilities.

    Changing the kernel setting from on demand to performance.

    I also disable cool and quiet in the mobo, but I did not notice any change, so switched it back on.

    The developer confirmed that the game now does detect my hardware, so we made progress.

    He asked for a new log file, he suspects driver issues, and I am waiting for his reply on the new log.
    The difference I noticed there were some lines, who had unknown before, but now state my gpu.

    If I overlook the flickering, the game runs better. First I saw when turning around, the game engine drawing stuff close to me. this is gone or has at least improved to a point I am very happy with.

    I am a gamer for years and since, I made a few maps myself, I notice more things then before.
    From my experience, I am guessing there is a problem with textures with an alpha mask ( semi transparent)
    That' s how grass and leaves on trees are done in games.

    Off topic
    For those curious (the game is Aliens vs Predator 2)

    =arc=factory - YouTube

    and a vid of a mod for Avp2.
    The Enterprise (from start trek) in the vid is made by me.
    From 4.20 till 7.10 you see the enterprise from star trek.
    2010-04-24_ytb.avi - YouTube

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •