Created attachment 2826 [details]
Xorg.0.log

a line in Xorg.0.log:

111.403] (WW) SIS(0): Could not find/read video BIOS

@ tv

Assigning to you, even though I still don't know what the udev_event error means. 
You'll reassign when needed :-D

Assignee: bugsquad => thierry.vignaud

Does it work better if you load sisfb?
(eg: "modprobe sisfb")

Keywords: (none) => NEEDINFO

Created attachment 2827 [details]
Xorg.0.log after startx

(In reply to comment #4)
> Does it work better if you load sisfb?
> (eg: "modprobe sisfb")

After booting into safe mode, I did

# modprobe sisfb
# startx

It was a bit better.... I got a nice red screen (because I did startx as root)

and right after that a segfault :(

and, really nice, I returned to the tty.

However, doing startx on the second system *without* doing "modprobe sisfb" gave exactly the same results.

The backtrace after the segfault (in the last attached Xorg.0.log) is not so long, putting an adjusted version (merged similar lines) in this comment, to save tv some time.


[    88.339] (EE) Backtrace:
[    88.350] (EE) 0: /etc/X11/X (xorg_backtrace+0x49) [0x81e6e19]
[    88.350] (EE) 1: /etc/X11/X (0x8048000+0x1a2d16) [0x81ead16]
[    88.350] (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xffffe40c]
[    88.350] (EE) 3: /usr/lib/xorg/modules/drivers/sis_drv.so (0xb6fc8000+0x4eda3) [0xb7016da3]
[    88.350] (EE) 4: /usr/lib/xorg/modules/drivers/sis_drv.so (0xb6fc8000+0x3a689) [0xb7002689]
[    88.350] (EE) 5: /usr/lib/xorg/modules/drivers/sis_drv.so (0xb6fc8000+0x28a45) [0xb6ff0a45]
[    88.350] (EE) 6-12: /usr/lib/xorg/modules/libexa.so (0xb6f79000+*) [0xb6f*]
[    88.350] (EE) 13: /etc/X11/X (miCopyRegion+0x17c) [0x81c378c]
[    88.350] (EE) 14: /etc/X11/X (miDoCopy+0x4f0) [0x81c3dc0]
[    88.350] (EE) 15: /usr/lib/xorg/modules/libexa.so (0xb6f79000+0x85a2) [0xb6f815a2]
[    88.350] (EE) 16-19: /etc/X11/X (0x8048000+*) [*]
[    88.350] (EE) 20: /lib/i686/libc.so.6 (__libc_start_main+0xf5) [0xb71f49a5]
[    88.350] (EE) 21: /etc/X11/X (0x8048000+0x1fbb9) [0x8067bb9]
[    88.350] (EE) 
[    88.351] (EE) Segmentation fault at address 0x0
[    88.351] 
Fatal server error:
[    88.351] Caught signal 11 (Segmentation fault). Server aborting

There's only on commit (a bug fix not related to this bug) in upstream git since the release we use.

In order to know what's the bug, we need a full GDB trace.
Can you please:
1) enable Core*Debug media
2) install glibc-debug, x11-server-debug, x11-driver-video-sis-debug
3) get both https://bugs.mageia.org/attachment.cgi?id=121 &
   https://bugs.mageia.org/attachment.cgi?id=122
4) Just run "sh ./Xgdb2.sh" on a text terminal, then switch back
   to X11 until it segfaults.
