Twitchy Graphical Response (and now a total lack thereof)

English Hardware
1

It’s been some time… But Hello,

So, I’ve recently installed opensuse 12.3 on a new server. It’s my first time using Suse in the past… 8 years or so; and it seems my forgetfulness has caused more issues than anticipated. Anyway, the graphics card on this box is an integrated ASPEED ast2050 chip (it’s an asus KCMA-D8 motherboard); which has a proprietary driver. Installing the driver caused the graphics to work for a small amount of time; albeit almost unusable due to the amount of lag. After a short amount of time the graphics stopped working completely; further attempts at Xorg -configure have left me with a “Number of created screens does not match number of detected devices” error. Does anyone have any idea what could be the issue here? What follows are the notes that I’ve taken for myself to maintain my sanity (and keep tabs on where I’ve looked and what I’ve done).

[HR][/HR]

So, first boot and xwindow fails to start. No big deal, I install ASPEED’s proprietary driver and move on from there. Startx works… but there is a tremendous amount of lag in the GUI (gnome). Lag, as in typing takes a few seconds to appear, things take their sweet time loading (I can physically see applications refresh, from top to bottom)… Okay, well, there was probably an issue with Xorg’s configuration. I go to close gdm before trying a standard Xorg reconfiguration and am greeted with the following error:

“error getting system bus …] The maximum number of active connections for UID 1000 has been reached”

This is weird. I check out /var/log/messages and there are a ton of errors relating to getting dbus and send messages. Additionally I’m getting system mail about a failed raid array - but smartctl reports 0 errors for all of these drives, they are brand new and seem to be fully functional. I’m going to have to get back to this in due time.

Hmm. Anyway. Restarting and booting with option nomodeset does have any effect, nor does booting in safe mode. Additionally, trying to configure Xorg leaves me with the error “Number of created screens does not match number of detected devices”. Low and behold - xorg.conf.new shows three screens when I only have one connected. Additionally, it looks as if Xorg is using the fbdev driver instead of the ast driver which I installed. Alright, I’ll force Xorg to use my proprietary AST driver. Nada, same error.

Alright, let’s look into this screen issue. xorg.conf.d/50-screen.conf only contains one entry. But… xorg.conf.install contains three entries for screens; vboxvideo, vmware, and vesa. I’m not sure if this should be this way… but it seems like it doesn’t matter after renaming the file (to xorg.conf.install.old) and trying configuration again. Additionally, no screen sections have been found in any of the other xorg.conf.d files.

Okay, going through the Xorg.1.conf (from when I got my screen to work for a hot second [or wait, is this the configuration for a second monitor? I don’t remember]). AST: more than one matching device section found: autoconfigured video device ast. Additionally, ast: the PCI device 0xnumber at numbers:num:n has a kernel module claiming it. the driver can’t operate and will be unloaded. This sounds again to be about multiple screens/devices. I swear that I have one… If only I could figure out how to make this stop doing that.

2

Umm, a lot has changed in eight years :wink: (that is was my polite way of saying you’re likely being a bit of a monkey)

  • a native xorg driver for aspeed adapters (xf86-video-ast, or “ast”) is included in the distro out of the box
  • if the prop. aspeed xorg driver that you installed was obtained from here: Driver Downloads：ASPEED 信驊科技 … then you have installed something ancient (as, from what I can see, the most recent of those targeted xorg 7.3 … which likely would have been applicable in ~ the days of openSUSE 11)
  • the old prop driver you installed likely over wrote the disro included driver … or, if it didn’t, and assuming it got placed in the appropriate path, is now a competitor to the other driver
  • generally, you don’t need to be running the xorg -configure … just let X do its own automagic configuration at boot
  • however, things are such in the case of the ast support that you will likely need to manually config a bit
    [LIST]
  • the aforementioned ast driver is a UMS driver that doesn’t have a kernel module … however, a DRM/KMS kernel module for the aspeed hardware now exists (being introduced last year) … consequently, if you wish to use the ast UMS driver (and I will refrain from asking why), use a “nomodeset” boot option to prevent the DRM/KMS driver from loading
  • if, on the other hand, you prefer to use the KMS route, then it (the DRM/KMS driver) is meant to be used with the generic xorg modesetting driver … the ast xorg driver is supposed to have code to prevent it from attempting to load if the DRM/KMS is being used … but in another thread, I seem to recall that code logic may not be working just right – see https://forums.opensuse.org/english/get-technical-help-here/install-boot-login/486588-12-3-graphic-display-issues.html
  • I suggest you use the DRM/KMS + generic modesetting driver route … there is no 2D or 3D accel, but there is none the other route either (the ast DDX used to have some basic 2D, but that’s gone now) … so being effectively the same, why not go with the former and enjoy the benefits of KMS?

