I had a dri failure-to-load with Radeon in a 64 bit Opteron system
(fedora core 2). Card is a Radeon RV250 (9000). (I did not find it in
drm_pciids.txt -- pci id 0x1002 0x496e -- but that's a separate issue)
The symptoms were kernel messages on modprobe:
radeon: Ignoring new-style parameters in presence of obsolete ones
[drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory!
[drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART!
radeon: probe of 0000:05:00.0 failed with error -22
The problem turned out to be the check on line 78 of drm_bufs.h
(CVS 10/21/04) and the following patch disabling the check fixed the
problem.
--- /tmp/drm_bufs.h 2004-10-22 14:14:49.581824144 -0500
+++ /tmp/updated/drm_bufs.h 2004-10-22 14:16:34.911497648 -0500
@@ -68,19 +68,19 @@
int DRM(initmap)( drm_device_t *dev, unsigned int offset, unsigned int size, int
type, int flags )
{
drm_map_t *map;
drm_map_list_t *list;
DRM_DEBUG("\n");
if ( (offset & (~PAGE_MASK)) || (size & (~PAGE_MASK)) )
return -EINVAL;
-#if !defined(__sparc__) && !defined(__alpha__)
+#if 0 && !defined(__sparc__) && !defined(__alpha__)
if ( offset + size < offset || offset < virt_to_phys(high_memory) )
return -EINVAL;
#endif
if ( !(list = DRM(alloc)( sizeof(*list), DRM_MEM_MAPS )))
return -ENOMEM;
memset(list, 0, sizeof(*list));
if ( !(map = DRM(alloc)( sizeof(*map), DRM_MEM_MAPS ))) {
DRM(free)(list, sizeof(*list), DRM_MEM_MAPS);
I added debug printfs and found that offset=0xff5f0000, size=0x10000,
and virt_to_phys(high_memory)=0x40000000, so the check really shouldn't
have failed, but I suspect a 64 bit sign extension bug. DRI loads and
works fine once this check is disabled. I also wonder if this check
is still useful in these days of complicated memory maps and 64 bit
architectures. (The machine in question has 4GB main memory, 1GB of
which is shifted above the 4GB boundary to leave space for PCI and
GART/IOMMU address space). Shouldn't offset be a 64 bit quantity?
Also, I noticed that the a failure at this point caused general system
instability after one or two modprobe/rmmod cycles. Perhaps the error
path needs to be investigated.
Steve
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