5) attach the generated bug trace (it should be named something
   like "X.gdb.<some_random_PID_number>.txt"

Anyway I'll probably backport the latest commit from
http://cgit.freedesktop.org/xorg/driver/xf86-video-sis/log/

Created attachment 2833 [details]
Failed backtrace

gcmds2:4: Error in sourced command file:
The program is not being run.

:(

When I google 

handle SIGUSR1 nostop
handle SIGUSR2 nostop
handle SIGPIPE nostop
cont
bt
quit

I get the impression that "cont" and "bt" should be switched

No.
Just replace "cont" by "run"

Created attachment 2834 [details]
X.gdb.2522.txt

(In reply to comment #11)

> Just replace "cont" by "run"

after I started the command, I switched to tty2 to startx. That wasn't needed, because "sh ./Xgdb2.sh" already tried to startx. I hope I didn't add noise to the backtrace.

Do I need to install *all* the suggested packages? (I remember gdb could be over-enthusiastic)

Attachment 2833 is obsolete: 0 => 1

Created attachment 2837 [details]
X.gdb.txt (without additional startx)

OK, I installed all the suggested debug packages, apart from the tainted ones. 
(I suppose that caused at least the libfreetype mismatch)

Then I ran "sh ./Xgdb2.sh" again, but did not try to go to tty2 to startx

What does this mean?:

[tcsetpgrp failed in terminal_inferior: Operation not permitted]

There's no trace here. Did you remove the "bt" command?

(In reply to comment #14)
> There's no trace here. Did you remove the "bt" command?

no, I replaced "cont" by "run", so now I have:

handle SIGUSR1 nostop
handle SIGUSR2 nostop
handle SIGPIPE nostop
run
bt
quit

Was I correct not to try to start x from tty2? I have the impression your command already tries to start it, because the system behaves really weird (screen turns different shades of black for a while, no text visible, before finally becoming tranquile and showing 

# sh ./Xgdb2.sh

again.

oh, Xgdb2.sh never finishes by itself, btw, I always have to do ctrl + Z to stop it

and I choose ctrl Z because crl C didn't work :/

how many minutes should I have waited?

sorry, Thierry, x11-driver-video-sis-0.10.7-3.mga3.src.rpm didn't fix it :(

Not adding a new X.gdb.*.txt, because there is nothing new in it. Or do you want another one from when I do startx in tty2?

Source RPM: x11-driver-video-sis-0.10.7-2.mga3.src.rpm => x11-driver-video-sis-0.10.7-3.mga3.src.rpm

Created attachment 2838 [details]
Xorg.0.log.updateddriver

Xorg.0.log with x11-driver-video-sis-0.10.7-3.mga3, from when I tried to get a backtrace.

At the beginning, where Open ACPI failed in the other two Xorg.0.logs, it is now successful.

I'll do startx again, without trying to get a backtrace, and attach that log later (maybe tomorrow)

Created attachment 2839 [details]
Xorg.0.log.newdriver_startx

Attachment 2826 is obsolete: 0 => 1
Attachment 2827 is obsolete: 0 => 1

Created attachment 2840 [details]
/var/log/messages.updateddriver

Attachment 2825 is obsolete: 0 => 1

Can you try running directly gdb then typing the following commands:

$ gdb -q --args /usr/bin/Xorg 
handle SIGUSR1 nostop
handle SIGUSR2 nostop
handle SIGPIPE nostop
run
bt

(In reply to comment #22)
> Can you try running directly gdb then typing the following commands:
> 
> $ gdb -q --args /usr/bin/Xorg 
> handle SIGUSR1 nostop
> handle SIGUSR2 nostop
> handle SIGPIPE nostop
> run
> bt

I'll try again as root, after installing missing tainted freetype2-debug.

As normal user I got:

Fatal server error:
Cannot move old log file: "var/log/Xorg.0.log" to "/var/log/Xorg.0.log.old"

the permissions on both of those files are:

-rw-r--r-- root root

apart from that, there was a note about a that missing debug package, and "No stack"

Created attachment 2841 [details]
gdb_run_directly.txt

I did 

# gdb -q --args /usr/bin/Xorg 2>&1 | tee /home/marja/gdb_run_directly.txt
(gdb) handle SIGUSR1 nostop
(gdb) handle SIGUSR2 nostop
(gdb) handle SIGPIPE nostop
(gdb) run

of course my screen turned black again.

I typed
bt
twice: one time when my screen was still black, but I was sure I had waited long enough, and one time when I could see things again.

I don't know why no "bt" command ended up in gdb_run_directly.txt

Can you try remotely through ssh?

(In reply to comment #25)
> Can you try remotely through ssh?

No success until now. 

==> Was it wrong to choose safe mode and then init 3 ? <==

In safe mode, before I did init 3, I got "connection refused", but with init 3, I get "connection timed out"

Then I tried pinging that system, that didn't work (anymore, I suppose), pinging this system from that one works fine

I even removed shorewall there (and turned it off, here), that doesn't make a difference.

After reboot I get nothing but time outs, both in safe mode and in init 3, so I somehow managed to make things worse (only time outs is worse than a refused connection) :(

Did you try manually run "service sshd start" on the target system?

(In reply to comment #27)
> Did you try manually run "service sshd start" on the target system?

No, I did
systemctl status sshd.service
and saw (and still see) it is loaded, active, running and listening on 
0.0.0.0 port 22
:: port 22

So I didn't (and don't) think it needs to be started

Is your network running?

service network status/start

CC: (none) => sander.lepik

(In reply to comment #29)
> Is your network running?
> 
> service network status/start

It runs (else I wouldn't be able to ping this system)

But I always start it with 
systemctl start network.service

I won't have time this afternoon,  but when I find time I'll try to ssh into the other system with the same problem. Maybe it works there.

This is a recent install (boot.iso from just before alpha1), that one started as ± Mageia 1 rc, it might respond differently.

Don't ask me why, but I just now I could ping that system, so I tried to log in:

[marja@Denkblok2 ~]$ ssh marja@10.0.0.172
Password:
System is booting up.


marja@10.0.0.172's password:
Connection closed by 10.0.0.172
[marja@Denkblok2 ~]$

I just don't have a clue what I'm doing wrong..... oh, maybe still being in safe mode, there? But last time, after doing init 3 I got all those connection time outs.

I'm reluctant to try init 3 again

now tried as root

[root@Denkblok2 marja]# ssh root@10.0.0.172
Warning: Permanently added '10.0.0.172' (RSA) to the list of known hosts.
Password:
Password:
Password:
root@10.0.0.172's password:
Permission denied, please try again.
root@10.0.0.172's password:
Permission denied, please try again.
root@10.0.0.172's password:
Received disconnect from 10.0.0.172: 2: Too many authentication failures for root
[root@Denkblok2 marja]# 

Is it possible that system thinks I'm typing other passwords than I am?

forget it, I'm in (suppose it needed init 3 after all)

sorry for all the noise

trying to get that backtrace now

Created attachment 2843 [details]
gdb_run_remotely2.txt

it just stops after 

Errors from xkbcomp are not fatal to the X server

after that nothing more happens, you don't get to see (gdb) and no matter how long you wait, typing "bt" does nothing

So the attached file is worthless :(

Doing startx remotely still gives the same backtrace as in comment 6, and this still comes very, very fast.

.xsession-errors from doing startx (see comment 36) is amazingly empty, btw, it only contains:

localhost being added to access control list

Doing top remotely when doing startx, shows very shortly, usually one after the other,

X
console-kit-dae
polkitd

at the top of the list.


doing gdb as instructed shows for quite a while

gdb

at the top of the list. Then

Xorg

joins in very, very shortly and they disappear together.

Created attachment 2844 [details]
Xorg_strace

The  result of 

strace -f -o /home/marja/Xorg_strace /usr/bin/Xorg

I stopped strace after seeing /home/marja/Xorg_strace hadn't grown larger for more than a minute

Hopefully it contains something useful

btw, I ran it as root

Sorry, I had totally forgotten about the discussion some months ago about startx being deprecated.

djcb suggested looking at what happens when starting a DM

So I started lxdm in init 3, and watched top using another machine. To my surprise, X remains very active, using different amounts of CPU and memory.

The screen remains black and it is impossible to see anything by pressing ctrl+alt+F*, not even after 10 minutes

So X only segfaults when doing startx?

oh, I did ctrl + C, and I can see things again

X is gone from top, now

ctrl + C only works if start and stop lxdm from the other system (using ssh), not when I started lxdm on the system where the screen turned black

colin suggested to try to get a core dump, and try to get a backtrace from it.

I tried for both Xorg and startx
neither was a success:

Failed to read a valid object file image from memory.
Core was generated by  `icewm'.
(for startx by:`/etc/X11/X :0 vt1 -auth /root/.serverauth.2389 -deferglyphs 16'.)
Program terminated with signal 6, Aborted.
#0  0xffffe424 in ?? ()
(gdb) bt
#0  0xffffe424 in ?? ()
#1  0x09460770 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 

(#1 was a bit different for startx:
#1  0x08265580 in ?? () )

You need to attach gdb to the X server, not to startx!

Created attachment 2849 [details]
gdb-Xorg of startx crash

(In reply to comment #46)
> You need to attach gdb to the X server, not to startx!

I tried the post mortem of startx again, now with gdb+Xorg. 

It looks better, does at least contain some errors and a fatal error.

Xorg doesn't crash (although I would have sworn it did when I got that icewm core dump). 

Xorg gives a black screen everywhere (after first showing varying degrees of black). 

However, Xorg keeps running forever if I let it.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2470 root      20   0 87024  10m 5768 S    1  0.7   0:05.03 Xorg


[marja@LenovoZolder ~]$ pidof X
[marja@LenovoZolder ~]$ pidof Xorg
2470
[marja@LenovoZolder ~]$

oh, the "icewm" core dump, of which I thought it was really an Xorg one (I never started icewm), gives nothing useful

So you did not reproduce the segfault you saw in comment #6 ?
Maybe sisfb wasn't loaded?

Have you tried boot with "vga=5"?

Both?

(In reply to comment #49)
> So you did not reproduce the segfault you saw in comment #6 ?

Maybe I should close this report as invalid (because it is too confusing) and start all over again and keep better note of what I do or don't do.

This is from memory, if it sounds too strange to be true it might be wrong:

I did see the exact same backtrace when doing startx (I *think* in the terminal on the other machine I used to ssh into the buggy one), and I remember being surprised that every time I saw it, no core dump was created.

However, I did get a core dump if I saw no backtrace, but the message that ends with "Errors from xkbcomp are not fatal to the X server."

> Maybe sisfb wasn't loaded?

I didn't think of loading it.
> 
> Have you tried boot with "vga=5"?

Not yet
> 
> Both?

Ultimately Wednesday, I'll try both (apart as well as together).

Just keep this BR for now

(In reply to comment #49)
> So you did not reproduce the segfault you saw in comment #6 ?
> Maybe sisfb wasn't loaded?
> 
> Have you tried boot with "vga=5"?
> 
> Both?

OK, I found out that I can ssh into the system now, even when booting it up into  graphical mode.

There is no difference between vga=788 and vga=5, nor with either of them with or without doing "modprobe=sisfb" (in the terminal). 

But now I saw things I missed before when ssh'ing into the system: X gets a new PID every two seconds or so, and all the time new Xorg.0.log(.old)'s are created. The backtrace is still the same as in comment 6.

Later today I'll try to get core dumps of Xorg and X again, after making sure I did "modprobe=sisfb"

Created attachment 2863 [details]
gdb-Xorg backtrace of startx crash, after "modprobe sisfb"

I made sure I had done "modprobe sisfb" before getting the core.

In the terminal the backtrace from comment 6 was visible and a core was created. The backtrace from it looks the same as the last one I attached :/

What is missing in #5-10 of thread 1?

This was done in RL3, so no VGA=whatever was set.

also in RL3:

doing /usr/bin/Xorg after "modprobe sisfb", doesn't lead to a crash. The only difference with comment 47, is that I don't see Xorg in top anymore. However, it keeps having PID 1729. There is still no X

Just tried a fresh install with boot.iso of september 18th
For the monitor, I didn't choose plug 'n play (that is what it usually defaults to), but flat panel 1920 x 1080. 


From /var/log/messages I can see every two seconds a process is started again.

in Xorg.0.log I see:

[   113.206]
Fatal server error:
[   113.206] xf86OpenConsole: VT_ACTIVATE failed: Input/output error
[   113.207]
[   113.207] (EE)
Please consult the The X.Org Foundation support
         at http://bugs.mageia.org
 for help.
[   113.207] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[   113.207] (EE)
[   113.207] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error
[   113.207] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error
[   113.207]
FatalError re-entered, aborting
[   113.207] xf86CloseConsole: VT_ACTIVATE failed: Input/output erro

In case it does make a difference which exact video chip I have:
SiS 661FX on both systems

With the 3beta2 LiveCD, you see a black screen with the cursor blinking intermittently, and after about 15 minutes you see text.

Same version, traditional install: cursor blinks a few times, then everything stays black, even for 30 minutes.

For both, journalctl output gives an endless amount of repeated:

Feb 07 16:39:48 localhost acpid[650]: client connected from 21285[0:0]
Feb 07 16:39:48 localhost acpid[650]: 1 client rule loaded
Feb 07 16:39:50 localhost kdm[669]: X server for display :0 terminated unexpectedly
Feb 07 16:39:50 localhost kdm[21290]: :0[21290]: Fatal X server IO error: Interrupted system call
Feb 07 16:39:50 localhost acpid[650]: client 21285[0:0] has disconnected
Feb 07 16:39:50 localhost acpid[650]: client connected from 21317[0:0]
Feb 07 16:39:50 localhost acpid[650]: 1 client rule loaded
Feb 07 16:39:52 localhost kdm[669]: X server for display :0 terminated unexpectedly
Feb 07 16:39:52 localhost kdm[21322]: :0[21322]: Fatal X server IO error: Interrupted system call
Feb 07 16:39:52 localhost acpid[650]: client 21317[0:0] has disconnected

(In reply to comment #57)
> ..... a black screen with the cursor blinking
> intermittently

s/cursor/mouse arrow/

bug seems present in Fedora, Ubuntu and probably Debian too, but I couldn't find an upstream bug report 
https://bugzilla.redhat.com/show_bug.cgi?id=896165
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/1034812
http://lists.freedesktop.org/archives/xorg/2012-March/054179.html

Leaving the "release blocker", though. Maybe it is better to remove 
x11-driver-video-sis from Mga 3 and use vesa instead? ::cry::

Keywords: (none) => UPSTREAM
See Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=896165

(In reply to comment #57)

> With the 3beta2 LiveCD, you see a black screen with the cursor blinking
> intermittently, and after about 15 minutes you see text......

I can confirm that I am experienceing the same conditions
as Marja described in Comment 57. I have two identical
platforms with SiS video. Those systems are described
as follows:

MSI Hermes 651
Intel Celeron CPU 1.70GHz, 128Kb cache
SiS961/962 SMBus Controller Gigabyte MoBo
 SiS7012 PCI Audio
 SiS650/651/740 GUI 2D/3D Video
 Realtek RTL-8139 eth0 100Mhz
512MB DIMM
Maxtor 6Y160P0 160GB IDE (hda)
SONY CD-RW CRX230E

See attached image.

Both of these systems are running Mageia 2. One spends
most of it's time, unused, in a closet. The other is my
print server. During my last job ( 98 -> retirement in 10 )
I worked on a project that fielded over 1000 of these
devils in Home Depots throughout the USA. They're a good
little box and was one of the most successful MSI products.
I was the principle Engineer on this project. The OS was
Mandriva 10.x if I remember correctly. Maybe some 9.x's.

I have no problem with using the closeted system as a
test platform for this Bug. There is nothing on the
closeted system of importance. Wrinkes are that it will
not boot from a USB drive and is a little slow. Maybe a
lot slow.

Created attachment 3503 [details]
MSI Hermes 651, SiS video, image

@ Thierry

It would take me a lot of time to figure this out, and you probably know without looking anything up:

Can I downgrade to Mageia 2 version without ending up downgrading everything to Mageia 2.

If so, would just downgrading 

x11-server-common
x11-server-xorg
x11-driver-video-sis

be enough, or would I need to downgrade everything that starts with "x11-", or ?

> With the 3beta2 LiveCD, you see a black screen with the cursor blinking
intermittently
> Same version, traditional install: cursor blinks a few times, then everything
stays black
I have been asked to report the same problems on a 32-bit machine with SiS 660 or 661 or 662 video controller.
If that helps!
But I wonder why other distributions I have (or had) worked OK...

Lewis Smith

CC: (none) => lewyssmith

(In reply to comment #63)

> But I wonder why other distributions I have (or had) worked OK...
> 

In Mageia, this bug was introduced with version 1.13.0 of xorg x11 server, in September last year.

All LiveCDs I tried over the past weeks from other distros, either installed the vesa video driver, or an older version of xorg server.

If you find a distro where >= version 1.13.0 for xorg server and sis video driver works fine, please tell us.

Now I did find an upstream bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=35763#c2

> Just tried to install Fedora 18 which has X.Org 1.13 (whatever it may be, as
> the X.Org site has no such release) and it fell miserably with SIGSEGV. As some
> investigation showed, in 1.12 releases the X.Org has dropped XAA whatsoever and > now the SiS driver is trying to use EXA... which is broken... and it fails.

However, I really thought we were on 1.12.* in cauldron before, and we didn't have a problem then... or do I misunderstand this comment?

(In reply to comment #65)

Just checked: the last version we had before this bug appeared, was 
x11-server-1.12.4.mga3 and it worked fine with my SiS video cards

Summary: No X with last x11-driver-video-sis => No X with last x11-driver-video-sis and x11-server-1.13
Source RPM: x11-driver-video-sis-0.10.7-3.mga3.src.rpm => x11-driver-video-sis-0.10.7-5.mga3 x11-server-1.13.2-2.mga3

Trying to change settings with XFdrake, so that SiS driver won't try to use EXA or XAA, didn't help.

However, adding:

Option "NoAccel" "true"

to xorg.conf does work :-D


SOLUTION:

The part about my SiS card in xorg.conf now looks like this:

Section "Device"
    Identifier "device1"
    VendorName "Silicon Integrated Systems [SiS]"
    BoardName "SiS old series-based cards"
    Driver "sis"
    Option "DPMS"
    Option "SWCursor"
    Option "NoAccel" "true"
EndSection


After adding that line, I did 
systemctl start prefdm.service
and my DM and DE started without any problems :-D

This is a much better solution than using Vesa.... I can even watch television again in cauldron (not perfect, but good enough) :-D

I'll reboot, to make sure the fix survives a reboot

(In reply to comment #67)

> 
> I'll reboot, to make sure the fix survives a reboot

It does. 

\o/ \o/ \o/

for who wants to try the workaround, xorg.conf can be found here:
/etc/X11/xorg.conf

(In reply to comment #68)

> for who wants to try the workaround, xorg.conf can be found here:
> /etc/X11/xorg.conf

Given a completely empty HD how can I install cauldron and get
to some working environment to make the changes. Use VI?

(In reply to comment #69)

Using a Live-CD

> (In reply to comment #63)

> In Mageia, this bug was introduced with version 1.13.0 of xorg x11 server, in
> September last year.
> All LiveCDs I tried over the past weeks from other distros, either installed
> the vesa video driver, or an older version of xorg server.
> If you find a distro where >= version 1.13.0 for xorg server and sis video
> driver works fine, please tell us.

Can you advise me what commands to use to determine:
- the xorg server version
- what driver it is actually using?
TIA   Lewis

(In reply to comment #69)
> (In reply to comment #68)
> 
> > for who wants to try the workaround, xorg.conf can be found here:
> > /etc/X11/xorg.conf
> 
> Given a completely empty HD how can I install cauldron and get
> to some working environment to make the changes. Use VI?

(Ouch, having written what is below, I saw you want to use the liveCD... I'm not sure you can directly install the live without having to use the vesa driver. If you do need to set xdriver=vesa, then after install first use XFdrake to change your driver from vesa to sis and reboot. The rest is the same as written below) 

Just install with traditional installer DVD and then:
* boot into safe mode
* type "init 3"
* log in as root
* type "vim /etc/X11/xorg.conf" (without " ", of course)
* press "j" until you're one line above the "Endsection" that closes the section for your SiS device (press "k" to go back up if you went too far down)
* press "o" (starts a new line) and type "Option "NoAccel" "true"
* press the Escape button
* press shift and keep pressing while typing "ZZ"

The changes have been saved, now, so you can start your DM with:
* "systemctl start prefdm.service" 

And everything should work :-D

(In reply to comment #71)
> > (In reply to comment #63)
> 
> > If you find a distro where >= version 1.13.0 for xorg server and sis video
> > driver works fine, please tell us.
> 
> Can you advise me what commands to use to determine:
> - the xorg server version
> - what driver it is actually using?
> TIA   Lewis


At the top of /var/log/Xorg.0.log you see your xorg xserver version. The driver is in that file, too, but it easier (not sure whether it is just as good) to check in /etc/X11/xorg.conf which driver you use.

(In reply to comment #72)

> * press "o" (starts a new line) and type "Option "NoAccel" "true"

OUCH!!
THAT IS WRONG!
The first " should not be typed, but the other ones in that line should. 

Please type:

Option "NoAccel" "true"

(In reply to comment #64)
> > But I wonder why other distributions I have (or had) worked OK...
> In Mageia, this bug was introduced with version 1.13.0 of xorg x11 server, in
> September last year.
> If you find a distro where >= version 1.13.0 for xorg server and sis video
> driver works fine, please tell us.

All my other distributions use lower X server versions: MintDebian 1.12.4, Fedora16 1.11.4, Suse12.2 1.12.3. First & last use 'sis' driver version 0.10.4, Fed uses 'vesa'.
Not much help to you, alas.

(In reply to comment #74)
> (In reply to comment #64)

> > If you find a distro where >= version 1.13.0 for xorg server and sis video
> > driver works fine, please tell us.
> 
> All my other distributions use lower X server versions: MintDebian 1.12.4,
> Fedora16 1.11.4, Suse12.2 1.12.3. First & last use 'sis' driver version 0.10.4,
> Fed uses 'vesa'.
> Not much help to you, alas.

np, thanks for the feedback :)

Is it possible to somehow have

Option "NoAccel" "true"

auto-added to the SiS Device section in /etc/X11/xorg.conf when the SiS driver is installed?

See Also: (none) => https://bugs.freedesktop.org/show_bug.cgi?id=60891

Yes.
Just add a "LINE" line in /usr/share/ldetect-lst/Cards+

eg:
 NAME SiS old series-based cards
 DRIVER sis
>LINE Option "NoAccel" "true"

if it works, just commit it in ldetect-lst/lst/Cards+

Hm, I think I saw a comment on a xorg ml that 1.13 misses one patch that's needed for atleast some older drivers...

I'll try to dig it up and build some packages to test

(In reply to Thierry Vignaud from comment #77)
> Yes.
> Just add a "LINE" line in /usr/share/ldetect-lst/Cards+
> 
> eg:
>  NAME SiS old series-based cards
>  DRIVER sis
> >LINE Option "NoAccel" "true"
> 
> if it works, just commit it in ldetect-lst/lst/Cards+

Yes that works, thx Thierry :-D

The only commit rights I have are for docteam, so I *cannot* commit it.

(In reply to Thomas Backlund from comment #78)
> Hm, I think I saw a comment on a xorg ml that 1.13 misses one patch that's
> needed for atleast some older drivers...
> 
> I'll try to dig it up and build some packages to test

Did you find anything? 
If so, does it make adding that line to /usr/share/ldetect-lst/Cards+ unneeded?

Fixed in git

Status: NEW => RESOLVED
Resolution: (none) => FIXED

(In reply to Marja van Waes from comment #79)

> 
> (In reply to Thomas Backlund from comment #78)
> > Hm, I think I saw a comment on a xorg ml that 1.13 misses one patch that's
> > needed for atleast some older drivers...
> > 
> > I'll try to dig it up and build some packages to test
> 
> Did you find anything? 

Sorry for taking so long getting to it :/.

I've now added the fix in x11-server-1.13.3-2.mga3 that is currently building.

> If so, does it make adding that line to /usr/share/ldetect-lst/Cards+
> unneeded?


When you have installed latest version, try to remove the:

Option "NoAccel" "true"

and reboot and check if everything works.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

(In reply to Thomas Backlund from comment #81)
> (In reply to Marja van Waes from comment #79)
> 
> > 
> > (In reply to Thomas Backlund from comment #78)
> 
> Sorry for taking so long getting to it :/.

No problem at all, Thomas. (I get very little done now, because I don't manage to kill or renice 19 a looping process in my brain. It is comforting that I'm not surrounded by gods who achieve everything in less than no time)

> 
> I've now added the fix in x11-server-1.13.3-2.mga3 that is currently
> building.
> 
> > If so, does it make adding that line to /usr/share/ldetect-lst/Cards+
> > unneeded?
> 
> 
> When you have installed latest version, try to remove the:
> 
> Option "NoAccel" "true"
> 
> and reboot and check if everything works.

It didn't work, I got a black screen that kept switching between pitch black and "light" black. Couldn't switch to tty2 and had to use the SysRq keys to reboot.

It amazed me, though, that this already happened while booting up. This system (I think it was installed from the beta4 dual iso) used to fall back to text mode, after which I used to successfully start prefdm.service, but now it already hung before falling back. 

I intend to try again on another system.

Yesterday's test was on a boot.iso beta4 install

Today I tried on the beta4 dual iso install, after updating of course, but there I didn't get a working X, either.

Sorry, Thomas :-/

However, thanks a lot for having tried to find a better fix for this issue, I appreciate that very much :-D
Besides, the fix you added will undoubtedly be good for other video cards ;-)

IIUC, only upstream re-enabling XAA support for X11-server, or fixing EXA support for the SiS video driver can really solve this bug. 

Are you OK with closing this bug as fixed again?

If anything changes upstream, I'm of course willing to test again without the NoAccel option  :-)

ok closing it now. Let see what happens upstream

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

I guess this could be fixed without noaccel with
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/0001-Disable-UploadToScreen-and-DownloadFromScreen.patch?h=packages/xf86-video-sis

I've provided a test build with the patch to Marja for testing.

CC: (none) => anssi.hannula

I put a # before every "Option "NoAccel" "true"" I saw in /etc/X11/xorg.conf
and also before "LINE Option "NoAccel" "true"" in /usr/share/ldetect-lst/Cards+

Anssi's package works fine :)

Movies can be played very smoothly again :-D

Fixed package has been submitted to mga3, and NoAccel is no longer added to xorg.conf.

I confirm that m3 rc now works on my sis platform here:
Intel Celeron CPU 1.70GHz, 128Kb cache
SiS961/962 SMBus Controller Gigabyte MoBo
 SiS7012 PCI Audio
 SiS650/651/740 GUI 2D/3D Video
 Realtek RTL-8139 eth0 100Mhz

Good job.