SiS driver performance regression with linux-image-2.6.15-7-686

Bug #26637 reported by Rui Matos
8
Affects Status Importance Assigned to Milestone
xserver-xorg-video-sis (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

I've been running dapper with the breezy kernel (2.6.12-10-686) and all worked
as always. Since I now decided to try the new kernel I'm getting a serious
performance drop in X. Even scrolling text in an xterm (normal X fonts, i.e. no
xft) is really slow.

The following is a diff of two X logs where only the kernel changes:

$ diff Xorg.20.log Xorg.0.log
13,14c13,14
< Build Operating System:Linux 2.6.10 i686
< Current Operating System: Linux hive 2.6.12-10-686 #1 Fri Nov 18 12:09:04 UTC
2005 i686
---
> Build Operating System:Linux 2.6.12 i686
> Current Operating System: Linux hive 2.6.15-6-686 #1 SMP Thu Dec 1 04:13:59
UTC 2005 i686
22c22
< (==) Log file: "/var/log/Xorg.20.log", Time: Fri Dec 2 19:24:13 2005
---
> (==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 6 01:14:50 2005
53c53
< (++) using VT number 8
---
> (++) using VT number 7
68c68
< (II) PCI: 00:0c:0: chip 1524,1410 card 4000,0000 rev 00 class 06,07,00 hdr 02
---
> (II) PCI: 00:0c:0: chip 1524,1410 card 1c00,0000 rev 00 class 06,07,00 hdr 02
95,96c95,96
< [0] -1 0 0x00004000 - 0x000040ff (0x100) IX[B]
< [1] -1 0 0x00004400 - 0x000044ff (0x100) IX[B]
---
> [0] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]
> [1] -1 0 0x00002000 - 0x000020ff (0x100) IX[B]
98c98
< [0] -1 0 0x1f800000 - 0x1fbfffff (0x400000) MX[B]
---
> [0] -1 0 0x22000000 - 0x23ffffff (0x2000000) MX[B]
100c100
< [0] -1 0 0x1f400000 - 0x1f7fffff (0x400000) MX[B]
---
> [0] -1 0 0x20000000 - 0x21ffffff (0x2000000) MX[B]
536c536
< (--) SIS(0): CPU frequency 2533.89Mhz
---
> (--) SIS(0): CPU frequency 2533.87Mhz
538,543c538,543
< (--) SIS(0): Checked libc memcpy()... 61.3 MiB/s
< (--) SIS(0): Checked built-in-1 memcpy()... 61.9 MiB/s
< (--) SIS(0): Checked built-in-2 memcpy()... 34.5 MiB/s
< (--) SIS(0): Checked MMX memcpy()... 186.0 MiB/s
< (--) SIS(0): Checked SSE memcpy()... 62.6 MiB/s
< (--) SIS(0): Checked MMX2 memcpy()... 212.4 MiB/s
---
> (--) SIS(0): Checked libc memcpy()... 32.7 MiB/s
> (--) SIS(0): Checked built-in-1 memcpy()... 32.7 MiB/s
> (--) SIS(0): Checked built-in-2 memcpy()... 25.0 MiB/s
> (--) SIS(0): Checked MMX memcpy()... 63.5 MiB/s
> (--) SIS(0): Checked SSE memcpy()... 63.7 MiB/s
> (--) SIS(0): Checked MMX2 memcpy()... 63.9 MiB/s
598a599,600
> (II) SIS(0): Setting standard mode 0x28
> (II) Configured Mouse: ps2EnableDataReporting: succeeded

Revision history for this message
Thomas Winischhofer (thomas-winischhofer) wrote :

Obviously, MTRR support is either disabled in this kernel, or there is a problem
with MTRR setup. However, not sis driver related.

Revision history for this message
Rui Matos (tiagomatos) wrote :

I've chenged the Package to linux-image-k7 (there's nothing more suitable!)
following Thomas' comment. Also, the title is misleading now because I already
tested with the latest kernel 2.6.15-7 and the behaviour is the same.

Revision history for this message
Rui Matos (tiagomatos) wrote :

Added the ubuntu kernel maintainer as it seems a kernel issue and bugzilla
didn't do it automatically when I changed the Package field.

So MTRR seems to be enabled, so maybe there is some bug in it?

Revision history for this message
Ben Collins (ben-collins) wrote :

Let's first upgrade to 2.6.15-7. Send me dmesg output aswell.

Revision history for this message
Ben Collins (ben-collins) wrote :

