[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005)



On Wed, 16 Nov 2005, Nickolay V. Shmyrev wrote:
> 
> It's sad, but I still don't understand the way it should be fixed.
> Removal of VM_RESERVED is certainly not a solution, since we don't going
> to swap mmaped pages and VM_RESERVED is used in other drivers (for
> example, some sound drivers)

Early in this thread (last Friday) I said that I was working on
the fix for this and some other PageReserved removal problems.

I suggested then:
Though if you're curious and impatient, you could try just editing
the " | VM_RESERVED" out of mm/memory.c get_user_pages.

Does that not work for you?  It's not the full solution to all the
issues, but I'd expect it to be enough to get you going.  If it does
not work for you, then I need to understand why not in a hurry:
please let me know either way.

I'm at last getting near with my patches, hope to post later tonight
(but everything always takes me longer than I expect).

> So, we need to find the problem itself. After looking at the code I've
> found that the x86_64 dependency of that problem lies in the check in
> memory.c:get_user_pages
> 
> if (vma && in_gate_area (task, start))
> 
> x86_64 defines it's own arch-dependant function in_gate_area which fails
> in our case.

Why would you expect "in_gate_area" to pass in your case?  I'd be very
surprised if the user pages you're trying to get are in the gate area.
I doubt that has anything to do with it: please try what I suggested.

Hugh

> Can someone trace that code and find why do we fail and
> fail only on x86_64. It would be nice if someone could point me to
> get_user_pages documentation, why it's so differently behaves for 64 bit
> arch.
> 
> Also it seems that I had traces of video-buf module with debug enabled
> on 64 bit, but lost them. Can someone just enable debug option to video-
> buf module and collect those traces.



Reply to: