Joris van Rantwijk wrote:
Hello,
I modified some things in the VIA DRM driver to get it working properly
on my K8M800 Unichrome Pro chipset under Linux. I also got it working
on a x86_64 kernel with a 32-bit usermode system.
Could someone on this list please look through my patches and maybe
commit some things? I hope my work can be useful to others.
Below is a description of each patch. They are largely independent
of eachother. All patches are against the current CVS.
01_via_unichrome_pro
Trivial patch to make the VIA driver recognize my PCI id as
a Unichrome Pro chipset. This makes IRQ handling work properly
and avoids the kernel message
irq 201: nobody cared (try booting with the "irqpoll" option)
02_via_verifier_bugfix
Trivial fix to the VIA command verifier. The bug caused it to accept
some invalid commands on i386 and reject valid commands on x86_64.
03_via_mm_cleanup
Rework the FB and AGP memory management in the VIA driver so that
it no longer blindly passes kernel pointers to and from userspace.
This was a security issue on i386 and a fundamental problem with
32-bit compatibility on x86_64.
04_via_ioctl_security
Enable privilege checking on those ioctls that seem to be intended
for the X server only. Don't know if there was a particular reason
why this wasn't done before.
05_via_futex_niceabort
Avoid Oops and X server crash when something goes wrong during
DRM initialization.
06_via_compat32
Compatibility wrappers around the VIA ioctls to make it work with
a 32-bit usermode system on a x86_64 kernel.
Thanks,
Joris.
Hi, Joris.
Thanks for having done this!
Some first comments:
Patch 1: The K8M800/K8N800 is not a unichrome pro group A but rather a
unichrome pro group B, and lacks most of the group A features both when
it comes to IRQ capability and video DMA commands, so it is wrong to
enable group A features. However, if this fixes the "IRQ nobody cared"
problem it needs to be investigated further.
I have the same problem on my K8M800/K8N800 computers, but when a stray
interrupt occurs, nothing is seen in the Unichrome IRQ status register,
and returning IRQ_HANDLED will make the unichrome issue about 300000
interrupts per second. I've asked VIA about this and their first
response is that the IRQ functionality was never verified on chipsets
not having video capture functionality.
Could you further investigate exactly why the patch fixes this error?
Some looks into /proc/interrupts to determine IRQ frequency?
Does it work also in 64 bit mode?
Patch 2: Is correct and will be commited as soon as possible.
Patch 3: I agree that there is checking needed for the returned index
values,
but can't this be solved using range checking on the kernel pointers, or
perhaps store the
pointers in a hash table, the content of which is verified before a
memblock is freed?
It seems very inefficient to loop through the block map (up to 5000
blocks) on each allocation.
BTW How does the current solution interfere with x86-64?
Here it works nicely except the kernel crashes when it tries to free
unfreed memory blocks in final_context, but I haven't been able to track
down the cause yet.
Patch 4: An oversight in the initial code. It seems correct except for
the DMA_INIT ioctl where the privilege checking is done within the IOCTL
code.
Patch 5: Correct. Will go in.
Patch 6: Long awaited. Have to look a bit more into it.
Regards
Thomas
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
