sis 760 AGP broken on amd64

is this a regression?

the AGP aperture is only 4M this is never going to be big enough for the radeon driver..

you should check your BIOS to see if you can increase it.. that or the sis driver is getting the wrong size somehow..

Hi at all! I have the same problem but I've controlled the AGP Aperture size setting in the bios and is set to 128MB so it's probably the sis driver... dmesg reports
agpgart: AGP aperture is 4M @ 0xf0000000

Bye

Enrico

Hi!

Take a look at the bug #45942, It fixes the problem in my case.

Bye

Enrico

Please test Feisty beta if it works out of the box there.

Still no joy here. This is straight from Feisty's liveCD.

syslog:

Mar 30 13:46:20 ubuntu kernel: [ 134.924090] agpgart: Found an AGP 3.1 compliant device at 0000:00:00.0.
Mar 30 13:46:20 ubuntu kernel: [ 134.924226] agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
Mar 30 13:46:20 ubuntu kernel: [ 134.924355] agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
Mar 30 13:46:20 ubuntu kernel: [ 134.925908] [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
Mar 30 13:46:20 ubuntu kernel: [ 134.926083] [drm:drm_unlock] *ERROR* Process 7278 using kernel context 0

Xorg.log
(II) RADEON(0): [drm] DRM interface version 1.3
(II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:00.0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xf0b74000
(II) RADEON(0): [drm] mapped SAREA 0xf0b74000 to 0xb7c6c000
(II) RADEON(0): [drm] framebuffer handle = 0xd8000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [agp] Mode 0x1f004e09 [AGP 0x1039/0x0760; Card 0x1002/0x5964]
(II) RADEON(0): [agp] 8192 kB allocated with handle 0x00000001
(EE) RADEON(0): [agp] Could not bind
(EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI.
(II) RADEON(0): [agp] You may want to make sure the agpgart kernel module
is loaded before the radeon kernel module.
(**) RADEON(0): RADEONDRICloseScreen
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf0b74000 at 0xb7c6c000
(**) RADEON(0): RADEONInitMemoryMap() :
(**) RADEON(0): mem_size : 0x08000000
(**) RADEON(0): MC_FB_LOCATION : 0xdfffd800
(**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0
(**) RADEON(0): RADEONModeInit()
1280x1024 135.00 1280 1296 1440 1688 1024 1025 1028 1066 (24,32) +H +V
1280x1024 135.00 1280 1296 1440 1688 1024 1025 1028 1066 (24,32) +H +V
(**) RADEON(0): Pitch = 10485920 bytes (virtualX = 1280, displayWidth = 1280)
(**) RADEON(0): dc=13500, of=27000, fd=120, pd=2
(**) RADEON(0): RADEONInit returns 0x81f5cf8
(**) RADEON(0): RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x81f5cf8)
(**) RADEON(0): RADEONRestoreMemMapRegisters() :
(**) RADEON(0): MC_FB_LOCATION : 0xdfffd800
(**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0
(**) RADEON(0): Map Changed ! Applying ...
(**) RADEON(0): Map applied, resetting engine ...
(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset: 0x00000000
(**) RADEON(0): Wrote: 0x0000000c 0x00010078 0x00000000 (0x0000a700)
(**) RADEON(0): Wrote: rd=12, fd=120, pd=1
(**) RADEON(0): GRPH_BUFFER_CNTL from 20077c7c to 20165c5c
(**) RADEON(0): RADEONSaveScreen(0)
(II) RADEON(0): Depth moves disabled by default
(**) RADEON(0): Setting up initial surfaces
(**) RADEON(0): Initializing fb layer
(**) RADEON(0): Setting up accel memmap
(II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)
(II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7165
(**) RADEON(0): Initializing backing store
(==) RADEON(0): Backing store disabled
(WW) RADEON(0): Direct rendering disabled
(...

Hi, sorry for the slow response and thank you very much for attending to this bug. I wasn't able to reboot to try the Feisty beta CD until this evening.

Unfortunately, things are still not working for me with Feisty. The xorg.log indicates that agp could not bind and suggests verifying the order in which the agpgart and the radeon modules are loaded.
Lsmod and dmesg both indicate that agp is found, although during boot the size of the agp aperture detected is way off, reading 4M rather than the 128M that is there.

Here's some output from after the boot:

ubuntu@ubuntu:~$ glxinfo | grep render
direct rendering: No
OpenGL renderer string: Mesa GLX Indirect

ubuntu@ubuntu:~$ cat /var/log/Xorg.0.log | grep agp
(II) RADEON(0): [agp] Mode 0x1f004e09 [AGP 0x1039/0x0760; Card 0x1002/0x5960]
(II) RADEON(0): [agp] 8192 kB allocated with handle 0x00000001
(EE) RADEON(0): [agp] Could not bind
(EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI.
(II) RADEON(0): [agp] You may want to make sure the agpgart kernel module
is loaded before the radeon kernel module.

ubuntu@ubuntu:~$ lsmod | grep agp
amd64_agp 13572 0
sis_agp 9476 1
agpgart 33480 3 drm,amd64_agp,sis_agp

ubuntu@ubuntu:~$ cat /var/log/dmesg | grep agp
[ 101.260783] Linux agpgart interface v0.101 (c) Dave Jones
[ 102.351910] agpgart: Detected SiS 760 chipset
[ 102.352228] agpgart: AGP aperture is 4M @ 0xf0000000

Let me know if I can help with debugging. I will be happy to do so, especially after mid-April since until then I have an on-going project here that makes rebooting difficult. And thanks again for continuing to look into this, it's much appreciated. :-)

Hi all!

I can confirm that this bug is still present in feisty beta.

Thanks

Enrico

Please use attachments for your logs.

I can confirm this on an uptodate Feisty of today. Also tried the Gutsy Beta CD; the same problem occurs. Agpgart detects aperture size of 4M (though it is set to 128M in BIOS).

Upgraded to gutsy. This problem is still present.

I also confirm that this issue is still present on Gutsy.

(amd64 with sis 760 - ATI radeon 9200 on AGP)

Just to note that the workaround found in bug #45942 actually fixes it for me.

A patch is listed here:
http://lkml.org/lkml/2007/2/26/97
maybe some kernel developer can look into patching the ubuntu kernel.

Thank you "awen", workaround found in bug #45942 also fixes this bug for me.

It's great to have some video card capabilities !

Thanks.

Hi,

I'm still seeing this problem with the i386 version of Ubuntu 7.10, using the LiveCD. So, my experience is that the bug is not amd64 only.

The AGP aperture size is set to 128M in my BIOS. But agpgart only recognizes it to be 4M:
ubuntu@ubuntu:~$ sudo cat /var/log/dmesg | grep agpgart
[ 132.042214] Linux agpgart interface v0.102 (c) Dave Jones
[ 132.345993] agpgart: Detected SiS chipset - id:1888
[ 132.346322] agpgart: AGP aperture is 4M @ 0xf0000000

In the xorg log, dri seems to be loading fine but then there is the following error message:
ubuntu@ubuntu:~$ sudo cat /var/log/Xorg.0.log | grep bind
(EE) RADEON(0): [agp] Could not bind
I have attached a complete copy of the xorg log.

The following error appears in the kernel log:
ubuntu@ubuntu:~$ sudo cat /var/log/kern.log | grep drm
Oct 23 12:57:06 ubuntu kernel: [ 171.618188] [drm] Initialized drm 1.1.0 20060810
Oct 23 12:57:06 ubuntu kernel: [ 171.663073] [drm] Initialized radeon 1.27.0 20060524 on minor 0
Oct 23 12:57:12 ubuntu kernel: [ 173.904447] [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
Oct 23 12:57:12 ubuntu kernel: [ 173.904654] [drm:drm_unlock] *ERROR* Process 8267 using kernel context 0

I have not tried the fix in https://bugs.launchpad.net/bugs/45942 in Ubuntu because I am trying the liveCD. However, I have tried renaming the sis_agp module in a Gentoo installation, with kernels up to 2.6.23, and this did not change how the AGP aperture size was identified as 4M. I've also tried patching the device ids in the kernel so that the particular model of the SIS chipset isn't identified, but that didn't fix things either although I might have made errors with this.

Please let me know if other log files from a LiveCD boot would be useful. If anyone is willing to try to fix the issue and needs a tester, I will be happy to install Ubuntu as well.

Ok, some people use amd64 and can fix the issue by renaming sis-agp.ko. Do they get the "bind" error before renaming?
Or do we have (at least) two different bugs here?

Sybille, you can try the workaround on a live cd by switching to a console (ctrl-alt-f1) and stopping X (sudo /etc/init.d/gdm stop) and unloading the module (sudo modprobe -r sis_agp) and delete it (locate sis_agp.ko, sudo rm ..., sudo depmod -a) and restart X (sudo /etc/init.d/gdm start).

Since you also have a amd64 board (according to the original report) I guess the bug is amd64-hardware only.

@Tormod
I'm using an AMD Sempron 2800+ and fixed it by renaming sis-agp.ko . And yes, the bind error was there before renaming.

@Tormod
Well, I'm not able to remove the sis_agp module once it's been loaded during the LiveCD boot, even after stopping gdm and manually removing all other modules related to video (radeon, drm, amd64_agp) - agpgart cannot be removed either, but that makes sense because it depends on sis_agp. I also tried booting in safe graphics mode. But it seems that once the sis_agp module is active, it can't be unloaded.

So I will try installing Ubuntu to a partition and then renaming the sis agp module.

sybille, thanks, installing would be a good way to find out. Otherwise you can try to boot the live cd in single user mode by pressing F6 in the cd boot menu and adding "single" to the kernel parameters. Then rm the module and exit the shell to let it continue booting.

Or, by adding "break=bottom" you'll get a initrd shell where you can delete stuff under /root (will be / in the booted system). I am not sure at which point the module is loaded, but you'll find out. If the initrd shell does not have "lsmod" you can use "cat /proc/modules".

I was able to delete the module from the busybox shell and then boot into the LiveCD, and direct rendering is now working. Yay! And thanks for the hand-holding, I don't have a lot of experience with LiveCDs.

There is one side effect I've noticed, however. I'm seeing lots of APIC errors being written to the syslog. For example:
Oct 24 16:05:54 ubuntu kernel: [ 2638.714843] APIC error on CPU0: 40(40)
Oct 24 16:05:55 ubuntu kernel: [ 2639.289894] APIC error on CPU0: 40(40)
Oct 24 16:05:55 ubuntu kernel: [ 2639.403286] APIC error on CPU0: 40(40)
Oct 24 16:05:55 ubuntu kernel: [ 2639.563636] APIC error on CPU0: 40(40)
Oct 24 16:05:55 ubuntu kernel: [ 2639.627564] APIC error on CPU0: 40(40)
Oct 24 16:05:55 ubuntu kernel: [ 2639.714194] APIC error on CPU0: 40(40)
Oct 24 16:05:55 ubuntu kernel: [ 2639.723033] APIC error on CPU0: 40(40)
Oct 24 16:05:56 ubuntu kernel: [ 2640.718361] APIC error on CPU0: 40(40)
Oct 24 16:05:56 ubuntu kernel: [ 2640.718800] APIC error on CPU0: 40(40)
Oct 24 16:05:56 ubuntu kernel: [ 2640.798309] APIC error on CPU0: 40(40)
Oct 24 16:05:57 ubuntu kernel: [ 2640.964440] APIC error on CPU0: 40(40)

Over and over again, many times per second. Does anyone else see this, too? Any ideas what to do about it, other than maybe finding a way to disable logging of the errors?

@sybille
Didn't notice the side effect until you mentioned it. But i'm seeing the same errors in the syslog (though only once every 3-5 minutes on average).

Rather than deleting or renaming modules, why not do it properly.

add

blacklist sis_agp

to the bottom of /etc/modprobe.d/blacklist

The problem is caused by the amd64_agp and sis_agp drivers running into each other.

@Neil Wilson
Hi,
We only took the route of deleting the module because I'm using a LiveCD and so could not blacklist and reboot with that change saved. It's just a workaround because I don't have an Ubuntu install at present (although I will install if needed).

At this point, I think there are two problems.
Problem 1: If both the amd64_agp and the sis_agp drivers are loaded, then there is a conflict that prevents the size of the agp aperture from being identified correctly (4M rather than the setting in the BIOS, which is 128M for me); dri is not enabled.
Problem 2: If only the amd64_agp driver is used, then dri works too, BUT the system also produces a steady stream of APIC errors which are written to the syslog at varying rates (more frequently for me than for awen, it seems).

Do you happen to see the APIC errors in your syslog, too?

Since the kernel instructions indicate that both amd64_agp and a chipset specific module are needed for amd64 systems, maybe it's not too surprising that there is some kind of adverse effect to not using sis_agp at all. (I'm referring to the instruction that are visible from the curses menuconfig interface, I'm actually not sure where they are located to make a link to show what I'm talking about).

No. I think I'm running 'noapic' on boot, or I upgraded the BIOS to
fix the problem.

On 10/29/07, sybille <email address hidden> wrote:
> Do you happen to see the APIC errors in your syslog, too?

I had a chance to experiment with things some, and I think I made a little progress. I was doing this on a Gentoo system with a 2.6.22 kernel compiled from gentoo-sources, but I don't think that makes a difference. Although this is amd64 hardware, I'm using an x86 kernel/OS.

As I mentioned in the <a href=https://bugs.freedesktop.org/show_bug.cgi?id=8840>freedesktop bug</a>, it seems to me that incorrect identification of the AGP aperture size as 4M no matter what the BIOS setting is related to the SIS 760 device IDs in the sis-agp module of the kernel. If that is the case, then it should be possible to comment out the device IDs and recompile the module in order to see how the aperture size is identified.

I had tried to do this before and apparently made some mistakes, but this time I did things correctly. Because, when I booted using the modified sis-agp module, I saw the following in the syslog:
Oct 31 10:00:31 menagerie agpgart: Detected AGP bridge 0
Oct 31 10:00:31 menagerie agpgart: AGP aperture is 128M @ 0xf0000000

Compare this with the unaltered kernel module:
[ 102.351910] agpgart: Detected SiS 760 chipset
[ 102.352228] agpgart: AGP aperture is 4M @ 0xf0000000

128M is the BIOS setting. I've attached a "patch" to show what I changed in the sis-agp module to get the above result.

Unfortunately, however, using this altered module did not solve the APIC error problem. That is, with the altered sis-agp module and amd64-agp loaded, the AGP aperture size was identified correctly during boot, DRI was enabled, but the stream of APIC errors began once the drm module was loaded. So it's not really a patch that solves things for me, just some more information that I thought might be useful.

@Neil Wilson,
I'm using the most recent beta BIOS for my motherboard (asus k8s-mx). I've upgraded the BIOS twice since opening this bug, with no effect on the problem.
Regarding the "noapic" boot option, I've used that too but found it a problematic workaround. For me, it leads to IRQ problems such as:
Oct 31 06:04:20 menagerie irq 7: nobody cared (try booting with the "irqpoll" option)
Oct 31 06:04:20 menagerie [<c0148be4>] __report_bad_irq+0x24/0x80
Oct 31 06:04:20 menagerie [<c0148e91>] note_interrupt+0x251/0x280
Oct 31 06:04:20 menagerie [<c0148115>] handle_IRQ_event+0x25/0x50
Oct 31 06:04:20 menagerie [<c014987d>] handle_level_irq+0xcd/0x110
Oct 31 06:04:20 menagerie [<c010672e>] do_IRQ+0x3e/0x80
Oct 31 06:04:20 menagerie [<c010498f>] common_interrupt+0x23/0x28
Oct 31 06:04:20 menagerie [<c0102b3a>] default_idle+0x2a/0x40
Oct 31 06:04:20 menagerie [<c01023e3>] cpu_idle+0x43/0x80
Oct 31 06:04:20 menagerie [<c0462b2f>] start_kernel+0x21f/0x2b0
Oct 31 06:04:20 menagerie [<c0462450>] unknown_bootoption+0x0/0x260
Oct 31 06:04:20 menagerie =======================
Oct 31 06:04:20 menagerie handlers:
Oct 31 06:04:20 menagerie [<c02ddf50>] (usb_hcd_irq+0x0/0x60)
Oct 31 06:04:20 menagerie Disabling IRQ #7

And that is accompanied by the whole system freezing. Again, this is only when using "noapic" at boot.

The mother board I'm using is kind of strange because it has both an AGP slot and a PCI Express slot (1x), maybe that's part of the issue. I don't have a...

I've installed Ubuntu now. :)

With linux-image-2.6.22-14-generic (version 2.6.22-14.46), the size of the AGP aperture is identified correctly:
cat /var/log/dmesg | grep agpgart
[ 33.994241] Linux agpgart interface v0.102 (c) Dave Jones
[ 34.107968] agpgart: Detected AGP bridge 0
[ 34.111845] agpgart: AGP aperture is 128M @ 0xf0000000

DRI is working, as well, with both the sis-agp and the amd64-agp modules loaded.

However, the APIC errors continue:
Nov 14 00:23:53 menagerie kernel: [39901.561197] APIC error on CPU0: 40(40)
Nov 14 00:23:54 menagerie kernel: [39902.100165] APIC error on CPU0: 40(40)
Nov 14 00:23:54 menagerie kernel: [39902.558190] APIC error on CPU0: 40(40)
Nov 14 00:23:54 menagerie kernel: [39902.558507] APIC error on CPU0: 40(40)
Nov 14 00:23:54 menagerie kernel: [39902.558936] APIC error on CPU0: 40(40)
Nov 14 00:23:54 menagerie kernel: [39902.559095] APIC error on CPU0: 40(40)
Nov 14 00:23:54 menagerie kernel: [39902.742347] APIC error on CPU0: 40(40)
Nov 14 00:23:54 menagerie kernel: [39902.742956] APIC error on CPU0: 40(40)
Nov 14 00:23:55 menagerie kernel: [39903.359838] APIC error on CPU0: 40(40)

Do the APIC errors appear only if the sis-agp and amd64-agp modules are loaded, or is this an issue on its own?

The APIC errors begin when the drm module is loaded:
Nov 15 12:59:29 menagerie kernel: [ 45.484698] [drm] Initialized radeon 1.27.0 20060524 on minor 0
Nov 15 12:59:31 menagerie kernel: [ 47.527659] agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
Nov 15 12:59:31 menagerie kernel: [ 47.527832] agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
Nov 15 12:59:31 menagerie kernel: [ 47.529800] agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
Nov 15 12:59:31 menagerie kernel: [ 47.895092] [drm] Setting GART location based on new memory map
Nov 15 12:59:31 menagerie kernel: [ 47.895100] [drm] Loading R200 Microcode
Nov 15 12:59:31 menagerie kernel: [ 47.895142] [drm] writeback test succeeded in 1 usecs
Nov 15 12:59:32 menagerie kernel: [ 48.467376] APIC error on CPU0: 00(40)
Nov 15 12:59:32 menagerie kernel: [ 48.833567] APIC error on CPU0: 40(40)
Nov 15 12:59:32 menagerie kernel: [ 49.382855] APIC error on CPU0: 40(40)
etc.

They appear if sis-agp is blacklisted but amd64-agp is loaded (in which case drm can load as well).

So maybe it is a separate issue. I don't know, do you think it needs a new bug?

> They appear if sis-agp is blacklisted but amd64-agp is loaded

So they don't appear if both sis-agp and amd64-agp are loaded (which is the normal case)?

I think we can close this bug. Does it work now for the others who had the same issue?

Please open a new bug for the apic errors, since that issue can be something else than what this bug was originally about.

>So they don't appear if both sis-agp and amd64-agp are loaded (which is the normal case)?

No. Sorry I wasn't clear.

Here's what I observe:
1) sis-agp and amd64-agp are loaded -> APIC errors
2) only amd64-agp is loaded -> APIC errors
3) only sis-agp -> no APIC errors, but no drm module or direct rendering either

In other words, there is no case for me in which direct rendering works AND there are no APIC errors.

For me amd64-agp is loaded alone, and direct rendering works, without having to rename files or blacklist modules.

The APIC errors occur for me too. They seem to be closely connected to the DRI; they don't appear under normal use, but upon running glxgears I'll immediately receive 5 of them.

I'd just like to confirm, I have the same bug, using the same motherboard (K8S-MX).

I can get the AGP aperture to identify correctly, and allow direct rendering, by renaming (i.e. disabling) sis-agp.ko, but that breaks my power management.

Sybille, if I rename sis-agp.ko back to its original name and apply your patch, will that fix my power management without breaking direct rendering again?

Thanks!

@Chonnawonga

With the 2.6.22-14-generic kernel, no patch or module renaming is needed on my machine. The AGP aperture size is recognized correctly and direct rendering works with no modifications. Both amd64-agp and the stock, unmodified version of sis-agp are loaded.

The only problem I experience is the APIC error discussed above. This error does not seem to have any bad effects other than filling up the logs, though. I've experienced no other problems, even with desktop effects enabled.

I can't comment on power management. I'm not using hibernate or suspend at present.

And it is broken again. Using an uptodate gutsy:
linux-image-2.6.22-14-generic 2.6.22-14.52
linux-ubuntu-modules-2.6.22-14-generic 2.6.22-14.37

AGP aperture size is once again detected wrong:
Feb 19 22:04:06 andreas-desktop kernel: [ 41.818786] Linux agpgart interface v0.102 (c) Dave Jones
Feb 19 22:04:06 andreas-desktop kernel: [ 41.826460] agpgart: Detected SiS chipset - id:1888
Feb 19 22:04:06 andreas-desktop kernel: [ 41.826822] agpgart: AGP aperture is 4M @ 0xe0000000

and both AGP-modules is loaded:
amd64_agp 13700 0
sis_agp 10116 1
agpgart 35016 3 drm,amd64_agp,sis_agp

stil broken with latest intrepid ibex beta all updates

I get windows that disapear and the system freezes

The 18 month support period for Feisty Fawn 7.04 has reached it's end of life. As a result, we are closing the linux-source-2.6.20 Feisty Fawn kernel task. However, please note that this report will remain open against the actively developed kernel. Thank you for your continued support and help as we debug this issue.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[This is an automated message]

Hi sybillel,

Please attach the output of `lspci -vvnn` too.

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.

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
linux-source-2.6.22 kernel task. It would be helpful if you could test the
new Jaunty Jackalope 9.04 release and confirm if this issue remains -
http://www.ubuntu.com/getubuntu/releasenotes/904overview. If the issue still exists with the Jaunty
release, please update this report by changing the Status of the "linux (Ubuntu)"
task from "Incomplete" to "New". Also please be sure to run the command below
which will automatically gather and attach updated debug information to this
report. Thanks in advance.

apport-collect -p linux-image-2.6.28-11-generic 34144