Hello Jose,
Thank you for the response.
> Do you have a PCI card? If not make sure the agpgart kernel module is
> loaded before the mach64 module, by adding
>
> pre-install mach64 modprobe -k agpgart
Yes, it is an AGP card:
lspci -vv:
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility
P/M AGP 2x (rev 64) (prog-if 00 [VGA])
Subsystem: Hewlett-Packard Company: Unknown device 0011
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 66 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f5000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: I/O ports at 9000 [size=256]
Region 2: Memory at f4100000 (32-bit, non-prefetchable)
[size=4K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [50] AGP version 1.0
Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW- AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
Rate=<none>
Capabilities: [5c] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
and I had made sure that the agpgart module was loaded (that's why
I thought this problem was so odd):
lsmod:
Module Size Used by Not tainted
mach64 85368 0
agpgart 18896 0 (unused)
kernel messages:
kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann
kernel: agpgart: Maximum main memory to use for agp memory: 203M
kernel: agpgart: Detected Intel 440BX chipset
kernel: agpgart: AGP aperture is 64M @ 0xf8000000
kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0
kernel: [drm] Module unloaded
kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann
kernel: agpgart: Maximum main memory to use for agp memory: 203M
kernel: agpgart: Detected Intel 440BX chipset
kernel: agpgart: AGP aperture is 64M @ 0xf8000000
kernel: [drm] Initialized mach64 1.0.0 20020904 on minor 0
> > (II) ATI(0): [drm] register handle = 0xf4100000
> > (II) ATI(0): [dri] Visual configs initialized
> > (II) ATI(0): [dri] Block 0 base at 0xf4100400
> > (WW) ATI(0): Not enough memory for local textures, disabling DRI
>
> And you should decrease the screen depth (16bpp is a must if you care for 3D
> performance).
Oddly, it is already at 16bpp:
XF86Config:
Section "Screen"
Identifier "screen1"
Device "device1"
Monitor "monitor1"
DefaultColorDepth 16
Subsection "Display"
Depth 16
Virtual 1280 1024
EndSubsection
EndSection
XFree86.0.log:
(II) Setting vga for screen 0.
(==) ATI(0): Chipset: "ati".
(**) ATI(0): Depth 16, (--) framebuffer bpp 16
xdpyinfo:
screen #0:
dimensions: 1280x1024 pixels (361x292 millimeters)
resolution: 90x89 dots per inch
depths (7): 16, 1, 4, 8, 15, 24, 32
> > (II) ATI(0): [drm] removed 1 reserved context for kernel
> > (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0ba0000 at 0x40016000
> >
> > Did a lsmod, agpgart and mach64 are loaded. Looked at
> > kernel logs and found:
> >
> > kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held
> > kernel: [drm:mach64_unlock] *ERROR* Process 1836 using kernel context 0
> > kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held
> > kernel: [drm:mach64_unlock] *ERROR* Process 2427 using kernel context 0
> > kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held
> > kernel: [drm:mach64_unlock] *ERROR* Process 2733 using kernel context 0
> > kernel: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held
> > kernel: [drm:mach64_unlock] *ERROR* Process 4150 using kernel context 0
>
> Well, this is suerly a consequence of above, but these calls shouldn't
> be happening consedering DRM was disabled....
That's another thing that I thought was so odd and why I posted to the
list. My intuition (I am not an X developer) is that DRI is being
disabled as a result of the above errors?
> > I hope that this bug report helps and thank the dri development
> > people for their hard work.
>
> See if the above tips help. Let us know otherwise.
No dice so far. As mentioned before, the mach64-0-0-5-branch
on XFree86 4.2.0 used to work beautifully. I've attached the
XFree86.0.log from XFree86-4.3-23mdk with mach64-20031128-linux
applied.
If there is any particular testing that I can do let me know -- if
need be I can download and compile the mach64-0-0-6-branch CVS branch
again and give that a shot. Also this system does not have any
important information on it so I can set up ssh root access if that
would help in testing at all. If that would help, let me know and give
me a few days to prepare the setup.
--
-- Chris
_________________________________
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_/ _/ _/
_/ _/ ||||
_/ _/_/_/ _/_/ _/ _/_/ c ..
_/ _/ _/ _/ _/ _/ @ >
_/ _/ _/ _/ _/ _/_/ @,-
==>chris<at>soma.978.org<==
_________________________________
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
