[Bug 9284] Ubuntu 6.10 (Edgy) Live CD freezes (black screen) for ATI cards unless disabling DRI or reducing AGP speed
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=9284 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | Component|DRM modules |Driver/Radeon Product|DRI |xorg Version|DRI CVS |git --- Additional Comments From [EMAIL PROTECTED] 2006-12-19 02:37 --- I pushed a change to xf86-video-ati git which makes the radeon driver leave the AGP transfer mode and fast writes unchanged by default. I'm afraid this is too invasive for the 6.6 branch though. Is anything else needed to resolve this bug? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
mmap abuses in drm
Folks, could someone explain what the heck is going on here:
static int i830_map_buffer(drm_buf_t * buf, struct file *filp)
{
drm_file_t *priv = filp->private_data;
drm_device_t *dev = priv->head->dev;
drm_i830_buf_priv_t *buf_priv = buf->dev_private;
drm_i830_private_t *dev_priv = dev->dev_private;
const struct file_operations *old_fops;
unsigned long virtual;
int retcode = 0;
if (buf_priv->currently_mapped == I830_BUF_MAPPED)
return -EINVAL;
down_write(¤t->mm->mmap_sem);
old_fops = filp->f_op;
filp->f_op = &i830_buffer_fops;
dev_priv->mmap_buffer = buf;
virtual = do_mmap(filp, 0, buf->total, PROT_READ | PROT_WRITE,
MAP_SHARED, buf->bus_address);
dev_priv->mmap_buffer = NULL;
filp->f_op = old_fops;
if (IS_ERR((void *)virtual)) { /* ugh */
/* Real error */
DRM_ERROR("mmap error\n");
retcode = PTR_ERR((void *)virtual);
buf_priv->virtual = NULL;
} else {
buf_priv->virtual = (void __user *)virtual;
}
up_write(¤t->mm->mmap_sem);
return retcode;
}
(and same crap in i810_dma.c aswell)
Overriding the file operations just for mmap is for one thing racy
as hell and for another very fragile as the mmap and nopage routines
have to agree closely on what to do.
Even further why in hell do you call do_mmap from a driver? Mapping
memory into userspace from anything but syscall dedicated to it is
surely a desaster waiting to happen.
Is there any chance we can get rid of this crap (and similar stuff in
drm_bufs.c) as part of the memory manager overhaul? Long-term I'd
like to get rid of the do_mmap(_pgoff) export to avoid that people
introduce similar braindamage again.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
vmalloc_32?
Hi, Does anbody know why drm is using vmalloc_32 instead of vmalloc when allocating SHM maps? /Thomas - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vmalloc_32?
> > Does anbody know why drm is using vmalloc_32 instead of vmalloc when > allocating SHM maps? I may be wrong but maybe for mixed 64/32-bit kernel/userspace systems, did it ever use vmalloc? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vmalloc_32?
Dave Airlie wrote: >>Does anbody know why drm is using vmalloc_32 instead of vmalloc when >>allocating SHM maps? >> >> > >I may be wrong but maybe for mixed 64/32-bit kernel/userspace systems, did >it ever use vmalloc? > > > Don't know really, but since drm AFAICT never cares about the physical address of the underlying pages, vmalloc should probably do just fine, or even better vmalloc_user on newer kernels, => we could skip the memset() i just added. /Thomas >Dave. > > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vmalloc_32?
>> >> > Don't know really, but since drm AFAICT never cares about the physical > address of the > underlying pages, vmalloc should probably do just fine, or even better > vmalloc_user on newer kernels, > => we could skip the memset() i just added. I'ts been there for ever http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commitdiff;h=74e19a40187ac3b5907922e5dc01418135a5794b was the result of my digging... so it may be worth changing it in git and see what happens.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9201] xdemos/glxthreads get: Assertion `block->fenced' failed
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=9201 --- Additional Comments From [EMAIL PROTECTED] 2006-12-19 15:57 --- Looks OK to me. Normally Keith would review i965 changes but he's on vacation for the next few weeks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mmap abuses in drm
> static int i830_map_buffer(drm_buf_t * buf, struct file *filp)
> {
> drm_file_t *priv = filp->private_data;
> drm_device_t *dev = priv->head->dev;
> drm_i830_buf_priv_t *buf_priv = buf->dev_private;
> drm_i830_private_t *dev_priv = dev->dev_private;
> const struct file_operations *old_fops;
> unsigned long virtual;
> int retcode = 0;
>
> if (buf_priv->currently_mapped == I830_BUF_MAPPED)
> return -EINVAL;
>
> down_write(¤t->mm->mmap_sem);
> old_fops = filp->f_op;
> filp->f_op = &i830_buffer_fops;
> dev_priv->mmap_buffer = buf;
> virtual = do_mmap(filp, 0, buf->total, PROT_READ | PROT_WRITE,
> MAP_SHARED, buf->bus_address);
> dev_priv->mmap_buffer = NULL;
> filp->f_op = old_fops;
> if (IS_ERR((void *)virtual)) { /* ugh */
> /* Real error */
> DRM_ERROR("mmap error\n");
> retcode = PTR_ERR((void *)virtual);
> buf_priv->virtual = NULL;
> } else {
> buf_priv->virtual = (void __user *)virtual;
> }
> up_write(¤t->mm->mmap_sem);
>
> return retcode;
> }
>
> (and same crap in i810_dma.c aswell)
>
> Overriding the file operations just for mmap is for one thing racy
> as hell and for another very fragile as the mmap and nopage routines
> have to agree closely on what to do.
>
> Even further why in hell do you call do_mmap from a driver? Mapping
> memory into userspace from anything but syscall dedicated to it is
> surely a desaster waiting to happen.
>
> Is there any chance we can get rid of this crap (and similar stuff in
> drm_bufs.c) as part of the memory manager overhaul? Long-term I'd
> like to get rid of the do_mmap(_pgoff) export to avoid that people
> introduce similar braindamage again.
>
We can't change it without breaking userspace apps, so although the code
is ugly it has been working for years is only used on i810 systems, most
i830 use i915 driver now, and I don't think you can implement it any
other way that will remain compatible with userspace... the drm doesn't
use syscalls it uses ioctls, and the ioctl in this case is dedicated to
mapping buffers into userspace...
The code is mainly concerned with mapping userspace-generic buffers
whether they are in AGP/SG/framebuffer space to the userspace driver via
a single ioctl call, the userspace doesn't need to know what type of
buffers they are in theory, if you look at drm_mmap in drm_vm.c you'll see
the other half of this great fun,
I'm not sure reimplementing this stuff is worth it, to just avoid
do_mmap_pgoff export, and if it can be implemented without busting
userspace all over the place..
The new memory manager system can't fix old systems, it isn't a fix old
brain damage, it is a whole new interface, it just provides the new
interfaces and the drivers have to be ported to it, but the old interfaces
have to remain as far as I can see for ever.. the old memory manager
interfaces are driver specific in a lot of cases and it would be quite
impossible to overhaul and remain userspace compatible..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
