Re: Trying to fix 3dfx.o + question about char drivers..
Michael Bacarella wrote: > So, I upgrade to 2.4.0 and it's cool, except that I can't do > anything neat with my voodoo3 anymore. I've been looking > for a solution for weeks but to no avail. 3dfx's web site > looks like it's gone and nothing on lk about it. > > The process calls ioctl() after opening /dev/3dfx. That ioctl() triggers > an mmap() call, the driver gets addresses it's totally not expecting, > and it returns -EPERM. struct file_operations has changed in 2.4.0. The following patch for 3dfx module fixes the structure initialization and makes it work just fine. --- 3dfx_driver.c Sun Apr 9 03:44:10 2000 +++ 3dfx_driver.c Fri Feb 23 22:42:06 2001 @@ -707,25 +707,10 @@ #endif /* HAVE_MTRR */ static struct file_operations fops_3dfx = { - NULL, /* llseek (2.1) / lseek (2.0) */ - NULL, /* read */ - NULL, /* write */ - NULL, /* readdir */ - NULL, /* poll (2.1) / select (2.0) */ - ioctl_3dfx, /* ioctl */ - mmap_3dfx, /* mmap */ - open_3dfx, /* open */ -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 1, 118) - NULL, /* flush (2.1.118+) */ -#endif - release_3dfx, /* release */ - NULL, /* fsync */ - NULL, /* fasync */ - NULL, /* check_media_change */ - NULL, /* revalidate */ -#ifdef KERNEL_VER_2_1 - NULL/* lock (2.1) */ -#endif + ioctl: ioctl_3dfx, + mmap: mmap_3dfx, + open: open_3dfx, + release:release_3dfx }; #ifdef MODULE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to fix 3dfx.o + question about char drivers..
Michael Bacarella wrote: So, I upgrade to 2.4.0 and it's cool, except that I can't do anything neat with my voodoo3 anymore. I've been looking for a solution for weeks but to no avail. 3dfx's web site looks like it's gone and nothing on lk about it. The process calls ioctl() after opening /dev/3dfx. That ioctl() triggers an mmap() call, the driver gets addresses it's totally not expecting, and it returns -EPERM. struct file_operations has changed in 2.4.0. The following patch for 3dfx module fixes the structure initialization and makes it work just fine. --- 3dfx_driver.c Sun Apr 9 03:44:10 2000 +++ 3dfx_driver.c Fri Feb 23 22:42:06 2001 @@ -707,25 +707,10 @@ #endif /* HAVE_MTRR */ static struct file_operations fops_3dfx = { - NULL, /* llseek (2.1) / lseek (2.0) */ - NULL, /* read */ - NULL, /* write */ - NULL, /* readdir */ - NULL, /* poll (2.1) / select (2.0) */ - ioctl_3dfx, /* ioctl */ - mmap_3dfx, /* mmap */ - open_3dfx, /* open */ -#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 1, 118) - NULL, /* flush (2.1.118+) */ -#endif - release_3dfx, /* release */ - NULL, /* fsync */ - NULL, /* fasync */ - NULL, /* check_media_change */ - NULL, /* revalidate */ -#ifdef KERNEL_VER_2_1 - NULL/* lock (2.1) */ -#endif + ioctl: ioctl_3dfx, + mmap: mmap_3dfx, + open: open_3dfx, + release:release_3dfx }; #ifdef MODULE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Trying to fix 3dfx.o + question about char drivers..
So, I upgrade to 2.4.0 and it's cool, except that I can't do anything neat with my voodoo3 anymore. I've been looking for a solution for weeks but to no avail. 3dfx's web site looks like it's gone and nothing on lk about it. [ By all means, if someone has fixed this, do let me know ] Tracing the Glide test programs shows that ioctl() is returning -EPERM. Compiling the driver with 'make debug' shows: [ To aid in the confusion, my machine's hostname is 'mmap' ] [ insmod 3dfx.o ] Feb 14 15:08:14 mmap kernel: 3dfx: Entering init_module() Feb 14 15:08:14 mmap kernel: 3dfx: Successfully registered device 3dfx Feb 14 15:08:14 mmap kernel: 3dfx: board vendor 4634 type 5 located at de00/ [ ./test3Dfx ] Feb 14 15:08:29 mmap kernel: 3dfx: Entering mmap_3dfx Feb 14 15:08:29 mmap kernel: 3dfx: Couldn't match address 0 to a card Feb 14 15:08:29 mmap kernel: 3dfx: Entering release_3dfx mmap_3dfx is being called before ioctl_3dfx is ever reached. Looking to make heads of the "Couldn't match address 0 to a card" message, I stuck in some more debugging output: [ VM_OFFSET is #define VM_OFFSET(vma) (vma->vm_pgoff << PAGE_SHIFT) ] Feb 14 15:08:29 mmap kernel: 3dfx: Entering mmap_3dfx Feb 14 15:08:29 mmap kernel: 3dfx: Entering decode_vma: Feb 14 15:08:29 mmap kernel: 3dfx: start = c1270640, end = c5e40840 Feb 14 15:08:29 mmap kernel: 3dfx: offset = 0 (VM_OFFSET = 0) Feb 14 15:08:29 mmap kernel: 3dfx: Leaving decode_vma Feb 14 15:08:29 mmap kernel: 3dfx: compare de00 or e200 to 0 Feb 14 15:08:29 mmap kernel: 3dfx: Couldn't match address 0 to a card Feb 14 15:08:29 mmap kernel: 3dfx: Entering release_3dfx Sure stumped me. By my guess, it seems that mmap_3dfx is provided by the char driver so that a userland process can map a region of (video?) memory on the card. The process calls ioctl() after opening /dev/3dfx. That ioctl() triggers an mmap() call, the driver gets addresses it's totally not expecting, and it returns -EPERM. Why does mmap get called first?? Am I reading this right? -- Michael Bacarella <[EMAIL PROTECTED]> Technical Staff / System Development, New York Connect.Net, Ltd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/