From: Joris v. R. <jvr...@xs...> - 2005-08-14 09:57:09
|
Hello Thomas, Thanks for your positive feedback. On Sun, Aug 14, 2005 at 09:38:45AM +0200, Thomas Hellstr?m wrote: > >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) > 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. I was not aware of this, and unfortunately you seem to be right. I am getting 300000 interrupts per second with this patch. Completely missed that, although I did have the impression that my system was a bit slow overall. Some of these interrupts are genuine VBLANKs, but I can't figure out how to disable the spurious interrupts. > 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. My solution is not less efficient than the old situation. The old mm code can do fast mem_alloc() but will loop through all allocated blocks on mem_free() (twice). My current solution will loop on mem_alloc() but has a faster mem_free(). If you are concerned, I can use hashing to speed up mem_alloc(). I did this originally but then thought it not worthwhile. A possible approach is attached as 03a_via_mm_cleanup. This will of course turn slow again when the number of allocated blocks passes a certain treshold. > 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. The old solution passes a kernel pointer to userspace as a unsigned long. This should work in i386 as well as pure x86_64, but not in x86_64 with 32-bit compatibility. To be honest, I did not even test it; it simply cannot work. > 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. Right. I missed the check in the ioctl. Bye, Joris. |