VIA Technologies, Inc. VT8623 [Apollo CLE266] - xorg with openchrome segfaults
 

My video card on an old VIA-based system is not getting configured properly. The card is VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03).

Linux distro/version and kernel version:
Slackware 14.0
Linux trippy 3.2.29 #2 Mon Sep 17 14:10:59 CDT 2012 i686 VIA Samuel 2 CentaurHauls GNU/Linux
vendor_id : CentaurHauls
cpu family : 6
stepping : 3
model : 7
model name : VIA Samuel 2
cpu MHz : 799.014
cache size : 64 KB
cpuid level : 1
bogomips : 1598.02
clflush size : 32
MemTotal: 469872 kB
MemFree: 10460 kB

I tried configuring X with the xorgsetup program, resulting in an xorg.conf file which looked reasonable to me, but the openchrome driver crashes during initialization with startx.

I then added some modifications to xorg.conf, like

Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
Option "DPMS"
HorizSync 28-51
VertRefresh 43-60
EndSection

and

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 1
Modes "1024x768" "800x600" "640x480"
EndSubSection
... on to "Depth 24".

but, looking at the end of /var/log/Xorg.0.log,there is a segfault:

[ 96846.932] (II) CHROME(1): VIAGetRec
[ 96846.932] (**) CHROME(1): Depth 24, (--) framebuffer bpp 32
[ 96846.932] (==) CHROME(1): RGB weight 888
[ 96846.933] (==) CHROME(1): Default visual is TrueColor
[ 96846.933] (--) CHROME(1): Chipset: CLE266
[ 96846.933]
[ 96846.933] Backtrace:
[ 96846.934] 0: /usr/bin/X (xorg_backtrace+0x49) [0x81b54b9]
[ 96846.934] 1: /usr/bin/X (0x8048000+0x170d26) [0x81b8d26]
[ 96846.934] 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xffffe410]
[ 96846.934]
[ 96846.934] Segmentation fault at address (nil)
[ 96846.934]
Fatal server error:
[ 96846.934] Caught signal 11 (Segmentation fault). Server aborting
[ 96846.934]

I can attach the xorg.conf and Xorg.0.log files etc, if necessary.

This system formerly ran some old versions of Ubuntu and recently Debian 6.0 with no problem, also with an openchrome driver. I have another similar system which still runs Debian 6.0. with the openchrome driver.

If not already done I suggest you fallback to vesa till you solve the issue with openchrome. As root:
(1) "mv /etc/X11/xorg.conf /etc/X11/xorg.conf-openchrome"
(2) "cp /etc/X11/xorg.conf-vesa /etc/X11/xorg-vesa.conf"
(3) startx

xorg.conf and Xorg.0.log
 

Thank you, Didier! For some reason, this didn't work. Here are my xorg.conf file and resulting Xorg.0.log file.

I am using what I believer to be the original xorg.conf.vesa file. I had tried various xorg.conf files, including one generated by booting the live slax CD - even though that is based on an earlier slackware version.

By the way, the slax live CD did boot and display X.

Perhaps I failed to install something crucial for running the vesa driver.

Go into the BIOS setup and ensure that you've allocated enough RAM to the VGA - 32MB is usually enough, but anything below that and you might have problems.

It seems vesa can't be used because your GPU is already claimed by a conflicting kernel driver, as says the X log:
Please provide lsmod's output so we know which one it is. Then we will simply blacklist the involved driver and you should be able to start X. There is no point in tweaking your xorg.conf file, its settings are not involved in this issue.

So simply type:

and append lsmod.txt to your next post.

EDIT In addition, type:
and append lspci.txt to your next post.

Looks like here's the problem - thanks, Didier!

# lspci -k | grep -A3 VGA
01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03)
Subsystem: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics
Kernel driver in use: vt8623fb

I also attached the basic lsmod ouput.

I don't think there's a BIOS memory allocation problem, as someone suggested - this system has run several Linux distros, including the latest Debian, with no display problem, usually with an openchrome driver.

The via8623 driver is possibly the manufacturer's driver, distinct from both vesa and openchrome.

So, how do I blacklist the offending driver?

Peter

vt8623fb is a kernel module included in the kernel, not a proprietary driver

My guess is that it is loaded at boot simply because it is intended for your chipset. It is easy to check. If you issue the command "modinfo vt8623fb" you will get this:I have put in bold the vendor Id and the Device Id. My guess is that if you type this:
you will see this at the end of the output:This would confirm that.

But another kernel module, viafb, could be used for your chipset, as it has, among others, the same alias line as vt8623 (you can check typing "modinfo viafb", it is the last alias line).

About vt8623fb, the help text in kernel's configuration says:
And about viafb:It happens that your chipset includes both a VT8623 and a CLE266 devices as shows the block diagram on this page. So one would think that both vt8623fb and viafb modules be loaded, but this is not the case as the output of lsmod shows, probably because the kernel can handle only one frame buffer driver at a time.

