Firefox-3.5.2 Segfaults, but I don't care) & ATI video
New install slackware64 13.0. Sites that cause it to segfault are simple ones - gmail (2 seconds after I get past the sign in stage, and before I even open any email. This one also
I have done the obvious stuff - checking for missing libs with ldd, finding them, etc. Disks are 1-2 years old (ext3) and well checked, but this install has not been lived in yet. Plugins installed are: java 1.6.0_16; Flash 10.0 r45; SVG-2.26. Kernel is 18.104.22.168, made with 'make oldconfig from a very satisfactory 22.214.171.124 kernel which was faultless for some time.
The box is all-amd/ati HP6715S, with RS690 video and northbridge, sb600 southbridge. and a twin turion 2 Ghz. It is using the recent OSS xf86-video-ati drivers. The only strange Mozilla error was between 4th and 5th crash this session when it said "Input/Output Error". Otherwise the error shows as line 131 of run-mozilla.sh - the 'finally start the binary' routine.
Any ideas welcome: you're not beaten until you run out of ideas.
Try the mozilla-firefox-3.6.3-x86_64-1_slack13.0.txz package which is in slackware-13.0/patches/packages/
Got firefox-3.6.3 from heanet.ie (local mirror) and it barfs just the same :-(
This is a very new install and these are the teething problems. The other unusual feature here is that I have and am using the latest xf86-video-ati and am even getting direct rendering from a recently decent ATI RS690 video thing in the Northbridge. That's why I'm here. Because my old install of slamd64-12.2 just needs too much &#@$! work to get that running DRI, and the video was shameful.
It is shameful still, btw, but slightly less shameful.
EDIT: Found this 'cos when I started X last night, I ran
startx > x.error 2>&1
/goes off to google for that error.
/returns exhausted much later
I have DRI going. That error turned out to be in the pixman lib, because of a version problem.
So I ran and got
1. libva (source) - I forget why, but I needed it
2. pixman (pkg on slack64-current)
3. mesa-7.03 then mesa-7.8.1 (pkg) and xorg-server-1.7.7(pkg)
Then I did some reading. Before 2.4.18, libdrm_radeon wasn't automatically built, ergo the mesa package didn't have it so couldn't use it. So I had to get
5. libdrm-2.4.20 in source
6. a git clone of mesa, compiled --with-sixty-five-difficult-to-remember-options
7. kernel headers (pkg) because mesa wouldn't compile without newer headers and I removed the old ones before installing. When you have no kernel headers, kernel headers won't compile.
Then I fired up X, installed the glxinfo and glxgears from mesa that it didn't install. All the render strings said the right things, glxgears WAS SLOWED BY A FULL 100 FPS over software rendering and firefox _still_ crashes out on gmail!
/signs himself into a home for the bewildered
I believe the problem that you are running into was solved in -current with this:
Patched a bug that could cause the X server to crash.
Perhaps we need to go apply this patch in 13.0 if stock 13.0 + /patches is suffering from this bug.
A big problem is this: libdrm did not build the radeon lib before version 2.4.18 except you configured with --build-nutty-experimental-apis or the like in configure, which you guys didn't. So then you have to go round the houses, and update everything before rebuilding Mesa. The list there is missing.
5a. glproto-1.4.11 to help mesa compile.
Curiously, the other place you get libdrm_radeon.so is in the kernel headers, but you need at least 2.6.33 for a usable libdrm_radeon.so from there. So it seems you have to go around the houses and recompile anything remotely to do with video to get radeon "acceleration" which actually puts a brake on! Mind you google earth works - it doesn't throw a single error message. It will start firefox automagically (which promply crashes) and it pretends not to notice. It is bizzarre in appearance, however: I get these lines radiating into the centrepoint of the image. When I zoom, it's fine up to a point, and I'm looking at a building. I zoom more, and I get the top 25% or the bottom 75% as a reduced size photo thrown on a black background. If I have the bottom, and gradually move up, I end up with close to a horizontal line at one point out of which the top or the bottom picture will fold, depending on how I move :-/.
X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Slackware 13.1 Slackware Linux Project
Current Operating System: Linux harriet 126.96.36.199-slack13 #9 SMP Thu Apr 15 18:09:39 IST 2010 x86_64
Kernel command line: root=/dev/sda8 ro resume=/dev/sda9
Build Date: 05 May 2010 01:59:51AM
Current version of pixman: 0.16.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue May 18 11:05:41 2010
(==) Using config file: "/etc/X11/xorg.conf"
/usr/bin/X: symbol lookup error: /usr/bin/X: undefined symbol: pci_device_is_boot_vga
xinit: Connection refused (errno 111): unable to connect to X server
xinit: No such process (errno 3): Server error.
Unfortunately this is beginning to look like LFS Linux From Slackware, due to the number of compiled sources I'm using:-((. I feel a rebuild of mesa coming on. . .
By taking virtually the entire X system up to slackware64-current, I started getting somewhere. Spent a day compiling stuff, and what follows is exceptions to the above (source installs)
I meant to put in glew-1.5.4 before compiling mesa last time. glproto has to be 1.4.11 for something.
xf86-video-ati-6.9.0. This is the one to go for, or later. It's actually a hell of a lot more difficult to get compiled than 6.8.0, because it links against a lot of weirdo headers which I never found, but copied from an older system in hope.
I have mesa-7.9 development branch. If I --enable-glx-tls(which everything seems to use) my system barfs on the compile. Mesa also needs the 32 bit libs built because 32 bit programs like to use them.7.8 just _may_ be ok.
I now have 375FPS, X runs, video is A1 and firefox still crashes reliably on gmail. The curse of the seven snotty orphans on it - I'll try opera!
The end of this turned out to be
removepkg firefox (a plague on all their houses, patches, etc.)
inftallpkg qt3(thanks to an obliging 12.2 disk here)
On the video stuff, it is clear to me that I will have to compile everything into mesa and _then_ rebuild the radeon driver. I don't have enough libs updated yet to run the --enable-glx-tls mesa code I have just compiled, so when I install it I had better not have X running!
One last Epilogue:
I put the video away, and it hasn't been recompiled in a while. I tried xorg-server-1.8.1b but got a continual AllowEmptyInput disabling kbd & mouse :-/. Apparently you have to finish the ati update this way
3rd last - compile xorg-server
2nd last - compile ati video driver in 32 & 64 bit
last of all - compile mesa
so after I quit compiling, I lashed back in firefox for the laugh, and it works flawlessly. And just when I was wondering why, good old slamd64 came up with a 'quote of the day' that answered my questions, which I append for your amusement but do not take responsibility for.
|All times are GMT -5. The time now is 08:49 AM.|