Xorg troubles with VIA CLE266 graphics

English Hardware
1

Hello world,
I think I just discovered some solution to problems related to VIA EPIA ITX Mainboards that kept me busy over the last months:

Hardware:
VIA EPIA itx mainboard with VIA C3 Samuel 2 CPU @600MHz
RAM 1GB
Graphic Chipset CLE266

Software:
OpenSUSE 12.2, i586
Grub 0.97
Xorg 1.12.3
LXDE

There were three problems in getting this system to run a desktop:

  1. Booting the netinstall-CD

Simply hit “esc” when booting starts. You get a command prompt and you can start the installation in text mode. Be aware that you need an i586 kernel!

  1. Booting the installed system

In the first place, the system never reached the grub2 menu, but rebooted instead when it tried to load grub2. I could sit and watch that cycle repeat for hours. Installing grub0.97, setting it to text mode and booting to runlevel 3 solved this problem.

  1. Starting Xorg

In runlevel 3 everything was fine and the pc was fast, but every time I tried to startx, Xorg started and crashed immediately with some kind of error message like “Fatal server error: Caught signal 4 (illegal instruction)” and further up “/usr/lib/dri/swrast_dri.so” was part of this crash. Must have been some type of acceleration problem.

I tried different xservers, different graphics drivers, creating an xorg.conf file by hand, modprobing viafb and vt8623fb and launching sax3, but none of them showed any success. Forums said something about faulty bios framebuffers, others recommended not to use the unichrome driver. But as AntiX i486 could boot to an IceWM desktop, it must have been a bug in my Xorg configuration.

Finally I stumbled upon this post:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-openchrome/+bug/247071
which almost at its end recommends to disable some modules in the xorg.conf file which reduces hardware acceleration to zero, but helps.

So I edited /etc/X11/xorg.conf.d/05-glamor.conf by deleting the two “load” lines and adding a line which said: Disable “glx”

Section “Module”
Disable “glx”
EndSection

and started Xorg as root with startx and it worked!!! Incredible after all those efforts, even though there’s no hardware acceleration now.

So enjoy that solution if you have got one of those EPIA boards!!!

By the way, does anyone know a workaroud to get get at least some 2D acceleration?

2

What driver are you using ? The one included in xorg? There is mention on the openChrome wiki that the xorg supplied driver “is now deprecated and will not work with recent Xorg releases anyway”. Speaking of which, have you tried the openChrome driver?

As for acceleration, use EXA

3

I use the xorg-x11-driver-video-unichrome as included in the openSUSE release. My 50-device.conf file is set to load the unichrome driver. Back home tonight I will try to install the openchrome driver and I’ll play around with EXA.
Thanks :slight_smile:

4

Okay, lets us know how it works out

(PS – you might want to poke a mod and ask them to move this thread into the hardware forum; which specifically deals with such driver related issues)

5

The unichrome driver needs Disable “glx” and if I add Load “EXA”, LXDE seems to load faster, but still no smooth scrolling in midori.
I installed the openchrome driver from the X11:Drivers:Video repository - it is indeed marked as unstable and enabling it even without any acceleration it makes Xorg crash upon startup.

By the way I noticed that I have the viafb module enabled all the time which is shipped together with openSUSE 12.2.
According to that (outdated) howto Video in section 6.2.2 viafb was troublesome if you built it from source (but viaarena.com neither cares about old hardware nor about recent operating systems). This doesn’t seem to be relevant any more. Maybe one day I’ll test those suggestions: Setting viafb and xorg manually to use the same screen resolution and colour bit depth.

When blacklisting viafb and loading vt8623fb instead, nothing seems to change, the overall desktop experience stays the same: quite laggy when moving windows or scrolling.

Blacklisting both modules is a bad idea - upon startin X, my optical usb-mouse flickers and takes some time to get comnfigured and scrolling is almost impossible. When looking into 05-glamor.conf, EXA ist automatically disabled - xorg must be really clever! And openchrome still crashes the Xserver.

