FS#26015 - [stellarium] Immediate segfault on intel 82865G
Attached to Project:
Arch Linux
Opened by René Herman (rene) - Wednesday, 14 September 2011, 19:36 GMT
Last edited by Andrea Scarpino (BaSh) - Tuesday, 07 February 2012, 08:17 GMT
Opened by René Herman (rene) - Wednesday, 14 September 2011, 19:36 GMT
Last edited by Andrea Scarpino (BaSh) - Tuesday, 07 February 2012, 08:17 GMT
|
Details
Description: I just now installed "stellarium" (0.11.0-1,
via pacman) but the only thing it does is put up its
splashscreen before segfaulting. The system is fully up to
date.
Additional info: * package version(s) stellarium-0.11.0-1 * config and/or log files etc. $HOME/.stellarium/log.txt: === 2011-09-14T21:23:25 Linux version 3.0.4-e600+ (rene@e600) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #2 SMP PREEMPT Fri Sep 2 20:31:35 CEST 2011 Compiled with GCC 4.6.1 Qt runtime version: 4.7.4 Qt compilation version: 4.7.3 Addressing mode: 32-bit MemTotal: 1024644 kB MemFree: 765676 kB SwapTotal: 2097148 kB model name : Intel(R) Pentium(R) 4 CPU 3.00GHz cpu MHz : 2992.523 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz cpu MHz : 2992.523 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Kernel driver in use: i915 stellarium ------------------------------------------------------- [ This is Stellarium 0.11.0 - http://www.stellarium.org ] [ Copyright (C) 2000-2011 Fabien Chereau et al ] ------------------------------------------------------- Writing log file to: "/home/rene/.stellarium/log.txt" File search paths: 0 . "/home/rene/.stellarium" 1 . "/usr/share/stellarium" Config file is: "/home/rene/.stellarium/config.ini" OpenGL supported version: "1.3 Mesa 7.11" Qt GL paint engine is: "OpenGL" Cache directory is: "/home/rene/.cache/stellarium/stellarium" Sky language is "en_US" Application language is "en_US" Loading Solar System data ... Loaded 63 / 63 planet orbits from "/usr/share/stellarium/data/ssystem.ini" Loading star data ... "Loading "/usr/share/stellarium/stars/default/stars_0_0v0_1.cat": 0_0v0_1; 5013" "Loading "/usr/share/stellarium/stars/default/stars_1_0v0_1.cat": 1_0v0_1; 21999" "Loading "/usr/share/stellarium/stars/default/stars_2_0v0_1.cat": 2_0v0_1; 151416" "Loading "/usr/share/stellarium/stars/default/stars_3_1v0_0.cat": 3_1v0_0; 434064" Finished loading star catalogue data, max_geodesic_level: 3 navigation/preset_sky_time is a double - treating as jday: 2.45151e+06 Loaded 10051 NGC records Loading NGC name data ... Loaded 222 / 222 NGC name records successfully === (at this point it segfaults) Steps to reproduce: Start it. I (only) tried setting "fullscreen" in the config file from true to false, which did not make a difference. |
This task depends upon
Closed by Andrea Scarpino (BaSh)
Tuesday, 07 February 2012, 08:17 GMT
Reason for closing: Upstream
Additional comments about closing: Report this to Intel
Tuesday, 07 February 2012, 08:17 GMT
Reason for closing: Upstream
Additional comments about closing: Report this to Intel
It seems to be related to i915_dri. I would've tried it with software rendering if I'd have seen an obvious config.ini entry for it, but that would probably workaround the issue. I suppose then that the problem is in i915_dri, but if so: I wouldn't have a clue how and where to report what, so if you could coach...
At the moment I'm expecting that it'll be a problem common to i915 users, which is to say most intel onboard graphics users (I am on a 865G system).
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Kernel driver in use: i915
Kernel modules: i915
stellarium
[edit] though I'm on 64bit so there still may be something there.
[edit2] As well as a different opengl engine...
OpenGL supported version: "2.1 Mesa 7.11"
Qt GL paint engine is: "OpenGL2"
Sorry for going on a rant but it's so frustrating. If its indeed that same intel graphics situation again, intel will have finally managed to force me towards Windows after years of getting on my nerves bigtime. I just need (really need) this stuff to work at the moment and it simply never does...
I know where you come from.... I threw my old laptop out mainly because of the intel card, though it was even a somewhat older serie than yours. I'm happy with my intel card on my laptop I bought then though... you probably can't expect the thing to work for 10 years...
[/offtopic]
I've seen some report where stellarium works when you disable dri, not sure if it is the same problem though.
(*): add 'Option "DRI" "Off"' to the "Device" section of your xorg.conf, which these days might mean you'd create a
/etc/X11/xorg.conf.d/10-device.conf
consisting of
===
Section "Device"
Identifier "Device0"
Driver "intel"
Option "DRI" "Off"
EndSection
===
and restart the system (or X at least). The resulting speed -- not just of stellarium, if you run more 3D apps -- will clearly have this solution suck donkey-testicels, but hey, at least you get to pretend that your manly Linux system then works...
Sorry, was it noticeable that I'm a bit frustrated with linux systems? It's always something. Bloody time-sinks...
In any case, I suppose this MIGHT be closed as not so much a stellarium issue but if anyone with more time and idea about how and where could coach this issue upstream, you'd be doing me and probably a few other old-intel users quite a favour. Perhaps via stellarium itself?
Jan/Andreas, any input?
intel-dri-7.11-4
libgl-7.11-4
libgl-api-7.11-4
mesa-7.11-4
fixed the immediate segfault. And broke stellarium completely. Now, with or without DRI enabled, stellarium takes 100% CPU constantly and brings both itself and the rest of the system to its knees. As mentioned above, it used to work without DRI enabled.
Thanks for fixing the segfault though ;-/
P.S.: Simply rebuilding stellarium (in the ABS way) does not help.
Without wanting to sound overly defeatist (or arrogant, or cross, or ...): you shouldn't in fact bother much with this. This same scenario has played out again and again and again over the last 5 years or so. The intel issue with older hardware is a very well-known problem, but happens again every few months when something, basically anything, is changed in the driver. This indicates that no one doing development is testing on older hardware -- and that neither they nor anyone merging their work into the kernel and/or X gives a damn.
The older hardware should be spun of into a separate driver that is made stable and then sees no further (fundamental) development. I suggested such before through various channels, but well, seeing as how as said no one actually gives a damn nothing has changed with respect to this during quite a few years now: the intel driver breaks every few releases on what is at that point in time older hardware (as a matter or pure coincidence, the group of people that keeps on breaking it work in a company that has newer hardware to sell).
In any case, as far as I'm concerned, this report can and maybe should be closed. It will not be fixed and since the only one reporting it (I see that this report has gotten no votes) just reboots to Windows when actual work needs to be done -- I'd call it a day with respect to this issue if I were you. I have.
(EDIT)