Brenda J. Butler
2011-Nov-26 02:03 UTC
[Pkg-xen-devel] Bug#646987: /usr/bin/xinit: xinit fails with xkbcomp could not be invoked
The function that returns ENOMEM is actually copy_mm. It returns ENOMEM when dup_mm returns 0. copy_mm receives clone_flags and task_struct * tsk. I think tsk is pointing to the new task (the process being forked). copy_mm assigns some values into *tsk, then: tsk->mm = NULL; tsk->active_mm = NULL; then we check if current process has ->mm; if not, return 0 (effectively copying the "no mm" status into the new task_struct, is this true?). Presumably 0 return is "success", because failure returns are things like -ENOMEM. If we haven't returned, then we check if clone_flags includes CLONE_VM; if so, we set our mm = the current process' ->mm, set some elements in ->mm and ->tsk and return. If clone_flags does not include CLONE_VM, we try to set mm = dup_mm(tsk) which presumably means we are trying to duplicate the ->mm of the task being created?!? and if that fails (0 return) then we return with -ENOMEM. So presumably the X server is trying to fork xkbcomp and is coming to this bit of code - current->mm is not 0, but clone_flags & CLONE_VM is false. And I imagine that tsk->mm is still 0 (as we are trying to create it in copy_mm, is that true?) so copy_mm fails. I need to know more about clone_flags and who sets it. bjb
Brenda J. Butler
2011-Nov-26 02:22 UTC
[Pkg-xen-devel] Bug#646987: /usr/bin/xinit: xinit fails with xkbcomp could not be invoked
On Fri, Nov 25, 2011 at 09:03:03PM -0500, Brenda J. Butler wrote:> If clone_flags does not include CLONE_VM, we try to set > > mm = dup_mm(tsk) > > which presumably means we are trying to duplicate the > ->mm of the task being created?!? and if that fails (0 return) > then we return with -ENOMEM.No, dup_mm tries to copy memory of the current task into the new task. But we see this message in kern.log: Xorg:2967 map pfn expected mapping type write-back for d0000000-e0000000, got write-combining This comes from reserve_pfn_range in arch/x86/mm/pat.c. In another note: I was able to do a kernel compilation with the kernel under xen that couldn't run the X server due to this forking problem. bjb
Ian Campbell
2011-Nov-26 10:55 UTC
[Pkg-xen-devel] Bug#646987: Bug#646987: /usr/bin/xinit: xinit fails with xkbcomp could not be invoked
On Fri, 2011-11-25 at 21:22 -0500, Brenda J. Butler wrote:> > But we see this message in kern.log: > Xorg:2967 map pfn expected mapping type write-back for > d0000000-e0000000, got write-combining > > This comes from reserve_pfn_range in arch/x86/mm/pat.c.Does "nopat" on your kernel command line work as a workaround? Ian. -- Ian Campbell Anger kills as surely as the other vices.
Maybe Matching Threads
- [RFC/PATCH 01/15] preparation: provide hook to enable pgstes in user pagetable
- [PATCH v11 8/8] vhost: use vhost_tasks for worker threads
- [ 3009.778974] mcelog:16842 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
- [ANNOUNCE] xkbcomp 1.4.1
- [ANNOUNCE] xkbcomp 1.4.0