Long story short, type this as root:then reboot and start X.

You should have X working now.

In addition, if I am correct it was probably not necessary to use vesa instead of chrome as I suggested in my previous post. To check that you can try to revert the switch in X configuration files after blacklisting vt8623fb. In fact if simply blacklisting vt8623fb don't work you can either try to use the X config file for chrome or blacklist viafb as well as vt8623fb.

Please inform us of the outcome, whatever it be.

PS To clarify a bit you need two kinds of drivers for your video card to use it under X: a kernel driver and a driver for X.

Thank you! I set up blacklisting as you describe, and eventually the Xfce screen came up (meanwhile, I ssh'd in from another computer, ran 'top', and saw that X was taking about 98% of the CPU. It took 2-3 minutes - I left the room and came back. The screen res. was 1024x768.

I'll try with openchrome a bit later this evening. Also I should look at memory usage during startup - perhaps there was some swapping involved.

- Peter Belew

Partial status update: I tried reverting to the 'original' xorg.conf, which loads the openchrome and vesa drivers, apparently, and again got a segfault. I have not changed blacklisting yet, however. So I'll try various other changes, including blacklisting, tomorrow or on the weekend.

I'm attaching Xorg.0.log.old from trying openchrome.

The problem is partially solved in the sense that I can use the framebuffer vesa driver, but that starts up REALLY slowly.

According to this page your card is well supported by the openchrome X driver.

I would start again from the beginning.

(1) Delete your X config file. None should be needed.
(2) Do not blacklist openchrome. Delete the file /etc/modprobe.d/blacklist-vt8623fb.conf
(3) Reboot
(4) start X

I something don't go well, send your lsmod and X log.

PS I assume you made a full Slackware 14 installation, without anything coming from elsewhere.

I removed xorg.conf from /etc/X11, and removed the blacklist file from /etc/modprobe.d, then rebooted, logged in, and ran startx. The same thing happened.

I have not installed anything from outside the slackware 14 distro. I did skip some packages or groups, possibly something was omitted, like some kind of framebuffer driver? For text mode, I'm not using a framebuffer, but I suspect that's unrelated.

I'm attaching the Xorg.0.log and lsmod.txt files.
Also, I'm attaching the same files, and xorg.conf, from the Debian 6.0 system running on another computer with the same VIA hardware, in a following reply.

Here are the files from Debian 6.0 on similar hardware:

In Debian's lsmod the "via" kernel module shows, so try to do this :
(1) blacklist again the vt8623fb kernel module
(2) after reboot, type "modprobe via" and check that the via module be loaded
(3) start X

It should work even with no X config file. In case of a problem try the same steps with the xorg.conf-debian as xorg.conf (only because your card do not support a resolution higher than 1024x1024, but xorg-server should be smart enough to detect that, shouldn't it?).

Aside from that your Slackware 14 lsmod shows that a lot less modules are loaded than with Debian - and with my Slackware 14 as well, as shows my attached lsmod file.

So my question is: which kernel do you use? Did you configure it yourself, or may be it is a huge-smp one? In any case install the stock generic-smp included in Slackware 14 instead. You will need to make an initrd , see /boot/README.initrd for instructions.

Last word: with Slackware, making a full install (apart from the KDEI series) is highly recommended, unless you have very few space on your hard disk.

Thanks, I'll try that later today.

This cpu won't run the smp kernels. I'm running the 'huge' kernel, I believe - this works on this via Samuel 2 cpu.

I see you must be using an nvidia card - with the nouveau driver.

Peter

To check which kernel you are running:If you are able to run a huge kernel you are able to run à generic of the same "kind" (i.e. smp or not) anyway, so you certainly can install a generic kernel. Yes I am using a nVidia card but this is not the point. I have way more kernel modules loaded, video ones aside, that what puzzles me.

I installed slackware with the huge kernel - huge-smp won't run on this system.

I did try the instructions in #14 - blacklisting vt8623fb, modprobe via after a reboot, running with no xorg.conf or the one from the system running Debian 6. Again, I got the segfault.

I need a little prompting about how to install the generic kernel and make sure it doesn't affect the installation of the huge kernel, and I want to set up lilo so I can choose either kernel at boot time. (I know if I can do that, I can make either one the default kernel).

And, for the generic kernel, will I have to download the various necessary kernel modules?

There don't seem to be as many prebuilt kernels on the slackware 14 CDs as there were a few years ago, and not many on the ftp site(s) either.

I'm attaching the latest Xorg.0.log, from using the xorg.conf which worked on Debian.

Peter

I found the documentation for slackpkg and for installing the generic kernel (with modules etc.).

This does not appear to help.

I'll look at this more tomorrow.

As for uname -r, I found that uname -v provides further information for distingushing the huge and generic kernels - for the generic kernel, uname -v gives:

#1 Mon Sep 17 13:26:41 CDT 2012

I think the huge kernel version starts with #2.

Sorry, no more clue. If I search Google for: chrome(0) chipset cle266 segmentation fault I find some interesting threads, including one I did some input in, but if I add linux-gate.so.1 as a search argument I only find the present thread.

You could try the proprietary Unichrome driver instead on Openchrome. I don't know if that will help.

My best advise would be to switch to an older X stack (this thread makes me think that, though the backtrace mentions vdso, not linux-gate.so.1). The easiest way to do that is probably to install an older version of Slackware instead of Slackware 14.

Well, that's too bad, given that Debian 6 works fine with its openchrome driver, and the Slax live CD does too - I forget which slackware version it's based on; I suppose I could check that and try the corresponding slackware version.

Thanks though, for all your help! I've learned a bit about slackware. I have a LAMP server set up on this system, which works fine. I'm getting used to figuring out all the weird ways various distros set up the Apache2 config files: Debian, RedHat, Slackware, FreeBSD, NetBSD. Maybe I'll try slackware 14 on another old system, maybe one with an older AMD cpu, and see what I can do with that.

Peter

According to this thread linux-gat.so.1 is a vdso anyway.

Other than that, Slax 6.1.2 includes xorg-server-1.6.3 which is included in Slackware-13.0 as well. So you'll probably be safe installing Slackware 13.0.

But as Debian 6 ships xorg-server-1.7.7 included in Slackware-13.1 you could try Slackware-13.1 as well.

This occurred to me last night: was the openchrome driver for slackware built for i686 or for i486? If it was built for i686 it might well fail since the VIA Samuel 2 CPU does not have the CMOV instruction.

Ubuntu was building its '686' version without CMOV (different config flags) until a couple of years ago, so then I had to switch to Debian on this system and its twin.

Peter

Thanks, Didier - I'll probably try 13.1, in that case. I suspect my guess about the 14.0 driver being built only for i686 is wrong, but who knows?

If 13.1 supports ext4, I can probably get by keeping my /home partition, as I often do when I do an upgrade or when changing distros, that would be best!

- Peter

I assume that in Slackware 14 all X drivers are built for arch=i486 by default.

Anyway I think that optimizations depending on the processor type are made only at the kernel's level, not for X drivers.

In Slackware 13.1, ext4 is provided as a module in -generic, built-in in -huge.

I installed 13.1 in the same system, and managed to install all the LAMP components as usual. I set up the same web pages that I had before, with some additional feature, using php and MySQL.

I set up xfce, using the openchrome driver. By default, this came up in 800x600 mode; so I'll try using an xorg.conf file to change this. One problem is that it had neither a top nor a bottom panel, and the utility for setting up panels would not run, so I have to depend on launchers on the screen background and the righ-click pop-up menu. I did install all the X software for this version from the CD's, so I hope there is some upgrade.

The version of Firefox which comes with this over-2-year-old firefox is also very old, so I have to see if I can upgrade this a bit.

Now I have to figure out upgrades etc. for 13.1

An easy way to apply all security patches available for Slackware 13.1 is to use the slackpkg utility, see "man slackpkg". The Changelog for Slackware 13.1 will tell you all recommended updates/ upgrades since release date that slackpkg can deal with.

Other than that you can upgrade what you want using the SlackBuilds provided in the /source directory to make yourself a newer Slackware package if you wish. Personally I would only do that if I really need to upgrade a specific package but hey, that's your system ;)

Hi Didier -

Now I have the 13.1 slackware updated, and also I added the xorg.conf file from my twin VIA system (running Debian 6), in order to get 1024x768 resolution.

This works fairly well - it did come up with a panel at the bottom, which I set to autohide.

A major problem is that there are bugs in switching to text consoles with control-alt-Fn keys, and back again. The first few consoles (1-3 maybe?) don't work as expected, and switching back with Alt f7 or Alt f8 results in a partially-working screen with no panel or with a panel with nothing on it.

Another problem is that I should have tried to enable some old config files, or just all the old ones - the worst problem is that I had to reconfigure Apache over again. Not a big problem because I can practically do that automatically, having done that on various systems many times. What happened is that I went away while updating, and I had to go back and decide whether to use new config files.

If I had time, I'd reinstall version 14, and then file a bug with openchrome.org - I did that a couple of years ago, with openchrome on a laptop which always came up in too high a resolution.

Thanks again,

Peter

hi,
after having similar issues (segfault / high cpu load), i investigated a bit. for me the unichrome xorg driver works nicely: unichrome.sourceforge.net

i've also made a slackbuild for this: slackbuilds.org/repository/14.0/system/xf86-video-unichrome/ .

i hope that helps :)

PS: sorry for the not linked links, seems to be a linuxquestions rule for the first post..