[/LIST]

3

Yes, a bit of a monkey. Some things never change. Good to know about -configure; I’ll refrain from this.

That being said, I was unable to start xwindow using the bundled AST driver. Installing the one from my motherboard’s driver CD (for 7.7) got the graphics working, although it was barely functional. Using it for a short period of time ever caused the motherboard and mouse to stop working, before it stopped initializing all together.

I’m just unsure as to why startx is reporting that no screens are found and the best way to resolve this.

4
  • “startx” is a command, but because you are rusty from Linux, I’m unsure if you’re using it as an expression for trying to start the X server or as in actually using the command from console (to start the X server). If the later, do note that your failed attempts would fall under the “Umm, a lot has changed in eight years” category; see my comment here regarding the command startx … it will work for root, if that has been what you were doing, but you shouldn’t be logging into a graphical session as root.
  • When it was/is working, the tremendous amount of lag was/is due to it being a non accelerated driver…likely compounded by whatever other issue is going on. … this is coupled with the fact that GNOME, by default, wants a GL desktop, which your device can’t provide (lacking a 3D driver, and most likely, beside the point, lacking a 3D engine – its a server adapter, it was never intended to drive wobbly windows and what not) … so you fallback to, umm, fallback mode – cpu based software rendering of the desktop
  • I don’t know what you mean by “a short period of time” – are you talking at the session level (i.e. each boot), or do you mean across several days and boots. It makes a tremendous difference. For example, if you meant the later, then perhaps you installed an xorg update, thereby over writing your prop driver and bringing you back to the former condition you experienced with the in distro ast driver. In any regard, the problem with the in distro ast driver I explained above – two different drivers trying to bind to the hardware at the same time. For that matter, when you had the prop. ast installed and working, similar competition between drivers could have been occurring.
  • in regards to xorg.conf.install, see what I wrote about it here

the best way to resolve this.
In relation to the graphics issue, I already mentioned:

In other words,

  • don’t use “nomodeset”
  • set up a real basic xorg.conf file, or use the appropriate xorg.conf.d/ file, to have the device section load the modesetting driver (I gave an example in that other thread I linked to earlier).

If you have any problems after that, post your xorg.0.log to suse paste and give us a link http://paste.opensuse.org/

5

Okay, a couple of things for clarity’s sake. By saying a short period of time I mean within one session over the course of a few hours. I was able to get things (temporarily) working again by creating an xorg.conf file; thank you. However, several nonfatal errors occur when this happens. Here’s my .xsessios-errors log which contains all of these errors. Please note that these errors occur with a default fbdev driver with modesetting; an xorg.conf file that even suggests the possibility of the ast driver (modesetting or not) gets to the splash screen but no further.

Additionally, I’ve included a successful Xorg.0.log file (from when I use a Xorg.conf file) and an errored out Xorg.0.log file (from when I don’t). The errored out xorg.0.log has the same issues regardless of whether or not I’m using modeset fbdev or nomodeset with forced ast.

You mentioned that this could be related to having installed an ast driver on top of the one that came packaged. I don’t recall the error messages in Xorg.0.conf before I installed the driver that came bundled with my motherboard but it’s quite possible that it was the same issue. It looks like I only have one ast driver installed - “lsmod | grep “ast”” only shows one driver.

Thank you for that link to you post on startx; I had no idea that the command was depreciated. I’ll boot in init 5 and log into the terminal with other sessions from now on (instead of vice versa). Thanks again for your time; I really appreciate it.

6

okay

I was able to get things (temporarily) working again by creating an xorg.conf file; thank you. However, several nonfatal errors occur when this happens. Here’s my .xsessios-errors log which contains all of these errors.
I skimmed through it. While I do use it on a regular basis, I’m not really up on gnome (I’m much more of a KDE guy), so I couldn’t tell you what a lot of them are about, but it mostly looks like generic gnome related desktop stuff, with a sprinkle of harmless but annoying X related messages. I dislike tracker and the likes of semantic desktop search indexing blah blah blah stuff.

Please note that these errors occur with a default fbdev driver with modesetting;
fbdev is not a modesetting driver – I think you are confusing things there. In both your logs you linked to below, fbdev is not becomeing “thee” xorg driver being used. … it does, however, become the driver being used in the case of booting into recovery mode, as per yesterday’s discussion

an xorg.conf file that even suggests the possibility of the ast driver (modesetting or not) gets to the splash screen but no further.
I’m not sure exactly what you meant by “modesetting or not” – do you mean in cases of using and not using the “nomodeset” boot option? To be clear, the userspace xorg ast driver (ast_drv.so … whether the in distro or the proprietary supplied one) does not feature modesetting support. And it is this (the xorg driver) that is referenced in the xorg.conf file … on the kernel side, the drm driver (ast.ko), that just got introduced last year, is indeed a modesetting (i.e. KMS) driver, and it is meant to be used in conjunction with the generic, KMS supporting, userspace xorg modesetting driver (modesetting_drv.so) … the drm driver (ast.ko) will not work with ast_drv.so, fbdev_drv.so and all the other generic, strictly UMS based, xorg drivers