Finally, I decided to stick to viafb, Disable “glx”, Load “EXA”, Driver “unichrome”. Additionally I reenabled Load “dri2” and Load “glamoregl” as they do not crash X. LXDE is working fine, the overall desktop experience is okay and graphic performance is sufficient for my purpose - this machine is going to run lemonpos as a point of sale system. Maybe I’ll compile a specific CyrixIII/ViaC3 kernel to get more cpu performance, but this is a different story.

(PS. How do I get this thread moved to the hardware forum? I guess I have to find a forum administrator who’ll do that for me.)

6

To get thread moved, pick one of the Global Mods (See low down on home page - View Site Leaders) currently online and send a private message requesting the move.

7

Okay, you’ve got so much in there, and I don’t have time right now to try to address things point by point, so I will try to provide a over view:

  • the (old) framebuffer drivers are for the console framebuffer and don’t have an impact on X
  • that said, certain fb drivers can negatively impact upon X drivers operation, and in turn impact your X environment… you will often see X driver documentation say “don’t load this or that fb driver” … caveat emptor as they say. So you will have to figure out which fb driver is applicable to load
  • I suspect that if you blacklist those two fb drivers, you end up with the vesafb driver (also note that vesafb and vesa are two different things; fb and X driver respectfully … I only mention it because it seems to be a general confusion) … are you using kernel boot parms? (i.e. vga=xxx) that would very likely result in the vesafb
  • if you have user supplied xorg configurations (i.e. xorg.conf or the xorg.conf.d/xx-files), then some of them may conflict with the openchrome driver, causing it to crash (this is where parsing your xorg log also comes in handy) … same with what I said about fb drivers … make sure you are not using one that would conflict with openChrome
  • glamor is not used by Via stuff … presently only intel and the newer radeonsi driver do, and I think optionally the radeon driver … I suspect (though could be wrong) that its only for KMS drivers … meaning your UMS Via driversf need not apply :stuck_out_tongue:
  • you want to get glx working
8

OK , I’m going to move this thread form where it is currently (in applications) to the hardware forum area. NNTP users, you will be able to find any continuation of this thread in “hardware” under the same thread title. I do ask that no one post on this thread until it is moved (it should take less than 1/2 hour - I need to wait for this notification post that I am typing now to get out through the NNTP gateway, before I move the entire thread). I will reply to the main post in this thread, after this thread is moved, so that it can be found by NNTP users.

9

[/QUOTE]
[/QUOTE]
[/QUOTE]

This thread has been moved from ‘applications’ area to ‘hardware’ area, per user request. While I have tried to quote all the salient posts to make this easier for NNTP users, for same NNTP users if you believe something is missing, you can find the original thread under ‘applications’ area by the same name.

This thread is now reopened to all for posting. Thank you for your patience during the move.

10

The basic driver to first try when you change something is “fbdev”, now packaged and usually installed by default on 12.2 as this package: xf86-video-fbdev. Tell us how that works.

Next up, but still basic performance-wise is the “vesa” driver packaged as xf86-video-vesa. I think you mentioned you tried that at some stage.

I have a now very old desktop pc with a Via graphics chip (K8M800) which I managed to use since openSUSE 10.1 (not with 12.1 or 12.2), but not in use now unless I replace the monitor. It was time-consuming work, as in my experience openSUSE came up short in providing driver support for Via graphics hardware, especially wrt Direct Rendering Infrastructure (DRI) and hardware acceleration. It was always incorrectly configured with useless mode setting parameters, etc etc. However as openSUSE releases changed, the “fbdev” driver almost always worked, although the performence and screen resolution was not great. Sometimes the “vesa” driver didn’t work.

As far as “openchrome” driver goes, I had more success with PCLinuxOS and Kubuntu, and that was the leading driver, although not included officially in openSUSE releases. It was the best driver I used, relying on one or two users’ packages on the Build Service. However that packaging became more of a lottery wrt unreliabilty say around 11.3 to 12.1.