(In reply to comment #4)
> Let's first upgrade to 2.6.15-7. Send me dmesg output aswell.

Nevermind. Missed that you have already done this. Keep me posted on any tests
you do with newer kernels (-8.10 is coming in a day).

Revision history for this message
Rui Matos (tiagomatos) wrote :

Using the new -8 kernel still gives me the same results. If more info is needed
please ask.

Revision history for this message
Rui Matos (tiagomatos) wrote :

Using 2.6.15-9 now. No improvements.

Revision history for this message
Ben Collins (ben-collins) wrote :

(In reply to comment #7)
> Using 2.6.15-9 now. No improvements.

Can you do me a favor and test with linux-image-2.6.15-9-386?

Revision history for this message
Rui Matos (tiagomatos) wrote :

(In reply to comment #8)
> Can you do me a favor and test with linux-image-2.6.15-9-386?

Sure. It's still the same :-(

Revision history for this message
Ben Collins (ben-collins) wrote :

Also, can you attach dmesg for 2.6.12 and 2.6.15 please?

Revision history for this message
Rui Matos (tiagomatos) wrote :

(In reply to comment #10)
> Also, can you attach dmesg for 2.6.12 and 2.6.15 please?

Since I no longer have 2.6.12 around (and it probably wouldn't work since dapper
changed to new udev) I used the breezy live CD to get the logs.

I'll attach both dmesg and X log for both kernels. But keep in mind that the
driver version and X version are different too due to breezy's older software.

Revision history for this message
Rui Matos (tiagomatos) wrote :

Created an attachment (id=5432)
2.6.12-9-386 dmesg

Revision history for this message
Rui Matos (tiagomatos) wrote :

Created an attachment (id=5433)
2.6.15-9-686 dmesg

Revision history for this message
Rui Matos (tiagomatos) wrote :

Created an attachment (id=5434)
breezy X log

Revision history for this message
Rui Matos (tiagomatos) wrote :

Created an attachment (id=5435)
dapper X log

Revision history for this message
Ben Collins (ben-collins) wrote :

Looks like the first part of the dmesg is gone. Please attach the last boot
record from /var/log/kern.log. I think the MTRR stuff I am interested in is in
the first part of kernel output.

Revision history for this message
Rui Matos (tiagomatos) wrote :

Created an attachment (id=5438)
kernel logs

Here you'll find several kernel outputs including one from last night with a
2.6.12-10 kernel (with wich X wouldn't start).

Revision history for this message
Ben Collins (ben-collins) wrote :

I see mtrr init (just the banner), but nothing about mtrr setup. And if this
contains a 2.6.12 boot, then there's no regression there.

I'm adding Thomas to the Cc, since he's supposed to be the expert here :)

Thomas, what could possibly cause such a drastic change in throughput to the sis
cards memory? MTRR doesn't seem to be used in either case.

Revision history for this message
Rui Matos (tiagomatos) wrote :

I guess I've nailed the problem:

I tried booting breezy's 2.6.12-10-686 kernel with the 'lapic' option and it too
dropped the sis drivers' memcpy benchmark to the levels I get with 2.6.15-9-686.
Obviously as dapper's kernel is now SMP enabled I couldn't desable the APIC
emulation no matter what boot options I tried (noapic, nolapic). Thus I tried
again with 2.6.15-9-386 but it too doesn't want to disable APIC with those boot
options.

So that's the source of the problem, now I'd like solutions :-)

BTW, if I enable EXA in xorg.conf I get some decent performance but the memcpy
benchmarks remain crappy. I wonder how much good would EXA be with a fast memcpy...

Revision history for this message
Ben Collins (ben-collins) wrote :

Can you show me the dmesg when you boot with "noapic nolapic"?

Revision history for this message
Rui Matos (tiagomatos) wrote :

Created an attachment (id=5470)
dmesg with 'noapic nolapic'

Revision history for this message
Rui Matos (tiagomatos) wrote :

Created an attachment (id=5471)
dmesg with 'noapic nolapic' -686

Revision history for this message
Ben Collins (ben-collins) wrote :

Sure enough looks like the ACPI is disabled to me. The second one shows that it
is enabling dummy APIC emulation, which doesn't really do anything other than
allow some trivial lookups of some sort.

Revision history for this message
Rui Matos (tiagomatos) wrote :

(In reply to comment #23)
> Sure enough looks like the ACPI is disabled to me. The second one shows that it
> is enabling dummy APIC emulation, which doesn't really do anything other than
> allow some trivial lookups of some sort.

I don't know much about the kernel so I don't know if this is relevant but they
both say:

[4294667.296000] mapped APIC to ffffd000 (013de000) -- 386

and

[4294667.296000] mapped APIC to ffffd000 (0149a000) -- 686

Anyway, like I said, using 'lapic' on 2.6.12-10-686 also makes the performace
drop there which must mean something...

Revision history for this message
Ben Collins (ben-collins) wrote :

Rui says that disabling vga16fb and vesafb from usplash fixes this problem.
Since I'm inclined to think that the X driver should not be affected by the
framebuffer device (which is the case for any other chipset), that this is a bug
in the X sis driver.

Revision history for this message
Rui Matos (tiagomatos) wrote :

I'm posting what I found here for the record:

1. Disregard all I said from comment #19 down, it makes me look really dumb :-P
It turns out that the APIC options have nothing to do with this, actually I'm
runnig 2.6.15-9-686 now with 'lapic' and all is OK. I only got the idea that
lapic made the 2.6.12 performance drop because at the same time I changed other
things on the grub vmlinuz line...

2. Which brings me to the _real_ culprit. What I had been also messing with was
the vga= option. By default usplash loads vga16fb which on both .12 and .15
_does_ make the performance drop. But vesafb which I used before (in breezy)
works great on .12. But in .15 vesafb also makes the performance drop.

3. After changing the usplash hook and script to load sisfb by default instead
of vga16fb and removing vga= from the boot options all works fine with either
kernel and sisfb even autodetects my LCD size :-)

Conclusion: the sis X driver's memcpy performance depends on the kernel
framebuffer driver that is loaded.

Daniel Stone (daniels)
Changed in xserver-xorg-driver-sis:
assignee: daniels → nobody
Revision history for this message
Matt Zimmerman (mdz) wrote :

Fabio, is this a driver issue or a kernel issue?

Revision history for this message
Josef Assad (josefassad) wrote :

I witnessed the same problem when I upgraded from breezy to dapper. Rui's solution described two comments up does indeed improve matters.

Revision history for this message
Dennis Schäfers (yok-sudo) wrote :

I'm on edgy eft and I have the same problems with my sis onboard graphic card. It's dawn slow and the windows hangs, when i'm chainging the position of them. in abiword scrolling in an 8 pages document is imbossible, but I have a duron amd and above 500mb ram an on ubuntu dapper(?) or older kernel(?) all worked fine.

Revision history for this message
Dennis Schäfers (yok-sudo) wrote :

I'm on edgy eft and I have the same problems with my sis onboard graphic card. It's damn slow and the windows hangs, when i'm chainging the position of them. in abiword scrolling in an 8 pages document is imbossible, but I have a duron amd and above 500mb ram an on ubuntu dapper(?) or older kernel(?) all worked fine.

Revision history for this message
Josef Assad (josefassad) wrote :

Have you tried what Rui suggested, Dennis? It solved my responsiveness issues (even if glxgears still runs at about a frame per hour, more likely to be glxgears' problem tha xorg)

Revision history for this message
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote :

I can confirm this. The blacklist trick works.

Revision history for this message
Ronald van Engelen (ronalde) wrote :

We are experiencing severe performance problems in X on our ltsp-clients (HP t5725 using SiS741GX) since upgrading from gutsy to hardy.

I'm not sure how to apply the Rui fix only for mentioned clients and not for all others; advice would be appreciated.

Revision history for this message
Ronald van Engelen (ronalde) wrote :

Note to self:
> I'm not sure how to apply the Rui fix only for mentioned clients and not for all others; advice would be appreciated.

 * un-blacklisted fbsis framebuffer-driver in $(CHROOT)/etc/modprobe.d/blacklist-framebuffer
 * manual_add_modules vga16fb commented in $(CHROOT)/usr/share/initramfs-tools/hooks/kernelextras
 * rebuilt initrd-image (using mkinitramfs -o /boot/initrd.img-2.6.24-16-generic 2.6.24-16-generic in $(CHROOT))
 * sudo ltsp-update-kernels
 * sudo ltsp-update-image

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi tiagomatos,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISOs are available from cdimage.ubuntu.com)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

The output of lspci -vvnn would also be worth having.

Changed in xserver-xorg-video-sis:
status: New → Incomplete
Revision history for this message
Bryce Harrington (bryce) wrote :

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

Changed in xserver-xorg-video-sis:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.