SLUB problems (was Re: lvcreate on 2.6.22.1: kernel tried to execute NX-protected page)
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/
SLUB problems (was Re: lvcreate on 2.6.22.1: kernel tried to execute NX-protected page)
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 ff 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:[f551df78]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: [f551df78] 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
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
l+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
[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: [f551df78] 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
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
lvcreate on 2.6.22.1: kernel tried to execute NX-protected page
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/
lvcreate on 2.6.22.1: kernel tried to execute NX-protected page
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:[f551df78]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: [f551df78] 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
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
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
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
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
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
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
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
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
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
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: 2.6.12-rc2-mm3
-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: 2.6.12-rc2-mm3
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: Logitech MX1000 Horizontal Scrolling
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
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
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
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, ( pause, ( 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 = ( 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, ( pause, ( 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
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: Logitech MX1000 Horizontal Scrolling
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
>>>>> "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/
Re: java (and possibly other threaded apps) hanging in rt_sigsuspend
"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/