Additionally, I’ve included a successful Xorg.0.log file (from when I use a Xorg.conf file)
yep, that looks good: drm/KMS + modesetting driver being used… only post your xorg.conf file, as it appears you still have a bunch of kruft in it and we can trim it right down.

and an errored out Xorg.0.log file (from when I don’t). The errored out xorg.0.log has the same issues regardless of whether or not I’m using modeset fbdev or nomodeset with forced ast.

  • See note about fbdev above.
  • yep, result is indicative of what I described yesterday. in this example that you have provided, you didn’t use the nomodeset boot option, were you using an xorg.conf file, so what happens in that case is that, at boot, the new fangled drm/KMS kernel driver (ast.ko) is loaded. Then along comes X, and in its automagic configuration routine, it tries to load drivers that could be used for your hardware (ast, modesetting, fbdev, etc). The ast xorg driver is not suppsed to try to bind to the device if the drm/KMS is being used, but there is a bug somewhere in its code and so is ignoring that logic and attempting to do so anyways. See " 29.730] (EE) ast: The PCI device 0x2000 at 01@00:05:0 has a kernel module claiming it." And then X bombs out gracefully, as it … additonally, the cirrus xorg driver seems to be trying to get in on the act too; See
 29.727] (==) Matched ast as autoconfigured driver 0
    29.727] (==) Matched ast as autoconfigured driver 1

 ...(EE) cirrus: This driver cannot operate until it has been unloaded.

one of those “matched ast as” is, in most likelihood, actually the cirrus driver (I believe Wolfi323 mentioned that there was an obvious copy and paste error in the driver code (the one driver was being used as a template for the other at some pt).

You mentioned that this could be related to having installed an ast driver on top of the one that came packaged. I don’t recall the error messages in Xorg.0.conf before I installed the driver that came bundled with my motherboard but it’s quite possible that it was the same issue.
maybe … depends upon where it gets placed … likely it just overwrote the xorg provided ast driver. I don’t know … its academic and moot at this point.

It looks like I only have one ast driver installed - “lsmod | grep “ast”” only shows one driver.
That’s not the xorg ast driver … that’s the drm/kerenl module (ast.ko) … commands like “lsmod” and “modinfo drivername” return info about the kernel modules … not the userspace drivers … the xorg log will tell you about which userspace drivers are getting loaded. And only one can bind to the device at a time.

Thank you for that link to you post on startx; I had no idea that the command was depreciated. I’ll boot in init 5 and log into the terminal with other sessions from now on (instead of vice versa). Thanks again for your time; I really appreciate it.
okay, np. after you post your xorg.conf file though, I’m going to cut bait as I can’t afford the time any more

7

And then X bombs out gracefully, as it
…can’t configure a Screen … as in the X meaning of the word, as opposed to common language’s reference to something else (i.e. a monitor/display/panel/screen/thing_that_shows_images/…)

8

Correct. The ast driver (at least the version included in openSUSE 12.3) contains the following code:

                if (pci_device_has_kernel_driver(pPci)) {
                    xf86DrvMsg(0, X_ERROR,
                               "ast: The PCI device 0x%x at %2.2d@%2.2d:%2.2d:%1.1d has a kernel module claiming it.
",
                               pPci->device_id, pPci->bus, pPci->domain, pPci->dev, pPci->func);
                    xf86DrvMsg(0, X_ERROR,
                               "cirrus: This driver cannot operate until it has been unloaded.
");
                    return FALSE;
                }
9

that last bit should have been “and you weren’t using an xorg.conf” files, so what happens" …

[quote=“wolfi323,post:8,topic:91509”]

Correct. The ast driver (at least the version included in openSUSE 12.3) contains the following code:

                if (pci_device_has_kernel_driver(pPci)) {
                    xf86DrvMsg(0, X_ERROR,
                               "ast: The PCI device 0x%x at %2.2d@%2.2d:%2.2d:%1.1d has a kernel module claiming it.
",
                               pPci->device_id, pPci->bus, pPci->domain, pPci->dev, pPci->func);
                    xf86DrvMsg(0, X_ERROR,
                               "cirrus: This driver cannot operate until it has been unloaded.
");
                    return FALSE;
                }

[/QUOTE]Thanks. The misbehaviour would appear to be spawn strictly from ast then … which accounts for why such occurs “whether or not I’m using modeset …or nomodeset with forced ast”