SLUB problems (was Re: lvcreate on 2.6.22.1: kernel tried to execute NX-protected page)

2007-08-16 Thread Juergen Kreileder
I got a few more oopses like the one in the original message (see below)
and one with a different call trace but that happened while creating a
snapshot too.

After that I rebuilt the kernel with SLAB instead of SLUB.  The system
is running fine for a week now.


BUG: unable to handle kernel NULL pointer dereference at virtual address
0013
 printing eip:
c0118ef5
*pdpt = 1d044001
*pde = 20946067
*pte = 
Oops: 0002 [#1]
CPU:0
EIP:0060:[dup_fd+181/432]Not tainted VLI
EFLAGS: 00010286   (2.6.22.1-jk1-exec-shield #1)
EIP is at dup_fd+0xb5/0x1b0
eax: f0f30128   ebx: 0013   ecx:    edx: 000c
esi: f0f300ec   edi: f537b7ac   ebp: f537b7e4   esp: d94cbef8
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process udev (pid: 9491, ti=d94ca000 task=f6b36a00 task.ti=d94ca000)
Stack: 0001 f537b788 0020 f0f30128 f537b780 f5784f00 
c18e5370
   01200011 c0119034 fff4 f5784f00 c0119360 dd044270 de5469a0
f2b82a80
   251a f5784fbc d94cbfb8 bfb1bbe8 c040d0d0 c18e5370 01200011
b7f734a8
Call Trace:
 [copy_files+68/96] copy_files+0x44/0x60
 [copy_process+624/2752] copy_process+0x270/0xac0
 [do_fork+100/496] do_fork+0x64/0x1f0
 [sys_clone+50/64] sys_clone+0x32/0x40
 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
 ===
Code: 08 f3 a5 89 c1 83 e1 03 74 02 f3 a4 8b 5c 24 08 85 db 74 23 89 f6
8b 44 24 0c 8b 08 83 c0 04 89 44 24 0c 85 c9 0f 84 a1 00 00 00  41
14 89 4d 00 83 c5 04 4b 75 df 8b 4c 24 04 31 f6 89 ef 8b
EIP: [dup_fd+181/432] dup_fd+0xb5/0x1b0 SS:ESP 0068:d94cbef8


Juergen Kreileder wrote:
> I got the appended BUG from a 32-bit 2.6.22.1 kernel (with exec-shield
> patch and PAE enabled) on an Athlon64 with dmsetup 1.02.03 and lvm2
> v2.02.02.
> (Note, the message comes from the vanilla kernel, not from the
> exec-shiled patch.)
>
> I wasn't able to reproduce the problem so far.  The machine creates
> several snapshot volumes every 4 hours and worked fine with the new
> kernel for several days.  It had 2.6.16.12+exec-shield before and ran
> flawlessy for over a year.
>
>
> kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> BUG: unable to handle kernel paging request at virtual address f551df78
>  printing eip:
> f551df78
> *pdpt = 1001
> *pde = 8000354001e3
> *pte = 9293396c5d22e546
> Oops: 0011 [#1]
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010286   (2.6.22.1-jk1-exec-shield #1)
> EIP is at 0xf551df78
> eax: f551df4c   ebx: f551df4c   ecx:    edx: f551df78
> esi: f551df78   edi:    ebp:    esp: e8ee5db4
> ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
> Process lvcreate (pid: 25916, ti=e8ee4000 task=f7358a00 task.ti=e8ee4000)
> Stack: c02088c4 f551df64 c02088d0 c03dd95e c64ccf00 c0209118 0287 c03dd95e
>0287 c018e38b c03dd952 d3e460e8 c018e393 c192a90c  c192b900
>c03dd952 f557a600 f59bbcc0  c0157664 f557a64c f557a600 c01575be
> Call Trace:
>  [kobject_cleanup+116/128] kobject_cleanup+0x74/0x80
>  [kobject_release+0/16] kobject_release+0x0/0x10
>  [kref_put+56/160] kref_put+0x38/0xa0
>  [sysfs_hash_and_remove+267/320] sysfs_hash_and_remove+0x10b/0x140
>  [sysfs_hash_and_remove+275/320] sysfs_hash_and_remove+0x113/0x140
>  [sysfs_slab_alias+100/128] sysfs_slab_alias+0x64/0x80
>  [sysfs_slab_add+174/208] sysfs_slab_add+0xae/0xd0
>  [kmem_cache_create+236/320] kmem_cache_create+0xec/0x140
>  [jobs_init+46/128] jobs_init+0x2e/0x80
>  [kcopyd_init+45/176] kcopyd_init+0x2d/0xb0
>  [kcopyd_client_create+28/208] kcopyd_client_create+0x1c/0xd0
>  [init_hash_tables+142/192] init_hash_tables+0x8e/0xc0
>  [snapshot_ctr+506/752] snapshot_ctr+0x1fa/0x2f0
>  [dm_split_args+47/272] dm_split_args+0x2f/0x110
>  [dm_table_add_target+252/400] dm_table_add_target+0xfc/0x190
>  [vmalloc+32/48] vmalloc+0x20/0x30
>  [populate_table+98/192] populate_table+0x62/0xc0
>  [table_load+82/240] table_load+0x52/0xf0
>  [table_load+0/240] table_load+0x0/0xf0
>  [ctl_ioctl+209/288] ctl_ioctl+0xd1/0x120
>  [ctl_ioctl+0/288] ctl_ioctl+0x0/0x120
>  [do_ioctl+59/96] do_ioctl+0x3b/0x60
>  [vfs_ioctl+94/416] vfs_ioctl+0x5e/0x1a0
>  [sys_ioctl+61/128] sys_ioctl+0x3d/0x80
>  [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
>  ===
> Code: 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 20 00 00 00 00 
> 00 00 \
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <78> df 51 f5 78 df 51 f5 
> 74 1b 8b \
> f7 00 00 00 00 00 00 00 00 32
> EIP: [] 0xf551df78 SS:ESP 0068:e8ee5db4

Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: lvcreate on 2.6.22.1: kernel tried to execute NX-protected page

2007-08-05 Thread Juergen Kreileder
Arjan van de Ven wrote:
> On Sun, 2007-08-05 at 21:03 +0200, Juergen Kreileder wrote:
>> I've upgraded devmapper to 1.02.20 and lvm2 to 2.02.26.  Didn't help much,
>> I just got a the same BUG again:
>>
>> kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
>> BUG: unable to handle kernel paging request at virtual address f492c1f8
> 
> 
> I suspect this is a module that got unloaded but still had some function
> pointer registered somewhere.
> 
> do you know if/which module that could be?
> (one trick is to compile the kernel such that you don't allow modules to
> be unloaded at all; if that makes it work it's clearly the type of bug I
> described above)

It's a static kernel, no modules.  I've attached the config.


Juergen




config-2.6.22.1-jk1-exec-shield.gz
Description: GNU Zip compressed data


Re: lvcreate on 2.6.22.1: kernel tried to execute NX-protected page

2007-08-05 Thread Juergen Kreileder
9/288] ctl_ioctl+0xd1/0x120
>  [ctl_ioctl+0/288] ctl_ioctl+0x0/0x120
>  [do_ioctl+59/96] do_ioctl+0x3b/0x60
>  [vfs_ioctl+94/416] vfs_ioctl+0x5e/0x1a0
>  [sys_ioctl+61/128] sys_ioctl+0x3d/0x80
>  [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
>  ===
> Code: 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 20 00 00 00 00 
> 00 00 \
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <78> df 51 f5 78 df 51 f5 
> 74 1b 8b \
> f7 00 00 00 00 00 00 00 00 32
> EIP: [] 0xf551df78 SS:ESP 0068:e8ee5db4

Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


lvcreate on 2.6.22.1: kernel tried to execute NX-protected page

2007-08-03 Thread Juergen Kreileder
Hi,

I got the appended BUG from a 32-bit 2.6.22.1 kernel (with exec-shield
patch and PAE enabled) on an Athlon64 with dmsetup 1.02.03 and lvm2
v2.02.02.
(Note, the message comes from the vanilla kernel, not from the
exec-shiled patch.)

I wasn't able to reproduce the problem so far.  The machine creates
several snapshot volumes every 4 hours and worked fine with the new
kernel for several days.  It had 2.6.16.12+exec-shield before and ran
flawlessy for over a year.


kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
BUG: unable to handle kernel paging request at virtual address f551df78
 printing eip:
f551df78
*pdpt = 1001
*pde = 8000354001e3
*pte = 9293396c5d22e546
Oops: 0011 [#1]
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286   (2.6.22.1-jk1-exec-shield #1)
EIP is at 0xf551df78
eax: f551df4c   ebx: f551df4c   ecx:    edx: f551df78
esi: f551df78   edi:    ebp:    esp: e8ee5db4
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process lvcreate (pid: 25916, ti=e8ee4000 task=f7358a00 task.ti=e8ee4000)
Stack: c02088c4 f551df64 c02088d0 c03dd95e c64ccf00 c0209118 0287 c03dd95e
   0287 c018e38b c03dd952 d3e460e8 c018e393 c192a90c  c192b900
   c03dd952 f557a600 f59bbcc0  c0157664 f557a64c f557a600 c01575be
Call Trace:
 [kobject_cleanup+116/128] kobject_cleanup+0x74/0x80
 [kobject_release+0/16] kobject_release+0x0/0x10
 [kref_put+56/160] kref_put+0x38/0xa0
 [sysfs_hash_and_remove+267/320] sysfs_hash_and_remove+0x10b/0x140
 [sysfs_hash_and_remove+275/320] sysfs_hash_and_remove+0x113/0x140
 [sysfs_slab_alias+100/128] sysfs_slab_alias+0x64/0x80
 [sysfs_slab_add+174/208] sysfs_slab_add+0xae/0xd0
 [kmem_cache_create+236/320] kmem_cache_create+0xec/0x140
 [jobs_init+46/128] jobs_init+0x2e/0x80
 [kcopyd_init+45/176] kcopyd_init+0x2d/0xb0
 [kcopyd_client_create+28/208] kcopyd_client_create+0x1c/0xd0
 [init_hash_tables+142/192] init_hash_tables+0x8e/0xc0
 [snapshot_ctr+506/752] snapshot_ctr+0x1fa/0x2f0
 [dm_split_args+47/272] dm_split_args+0x2f/0x110
 [dm_table_add_target+252/400] dm_table_add_target+0xfc/0x190
 [vmalloc+32/48] vmalloc+0x20/0x30
 [populate_table+98/192] populate_table+0x62/0xc0
 [table_load+82/240] table_load+0x52/0xf0
 [table_load+0/240] table_load+0x0/0xf0
 [ctl_ioctl+209/288] ctl_ioctl+0xd1/0x120
 [ctl_ioctl+0/288] ctl_ioctl+0x0/0x120
 [do_ioctl+59/96] do_ioctl+0x3b/0x60
 [vfs_ioctl+94/416] vfs_ioctl+0x5e/0x1a0
 [sys_ioctl+61/128] sys_ioctl+0x3d/0x80
 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
 ===
Code: 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 20 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <78> df 51 f5 78 df 51 
f5 74 1b 8b f7 00 00 00 00 00 00 00 00 32
EIP: [] 0xf551df78 SS:ESP 0068:e8ee5db4


Juergen



config-2.6.22.1-jk1-exec-shield.gz
Description: Binary data


-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/


Re: 2.6.12-rc2-mm3

2005-04-17 Thread Juergen Kreileder
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

> On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
>> Juergen Kreileder <[EMAIL PROTECTED]> writes:
>>
>>> Andrew Morton <[EMAIL PROTECTED]> writes:
>>>
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>>
>>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>
>> I think I finally found the culprit.  Both rc2-mm3 and rc1-mm1 work
>> fine when I reverse the timer-* patches.
>>
>> Any idea?  Bug in my ppc64 gcc?
>
> Or a bug in those patches,

Probably.  I've tried a different toolchain now (3.4.3), didn't help.


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12-rc2-mm3

2005-04-15 Thread Juergen Kreileder
Juergen Kreileder <[EMAIL PROTECTED]> writes:

> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.

I think I finally found the culprit.  Both rc2-mm3 and rc1-mm1 work
fine when I reverse the timer-* patches.

Any idea?  Bug in my ppc64 gcc?


    Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12-rc2-mm3

2005-04-12 Thread Juergen Kreileder
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

> On Tue, 2005-04-12 at 06:42 +0200, Juergen Kreileder wrote:
>> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>>
>>> On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
>>>> Andrew Morton <[EMAIL PROTECTED]> writes:
>>>>
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>>>
>>>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>>>
>>>> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all
>>>> since -rc1-mm3) lock up randomly.  The easiest way to reproduce
>>>> the problem seems to be running Azareus.  So it might be network
>>>> related, but I'm not 100% sure about that, there was a least one
>>>> deadlock with virtually no network usage.
>>>
>>> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
>>> test without it and let me know if it makes a difference ?
>>
>> IIRC I had disabled that for rc2-mm2 and it didn't make a
>> difference.  I'll disable it again when I try older versions.
>>
>> I just got another crash with rc2-mm3.  The crash was a bit
>> different this time, I still could move the mouse pointer and the
>> logs contained some info:
>
> Ok, what about non-mm  ? (just plain rc2)

I've tried older kernels now.  rc1-mm1 locks up (no logs); plain rc1
seems to be OK (running fine for several hours now).

Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12-rc2-mm3

2005-04-12 Thread Juergen Kreileder
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

>>>>> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
>>>>> test without it and let me know if it makes a difference ?
>>>>
>>>> IIRC I had disabled that for rc2-mm2 and it didn't make a
>>>> difference.  I'll disable it again when I try older versions.
>>>>
>>>> I just got another crash with rc2-mm3.  The crash was a bit
>>>> different this time, I still could move the mouse pointer and the
>>>> logs contained some info:
>>>
>>> Ok, what about non-mm  ? (just plain rc2)
>>
>> I've tried older kernels now.  rc1-mm1 locks up (no logs); plain
>> rc1 seems to be OK (running fine for several hours now).
>
> Interesting. Please try -rc2 too...

Works fine so far.


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12-rc2-mm3

2005-04-11 Thread Juergen Kreileder
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

> On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
>> Andrew Morton <[EMAIL PROTECTED]> writes:
>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>
>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>
>> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
>> -rc1-mm3) lock up randomly.  The easiest way to reproduce the
>> problem seems to be running Azareus.  So it might be network
>> related, but I'm not 100% sure about that, there was a least one
>> deadlock with virtually no network usage.
>
> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
> test without it and let me know if it makes a difference ?

IIRC I had disabled that for rc2-mm2 and it didn't make a difference.
I'll disable it again when I try older versions.

I just got another crash with rc2-mm3.  The crash was a bit different
this time, I still could move the mouse pointer and the logs contained
some info:

Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
[c0017690b860] [00069a73] 0x69a73 (unreliable)
[c0017690b900] [c003b300] .__schedule_tail+0x9c/0x1b4
[c0017690b9a0] [c03162b0] .schedule+0x324/0x610
[c0017690ba80] [c03177e8] .schedule_timeout+0xfc/0x104
[c0017690bb60] [c00b6118] .do_select+0x278/0x4c4
[c0017690bcb0] [c00d6f4c] .compat_sys_select+0x390/0x690
[c0017690bdc0] [c0019eb8] .ppc32_select+0x14/0x28
[c0017690be30] [c000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c0016fe23860] [0413] 0x413 (unreliable)
[c0016fe23900] [c003b300] .__schedule_tail+0x9c/0x1b4
[c0016fe239a0] [c03162b0] .schedule+0x324/0x610
[c0016fe23a80] [c0317774] .schedule_timeout+0x88/0x104
[c0016fe23b60] [c00b6118] .do_select+0x278/0x4c4
[c0016fe23cb0] [c00d6f4c] .compat_sys_select+0x390/0x690
[c0016fe23dc0] [c0019eb8] .ppc32_select+0x14/0x28
[c0016fe23e30] [c000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c00175d2b860] [0163] 0x163 (unreliable)
[c00175d2b900] [c003b300] .__schedule_tail+0x9c/0x1b4
[c00175d2b9a0] [c03162b0] .schedule+0x324/0x610
[c00175d2ba80] [c0317774] .schedule_timeout+0x88/0x104
[c00175d2bb60] [c00b6118] .do_select+0x278/0x4c4
[c00175d2bcb0] [c00d6f4c] .compat_sys_select+0x390/0x690
[c00175d2bdc0] [c0019eb8] .ppc32_select+0x14/0x28
[c00175d2be30] [c000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c00178a17860] [0eb1] 0xeb1 (unreliable)
[c00178a17900] [c003b300] .__schedule_tail+0x9c/0x1b4
[c00178a179a0] [c03162b0] .schedule+0x324/0x610
[c00178a17a80] [c0317774] .schedule_timeout+0x88/0x104
[c00178a17b60] [c00b6118] .do_select+0x278/0x4c4
[c00178a17cb0] [c00d6f4c] .compat_sys_select+0x390/0x690
[c00178a17dc0] [c0019eb8] .ppc32_select+0x14/0x28
[c00178a17e30] [c000da00] syscall_exit+0x0/0x18
Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52
Call Trace:
[c001767fba10] [1bca] 0x1bca (unreliable)

and so on until the machine switched into jet-fighter mode after:

[c0016f887a10] [0001fc8c] 0x1fc8c (unreliable)
[c0016f887ab0] [c003b300] .__schedule_tail+0x9c/0x1b4
[c0016f887b50] [c03162b0] .schedule+0x324/0x610
[c0016f887c30] [c0317774] .schedule_timeout+0x88/0x104
[c0016f887d10] [c00b6bb4] .sys_poll+0x3b8/0x4dc
[c0016f887e30] [c000da00] syscall_exit+0x0/0x18
Oops: Machine check, sig: 0 [#1]


Machine info:
* PowerMac7,2 with 2x 2GHz
* 4GB RAM
* 2 disks with ext3 partitions on top of LVM2
* Radeon 9800Pro with radeonfb and X (from Debian sid) at 1600x1200
* USB Mouse via evdev
* Bluetooth enabled but unused
* Firewire disabled
* No PCI cards
* Kernel compiled with gcc-3.4.2


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12-rc2-mm3

2005-04-11 Thread Juergen Kreileder
_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_RELAYFS_FS=m
CONFIG_HFS_FS=y
CONFIG_HFSPLUS_FS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_IRQSTACKS=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/


Re: Logitech MX1000 Horizontal Scrolling

2005-04-05 Thread Juergen Kreileder
Esben Stien <[EMAIL PROTECTED]> writes:

> Esben Stien <[EMAIL PROTECTED]> writes:
>
>> can't find a single problem with the device.
>
> I should mention a couple of things after some testing: There are
> some inconsistencies with regard to cruise control.
>
> When I press TOP CLICK BACKWARD/TOP CLICK FORWARD to cruise control
> down/up, it waits about 100ms

The pause is actually generated by the device, probably to make single
step scrolling easier.

> before it starts cruising. This means that pressing a single click
> does not move me anywhere. I have to hold the key down and wait
> until it starts cruising.

That's a problem with xbindkeys. Without xbindkeys, the X events are
(p = press, r = release)

p 11/12, p 4/5, r 4/5, ( , ( p 4/5, r 4/5 )* )?, r 11/12

As the 11/12 events are a bit annoying (Mozilla, but not Firefox,
interprets them as a left click), I use xbindkeys to bind them to
nothing.  But xbindkeys seems to have problems with the press 11/12
and release 11/12 events being interrupted by 4/5 events, it eats
everything before the pause =>

( , ( p 4/5, r 4/5 )* )?, r 11/12

> When I press HORIZONTAL LEFT/HORIZONTAL RIGHT to cruise control
> left/right, it starts immediately going one step in the direction,
> then waits about 100ms before it starts cruising left/right
> again. This means that a single click takes me one click in the
> horizontal direction.

For horizontal scrolling I see:

p 6/7, r 6/7, ( , ( p 6/7, r 6/7 )* )?

That's OK with me.  If vertical scrolling would work the same way
(ie. without the additional 11/12 events), I'd be happy.

Anyhow, this looks a problem with X not the kernel.  evtest shows that
the device reports similar event sequences for tilting the wheel and
the cruise control buttons.

E.g. scrolling left by tilting the wheel:

,
| Event: time 1112723029.967722, type 1 (Key), code 280 (?), value 1
| Event: time 1112723029.967729, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723029.983709, type 2 (Relative), code 6 (HWheel), value -1
| Event: time 1112723029.983715, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723030.359712, type 2 (Relative), code 6 (HWheel), value -1
| Event: time 1112723030.359719, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723030.463706, type 2 (Relative), code 6 (HWheel), value -1
| Event: time 1112723030.463715, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723030.551708, type 1 (Key), code 280 (?), value 0
| Event: time 1112723030.551712, type 0 (Reset), code 0 (Reset), value 0
`

and scrolling down with the cruise controll button:

,
| Event: time 1112723159.628081, type 1 (Key), code 279 (?), value 1
| Event: time 1112723159.628090, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723159.644084, type 2 (Relative), code 8 (Wheel), value -1
| Event: time 1112723159.644091, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723160.020068, type 2 (Relative), code 8 (Wheel), value -1
| Event: time 1112723160.020075, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723160.124067, type 2 (Relative), code 8 (Wheel), value -1
| Event: time 1112723160.124075, type 0 (Reset), code 0 (Reset), value 0
| Event: time 1112723160.212060, type 1 (Key), code 279 (?), value 0
`

Note the 280 and 279 events at the start and end.


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Logitech MX1000 Horizontal Scrolling

2005-04-05 Thread Juergen Kreileder
Esben Stien <[EMAIL PROTECTED]> writes:

> "David A. Desrosiers" <[EMAIL PROTECTED]> writes:
>
>> Using these same instructions [..] doesn't work at all
>
> This is too little information to work with. Please be more specific
> as to what you've done.

I've looked at his configuration a bit, it's maybe an X bug.  I've
only tried using the MX1000 standalone, there might be some issues
when using multiple pointer devices with different button counts at
the same time (e.g. normal 3 button mouse + 12 button MX1000).


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Logitech MX1000 Horizontal Scrolling

2005-04-03 Thread Juergen Kreileder
Esben Stien <[EMAIL PROTECTED]> writes:

> Jeremy Nickurak <[EMAIL PROTECTED]> writes:
>
>> I'm playing with this under 2.6.11.4 
>
> I got 2.6.12-rc1 
>
>> The vertical cruise control buttons work properly, with the
>> exception of the extra button press.
>
> Yup, nice, I see the same

Same here.

>> But the horizontal buttons are mapping to 6/7 as non-repeat
>> buttons, and adding simulateously the 4/5 events auto-repeated for
>> as long as the button is down. That is to say, pressing the the
>> horizontal scroll in a 2d scrolling area will scroll *diagonally*
>> one step, then vertically until the button is released.
>
> Yup, seeing exactly the same here. 

Horizontal scrolling works fine for me.  I just get repeated 6/7
events, nothing else.

I'm using the configuration described at:
http://blog.blackdown.de/2005/04/03/logitech-mx1000-configuration/


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: java (and possibly other threaded apps) hanging in rt_sigsuspend

2000-12-07 Thread Juergen Kreileder

>>>>> "Frank" == Frank de Lange <[EMAIL PROTECTED]> writes:

Frank> I saw your remarks on the kernel mailing list
Frank> wrt. 'threaded processes get stuck in
Frank> rt_sigsuspend/fillonedir/exit_notify' dd. 2911-12, and
Frank> thought you might be interested in the fact that something
Frank> quite like this also happens on 2.4.0-test11 with glibc-2.2
Frank> (release), BUT NOT ALWAYS...

Frank> I can reliably hang java (Blackdown port jdk1.3, FCS) using
Frank> the -Xmx parameter (which specifies a maximum heap size),
Frank> the weird thing is that it does NOT hang which this
Frank> parameter is either not specified OR specified but larger
Frank> than a certain value. When it hangs, it always is stuck in
Frank> a rt_sigsuspend call just after a clone() call. An example:

Frank>  [frank@behemoth frank]$ java
Frank> (java starts and spits out some info, then exits as
Frank> it should)

Frank>  [frank@behemoth frank]$ java -Xmx32m
Frank> (java ALWAYS gets stuck:

Frank>  pipe([6, 7])= 0
Frank>  clone() = 14732
Frank>  [pid 14679] write(7, "\0\0\0\0\5\0\0\0~\266\2@ $T@\0 T@\0 
T@\300\265\2@\0\0\0"..., 148) = 148
Frank>  [pid 14679] rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
Frank>  [pid 14679] write(7, 
"`S\3@\0\0\0\0\20\321\377\277pD\37@\30&\5\10\0\0\0\200\0"..., 148) = 148
Frank>  [pid 14679] rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
Frank>  [pid 14679] rt_sigsuspend([]
Frank>  )

Can you reproduce this without strace?

I only see this problem when I run with 'strace -f' and java wants to
exit (apart from that java works correctly).  I don't see the dependency
on the heap size here.


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux.html
JVM'01: http://www.usenix.org/events/jvm01/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/