The “unichrome” driver lagged behind in development, due to the developer’s limited hardware for testing. That’s still a problem for unichrome, but it eventually improved in quality, and was later included in openSUSE releases, when the Xorg driver became deprecated, and IIRC the developer worked for Novell for a while. This driver worked on some releases, some it didn’t.

I would NEVER use the proprietary or closed-source graphics drivers produced by VIA. They are poor quality and vulnerable to attack.

Eventually Via actually tried to embrace open source (not just pretending to in press releases), failed in their efforts to produce a working 3D driver, and gave up!

11

Hmm, KMS versus UMS? Openchrome’s driver xf86-video-openchrome 0.3.0 was releasedby them back in July 2012, with UMS and KMS support. I think 0.3.1 is now available.

Why only for KMS drivers? Currently glamor needs to be embedded in a 2D DDX driver (e.g. xf86-video-intel). Don’t see any sign of that yet for openchrome’s DDX.

12

Right your are! I had forgotten about that. I no longer really pay close attention to the Via stuff – I gave up on them several years ago. I wish the openChrome folks well with their endeavours, but Via itself could fall off the face of the earth and I would care less. Though their chipsets tended to be buggy, they did indeed work for the most part, and they were a viable option for a while back in the early '00s. I tend to think they had a good opportunity to run with it (so to speak) with the mini-ITX platform, but that they really, really blew it by failing to open up on the driver front. But that’s just hindsight talking and who knows, the outcome might not have been any different then had they actually embraced the OSS pathway (though it certainly seemed like there was considerable consumer demand, and likely commercial too). Nowadays they’re almost like an after thought – its like I think “you mean they’re still in business?” every time I see something about them. Who knows, maybe their ARM stuff will be successful, but I think they are falling into an arena that is increasingly becoming highly competitive and provides low margins (i.e. commoditized hardware).

Anyway, I digress into personal diatribes. As for some content that is pertinent to the thread, there appears that there currently are some important considerations that must be taken when it comes to using the openChrome: see [Phoronix] VIA’s OpenChrome 0.3.0: “A Major Step Forward”](VIA's OpenChrome 0.3.0: "A Major Step Forward" - Phoronix)

[Background posts:
[Phoronix] VIA KMS + TTM/GEM Driver Moves Along Without VIA]
[Phoronix] VIA Kernel Mode-Setting Code Might Merge Soon](VIA Kernel Mode-Setting Code Might Merge Soon - Phoronix) ]

I think 0.3.1 is now available.
I’m ignorant, but I’m sure the openChrome m/l would provide the answer.

Hmm, KMS versus UMS? … Why only for KMS drivers?
I don’t know, though I suspect that glamor is written/designed for a modern stack, DRM in particular.

Currently glamor needs to be embedded in a 2D DDX driver (e.g. xf86-video-intel). Don’t see any sign of that yet for openchrome’s DDX.
Well, its (now) a shared library, but a driver has to be (i) capable of supporting glamor acceleration and then (ii) built with that option enabled. On top of that, you have the mesa build requirements. Then you have to evoke glamor accel accordingly in xorg.

glamor isn’t anything special (it is the worst performing method for intel hardware for example), but it can make sense (like in the case of using it with radeonsi, which doesn’t have a DDX) or maybe even beneficial in the case of others (like with the radeon driver, as its EXA performance isn’t great, and early comparisons show using glamor to be about on par with EXA with it). Other drivers will have to evaluate if there is any benefit

13

:slight_smile: I could have written that, at least with the same sentiment. Via’s low-budget chip on an inexpensive Asus motherboard suited me at the time. In a way, openSUSE lost many users of such hardware sticking with Windows or other distros. Made sure my notebook had integrated Intel chipset graphics, and also after not paying much attention for a year or so, except occasionally checking openchrome website. So good of you to post that Phoronix link, which I haven’t seen:

