(In reply to comment #0)
> Currently I start X with a query to localhost from gdb. There I saw a SIGPIPE.
> In gdb X freezes completely (need another computer to login remote to restart
> X).

a SIGPIPE shouldn't affect you. try "handle SIGPIPE nostop" in gdb.

If the sigpipe does not stop X I can close all application in a more gentle way.
This does not help me since the mousepointer is still stuck in a corner of the screen.

I still need to restart X to get any work done.

this bug is almost certainly a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=3113

*** This bug has been marked as a duplicate of bug 3113 ***

sorry. my bad. I did this to the wrong bug. I will undo, and re-do on my bug.

apologies

-George

[sorry for the long delay]

(In reply to comment #0).
> Problem started with kernel 2.6.20 and is still there in 2.6.23.1.

just realised this when reading through bug reports. This would indicate a kernel issue if you haven't switched the X server in between the kernels.


Anyway, to track this down do the following when the mouse gets stuck:\
ssh into the machine

first check if /dev/input/mice emits data when you move the mouse - if not, then it's a kernel bug.

attach gdb. Put a breakpoint on xf86PostMotionEvent and xf86PostMotionEventP (if you have server 1.4). This is the driver's entry point for mouse movements. If it never gets called, it's a driver issue.

Find the ReadInput proc of your driver (MouseReadInput IIRC) and see if it receives data and check where the data dissappears to.

(In reply to comment #5)
> [sorry for the long delay]
> 
> (In reply to comment #0).
> > Problem started with kernel 2.6.20 and is still there in 2.6.23.1.
> 
> just realised this when reading through bug reports. This would indicate a
> kernel issue if you haven't switched the X server in between the kernels.
> 
> 
> Anyway, to track this down do the following when the mouse gets stuck:\
> ssh into the machine
> 
> first check if /dev/input/mice emits data when you move the mouse - if not,
> then it's a kernel bug.

Then it is not a kernel bug.
/dev/input/mice emits data and by simply restarting X I can (sometimes) work again. Sometimes I can restart X but the mouse is stuck with the first graphical application started (iceweasel/firefox for example).

> attach gdb. Put a breakpoint on xf86PostMotionEvent and xf86PostMotionEventP
> (if you have server 1.4). This is the driver's entry point for mouse movements.
> If it never gets called, it's a driver issue.

This is a problem, because I need to compile X for that. I simply don't have the disk space necessary/
 
> Find the ReadInput proc of your driver (MouseReadInput IIRC) and see if it
> receives data and check where the data dissappears to.

Have done that yet.

Don't know if it is really the same bug but the last time the aplication called to 127.0.0.6. After blocking access to 127.0.0.7 I got a strace.


iptables  -t filter -A OUTPUT -d 127.0.0.6  -j LOG
iptables  -t filter -A OUTPUT -d 127.0.0.6  -j REJECT

Which yields to:

ip_tables: (C) 2000-2006 Netfilter Core Team
grsec: From 127.0.0.6: signal 4 sent to /usr/lib/j2se/1.4/jre/bin/java[java:4775
] uid/euid:1000/1000 gid/egid:1000/1000, parent /sbin/init[init:1] uid/euid:0/0 
gid/egid:0/0
grsec: From 127.0.0.6: signal 4 sent to /usr/lib/j2se/1.4/jre/bin/java[java:4775
] uid/euid:1000/1000 gid/egid:1000/1000, parent /sbin/init[init:1] uid/euid:0/0 
gid/egid:0/0
------------[ cut here ]------------
kernel BUG at mm/mmap.c:1730!
invalid opcode: 0000 [#1] PREEMPT 
Modules linked in: ipt_REJECT ipt_LOG iptable_filter ip_tables x_tables af_packe
t lp nfs lockd nfs_acl sunrpc ipv6 loop usbhid snd_via82xx snd_ac97_codec ac97_b
us snd_mpu401_uart snd_rawmidi snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss 
evdev snd_seq_oss parport_pc parport snd_seq_midi_event snd_seq snd_timer snd_se
q_device snd via_rhine mii bitrev soundcore crc32 i2c_viapro i2c_core ehci_hcd u
hci_hcd thermal button processor usbcore via_agp unix

Pid: 4753, comm: java Not tainted (2.6.24.5-grsec-200804171953-1 #1)
EIP: 0060:[<000407f6>] EFLAGS: 00010206 CPU: 0
EAX: 00001000 EBX: 00002000 ECX: f4116a14 EDX: f4116bcc
ESI: 08472000 EDI: 00100077 EBP: f4116a14 ESP: f400ff04
 DS: 0068 ES: 0068 FS: 0000 GS: 0033 SS: 0068
Process java (pid: 4753, ti=f400e000 task=f72b5aa0 task.ti=f400e000)
Stack: f4116a14 f71f3280 00000001 0003ed23 00000007 08474000 08473000 c09903b4 
       00000007 08472000 f71f3280 f72b5aa0 00186286 f72b5aa0 f71f3280 f4116a14 
       f71f3280 00000001 08472000 0000eae8 00000001 55049e48 00003938 55049e48 
Call Trace:
 [<0003ed23>] <0> [<00186286>] <0> [<0000eae8>] <0> [<00003938>] <0> [<0000e7d0>
] <0> [<001877ca>] <0> [<00010212>] <0> =======================
Code: 0b eb fe 8b 51 54 85 d2 74 05 39 4a 54 74 04 0f 0b eb fe 8b 41 48 3b 42 48
 74 04 0f 0b eb fe 8b 42 08 29 f3 2b 42 04 39 c3 74 04 <0f> 0b eb fe 8b 41 44 3b
 42 44 75 08 8b 41 3c 3b 42 3c 74 15 0f 
EIP: [<000407f6>]  SS:ESP 0068:f400ff04
---[ end trace 531aca9b5c70aa23 ]---
grsec: From 127.0.0.6: signal 4 sent to /usr/lib/j2se/1.4/jre/bin/java[java:4960
] uid/euid:1000/1000 gid/egid:1000/1000, parent /sbin/init[init:1] uid/euid:0/0 
gid/egid:0/0

(In reply to comment #6)
> (In reply to comment #5)
> > attach gdb. Put a breakpoint on xf86PostMotionEvent and xf86PostMotionEventP
> > (if you have server 1.4). This is the driver's entry point for mouse movements.
> > If it never gets called, it's a driver issue.
> 
> This is a problem, because I need to compile X for that. I simply don't have
> the disk space necessary/


you can just get the source code for the mouse driver alone (git://anongit.freedesktop.org/git/xorg/driver/xf86-input-mouse) and compile it up. This allows you to put printf's all over the place and find out where the events disappear in the driver.

You'll need the xorg headers installed to compile it. your distro should have a matching package.

oh. and by printf I mean xf86Msg(X_ERROR, "....

I observed the very same problem on hardened gentoo across several kernel and X versions. The problem vanished completely when I switched to a non-hardened kernel.

According to http://home.coming.dk/index.php/2008/06/24/p815#comments, this is a PAX issue. Gordon Malm comments there: "I've been doing some research/testing on this issue. It seems to be an interaction between forced-preemption and KERNEXEC. You should be able to re-enable KERNEXEC as long as you disable preemption or use voluntary preemption"

(In continuation of comment #9)
falling back to voluntary kernel preemption actually fixed the problem on Gentoo hardened 2.6.28-hardened-r3. When it previously happened, then on high CPU load and mostly with OpenGL applications running. Also considering the comment https://bugs.freedesktop.org/show_bug.cgi?id=3113#c7, I guess this problem is really related to a sometimes incorrectly restored FPU context.

Besides the mouse problem, I also encountered strange program behaviour in for loops controlled by a double variable. For example, a loop of the following type was sometimes not executed at all, until reboot:

for (double dk=0; dk < 1; dk+=0.2) {
     something();
}

The problem with PREEMPT is very likely or at least disabling the PREEMPT feature should increase the stability of the system.

I wonder if PAX did anything but increase the chance the bug shows itself. From all the comments I've seen, I'm more or less convinced the pre-emption feature with Pax causes trouble. Looking back I'm sad to say I don't have al the old kernels and configurations anymore, since I have been experiencing this problem for quite a while. In fact I can't remember a stable 2.6-kernel with Pax on one particular system.

I'm not yet convinced the pre-emption feature works well without Pax.

I'll disable the feature and continu using Pax.

(In reply to comment #11)
> I wonder if PAX did anything but increase the chance the bug shows itself. 
yes, probably! Perhaps Con Kolivas and spender may want to comment on this?

Comment from Pax team:
"i never recommended PREEMPT because i haven't made any big effort to ensure that everything in PaX is compatible with it, ..."

Short answer, the preempt code is provided as is, untested and not supported.
It should work with Pax or it should fail without Pax, since Pax only added basic functions to the preempt function (like open/close).
The Pax-team can't reproduce the problem, therefore the bughunting stops there (unless someone can trace the bug).
See for the complete answer the grsecurity forum.

Either the preempt-code is very strict (and Pax broke it) or the kernelcode already is broken without patch.

I have different computers and only one exhibits the problem. However it is one of the weakest computers and probably the one which has the highest system load (at times). It would not surprise me if it were my only computer where any influence of forced preemption would be noticed.

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.