Pallipadi, Venkatesh wrote:
> Use of vma->vm_pgoff to identify the pfnmaps that are fully
> mapped at mmap time is broke. vm_pgoff is set by generic mmap
> code even for cases where drivers are setting up the mappings
> at the fault time.
> 
> The problem was originally reported here.
> http://marc.info/?l=linux-kernel&m=123383810628583&w=2
> 
> Change is_linear_pfn_mapping logic to overload VM_NONLINEAR
> flag along with VM_PFNMAP to mean full PFNMAP setup at mmap
> time.
> 
> Acked-by: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> Signed-off-by: Suresh Siddha <suresh.b.siddha>@intel.com>

I've applied this patch on top of v2.6.29-rc7-143-g99adcd9 [1] and since 
then I've had my system, or rather X/KDE, hang several times. The last 
time the problem seems to have been KDE's kicker. I was running a kernel 
compile in a konsole window and that just continued and finished, but the 
keyboard was completely dead.
I could still ssh in from another box. 'ps' would show the top processes, 
but hang as well at some point (in the middle of listing KDE processes.

The hang was with pat enabled. I've now booted with nopat.

The log shows (full log attached):
kernel: BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
kernel: IP: [<ffffffff80322504>] prio_tree_remove+0x9c/0xcc
kernel: PGD 7cab1067 PUD 7d644067 PMD 0
kernel: Oops: 0000 [#1] SMP
kernel: last sysfs file: /sys/class/power_supply/C23D/charge_full
kernel: CPU 1
kernel: Pid: 5415, comm: kicker Not tainted 2.6.29-rc7 #4 HP Comp
aq 2510p Notebook PC
kernel: RIP: 0010:[<ffffffff80322504>]  [<ffffffff80322504>] prio
_tree_remove+0x9c/0xcc
[...]
kernel: Call Trace:
kernel:  [<ffffffff803225df>] prio_tree_insert+0xab/0x22a
kernel:  [<ffffffff8027e90d>] vma_prio_tree_insert+0x23/0xc2
kernel:  [<ffffffff802864af>] __vma_link_file+0x70/0x72
kernel:  [<ffffffff80286c15>] vma_link+0x7d/0xab
kernel:  [<ffffffff802881ea>] mmap_region+0x313/0x479
kernel:  [<ffffffff80288646>] do_mmap_pgoff+0x2f6/0x35c
kernel:  [<ffffffff802ea99a>] do_shmat+0x28a/0x36c
kernel:  [<ffffffff802eaa8d>] sys_shmat+0x11/0x1c
kernel:  [<ffffffff8020c25b>] system_call_fastpath+0x16/0x1b

From the symptoms I strongly suspect this patch to be the culprit.

Cheers,
FJP

[1] Together with some other patches (mainly Rafael's latest patchset 
for "Rework disabling of interrupts during suspend-resume"), but I doubt 
any of those are related to this issue.