glamor isn’t anything special (it is the worst performing method for intel hardware for example) … Other drivers will have to evaluate if there is any benefit

That’s a pity for intel h/w. Hmm, is it falling back too often to software rendering, I wonder.

I probably need to read more carefully, but I wasn’t clear from glamor’s web page if the Mesa-owned 3D driver component was still involved (if glamor is doing the hardware acceleration and all)? For unichrome chips that is the unmaintained and regressed unichrome_dri.so, also buggy allegedly with lockups on my K8M800.

14

[quote=“consused,post:13,topic:84337”]

Phoronix link, which I haven’t seen[/QUOTE]Adding to that (my subconscious must have been working overtime, cause out of the blue last night (while at the gym of all places), I got this thought that I had seen something related to this very recently), I checked this morning and it would seem that the openChrome DRM/KMS work will still reside outside the kernel for the near term future (see very bottom of page: [Phoronix] Features On The Horizon For The Linux 3.8 Kernel](Features On The Horizon For The Linux 3.8 Kernel - Phoronix)).
.

That’s a pity for intel h/w.
Meh, its just another alternative for them, or can assist them in early stage development for future adapters. In any regards, UXA currently betters glamor, and SNA, UXA’s intended replacement, trounces it. SNA is very good and is the future.

Hmm, is it falling back too often to software rendering, I wonder.
I believe it is largely a case of inherent inefficiencies in the translation from Render commands to OpenGL and the fact that the mesa drivers are not optimized for 2D work.

I probably need to read more carefully, but I wasn’t clear from glamor’s web page if the Mesa-owned 3D driver component was still involved (if glamor is doing the hardware acceleration and all)?
Mesa drivers very much involved! The glamor library translates the 2D render commands into GL commands, and the (3D GL) mesa drivers go to town on that … but as implied, by being 3D drivers, they aren’t particularly tuned for 2D work.

15

I’m back again testing desktop performance! Great to see that this thread has come to life =D

Both viafb and vt8623fb are blacklisted, all kernel boot parameters have been removed and all manual changes in the /etc/X11/xorg.conf.d/ have been removed, both unichrome and openchrome are still installed. To disable KMS, nomodeset was added as a boot parameter again.

**Setting 50-device.conf to fbdev and typing startx:
**

Fatal server error:no screens found

(Disable “glx” doesn’t make any difference.)
How do I fix that? But testing goes on…

**Whereas if I use vesa, **X is starting and starting and starting, the machine gets stuck at a colourful screen but crashes:

X.Org X Server 1.12.3
Release Date: 2012-07-09
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux lemonpos 3.4.6-2.10-default #1 SMP Thu Jul 26 09:36:26 UTC 2012 (641c197) i686
Kernel command line: root=/dev/sda3 nomodeset
Build Date: 15 October 2012 09:39:02AM

Current version of pixman: 0.24.4
Before reporting problems, check X.Org Wiki - Home
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: Fri Nov 2 16:45:18 2012
(==) Using config directory: “/etc/X11/xorg.conf.d”
(==) Using system config directory “/usr/share/X11/xorg.conf.d”

Backtrace:
0: X (xorg_backtrace+0x49) [0x81bc9c9]
1: X (0x8048000+0x178636) [0x81c0636]
2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb76fa410]
3: /usr/lib/dri/swrast_dri.so (_ZN4llvm13StringMapImpl15LookupBucketForENS_9StringRefE+0x75) [0xb645bb15]

Illegal instruction at address 0xb645bb15

Fatal server error:
Caught signal 4 (Illegal instruction). Server aborting

Please consult the The X.Org Foundation support
at X.Org Wiki - Home
for help.
Please also check the log file at “/var/log/Xorg.0.log” for additional information.

waiting for X server to begin accepting connections .
…
…
…
…
…
…
…
…
…
…
…
…Server terminated with error (1). Closing log file.

xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

If I Disable “glx” and use vesa, X starts and the machine gets stuck at a blank screen, not responding to any keystrokes. I almost pressed the reset button, but after a minute or so, the openbox-session started - great! However, tty1 is the only virtual console I have access to, the others are covered in colourful patterns.

Selecting unichrome (glx will remain disabled from now on):

Backtrace:
0: X (xorg_backtrace+0x49) [0x81bc9c9]
1: X (0x8048000+0x178636) [0x81c0636]
2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb77d2410]
3: /usr/lib/dri/swrast_dri.so (_ZN4llvm13StringMapImpl15LookupBucketForENS_9StringRefE+0x75) [0xb4cceb15]

Illegal instruction at address 0xb4cceb15

Fatal server error:
Caught signal 4 (Illegal instruction). Server aborting

Selecting openchrome:

Backtrace:
0: X (xorg_backtrace+0x49) [0x81bc9c9]
1: X (0x8048000+0x178636) [0x81c0636]
2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb77d6410]

Segmentation fault at address (nil)

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

**Rebooting without any kernel parms,**​ and thus KMS enabled, X and openchrome print the same crash report, but unichrome works!!!

As consused said, openchrome 0.3.0 was released a few months ago, but it has not been packed into a repository yet. The one I installed is a 0.2.9 - I wonder how much work it would be to build the new driver from source, but waiting until it there is a driver package for openSUSE seems to be easier for me.

16

No need to disable KMS, since KMS support shouldn’t be there for openchrome, unichrome, or any VIA, just the three graphics vendors mentioned in the release notes.

**
Setting 50-device.conf to fbdev and typing startx:
**(Disable “glx” doesn’t make any difference.)
How do I fix that? But testing goes on…

That’s disappointing. It will only support resolutions 800x600 and 1024x768 (IIRC). Depends what’s shown in Xorg.0.log as to remedy if at all.

Selecting openchrome:
**Rebooting without any kernel parms,**​ and thus KMS enabled, X and openchrome print the same crash report, but unichrome works!!!

Hmm, KMS should have no effect! That X/openchrome error giving a segmentation fault… I’m trying to remember about my last install on my desktop PC (VIA K8M800) before it got sidelined many months ago. I have a recollection that I had same as you and abandoned openchrome driver (on openSUSE 11.4) due to similar crash, but unichrome worked. Anyway one of them worked and the other didn’t.

That wouldn’t surprise me, as the unichrome developer is familiar with openSUSE and/or SUSE and has some VIA hardware so will test his package, whereas the openSUSE packager doing openchrome may not have access to VIA hardware so mightrjust rely on bug reports. The openchrome driver in X11:drivers:video is at release 0.2.906, and someone has filed bug “#435 system freeze when X starts” at openchrome website.

You could also try another openSUSE Build Service version (from a user and frequent poster here on the forum) for 12.2, e.g. home:martin_helm has packaged 0.2.905. Use this link to 1 Click Install here

17

Seeing Malcolm’s post about glamor in another thread reminded me of some very recent info related to this thread.

But first a correction to something that I wrote earlier:

radeonsi DOES have a DDX; specifically, the “radeon” driver (radeon_drv.so … i.e. that provided by xf86-video-ati). The catch is that the radeon DDX doesn’t have within it any SI (which refers to the “Southern Islands” generation of AMD graphics adapters i.e. 77xx and greater) specific 2D accel code. That is where evoking glamor acceleration steps in — the 2D rendering is accelerated within X via OpenGL (i.e. Mesa). So, for SI hardware, that means the acceleration gets done via the gallium radeonsi driver*. For an earlier card arch., like say a 58xx, it’d be the r600g driver … and so forth.

  • Problem: I see no evidence that openSUSE has picked up/included the radeonsi in its mesa package. Boo to that.

Now in regards to the recent VIA related news stuff; see: