Latest xorg, and latest dri from cvs with my IBM-thinkpad T22:
The savage oopses if glxinfo is called:
Steps to reproduce:
mtrr: base(0xf2000000) is not aligned on a size(0x5000000) boundary
Unable to handle kernel paging request at virtual address e0990000
*pde = 014d7067
*pte = 00000000
Oops: 0002 [#1]
Modules linked in: md5 ipv6 pcmcia yenta_socket rsrc_nonstatic parport_pc lp
parport savage drm thinkpad ibm_acpi snd_cs46xx gameport snd_rawmidi
snd_seq_device snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc
speedstep_smi freq_table speedstep_lib af_packet st scsi_mod
EIP: 0060:[<e093f562>] Not tainted VLI
EFLAGS: 00010286 (2.6.12-gentoo-r6)
EIP is at savage_bci_emit_event+0xa2/0xf0 [savage]
eax: 00000000 ebx: c0030000 ecx: 00000003 edx: e0990000
esi: 00008073 edi: dfb73200 ebp: bf893a60 esp: d51cded4
ds: 007b es: 007b ss: 0068
Process glxinfo (pid: 10861, threadinfo=d51cc000 task=d832a060)
Stack: dfb73200 00000002 00000000 d51cdf04 dfb73200 e0941467 dfb73200 00000003
00000008 00100100 00200200 00000000 00000000 00000003 df257000 00000001
d1dd0c20 00000000 e096c7c1 dfb975c0 d53bef60 c0086442 bf893a60 dff61600
[<e0941467>] savage_bci_event_emit+0xd7/0x130 [savage]
[<e096c7c1>] drm_ioctl+0xf1/0x1bb [drm]
Code: c0 bb 00 00 00 c0 0f 45 d8 89 d8 0d 00 00 01 00 f6 c1 02 0f 45 d8 b8 02
00 00 00 89 44 24 04 ff 97 2c 01 00 00 8b 97 d0 00 00 00 <89> 1a 83 c2 04 89 f0
0d 00 00 00 98 89 02 83 c4 08 89 f0 5b 5e
I compiled agpgart and intel-agp as modules. Works better, since the kernel
doesn't oops again. It just gives an
Jul 29 22:08:54 thinkpad kernel: [drm:savage_bci_wait_event_shadow] *ERROR*
Jul 29 22:08:54 thinkpad kernel: [drm] status=0x000100a8, e=0x00aa
Then the savage-driver resets.
If I set Option "DmaType" "PCI" in xorg.conf, glxgears works with 330
fps. glxinfo shows direct rendering enabled
I can provide with several logs, if needed.
there seems to be a problem with savage and agp on IBM laptops. several others
have reported the same problem. I've noticed similar problems on my T20. I
looked into it, but didn't notice anything apparent. you might try forcing
shadowstatus off in your config (you may have to edit the code, savage_driver.c
in the DDX, I don't know if it'll let you turn shadowstatus off and still enable
the DRI anymore), I seem to recall hearing the shadowstatus was problematic on
(In reply to comment #2)
> there seems to be a problem with savage and agp on IBM laptops. several others
> have reported the same problem. I've noticed similar problems on my T20. I
> looked into it, but didn't notice anything apparent. you might try forcing
> shadowstatus off in your config (you may have to edit the code, savage_driver.c
> in the DDX, I don't know if it'll let you turn shadowstatus off and still enable
> the DRI anymore), I seem to recall hearing the shadowstatus was problematic on
> ibm laptops.
Disabling shadow status in the config file should work. DRI vs. no DRI is only
supposed to change the default setting. See also the manual page.
Direct rendering on my "IBM ThinkPad T23" is up and running
after booting the machine. The video chip is an "S3 Inc.
SuperSavage IX/C SDR rev 5". "glxinfo" reports that direct
rendering is enabled and 3D hardware acceleration is ok.
However, after logging out and in again, execution of
"glxinfo" triggers a segmentation fault. "DRI" enabled
applications make the "X" session abort instantaneously.
After rebuilding the "DRM" kernel modules for current
version 1.0.1, the problem goes away. Seems to be identical
to this bug. Can you try with current "DRM"? I am using
modular "X" 188.8.131.522 (7.0.0 RC2) on FC5 test1.
The strange thing here is that even without updating the kernel "DRM"
the problem goes away by merely manually loading the already present
system kernel module "savage.ko" corresponding to "DRM" version 1.0.0.
I have noticed that appending "/sbin/modprobe savage" to "rc.sysinit"
on my FC4 system (2.6.14-1.1653_FC4) makes it impossible to me to
trigger any kernel oops or segmentation fault by launching "OpenGL"
applications such as "glxinfo" or "glxgears" after successive "X"
sessions or even after restarting the "X" server.
Seems to be fixed in kernel 2.6.15-git9 through DRM upstream
update to version 1.0.1 committed by D. Airlie. Please check!
Works for mem noe