possible circular locking in reiserfs_removexattr
Hello,
I've got this while running beagle. /home is mounted with the following options:
/dev/mapper/vglinux1-lvhome /home reiserfs rw,noatime,nodiratime,user_xattr 0 0
This still happens with latest kernel (next-20080222), I can't tell when it
first appears.
===
[ INFO: possible circular locking dependency detected ]
2.6.25-rc1 #15
---
beagled/3781 is trying to acquire lock:
(_I(inode)->xattr_sem){}, at: []
reiserfs_removexattr+0x42/0xbf [reiserfs]
but task is already holding lock:
(>s_type->i_mutex_key#8){--..}, at: [] vfs_removexattr+0x59/0xc2
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (>s_type->i_mutex_key#8){--..}:
[] __lock_acquire+0x8d9/0xa83
[] reiserfs_file_release+0x171/0x3b2 [reiserfs]
[] lock_acquire+0x4c/0x63
[] reiserfs_file_release+0x171/0x3b2 [reiserfs]
[] mutex_lock_nested+0xa9/0x219
[] reiserfs_file_release+0x171/0x3b2 [reiserfs]
[] reiserfs_file_release+0x171/0x3b2 [reiserfs]
[] __fput+0x90/0x155
[] reiserfs_xattr_set+0x2a2/0x2c5 [reiserfs]
[] reiserfs_setxattr+0x7a/0xe3 [reiserfs]
[] reiserfs_setxattr+0x0/0xe3 [reiserfs]
[] vfs_setxattr+0x74/0xe4
[] setxattr+0xad/0xc7
[] _spin_unlock+0x25/0x3a
[] _atomic_dec_and_lock+0x22/0x2c
[] mntput_no_expire+0x11/0x5b
[] link_path_walk+0xa5/0xaf
[] restore_nocheck+0x12/0x15
[] do_page_fault+0x0/0x484
[] trace_hardirqs_on+0xdd/0xfd
[] kmem_cache_free+0x53/0x5a
[] trace_hardirqs_on+0xdd/0xfd
[] __user_walk_fd+0x37/0x3f
[] sys_lsetxattr+0x37/0x4a
[] restore_nocheck+0x12/0x15
[] do_page_fault+0x0/0x484
[] trace_hardirqs_on+0xdd/0xfd
[] restore_nocheck+0x12/0x15
[] sysenter_past_esp+0x5f/0xa5
[] 0x
-> #1 (_SB(s)->xattr_dir_sem){}:
[] __lock_acquire+0x8d9/0xa83
[] reiserfs_setxattr+0x68/0xe3 [reiserfs]
[] lock_acquire+0x4c/0x63
[] reiserfs_setxattr+0x68/0xe3 [reiserfs]
[] down_write+0x17/0x2f
[] reiserfs_setxattr+0x68/0xe3 [reiserfs]
[] reiserfs_setxattr+0x68/0xe3 [reiserfs]
[] reiserfs_setxattr+0x0/0xe3 [reiserfs]
[] vfs_setxattr+0x74/0xe4
[] setxattr+0xad/0xc7
[] _spin_unlock+0x25/0x3a
[] _atomic_dec_and_lock+0x22/0x2c
[] mntput_no_expire+0x11/0x5b
[] link_path_walk+0xa5/0xaf
[] restore_nocheck+0x12/0x15
[] do_page_fault+0x0/0x484
[] trace_hardirqs_on+0xdd/0xfd
[] kmem_cache_free+0x53/0x5a
[] trace_hardirqs_on+0xdd/0xfd
[] __user_walk_fd+0x37/0x3f
[] sys_lsetxattr+0x37/0x4a
[] restore_nocheck+0x12/0x15
[] do_page_fault+0x0/0x484
[] trace_hardirqs_on+0xdd/0xfd
[] restore_nocheck+0x12/0x15
[] sysenter_past_esp+0x5f/0xa5
[] 0x
-> #0 (_I(inode)->xattr_sem){}:
[] __lock_acquire+0x7f9/0xa83
[] lock_acquire+0x4c/0x63
[] reiserfs_removexattr+0x42/0xbf [reiserfs]
[] down_write+0x17/0x2f
[] reiserfs_removexattr+0x42/0xbf [reiserfs]
[] reiserfs_removexattr+0x42/0xbf [reiserfs]
[] vfs_removexattr+0x67/0xc2
[] removexattr+0x3d/0x4a
[] _spin_unlock+0x25/0x3a
[] _atomic_dec_and_lock+0x22/0x2c
[] mntput_no_expire+0x11/0x5b
[] link_path_walk+0xa5/0xaf
[] sysenter_past_esp+0x9a/0xa5
[] trace_hardirqs_on+0xdd/0xfd
[] kmem_cache_free+0x53/0x5a
[] trace_hardirqs_on+0xdd/0xfd
[] __user_walk_fd+0x37/0x3f
[] sys_lremovexattr+0x2b/0x3c
[] sysenter_past_esp+0x9a/0xa5
[] trace_hardirqs_on+0xdd/0xfd
[] sysenter_past_esp+0x9a/0xa5
[] sysenter_past_esp+0x5f/0xa5
[] 0x
other info that might help us debug this:
1 lock held by beagled/3781:
#0: (>s_type->i_mutex_key#8){--..}, at: []
vfs_removexattr+0x59/0xc2
stack backtrace:
Pid: 3781, comm: beagled Not tainted 2.6.25-rc1 #15
[] print_circular_bug_tail+0x56/0x60
[] __lock_acquire+0x7f9/0xa83
[] lock_acquire+0x4c/0x63
[] reiserfs_removexattr+0x42/0xbf [reiserfs]
[] down_write+0x17/0x2f
[] reiserfs_removexattr+0x42/0xbf [reiserfs]
[] reiserfs_removexattr+0x42/0xbf [reiserfs]
[] vfs_removexattr+0x67/0xc2
[] removexattr+0x3d/0x4a
[] _spin_unlock+0x25/0x3a
[] _atomic_dec_and_lock+0x22/0x2c
[] mntput_no_expire+0x11/0x5b
[] link_path_walk+0xa5/0xaf
[] sysenter_past_esp+0x9a/0xa5
[] trace_hardirqs_on+0xdd/0xfd
[] kmem_cache_free+0x53/0x5a
[] trace_hardirqs_on+0xdd/0xfd
[] __user_walk_fd+0x37/0x3f
[] sys_lremovexattr+0x2b/0x3c
[] sysenter_past_esp+0x9a/0xa5
[] trace_hardirqs_on+0xdd/0xfd
[] sysenter_past_esp+0x9a/0xa5
[] sysenter_past_esp+0x5f/0xa5
===
step to reproduce:
- mount /home as reiserfs with user_xattr option.
- run "beagled --fg --debug --indexing-delay 5", and wait 10 seconds.
~~
laurent
--
To unsubscribe from this list:
possible circular locking in reiserfs_removexattr
Hello,
I've got this while running beagle. /home is mounted with the following options:
/dev/mapper/vglinux1-lvhome /home reiserfs rw,noatime,nodiratime,user_xattr 0 0
This still happens with latest kernel (next-20080222), I can't tell when it
first appears.
===
[ INFO: possible circular locking dependency detected ]
2.6.25-rc1 #15
---
beagled/3781 is trying to acquire lock:
(REISERFS_I(inode)-xattr_sem){}, at: [e1ac02fa]
reiserfs_removexattr+0x42/0xbf [reiserfs]
but task is already holding lock:
(sb-s_type-i_mutex_key#8){--..}, at: [c016f006] vfs_removexattr+0x59/0xc2
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #2 (sb-s_type-i_mutex_key#8){--..}:
[c01311f5] __lock_acquire+0x8d9/0xa83
[e1aacd0e] reiserfs_file_release+0x171/0x3b2 [reiserfs]
[c01316f2] lock_acquire+0x4c/0x63
[e1aacd0e] reiserfs_file_release+0x171/0x3b2 [reiserfs]
[c0290e57] mutex_lock_nested+0xa9/0x219
[e1aacd0e] reiserfs_file_release+0x171/0x3b2 [reiserfs]
[e1aacd0e] reiserfs_file_release+0x171/0x3b2 [reiserfs]
[c015a01b] __fput+0x90/0x155
[e1ac0ebd] reiserfs_xattr_set+0x2a2/0x2c5 [reiserfs]
[e1ac0858] reiserfs_setxattr+0x7a/0xe3 [reiserfs]
[e1ac07de] reiserfs_setxattr+0x0/0xe3 [reiserfs]
[c016f3de] vfs_setxattr+0x74/0xe4
[c016f4fb] setxattr+0xad/0xc7
[c0292243] _spin_unlock+0x25/0x3a
[c01bfb26] _atomic_dec_and_lock+0x22/0x2c
[c016aeee] mntput_no_expire+0x11/0x5b
[c0160fc2] link_path_walk+0xa5/0xaf
[c010492b] restore_nocheck+0x12/0x15
[c01122d0] do_page_fault+0x0/0x484
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c0155b72] kmem_cache_free+0x53/0x5a
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c01619e7] __user_walk_fd+0x37/0x3f
[c016f58a] sys_lsetxattr+0x37/0x4a
[c010492b] restore_nocheck+0x12/0x15
[c01122d0] do_page_fault+0x0/0x484
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c010492b] restore_nocheck+0x12/0x15
[c0104842] sysenter_past_esp+0x5f/0xa5
[] 0x
- #1 (REISERFS_SB(s)-xattr_dir_sem){}:
[c01311f5] __lock_acquire+0x8d9/0xa83
[e1ac0846] reiserfs_setxattr+0x68/0xe3 [reiserfs]
[c01316f2] lock_acquire+0x4c/0x63
[e1ac0846] reiserfs_setxattr+0x68/0xe3 [reiserfs]
[c0291367] down_write+0x17/0x2f
[e1ac0846] reiserfs_setxattr+0x68/0xe3 [reiserfs]
[e1ac0846] reiserfs_setxattr+0x68/0xe3 [reiserfs]
[e1ac07de] reiserfs_setxattr+0x0/0xe3 [reiserfs]
[c016f3de] vfs_setxattr+0x74/0xe4
[c016f4fb] setxattr+0xad/0xc7
[c0292243] _spin_unlock+0x25/0x3a
[c01bfb26] _atomic_dec_and_lock+0x22/0x2c
[c016aeee] mntput_no_expire+0x11/0x5b
[c0160fc2] link_path_walk+0xa5/0xaf
[c010492b] restore_nocheck+0x12/0x15
[c01122d0] do_page_fault+0x0/0x484
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c0155b72] kmem_cache_free+0x53/0x5a
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c01619e7] __user_walk_fd+0x37/0x3f
[c016f58a] sys_lsetxattr+0x37/0x4a
[c010492b] restore_nocheck+0x12/0x15
[c01122d0] do_page_fault+0x0/0x484
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c010492b] restore_nocheck+0x12/0x15
[c0104842] sysenter_past_esp+0x5f/0xa5
[] 0x
- #0 (REISERFS_I(inode)-xattr_sem){}:
[c0131115] __lock_acquire+0x7f9/0xa83
[c01316f2] lock_acquire+0x4c/0x63
[e1ac02fa] reiserfs_removexattr+0x42/0xbf [reiserfs]
[c0291367] down_write+0x17/0x2f
[e1ac02fa] reiserfs_removexattr+0x42/0xbf [reiserfs]
[e1ac02fa] reiserfs_removexattr+0x42/0xbf [reiserfs]
[c016f014] vfs_removexattr+0x67/0xc2
[c016f0ac] removexattr+0x3d/0x4a
[c0292243] _spin_unlock+0x25/0x3a
[c01bfb26] _atomic_dec_and_lock+0x22/0x2c
[c016aeee] mntput_no_expire+0x11/0x5b
[c0160fc2] link_path_walk+0xa5/0xaf
[c010487d] sysenter_past_esp+0x9a/0xa5
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c0155b72] kmem_cache_free+0x53/0x5a
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c01619e7] __user_walk_fd+0x37/0x3f
[c016f114] sys_lremovexattr+0x2b/0x3c
[c010487d] sysenter_past_esp+0x9a/0xa5
[c0130556] trace_hardirqs_on+0xdd/0xfd
[c010487d] sysenter_past_esp+0x9a/0xa5
[c0104842] sysenter_past_esp+0x5f/0xa5
[] 0x
other info that might help us debug this:
1 lock held by beagled/3781:
#0: (sb-s_type-i_mutex_key#8){--..}, at: [c016f006]
vfs_removexattr+0x59/0xc2
stack backtrace:
Pid: 3781, comm: beagled Not tainted 2.6.25-rc1 #15
[c012fafa] print_circular_bug_tail+0x56/0x60
[c0131115] __lock_acquire+0x7f9/0xa83
[c01316f2] lock_acquire+0x4c/0x63
[e1ac02fa] reiserfs_removexattr+0x42/0xbf [reiserfs]
[c0291367] down_write+0x17/0x2f
[e1ac02fa] reiserfs_removexattr+0x42/0xbf [reiserfs]
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Le 18.02.2008 20:35, Arjan van de Ven a écrit : Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ Got this in dmesg output: [ cut here ] WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182() Can you try the patch below? It should print a bit more information so that we can figure out who's really at fault here.. (eg it's either the diagnostics that are wrong, or ACPI is doing something evil (on behalf of the bios), we need to know what address is being triggered) I've got 2 new lines in dmesg output: ACPI: EC: Look up EC in DSDT ioremap: trying to map RAM page at 0 <=== [ cut here ] WARNING: at arch/x86/mm/ioremap.c:134 __ioremap+0xe8/0x1b6() Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #41 [] warn_on_slowpath+0x41/0x6d [] ? trace_hardirqs_off+0xb/0xd [] ? runqueue_is_locked+0x23/0x3f [] ? release_console_sem+0x1be/0x1c6 [] ? vprintk+0x2d0/0x31d [] __ioremap+0xe8/0x1b6 [] ioremap_nocache+0xa/0xc [] acpi_os_map_memory+0x11/0x1a [] acpi_ex_system_memory_space_handler+0xd3/0x228 [] ? acpi_ev_address_space_dispatch+0x142/0x1a8 [] ? acpi_ex_system_memory_space_handler+0x0/0x228 [] acpi_ev_address_space_dispatch+0x167/0x1a8 [] acpi_ex_access_region+0x1e4/0x270 [] acpi_ex_field_datum_io+0x153/0x2a1 [] ? cache_alloc_debugcheck_after+0xe9/0x165 [] acpi_ex_extract_from_field+0x91/0x224 [] ? acpi_ex_read_data_from_field+0x163/0x1b0 [] acpi_ex_read_data_from_field+0x180/0x1b0 [] acpi_ex_resolve_node_to_value+0x1aa/0x230 [] acpi_ex_resolve_to_value+0x270/0x2aa [] acpi_ex_resolve_operands+0x24e/0x52f [] acpi_ds_exec_end_op+0xb7/0x4f4 [] acpi_ps_parse_loop+0x5e5/0x79c [] acpi_ps_parse_aml+0xb2/0x2dd [] acpi_ps_execute_method+0x13d/0x20d [] acpi_ns_evaluate+0x10e/0x1b0 [] acpi_ut_evaluate_object+0x57/0x1a1 [] acpi_ut_execute_STA+0x22/0x7b [] ? acpi_ut_release_mutex+0x85/0x8f [] acpi_ns_get_device_callback+0x5a/0x121 [] acpi_ns_walk_namespace+0xfa/0x114 [] acpi_get_devices+0x47/0x5d [] ? acpi_ns_get_device_callback+0x0/0x121 [] ? ec_parse_device+0x0/0x6e [] acpi_ec_ecdt_probe+0xaa/0x10a [] acpi_init+0x73/0x21e [] ? class_create+0x4b/0x64 [] kernel_init+0xa3/0x1f3 [] ? restore_nocheck_notrace+0x0/0xe [] ? kernel_init+0x0/0x1f3 [] ? kernel_init+0x0/0x1f3 [] kernel_thread_helper+0x7/0x10 === ---[ end trace 4eaa2a86a8e2da22 ]--- ioremap: trying to map RAM page at 0 <=== Completing Region/Field/Buffer/Package initialization: Hope this helps. -- laurent -- 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.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Le 18.02.2008 20:35, Arjan van de Ven a écrit : Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ Got this in dmesg output: [ cut here ] WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182() Can you try the patch below? It should print a bit more information so that we can figure out who's really at fault here.. (eg it's either the diagnostics that are wrong, or ACPI is doing something evil (on behalf of the bios), we need to know what address is being triggered) I've got 2 new lines in dmesg output: ACPI: EC: Look up EC in DSDT ioremap: trying to map RAM page at 0 === [ cut here ] WARNING: at arch/x86/mm/ioremap.c:134 __ioremap+0xe8/0x1b6() Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #41 [c0118989] warn_on_slowpath+0x41/0x6d [c0130ae6] ? trace_hardirqs_off+0xb/0xd [c0116326] ? runqueue_is_locked+0x23/0x3f [c0118d31] ? release_console_sem+0x1be/0x1c6 [c0119304] ? vprintk+0x2d0/0x31d [c01129e6] __ioremap+0xe8/0x1b6 [c0112acd] ioremap_nocache+0xa/0xc [c02a68a7] acpi_os_map_memory+0x11/0x1a [c020b6c7] acpi_ex_system_memory_space_handler+0xd3/0x228 [c0203c08] ? acpi_ev_address_space_dispatch+0x142/0x1a8 [c020b5f4] ? acpi_ex_system_memory_space_handler+0x0/0x228 [c0203c2d] acpi_ev_address_space_dispatch+0x167/0x1a8 [c020840d] acpi_ex_access_region+0x1e4/0x270 [c02085ec] acpi_ex_field_datum_io+0x153/0x2a1 [c0158af4] ? cache_alloc_debugcheck_after+0xe9/0x165 [c02087cb] acpi_ex_extract_from_field+0x91/0x224 [c0206bff] ? acpi_ex_read_data_from_field+0x163/0x1b0 [c0206c1c] acpi_ex_read_data_from_field+0x180/0x1b0 [c020d286] acpi_ex_resolve_node_to_value+0x1aa/0x230 [c0207a62] acpi_ex_resolve_to_value+0x270/0x2aa [c0209e77] acpi_ex_resolve_operands+0x24e/0x52f [c0200857] acpi_ds_exec_end_op+0xb7/0x4f4 [c0212d81] acpi_ps_parse_loop+0x5e5/0x79c [c021210c] acpi_ps_parse_aml+0xb2/0x2dd [c021353c] acpi_ps_execute_method+0x13d/0x20d [c020fba2] acpi_ns_evaluate+0x10e/0x1b0 [c02164fa] acpi_ut_evaluate_object+0x57/0x1a1 [c02166fe] acpi_ut_execute_STA+0x22/0x7b [c0218d91] ? acpi_ut_release_mutex+0x85/0x8f [c020f48d] acpi_ns_get_device_callback+0x5a/0x121 [c021176e] acpi_ns_walk_namespace+0xfa/0x114 [c020f3b1] acpi_get_devices+0x47/0x5d [c020f433] ? acpi_ns_get_device_callback+0x0/0x121 [c021ce7a] ? ec_parse_device+0x0/0x6e [c03a4460] acpi_ec_ecdt_probe+0xaa/0x10a [c03a404b] acpi_init+0x73/0x21e [c023e5eb] ? class_create+0x4b/0x64 [c0390652] kernel_init+0xa3/0x1f3 [c0103a4e] ? restore_nocheck_notrace+0x0/0xe [c03905af] ? kernel_init+0x0/0x1f3 [c03905af] ? kernel_init+0x0/0x1f3 [c01045a7] kernel_thread_helper+0x7/0x10 === ---[ end trace 4eaa2a86a8e2da22 ]--- ioremap: trying to map RAM page at 0 === Completing Region/Field/Buffer/Package initialization: Hope this helps. -- laurent -- 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.24-rc4-mm1: VDSOSYM build error
Le 05.12.2007 06:17, Andrew Morton a écrit : > Temporarily at > http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/ > Will appear later at > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/ LDS arch/x86/vdso/vdso32/vdso32.lds AS arch/x86/vdso/vdso32/note.o AS arch/x86/vdso/vdso32/int80.o VDSOarch/x86/vdso/vdso32-int80.so.dbg OBJCOPY arch/x86/vdso/vdso32-int80.so AS arch/x86/vdso/vdso32/sysenter.o VDSOarch/x86/vdso/vdso32-sysenter.so.dbg OBJCOPY arch/x86/vdso/vdso32-sysenter.so AS arch/x86/vdso/vdso32.o CC arch/x86/vdso/vdso32-setup.o VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds VDSOSYM arch/x86/vdso/vdso32-syms.lds --- - 2007-12-06 23:23:08.785302925 +0100 +++ arch/x86/vdso/vdso32-int80-syms.lds 2007-12-06 23:23:08.0 +0100 @@ -3,4 +3,3 @@ VDSO32_sigreturn = 0x0400; VDSO32_vsyscall = 0x0414; VDSO32_vsyscall_eh_frame_size = 0x044; -VDSO32_vsyscall_eh_frame_size = 0x058; make[1]: *** [arch/x86/vdso/vdso32-syms.lds] Error 1 make: *** [arch/x86/vdso] Error 2 # cat arch/x86/vdso/vdso32-int80-syms.lds VDSO32_PRELINK = 0x0; VDSO32_rt_sigreturn = 0x040c; VDSO32_sigreturn = 0x0400; VDSO32_vsyscall = 0x0414; VDSO32_vsyscall_eh_frame_size = 0x044; # cat arch/x86/vdso/vdso32-sysenter-syms.lds VDSO32_PRELINK = 0x0; VDSO32_SYSENTER_RETURN = 0x0424; VDSO32_rt_sigreturn = 0x040c; VDSO32_sigreturn = 0x0400; VDSO32_vsyscall = 0x0414; VDSO32_vsyscall_eh_frame_size = 0x058; # scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux calimero 2.6.24-rc4-g81b45b40 #2 PREEMPT Thu Dec 6 00:39:02 CET 2007 i686 GNU/Linux Gnu C 4.1.3 Gnu make 3.81 binutils 2.18 util-linux 2.13 mount 2.13 module-init-tools 3.3-pre2 e2fsprogs 1.40.2 reiserfsprogs 3.6.19 reiser4progs 1.0.6 pcmciautils014 PPP2.4.4 Linux C Library2.6.1 Dynamic linker (ldd) 2.6.1 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 oprofile 0.9.3 Sh-utils 5.97 udev 113 wireless-tools 29 Modules Loaded radeon drm lp nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event firewire_ohci firewire_core snd_seq sg crc_itu_t snd_timer snd_seq_device sr_mod cdrom uhci_hcd snd i2c_viapro ohci1394 ata_generic pcspkr floppy 8250_pnp 8250 serial_core soundcore snd_page_alloc via686a rtc ieee1394 usbcore parport_pc parport ne2k_pci 8390 via_agp agpgart evdev dm_snapshot reiserfs sd_mod pata_via libata scsi_mod dm_mirror dm_mod .config attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc4-mm1 # Thu Dec 6 23:05:19 2007 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y
Re: 2.6.24-rc4-mm1: VDSOSYM build error
Le 05.12.2007 06:17, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/ LDS arch/x86/vdso/vdso32/vdso32.lds AS arch/x86/vdso/vdso32/note.o AS arch/x86/vdso/vdso32/int80.o VDSOarch/x86/vdso/vdso32-int80.so.dbg OBJCOPY arch/x86/vdso/vdso32-int80.so AS arch/x86/vdso/vdso32/sysenter.o VDSOarch/x86/vdso/vdso32-sysenter.so.dbg OBJCOPY arch/x86/vdso/vdso32-sysenter.so AS arch/x86/vdso/vdso32.o CC arch/x86/vdso/vdso32-setup.o VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds VDSOSYM arch/x86/vdso/vdso32-syms.lds --- - 2007-12-06 23:23:08.785302925 +0100 +++ arch/x86/vdso/vdso32-int80-syms.lds 2007-12-06 23:23:08.0 +0100 @@ -3,4 +3,3 @@ VDSO32_sigreturn = 0x0400; VDSO32_vsyscall = 0x0414; VDSO32_vsyscall_eh_frame_size = 0x044; -VDSO32_vsyscall_eh_frame_size = 0x058; make[1]: *** [arch/x86/vdso/vdso32-syms.lds] Error 1 make: *** [arch/x86/vdso] Error 2 # cat arch/x86/vdso/vdso32-int80-syms.lds VDSO32_PRELINK = 0x0; VDSO32_rt_sigreturn = 0x040c; VDSO32_sigreturn = 0x0400; VDSO32_vsyscall = 0x0414; VDSO32_vsyscall_eh_frame_size = 0x044; # cat arch/x86/vdso/vdso32-sysenter-syms.lds VDSO32_PRELINK = 0x0; VDSO32_SYSENTER_RETURN = 0x0424; VDSO32_rt_sigreturn = 0x040c; VDSO32_sigreturn = 0x0400; VDSO32_vsyscall = 0x0414; VDSO32_vsyscall_eh_frame_size = 0x058; # scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux calimero 2.6.24-rc4-g81b45b40 #2 PREEMPT Thu Dec 6 00:39:02 CET 2007 i686 GNU/Linux Gnu C 4.1.3 Gnu make 3.81 binutils 2.18 util-linux 2.13 mount 2.13 module-init-tools 3.3-pre2 e2fsprogs 1.40.2 reiserfsprogs 3.6.19 reiser4progs 1.0.6 pcmciautils014 PPP2.4.4 Linux C Library2.6.1 Dynamic linker (ldd) 2.6.1 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 oprofile 0.9.3 Sh-utils 5.97 udev 113 wireless-tools 29 Modules Loaded radeon drm lp nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event firewire_ohci firewire_core snd_seq sg crc_itu_t snd_timer snd_seq_device sr_mod cdrom uhci_hcd snd i2c_viapro ohci1394 ata_generic pcspkr floppy 8250_pnp 8250 serial_core soundcore snd_page_alloc via686a rtc ieee1394 usbcore parport_pc parport ne2k_pci 8390 via_agp agpgart evdev dm_snapshot reiserfs sd_mod pata_via libata scsi_mod dm_mirror dm_mod .config attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc4-mm1 # Thu Dec 6 23:05:19 2007 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y #
Re: 2.6.24-rc3-mm1: I/O error, system hangs
Le 25.11.2007 21:39, Laurent Riffard a écrit : > Le 25.11.2007 08:37, James Bottomley a écrit : >> On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote: >>> Le 24.11.2007 14:26, James Bottomley a écrit : >>>> OK, could you post dmesgs again, please. I actually tested this >>> with an >>>> aic79xx card, and for me it does cause Domain Validation to succeed >>>> again. >>> James, >>> >>> Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates >>> the >>> BLOCK and QUIESCE states >>> correctly" (http://lkml.org/lkml/2007/11/24/8). >>> [...] >>> [ 25.521256] scsi0 : pata_via >>> [ 25.521711] scsi1 : pata_via >>> [ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq >>> 14 >>> [ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xb808 irq >>> 15 >>> [ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 >>> [ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA >>> [ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 >>> [ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA >>> [ 25.691127] ata1.00: configured for UDMA/100 >>> [ 25.699142] ata1.01: configured for UDMA/100 >>> [ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max UDMA/33 >>> [ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr >>> [ 26.330839] ata2.00: configured for UDMA/33 >>> [ 26.490828] ata2.01: configured for MWDMA2 >>> [ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A 3.75 PQ: >>> 0 ANSI: 5 >>> [ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0 YAR4 >>> PQ: 0 ANSI: 5 >>> [ 26.509842] scsi 1:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-4165B >>> DL05 PQ: 0 ANSI: 5 >>> [ 26.511673] scsi 1:0:1:0: CD-ROME-IDECD-950E/AKU A4Q >>> PQ: 0 ANSI: 5 >> [...] >>> [ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT >>> driverbyte=DRIVER_OK,SUGGEST_OK >>> [ 60.216124] end_request: I/O error, dev sda, sector 16460 >> I think this one's quite easy: PATA devices in libata are queue depth 1 >> (since they don't do NCQ). Thus, they're peculiarly sensitive to the >> bug where we fail over queue depth requests. >> >> On the other hand, I don't see how a filesystem request is getting >> REQ_FAILFAST ... unless there's a bio or readahead issue involved. >> Anyway, could you try this patch: >> >> http://marc.info/?l=linux-scsi=119592627425498 >> >> Which should fix the queue depth issue, and see if the errors go away? > > No, this one doesn't help... still happens with 2.6.24-rc3-mm2... -- laurent - 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.24-rc3-mm1: I/O error, system hangs
Le 25.11.2007 21:39, Laurent Riffard a écrit : Le 25.11.2007 08:37, James Bottomley a écrit : On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote: Le 24.11.2007 14:26, James Bottomley a écrit : OK, could you post dmesgs again, please. I actually tested this with an aic79xx card, and for me it does cause Domain Validation to succeed again. James, Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch separates the BLOCK and QUIESCE states correctly (http://lkml.org/lkml/2007/11/24/8). [...] [ 25.521256] scsi0 : pata_via [ 25.521711] scsi1 : pata_via [ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq 14 [ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xb808 irq 15 [ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 [ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA [ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 [ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA [ 25.691127] ata1.00: configured for UDMA/100 [ 25.699142] ata1.01: configured for UDMA/100 [ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max UDMA/33 [ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr [ 26.330839] ata2.00: configured for UDMA/33 [ 26.490828] ata2.01: configured for MWDMA2 [ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A 3.75 PQ: 0 ANSI: 5 [ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5 [ 26.509842] scsi 1:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-4165B DL05 PQ: 0 ANSI: 5 [ 26.511673] scsi 1:0:1:0: CD-ROME-IDECD-950E/AKU A4Q PQ: 0 ANSI: 5 [...] [ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK [ 60.216124] end_request: I/O error, dev sda, sector 16460 I think this one's quite easy: PATA devices in libata are queue depth 1 (since they don't do NCQ). Thus, they're peculiarly sensitive to the bug where we fail over queue depth requests. On the other hand, I don't see how a filesystem request is getting REQ_FAILFAST ... unless there's a bio or readahead issue involved. Anyway, could you try this patch: http://marc.info/?l=linux-scsim=119592627425498 Which should fix the queue depth issue, and see if the errors go away? No, this one doesn't help... still happens with 2.6.24-rc3-mm2... -- laurent - 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.24-rc3-mm1: I/O error, system hangs
Le 25.11.2007 08:37, James Bottomley a écrit : > On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote: >> Le 24.11.2007 14:26, James Bottomley a écrit : >>> OK, could you post dmesgs again, please. I actually tested this >> with an >>> aic79xx card, and for me it does cause Domain Validation to succeed >>> again. >> James, >> >> Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates >> the >> BLOCK and QUIESCE states >> correctly" (http://lkml.org/lkml/2007/11/24/8). >> >> How to reproduce : >> - boot >> - switch to a text console >> - capture dmesg in a file, sync, etc. There are 3 I/O errors, but the >> system does work. >> - switch to X console, log in the Gnome Desktop, the system partially >> hangs. >> - switch back to a text console: dmesg(1) still works, it shows some >> additonal I/O errors. At this point, any disk access makes the system >> completely hung. >> >> Additionnal data: >> - the I/O errors always happen on the same blocks. >> >> plain text document attachment (dmesg-2.6.24-rc3-mm1-patched) > [...] >> [ 25.521256] scsi0 : pata_via >> [ 25.521711] scsi1 : pata_via >> [ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq >> 14 >> [ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xb808 irq >> 15 >> [ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 >> [ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA >> [ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 >> [ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA >> [ 25.691127] ata1.00: configured for UDMA/100 >> [ 25.699142] ata1.01: configured for UDMA/100 >> [ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max UDMA/33 >> [ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr >> [ 26.330839] ata2.00: configured for UDMA/33 >> [ 26.490828] ata2.01: configured for MWDMA2 >> [ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A 3.75 PQ: 0 >> ANSI: 5 >> [ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0 YAR4 >> PQ: 0 ANSI: 5 >> [ 26.509842] scsi 1:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-4165B >> DL05 PQ: 0 ANSI: 5 >> [ 26.511673] scsi 1:0:1:0: CD-ROME-IDECD-950E/AKU A4Q PQ: >> 0 ANSI: 5 > [...] >> [ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT >> driverbyte=DRIVER_OK,SUGGEST_OK >> [ 60.216124] end_request: I/O error, dev sda, sector 16460 > > I think this one's quite easy: PATA devices in libata are queue depth 1 > (since they don't do NCQ). Thus, they're peculiarly sensitive to the > bug where we fail over queue depth requests. > > On the other hand, I don't see how a filesystem request is getting > REQ_FAILFAST ... unless there's a bio or readahead issue involved. > Anyway, could you try this patch: > > http://marc.info/?l=linux-scsi=119592627425498 > > Which should fix the queue depth issue, and see if the errors go away? No, this one doesn't help... -- laurent - 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.24-rc3-mm1: I/O error, system hangs
Le 25.11.2007 08:37, James Bottomley a écrit : On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote: Le 24.11.2007 14:26, James Bottomley a écrit : OK, could you post dmesgs again, please. I actually tested this with an aic79xx card, and for me it does cause Domain Validation to succeed again. James, Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch separates the BLOCK and QUIESCE states correctly (http://lkml.org/lkml/2007/11/24/8). How to reproduce : - boot - switch to a text console - capture dmesg in a file, sync, etc. There are 3 I/O errors, but the system does work. - switch to X console, log in the Gnome Desktop, the system partially hangs. - switch back to a text console: dmesg(1) still works, it shows some additonal I/O errors. At this point, any disk access makes the system completely hung. Additionnal data: - the I/O errors always happen on the same blocks. plain text document attachment (dmesg-2.6.24-rc3-mm1-patched) [...] [ 25.521256] scsi0 : pata_via [ 25.521711] scsi1 : pata_via [ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq 14 [ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xb808 irq 15 [ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 [ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA [ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 [ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA [ 25.691127] ata1.00: configured for UDMA/100 [ 25.699142] ata1.01: configured for UDMA/100 [ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max UDMA/33 [ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr [ 26.330839] ata2.00: configured for UDMA/33 [ 26.490828] ata2.01: configured for MWDMA2 [ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A 3.75 PQ: 0 ANSI: 5 [ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5 [ 26.509842] scsi 1:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-4165B DL05 PQ: 0 ANSI: 5 [ 26.511673] scsi 1:0:1:0: CD-ROME-IDECD-950E/AKU A4Q PQ: 0 ANSI: 5 [...] [ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK [ 60.216124] end_request: I/O error, dev sda, sector 16460 I think this one's quite easy: PATA devices in libata are queue depth 1 (since they don't do NCQ). Thus, they're peculiarly sensitive to the bug where we fail over queue depth requests. On the other hand, I don't see how a filesystem request is getting REQ_FAILFAST ... unless there's a bio or readahead issue involved. Anyway, could you try this patch: http://marc.info/?l=linux-scsim=119592627425498 Which should fix the queue depth issue, and see if the errors go away? No, this one doesn't help... -- laurent - 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.24-rc3-mm1: I/O error, system hangs
Le 24.11.2007 14:26, James Bottomley a écrit : > On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: >> Le 24.11.2007 07:42, James Bottomley a écrit : >>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: >>>> Le 23.11.2007 12:38, Hannes Reinecke a écrit : [snip] >>>> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 >>>> does fix the problem. >>>> >>>>>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an >>>>>> error where >>>>>> I shouldn't. Checking ... >>>>>> >>>>> Ok, found it. We are blocking even special commands (ie requests with >>>>> PREEMPT not set) >>>>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes >>>>> this. >>>> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O >>>> errors. >>> I think the problem is the way we treat BLOCKED and QUIESCED (the latter >>> is the state that the domain validation uses and which we cannot kill >>> fastfail on). It's definitely wrong to kill fastfail requests when the >>> state is QUIESCE. >>> >>> This patch (which is applied on top of Hannes original) separates the >>> BLOCK and QUIESCE states correctly ... does this fix the problem? >> >> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) > > OK, could you post dmesgs again, please. I actually tested this with an > aic79xx card, and for me it does cause Domain Validation to succeed > again. James, Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates the BLOCK and QUIESCE states correctly" (http://lkml.org/lkml/2007/11/24/8). How to reproduce : - boot - switch to a text console - capture dmesg in a file, sync, etc. There are 3 I/O errors, but the system does work. - switch to X console, log in the Gnome Desktop, the system partially hangs. - switch back to a text console: dmesg(1) still works, it shows some additonal I/O errors. At this point, any disk access makes the system completely hung. Additionnal data: - the I/O errors always happen on the same blocks. -- laurent [0.00] Linux version 2.6.24-rc3-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #122 PREEMPT Fri Nov 23 18:47:58 CET 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1ffec000 (usable) [0.00] BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) [0.00] BIOS-e820: 1ffef000 - 1000 (reserved) [0.00] BIOS-e820: 1000 - 2000 (ACPI NVS) [0.00] BIOS-e820: - 0001 (reserved) [0.00] 511MB LOWMEM available. [0.00] Entering add_active_range(0, 0, 131052) 0 entries of 256 used [0.00] sizeof(struct page) = 32 [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 131052 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 131052 [0.00] On node 0 totalpages: 131052 [0.00] Node 0 memmap at 0xC100 size 4194304 first pfn 0xC100 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 991 pages used for memmap [0.00] Normal zone: 125965 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F6A80, 0014 (r0 ASUS ) [0.00] ACPI: RSDT 1FFEC000, 002C (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: FACP 1FFEC080, 0074 (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: DSDT 1FFEC100, 2CE1 (r1 ASUS A7V133-C 1000 MSFT 10B) [0.00] ACPI: FACS 1000, 0040 [0.00] ACPI: BOOT 1FFEC040, 0028 (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: PM-Timer IO Port: 0xe408 [0.00] Allocating PCI resources starting at 3000 (gap: 2000:dfff) [0.00] swsusp: Registered nosave memory region: 0009f000 - 000a [0.00] swsusp: Registered nosave memory region: 000a - 000f [0.00] swsusp: Registered nosave memory region: 000f - 0010 [0.00] Built 1 zonelists in Z
Re: 2.6.24-rc3-mm1: I/O error, system hangs
Le 24.11.2007 07:42, James Bottomley a écrit : > On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: >> Le 23.11.2007 12:38, Hannes Reinecke a écrit : >>> Hannes Reinecke wrote: >>>> Laurent Riffard wrote: >>>>> Le 21.11.2007 23:41, Andrew Morton a écrit : >>>>>> On Wed, 21 Nov 2007 22:45:22 +0100 >>>>>> Laurent Riffard <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit : >>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ >>>>>>> Hello, >>>>>>> >>>>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows >>>>>>> that a bunch of task are blocked in "D" state, they seem to wait for >>>>>>> some I/O completion. I can try to hand-copy some data if requested. >>>>>>> >>>>>>> I found these messages in dmesg: >>>>>>> >>>>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 >>>>>>> EXT3-fs: mounted filesystem with ordered data mode. >>>>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT >>>>>>> driverbyte=DRIVER_OK,SUGGEST_OK >>>>>>> end_request: I/O error, dev sda, sector 16460 >>>>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal >>>>>>> ReiserFS: sda7: using ordered data mode >>>>>>> -- >>>>>>> ReiserFS: sda7: Using r5 hash to sort names >>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT >>>>>>> driverbyte=DRIVER_OK,SUGGEST_OK >>>>>>> end_request: I/O error, dev sdb, sector 19632 >>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT >>>>>>> driverbyte=DRIVER_OK,SUGGEST_OK >>>>>>> end_request: I/O error, dev sdb, sector 40037363 >>>>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 >>>>>>> extents:1 across:1048568k >>>>>>> lp0: using parport0 (interrupt-driven). >>>>>>> >>>>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% >>>>>>> reproducible. >>>>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. >>>>>>> >>>>>>> Maybe something is broken in pata_via driver ? >>>>>>> >>>>>> Could be - >>>>>> libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch >>>>>> and >>>>>> pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch >>>>>> touch pata_via.c. >>>>> None of the above... >>>>> >>>>> I did a bisection, it spotted git-scsi-misc.patch. >>>>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. >>>>> >>>>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not >>>>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other >>>>> commits are touching documentation or drivers I don't use. I'll try >>>>> to revert only this one this evening. >> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 >> does fix the problem. >> >>>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an >>>> error where >>>> I shouldn't. Checking ... >>>> >>> Ok, found it. We are blocking even special commands (ie requests with >>> PREEMPT not set) >>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. >> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O >> errors. > > I think the problem is the way we treat BLOCKED and QUIESCED (the latter > is the state that the domain validation uses and which we cannot kill > fastfail on). It's definitely wrong to kill fastfail requests when the > state is QUIESCE. > > This patch (which is applied on top of Hannes original) separates the > BLOCK and QUIESCE states correctly ... does this fix the problem? No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) > James > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index 13e7e09..a7cf23a 100644 > ---
Re: 2.6.24-rc3-mm1: I/O error, system hangs
Le 24.11.2007 07:42, James Bottomley a écrit : On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: Le 23.11.2007 12:38, Hannes Reinecke a écrit : Hannes Reinecke wrote: Laurent Riffard wrote: Le 21.11.2007 23:41, Andrew Morton a écrit : On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard [EMAIL PROTECTED] wrote: Le 21.11.2007 05:45, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ Hello, My system hangs shortly after I logged in Gnome desktop. SysRq-W shows that a bunch of task are blocked in D state, they seem to wait for some I/O completion. I can try to hand-copy some data if requested. I found these messages in dmesg: ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 EXT3-fs: mounted filesystem with ordered data mode. sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 16460 ReiserFS: sda7: found reiserfs format 3.6 with standard journal ReiserFS: sda7: using ordered data mode -- ReiserFS: sda7: Using r5 hash to sort names sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 19632 sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 40037363 Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k lp0: using parport0 (interrupt-driven). These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. Maybe something is broken in pata_via driver ? Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. None of the above... I did a bisection, it spotted git-scsi-misc.patch. I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 [SCSI] Do not requeue requests if REQ_FAILFAST is set is the real culprit. The other commits are touching documentation or drivers I don't use. I'll try to revert only this one this evening. I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where I shouldn't. Checking ... Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set) when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. I think the problem is the way we treat BLOCKED and QUIESCED (the latter is the state that the domain validation uses and which we cannot kill fastfail on). It's definitely wrong to kill fastfail requests when the state is QUIESCE. This patch (which is applied on top of Hannes original) separates the BLOCK and QUIESCE states correctly ... does this fix the problem? No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) James diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 13e7e09..a7cf23a 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1279,18 +1279,21 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req) rejecting I/O to dead device\n); ret = BLKPREP_KILL; break; - case SDEV_QUIESCE: case SDEV_BLOCK: /* - * If the devices is blocked we defer normal commands. - */ - if (!(req-cmd_flags REQ_PREEMPT)) - ret = BLKPREP_DEFER; - /* * Return failfast requests immediately */ if (req-cmd_flags REQ_FAILFAST) ret = BLKPREP_KILL; + + /* fall through */ + + case SDEV_QUIESCE: + /* + * If the devices is blocked we defer normal commands. + */ + if (!(req-cmd_flags REQ_PREEMPT)) + ret = BLKPREP_DEFER; break; default: /* - 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.24-rc3-mm1: I/O error, system hangs
Le 24.11.2007 14:26, James Bottomley a écrit : On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote: Le 24.11.2007 07:42, James Bottomley a écrit : On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote: Le 23.11.2007 12:38, Hannes Reinecke a écrit : [snip] I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where I shouldn't. Checking ... Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set) when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. I think the problem is the way we treat BLOCKED and QUIESCED (the latter is the state that the domain validation uses and which we cannot kill fastfail on). It's definitely wrong to kill fastfail requests when the state is QUIESCE. This patch (which is applied on top of Hannes original) separates the BLOCK and QUIESCE states correctly ... does this fix the problem? No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems) OK, could you post dmesgs again, please. I actually tested this with an aic79xx card, and for me it does cause Domain Validation to succeed again. James, Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch separates the BLOCK and QUIESCE states correctly (http://lkml.org/lkml/2007/11/24/8). How to reproduce : - boot - switch to a text console - capture dmesg in a file, sync, etc. There are 3 I/O errors, but the system does work. - switch to X console, log in the Gnome Desktop, the system partially hangs. - switch back to a text console: dmesg(1) still works, it shows some additonal I/O errors. At this point, any disk access makes the system completely hung. Additionnal data: - the I/O errors always happen on the same blocks. -- laurent [0.00] Linux version 2.6.24-rc3-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #122 PREEMPT Fri Nov 23 18:47:58 CET 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1ffec000 (usable) [0.00] BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) [0.00] BIOS-e820: 1ffef000 - 1000 (reserved) [0.00] BIOS-e820: 1000 - 2000 (ACPI NVS) [0.00] BIOS-e820: - 0001 (reserved) [0.00] 511MB LOWMEM available. [0.00] Entering add_active_range(0, 0, 131052) 0 entries of 256 used [0.00] sizeof(struct page) = 32 [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] Normal 4096 - 131052 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 - 131052 [0.00] On node 0 totalpages: 131052 [0.00] Node 0 memmap at 0xC100 size 4194304 first pfn 0xC100 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 991 pages used for memmap [0.00] Normal zone: 125965 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F6A80, 0014 (r0 ASUS ) [0.00] ACPI: RSDT 1FFEC000, 002C (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: FACP 1FFEC080, 0074 (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: DSDT 1FFEC100, 2CE1 (r1 ASUS A7V133-C 1000 MSFT 10B) [0.00] ACPI: FACS 1000, 0040 [0.00] ACPI: BOOT 1FFEC040, 0028 (r1 ASUS A7V133-C 30303031 MSFT 31313031) [0.00] ACPI: PM-Timer IO Port: 0xe408 [0.00] Allocating PCI resources starting at 3000 (gap: 2000:dfff) [0.00] swsusp: Registered nosave memory region: 0009f000 - 000a [0.00] swsusp: Registered nosave memory region: 000a - 000f [0.00] swsusp: Registered nosave memory region: 000f - 0010 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130029 [0.00] Kernel command line: root=/dev/mapper/vglinux1-lv_ubuntu2 ro locale=fr_FR video=radeonfb:[EMAIL PROTECTED] resume=/dev/mapper/vglinux1-lvswap [0.00] Local APIC disabled by BIOS -- you can enable it with lapic [0.00] mapped APIC to b000 (01406000) [0.00] Enabling fast FPU save and restore... done. [0.00] Enabling unmasked SIMD FPU
Re: 2.6.24-rc3-mm1: I/O error, system hangs
Le 23.11.2007 12:38, Hannes Reinecke a écrit : > Hannes Reinecke wrote: >> Laurent Riffard wrote: >>> Le 21.11.2007 23:41, Andrew Morton a écrit : >>>> On Wed, 21 Nov 2007 22:45:22 +0100 >>>> Laurent Riffard <[EMAIL PROTECTED]> wrote: >>>> >>>>> Le 21.11.2007 05:45, Andrew Morton a écrit : >>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ >>>>> Hello, >>>>> >>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows >>>>> that a bunch of task are blocked in "D" state, they seem to wait for >>>>> some I/O completion. I can try to hand-copy some data if requested. >>>>> >>>>> I found these messages in dmesg: >>>>> >>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 >>>>> EXT3-fs: mounted filesystem with ordered data mode. >>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT >>>>> driverbyte=DRIVER_OK,SUGGEST_OK >>>>> end_request: I/O error, dev sda, sector 16460 >>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal >>>>> ReiserFS: sda7: using ordered data mode >>>>> -- >>>>> ReiserFS: sda7: Using r5 hash to sort names >>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT >>>>> driverbyte=DRIVER_OK,SUGGEST_OK >>>>> end_request: I/O error, dev sdb, sector 19632 >>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT >>>>> driverbyte=DRIVER_OK,SUGGEST_OK >>>>> end_request: I/O error, dev sdb, sector 40037363 >>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 >>>>> extents:1 across:1048568k >>>>> lp0: using parport0 (interrupt-driven). >>>>> >>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. >>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. >>>>> >>>>> Maybe something is broken in pata_via driver ? >>>>> >>>> Could be - >>>> libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch >>>> and >>>> pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch >>>> touch pata_via.c. >>> None of the above... >>> >>> I did a bisection, it spotted git-scsi-misc.patch. >>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. >>> >>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not >>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other >>> commits are touching documentation or drivers I don't use. I'll try >>> to revert only this one this evening. I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. >> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error >> where >> I shouldn't. Checking ... >> > Ok, found it. We are blocking even special commands (ie requests with PREEMPT > not set) > when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. -- laurent - 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.24-rc3-mm1: I/O error, system hangs
Le 23.11.2007 12:38, Hannes Reinecke a écrit : Hannes Reinecke wrote: Laurent Riffard wrote: Le 21.11.2007 23:41, Andrew Morton a écrit : On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard [EMAIL PROTECTED] wrote: Le 21.11.2007 05:45, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ Hello, My system hangs shortly after I logged in Gnome desktop. SysRq-W shows that a bunch of task are blocked in D state, they seem to wait for some I/O completion. I can try to hand-copy some data if requested. I found these messages in dmesg: ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 EXT3-fs: mounted filesystem with ordered data mode. sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 16460 ReiserFS: sda7: found reiserfs format 3.6 with standard journal ReiserFS: sda7: using ordered data mode -- ReiserFS: sda7: Using r5 hash to sort names sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 19632 sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 40037363 Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k lp0: using parport0 (interrupt-driven). These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. Maybe something is broken in pata_via driver ? Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. None of the above... I did a bisection, it spotted git-scsi-misc.patch. I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 [SCSI] Do not requeue requests if REQ_FAILFAST is set is the real culprit. The other commits are touching documentation or drivers I don't use. I'll try to revert only this one this evening. I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 does fix the problem. Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where I shouldn't. Checking ... Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set) when FAILFAST is set. Which is clearly wrong. The attached patch fixes this. Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors. -- laurent - 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.24-rc3-mm1: I/O error, system hangs
Le 21.11.2007 23:41, Andrew Morton a écrit : > On Wed, 21 Nov 2007 22:45:22 +0100 > Laurent Riffard <[EMAIL PROTECTED]> wrote: > >> Le 21.11.2007 05:45, Andrew Morton a écrit : >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ >> Hello, >> >> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows >> that a bunch of task are blocked in "D" state, they seem to wait for >> some I/O completion. I can try to hand-copy some data if requested. >> >> I found these messages in dmesg: >> >> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 >> EXT3-fs: mounted filesystem with ordered data mode. >> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT >> driverbyte=DRIVER_OK,SUGGEST_OK >> end_request: I/O error, dev sda, sector 16460 >> ReiserFS: sda7: found reiserfs format "3.6" with standard journal >> ReiserFS: sda7: using ordered data mode >> -- >> ReiserFS: sda7: Using r5 hash to sort names >> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT >> driverbyte=DRIVER_OK,SUGGEST_OK >> end_request: I/O error, dev sdb, sector 19632 >> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT >> driverbyte=DRIVER_OK,SUGGEST_OK >> end_request: I/O error, dev sdb, sector 40037363 >> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 >> across:1048568k >> lp0: using parport0 (interrupt-driven). >> >> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. >> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. >> >> Maybe something is broken in pata_via driver ? >> > > Could be - > libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch > and > pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch > touch pata_via.c. None of the above... I did a bisection, it spotted git-scsi-misc.patch. I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not requeue requests if REQ_FAILFAST is set" is the real culprit. The other commits are touching documentation or drivers I don't use. I'll try to revert only this one this evening. -- laurent - 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.24-rc3-mm1: I/O error, system hangs
Le 21.11.2007 23:41, Andrew Morton a écrit : On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard [EMAIL PROTECTED] wrote: Le 21.11.2007 05:45, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ Hello, My system hangs shortly after I logged in Gnome desktop. SysRq-W shows that a bunch of task are blocked in D state, they seem to wait for some I/O completion. I can try to hand-copy some data if requested. I found these messages in dmesg: ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 EXT3-fs: mounted filesystem with ordered data mode. sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 16460 ReiserFS: sda7: found reiserfs format 3.6 with standard journal ReiserFS: sda7: using ordered data mode -- ReiserFS: sda7: Using r5 hash to sort names sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 19632 sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 40037363 Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k lp0: using parport0 (interrupt-driven). These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. Maybe something is broken in pata_via driver ? Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. None of the above... I did a bisection, it spotted git-scsi-misc.patch. I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine. I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 [SCSI] Do not requeue requests if REQ_FAILFAST is set is the real culprit. The other commits are touching documentation or drivers I don't use. I'll try to revert only this one this evening. -- laurent - 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.23-mm1: BUG in reiserfs_delete_xattrs
Le 15.10.2007 20:31, Jeff Mahoney a écrit :
> Christoph Hellwig wrote:
>> On Mon, Oct 15, 2007 at 12:34:58AM +0200, Laurent Riffard wrote:
>>> reiserfs_delete_xattrs
>>> reiserfs_delete_inode
>>> generic_delete_inode
>>> generic_drop_inode
>>> iput
>>> do_unlinkat
>>> sys_unlink
>>> sys_enter_past_esp
>>>
>>> I reported a similar BUG in 2.6.22-rc8-mm2 (see
>>> http://lkml.org/lkml/2007/9/27/235). Dave Hansen sent a patch for it, I
>>> tested it and it was OK for 2.6.22-rc8-mm2.
>>>
>>> I tried this patch on 2.6.23-mm1, and it fixed the BUGs here too.
>> The delete path is a similar case as the one Dave fixed, also cause by
>> a NULL vfsmount passed to dentry_open, but through a different code-path.
>>
>> Untested fix for this problem below:
>
> Here's a patch I worked up the other night that kills off struct file
> completely from the xattr code. I've tested it locally.
Sorry Jeff, your patch does not apply on 2.6.23-mm1. The 'struct file'
removal from reiserfs_xattr_ function is already in -mm
(make-reiserfs-stop-using-struct-file-for-internal.patch).
The Dave's patch I was refering to is this one:
BEGIN =
The bug is caused by reiserfs creating a special 'struct file' with a
NULL vfsmount.
/* Opens a file pointer to the attribute associated with inode */
static struct file *open_xa_file(const struct inode *inode, const char
*name,
int flags)
{
...
fp = dentry_open(xafile, NULL, O_RDWR);
/* dentry_open dputs the dentry if it fails */
As Christoph just said, this is somewhat of a bandaid. But, it
shouldn't hurt anything.
---
lxc-dave/fs/file_table.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/open.c~fix-reiserfs-oops fs/open.c
diff -puN fs/file_table.c~fix-reiserfs-oops fs/file_table.c
--- lxc/fs/file_table.c~fix-reiserfs-oops 2007-09-27 13:32:20.0
-0700
+++ lxc-dave/fs/file_table.c2007-09-27 13:33:11.0 -0700
@@ -236,7 +236,7 @@ void fastcall __fput(struct file *file)
fops_put(file->f_op);
if (file->f_mode & FMODE_WRITE) {
put_write_access(inode);
- if (!special_file(inode->i_mode))
+ if (!special_file(inode->i_mode) && mnt)
mnt_drop_write(mnt);
}
put_pid(file->f_owner.pid);
diff -puN include/linux/mount.h~fix-reiserfs-oops include/linux/mount.h
END
Dave sent it privately to me... I guess this "bandaid" is no longer
needed now, is it?
~~
laurent
-
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.23-mm1: BUG in reiserfs_delete_xattrs
Le 15.10.2007 10:40, Christoph Hellwig a écrit :
> On Mon, Oct 15, 2007 at 12:34:58AM +0200, Laurent Riffard wrote:
>> reiserfs_delete_xattrs
>> reiserfs_delete_inode
>> generic_delete_inode
>> generic_drop_inode
>> iput
>> do_unlinkat
>> sys_unlink
>> sys_enter_past_esp
>>
>> I reported a similar BUG in 2.6.22-rc8-mm2 (see
>> http://lkml.org/lkml/2007/9/27/235). Dave Hansen sent a patch for it, I
>> tested it and it was OK for 2.6.22-rc8-mm2.
>>
>> I tried this patch on 2.6.23-mm1, and it fixed the BUGs here too.
>
> The delete path is a similar case as the one Dave fixed, also cause by
> a NULL vfsmount passed to dentry_open, but through a different code-path.
>
> Untested fix for this problem below:
Does work fine, thanks.
Tested-by: Laurent Riffard <[EMAIL PROTECTED]>
> Index: linux-2.6.23-rc8/fs/reiserfs/xattr.c
> ===
> --- linux-2.6.23-rc8.orig/fs/reiserfs/xattr.c 2007-09-30 14:13:46.0
> +0200
> +++ linux-2.6.23-rc8/fs/reiserfs/xattr.c 2007-09-30 14:18:30.0
> +0200
> @@ -207,9 +207,8 @@ static struct dentry *get_xa_file_dentry
> * we're called with i_mutex held, so there are no worries about the
> directory
> * changing underneath us.
> */
> -static int __xattr_readdir(struct file *filp, void *dirent, filldir_t
> filldir)
> +static int __xattr_readdir(struct inode *inode, void *dirent, filldir_t
> filldir)
> {
> - struct inode *inode = filp->f_path.dentry->d_inode;
> struct cpu_key pos_key; /* key of current position in the directory
> (key of directory entry) */
> INITIALIZE_PATH(path_to_entry);
> struct buffer_head *bh;
> @@ -352,24 +351,19 @@ static int __xattr_readdir(struct file *
> * this is stolen from vfs_readdir
> *
> */
> -static
> -int xattr_readdir(struct file *file, filldir_t filler, void *buf)
> +static int xattr_readdir(struct inode *inode, filldir_t filler, void *buf)
> {
> - struct inode *inode = file->f_path.dentry->d_inode;
> int res = -ENOTDIR;
> - if (!file->f_op || !file->f_op->readdir)
> - goto out;
> +
> mutex_lock_nested(>i_mutex, I_MUTEX_XATTR);
> -//down(>i_zombie);
> res = -ENOENT;
> if (!IS_DEADDIR(inode)) {
> lock_kernel();
> - res = __xattr_readdir(file, buf, filler);
> + res = __xattr_readdir(inode, buf, filler);
> unlock_kernel();
> }
> -//up(>i_zombie);
> mutex_unlock(>i_mutex);
> - out:
> +
> return res;
> }
>
> @@ -721,7 +715,6 @@ reiserfs_delete_xattrs_filler(void *buf,
> /* This is called w/ inode->i_mutex downed */
> int reiserfs_delete_xattrs(struct inode *inode)
> {
> - struct file *fp;
> struct dentry *dir, *root;
> int err = 0;
>
> @@ -742,15 +735,8 @@ int reiserfs_delete_xattrs(struct inode
> return 0;
> }
>
> - fp = dentry_open(dir, NULL, O_RDWR);
> - if (IS_ERR(fp)) {
> - err = PTR_ERR(fp);
> - /* dentry_open dputs the dentry if it fails */
> - goto out;
> - }
> -
> lock_kernel();
> - err = xattr_readdir(fp, reiserfs_delete_xattrs_filler, dir);
> + err = xattr_readdir(dir->d_inode, reiserfs_delete_xattrs_filler, dir);
> if (err) {
> unlock_kernel();
> goto out_dir;
> @@ -770,7 +756,7 @@ int reiserfs_delete_xattrs(struct inode
> unlock_kernel();
>
>out_dir:
> - fput(fp);
> + dput(dir);
>
>out:
> if (!err)
> @@ -812,7 +798,6 @@ reiserfs_chown_xattrs_filler(void *buf,
>
> int reiserfs_chown_xattrs(struct inode *inode, struct iattr *attrs)
> {
> - struct file *fp;
> struct dentry *dir;
> int err = 0;
> struct reiserfs_chown_buf buf;
> @@ -836,13 +821,6 @@ int reiserfs_chown_xattrs(struct inode *
> goto out;
> }
>
> - fp = dentry_open(dir, NULL, O_RDWR);
> - if (IS_ERR(fp)) {
> - err = PTR_ERR(fp);
> - /* dentry_open dputs the dentry if it fails */
> - goto out;
> - }
> -
> lock_kernel();
>
> attrs->ia_valid &= (ATTR_UID | ATTR_GID | ATTR_CTIME);
> @@ -850,7 +828,7 @@ int reiserfs_chown_xattrs(struct inode *
> buf.attrs = attrs;
> buf.inode = inode;
>
> - err = xattr_readdir(fp, reiserfs_chown_xattrs_filler, );
> + err = xattr_readdir(dir->d_inode, reiserfs_chown_xattrs_filler, );
> if (err)
Re: 2.6.23-mm1: BUG in reiserfs_delete_xattrs
Le 15.10.2007 10:40, Christoph Hellwig a écrit :
On Mon, Oct 15, 2007 at 12:34:58AM +0200, Laurent Riffard wrote:
reiserfs_delete_xattrs
reiserfs_delete_inode
generic_delete_inode
generic_drop_inode
iput
do_unlinkat
sys_unlink
sys_enter_past_esp
I reported a similar BUG in 2.6.22-rc8-mm2 (see
http://lkml.org/lkml/2007/9/27/235). Dave Hansen sent a patch for it, I
tested it and it was OK for 2.6.22-rc8-mm2.
I tried this patch on 2.6.23-mm1, and it fixed the BUGs here too.
The delete path is a similar case as the one Dave fixed, also cause by
a NULL vfsmount passed to dentry_open, but through a different code-path.
Untested fix for this problem below:
Does work fine, thanks.
Tested-by: Laurent Riffard [EMAIL PROTECTED]
Index: linux-2.6.23-rc8/fs/reiserfs/xattr.c
===
--- linux-2.6.23-rc8.orig/fs/reiserfs/xattr.c 2007-09-30 14:13:46.0
+0200
+++ linux-2.6.23-rc8/fs/reiserfs/xattr.c 2007-09-30 14:18:30.0
+0200
@@ -207,9 +207,8 @@ static struct dentry *get_xa_file_dentry
* we're called with i_mutex held, so there are no worries about the
directory
* changing underneath us.
*/
-static int __xattr_readdir(struct file *filp, void *dirent, filldir_t
filldir)
+static int __xattr_readdir(struct inode *inode, void *dirent, filldir_t
filldir)
{
- struct inode *inode = filp-f_path.dentry-d_inode;
struct cpu_key pos_key; /* key of current position in the directory
(key of directory entry) */
INITIALIZE_PATH(path_to_entry);
struct buffer_head *bh;
@@ -352,24 +351,19 @@ static int __xattr_readdir(struct file *
* this is stolen from vfs_readdir
*
*/
-static
-int xattr_readdir(struct file *file, filldir_t filler, void *buf)
+static int xattr_readdir(struct inode *inode, filldir_t filler, void *buf)
{
- struct inode *inode = file-f_path.dentry-d_inode;
int res = -ENOTDIR;
- if (!file-f_op || !file-f_op-readdir)
- goto out;
+
mutex_lock_nested(inode-i_mutex, I_MUTEX_XATTR);
-//down(inode-i_zombie);
res = -ENOENT;
if (!IS_DEADDIR(inode)) {
lock_kernel();
- res = __xattr_readdir(file, buf, filler);
+ res = __xattr_readdir(inode, buf, filler);
unlock_kernel();
}
-//up(inode-i_zombie);
mutex_unlock(inode-i_mutex);
- out:
+
return res;
}
@@ -721,7 +715,6 @@ reiserfs_delete_xattrs_filler(void *buf,
/* This is called w/ inode-i_mutex downed */
int reiserfs_delete_xattrs(struct inode *inode)
{
- struct file *fp;
struct dentry *dir, *root;
int err = 0;
@@ -742,15 +735,8 @@ int reiserfs_delete_xattrs(struct inode
return 0;
}
- fp = dentry_open(dir, NULL, O_RDWR);
- if (IS_ERR(fp)) {
- err = PTR_ERR(fp);
- /* dentry_open dputs the dentry if it fails */
- goto out;
- }
-
lock_kernel();
- err = xattr_readdir(fp, reiserfs_delete_xattrs_filler, dir);
+ err = xattr_readdir(dir-d_inode, reiserfs_delete_xattrs_filler, dir);
if (err) {
unlock_kernel();
goto out_dir;
@@ -770,7 +756,7 @@ int reiserfs_delete_xattrs(struct inode
unlock_kernel();
out_dir:
- fput(fp);
+ dput(dir);
out:
if (!err)
@@ -812,7 +798,6 @@ reiserfs_chown_xattrs_filler(void *buf,
int reiserfs_chown_xattrs(struct inode *inode, struct iattr *attrs)
{
- struct file *fp;
struct dentry *dir;
int err = 0;
struct reiserfs_chown_buf buf;
@@ -836,13 +821,6 @@ int reiserfs_chown_xattrs(struct inode *
goto out;
}
- fp = dentry_open(dir, NULL, O_RDWR);
- if (IS_ERR(fp)) {
- err = PTR_ERR(fp);
- /* dentry_open dputs the dentry if it fails */
- goto out;
- }
-
lock_kernel();
attrs-ia_valid = (ATTR_UID | ATTR_GID | ATTR_CTIME);
@@ -850,7 +828,7 @@ int reiserfs_chown_xattrs(struct inode *
buf.attrs = attrs;
buf.inode = inode;
- err = xattr_readdir(fp, reiserfs_chown_xattrs_filler, buf);
+ err = xattr_readdir(dir-d_inode, reiserfs_chown_xattrs_filler, buf);
if (err) {
unlock_kernel();
goto out_dir;
@@ -860,7 +838,7 @@ int reiserfs_chown_xattrs(struct inode *
unlock_kernel();
out_dir:
- fput(fp);
+ dput(dir);
out:
attrs-ia_valid = ia_valid;
@@ -1008,7 +986,6 @@ reiserfs_listxattr_filler(void *buf, con
*/
ssize_t reiserfs_listxattr(struct dentry * dentry, char *buffer, size_t size)
{
- struct file *fp;
struct dentry *dir;
int err = 0;
struct reiserfs_listxattr_buf buf;
@@ -1031,13 +1008,6 @@ ssize_t reiserfs_listxattr(struct dentry
goto out;
}
- fp
Re: 2.6.23-mm1: BUG in reiserfs_delete_xattrs
Le 15.10.2007 20:31, Jeff Mahoney a écrit :
Christoph Hellwig wrote:
On Mon, Oct 15, 2007 at 12:34:58AM +0200, Laurent Riffard wrote:
reiserfs_delete_xattrs
reiserfs_delete_inode
generic_delete_inode
generic_drop_inode
iput
do_unlinkat
sys_unlink
sys_enter_past_esp
I reported a similar BUG in 2.6.22-rc8-mm2 (see
http://lkml.org/lkml/2007/9/27/235). Dave Hansen sent a patch for it, I
tested it and it was OK for 2.6.22-rc8-mm2.
I tried this patch on 2.6.23-mm1, and it fixed the BUGs here too.
The delete path is a similar case as the one Dave fixed, also cause by
a NULL vfsmount passed to dentry_open, but through a different code-path.
Untested fix for this problem below:
Here's a patch I worked up the other night that kills off struct file
completely from the xattr code. I've tested it locally.
Sorry Jeff, your patch does not apply on 2.6.23-mm1. The 'struct file'
removal from reiserfs_xattr_ function is already in -mm
(make-reiserfs-stop-using-struct-file-for-internal.patch).
The Dave's patch I was refering to is this one:
BEGIN =
The bug is caused by reiserfs creating a special 'struct file' with a
NULL vfsmount.
/* Opens a file pointer to the attribute associated with inode */
static struct file *open_xa_file(const struct inode *inode, const char
*name,
int flags)
{
...
fp = dentry_open(xafile, NULL, O_RDWR);
/* dentry_open dputs the dentry if it fails */
As Christoph just said, this is somewhat of a bandaid. But, it
shouldn't hurt anything.
---
lxc-dave/fs/file_table.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/open.c~fix-reiserfs-oops fs/open.c
diff -puN fs/file_table.c~fix-reiserfs-oops fs/file_table.c
--- lxc/fs/file_table.c~fix-reiserfs-oops 2007-09-27 13:32:20.0
-0700
+++ lxc-dave/fs/file_table.c2007-09-27 13:33:11.0 -0700
@@ -236,7 +236,7 @@ void fastcall __fput(struct file *file)
fops_put(file-f_op);
if (file-f_mode FMODE_WRITE) {
put_write_access(inode);
- if (!special_file(inode-i_mode))
+ if (!special_file(inode-i_mode) mnt)
mnt_drop_write(mnt);
}
put_pid(file-f_owner.pid);
diff -puN include/linux/mount.h~fix-reiserfs-oops include/linux/mount.h
END
Dave sent it privately to me... I guess this bandaid is no longer
needed now, is it?
~~
laurent
-
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.23-mm1: BUG in reiserfs_delete_xattrs
Le 12.10.2007 06:31, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
/home is mounted with the following options:
/dev/mapper/vglinux1-lvhome on /home type reiserfs
(rw,noatime,nodiratime,user_xattr)
I guess that beagled (the Beagle desktop search daemon) has populated user
xattrs on almost all files. Now, when I delete a file, two BUGs occur
and the system hangs. Here is the stack for the first BUG (the second
one is very similar):
[partially hand copied stack]
_fput
fput
reiserfs_delete_xattrs
reiserfs_delete_inode
generic_delete_inode
generic_drop_inode
iput
do_unlinkat
sys_unlink
sys_enter_past_esp
I reported a similar BUG in 2.6.22-rc8-mm2 (see
http://lkml.org/lkml/2007/9/27/235). Dave Hansen sent a patch for it, I
tested it and it was OK for 2.6.22-rc8-mm2.
I tried this patch on 2.6.23-mm1, and it fixed the BUGs here too.
From: Dave Hansen <[EMAIL PROTECTED]>
The bug is caused by reiserfs creating a special 'struct file' with a
NULL vfsmount.
/* Opens a file pointer to the attribute associated with inode */
static struct file *open_xa_file(const struct inode *inode, const char
*name,
int flags)
{
...
fp = dentry_open(xafile, NULL, O_RDWR);
/* dentry_open dputs the dentry if it fails */
As Christoph just said, this is somewhat of a bandaid. But, it
shouldn't hurt anything.
---
lxc-dave/fs/file_table.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/open.c~fix-reiserfs-oops fs/open.c
diff -puN fs/file_table.c~fix-reiserfs-oops fs/file_table.c
--- lxc/fs/file_table.c~fix-reiserfs-oops 2007-09-27 13:32:20.0
-0700
+++ lxc-dave/fs/file_table.c2007-09-27 13:33:11.0 -0700
@@ -236,7 +236,7 @@ void fastcall __fput(struct file *file)
fops_put(file->f_op);
if (file->f_mode & FMODE_WRITE) {
put_write_access(inode);
- if (!special_file(inode->i_mode))
+ if (!special_file(inode->i_mode) && mnt)
mnt_drop_write(mnt);
}
put_pid(file->f_owner.pid);
diff -puN include/linux/mount.h~fix-reiserfs-oops include/linux/mount.h
_
-
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.23-mm1: BUG in reiserfs_delete_xattrs
Le 12.10.2007 06:31, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
/home is mounted with the following options:
/dev/mapper/vglinux1-lvhome on /home type reiserfs
(rw,noatime,nodiratime,user_xattr)
I guess that beagled (the Beagle desktop search daemon) has populated user
xattrs on almost all files. Now, when I delete a file, two BUGs occur
and the system hangs. Here is the stack for the first BUG (the second
one is very similar):
[partially hand copied stack]
_fput
fput
reiserfs_delete_xattrs
reiserfs_delete_inode
generic_delete_inode
generic_drop_inode
iput
do_unlinkat
sys_unlink
sys_enter_past_esp
I reported a similar BUG in 2.6.22-rc8-mm2 (see
http://lkml.org/lkml/2007/9/27/235). Dave Hansen sent a patch for it, I
tested it and it was OK for 2.6.22-rc8-mm2.
I tried this patch on 2.6.23-mm1, and it fixed the BUGs here too.
From: Dave Hansen [EMAIL PROTECTED]
The bug is caused by reiserfs creating a special 'struct file' with a
NULL vfsmount.
/* Opens a file pointer to the attribute associated with inode */
static struct file *open_xa_file(const struct inode *inode, const char
*name,
int flags)
{
...
fp = dentry_open(xafile, NULL, O_RDWR);
/* dentry_open dputs the dentry if it fails */
As Christoph just said, this is somewhat of a bandaid. But, it
shouldn't hurt anything.
---
lxc-dave/fs/file_table.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/open.c~fix-reiserfs-oops fs/open.c
diff -puN fs/file_table.c~fix-reiserfs-oops fs/file_table.c
--- lxc/fs/file_table.c~fix-reiserfs-oops 2007-09-27 13:32:20.0
-0700
+++ lxc-dave/fs/file_table.c2007-09-27 13:33:11.0 -0700
@@ -236,7 +236,7 @@ void fastcall __fput(struct file *file)
fops_put(file-f_op);
if (file-f_mode FMODE_WRITE) {
put_write_access(inode);
- if (!special_file(inode-i_mode))
+ if (!special_file(inode-i_mode) mnt)
mnt_drop_write(mnt);
}
put_pid(file-f_owner.pid);
diff -puN include/linux/mount.h~fix-reiserfs-oops include/linux/mount.h
_
-
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/
[PATCH] Reiser4: Drop 'size' argument from bio_endio and bi_end_io
Reiser4: Drop 'size' argument from bio_endio and bi_end_io
This patch pushes into Reiser4 the changes introduced by
commit 6712ecf8f648118c3363c142196418f89a510b90:
As bi_end_io is only called once when the request is complete,
the 'size' argument is now redundant. Remove it.
Now there is no need for bio_endio to subtract the size completed
from bi_size. So don't do that either.
While we are at it, change bi_end_io to return void.
Please review.
Signed-Off-By: Laurent Riffard <[EMAIL PROTECTED]>
---
fs/reiser4/flush_queue.c | 10 ++
fs/reiser4/page_cache.c | 24
fs/reiser4/status_flags.c |7 +--
3 files changed, 7 insertions(+), 34 deletions(-)
Index: linux-2.6-mm/fs/reiser4/flush_queue.c
===
--- linux-2.6-mm.orig/fs/reiser4/flush_queue.c
+++ linux-2.6-mm/fs/reiser4/flush_queue.c
@@ -391,9 +391,8 @@ int atom_fq_parts_are_clean(txn_atom * a
}
#endif
/* Bio i/o completion routine for reiser4 write operations. */
-static int
-end_io_handler(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
- int err)
+static void
+end_io_handler(struct bio *bio, int err)
{
int i;
int nr_errors = 0;
@@ -401,10 +400,6 @@ end_io_handler(struct bio *bio, unsigned
assert("zam-958", bio->bi_rw & WRITE);
- /* i/o op. is not fully completed */
- if (bio->bi_size != 0)
- return 1;
-
if (err == -EOPNOTSUPP)
set_bit(BIO_EOPNOTSUPP, >bi_flags);
@@ -447,7 +442,6 @@ end_io_handler(struct bio *bio, unsigned
}
bio_put(bio);
- return 0;
}
/* Count I/O requests which will be submitted by @bio in given flush queues
Index: linux-2.6-mm/fs/reiser4/page_cache.c
===
--- linux-2.6-mm.orig/fs/reiser4/page_cache.c
+++ linux-2.6-mm/fs/reiser4/page_cache.c
@@ -320,18 +320,11 @@ reiser4_tree *reiser4_tree_by_page(const
mpage_end_io_read() would also do. But it's static.
*/
-static int
-end_bio_single_page_read(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
-int err UNUSED_ARG)
+static void
+end_bio_single_page_read(struct bio *bio, int err UNUSED_ARG)
{
struct page *page;
- if (bio->bi_size != 0) {
- warning("nikita-3332", "Truncated single page read: %i",
- bio->bi_size);
- return 1;
- }
-
page = bio->bi_io_vec[0].bv_page;
if (test_bit(BIO_UPTODATE, >bi_flags)) {
@@ -342,7 +335,6 @@ end_bio_single_page_read(struct bio *bio
}
unlock_page(page);
bio_put(bio);
- return 0;
}
/* completion handler for single page bio-based write.
@@ -350,25 +342,17 @@ end_bio_single_page_read(struct bio *bio
mpage_end_io_write() would also do. But it's static.
*/
-static int
-end_bio_single_page_write(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
- int err UNUSED_ARG)
+static void
+end_bio_single_page_write(struct bio *bio, int err UNUSED_ARG)
{
struct page *page;
- if (bio->bi_size != 0) {
- warning("nikita-", "Truncated single page write: %i",
- bio->bi_size);
- return 1;
- }
-
page = bio->bi_io_vec[0].bv_page;
if (!test_bit(BIO_UPTODATE, >bi_flags))
SetPageError(page);
end_page_writeback(page);
bio_put(bio);
- return 0;
}
/* ->readpage() method for formatted nodes */
Index: linux-2.6-mm/fs/reiser4/status_flags.c
===
--- linux-2.6-mm.orig/fs/reiser4/status_flags.c
+++ linux-2.6-mm/fs/reiser4/status_flags.c
@@ -15,12 +15,8 @@
/* This is our end I/O handler that marks page uptodate if IO was successful.
It also
unconditionally unlocks the page, so we can see that io was done.
We do not free bio, because we hope to reuse that. */
-static int reiser4_status_endio(struct bio *bio, unsigned int bytes_done,
- int err)
+static void reiser4_status_endio(struct bio *bio, int err)
{
- if (bio->bi_size)
- return 1;
-
if (test_bit(BIO_UPTODATE, >bi_flags)) {
SetPageUptodate(bio->bi_io_vec->bv_page);
} else {
@@ -28,7 +24,6 @@ static int reiser4_status_endio(struct b
SetPageError(bio->bi_io_vec->bv_page);
}
unlock_page(bio->bi_io_vec->bv_page);
- return 0;
}
/* Initialise status code. This is expected to be called from the disk format
-
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/
[PATCH] Reiser4: Drop 'size' argument from bio_endio and bi_end_io
Reiser4: Drop 'size' argument from bio_endio and bi_end_io
This patch pushes into Reiser4 the changes introduced by
commit 6712ecf8f648118c3363c142196418f89a510b90:
As bi_end_io is only called once when the request is complete,
the 'size' argument is now redundant. Remove it.
Now there is no need for bio_endio to subtract the size completed
from bi_size. So don't do that either.
While we are at it, change bi_end_io to return void.
Please review.
Signed-Off-By: Laurent Riffard [EMAIL PROTECTED]
---
fs/reiser4/flush_queue.c | 10 ++
fs/reiser4/page_cache.c | 24
fs/reiser4/status_flags.c |7 +--
3 files changed, 7 insertions(+), 34 deletions(-)
Index: linux-2.6-mm/fs/reiser4/flush_queue.c
===
--- linux-2.6-mm.orig/fs/reiser4/flush_queue.c
+++ linux-2.6-mm/fs/reiser4/flush_queue.c
@@ -391,9 +391,8 @@ int atom_fq_parts_are_clean(txn_atom * a
}
#endif
/* Bio i/o completion routine for reiser4 write operations. */
-static int
-end_io_handler(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
- int err)
+static void
+end_io_handler(struct bio *bio, int err)
{
int i;
int nr_errors = 0;
@@ -401,10 +400,6 @@ end_io_handler(struct bio *bio, unsigned
assert(zam-958, bio-bi_rw WRITE);
- /* i/o op. is not fully completed */
- if (bio-bi_size != 0)
- return 1;
-
if (err == -EOPNOTSUPP)
set_bit(BIO_EOPNOTSUPP, bio-bi_flags);
@@ -447,7 +442,6 @@ end_io_handler(struct bio *bio, unsigned
}
bio_put(bio);
- return 0;
}
/* Count I/O requests which will be submitted by @bio in given flush queues
Index: linux-2.6-mm/fs/reiser4/page_cache.c
===
--- linux-2.6-mm.orig/fs/reiser4/page_cache.c
+++ linux-2.6-mm/fs/reiser4/page_cache.c
@@ -320,18 +320,11 @@ reiser4_tree *reiser4_tree_by_page(const
mpage_end_io_read() would also do. But it's static.
*/
-static int
-end_bio_single_page_read(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
-int err UNUSED_ARG)
+static void
+end_bio_single_page_read(struct bio *bio, int err UNUSED_ARG)
{
struct page *page;
- if (bio-bi_size != 0) {
- warning(nikita-3332, Truncated single page read: %i,
- bio-bi_size);
- return 1;
- }
-
page = bio-bi_io_vec[0].bv_page;
if (test_bit(BIO_UPTODATE, bio-bi_flags)) {
@@ -342,7 +335,6 @@ end_bio_single_page_read(struct bio *bio
}
unlock_page(page);
bio_put(bio);
- return 0;
}
/* completion handler for single page bio-based write.
@@ -350,25 +342,17 @@ end_bio_single_page_read(struct bio *bio
mpage_end_io_write() would also do. But it's static.
*/
-static int
-end_bio_single_page_write(struct bio *bio, unsigned int bytes_done UNUSED_ARG,
- int err UNUSED_ARG)
+static void
+end_bio_single_page_write(struct bio *bio, int err UNUSED_ARG)
{
struct page *page;
- if (bio-bi_size != 0) {
- warning(nikita-, Truncated single page write: %i,
- bio-bi_size);
- return 1;
- }
-
page = bio-bi_io_vec[0].bv_page;
if (!test_bit(BIO_UPTODATE, bio-bi_flags))
SetPageError(page);
end_page_writeback(page);
bio_put(bio);
- return 0;
}
/* -readpage() method for formatted nodes */
Index: linux-2.6-mm/fs/reiser4/status_flags.c
===
--- linux-2.6-mm.orig/fs/reiser4/status_flags.c
+++ linux-2.6-mm/fs/reiser4/status_flags.c
@@ -15,12 +15,8 @@
/* This is our end I/O handler that marks page uptodate if IO was successful.
It also
unconditionally unlocks the page, so we can see that io was done.
We do not free bio, because we hope to reuse that. */
-static int reiser4_status_endio(struct bio *bio, unsigned int bytes_done,
- int err)
+static void reiser4_status_endio(struct bio *bio, int err)
{
- if (bio-bi_size)
- return 1;
-
if (test_bit(BIO_UPTODATE, bio-bi_flags)) {
SetPageUptodate(bio-bi_io_vec-bv_page);
} else {
@@ -28,7 +24,6 @@ static int reiser4_status_endio(struct b
SetPageError(bio-bi_io_vec-bv_page);
}
unlock_page(bio-bi_io_vec-bv_page);
- return 0;
}
/* Initialise status code. This is expected to be called from the disk format
-
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.23-mm1
Le 12.10.2007 06:31, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Mounting reiser4 fs does hang with these messages in dmesg: Loading Reiser4. See www.namesys.com for a description of Reiser4. reiser4[swapper(0)]: end_bio_single_page_read (fs/reiser4/page_cache.c:331)[nikita-3332]: WARNING: Truncated single page read: 4096 Hitting SysRq-W produces this output: SysRq : Show Blocked State taskPC stack pid father mount D c20d6b70 1592 2509 2495 c229bbd8 0046 c239d684 c20d6b70 e0824b8d c229bc10 c229bc18 c229bbe0 c02ac14e c229bbe8 c0141b7b c229bc04 c02ac344 c0141b45 c1402654 c1045f60 c1045f60 c229bc10 c229bc30 c0141d6e 0002 c1045f60 Call Trace: [] io_schedule+0xe/0x16 [] sync_page+0x36/0x3a [] __wait_on_bit+0x36/0x5d [] wait_on_page_bit+0x55/0x5b [] jload_gfp+0x73/0x163 [reiser4] [] load_journal_control_block+0x4d/0x77 [reiser4] [] reiser4_init_journal_info+0x2b/0x54 [reiser4] [] init_format_format40+0x79/0x4ab [reiser4] [] fill_super+0xce/0x1ee [reiser4] [] get_sb_bdev+0xe0/0x11e [] reiser4_get_sb+0x13/0x15 [reiser4] [] vfs_kern_mount+0x3b/0x76 [] do_mount+0x68a/0x7a3 [] sys_mount+0x68/0xa4 [] sysenter_past_esp+0x5f/0x99 === .config attached. Feel free to ask for more info. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-mm1 # Fri Oct 12 20:44:24 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set
Re: 2.6.23-mm1
Le 12.10.2007 06:31, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Mounting reiser4 fs does hang with these messages in dmesg: Loading Reiser4. See www.namesys.com for a description of Reiser4. reiser4[swapper(0)]: end_bio_single_page_read (fs/reiser4/page_cache.c:331)[nikita-3332]: WARNING: Truncated single page read: 4096 Hitting SysRq-W produces this output: SysRq : Show Blocked State taskPC stack pid father mount D c20d6b70 1592 2509 2495 c229bbd8 0046 c239d684 c20d6b70 e0824b8d c229bc10 c229bc18 c229bbe0 c02ac14e c229bbe8 c0141b7b c229bc04 c02ac344 c0141b45 c1402654 c1045f60 c1045f60 c229bc10 c229bc30 c0141d6e 0002 c1045f60 Call Trace: [c02ac14e] io_schedule+0xe/0x16 [c0141b7b] sync_page+0x36/0x3a [c02ac344] __wait_on_bit+0x36/0x5d [c0141d6e] wait_on_page_bit+0x55/0x5b [e1c0e1a6] jload_gfp+0x73/0x163 [reiser4] [e1c1c7f8] load_journal_control_block+0x4d/0x77 [reiser4] [e1c1c86e] reiser4_init_journal_info+0x2b/0x54 [reiser4] [e1c454e6] init_format_format40+0x79/0x4ab [reiser4] [e1c21cf8] fill_super+0xce/0x1ee [reiser4] [c015f731] get_sb_bdev+0xe0/0x11e [e1c21a8f] reiser4_get_sb+0x13/0x15 [reiser4] [c015f336] vfs_kern_mount+0x3b/0x76 [c0171621] do_mount+0x68a/0x7a3 [c01717a2] sys_mount+0x68/0xa4 [c0103dee] sysenter_past_esp+0x5f/0x99 === .config attached. Feel free to ask for more info. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-mm1 # Fri Oct 12 20:44:24 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set #
Re: 2.6.23-rc[68]-mm: network hangs
Le 29.09.2007 10:31, Andrew Morton a écrit : > On Fri, 28 Sep 2007 21:48:18 +0200 Laurent Riffard <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> >From time to time, I experience some complete network hangs: >> >> Suddenly, all network connections become unresponsive. Even "ping >> 127.0.0.1" doesn't work. SysRq-w does not show any blocked processus. >> >> When such hang happen, I have to reboot (shutdown does work). >> >> This is not easily reproducible: it happens several minutes after >> boot (could be 45 minutes or 2 hours). I do not use heavy networking >> apps (like P2P). My typical usage is a Gnome desktop with browser, >> mailer, IM, video or audio streaming. >> >> I have a single PC connected to a DSL router via ethernet (so no LAN >> with NFS or CIFS). >> >> This happens with 2.6.23-rc8-mm2 and 2.6.23-rc6-mm1. I can't remember >> when I first see this problem. Maybe 2 months ago. >> >> I attached the output of "strace ping 127.0.0.1". How can I collect >> some more data when this problem happens ? >> > > I have a second report of this from Uwe Bugla (who has been banished from > all vger lists for various naughtinesses). > > Similar story - after a few hours his network router (which is using ppp in > some fashion) craps out and dhcp queries all time out. > > I'd be suspecting a ppp bug in net-2.6.24. mmm... I don't use PPP at all, nor dhcp. My DSL box act as a NAT-router. Its local adress is 192.168.0.254 and my PC is at 192.192.0.9 (fixed IP). /--- telephone line | +--+ | ADSL box | +--+ 192.168.0.254 | 192.168.0.9 +---+ |PC | +---+ Firstly, I suspected a bug in the DSL box, so I reset it but it did not help. I have to reboot the PC (don't need to reset the DSL box). Could a router problem prevent "ping 127.0.0.1" from working ? [this becomes somewhat off-topic for LKML, sorry] Here's my routing table: linux-2.6-mm$ LANG=C netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.0.254 0.0.0.0 UG0 0 0 eth0 It seems it lacks a route for 127.0.0.1 through lo, isn't it? In this case, if eth0 hangs, 127.0.0.1 hangs too, no? So, it could be an ethernet driver bug. I'm using ne2k-pci. -- laurent - 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.23-rc[68]-mm: network hangs
Le 29.09.2007 10:31, Andrew Morton a écrit : On Fri, 28 Sep 2007 21:48:18 +0200 Laurent Riffard [EMAIL PROTECTED] wrote: Hi, From time to time, I experience some complete network hangs: Suddenly, all network connections become unresponsive. Even ping 127.0.0.1 doesn't work. SysRq-w does not show any blocked processus. When such hang happen, I have to reboot (shutdown does work). This is not easily reproducible: it happens several minutes after boot (could be 45 minutes or 2 hours). I do not use heavy networking apps (like P2P). My typical usage is a Gnome desktop with browser, mailer, IM, video or audio streaming. I have a single PC connected to a DSL router via ethernet (so no LAN with NFS or CIFS). This happens with 2.6.23-rc8-mm2 and 2.6.23-rc6-mm1. I can't remember when I first see this problem. Maybe 2 months ago. I attached the output of strace ping 127.0.0.1. How can I collect some more data when this problem happens ? I have a second report of this from Uwe Bugla (who has been banished from all vger lists for various naughtinesses). Similar story - after a few hours his network router (which is using ppp in some fashion) craps out and dhcp queries all time out. I'd be suspecting a ppp bug in net-2.6.24. mmm... I don't use PPP at all, nor dhcp. My DSL box act as a NAT-router. Its local adress is 192.168.0.254 and my PC is at 192.192.0.9 (fixed IP). /--- telephone line | +--+ | ADSL box | +--+ 192.168.0.254 | 192.168.0.9 +---+ |PC | +---+ Firstly, I suspected a bug in the DSL box, so I reset it but it did not help. I have to reboot the PC (don't need to reset the DSL box). Could a router problem prevent ping 127.0.0.1 from working ? [this becomes somewhat off-topic for LKML, sorry] Here's my routing table: linux-2.6-mm$ LANG=C netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.0.254 0.0.0.0 UG0 0 0 eth0 It seems it lacks a route for 127.0.0.1 through lo, isn't it? In this case, if eth0 hangs, 127.0.0.1 hangs too, no? So, it could be an ethernet driver bug. I'm using ne2k-pci. -- laurent - 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/
2.6.23-rc[68]-mm: network hangs
Hi,
>From time to time, I experience some complete network hangs:
Suddenly, all network connections become unresponsive. Even "ping
127.0.0.1" doesn't work. SysRq-w does not show any blocked processus.
When such hang happen, I have to reboot (shutdown does work).
This is not easily reproducible: it happens several minutes after
boot (could be 45 minutes or 2 hours). I do not use heavy networking
apps (like P2P). My typical usage is a Gnome desktop with browser,
mailer, IM, video or audio streaming.
I have a single PC connected to a DSL router via ethernet (so no LAN
with NFS or CIFS).
This happens with 2.6.23-rc8-mm2 and 2.6.23-rc6-mm1. I can't remember
when I first see this problem. Maybe 2 months ago.
I attached the output of "strace ping 127.0.0.1". How can I collect
some more data when this problem happens ?
~~
laurent
execve("/bin/ping", ["ping", "127.0.0.1"], [/* 42 vars */]) = 0
brk(0) = 0x93ac000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f9b000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=57464, ...}) = 0
mmap2(NULL, 57464, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f8c000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libresolv.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0!\0\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=67408, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f8b000
mmap2(NULL, 75976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7f78000
mmap2(0xb7f87000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7f87000
mmap2(0xb7f89000, 6344, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f89000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e37000
mmap2(0xb7f72000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f72000
mmap2(0xb7f75000, 9636, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f75000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e36000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e366c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb7f72000, 4096, PROT_READ) = 0
munmap(0xb7f8c000, 57464) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
getuid32() = 0
setuid32(0) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(44103),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
close(4)= 0
setsockopt(3, SOL_RAW, ICMP_FILTER,
~(ICMP_ECHOREPLY|ICMP_DEST_UNREACH|ICMP_SOURCE_QUENCH|ICMP_REDIRECT|ICMP_TIME_EXCEEDED|ICMP_PARAMETERPROB),
4) = 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [324], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [131072], [4]) = 0
brk(0) = 0x93ac000
brk(0x93cd000) = 0x93cd000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f9a000
write(1, "PING 127.0.0.1 (127.0.0.1) 56(84"..., 49) = 49
setsockopt(3, SOL_SOCKET, SO_TIMESTAMP, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_SNDTIMEO, "\1\0\0\0\0\0\0\0", 8) = 0
setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, "\1\0\0\0\0\0\0\0", 8) = 0
getpid()= 9353
rt_sigaction(SIGINT, {0x804b5b0, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGALRM, {0x804b5b0, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x804b5c0, [], SA_INTERRUPT}, NULL, 8) = 0
gettimeofday({1190968694, 793502}, NULL) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=52, ws_col=157, ws_xpixel=0, ws_ypixel=0}) = 0
gettimeofday({1190968694, 793762}, NULL) = 0
gettimeofday({1190968694, 793824}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
2.6.23-rc[68]-mm: network hangs
Hi,
From time to time, I experience some complete network hangs:
Suddenly, all network connections become unresponsive. Even ping
127.0.0.1 doesn't work. SysRq-w does not show any blocked processus.
When such hang happen, I have to reboot (shutdown does work).
This is not easily reproducible: it happens several minutes after
boot (could be 45 minutes or 2 hours). I do not use heavy networking
apps (like P2P). My typical usage is a Gnome desktop with browser,
mailer, IM, video or audio streaming.
I have a single PC connected to a DSL router via ethernet (so no LAN
with NFS or CIFS).
This happens with 2.6.23-rc8-mm2 and 2.6.23-rc6-mm1. I can't remember
when I first see this problem. Maybe 2 months ago.
I attached the output of strace ping 127.0.0.1. How can I collect
some more data when this problem happens ?
~~
laurent
execve(/bin/ping, [ping, 127.0.0.1], [/* 42 vars */]) = 0
brk(0) = 0x93ac000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f9b000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=57464, ...}) = 0
mmap2(NULL, 57464, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f8c000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libresolv.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0!\0\000..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=67408, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f8b000
mmap2(NULL, 75976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7f78000
mmap2(0xb7f87000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7f87000
mmap2(0xb7f89000, 6344, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f89000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e37000
mmap2(0xb7f72000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f72000
mmap2(0xb7f75000, 9636, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f75000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e36000
set_thread_area({entry_number:-1 - 6, base_addr:0xb7e366c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb7f72000, 4096, PROT_READ) = 0
munmap(0xb7f8c000, 57464) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
getuid32() = 0
setuid32(0) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(44103),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 0
close(4)= 0
setsockopt(3, SOL_RAW, ICMP_FILTER,
~(ICMP_ECHOREPLY|ICMP_DEST_UNREACH|ICMP_SOURCE_QUENCH|ICMP_REDIRECT|ICMP_TIME_EXCEEDED|ICMP_PARAMETERPROB),
4) = 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [324], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0
getsockopt(3, SOL_SOCKET, SO_RCVBUF, [131072], [4]) = 0
brk(0) = 0x93ac000
brk(0x93cd000) = 0x93cd000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f9a000
write(1, PING 127.0.0.1 (127.0.0.1) 56(84..., 49) = 49
setsockopt(3, SOL_SOCKET, SO_TIMESTAMP, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_SNDTIMEO, \1\0\0\0\0\0\0\0, 8) = 0
setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, \1\0\0\0\0\0\0\0, 8) = 0
getpid()= 9353
rt_sigaction(SIGINT, {0x804b5b0, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGALRM, {0x804b5b0, [], SA_INTERRUPT}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x804b5c0, [], SA_INTERRUPT}, NULL, 8) = 0
gettimeofday({1190968694, 793502}, NULL) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=52, ws_col=157, ws_xpixel=0, ws_ypixel=0}) = 0
gettimeofday({1190968694, 793762}, NULL) = 0
gettimeofday({1190968694, 793824}, NULL) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(127.0.0.1)},
Re: 2.6.23-rc8-mm2: BUG near reiserfs_xattr_set
Le 27.09.2007 11:22, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ I've got this BUG a few seconds after I logged in into Gnome desktop : [partially hand copied BUG] BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: c016f55e *pde=0b8a5067 *pte= Oops: 0002 [#1] PREEMPT ... Process beagled... ... Call Trace: __fput+0x124/0x1a9 fput+0x31/0x35 reiserfs_xattr_set+0x291/0x2b0 [reiserfs] user_set+0x4c/0x57 [reiserfs] reiserfs_setxattr+0x81/0xf1 [reiserfs] vfs_setxattr+0x7d/0xfa setxattr+0xb9/0xd1 sys_lsetxattr+0x4c/0x85 sysenter_past_esp+0x57/0x85 EIP: mnt_drop_write+0x5b/0x9d It's fully reproducible. /home is mounted with the following options: /dev/mapper/vglinux1-lvhome on /home type reiserfs (rw,noatime,nodiratime,user_xattr) This BUG happened with rc8-mm1 too. rc6-mm1 works fine. I didn't try rc7-mm1. .config attached. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Thu Sep 27 18:18:14 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y
Re: 2.6.23-rc8-mm2: BUG near reiserfs_xattr_set
Le 27.09.2007 11:22, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/ I've got this BUG a few seconds after I logged in into Gnome desktop : [partially hand copied BUG] BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: c016f55e *pde=0b8a5067 *pte= Oops: 0002 [#1] PREEMPT ... Process beagled... ... Call Trace: __fput+0x124/0x1a9 fput+0x31/0x35 reiserfs_xattr_set+0x291/0x2b0 [reiserfs] user_set+0x4c/0x57 [reiserfs] reiserfs_setxattr+0x81/0xf1 [reiserfs] vfs_setxattr+0x7d/0xfa setxattr+0xb9/0xd1 sys_lsetxattr+0x4c/0x85 sysenter_past_esp+0x57/0x85 EIP: mnt_drop_write+0x5b/0x9d It's fully reproducible. /home is mounted with the following options: /dev/mapper/vglinux1-lvhome on /home type reiserfs (rw,noatime,nodiratime,user_xattr) This BUG happened with rc8-mm1 too. rc6-mm1 works fine. I didn't try rc7-mm1. .config attached. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc8-mm2 # Thu Sep 27 18:18:14 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y
Re: 2.6.23-rc7-mm1: build error with CONFIG_KEXEC=y and CONFIG_NOHIGHMEM=y
Le 24.09.2007 11:17, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/ > I've got this compilation when CONFIG_KEXEC=y and CCONFIG_NOHIGHMEM=y: linux-2.6-mm$ LANG=C make CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CC arch/i386/kernel/setup.o arch/i386/kernel/setup.c: In function 'reserve_crashkernel': arch/i386/kernel/setup.c:391: error: 'highend_pfn' undeclared (first use in this function) arch/i386/kernel/setup.c:391: error: (Each undeclared identifier is reported only once arch/i386/kernel/setup.c:391: error: for each function it appears in.) arch/i386/kernel/setup.c:391: error: 'highstart_pfn' undeclared (first use in this function) make[1]: *** [arch/i386/kernel/setup.o] Error 1 make: *** [arch/i386/kernel] Error 2 .config attached. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc7-mm1 # Mon Sep 24 20:25:04 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is
Re: 2.6.23-rc7-mm1: build error with CONFIG_KEXEC=y and CONFIG_NOHIGHMEM=y
Le 24.09.2007 11:17, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/ I've got this compilation when CONFIG_KEXEC=y and CCONFIG_NOHIGHMEM=y: linux-2.6-mm$ LANG=C make CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CC arch/i386/kernel/setup.o arch/i386/kernel/setup.c: In function 'reserve_crashkernel': arch/i386/kernel/setup.c:391: error: 'highend_pfn' undeclared (first use in this function) arch/i386/kernel/setup.c:391: error: (Each undeclared identifier is reported only once arch/i386/kernel/setup.c:391: error: for each function it appears in.) arch/i386/kernel/setup.c:391: error: 'highstart_pfn' undeclared (first use in this function) make[1]: *** [arch/i386/kernel/setup.o] Error 1 make: *** [arch/i386/kernel] Error 2 .config attached. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc7-mm1 # Mon Sep 24 20:25:04 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MCORE2 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set
[PATCH] pktcdvd: don't rely on bio_init() preserving bio->bi_destructor
Le 14.09.2007 21:04, Laurent Riffard a écrit : > Le 14.09.2007 13:06, Jens Axboe a écrit : >> On Fri, Sep 14 2007, Jens Axboe wrote: >>> On Fri, Sep 14 2007, Laurent Riffard wrote: >>>> Le 10.09.2007 22:19, Laurent Riffard a écrit : >>>>> Jens, >>>>> >>>>> git-block.patch broke pktcdvd, I've got an Oops while syncing: >>>>> > [snip] >>>> I dig through git-block.patch and the culprit seems to be commit >>>> c94f1c4ac87862675c8d70941973bc3a69aff5d8 "bio: use memset() in >>>> bio_init()". >>>> >>>> Maybe the real bug is a bad bio initialization in pktcdvd driver, >>>> which is revealed by this commit ? >>> At least pktcdvd doesn't expect bio->bi_io_vec[] to be cleared, that's >>> why it's oopsing now. I'll revert this bit for now, thanks for the >>> report. >> Rethinking this, I think bio_init() is doing the right thing, only >> pktcdvd seems to rely on it preserving some members. So I'd rather fixup >> pktcdvd instead. >> >> Does this work for you? > > Well, it's better: I was able to mount the DVD-RW, sync, and write data, > but kernel oopsed when I unmounted the drive: Jens, this patch, applied on top of your previous patch, solved it. pktcdvd: don't rely on bio_init() preserving bio->bi_destructor Signed-off-by: Laurent Riffard <[EMAIL PROTECTED]> --- drivers/block/pktcdvd.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6-mm/drivers/block/pktcdvd.c === --- linux-2.6-mm.orig/drivers/block/pktcdvd.c +++ linux-2.6-mm/drivers/block/pktcdvd.c @@ -1156,6 +1156,7 @@ static void pkt_gather_data(struct pktcd bio->bi_end_io = pkt_end_io_read; bio->bi_private = pkt; bio->bi_io_vec = vec; + bio->bi_destructor = pkt_bio_destructor; p = (f * CD_FRAMESIZE) / PAGE_SIZE; offset = (f * CD_FRAMESIZE) % PAGE_SIZE; @@ -1453,6 +1454,7 @@ static void pkt_start_write(struct pktcd pkt->w_bio->bi_end_io = pkt_end_io_packet_write; pkt->w_bio->bi_private = pkt; pkt->w_bio->bi_io_vec = bvec; + pkt->w_bio->bi_destructor = pkt_bio_destructor; for (f = 0; f < pkt->frames; f++) if (!bio_add_page(pkt->w_bio, bvec[f].bv_page, CD_FRAMESIZE, bvec[f].bv_offset)) BUG(); - 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/
[PATCH] pktcdvd: don't rely on bio_init() preserving bio-bi_destructor
Le 14.09.2007 21:04, Laurent Riffard a écrit : Le 14.09.2007 13:06, Jens Axboe a écrit : On Fri, Sep 14 2007, Jens Axboe wrote: On Fri, Sep 14 2007, Laurent Riffard wrote: Le 10.09.2007 22:19, Laurent Riffard a écrit : Jens, git-block.patch broke pktcdvd, I've got an Oops while syncing: [snip] I dig through git-block.patch and the culprit seems to be commit c94f1c4ac87862675c8d70941973bc3a69aff5d8 bio: use memset() in bio_init(). Maybe the real bug is a bad bio initialization in pktcdvd driver, which is revealed by this commit ? At least pktcdvd doesn't expect bio-bi_io_vec[] to be cleared, that's why it's oopsing now. I'll revert this bit for now, thanks for the report. Rethinking this, I think bio_init() is doing the right thing, only pktcdvd seems to rely on it preserving some members. So I'd rather fixup pktcdvd instead. Does this work for you? Well, it's better: I was able to mount the DVD-RW, sync, and write data, but kernel oopsed when I unmounted the drive: Jens, this patch, applied on top of your previous patch, solved it. pktcdvd: don't rely on bio_init() preserving bio-bi_destructor Signed-off-by: Laurent Riffard [EMAIL PROTECTED] --- drivers/block/pktcdvd.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6-mm/drivers/block/pktcdvd.c === --- linux-2.6-mm.orig/drivers/block/pktcdvd.c +++ linux-2.6-mm/drivers/block/pktcdvd.c @@ -1156,6 +1156,7 @@ static void pkt_gather_data(struct pktcd bio-bi_end_io = pkt_end_io_read; bio-bi_private = pkt; bio-bi_io_vec = vec; + bio-bi_destructor = pkt_bio_destructor; p = (f * CD_FRAMESIZE) / PAGE_SIZE; offset = (f * CD_FRAMESIZE) % PAGE_SIZE; @@ -1453,6 +1454,7 @@ static void pkt_start_write(struct pktcd pkt-w_bio-bi_end_io = pkt_end_io_packet_write; pkt-w_bio-bi_private = pkt; pkt-w_bio-bi_io_vec = bvec; + pkt-w_bio-bi_destructor = pkt_bio_destructor; for (f = 0; f pkt-frames; f++) if (!bio_add_page(pkt-w_bio, bvec[f].bv_page, CD_FRAMESIZE, bvec[f].bv_offset)) BUG(); - 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.23-rc4-mm1: git-block.patch broke pktcdvd
Le 14.09.2007 13:06, Jens Axboe a écrit :
> On Fri, Sep 14 2007, Jens Axboe wrote:
>> On Fri, Sep 14 2007, Laurent Riffard wrote:
>>> Le 10.09.2007 22:19, Laurent Riffard a écrit :
>>>>
>>>> Jens,
>>>>
>>>> git-block.patch broke pktcdvd, I've got an Oops while syncing:
>>>>
[snip]
>>> I dig through git-block.patch and the culprit seems to be commit
>>> c94f1c4ac87862675c8d70941973bc3a69aff5d8 "bio: use memset() in
>>> bio_init()".
>>>
>>> Maybe the real bug is a bad bio initialization in pktcdvd driver,
>>> which is revealed by this commit ?
>> At least pktcdvd doesn't expect bio->bi_io_vec[] to be cleared, that's
>> why it's oopsing now. I'll revert this bit for now, thanks for the
>> report.
>
> Rethinking this, I think bio_init() is doing the right thing, only
> pktcdvd seems to rely on it preserving some members. So I'd rather fixup
> pktcdvd instead.
>
> Does this work for you?
Well, it's better: I was able to mount the DVD-RW, sync, and write data,
but kernel oopsed when I unmounted the drive:
[ 529.295829] BUG: unable to handle kernel NULL pointer dereference at virtual
address
[ 529.296490] printing eip: *pde =
[ 529.297106] Oops: [#1] PREEMPT
[ 529.297702] last sysfs file: /block/pktcdvd0/range
[ 529.298284] Modules linked in: udf binfmt_misc pktcdvd radeon drm lp
nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom
w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
firewire_ohci firewire_core snd_seq crc_itu_t sg snd_timer snd_seq_device
8250_pnp snd sr_mod cdrom rtc ohci1394 i2c_viapro 8250 serial_core uhci_hcd
soundcore snd_page_alloc floppy pcspkr ne2k_pci 8390 parport_pc via686a
ieee1394 usbcore parport ata_generic via_agp agpgart evdev reiserfs sd_mod
pata_via libata scsi_mod dm_mirror dm_mod
[ 529.302127]
[ 529.302785] Pid: 3718, comm: umount Not tainted (2.6.23-rc4-mm1 #73)
[ 529.303493] EIP: 0060:[<>] EFLAGS: 00010202 CPU: 0
[ 529.304207] EIP is at _stext+0x3feff000/0x19
[ 529.304911] EAX: c30ded90 EBX: cb110da8 ECX: EDX: c30ded90
[ 529.305640] ESI: 0001 EDI: cb0c7748 EBP: cb1dfe98 ESP: cb1dfe90
[ 529.306389] DS: 007b ES: 007b FS: GS: 0033 SS: 0068
[ 529.307136] Process umount (pid: 3718, ti=cb1df000 task=c27157b0
task.ti=cb1df000)
[ 529.307213] Stack: c017b4bf cb1dfeb0 e1c0e57a cb1115d8 cb0c7748
c1e4a828 c26663c8
[ 529.308122]cb1dfec4 e1c0e650 cb1dfec4 c017c15f cb1dfee4
c017c8f3 c1e4a834
[ 529.309040] c1e4a8bc c1e4a828 e1f12ea0 cb1dfeec
c017c9ab cb1dfef8
[ 529.309972] Call Trace:
[ 529.311464] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f
[ 529.312264] [show_stack_log_lvl+155/163] show_stack_log_lvl+0x9b/0xa3
[ 529.313056] [show_registers+160/482] show_registers+0xa0/0x1e2
[ 529.313840] [die+261/567] die+0x105/0x237
[ 529.314611] [do_page_fault+1127/1349] do_page_fault+0x467/0x545
[ 529.315396] [error_code+106/112] error_code+0x6a/0x70
[ 529.316186] [] pkt_shrink_pktlist+0x29/0x79 [pktcdvd]
[ 529.317007] [] pkt_close+0x86/0x97 [pktcdvd]
[ 529.317816] [__blkdev_put+95/269] __blkdev_put+0x5f/0x10d
[ 529.318630] [blkdev_put+10/12] blkdev_put+0xa/0xc
[ 529.319436] [close_bdev_excl+18/21] close_bdev_excl+0x12/0x15
[ 529.320260] [kill_block_super+29/32] kill_block_super+0x1d/0x20
[ 529.321095] [deactivate_super+63/81] deactivate_super+0x3f/0x51
[ 529.321933] [mntput_no_expire+73/102] mntput_no_expire+0x49/0x66
[ 529.322782] [path_release_on_umount+21/24] path_release_on_umount+0x15/0x18
[ 529.323641] [sys_umount+461/501] sys_umount+0x1cd/0x1f5
[ 529.324499] [sys_oldumount+25/27] sys_oldumount+0x19/0x1b
[ 529.325361] [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
[ 529.326248] ===
[ 529.327094] Code: Bad EIP value.
[ 529.327969] EIP: [<>] _stext+0x3feff000/0x19 SS:ESP 0068:cb1dfe90
> diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> index fadbfd8..98343a1 100644
> --- a/drivers/block/pktcdvd.c
> +++ b/drivers/block/pktcdvd.c
> @@ -1142,16 +1142,20 @@ static void pkt_gather_data(struct pktcdvd_device
> *pd, struct packet_data *pkt)
>* Schedule reads for missing parts of the packet.
>*/
> for (f = 0; f < pkt->frames; f++) {
> + struct bio_vec *vec;
> +
> int p, offset;
> if (written[f])
> continue;
> bio = pkt->r_bios[f];
> + vec = bio->bi_io_vec;
> bio_init(bio);
> bio->bi_max_vecs = 1;
> bio->bi_se
Re: 2.6.23-rc4-mm1: git-block.patch broke pktcdvd
Le 14.09.2007 13:06, Jens Axboe a écrit :
On Fri, Sep 14 2007, Jens Axboe wrote:
On Fri, Sep 14 2007, Laurent Riffard wrote:
Le 10.09.2007 22:19, Laurent Riffard a écrit :
Jens,
git-block.patch broke pktcdvd, I've got an Oops while syncing:
[snip]
I dig through git-block.patch and the culprit seems to be commit
c94f1c4ac87862675c8d70941973bc3a69aff5d8 bio: use memset() in
bio_init().
Maybe the real bug is a bad bio initialization in pktcdvd driver,
which is revealed by this commit ?
At least pktcdvd doesn't expect bio-bi_io_vec[] to be cleared, that's
why it's oopsing now. I'll revert this bit for now, thanks for the
report.
Rethinking this, I think bio_init() is doing the right thing, only
pktcdvd seems to rely on it preserving some members. So I'd rather fixup
pktcdvd instead.
Does this work for you?
Well, it's better: I was able to mount the DVD-RW, sync, and write data,
but kernel oopsed when I unmounted the drive:
[ 529.295829] BUG: unable to handle kernel NULL pointer dereference at virtual
address
[ 529.296490] printing eip: *pde =
[ 529.297106] Oops: [#1] PREEMPT
[ 529.297702] last sysfs file: /block/pktcdvd0/range
[ 529.298284] Modules linked in: udf binfmt_misc pktcdvd radeon drm lp
nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom
w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
firewire_ohci firewire_core snd_seq crc_itu_t sg snd_timer snd_seq_device
8250_pnp snd sr_mod cdrom rtc ohci1394 i2c_viapro 8250 serial_core uhci_hcd
soundcore snd_page_alloc floppy pcspkr ne2k_pci 8390 parport_pc via686a
ieee1394 usbcore parport ata_generic via_agp agpgart evdev reiserfs sd_mod
pata_via libata scsi_mod dm_mirror dm_mod
[ 529.302127]
[ 529.302785] Pid: 3718, comm: umount Not tainted (2.6.23-rc4-mm1 #73)
[ 529.303493] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[ 529.304207] EIP is at _stext+0x3feff000/0x19
[ 529.304911] EAX: c30ded90 EBX: cb110da8 ECX: EDX: c30ded90
[ 529.305640] ESI: 0001 EDI: cb0c7748 EBP: cb1dfe98 ESP: cb1dfe90
[ 529.306389] DS: 007b ES: 007b FS: GS: 0033 SS: 0068
[ 529.307136] Process umount (pid: 3718, ti=cb1df000 task=c27157b0
task.ti=cb1df000)
[ 529.307213] Stack: c017b4bf cb1dfeb0 e1c0e57a cb1115d8 cb0c7748
c1e4a828 c26663c8
[ 529.308122]cb1dfec4 e1c0e650 cb1dfec4 c017c15f cb1dfee4
c017c8f3 c1e4a834
[ 529.309040] c1e4a8bc c1e4a828 e1f12ea0 cb1dfeec
c017c9ab cb1dfef8
[ 529.309972] Call Trace:
[ 529.311464] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f
[ 529.312264] [show_stack_log_lvl+155/163] show_stack_log_lvl+0x9b/0xa3
[ 529.313056] [show_registers+160/482] show_registers+0xa0/0x1e2
[ 529.313840] [die+261/567] die+0x105/0x237
[ 529.314611] [do_page_fault+1127/1349] do_page_fault+0x467/0x545
[ 529.315396] [error_code+106/112] error_code+0x6a/0x70
[ 529.316186] [e1c0e57a] pkt_shrink_pktlist+0x29/0x79 [pktcdvd]
[ 529.317007] [e1c0e650] pkt_close+0x86/0x97 [pktcdvd]
[ 529.317816] [__blkdev_put+95/269] __blkdev_put+0x5f/0x10d
[ 529.318630] [blkdev_put+10/12] blkdev_put+0xa/0xc
[ 529.319436] [close_bdev_excl+18/21] close_bdev_excl+0x12/0x15
[ 529.320260] [kill_block_super+29/32] kill_block_super+0x1d/0x20
[ 529.321095] [deactivate_super+63/81] deactivate_super+0x3f/0x51
[ 529.321933] [mntput_no_expire+73/102] mntput_no_expire+0x49/0x66
[ 529.322782] [path_release_on_umount+21/24] path_release_on_umount+0x15/0x18
[ 529.323641] [sys_umount+461/501] sys_umount+0x1cd/0x1f5
[ 529.324499] [sys_oldumount+25/27] sys_oldumount+0x19/0x1b
[ 529.325361] [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
[ 529.326248] ===
[ 529.327094] Code: Bad EIP value.
[ 529.327969] EIP: [] _stext+0x3feff000/0x19 SS:ESP 0068:cb1dfe90
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index fadbfd8..98343a1 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -1142,16 +1142,20 @@ static void pkt_gather_data(struct pktcdvd_device
*pd, struct packet_data *pkt)
* Schedule reads for missing parts of the packet.
*/
for (f = 0; f pkt-frames; f++) {
+ struct bio_vec *vec;
+
int p, offset;
if (written[f])
continue;
bio = pkt-r_bios[f];
+ vec = bio-bi_io_vec;
bio_init(bio);
bio-bi_max_vecs = 1;
bio-bi_sector = pkt-sector + f * (CD_FRAMESIZE 9);
bio-bi_bdev = pd-bdev;
bio-bi_end_io = pkt_end_io_read;
bio-bi_private = pkt;
+ bio-bi_io_vec = vec;
p = (f * CD_FRAMESIZE) / PAGE_SIZE;
offset = (f * CD_FRAMESIZE) % PAGE_SIZE;
@@ -1448,6 +1452,7 @@ static void
Re: 2.6.23-rc4-mm1: git-block.patch broke pktcdvd
Le 10.09.2007 22:19, Laurent Riffard a écrit : > Le 01.09.2007 06:58, Andrew Morton a écrit : >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ > [...] > > Jens, > > git-block.patch broke pktcdvd, I've got an Oops while syncing: > >> [ 713.014888] pktcdvd: Fixed packets, 16 blocks, Mode-1 disc >> [ 713.021844] pktcdvd: write speed 2770kB/s >> [ 718.401761] pktcdvd: 4595774kB available on disc >> [ 721.175644] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume >> 'LinuxUDF', timestamp 2006/10/08 21:17 (1078) >> [ 721.213784] mount used greatest stack depth: 460 bytes left >> [ 752.634402] BUG: unable to handle kernel NULL pointer dereference at >> virtual address >> [ 752.635711] printing eip: c017b69e *pde = >> [ 752.636983] Oops: 0002 [#1] PREEMPT >> [ 752.638240] last sysfs file: /devices/pci:00/:00:0d.0/modalias >> [ 752.639477] Modules linked in: udf binfmt_misc pktcdvd radeon drm lp >> nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom >> w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss >> snd_mixer_oss snd_pcm sg firewire_ohci firewire_core sr_mod cdrom crc_itu_t >> snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer >> snd_seq_device snd 8250_pnp i2c_viapro via_agp floppy ohci1394 soundcore >> 8250 serial_core ata_generic uhci_hcd agpgart ne2k_pci 8390 ieee1394 >> snd_page_alloc rtc pcspkr via686a usbcore parport_pc parport evdev reiserfs >> sd_mod pata_via libata scsi_mod dm_mirror dm_mod >> [ 752.645759] >> [ 752.646990] Pid: 3403, comm: pktcdvd0 Not tainted (2.6.23-rc4-mm1 #50) >> [ 752.648256] EIP: 0060:[__bio_add_page+212/355] EFLAGS: 00010246 CPU: 0 >> [ 752.649515] EIP is at __bio_add_page+0xd4/0x163 >> [ 752.650750] EAX: EBX: ECX: c26ca400 EDX: >> [ 752.651984] ESI: cba3cf48 EDI: c1174be0 EBP: cb01cef4 ESP: cb01cee4 >> [ 752.653219] DS: 007b ES: 007b FS: GS: SS: 0068 >> [ 752.654446] Process pktcdvd0 (pid: 3403, ti=cb01c000 task=c1b9cdb0 >> task.ti=cb01c000) >> [ 752.654526] Stack: c26ca400 cba3cf48 c1174be0 0001 cb01cf10 c017b763 >> 0800 0800 >> [ 752.655908]0040 cba3cf48 cb06e120 cb01cfd0 e1d94044 0800 >> 0004 cb09b8a0 >> [ 752.657297]c1853ce0 0800 0001 >> >> [ 752.658695] Call Trace: >> [ 752.661126] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f >> [ 752.662383] [show_stack_log_lvl+155/163] show_stack_log_lvl+0x9b/0xa3 >> [ 752.663626] [show_registers+160/482] show_registers+0xa0/0x1e2 >> [ 752.664868] [die+261/567] die+0x105/0x237 >> [ 752.666072] [do_page_fault+1127/1349] do_page_fault+0x467/0x545 >> [ 752.667274] [error_code+106/112] error_code+0x6a/0x70 >> [ 752.668477] [bio_add_page+54/61] bio_add_page+0x36/0x3d >> [ 752.669669] [] kcdrwd+0x5a5/0x9ba [pktcdvd] >> [ 752.670856] [kthread+57/97] kthread+0x39/0x61 >> [ 752.672024] [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 >> [ 752.673197] === >> [ 752.674336] Code: ba 01 00 00 00 8b 4d f0 8b 46 18 66 3b 81 50 01 00 00 >> 73 da 66 8b 46 1a 66 3b 81 52 01 00 00 73 cd 0f >> b7 46 14 6b d8 0c 03 5e 2c <89> 3b 8b 45 08 89 43 04 8b 4d 0c 89 4b 08 8b 45 >> f0 8b 78 68 85 >> [ 752.677879] EIP: [__bio_add_page+212/355] __bio_add_page+0xd4/0x163 >> SS:ESP 0068:cb01cee4 I dig through git-block.patch and the culprit seems to be commit c94f1c4ac87862675c8d70941973bc3a69aff5d8 "bio: use memset() in bio_init()". Maybe the real bug is a bad bio initialization in pktcdvd driver, which is revealed by this commit ? > 2.6.23-rc4 and 2.6.23-rc3-mm1 work fine. > > Steps to reproduce: > $ pktsetup /dev/pktcdvd/0 /dev/sr0 > # put an UDF-formatted DVD-RW in the drive > $ mount -o noatime,nodiratime,rw /dev/pktcdvd/0 /media/pkt > $ sync > > /dev/sr0 drive is a LG-branded DVD burner: > Vendor: HL-DT-ST Model: DVDRAM GSA-4165B Rev: DL03 > - 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.23-rc4-mm1: git-block.patch broke pktcdvd
Le 10.09.2007 22:19, Laurent Riffard a écrit : Le 01.09.2007 06:58, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ [...] Jens, git-block.patch broke pktcdvd, I've got an Oops while syncing: [ 713.014888] pktcdvd: Fixed packets, 16 blocks, Mode-1 disc [ 713.021844] pktcdvd: write speed 2770kB/s [ 718.401761] pktcdvd: 4595774kB available on disc [ 721.175644] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2006/10/08 21:17 (1078) [ 721.213784] mount used greatest stack depth: 460 bytes left [ 752.634402] BUG: unable to handle kernel NULL pointer dereference at virtual address [ 752.635711] printing eip: c017b69e *pde = [ 752.636983] Oops: 0002 [#1] PREEMPT [ 752.638240] last sysfs file: /devices/pci:00/:00:0d.0/modalias [ 752.639477] Modules linked in: udf binfmt_misc pktcdvd radeon drm lp nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm sg firewire_ohci firewire_core sr_mod cdrom crc_itu_t snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd 8250_pnp i2c_viapro via_agp floppy ohci1394 soundcore 8250 serial_core ata_generic uhci_hcd agpgart ne2k_pci 8390 ieee1394 snd_page_alloc rtc pcspkr via686a usbcore parport_pc parport evdev reiserfs sd_mod pata_via libata scsi_mod dm_mirror dm_mod [ 752.645759] [ 752.646990] Pid: 3403, comm: pktcdvd0 Not tainted (2.6.23-rc4-mm1 #50) [ 752.648256] EIP: 0060:[__bio_add_page+212/355] EFLAGS: 00010246 CPU: 0 [ 752.649515] EIP is at __bio_add_page+0xd4/0x163 [ 752.650750] EAX: EBX: ECX: c26ca400 EDX: [ 752.651984] ESI: cba3cf48 EDI: c1174be0 EBP: cb01cef4 ESP: cb01cee4 [ 752.653219] DS: 007b ES: 007b FS: GS: SS: 0068 [ 752.654446] Process pktcdvd0 (pid: 3403, ti=cb01c000 task=c1b9cdb0 task.ti=cb01c000) [ 752.654526] Stack: c26ca400 cba3cf48 c1174be0 0001 cb01cf10 c017b763 0800 0800 [ 752.655908]0040 cba3cf48 cb06e120 cb01cfd0 e1d94044 0800 0004 cb09b8a0 [ 752.657297]c1853ce0 0800 0001 [ 752.658695] Call Trace: [ 752.661126] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f [ 752.662383] [show_stack_log_lvl+155/163] show_stack_log_lvl+0x9b/0xa3 [ 752.663626] [show_registers+160/482] show_registers+0xa0/0x1e2 [ 752.664868] [die+261/567] die+0x105/0x237 [ 752.666072] [do_page_fault+1127/1349] do_page_fault+0x467/0x545 [ 752.667274] [error_code+106/112] error_code+0x6a/0x70 [ 752.668477] [bio_add_page+54/61] bio_add_page+0x36/0x3d [ 752.669669] [e1d94044] kcdrwd+0x5a5/0x9ba [pktcdvd] [ 752.670856] [kthread+57/97] kthread+0x39/0x61 [ 752.672024] [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 [ 752.673197] === [ 752.674336] Code: ba 01 00 00 00 8b 4d f0 8b 46 18 66 3b 81 50 01 00 00 73 da 66 8b 46 1a 66 3b 81 52 01 00 00 73 cd 0f b7 46 14 6b d8 0c 03 5e 2c 89 3b 8b 45 08 89 43 04 8b 4d 0c 89 4b 08 8b 45 f0 8b 78 68 85 [ 752.677879] EIP: [__bio_add_page+212/355] __bio_add_page+0xd4/0x163 SS:ESP 0068:cb01cee4 I dig through git-block.patch and the culprit seems to be commit c94f1c4ac87862675c8d70941973bc3a69aff5d8 bio: use memset() in bio_init(). Maybe the real bug is a bad bio initialization in pktcdvd driver, which is revealed by this commit ? 2.6.23-rc4 and 2.6.23-rc3-mm1 work fine. Steps to reproduce: $ pktsetup /dev/pktcdvd/0 /dev/sr0 # put an UDF-formatted DVD-RW in the drive $ mount -o noatime,nodiratime,rw /dev/pktcdvd/0 /media/pkt $ sync /dev/sr0 drive is a LG-branded DVD burner: Vendor: HL-DT-ST Model: DVDRAM GSA-4165B Rev: DL03 - 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.23-rc4-mm1: git-block.patch broke pktcdvd
Le 01.09.2007 06:58, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ [...] Jens, git-block.patch broke pktcdvd, I've got an Oops while syncing: > [ 713.014888] pktcdvd: Fixed packets, 16 blocks, Mode-1 disc > [ 713.021844] pktcdvd: write speed 2770kB/s > [ 718.401761] pktcdvd: 4595774kB available on disc > [ 721.175644] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume > 'LinuxUDF', timestamp 2006/10/08 21:17 (1078) > [ 721.213784] mount used greatest stack depth: 460 bytes left > [ 752.634402] BUG: unable to handle kernel NULL pointer dereference at > virtual address > [ 752.635711] printing eip: c017b69e *pde = > [ 752.636983] Oops: 0002 [#1] PREEMPT > [ 752.638240] last sysfs file: /devices/pci:00/:00:0d.0/modalias > [ 752.639477] Modules linked in: udf binfmt_misc pktcdvd radeon drm lp > nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom > w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss > snd_mixer_oss snd_pcm sg firewire_ohci firewire_core sr_mod cdrom crc_itu_t > snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer > snd_seq_device snd 8250_pnp i2c_viapro via_agp floppy ohci1394 soundcore 8250 > serial_core ata_generic uhci_hcd agpgart ne2k_pci 8390 ieee1394 > snd_page_alloc rtc pcspkr via686a usbcore parport_pc parport evdev reiserfs > sd_mod pata_via libata scsi_mod dm_mirror dm_mod > [ 752.645759] > [ 752.646990] Pid: 3403, comm: pktcdvd0 Not tainted (2.6.23-rc4-mm1 #50) > [ 752.648256] EIP: 0060:[__bio_add_page+212/355] EFLAGS: 00010246 CPU: 0 > [ 752.649515] EIP is at __bio_add_page+0xd4/0x163 > [ 752.650750] EAX: EBX: ECX: c26ca400 EDX: > [ 752.651984] ESI: cba3cf48 EDI: c1174be0 EBP: cb01cef4 ESP: cb01cee4 > [ 752.653219] DS: 007b ES: 007b FS: GS: SS: 0068 > [ 752.654446] Process pktcdvd0 (pid: 3403, ti=cb01c000 task=c1b9cdb0 > task.ti=cb01c000) > [ 752.654526] Stack: c26ca400 cba3cf48 c1174be0 0001 cb01cf10 c017b763 > 0800 0800 > [ 752.655908]0040 cba3cf48 cb06e120 cb01cfd0 e1d94044 0800 > 0004 cb09b8a0 > [ 752.657297]c1853ce0 0800 0001 > > [ 752.658695] Call Trace: > [ 752.661126] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f > [ 752.662383] [show_stack_log_lvl+155/163] show_stack_log_lvl+0x9b/0xa3 > [ 752.663626] [show_registers+160/482] show_registers+0xa0/0x1e2 > [ 752.664868] [die+261/567] die+0x105/0x237 > [ 752.666072] [do_page_fault+1127/1349] do_page_fault+0x467/0x545 > [ 752.667274] [error_code+106/112] error_code+0x6a/0x70 > [ 752.668477] [bio_add_page+54/61] bio_add_page+0x36/0x3d > [ 752.669669] [] kcdrwd+0x5a5/0x9ba [pktcdvd] > [ 752.670856] [kthread+57/97] kthread+0x39/0x61 > [ 752.672024] [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 > [ 752.673197] === > [ 752.674336] Code: ba 01 00 00 00 8b 4d f0 8b 46 18 66 3b 81 50 01 00 00 > 73 da 66 8b 46 1a 66 3b 81 52 01 00 00 73 cd 0f > b7 46 14 6b d8 0c 03 5e 2c <89> 3b 8b 45 08 89 43 04 8b 4d 0c 89 4b 08 8b 45 > f0 8b 78 68 85 > [ 752.677879] EIP: [__bio_add_page+212/355] __bio_add_page+0xd4/0x163 > SS:ESP 0068:cb01cee4 2.6.23-rc4 and 2.6.23-rc3-mm1 work fine. Steps to reproduce: $ pktsetup /dev/pktcdvd/0 /dev/sr0 # put an UDF-formatted DVD-RW in the drive $ mount -o noatime,nodiratime,rw /dev/pktcdvd/0 /media/pkt $ sync /dev/sr0 drive is a LG-branded DVD burner: Vendor: HL-DT-ST Model: DVDRAM GSA-4165B Rev: DL03 .config is attached. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc4-mm1 # Sat Sep 1 23:24:40 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CONTAINERS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y
Re: 2.6.23-rc4-mm1: git-block.patch broke pktcdvd
Le 01.09.2007 06:58, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ [...] Jens, git-block.patch broke pktcdvd, I've got an Oops while syncing: [ 713.014888] pktcdvd: Fixed packets, 16 blocks, Mode-1 disc [ 713.021844] pktcdvd: write speed 2770kB/s [ 718.401761] pktcdvd: 4595774kB available on disc [ 721.175644] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2006/10/08 21:17 (1078) [ 721.213784] mount used greatest stack depth: 460 bytes left [ 752.634402] BUG: unable to handle kernel NULL pointer dereference at virtual address [ 752.635711] printing eip: c017b69e *pde = [ 752.636983] Oops: 0002 [#1] PREEMPT [ 752.638240] last sysfs file: /devices/pci:00/:00:0d.0/modalias [ 752.639477] Modules linked in: udf binfmt_misc pktcdvd radeon drm lp nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm sg firewire_ohci firewire_core sr_mod cdrom crc_itu_t snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd 8250_pnp i2c_viapro via_agp floppy ohci1394 soundcore 8250 serial_core ata_generic uhci_hcd agpgart ne2k_pci 8390 ieee1394 snd_page_alloc rtc pcspkr via686a usbcore parport_pc parport evdev reiserfs sd_mod pata_via libata scsi_mod dm_mirror dm_mod [ 752.645759] [ 752.646990] Pid: 3403, comm: pktcdvd0 Not tainted (2.6.23-rc4-mm1 #50) [ 752.648256] EIP: 0060:[__bio_add_page+212/355] EFLAGS: 00010246 CPU: 0 [ 752.649515] EIP is at __bio_add_page+0xd4/0x163 [ 752.650750] EAX: EBX: ECX: c26ca400 EDX: [ 752.651984] ESI: cba3cf48 EDI: c1174be0 EBP: cb01cef4 ESP: cb01cee4 [ 752.653219] DS: 007b ES: 007b FS: GS: SS: 0068 [ 752.654446] Process pktcdvd0 (pid: 3403, ti=cb01c000 task=c1b9cdb0 task.ti=cb01c000) [ 752.654526] Stack: c26ca400 cba3cf48 c1174be0 0001 cb01cf10 c017b763 0800 0800 [ 752.655908]0040 cba3cf48 cb06e120 cb01cfd0 e1d94044 0800 0004 cb09b8a0 [ 752.657297]c1853ce0 0800 0001 [ 752.658695] Call Trace: [ 752.661126] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f [ 752.662383] [show_stack_log_lvl+155/163] show_stack_log_lvl+0x9b/0xa3 [ 752.663626] [show_registers+160/482] show_registers+0xa0/0x1e2 [ 752.664868] [die+261/567] die+0x105/0x237 [ 752.666072] [do_page_fault+1127/1349] do_page_fault+0x467/0x545 [ 752.667274] [error_code+106/112] error_code+0x6a/0x70 [ 752.668477] [bio_add_page+54/61] bio_add_page+0x36/0x3d [ 752.669669] [e1d94044] kcdrwd+0x5a5/0x9ba [pktcdvd] [ 752.670856] [kthread+57/97] kthread+0x39/0x61 [ 752.672024] [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 [ 752.673197] === [ 752.674336] Code: ba 01 00 00 00 8b 4d f0 8b 46 18 66 3b 81 50 01 00 00 73 da 66 8b 46 1a 66 3b 81 52 01 00 00 73 cd 0f b7 46 14 6b d8 0c 03 5e 2c 89 3b 8b 45 08 89 43 04 8b 4d 0c 89 4b 08 8b 45 f0 8b 78 68 85 [ 752.677879] EIP: [__bio_add_page+212/355] __bio_add_page+0xd4/0x163 SS:ESP 0068:cb01cee4 2.6.23-rc4 and 2.6.23-rc3-mm1 work fine. Steps to reproduce: $ pktsetup /dev/pktcdvd/0 /dev/sr0 # put an UDF-formatted DVD-RW in the drive $ mount -o noatime,nodiratime,rw /dev/pktcdvd/0 /media/pkt $ sync /dev/sr0 drive is a LG-branded DVD burner: Vendor: HL-DT-ST Model: DVDRAM GSA-4165B Rev: DL03 .config is attached. ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc4-mm1 # Sat Sep 1 23:24:40 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CONTAINERS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y #
Re: 2.6.23-rc4-mm1: broke pata_via cable detection
Le 01.09.2007 06:58, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ [...] > +libata-correct-handling-of-srst-reset-sequences.patch [...] Alan, libata-correct-handling-of-srst-reset-sequences.patch broke 80-wire cable detection on pata_via driver: > $ dmesg | grep ata1 > ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq 14 > ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 > ata1.00: 78165360 sectors, multi 16: LBA > ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 > ata1.01: 160086528 sectors, multi 16: LBA > ata1.00: limited to UDMA/33 due to 40-wire cable > ata1.01: limited to UDMA/33 due to 40-wire cable > ata1.00: configured for UDMA/33 > ata1.01: configured for UDMA/33 2.6.23-rc3-mm1 and 2.6.23-rc4 work fine (ata1 devices are configured for UDMA/100). Few weeks ago, I wrote a patch to solve a wrong cable detection problem after suspend-to-disk/resume, and it solves this problem too. Is it the right way to go ? via_do_set_mode overwrites 80-wire cable detection bits. Let's preserve them. Signed-off-by: Laurent Riffard <[EMAIL PROTECTED]> --- drivers/ata/pata_via.c |7 +++ 1 file changed, 7 insertions(+) Index: linux-2.6-mm/drivers/ata/pata_via.c === --- linux-2.6-mm.orig/drivers/ata/pata_via.c +++ linux-2.6-mm/drivers/ata/pata_via.c @@ -245,6 +245,7 @@ static void via_do_set_mode(struct ata_p unsigned long T = 10 / via_clock; unsigned long UT = T/tdiv; int ut; + u8 cable80_status; int offset = 3 - (2*ap->port_no) - adev->devno; @@ -294,9 +295,14 @@ static void via_do_set_mode(struct ata_p ut = t.udma ? (0xe0 | (FIT(t.udma, 2, 9) - 2)) : 0x07; break; } + + /* Get 80-wire cable detection bit */ + pci_read_config_byte(pdev, 0x50 + offset, _status); + cable80_status &= 0x10; + /* Set UDMA unless device is not UDMA capable */ if (udma_type) - pci_write_config_byte(pdev, 0x50 + offset, ut); + pci_write_config_byte(pdev, 0x50 + offset, ut | cable80_status); } static void via_set_piomode(struct ata_port *ap, struct ata_device *adev) - 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.23-rc4-mm1: broke pata_via cable detection
Le 01.09.2007 06:58, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ [...] +libata-correct-handling-of-srst-reset-sequences.patch [...] Alan, libata-correct-handling-of-srst-reset-sequences.patch broke 80-wire cable detection on pata_via driver: $ dmesg | grep ata1 ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq 14 ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 ata1.00: 78165360 sectors, multi 16: LBA ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 ata1.01: 160086528 sectors, multi 16: LBA ata1.00: limited to UDMA/33 due to 40-wire cable ata1.01: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 ata1.01: configured for UDMA/33 2.6.23-rc3-mm1 and 2.6.23-rc4 work fine (ata1 devices are configured for UDMA/100). Few weeks ago, I wrote a patch to solve a wrong cable detection problem after suspend-to-disk/resume, and it solves this problem too. Is it the right way to go ? via_do_set_mode overwrites 80-wire cable detection bits. Let's preserve them. Signed-off-by: Laurent Riffard [EMAIL PROTECTED] --- drivers/ata/pata_via.c |7 +++ 1 file changed, 7 insertions(+) Index: linux-2.6-mm/drivers/ata/pata_via.c === --- linux-2.6-mm.orig/drivers/ata/pata_via.c +++ linux-2.6-mm/drivers/ata/pata_via.c @@ -245,6 +245,7 @@ static void via_do_set_mode(struct ata_p unsigned long T = 10 / via_clock; unsigned long UT = T/tdiv; int ut; + u8 cable80_status; int offset = 3 - (2*ap-port_no) - adev-devno; @@ -294,9 +295,14 @@ static void via_do_set_mode(struct ata_p ut = t.udma ? (0xe0 | (FIT(t.udma, 2, 9) - 2)) : 0x07; break; } + + /* Get 80-wire cable detection bit */ + pci_read_config_byte(pdev, 0x50 + offset, cable80_status); + cable80_status = 0x10; + /* Set UDMA unless device is not UDMA capable */ if (udma_type) - pci_write_config_byte(pdev, 0x50 + offset, ut); + pci_write_config_byte(pdev, 0x50 + offset, ut | cable80_status); } static void via_set_piomode(struct ata_port *ap, struct ata_device *adev) - 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.23-rc1-mm2 (checks-for-80wire-cable-use-in-pata_via)
Le 01.08.2007 08:09, Andrew Morton a écrit : > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm2/ ... > +libata-acpi-checks-for-80wire-cable-use-in-pata_via.patch ... > sata/pata things Alan, this does not work after a suspend-resume cycle, I get a " ACPI get timing mode failed (AE 0x1001)" error. $ dmesg | grep ata ... scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001b800 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001b808 irq 15 ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 ata1.00: 78165360 sectors, multi 16: LBA ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 ata1.01: 160086528 sectors, multi 16: LBA ata1.00: configured for UDMA/100 ata1.01: configured for UDMA/100 ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL03, max UDMA/33 ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr ata2.00: configured for UDMA/33 ata2.01: configured for MWDMA2 ata1.00: Unable to set Link PM policy ata1.01: Unable to set Link PM policy ata2.00: Unable to set Link PM policy ata2.01: Unable to set Link PM policy ... [ suspend-to-disk/resume cycle happens here ] ... ata1.00: Unable to set Link PM policy ata1.01: Unable to set Link PM policy ata2.00: Unable to set Link PM policy ata2.01: Unable to set Link PM policy ata1: ACPI get timing mode failed (AE 0x1001) <== ata1.00: limited to UDMA/33 due to 40-wire cable ata1.01: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 ata1.01: configured for UDMA/33 ata2: ACPI get timing mode failed (AE 0x1001) ata2.00: configured for UDMA/33 ata2.01: configured for MWDMA2 Anyway, long before 2.6.23-rc1-mm2, 80-wire cable detection was already wrong after a suspend-resume cycle. So I cooked the following patch 2 days ago. It may be the wrong approach but it works for me. -- pata_via: preserve cable detection bits in via_do_set_mode via_cable_detect performs cable detection by checking bits in PCI layer. But via_do_set_mode overwrites these bits. This behaviour breaks cable detection after suspend/resume cycle. So let's teach via_do_set_mode to preserve cable detection bits. Signed-off-by: Laurent Riffard <[EMAIL PROTECTED]> --- drivers/ata/pata_via.c |7 +++ 1 file changed, 7 insertions(+) Index: linux-2.6-mm/drivers/ata/pata_via.c === --- linux-2.6-mm.orig/drivers/ata/pata_via.c +++ linux-2.6-mm/drivers/ata/pata_via.c @@ -238,6 +238,7 @@ static void via_do_set_mode(struct ata_p unsigned long T = 10 / via_clock; unsigned long UT = T/tdiv; int ut; + u8 cable80_status; int offset = 3 - (2*ap->port_no) - adev->devno; @@ -287,6 +288,12 @@ static void via_do_set_mode(struct ata_p ut = t.udma ? (0xe0 | (FIT(t.udma, 2, 9) - 2)) : 0x07; break; } + + /* Preserve cable detection bit */ + pci_read_config_byte(pdev, 0x50 + offset, _status); + cable80_status &= 0x10; + ut |= cable80_status; + /* Set UDMA unless device is not UDMA capable */ if (udma_type) pci_write_config_byte(pdev, 0x50 + offset, ut); - 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.23-rc1-mm2 (checks-for-80wire-cable-use-in-pata_via)
Le 01.08.2007 08:09, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm2/ ... +libata-acpi-checks-for-80wire-cable-use-in-pata_via.patch ... sata/pata things Alan, this does not work after a suspend-resume cycle, I get a ACPI get timing mode failed (AE 0x1001) error. $ dmesg | grep ata ... scsi0 : pata_via scsi1 : pata_via ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001b800 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001b808 irq 15 ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 ata1.00: 78165360 sectors, multi 16: LBA ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 ata1.01: 160086528 sectors, multi 16: LBA ata1.00: configured for UDMA/100 ata1.01: configured for UDMA/100 ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL03, max UDMA/33 ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr ata2.00: configured for UDMA/33 ata2.01: configured for MWDMA2 ata1.00: Unable to set Link PM policy ata1.01: Unable to set Link PM policy ata2.00: Unable to set Link PM policy ata2.01: Unable to set Link PM policy ... [ suspend-to-disk/resume cycle happens here ] ... ata1.00: Unable to set Link PM policy ata1.01: Unable to set Link PM policy ata2.00: Unable to set Link PM policy ata2.01: Unable to set Link PM policy ata1: ACPI get timing mode failed (AE 0x1001) == ata1.00: limited to UDMA/33 due to 40-wire cable ata1.01: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 ata1.01: configured for UDMA/33 ata2: ACPI get timing mode failed (AE 0x1001) ata2.00: configured for UDMA/33 ata2.01: configured for MWDMA2 Anyway, long before 2.6.23-rc1-mm2, 80-wire cable detection was already wrong after a suspend-resume cycle. So I cooked the following patch 2 days ago. It may be the wrong approach but it works for me. -- pata_via: preserve cable detection bits in via_do_set_mode via_cable_detect performs cable detection by checking bits in PCI layer. But via_do_set_mode overwrites these bits. This behaviour breaks cable detection after suspend/resume cycle. So let's teach via_do_set_mode to preserve cable detection bits. Signed-off-by: Laurent Riffard [EMAIL PROTECTED] --- drivers/ata/pata_via.c |7 +++ 1 file changed, 7 insertions(+) Index: linux-2.6-mm/drivers/ata/pata_via.c === --- linux-2.6-mm.orig/drivers/ata/pata_via.c +++ linux-2.6-mm/drivers/ata/pata_via.c @@ -238,6 +238,7 @@ static void via_do_set_mode(struct ata_p unsigned long T = 10 / via_clock; unsigned long UT = T/tdiv; int ut; + u8 cable80_status; int offset = 3 - (2*ap-port_no) - adev-devno; @@ -287,6 +288,12 @@ static void via_do_set_mode(struct ata_p ut = t.udma ? (0xe0 | (FIT(t.udma, 2, 9) - 2)) : 0x07; break; } + + /* Preserve cable detection bit */ + pci_read_config_byte(pdev, 0x50 + offset, cable80_status); + cable80_status = 0x10; + ut |= cable80_status; + /* Set UDMA unless device is not UDMA capable */ if (udma_type) pci_write_config_byte(pdev, 0x50 + offset, ut); - 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: REISER4: fix for reiser4_write_extent
Le 06.04.2007 00:42, Ignatich a écrit : While trying to find the cause of problems with reiser4 in recent kernels I came across this. Incomplete write handling seem to be missing from reiser4_write_extent() thanks to reiser4-temp-fix.patch. Strangely, there is a patch by Edward Shishkin that should address that issue, but it is missing from -mm tree. Please check. Max This patch was added to -mm tree the 14 Dec 2006 (see http://www.mail-archive.com/mm-commits@vger.kernel.org/msg05338.html). It was then dropped from -mm tree the 05 Mar 2007 (see http://www.mail-archive.com/mm-commits@vger.kernel.org/msg10818.html), with this comment: "This patch was dropped because it is obsolete" No idea why it was obsolete. Does somebody know ? ~~ laurent - 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: REISER4: fix for reiser4_write_extent
Le 06.04.2007 00:42, Ignatich a écrit : While trying to find the cause of problems with reiser4 in recent kernels I came across this. Incomplete write handling seem to be missing from reiser4_write_extent() thanks to reiser4-temp-fix.patch. Strangely, there is a patch by Edward Shishkin that should address that issue, but it is missing from -mm tree. Please check. Max This patch was added to -mm tree the 14 Dec 2006 (see http://www.mail-archive.com/mm-commits@vger.kernel.org/msg05338.html). It was then dropped from -mm tree the 05 Mar 2007 (see http://www.mail-archive.com/mm-commits@vger.kernel.org/msg10818.html), with this comment: This patch was dropped because it is obsolete No idea why it was obsolete. Does somebody know ? ~~ laurent - 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/5] 2.6.21-rc5: known regressions
Le 27.03.2007 03:59, Adrian Bunk a écrit :
This email lists some known regressions in Linus' tree compared to 2.6.20.
...
Subject: libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
http://bugzilla.kernel.org/show_bug.cgi?id=8133
http://bugzilla.kernel.org/show_bug.cgi?id=8164
http://lkml.org/lkml/2007/3/21/330
Submitter : Fabio Comolli <[EMAIL PROTECTED]>
Plamen Petrov <[EMAIL PROTECTED]>
Laurent Riffard <[EMAIL PROTECTED]>
Lukas Hejtmanek <[EMAIL PROTECTED]>
Handled-By : Tejun Heo <[EMAIL PROTECTED]>
Patch : http://thread.gmane.org/gmane.linux.ide/17444
Status : patch available
pata-via case is fixed for me in 2.6.21-rc5-mm2 (was already fixed in
2.6.21-rc4-mm1).
thanks
~~
laurent
-
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/5] 2.6.21-rc5: known regressions
Le 27.03.2007 03:59, Adrian Bunk a écrit : This email lists some known regressions in Linus' tree compared to 2.6.20. ... Subject: libata: PATA UDMA/100 configured as UDMA/33 References : http://lkml.org/lkml/2007/2/20/294 http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html http://bugzilla.kernel.org/show_bug.cgi?id=8133 http://bugzilla.kernel.org/show_bug.cgi?id=8164 http://lkml.org/lkml/2007/3/21/330 Submitter : Fabio Comolli [EMAIL PROTECTED] Plamen Petrov [EMAIL PROTECTED] Laurent Riffard [EMAIL PROTECTED] Lukas Hejtmanek [EMAIL PROTECTED] Handled-By : Tejun Heo [EMAIL PROTECTED] Patch : http://thread.gmane.org/gmane.linux.ide/17444 Status : patch available pata-via case is fixed for me in 2.6.21-rc5-mm2 (was already fixed in 2.6.21-rc4-mm1). thanks ~~ laurent - 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.21-rc2-mm1: pata_via: wrong cable detection
Le 02.03.2007 12:00, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/ Hello, My 2 hard drives are connected to the same pata slot with a 80-wire cable. But kernel found a 40-wire cable for the master HD! $ dmesg | grep ata ... pata_via :00:04.1: version 0.2.1 ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001b800 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001b808 irq 15 scsi0 : pata_via ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 ata1.00: 78165360 sectors, multi 16: LBA ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 ata1.01: 160086528 sectors, multi 16: LBA ata1.00: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 ata1.01: configured for UDMA/100 scsi1 : pata_via ata2.00: ATAPI, max UDMA/33 ata2.01: ATAPI, max MWDMA2, CDB intr ata2.00: configured for UDMA/33 ata2.01: configured for MWDMA2 ... (A DVD burner and a CDROM drive are plugged on the 2nd pata slot with a 40-wire cable). ~~ laurent - 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.21-rc2-mm1: what about CONFIG_NO_HZ and !CONFIG_SMP ?
Le 02.03.2007 21:57, Siddha, Suresh B a écrit :
On Fri, Mar 02, 2007 at 10:12:25PM +0100, Laurent Riffard wrote:
Le 02.03.2007 12:00, Andrew Morton a écrit :
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/
Got this when CONFIG_NO_HZ=y and CONFIG_SMP=n:
CC kernel/sched.o
kernel/sched.c: In function 'trigger_load_balance':
kernel/sched.c:3384: error: 'struct rq' has no member named 'in_nohz_recently'
kernel/sched.c:3384: error: 'struct rq' has no member named 'idle_at_tick'
kernel/sched.c:3385: error: 'struct rq' has no member named 'in_nohz_recently'
kernel/sched.c:3387: error: 'nohz' undeclared (first use in this function)
kernel/sched.c:3387: error: (Each undeclared identifier is reported only once
kernel/sched.c:3387: error: for each function it appears in.)
kernel/sched.c:3404: warning: implicit declaration of function 'resched_cpu'
kernel/sched.c:3412: error: 'struct rq' has no member named 'idle_at_tick'
kernel/sched.c:3422: error: 'struct rq' has no member named 'idle_at_tick'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
Looking at kernel/sched.c, it seems CONFIG_NO_HZ should depend on CONFIG_SMP...
No. There is no such dependency. Can you please check if the below patch fixes
the compilation issue. Thanks.
Yes, it does fix the compilation issue.
thanks
~~
laurent
Move trigger_load_balance() under ifdef CONFIG_SMP.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
---
diff -pNru linux-2.6.21-rc2/kernel/sched.c linux-mm/kernel/sched.c
--- linux-2.6.21-rc2/kernel/sched.c 2007-03-02 13:23:46.0 -0800
+++ linux-mm/kernel/sched.c 2007-03-02 13:26:38.0 -0800
@@ -3156,6 +3156,68 @@ static void run_rebalance_domains(struct
}
#endif
}
+
+/*
+ * Trigger the SCHED_SOFTIRQ if it is time to do periodic load balancing.
+ *
+ * In case of CONFIG_NO_HZ, this is the place where we nominate a new
+ * idle load balancing owner or decide to stop the periodic load balancing,
+ * if the whole system is idle.
+ */
+static inline void trigger_load_balance(int cpu)
+{
+ struct rq *rq = cpu_rq(cpu);
+#ifdef CONFIG_NO_HZ
+ /*
+* If we were in the nohz mode recently and busy at the current
+* scheduler tick, then check if we need to nominate new idle
+* load balancer.
+*/
+ if (rq->in_nohz_recently && !rq->idle_at_tick) {
+ rq->in_nohz_recently = 0;
+
+ if (atomic_read(_balancer) == cpu) {
+ cpu_clear(cpu, nohz.cpu_mask);
+ atomic_set(_balancer, -1);
+ }
+
+ if (atomic_read(_balancer) == -1) {
+ /*
+* simple selection for now: Nominate the
+* first cpu in the nohz list to be the next
+* ilb owner.
+*
+* TBD: Traverse the sched domains and nominate
+* the nearest cpu in the nohz.cpu_mask.
+*/
+ int ilb = first_cpu(nohz.cpu_mask);
+
+ if (ilb != NR_CPUS)
+ resched_cpu(ilb);
+ }
+ }
+
+ /*
+* If this cpu is idle and doing idle load balancing for all the
+* cpus with ticks stopped, is it time for that to stop?
+*/
+ if (rq->idle_at_tick && atomic_read(_balancer) == cpu &&
+ cpus_weight(nohz.cpu_mask) == num_online_cpus()) {
+ resched_cpu(cpu);
+ return;
+ }
+
+ /*
+* If this cpu is idle and the idle load balancing is done by
+* someone else, then no need raise the SCHED_SOFTIRQ
+*/
+ if (rq->idle_at_tick && atomic_read(_balancer) != cpu &&
+ cpu_isset(cpu, nohz.cpu_mask))
+ return;
+#endif
+ if (time_after_eq(jiffies, rq->next_balance))
+ raise_softirq(SCHED_SOFTIRQ);
+}
#else
/*
* on UP we do not need to balance between CPUs:
@@ -3366,68 +3428,6 @@ out_unlock:
}
/*
- * Trigger the SCHED_SOFTIRQ if it is time to do periodic load balancing.
- *
- * In case of CONFIG_NO_HZ, this is the place where we nominate a new
- * idle load balancing owner or decide to stop the periodic load balancing,
- * if the whole system is idle.
- */
-static inline void trigger_load_balance(int cpu)
-{
- struct rq *rq = cpu_rq(cpu);
-#ifdef CONFIG_NO_HZ
- /*
-* If we were in the nohz mode recently and busy at the current
-* scheduler tick, then check if we need to nominate new idle
-* load balancer.
-*/
- if (rq->in_nohz_recently && !rq->idle_at_tick) {
- rq->in_nohz_recently = 0;
-
- if (atom
Re: 2.6.21-rc2-mm1: what about CONFIG_NO_HZ and !CONFIG_SMP ?
Le 02.03.2007 12:00, Andrew Morton a écrit :
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/
Got this when CONFIG_NO_HZ=y and CONFIG_SMP=n:
CC kernel/sched.o
kernel/sched.c: In function 'trigger_load_balance':
kernel/sched.c:3384: error: 'struct rq' has no member named 'in_nohz_recently'
kernel/sched.c:3384: error: 'struct rq' has no member named 'idle_at_tick'
kernel/sched.c:3385: error: 'struct rq' has no member named 'in_nohz_recently'
kernel/sched.c:3387: error: 'nohz' undeclared (first use in this function)
kernel/sched.c:3387: error: (Each undeclared identifier is reported only once
kernel/sched.c:3387: error: for each function it appears in.)
kernel/sched.c:3404: warning: implicit declaration of function 'resched_cpu'
kernel/sched.c:3412: error: 'struct rq' has no member named 'idle_at_tick'
kernel/sched.c:3422: error: 'struct rq' has no member named 'idle_at_tick'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
Looking at kernel/sched.c, it seems CONFIG_NO_HZ should depend on CONFIG_SMP...
238 struct rq {
239 spinlock_t lock;
240
241 /*
242 * nr_running and cpu_load should be in the same cacheline because
243 * remote CPUs use both these fields when doing load calculation.
244 */
245 unsigned long nr_running;
246 unsigned long raw_weighted_load;
247 #ifdef CONFIG_SMP
248 unsigned long cpu_load[3];
249 unsigned char idle_at_tick;
250 #ifdef CONFIG_NO_HZ
251 unsigned char in_nohz_recently;
252 #endif
253 #endif
254 unsigned long long nr_switches;
~~
laurent
-
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.21-rc2-mm1: what about CONFIG_NO_HZ and !CONFIG_SMP ?
Le 02.03.2007 12:00, Andrew Morton a écrit :
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/
Got this when CONFIG_NO_HZ=y and CONFIG_SMP=n:
CC kernel/sched.o
kernel/sched.c: In function 'trigger_load_balance':
kernel/sched.c:3384: error: 'struct rq' has no member named 'in_nohz_recently'
kernel/sched.c:3384: error: 'struct rq' has no member named 'idle_at_tick'
kernel/sched.c:3385: error: 'struct rq' has no member named 'in_nohz_recently'
kernel/sched.c:3387: error: 'nohz' undeclared (first use in this function)
kernel/sched.c:3387: error: (Each undeclared identifier is reported only once
kernel/sched.c:3387: error: for each function it appears in.)
kernel/sched.c:3404: warning: implicit declaration of function 'resched_cpu'
kernel/sched.c:3412: error: 'struct rq' has no member named 'idle_at_tick'
kernel/sched.c:3422: error: 'struct rq' has no member named 'idle_at_tick'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
Looking at kernel/sched.c, it seems CONFIG_NO_HZ should depend on CONFIG_SMP...
238 struct rq {
239 spinlock_t lock;
240
241 /*
242 * nr_running and cpu_load should be in the same cacheline because
243 * remote CPUs use both these fields when doing load calculation.
244 */
245 unsigned long nr_running;
246 unsigned long raw_weighted_load;
247 #ifdef CONFIG_SMP
248 unsigned long cpu_load[3];
249 unsigned char idle_at_tick;
250 #ifdef CONFIG_NO_HZ
251 unsigned char in_nohz_recently;
252 #endif
253 #endif
254 unsigned long long nr_switches;
~~
laurent
-
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.21-rc2-mm1: what about CONFIG_NO_HZ and !CONFIG_SMP ?
Le 02.03.2007 21:57, Siddha, Suresh B a écrit :
On Fri, Mar 02, 2007 at 10:12:25PM +0100, Laurent Riffard wrote:
Le 02.03.2007 12:00, Andrew Morton a écrit :
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/
Got this when CONFIG_NO_HZ=y and CONFIG_SMP=n:
CC kernel/sched.o
kernel/sched.c: In function 'trigger_load_balance':
kernel/sched.c:3384: error: 'struct rq' has no member named 'in_nohz_recently'
kernel/sched.c:3384: error: 'struct rq' has no member named 'idle_at_tick'
kernel/sched.c:3385: error: 'struct rq' has no member named 'in_nohz_recently'
kernel/sched.c:3387: error: 'nohz' undeclared (first use in this function)
kernel/sched.c:3387: error: (Each undeclared identifier is reported only once
kernel/sched.c:3387: error: for each function it appears in.)
kernel/sched.c:3404: warning: implicit declaration of function 'resched_cpu'
kernel/sched.c:3412: error: 'struct rq' has no member named 'idle_at_tick'
kernel/sched.c:3422: error: 'struct rq' has no member named 'idle_at_tick'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
Looking at kernel/sched.c, it seems CONFIG_NO_HZ should depend on CONFIG_SMP...
No. There is no such dependency. Can you please check if the below patch fixes
the compilation issue. Thanks.
Yes, it does fix the compilation issue.
thanks
~~
laurent
Move trigger_load_balance() under ifdef CONFIG_SMP.
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
---
diff -pNru linux-2.6.21-rc2/kernel/sched.c linux-mm/kernel/sched.c
--- linux-2.6.21-rc2/kernel/sched.c 2007-03-02 13:23:46.0 -0800
+++ linux-mm/kernel/sched.c 2007-03-02 13:26:38.0 -0800
@@ -3156,6 +3156,68 @@ static void run_rebalance_domains(struct
}
#endif
}
+
+/*
+ * Trigger the SCHED_SOFTIRQ if it is time to do periodic load balancing.
+ *
+ * In case of CONFIG_NO_HZ, this is the place where we nominate a new
+ * idle load balancing owner or decide to stop the periodic load balancing,
+ * if the whole system is idle.
+ */
+static inline void trigger_load_balance(int cpu)
+{
+ struct rq *rq = cpu_rq(cpu);
+#ifdef CONFIG_NO_HZ
+ /*
+* If we were in the nohz mode recently and busy at the current
+* scheduler tick, then check if we need to nominate new idle
+* load balancer.
+*/
+ if (rq-in_nohz_recently !rq-idle_at_tick) {
+ rq-in_nohz_recently = 0;
+
+ if (atomic_read(nohz.load_balancer) == cpu) {
+ cpu_clear(cpu, nohz.cpu_mask);
+ atomic_set(nohz.load_balancer, -1);
+ }
+
+ if (atomic_read(nohz.load_balancer) == -1) {
+ /*
+* simple selection for now: Nominate the
+* first cpu in the nohz list to be the next
+* ilb owner.
+*
+* TBD: Traverse the sched domains and nominate
+* the nearest cpu in the nohz.cpu_mask.
+*/
+ int ilb = first_cpu(nohz.cpu_mask);
+
+ if (ilb != NR_CPUS)
+ resched_cpu(ilb);
+ }
+ }
+
+ /*
+* If this cpu is idle and doing idle load balancing for all the
+* cpus with ticks stopped, is it time for that to stop?
+*/
+ if (rq-idle_at_tick atomic_read(nohz.load_balancer) == cpu
+ cpus_weight(nohz.cpu_mask) == num_online_cpus()) {
+ resched_cpu(cpu);
+ return;
+ }
+
+ /*
+* If this cpu is idle and the idle load balancing is done by
+* someone else, then no need raise the SCHED_SOFTIRQ
+*/
+ if (rq-idle_at_tick atomic_read(nohz.load_balancer) != cpu
+ cpu_isset(cpu, nohz.cpu_mask))
+ return;
+#endif
+ if (time_after_eq(jiffies, rq-next_balance))
+ raise_softirq(SCHED_SOFTIRQ);
+}
#else
/*
* on UP we do not need to balance between CPUs:
@@ -3366,68 +3428,6 @@ out_unlock:
}
/*
- * Trigger the SCHED_SOFTIRQ if it is time to do periodic load balancing.
- *
- * In case of CONFIG_NO_HZ, this is the place where we nominate a new
- * idle load balancing owner or decide to stop the periodic load balancing,
- * if the whole system is idle.
- */
-static inline void trigger_load_balance(int cpu)
-{
- struct rq *rq = cpu_rq(cpu);
-#ifdef CONFIG_NO_HZ
- /*
-* If we were in the nohz mode recently and busy at the current
-* scheduler tick, then check if we need to nominate new idle
-* load balancer.
-*/
- if (rq-in_nohz_recently !rq-idle_at_tick) {
- rq-in_nohz_recently = 0;
-
- if (atomic_read(nohz.load_balancer) == cpu
Re: 2.6.21-rc2-mm1: pata_via: wrong cable detection
Le 02.03.2007 12:00, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/ Hello, My 2 hard drives are connected to the same pata slot with a 80-wire cable. But kernel found a 40-wire cable for the master HD! $ dmesg | grep ata ... pata_via :00:04.1: version 0.2.1 ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001b800 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001b808 irq 15 scsi0 : pata_via ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100 ata1.00: 78165360 sectors, multi 16: LBA ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 ata1.01: 160086528 sectors, multi 16: LBA ata1.00: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 ata1.01: configured for UDMA/100 scsi1 : pata_via ata2.00: ATAPI, max UDMA/33 ata2.01: ATAPI, max MWDMA2, CDB intr ata2.00: configured for UDMA/33 ata2.01: configured for MWDMA2 ... (A DVD burner and a CDROM drive are plugged on the 2nd pata slot with a 40-wire cable). ~~ laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 01.02.2007 22:52, Edward Shishkin a écrit : Laurent Riffard wrote: Le 01.02.2007 21:04, Edward Shishkin a écrit : Laurent, would you please try 2.6.20-rc6-mm3 + this patch: http://lkml.org/lkml/diff/2007/2/1/195/1 Reiser4 works fine with 2.6.20-rc6-mm2 or 2.6.20-rc6-mm3 without any additional patch (it was broken in rc6-mm1). FWIW, Andrew removed git-block.patch from 2.6.20-rc6-mm2, and he restored git-block.patch without some problematic CFQ updates in 2.6.20-rc6-mm3. In this case, does this patch need testing in rc6-mm3 ? Yes. This is against git-block patch to prevent endless waiting for IO completion. I have reproduced it by ./iozone -B -a -n 524288 -f /mnt/foo on x86 box with 512M RAM available. OK, applied yesterday. I have been using it a few hours with a normal workload and I didn't notice any problem. Thanks -- laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 01.02.2007 22:52, Edward Shishkin a écrit : Laurent Riffard wrote: Le 01.02.2007 21:04, Edward Shishkin a écrit : Laurent, would you please try 2.6.20-rc6-mm3 + this patch: http://lkml.org/lkml/diff/2007/2/1/195/1 Reiser4 works fine with 2.6.20-rc6-mm2 or 2.6.20-rc6-mm3 without any additional patch (it was broken in rc6-mm1). FWIW, Andrew removed git-block.patch from 2.6.20-rc6-mm2, and he restored git-block.patch without some problematic CFQ updates in 2.6.20-rc6-mm3. In this case, does this patch need testing in rc6-mm3 ? Yes. This is against git-block patch to prevent endless waiting for IO completion. I have reproduced it by ./iozone -B -a -n 524288 -f /mnt/foo on x86 box with 512M RAM available. OK, applied yesterday. I have been using it a few hours with a normal workload and I didn't notice any problem. Thanks -- laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 01.02.2007 21:04, Edward Shishkin a écrit : Laurent Riffard wrote: Le 23.01.2007 16:46, Jens Axboe a écrit : On Tue, Jan 23 2007, Vladimir V. Saveliev wrote: Hello On Saturday 13 January 2007 01:56, Laurent Riffard wrote: Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda0380002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [] synchronize_qrcu+0x70/0x8c [] __make_request+0x4c/0x29b [] generic_make_request+0x1b0/0x1de [] submit_bio+0xda/0xe2 [] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [] update_journal_footer+0x29f/0x2b7 [reiser4] [] write_tx_back+0x149/0x185 [reiser4] [] reiser4_write_logs+0xea4/0xfd2 [reiser4] [] try_commit_txnh+0x7e6/0xa4f [reiser4] [] reiser4_txn_end+0x148/0x3cf [reiser4] [] reiser4_txn_restart+0xb/0x1a [reiser4] [] reiser4_txn_restart_current+0x73/0x75 [reiser4] [] force_commit_atom+0x258/0x261 [reiser4] [] txnmgr_force_commit_all+0x406/0x697 [reiser4] [] release_format40+0x10c/0x193 [reiser4] [] reiser4_put_super+0x134/0x16a [reiser4] [] generic_shutdown_super+0x55/0xd8 [] kill_block_super+0x20/0x32 [] deactivate_super+0x3f/0x51 [] mntput_no_expire+0x42/0x5f [] path_release_on_umount+0x15/0x18 [] sys_umount+0x1a3/0x1cb [] sys_oldumount+0x19/0x1b [] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? Which device with reiser4 did you try to umount? Jens wrote that it could be a barrier related. If there are no multidevices involved - please report to bugzilla. Make sure that your kernel contains this fix: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=4af09c42ee1af70356471f51c1f40c1ff7881b68;hp=036f6008f43b5b4dd8c825365f15434d75005c6d I think it missed 2.6.20-rc3-mm1. Again, that assumes you are using md or dm. I've got 2 reiser4 FS: - one with /dev/sdb6 - the other with /dev/vglinux1/ccache (vglinux1 is built on /dev/sda4 and /dev/sdb7). There is no md here, only dm. I applied the above patch on top of 2.6.20-rc4-mm1, but the problem still happens with the two devices. thanks Laurent, would you please try 2.6.20-rc6-mm3 + this patch: http://lkml.org/lkml/diff/2007/2/1/195/1 Reiser4 works fine with 2.6.20-rc6-mm2 or 2.6.20-rc6-mm3 without any additional patch (it was broken in rc6-mm1). FWIW, Andrew removed git-block.patch from 2.6.20-rc6-mm2, and he restored git-block.patch without some problematic CFQ updates in 2.6.20-rc6-mm3. In this case, does this patch need testing in rc6-mm3 ? -- laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 01.02.2007 21:04, Edward Shishkin a écrit : Laurent Riffard wrote: Le 23.01.2007 16:46, Jens Axboe a écrit : On Tue, Jan 23 2007, Vladimir V. Saveliev wrote: Hello On Saturday 13 January 2007 01:56, Laurent Riffard wrote: Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda0380002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [c012d600] synchronize_qrcu+0x70/0x8c [c01bede4] __make_request+0x4c/0x29b [c01bd24b] generic_make_request+0x1b0/0x1de [c01bf354] submit_bio+0xda/0xe2 [e12674bd] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [e12678dd] update_journal_footer+0x29f/0x2b7 [reiser4] [e1268b65] write_tx_back+0x149/0x185 [reiser4] [e126a8e7] reiser4_write_logs+0xea4/0xfd2 [reiser4] [e125626a] try_commit_txnh+0x7e6/0xa4f [reiser4] [e125661b] reiser4_txn_end+0x148/0x3cf [reiser4] [e12568ad] reiser4_txn_restart+0xb/0x1a [reiser4] [e125692f] reiser4_txn_restart_current+0x73/0x75 [reiser4] [e1256b89] force_commit_atom+0x258/0x261 [reiser4] [e1257703] txnmgr_force_commit_all+0x406/0x697 [reiser4] [e12e5e08] release_format40+0x10c/0x193 [reiser4] [e1279922] reiser4_put_super+0x134/0x16a [reiser4] [c015c930] generic_shutdown_super+0x55/0xd8 [c015c9d3] kill_block_super+0x20/0x32 [c015ca75] deactivate_super+0x3f/0x51 [c016d903] mntput_no_expire+0x42/0x5f [c0160f37] path_release_on_umount+0x15/0x18 [c016df77] sys_umount+0x1a3/0x1cb [c016dfb8] sys_oldumount+0x19/0x1b [c0103ed2] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? Which device with reiser4 did you try to umount? Jens wrote that it could be a barrier related. If there are no multidevices involved - please report to bugzilla. Make sure that your kernel contains this fix: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=4af09c42ee1af70356471f51c1f40c1ff7881b68;hp=036f6008f43b5b4dd8c825365f15434d75005c6d I think it missed 2.6.20-rc3-mm1. Again, that assumes you are using md or dm. I've got 2 reiser4 FS: - one with /dev/sdb6 - the other with /dev/vglinux1/ccache (vglinux1 is built on /dev/sda4 and /dev/sdb7). There is no md here, only dm. I applied the above patch on top of 2.6.20-rc4-mm1, but the problem still happens with the two devices. thanks Laurent, would you please try 2.6.20-rc6-mm3 + this patch: http://lkml.org/lkml/diff/2007/2/1/195/1 Reiser4 works fine with 2.6.20-rc6-mm2 or 2.6.20-rc6-mm3 without any additional patch (it was broken in rc6-mm1). FWIW, Andrew removed git-block.patch from 2.6.20-rc6-mm2, and he restored git-block.patch without some problematic CFQ updates in 2.6.20-rc6-mm3. In this case, does this patch need testing in rc6-mm3 ? -- laurent - 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: [PATCH] compile and link utsname_sysctl.o
Le 30.01.2007 16:11, Eric W. Biederman a écrit :
Laurent Riffard <[EMAIL PROTECTED]> writes:
The utsname stuff has been moved from kernel/sysctl.c to the new file
utsname_sysctl.c. Let's use it...
Signed-off-by: Laurent Riffard <[EMAIL PROTECTED]>
Hmm. Maybe something got lost along the way but I have this
line in my kernel/Makefile and in the patch I sent out.
obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
Do you not have that?
mmm...
linux-2.6-mm$ grep SYSCTL kernel/Makefile
linux-2.6-mm$ echo $?
1
linux-2.6-mm$ grep SYSCTL .config
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_SYSCTL=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_PROC_SYSCTL=y
tmp$ grep "obj-\$(CONFIG_SYSCTL)" broken-out/*
tmp$ echo $?
1
tmp$
What problem are you seeing?
Some /proc files were lacking:
/proc/sys/kernel/{osrelease|osrelease|version|...}.
--
laurent
-
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: [PATCH] compile and link utsname_sysctl.o
Le 30.01.2007 16:11, Eric W. Biederman a écrit :
Laurent Riffard [EMAIL PROTECTED] writes:
The utsname stuff has been moved from kernel/sysctl.c to the new file
utsname_sysctl.c. Let's use it...
Signed-off-by: Laurent Riffard [EMAIL PROTECTED]
Hmm. Maybe something got lost along the way but I have this
line in my kernel/Makefile and in the patch I sent out.
obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
Do you not have that?
mmm...
linux-2.6-mm$ grep SYSCTL kernel/Makefile
linux-2.6-mm$ echo $?
1
linux-2.6-mm$ grep SYSCTL .config
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_SYSCTL=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_PROC_SYSCTL=y
tmp$ grep obj-\$(CONFIG_SYSCTL) broken-out/*
tmp$ echo $?
1
tmp$
What problem are you seeing?
Some /proc files were lacking:
/proc/sys/kernel/{osrelease|osrelease|version|...}.
--
laurent
-
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/
[PATCH] compile and link utsname_sysctl.o
The utsname stuff has been moved from kernel/sysctl.c to the new file utsname_sysctl.c. Let's use it... Signed-off-by: Laurent Riffard <[EMAIL PROTECTED]> --- Index: linux-2.6-mm/kernel/Makefile === --- linux-2.6-mm.orig/kernel/Makefile +++ linux-2.6-mm/kernel/Makefile @@ -8,7 +8,8 @@ obj-y = sched.o fork.o exec_domain.o signal.o sys.o kmod.o workqueue.o pid.o \ extable.o params.o posix-timers.o \ kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \ - hrtimer.o rwsem.o latency.o nsproxy.o rcupdate.o srcu.o utsname.o + hrtimer.o rwsem.o latency.o nsproxy.o rcupdate.o srcu.o utsname.o \ + utsname_sysctl.o obj-$(CONFIG_STACKTRACE) += stacktrace.o obj-y += time/ - 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.20-rc6-mm2
Le 29.01.2007 09:12, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc6-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm2/ - Dropped git-block due to CFQ breakage Nice, reiser4 does work now. It was broken since 2.6.20-rc3-mm1, see http://lkml.org/lkml/2007/1/6/57. - Dropped the fsaio patches due to their dependence on git-block. - Added the new hrtimers/dynticks patches. This is an update of the 2.6.20-rc4-mm1 patches, now apparently fixed. thanks ~~ laurent - 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.20-rc6-mm2
Le 29.01.2007 09:12, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc6-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm2/ - Dropped git-block due to CFQ breakage Nice, reiser4 does work now. It was broken since 2.6.20-rc3-mm1, see http://lkml.org/lkml/2007/1/6/57. - Dropped the fsaio patches due to their dependence on git-block. - Added the new hrtimers/dynticks patches. This is an update of the 2.6.20-rc4-mm1 patches, now apparently fixed. thanks ~~ laurent - 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/
[PATCH] compile and link utsname_sysctl.o
The utsname stuff has been moved from kernel/sysctl.c to the new file utsname_sysctl.c. Let's use it... Signed-off-by: Laurent Riffard [EMAIL PROTECTED] --- Index: linux-2.6-mm/kernel/Makefile === --- linux-2.6-mm.orig/kernel/Makefile +++ linux-2.6-mm/kernel/Makefile @@ -8,7 +8,8 @@ obj-y = sched.o fork.o exec_domain.o signal.o sys.o kmod.o workqueue.o pid.o \ extable.o params.o posix-timers.o \ kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \ - hrtimer.o rwsem.o latency.o nsproxy.o rcupdate.o srcu.o utsname.o + hrtimer.o rwsem.o latency.o nsproxy.o rcupdate.o srcu.o utsname.o \ + utsname_sysctl.o obj-$(CONFIG_STACKTRACE) += stacktrace.o obj-y += time/ - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 23.01.2007 16:46, Jens Axboe a écrit : On Tue, Jan 23 2007, Vladimir V. Saveliev wrote: Hello On Saturday 13 January 2007 01:56, Laurent Riffard wrote: Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007 dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda038 0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [] synchronize_qrcu+0x70/0x8c [] __make_request+0x4c/0x29b [] generic_make_request+0x1b0/0x1de [] submit_bio+0xda/0xe2 [] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [] update_journal_footer+0x29f/0x2b7 [reiser4] [] write_tx_back+0x149/0x185 [reiser4] [] reiser4_write_logs+0xea4/0xfd2 [reiser4] [] try_commit_txnh+0x7e6/0xa4f [reiser4] [] reiser4_txn_end+0x148/0x3cf [reiser4] [] reiser4_txn_restart+0xb/0x1a [reiser4] [] reiser4_txn_restart_current+0x73/0x75 [reiser4] [] force_commit_atom+0x258/0x261 [reiser4] [] txnmgr_force_commit_all+0x406/0x697 [reiser4] [] release_format40+0x10c/0x193 [reiser4] [] reiser4_put_super+0x134/0x16a [reiser4] [] generic_shutdown_super+0x55/0xd8 [] kill_block_super+0x20/0x32 [] deactivate_super+0x3f/0x51 [] mntput_no_expire+0x42/0x5f [] path_release_on_umount+0x15/0x18 [] sys_umount+0x1a3/0x1cb [] sys_oldumount+0x19/0x1b [] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? Which device with reiser4 did you try to umount? Jens wrote that it could be a barrier related. If there are no multidevices involved - please report to bugzilla. Make sure that your kernel contains this fix: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=4af09c42ee1af70356471f51c1f40c1ff7881b68;hp=036f6008f43b5b4dd8c825365f15434d75005c6d I think it missed 2.6.20-rc3-mm1. Again, that assumes you are using md or dm. I've got 2 reiser4 FS: - one with /dev/sdb6 - the other with /dev/vglinux1/ccache (vglinux1 is built on /dev/sda4 and /dev/sdb7). There is no md here, only dm. I applied the above patch on top of 2.6.20-rc4-mm1, but the problem still happens with the two devices. thanks -- laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 23.01.2007 16:46, Jens Axboe a écrit : On Tue, Jan 23 2007, Vladimir V. Saveliev wrote: Hello On Saturday 13 January 2007 01:56, Laurent Riffard wrote: Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007 dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda038 0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [c012d600] synchronize_qrcu+0x70/0x8c [c01bede4] __make_request+0x4c/0x29b [c01bd24b] generic_make_request+0x1b0/0x1de [c01bf354] submit_bio+0xda/0xe2 [e12674bd] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [e12678dd] update_journal_footer+0x29f/0x2b7 [reiser4] [e1268b65] write_tx_back+0x149/0x185 [reiser4] [e126a8e7] reiser4_write_logs+0xea4/0xfd2 [reiser4] [e125626a] try_commit_txnh+0x7e6/0xa4f [reiser4] [e125661b] reiser4_txn_end+0x148/0x3cf [reiser4] [e12568ad] reiser4_txn_restart+0xb/0x1a [reiser4] [e125692f] reiser4_txn_restart_current+0x73/0x75 [reiser4] [e1256b89] force_commit_atom+0x258/0x261 [reiser4] [e1257703] txnmgr_force_commit_all+0x406/0x697 [reiser4] [e12e5e08] release_format40+0x10c/0x193 [reiser4] [e1279922] reiser4_put_super+0x134/0x16a [reiser4] [c015c930] generic_shutdown_super+0x55/0xd8 [c015c9d3] kill_block_super+0x20/0x32 [c015ca75] deactivate_super+0x3f/0x51 [c016d903] mntput_no_expire+0x42/0x5f [c0160f37] path_release_on_umount+0x15/0x18 [c016df77] sys_umount+0x1a3/0x1cb [c016dfb8] sys_oldumount+0x19/0x1b [c0103ed2] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? Which device with reiser4 did you try to umount? Jens wrote that it could be a barrier related. If there are no multidevices involved - please report to bugzilla. Make sure that your kernel contains this fix: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=4af09c42ee1af70356471f51c1f40c1ff7881b68;hp=036f6008f43b5b4dd8c825365f15434d75005c6d I think it missed 2.6.20-rc3-mm1. Again, that assumes you are using md or dm. I've got 2 reiser4 FS: - one with /dev/sdb6 - the other with /dev/vglinux1/ccache (vglinux1 is built on /dev/sda4 and /dev/sdb7). There is no md here, only dm. I applied the above patch on top of 2.6.20-rc4-mm1, but the problem still happens with the two devices. thanks -- laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007 dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda038 0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [] synchronize_qrcu+0x70/0x8c [] __make_request+0x4c/0x29b [] generic_make_request+0x1b0/0x1de [] submit_bio+0xda/0xe2 [] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [] update_journal_footer+0x29f/0x2b7 [reiser4] [] write_tx_back+0x149/0x185 [reiser4] [] reiser4_write_logs+0xea4/0xfd2 [reiser4] [] try_commit_txnh+0x7e6/0xa4f [reiser4] [] reiser4_txn_end+0x148/0x3cf [reiser4] [] reiser4_txn_restart+0xb/0x1a [reiser4] [] reiser4_txn_restart_current+0x73/0x75 [reiser4] [] force_commit_atom+0x258/0x261 [reiser4] [] txnmgr_force_commit_all+0x406/0x697 [reiser4] [] release_format40+0x10c/0x193 [reiser4] [] reiser4_put_super+0x134/0x16a [reiser4] [] generic_shutdown_super+0x55/0xd8 [] kill_block_super+0x20/0x32 [] deactivate_super+0x3f/0x51 [] mntput_no_expire+0x42/0x5f [] path_release_on_umount+0x15/0x18 [] sys_umount+0x1a3/0x1cb [] sys_oldumount+0x19/0x1b [] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? -- laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 06.01.2007 19:58, Vladimir V. Saveliev a écrit : Hello On Saturday 06 January 2007 13:58, Laurent Riffard wrote: Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007 dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda038 0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [c012d600] synchronize_qrcu+0x70/0x8c [c01bede4] __make_request+0x4c/0x29b [c01bd24b] generic_make_request+0x1b0/0x1de [c01bf354] submit_bio+0xda/0xe2 [e12674bd] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [e12678dd] update_journal_footer+0x29f/0x2b7 [reiser4] [e1268b65] write_tx_back+0x149/0x185 [reiser4] [e126a8e7] reiser4_write_logs+0xea4/0xfd2 [reiser4] [e125626a] try_commit_txnh+0x7e6/0xa4f [reiser4] [e125661b] reiser4_txn_end+0x148/0x3cf [reiser4] [e12568ad] reiser4_txn_restart+0xb/0x1a [reiser4] [e125692f] reiser4_txn_restart_current+0x73/0x75 [reiser4] [e1256b89] force_commit_atom+0x258/0x261 [reiser4] [e1257703] txnmgr_force_commit_all+0x406/0x697 [reiser4] [e12e5e08] release_format40+0x10c/0x193 [reiser4] [e1279922] reiser4_put_super+0x134/0x16a [reiser4] [c015c930] generic_shutdown_super+0x55/0xd8 [c015c9d3] kill_block_super+0x20/0x32 [c015ca75] deactivate_super+0x3f/0x51 [c016d903] mntput_no_expire+0x42/0x5f [c0160f37] path_release_on_umount+0x15/0x18 [c016df77] sys_umount+0x1a3/0x1cb [c016dfb8] sys_oldumount+0x19/0x1b [c0103ed2] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system. Earlier kernels were OK. This still happens with 2.6.20-rc4-mm1... Should I open a bug report at http://bugzilla.kernel.org? -- laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 06.01.2007 11:58, Laurent Riffard a écrit : Le 05.01.2007 07:02, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1/ will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/ Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007 dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda038 0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [] synchronize_qrcu+0x70/0x8c [] __make_request+0x4c/0x29b [] generic_make_request+0x1b0/0x1de [] submit_bio+0xda/0xe2 [] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [] update_journal_footer+0x29f/0x2b7 [reiser4] [] write_tx_back+0x149/0x185 [reiser4] [] reiser4_write_logs+0xea4/0xfd2 [reiser4] [] try_commit_txnh+0x7e6/0xa4f [reiser4] [] reiser4_txn_end+0x148/0x3cf [reiser4] [] reiser4_txn_restart+0xb/0x1a [reiser4] [] reiser4_txn_restart_current+0x73/0x75 [reiser4] [] force_commit_atom+0x258/0x261 [reiser4] [] txnmgr_force_commit_all+0x406/0x697 [reiser4] [] release_format40+0x10c/0x193 [reiser4] [] reiser4_put_super+0x134/0x16a [reiser4] [] generic_shutdown_super+0x55/0xd8 [] kill_block_super+0x20/0x32 [] deactivate_super+0x3f/0x51 [] mntput_no_expire+0x42/0x5f [] path_release_on_umount+0x15/0x18 [] sys_umount+0x1a3/0x1cb [] sys_oldumount+0x19/0x1b [] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Earlier kernels were OK. I tested Frederik Deweerdt's patch for "lockdep: unbalance at generic_sync_sb_inodes", it did not help. I think I'll a give a try to http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1x.bz2 (basically 2.6.20-rc3-mm1, minus git-block.patch). Ok, 2.6.20-rc3-mm1 minus git-block.patch does work for me, ie I can safely use reiser4 FS, there is no more lockups. -- laurent - 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.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 05.01.2007 07:02, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1/ will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/ Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007 dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda038 0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [] synchronize_qrcu+0x70/0x8c [] __make_request+0x4c/0x29b [] generic_make_request+0x1b0/0x1de [] submit_bio+0xda/0xe2 [] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [] update_journal_footer+0x29f/0x2b7 [reiser4] [] write_tx_back+0x149/0x185 [reiser4] [] reiser4_write_logs+0xea4/0xfd2 [reiser4] [] try_commit_txnh+0x7e6/0xa4f [reiser4] [] reiser4_txn_end+0x148/0x3cf [reiser4] [] reiser4_txn_restart+0xb/0x1a [reiser4] [] reiser4_txn_restart_current+0x73/0x75 [reiser4] [] force_commit_atom+0x258/0x261 [reiser4] [] txnmgr_force_commit_all+0x406/0x697 [reiser4] [] release_format40+0x10c/0x193 [reiser4] [] reiser4_put_super+0x134/0x16a [reiser4] [] generic_shutdown_super+0x55/0xd8 [] kill_block_super+0x20/0x32 [] deactivate_super+0x3f/0x51 [] mntput_no_expire+0x42/0x5f [] path_release_on_umount+0x15/0x18 [] sys_umount+0x1a3/0x1cb [] sys_oldumount+0x19/0x1b [] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Earlier kernels were OK. I tested Frederik Deweerdt's patch for "lockdep: unbalance at generic_sync_sb_inodes", it did not help. I think I'll a give a try to http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1x.bz2 (basically 2.6.20-rc3-mm1, minus git-block.patch). .config attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc3-mm1 # Sat Jan 6 09:34:05 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_USER_NS=y # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not
Re: 2.6.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 05.01.2007 07:02, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1/ will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/ Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007 dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda038 0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [c012d600] synchronize_qrcu+0x70/0x8c [c01bede4] __make_request+0x4c/0x29b [c01bd24b] generic_make_request+0x1b0/0x1de [c01bf354] submit_bio+0xda/0xe2 [e12674bd] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [e12678dd] update_journal_footer+0x29f/0x2b7 [reiser4] [e1268b65] write_tx_back+0x149/0x185 [reiser4] [e126a8e7] reiser4_write_logs+0xea4/0xfd2 [reiser4] [e125626a] try_commit_txnh+0x7e6/0xa4f [reiser4] [e125661b] reiser4_txn_end+0x148/0x3cf [reiser4] [e12568ad] reiser4_txn_restart+0xb/0x1a [reiser4] [e125692f] reiser4_txn_restart_current+0x73/0x75 [reiser4] [e1256b89] force_commit_atom+0x258/0x261 [reiser4] [e1257703] txnmgr_force_commit_all+0x406/0x697 [reiser4] [e12e5e08] release_format40+0x10c/0x193 [reiser4] [e1279922] reiser4_put_super+0x134/0x16a [reiser4] [c015c930] generic_shutdown_super+0x55/0xd8 [c015c9d3] kill_block_super+0x20/0x32 [c015ca75] deactivate_super+0x3f/0x51 [c016d903] mntput_no_expire+0x42/0x5f [c0160f37] path_release_on_umount+0x15/0x18 [c016df77] sys_umount+0x1a3/0x1cb [c016dfb8] sys_oldumount+0x19/0x1b [c0103ed2] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Earlier kernels were OK. I tested Frederik Deweerdt's patch for lockdep: unbalance at generic_sync_sb_inodes, it did not help. I think I'll a give a try to http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1x.bz2 (basically 2.6.20-rc3-mm1, minus git-block.patch). .config attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc3-mm1 # Sat Jan 6 09:34:05 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_USER_NS=y # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is
Re: 2.6.20-rc3-mm1: umount reiser4 FS stuck in D state
Le 06.01.2007 11:58, Laurent Riffard a écrit : Le 05.01.2007 07:02, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1/ will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/ Hello, got this with 2.6.20-rc3-mm1: === SysRq : Show Blocked State freesibling task PCstack pid father child younger older umountD C013135E 6044 1168 1150 (NOTLB) de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 0007 dfd94ac0 128d3000 0026 dfd94bcc dff979c8 de591ae4 dffda038 0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 Call Trace: [c012d600] synchronize_qrcu+0x70/0x8c [c01bede4] __make_request+0x4c/0x29b [c01bd24b] generic_make_request+0x1b0/0x1de [c01bf354] submit_bio+0xda/0xe2 [e12674bd] write_jnodes_to_disk_extent+0x920/0x974 [reiser4] [e12678dd] update_journal_footer+0x29f/0x2b7 [reiser4] [e1268b65] write_tx_back+0x149/0x185 [reiser4] [e126a8e7] reiser4_write_logs+0xea4/0xfd2 [reiser4] [e125626a] try_commit_txnh+0x7e6/0xa4f [reiser4] [e125661b] reiser4_txn_end+0x148/0x3cf [reiser4] [e12568ad] reiser4_txn_restart+0xb/0x1a [reiser4] [e125692f] reiser4_txn_restart_current+0x73/0x75 [reiser4] [e1256b89] force_commit_atom+0x258/0x261 [reiser4] [e1257703] txnmgr_force_commit_all+0x406/0x697 [reiser4] [e12e5e08] release_format40+0x10c/0x193 [reiser4] [e1279922] reiser4_put_super+0x134/0x16a [reiser4] [c015c930] generic_shutdown_super+0x55/0xd8 [c015c9d3] kill_block_super+0x20/0x32 [c015ca75] deactivate_super+0x3f/0x51 [c016d903] mntput_no_expire+0x42/0x5f [c0160f37] path_release_on_umount+0x15/0x18 [c016df77] sys_umount+0x1a3/0x1cb [c016dfb8] sys_oldumount+0x19/0x1b [c0103ed2] sysenter_past_esp+0x5f/0x99 === Scenario: - umount a reiser4 FS (no need to write something before) Earlier kernels were OK. I tested Frederik Deweerdt's patch for lockdep: unbalance at generic_sync_sb_inodes, it did not help. I think I'll a give a try to http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1x.bz2 (basically 2.6.20-rc3-mm1, minus git-block.patch). Ok, 2.6.20-rc3-mm1 minus git-block.patch does work for me, ie I can safely use reiser4 FS, there is no more lockups. -- laurent - 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: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Le 30.12.2006 08:20, Rene Herman a écrit : Dmitry Torokhov wrote: Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps command and data into keyboard before i8042_interrupt gets a chance to run. Could you please apply the debug patch below and tell me the pattern of the data flow. Yes, I believe the below trace confirms what you said? Both the ED and the 00/05 are sent before the first ACK gets back, by a 1 jiffie margin: drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [N] drivers/input/serio/i8042.c: 05 -> i8042 (panic blink) [N + 2] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [N + 3] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [N + 6] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [M] drivers/input/serio/i8042.c: 00 -> i8042 (panic blink) [M + 2] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [M + 3] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [M + 6] The +2, +3 and +6 are constant. Forgot to pay attention to M - N, but I suppose it's not too important. For me, the patch as you posted it is actually good to go. No more spurious ACK complaints... Thanks, Rene. Hi Dmitry, Rene I can confirm Rene's report: this patch works fine since there is no more "Spurious ACK on isa0060/serio0" message. Here is a debug output as requested: <0>Kernel panic - not syncing: Fatal exception in interrupt <7>drivers/input/serio/i8042.c: 13 <- i8042 (interrupt, 0, 1) [49602] drivers/input/serio/i8042.c: 93 <- i8042 (interrupt, 0, 1) [49603] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [49728] drivers/input/serio/i8042.c: 05 -> i8042 (panic blink) [49729] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49730] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49732] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [49856] drivers/input/serio/i8042.c: 00 -> i8042 (panic blink) [49857] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49858] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49860] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [49983] drivers/input/serio/i8042.c: 05 -> i8042 (panic blink) [49985] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49986] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [49988] drivers/input/serio/i8042.c: ed -> i8042 (panic blink) [50112] drivers/input/serio/i8042.c: 00 -> i8042 (panic blink) [50114] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [50115] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [50117] thanks -- laurent - 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: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Le 30.12.2006 08:20, Rene Herman a écrit : Dmitry Torokhov wrote: Somehow you get 2 ACks in a row, I wonder if on your boxes i8042 pumps command and data into keyboard before i8042_interrupt gets a chance to run. Could you please apply the debug patch below and tell me the pattern of the data flow. Yes, I believe the below trace confirms what you said? Both the ED and the 00/05 are sent before the first ACK gets back, by a 1 jiffie margin: drivers/input/serio/i8042.c: ed - i8042 (panic blink) [N] drivers/input/serio/i8042.c: 05 - i8042 (panic blink) [N + 2] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [N + 3] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [N + 6] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [M] drivers/input/serio/i8042.c: 00 - i8042 (panic blink) [M + 2] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [M + 3] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [M + 6] The +2, +3 and +6 are constant. Forgot to pay attention to M - N, but I suppose it's not too important. For me, the patch as you posted it is actually good to go. No more spurious ACK complaints... Thanks, Rene. Hi Dmitry, Rene I can confirm Rene's report: this patch works fine since there is no more Spurious ACK on isa0060/serio0 message. Here is a debug output as requested: 0Kernel panic - not syncing: Fatal exception in interrupt 7drivers/input/serio/i8042.c: 13 - i8042 (interrupt, 0, 1) [49602] drivers/input/serio/i8042.c: 93 - i8042 (interrupt, 0, 1) [49603] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [49728] drivers/input/serio/i8042.c: 05 - i8042 (panic blink) [49729] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49730] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49732] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [49856] drivers/input/serio/i8042.c: 00 - i8042 (panic blink) [49857] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49858] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49860] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [49983] drivers/input/serio/i8042.c: 05 - i8042 (panic blink) [49985] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49986] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [49988] drivers/input/serio/i8042.c: ed - i8042 (panic blink) [50112] drivers/input/serio/i8042.c: 00 - i8042 (panic blink) [50114] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [50115] drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [50117] thanks -- laurent - 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.20-rc2-mm1: INFO: possible recursive locking detected in con_close
Le 29.12.2006 12:00, Frederik Deweerdt a ecrit :
On Thu, Dec 28, 2006 at 10:25:12PM +0100, Laurent Riffard wrote:
Le 28.12.2006 11:42, Andrew Morton a ecrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/
Hello,
got this with 2.6.20-rc2-mm1, reverting
gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch made it disappear.
Hi,
This is due to sysfs_hash_and_remove() holding dir->d_inode->i_mutex
before calling sysfs_drop_dentry() which calls orphan_all_buffers()
which in turn takes node->i_mutex.
The following patch solves the problem by defering the buffers orphaning
after the dir->d_inode->imutex is released. Not sure it's the best
solution though, Greg?
Regards,
Frederik
Tested, it does work: the INFO about "possible recursive locking" went away.
Thanks
~~
laurent
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
diff --git a/fs/sysfs/inode.c b/fs/sysfs/inode.c
index 8c533cb..7cac0b6 100644
--- a/fs/sysfs/inode.c
+++ b/fs/sysfs/inode.c
@@ -230,10 +230,10 @@ static inline void orphan_all_buffers(struct inode *node)
* Unhashes the dentry corresponding to given sysfs_dirent
* Called with parent inode's i_mutex held.
*/
-void sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry * parent)
+struct inode *sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry *
parent)
{
struct dentry * dentry = sd->s_dentry;
- struct inode *inode;
+ struct inode *inode = NULL;
if (dentry) {
spin_lock(_lock);
@@ -248,19 +248,19 @@ void sysfs_drop_dentry(struct sysfs_dirent * sd, struct
dentry * parent)
spin_unlock(>d_lock);
spin_unlock(_lock);
simple_unlink(parent->d_inode, dentry);
- orphan_all_buffers(inode);
- iput(inode);
} else {
spin_unlock(>d_lock);
spin_unlock(_lock);
}
}
+ return inode;
}
int sysfs_hash_and_remove(struct dentry * dir, const char * name)
{
struct sysfs_dirent * sd;
struct sysfs_dirent * parent_sd;
+ struct inode *inode;
int found = 0;
if (!dir)
@@ -277,7 +277,7 @@ int sysfs_hash_and_remove(struct dentry * dir, const char *
name)
continue;
if (!strcmp(sysfs_get_name(sd), name)) {
list_del_init(>s_sibling);
- sysfs_drop_dentry(sd, dir);
+ inode = sysfs_drop_dentry(sd, dir);
sysfs_put(sd);
found = 1;
break;
@@ -285,5 +285,10 @@ int sysfs_hash_and_remove(struct dentry * dir, const char
* name)
}
mutex_unlock(>d_inode->i_mutex);
+ if (found == 1 && inode) {
+ orphan_all_buffers(inode);
+ iput(inode);
+ }
+
return found ? 0 : -ENOENT;
}
diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index 5100a12..ef9d217 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -17,7 +17,7 @@ extern int sysfs_create_subdir(struct kobject *, const char
*, struct dentry **)
extern void sysfs_remove_subdir(struct dentry *);
extern const unsigned char * sysfs_get_name(struct sysfs_dirent *sd);
-extern void sysfs_drop_dentry(struct sysfs_dirent *sd, struct dentry *parent);
+extern struct inode * sysfs_drop_dentry(struct sysfs_dirent *sd, struct dentry
*parent);
extern int sysfs_setattr(struct dentry *dentry, struct iattr *iattr);
extern struct rw_semaphore sysfs_rename_sem;
-
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: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Le 29.12.2006 06:54, Rene Herman a écrit :
Dmitry Torokhov wrote:
On Friday 29 December 2006 00:17, Rene Herman wrote:
Yes, I do have that in my tree. From the looks of it it's probably
not surprising, but the following gets me blinking leds without the
spurious ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO &&
(data == 0xfa || data == 0xfe)) {
-i8042_suppress_kbd_ack = 0;
+/* i8042_suppress_kbd_ack = 0; */
goto out;
That would indicate that your keyboard generates multiple acks... I
wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
Not even an analog camera, but with or without the above, I get a single:
" <7>drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [ 902]"
when it panics. During a full boot, I get:
===
[snip]
===
Rene.
Dmitry,
How about this output? (got this after a kernel panic)
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35172]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35172]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35296]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35297]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35420]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35421]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35544]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [35545]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
===
~~
laurent
-
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: [BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Le 29.12.2006 06:54, Rene Herman a écrit :
Dmitry Torokhov wrote:
On Friday 29 December 2006 00:17, Rene Herman wrote:
Yes, I do have that in my tree. From the looks of it it's probably
not surprising, but the following gets me blinking leds without the
spurious ACK messages. Maybe still useful to know?
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index debe944..9c70d34 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -371,7 +371,7 @@ static irqreturn_t i8042_interrupt(int i
if (unlikely(i8042_suppress_kbd_ack))
if (port_no == I8042_KBD_PORT_NO
(data == 0xfa || data == 0xfe)) {
-i8042_suppress_kbd_ack = 0;
+/* i8042_suppress_kbd_ack = 0; */
goto out;
That would indicate that your keyboard generates multiple acks... I
wonder
if you could boot with i8042.debug=1 and somehow capture the data flow
during panic (do you have a digital camera?).
Not even an analog camera, but with or without the above, I get a single:
7drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [ 902]
when it panics. During a full boot, I get:
===
[snip]
===
Rene.
Dmitry,
How about this output? (got this after a kernel panic)
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35172]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35172]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35296]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35297]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35420]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35421]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35544]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, 0, 1) [35545]
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access
hardware directly.
===
~~
laurent
-
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.20-rc2-mm1: INFO: possible recursive locking detected in con_close
Le 29.12.2006 12:00, Frederik Deweerdt a ecrit :
On Thu, Dec 28, 2006 at 10:25:12PM +0100, Laurent Riffard wrote:
Le 28.12.2006 11:42, Andrew Morton a ecrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/
Hello,
got this with 2.6.20-rc2-mm1, reverting
gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch made it disappear.
Hi,
This is due to sysfs_hash_and_remove() holding dir-d_inode-i_mutex
before calling sysfs_drop_dentry() which calls orphan_all_buffers()
which in turn takes node-i_mutex.
The following patch solves the problem by defering the buffers orphaning
after the dir-d_inode-imutex is released. Not sure it's the best
solution though, Greg?
Regards,
Frederik
Tested, it does work: the INFO about possible recursive locking went away.
Thanks
~~
laurent
Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
diff --git a/fs/sysfs/inode.c b/fs/sysfs/inode.c
index 8c533cb..7cac0b6 100644
--- a/fs/sysfs/inode.c
+++ b/fs/sysfs/inode.c
@@ -230,10 +230,10 @@ static inline void orphan_all_buffers(struct inode *node)
* Unhashes the dentry corresponding to given sysfs_dirent
* Called with parent inode's i_mutex held.
*/
-void sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry * parent)
+struct inode *sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry *
parent)
{
struct dentry * dentry = sd-s_dentry;
- struct inode *inode;
+ struct inode *inode = NULL;
if (dentry) {
spin_lock(dcache_lock);
@@ -248,19 +248,19 @@ void sysfs_drop_dentry(struct sysfs_dirent * sd, struct
dentry * parent)
spin_unlock(dentry-d_lock);
spin_unlock(dcache_lock);
simple_unlink(parent-d_inode, dentry);
- orphan_all_buffers(inode);
- iput(inode);
} else {
spin_unlock(dentry-d_lock);
spin_unlock(dcache_lock);
}
}
+ return inode;
}
int sysfs_hash_and_remove(struct dentry * dir, const char * name)
{
struct sysfs_dirent * sd;
struct sysfs_dirent * parent_sd;
+ struct inode *inode;
int found = 0;
if (!dir)
@@ -277,7 +277,7 @@ int sysfs_hash_and_remove(struct dentry * dir, const char *
name)
continue;
if (!strcmp(sysfs_get_name(sd), name)) {
list_del_init(sd-s_sibling);
- sysfs_drop_dentry(sd, dir);
+ inode = sysfs_drop_dentry(sd, dir);
sysfs_put(sd);
found = 1;
break;
@@ -285,5 +285,10 @@ int sysfs_hash_and_remove(struct dentry * dir, const char
* name)
}
mutex_unlock(dir-d_inode-i_mutex);
+ if (found == 1 inode) {
+ orphan_all_buffers(inode);
+ iput(inode);
+ }
+
return found ? 0 : -ENOENT;
}
diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index 5100a12..ef9d217 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -17,7 +17,7 @@ extern int sysfs_create_subdir(struct kobject *, const char
*, struct dentry **)
extern void sysfs_remove_subdir(struct dentry *);
extern const unsigned char * sysfs_get_name(struct sysfs_dirent *sd);
-extern void sysfs_drop_dentry(struct sysfs_dirent *sd, struct dentry *parent);
+extern struct inode * sysfs_drop_dentry(struct sysfs_dirent *sd, struct dentry
*parent);
extern int sysfs_setattr(struct dentry *dentry, struct iattr *iattr);
extern struct rw_semaphore sysfs_rename_sem;
-
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.20-rc2-mm1: INFO: possible recursive locking detected in con_close
Le 28.12.2006 11:42, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/
Hello,
got this with 2.6.20-rc2-mm1, reverting
gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch
made it disappear.
=
[ INFO: possible recursive locking detected ]
2.6.20-rc2-mm1 #51
-
init/324 is trying to acquire lock:
(_inode_imutex_key){--..}, at: [] mutex_lock+0x1c/0x1f
but task is already holding lock:
(_inode_imutex_key){--..}, at: [] mutex_lock+0x1c/0x1f
other info that might help us debug this:
2 locks held by init/324:
#0: (tty_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
#1: (_inode_imutex_key){--..}, at: [] mutex_lock+0x1c/0x1f
stack backtrace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __lock_acquire+0x116/0xb33
[] lock_acquire+0x56/0x6f
[] __mutex_lock_slowpath+0xdc/0x266
[] mutex_lock+0x1c/0x1f
[] sysfs_drop_dentry+0xb7/0x12b
[] sysfs_hash_and_remove+0x90/0x14a
[] sysfs_remove_file+0xd/0xf
[] device_remove_file+0x1f/0x2a
[] device_del+0x31/0x1c4
[] device_unregister+0xb/0x15
[] device_destroy+0x8b/0x91
[] vcs_remove_sysfs+0x1a/0x36
[] con_close+0x4c/0x60
[] release_dev+0x221/0x62a
[] tty_release+0x12/0x1c
[] __fput+0xb9/0x177
[] fput+0x31/0x35
[] filp_close+0x54/0x5c
[] put_files_struct+0x7c/0xb9
[] do_exit+0x219/0x72f
[] sys_exit_group+0x0/0x11
[] sys_exit_group+0xf/0x11
[] sysenter_past_esp+0x5f/0x99
===
--
laurent
-
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.20-rc2-mm1: INFO: possible recursive locking detected in con_close
Le 28.12.2006 11:42, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/
Hello,
got this with 2.6.20-rc2-mm1, reverting
gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch
made it disappear.
=
[ INFO: possible recursive locking detected ]
2.6.20-rc2-mm1 #51
-
init/324 is trying to acquire lock:
(sysfs_inode_imutex_key){--..}, at: [c02b2c79] mutex_lock+0x1c/0x1f
but task is already holding lock:
(sysfs_inode_imutex_key){--..}, at: [c02b2c79] mutex_lock+0x1c/0x1f
other info that might help us debug this:
2 locks held by init/324:
#0: (tty_mutex){--..}, at: [c02b2c79] mutex_lock+0x1c/0x1f
#1: (sysfs_inode_imutex_key){--..}, at: [c02b2c79] mutex_lock+0x1c/0x1f
stack backtrace:
[c0104ea7] show_trace_log_lvl+0x1a/0x2f
[c010557a] show_trace+0x12/0x14
[c010562c] dump_stack+0x16/0x18
[c01314ad] __lock_acquire+0x116/0xb33
[c0132283] lock_acquire+0x56/0x6f
[c02b2ad3] __mutex_lock_slowpath+0xdc/0x266
[c02b2c79] mutex_lock+0x1c/0x1f
[c018b293] sysfs_drop_dentry+0xb7/0x12b
[c018b3d6] sysfs_hash_and_remove+0x90/0x14a
[c018b985] sysfs_remove_file+0xd/0xf
[c0235944] device_remove_file+0x1f/0x2a
[c02359bb] device_del+0x31/0x1c4
[c0235b59] device_unregister+0xb/0x15
[c0235bee] device_destroy+0x8b/0x91
[c022d7fc] vcs_remove_sysfs+0x1a/0x36
[c023254f] con_close+0x4c/0x60
[c0226b79] release_dev+0x221/0x62a
[c0226f94] tty_release+0x12/0x1c
[c015baf1] __fput+0xb9/0x177
[c015bc83] fput+0x31/0x35
[c015951c] filp_close+0x54/0x5c
[c011ac05] put_files_struct+0x7c/0xb9
[c011bcef] do_exit+0x219/0x72f
[c011c275] sys_exit_group+0x0/0x11
[c011c284] sys_exit_group+0xf/0x11
[c0103ed2] sysenter_past_esp+0x5f/0x99
===
--
laurent
-
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.20-rc1-mm1
Le 17.12.2006 12:07, Damien Wyart a écrit : Also, I got panics when unmounting reiser4 filesystems with 2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4 being broken in 2.6.19-mm1 (even if it is not listed in notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report the xfs messages which seems a bit suspect. The reiser4 failure is unexpected. Could you please see if you can capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit. Reverting it fix those reiser4 panics for me. Damien, could you confirm please ? ~~ laurent - 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.20-rc1-mm1
Le 17.12.2006 12:07, Damien Wyart a écrit : Also, I got panics when unmounting reiser4 filesystems with 2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4 being broken in 2.6.19-mm1 (even if it is not listed in notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report the xfs messages which seems a bit suspect. The reiser4 failure is unexpected. Could you please see if you can capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit. Reverting it fix those reiser4 panics for me. Damien, could you confirm please ? ~~ laurent - 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: DVD-RAM cannot be mounted RW with 2.6.18/2.6.19
Le 16.12.2006 20:55, A. Kalten a écrit : Hello, DVD-RAM disks previously made with a Linux system can no longer be mounted in RW mode. For some reason, as indicated by the error message from the mount command, the disks are detected as being write-protected (which is not the case). To be able to write to these disks, the mount command must be issued again with the "-o remount" option. The commands given are as follows. Although the file type in this example is ext2, the same behavior is seen also with the udf file type. # modprobe ide-cd # hdparm -d1 -X udma4 -k1 /dev/hde # mount -t ext2 -o rw,noatime /dev/hde /cdrom mount: block device /dev/hde is write-protected, mounting read-only # mount -t ext2 -o remount,rw,noatime /dev/hde /cdrom Now the DVD-RAM disk can be written normally, but there should be no need for the second mount command. The kernel log for this command sequence seems to show nothing abnormal: kernel: hde: ATAPI 39X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) kernel: Uniform CD-ROM driver Revision: 3.20 kernel: hde: CHECK for good STATUS kernel: cdrom: hde: mrw address space DMA selected kernel: cdrom open: mrw_status 'not mrw' Furthermore, if I attempt to check the unmounted DVD-RAM disk with e2fsck, the drive is still reported as read-only: # e2fsck -p /dev/hde e2fsck: Read-only file system while trying to open /dev/hde Disk write-protected; use the -n option to do a read-only check of the device. However, as I indicated above, the disk is not write-protected. I am reporting this problem on the lkml because of a hint that I discovered at this link: http://lists.opensuse.org/packet-writing/2006-10/msg0.html Although this problem does not involve packet-writing, it may be related to the cdrom code. The problem I reported in the above link was related to UDF filesystem. AFAIR, my DVD-RW have been formatted with "mkduffs --media-type=dvd", which toggled a read-only flag at the FS level. I reformatted this DVD-RW with "mkudffs --media-type=dvdram" and the problem was gone. I'm afraid this won't help you... ~~ laurent - 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: DVD-RAM cannot be mounted RW with 2.6.18/2.6.19
Le 16.12.2006 20:55, A. Kalten a écrit : Hello, DVD-RAM disks previously made with a Linux system can no longer be mounted in RW mode. For some reason, as indicated by the error message from the mount command, the disks are detected as being write-protected (which is not the case). To be able to write to these disks, the mount command must be issued again with the -o remount option. The commands given are as follows. Although the file type in this example is ext2, the same behavior is seen also with the udf file type. # modprobe ide-cd # hdparm -d1 -X udma4 -k1 /dev/hde # mount -t ext2 -o rw,noatime /dev/hde /cdrom mount: block device /dev/hde is write-protected, mounting read-only # mount -t ext2 -o remount,rw,noatime /dev/hde /cdrom Now the DVD-RAM disk can be written normally, but there should be no need for the second mount command. The kernel log for this command sequence seems to show nothing abnormal: kernel: hde: ATAPI 39X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) kernel: Uniform CD-ROM driver Revision: 3.20 kernel: hde: CHECK for good STATUS kernel: cdrom: hde: mrw address space DMA selected kernel: cdrom open: mrw_status 'not mrw' Furthermore, if I attempt to check the unmounted DVD-RAM disk with e2fsck, the drive is still reported as read-only: # e2fsck -p /dev/hde e2fsck: Read-only file system while trying to open /dev/hde Disk write-protected; use the -n option to do a read-only check of the device. However, as I indicated above, the disk is not write-protected. I am reporting this problem on the lkml because of a hint that I discovered at this link: http://lists.opensuse.org/packet-writing/2006-10/msg0.html Although this problem does not involve packet-writing, it may be related to the cdrom code. The problem I reported in the above link was related to UDF filesystem. AFAIR, my DVD-RW have been formatted with mkduffs --media-type=dvd, which toggled a read-only flag at the FS level. I reformatted this DVD-RW with mkudffs --media-type=dvdram and the problem was gone. I'm afraid this won't help you... ~~ laurent - 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.13-rc3-mm1 : oops in dnotify_parent
Le 15.07.2005 10:36, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
Hello,
I just got this oops :
Unable to handle kernel NULL pointer dereference at virtual address 0104
printing eip:
c016c7c4
*pde =
Oops: [#1]
last sysfs file:
Modules linked in: isofs pktcdvd autofs4 lp parport_pc parport snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_ens1371 gameport
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd
soundcore af_packet floppy ne2k_pci 8390 ide_cd cdrom ohci1394 ieee1394 loop
aes_i586 dm_crypt nls_iso8859_1 nls_cp850 vfat fat reiser4 zlib_deflate
zlib_inflate reiserfs pcspkr via_agp agpgart dm_mod joydev usbhid uhci_hcd
usbcore video hotkey configfs
CPU:0
EIP:0060:[dnotify_parent+19/67]Not tainted VLI
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.13-rc3-mm1)
EIP is at dnotify_parent+0x13/0x43
eax: c5d13f70 ebx: cffddfd8 ecx: edx: 0002
esi: c6f22504 edi: c5d13f70 ebp: c712ff0c esp: c712ff08
ds: 007b es: 007b ss: 0068
Process gnome-settings- (pid: 5078, threadinfo=c712e000 task=c708d050)
Jul 16 23:36:30 antares gconfd (laurent-4942): Sortie
Stack: 0002 c712ff7c c0147dcf 0001 080afdf0 000c c712ff30
c6e62b60 0001 080afdfc c712ff5c c015a7d5 c712ff40 c712ff40
cff8 c02217e7 0008 c63afc60 c712ff64 c015a810 c712ff84
Call Trace:
[show_stack+118/126] show_stack+0x76/0x7e
[] show_stack+0x76/0x7e
[show_registers+234/338] show_registers+0xea/0x152
[] show_registers+0xea/0x152
[die+194/316] die+0xc2/0x13c
[] die+0xc2/0x13c
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[] error_code+0x4f/0x54
[do_readv_writev+514/572] do_readv_writev+0x202/0x23c
[] do_readv_writev+0x202/0x23c
[vfs_writev+64/71] vfs_writev+0x40/0x47
[] vfs_writev+0x40/0x47
[sys_writev+59/147] sys_writev+0x3b/0x93
[] sys_writev+0x3b/0x93
[sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75
[] sysenter_past_esp+0x54/0x75
Code: 85 db 75 be 83 7d ec 00 74 07 89 f8 e8 ba fd ff ff 58 5a 5b 5e 5f c9 c3
83 3d 94 a1 2b c0 00 55 89 e5 53 74 30 8b 58 0c 8b 4b 08 <85> 91 04 01 00 00 74
22 85 db 74 10 8b 03 85 c0 75 08 0f 0b 27
<1>Unable to handle kernel NULL pointer dereference at virtual address 0099
printing eip:
c015a51b
*pde =
Oops: [#2]
last sysfs file:
Modules linked in: isofs pktcdvd autofs4 lp parport_pc parport snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_ens1371 gameport
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd
soundcore af_packet floppy ne2k_pci 8390 ide_cd cdrom ohci1394 ieee1394 loop
aes_i586 dm_crypt nls_iso8859_1 nls_cp850 vfat fat reiser4 zlib_deflate
zlib_inflate reiserfs pcspkr via_agp agpgart dm_mod joydev usbhid uhci_hcd
usbcore video hotkey configfs
CPU:0
EIP:0060:[dcache_shrinker_add+16/52]Not tainted VLI
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.13-rc3-mm1)
EIP is at dcache_shrinker_add+0x10/0x34
eax: 0001 ebx: c712fdb0 ecx: c5d13f70 edx: cffddfd8
esi: cffddfd8 edi: c6e62b60 ebp: c712fda8 esp: c712fda4
ds: 007b es: 007b ss: 0068
Process gnome-settings- (pid: 5078, threadinfo=c712e000 task=c708d050)
Stack: c5d13f70 c712fdcc c015a776 c712fdb8 c026b5cc cffddfd8 c02217e7 0008
c6e62b60 c712fdd4 c015a810 c712fdf4 c0148546 c6f22504 cffe04e0
c5d13f70 c6e62b60 c131f040 c712fe00 c0148422 c6e62b60 c712fe14
Call Trace:
[show_stack+118/126] show_stack+0x76/0x7e
[] show_stack+0x76/0x7e
[show_registers+234/338] show_registers+0xea/0x152
[] show_registers+0xea/0x152
[die+194/316] die+0xc2/0x13c
[] die+0xc2/0x13c
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[] error_code+0x4f/0x54
[dput_recursive+326/466] dput_recursive+0x146/0x1d2
[] dput_recursive+0x146/0x1d2
[dput+14/16] dput+0xe/0x10
[] dput+0xe/0x10
[__fput+287/354] __fput+0x11f/0x162
[] __fput+0x11f/0x162
[fput+46/51] fput+0x2e/0x33
[] fput+0x2e/0x33
[filp_close+78/88] filp_close+0x4e/0x58
[] filp_close+0x4e/0x58
[put_files_struct+132/183] put_files_struct+0x84/0xb7
[] put_files_struct+0x84/0xb7
[do_exit+376/844] do_exit+0x178/0x34c
[] do_exit+0x178/0x34c
[do_divide_error+0/153] do_divide_error+0x0/0x99
[] do_divide_error+0x0/0x99
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[] error_code+0x4f/0x54
[do_readv_writev+514/572] do_readv_writev+0x202/0x23c
[] do_readv_writev+0x202/0x23c
[vfs_writev+64/71] vfs_writev+0x40/0x47
[] vfs_writev+0x40/0x47
[sys_writev+59/147] sys_writev+0x3b/0x93
[] sys_writev+0x3b/0x93
[sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75
[] sysenter_past_esp+0x54/0x75
Re: 2.6.13-rc3-mm1 : oops in dnotify_parent
Le 15.07.2005 10:36, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
Hello,
I just got this oops :
Unable to handle kernel NULL pointer dereference at virtual address 0104
printing eip:
c016c7c4
*pde =
Oops: [#1]
last sysfs file:
Modules linked in: isofs pktcdvd autofs4 lp parport_pc parport snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_ens1371 gameport
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd
soundcore af_packet floppy ne2k_pci 8390 ide_cd cdrom ohci1394 ieee1394 loop
aes_i586 dm_crypt nls_iso8859_1 nls_cp850 vfat fat reiser4 zlib_deflate
zlib_inflate reiserfs pcspkr via_agp agpgart dm_mod joydev usbhid uhci_hcd
usbcore video hotkey configfs
CPU:0
EIP:0060:[dnotify_parent+19/67]Not tainted VLI
EIP:0060:[c016c7c4]Not tainted VLI
EFLAGS: 00010202 (2.6.13-rc3-mm1)
EIP is at dnotify_parent+0x13/0x43
eax: c5d13f70 ebx: cffddfd8 ecx: edx: 0002
esi: c6f22504 edi: c5d13f70 ebp: c712ff0c esp: c712ff08
ds: 007b es: 007b ss: 0068
Process gnome-settings- (pid: 5078, threadinfo=c712e000 task=c708d050)
Jul 16 23:36:30 antares gconfd (laurent-4942): Sortie
Stack: 0002 c712ff7c c0147dcf 0001 080afdf0 000c c712ff30
c6e62b60 0001 080afdfc c712ff5c c015a7d5 c712ff40 c712ff40
cff8 c02217e7 0008 c63afc60 c712ff64 c015a810 c712ff84
Call Trace:
[show_stack+118/126] show_stack+0x76/0x7e
[c0103861] show_stack+0x76/0x7e
[show_registers+234/338] show_registers+0xea/0x152
[c010396a] show_registers+0xea/0x152
[die+194/316] die+0xc2/0x13c
[c0103b0e] die+0xc2/0x13c
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[c026f801] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[c0103583] error_code+0x4f/0x54
[do_readv_writev+514/572] do_readv_writev+0x202/0x23c
[c0147dcf] do_readv_writev+0x202/0x23c
[vfs_writev+64/71] vfs_writev+0x40/0x47
[c0147e8d] vfs_writev+0x40/0x47
[sys_writev+59/147] sys_writev+0x3b/0x93
[c0147f62] sys_writev+0x3b/0x93
[sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75
[c0102a7f] sysenter_past_esp+0x54/0x75
Code: 85 db 75 be 83 7d ec 00 74 07 89 f8 e8 ba fd ff ff 58 5a 5b 5e 5f c9 c3
83 3d 94 a1 2b c0 00 55 89 e5 53 74 30 8b 58 0c 8b 4b 08 85 91 04 01 00 00 74
22 85 db 74 10 8b 03 85 c0 75 08 0f 0b 27
1Unable to handle kernel NULL pointer dereference at virtual address 0099
printing eip:
c015a51b
*pde =
Oops: [#2]
last sysfs file:
Modules linked in: isofs pktcdvd autofs4 lp parport_pc parport snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_ens1371 gameport
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd
soundcore af_packet floppy ne2k_pci 8390 ide_cd cdrom ohci1394 ieee1394 loop
aes_i586 dm_crypt nls_iso8859_1 nls_cp850 vfat fat reiser4 zlib_deflate
zlib_inflate reiserfs pcspkr via_agp agpgart dm_mod joydev usbhid uhci_hcd
usbcore video hotkey configfs
CPU:0
EIP:0060:[dcache_shrinker_add+16/52]Not tainted VLI
EIP:0060:[c015a51b]Not tainted VLI
EFLAGS: 00010202 (2.6.13-rc3-mm1)
EIP is at dcache_shrinker_add+0x10/0x34
eax: 0001 ebx: c712fdb0 ecx: c5d13f70 edx: cffddfd8
esi: cffddfd8 edi: c6e62b60 ebp: c712fda8 esp: c712fda4
ds: 007b es: 007b ss: 0068
Process gnome-settings- (pid: 5078, threadinfo=c712e000 task=c708d050)
Stack: c5d13f70 c712fdcc c015a776 c712fdb8 c026b5cc cffddfd8 c02217e7 0008
c6e62b60 c712fdd4 c015a810 c712fdf4 c0148546 c6f22504 cffe04e0
c5d13f70 c6e62b60 c131f040 c712fe00 c0148422 c6e62b60 c712fe14
Call Trace:
[show_stack+118/126] show_stack+0x76/0x7e
[c0103861] show_stack+0x76/0x7e
[show_registers+234/338] show_registers+0xea/0x152
[c010396a] show_registers+0xea/0x152
[die+194/316] die+0xc2/0x13c
[c0103b0e] die+0xc2/0x13c
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[c026f801] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[c0103583] error_code+0x4f/0x54
[dput_recursive+326/466] dput_recursive+0x146/0x1d2
[c015a776] dput_recursive+0x146/0x1d2
[dput+14/16] dput+0xe/0x10
[c015a810] dput+0xe/0x10
[__fput+287/354] __fput+0x11f/0x162
[c0148546] __fput+0x11f/0x162
[fput+46/51] fput+0x2e/0x33
[c0148422] fput+0x2e/0x33
[filp_close+78/88] filp_close+0x4e/0x58
[c01470fd] filp_close+0x4e/0x58
[put_files_struct+132/183] put_files_struct+0x84/0xb7
[c0117d52] put_files_struct+0x84/0xb7
[do_exit+376/844] do_exit+0x178/0x34c
[c011885d] do_exit+0x178/0x34c
[do_divide_error+0/153] do_divide_error+0x0/0x99
[c0103b88] do_divide_error+0x0/0x99
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[c026f801] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[c0103583] error_code+0x4f/0x54
[do_readv_writev+514/572] do_readv_writev+0x202/0x23c
[c0147dcf] do_readv_writev+0x202/0x23c
Re: [PATCH] device-mapper: Fix target suspension oops.
Le 12.07.2005 23:24, Alasdair G Kergon wrote:
> This section got lost while refactoring the 'Fix deadlocks in core' set
> of patches I sent yesterday. Without it, you'll have problems
> activating any device-mapper devices.
>
> The NULL detection is moved inside the functions instead of every
> caller having to do it.
>
> --- drivers/md/dm-table.c 2005-07-12 22:10:20.0 +0100
> +++ /data/kernels/pm-2612udm1/source/drivers/md/dm-table.c2005-07-06
> 18:52:18.0 +0100
> @@ -869,11 +869,17 @@
>
> void dm_table_presuspend_targets(struct dm_table *t)
> {
> + if (!t)
> + return;
> +
> return suspend_targets(t, 0);
> }
>
> void dm_table_postsuspend_targets(struct dm_table *t)
> {
> + if (!t)
> + return;
> +
> return suspend_targets(t, 1);
> }
>
Ok, it seems that it works well now.
[EMAIL PROTECTED] ~]# cat /proc/version
Linux version 2.6.13-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 3.4.3
(Mandrakelinux 10.2 3.4.3-7mdk)) #104 Tue Jul 12 19:16:28 CEST 2005
[EMAIL PROTECTED] ~]# dmsetup table
vglinux1-lvhome: 0 7340032 linear 3:4 4604288
vglinux1-lvhome: 7340032 1048576 linear 3:4 14655872
vglinux1-lvtmp: 0 106496 linear 3:4 13238656
vglinux1-lvusr: 0 4194304 linear 3:4 409984
vglinux1-lvusr: 4194304 212992 linear 3:4 11944320
vglinux1-lvusr: 4407296 835584 linear 3:4 12403072
vglinux1-lvvar: 0 409600 linear 3:4 384
vglinux1-lvvar: 409600 245760 linear 3:4 12157312
crypt-swap2: 0 1590434 crypt aes-cbc-plain
ad79bd09a98d3bf601bf15bb7cedd656ecd42fc1eb5c48822148de23ab724aad 0 3:71 0
crypt-swap1: 0 128457 crypt aes-cbc-plain
800d0c169e6e1b9dece5bfc645dfe08d61fd2d8a18f578c14501988cbf31590d 0 3:5 0
vglinux1-test: 0 1310720 linear 3:4 13345152
crypt-tmp: 0 106496 crypt aes-cbc-plain
d3de9d10862e89107374542c0cedb569c16d637262f5537f2c96bfc20eb2c1c1 0 254:3 0
Thank you for your quickness, Alasdair.
--
laurent
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] device-mapper: Fix target suspension oops.
Le 12.07.2005 23:24, Alasdair G Kergon wrote:
This section got lost while refactoring the 'Fix deadlocks in core' set
of patches I sent yesterday. Without it, you'll have problems
activating any device-mapper devices.
The NULL detection is moved inside the functions instead of every
caller having to do it.
--- drivers/md/dm-table.c 2005-07-12 22:10:20.0 +0100
+++ /data/kernels/pm-2612udm1/source/drivers/md/dm-table.c2005-07-06
18:52:18.0 +0100
@@ -869,11 +869,17 @@
void dm_table_presuspend_targets(struct dm_table *t)
{
+ if (!t)
+ return;
+
return suspend_targets(t, 0);
}
void dm_table_postsuspend_targets(struct dm_table *t)
{
+ if (!t)
+ return;
+
return suspend_targets(t, 1);
}
Ok, it seems that it works well now.
[EMAIL PROTECTED] ~]# cat /proc/version
Linux version 2.6.13-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 3.4.3
(Mandrakelinux 10.2 3.4.3-7mdk)) #104 Tue Jul 12 19:16:28 CEST 2005
[EMAIL PROTECTED] ~]# dmsetup table
vglinux1-lvhome: 0 7340032 linear 3:4 4604288
vglinux1-lvhome: 7340032 1048576 linear 3:4 14655872
vglinux1-lvtmp: 0 106496 linear 3:4 13238656
vglinux1-lvusr: 0 4194304 linear 3:4 409984
vglinux1-lvusr: 4194304 212992 linear 3:4 11944320
vglinux1-lvusr: 4407296 835584 linear 3:4 12403072
vglinux1-lvvar: 0 409600 linear 3:4 384
vglinux1-lvvar: 409600 245760 linear 3:4 12157312
crypt-swap2: 0 1590434 crypt aes-cbc-plain
ad79bd09a98d3bf601bf15bb7cedd656ecd42fc1eb5c48822148de23ab724aad 0 3:71 0
crypt-swap1: 0 128457 crypt aes-cbc-plain
800d0c169e6e1b9dece5bfc645dfe08d61fd2d8a18f578c14501988cbf31590d 0 3:5 0
vglinux1-test: 0 1310720 linear 3:4 13345152
crypt-tmp: 0 106496 crypt aes-cbc-plain
d3de9d10862e89107374542c0cedb569c16d637262f5537f2c96bfc20eb2c1c1 0 254:3 0
Thank you for your quickness, Alasdair.
--
laurent
signature.asc
Description: OpenPGP digital signature
Re: 2.6.12-rc1-mm2
Le 25.03.2005 02:00, Patrick Mochel a écrit : On Thu, 24 Mar 2005, Andrew Morton wrote: Laurent Riffard <[EMAIL PROTECTED]> wrote: hello, Same kinds of problem here. It depends on the removed module. I mean: "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod ohci1394" hangs. Sysrq-T when rmmoding snd_ens1371 : It looks like we're getting stuck in the wait_for_completion() in the new klist_remove(). D'oh! It's getting hung while waiting to remove the current node from the list (which it can't remove because it's being used). The patch below should fix it. Pat = drivers/base/dd.c 1.3 vs edited = --- 1.3/drivers/base/dd.c 2005-03-21 12:25:04 -08:00 +++ edited/drivers/base/dd.c2005-03-24 16:55:21 -08:00 @@ -177,7 +177,7 @@ sysfs_remove_link(>kobj, kobject_name(>kobj)); sysfs_remove_link(>kobj, "driver"); - klist_remove(>knode_driver); + klist_del(>knode_driver); down(>sem); device_detach_shutdown(dev); Ok, I can confirm this patch solved the problem. Thanks for your help. -- laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.12-rc1-mm2
Le 25.03.2005 02:00, Patrick Mochel a écrit : On Thu, 24 Mar 2005, Andrew Morton wrote: Laurent Riffard [EMAIL PROTECTED] wrote: hello, Same kinds of problem here. It depends on the removed module. I mean: rmmod loop or rmmod pcspkr works. But rmmod snd_ens1371 or rmmod ohci1394 hangs. Sysrq-T when rmmoding snd_ens1371 : snip It looks like we're getting stuck in the wait_for_completion() in the new klist_remove(). D'oh! It's getting hung while waiting to remove the current node from the list (which it can't remove because it's being used). The patch below should fix it. Pat = drivers/base/dd.c 1.3 vs edited = --- 1.3/drivers/base/dd.c 2005-03-21 12:25:04 -08:00 +++ edited/drivers/base/dd.c2005-03-24 16:55:21 -08:00 @@ -177,7 +177,7 @@ sysfs_remove_link(drv-kobj, kobject_name(dev-kobj)); sysfs_remove_link(dev-kobj, driver); - klist_remove(dev-knode_driver); + klist_del(dev-knode_driver); down(dev-sem); device_detach_shutdown(dev); Ok, I can confirm this patch solved the problem. Thanks for your help. -- laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.12-rc1-mm2
Le 24.03.2005 23:31, Rafael J. Wysocki a écrit : Hi, On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: Lee Revell <[EMAIL PROTECTED]> wrote: On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when. I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. We've been discussing how to get ALSA CVS into ALSA bk more promptly. BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process goes into the D state immediately), which did not happen before. This is 100% reproducible, on two different AMD64-based boxes, with different sound chips. Greets, Rafael hello, Same kinds of problem here. It depends on the removed module. I mean: "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod ohci1394" hangs. Sysrq-T when rmmoding snd_ens1371 : rmmod D C92EBE8C 0 8231 8159 (NOTLB) c92ebea0 0082 0003 c92ebe8c 5685fc00 000f4253 cd624530 cd624658 cff60874 cff60844 c92ebebc c92ebef0 c02618c7 cd624530 c0113137 0282 cd248c20 cd248c07 0001 cd624530 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [] sys_delete_module+0x142/0x17b Sysrq-T when rmmoding ohci1394 : rmmod D 0001 0 12353 10401 (NOTLB) cefa9ea0 0082 c012f3d9 0001 0001e848 e88bbbc0 000f426d cb613570 cb613698 cff60074 cff60044 cefa9ebc cefa9ef0 c02618d7 cb613570 c0113137 0286 cd379e60 cd379e47 0001 cb613570 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [] sys_delete_module+0x142/0x17b [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 .config attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm2 # Thu Mar 24 23:38:31 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set #
Re: 2.6.12-rc1-mm2
Le 24.03.2005 23:31, Rafael J. Wysocki a crit : Hi, On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: Lee Revell [EMAIL PROTECTED] wrote: On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when. I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. We've been discussing how to get ALSA CVS into ALSA bk more promptly. BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process goes into the D state immediately), which did not happen before. This is 100% reproducible, on two different AMD64-based boxes, with different sound chips. Greets, Rafael hello, Same kinds of problem here. It depends on the removed module. I mean: rmmod loop or rmmod pcspkr works. But rmmod snd_ens1371 or rmmod ohci1394 hangs. Sysrq-T when rmmoding snd_ens1371 : rmmod D C92EBE8C 0 8231 8159 (NOTLB) c92ebea0 0082 0003 c92ebe8c 5685fc00 000f4253 cd624530 cd624658 cff60874 cff60844 c92ebebc c92ebef0 c02618c7 cd624530 c0113137 0282 cd248c20 cd248c07 0001 cd624530 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [c02618c7] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [c01f0ae3] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [c01f0b2b] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [c01f0bd8] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [c01f0b40] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [c01f05eb] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [c01f0cb2] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [c019b242] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [c0128356] sys_delete_module+0x142/0x17b Sysrq-T when rmmoding ohci1394 : rmmod D 0001 0 12353 10401 (NOTLB) cefa9ea0 0082 c012f3d9 0001 0001e848 e88bbbc0 000f426d cb613570 cb613698 cff60074 cff60044 cefa9ebc cefa9ef0 c02618d7 cb613570 c0113137 0286 cd379e60 cd379e47 0001 cb613570 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [c02618d7] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [c01f0aeb] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [c01f0b33] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [c01f0be0] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [c01f0b48] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [c01f05f3] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [c01f0cba] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [c019b242] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [c0128356] sys_delete_module+0x142/0x17b [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 .config attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm2 # Thu Mar 24 23:38:31 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Le 01.03.2005 00:17, Pavel Machek a écrit : Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. Pavel Hello, I noticed this behaviour, too. Can't remember if it came with 2.6.11-rc3-mm2 or with 2.6.11-rc4-mm1. Didn't try another kernel. I was able to workaround this problem by doing "echo platform > /sys/power/disk" before "echo disk > /sys/power/state" The box is a desktop with an asus A7V133 mb (VIA 82Cxxx chipset), Athlon XP 1600+ CPU and NVidia Geforce2 MX400 graphics. ~~ laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Le 01.03.2005 00:17, Pavel Machek a écrit : Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. Pavel Hello, I noticed this behaviour, too. Can't remember if it came with 2.6.11-rc3-mm2 or with 2.6.11-rc4-mm1. Didn't try another kernel. I was able to workaround this problem by doing echo platform /sys/power/disk before echo disk /sys/power/state The box is a desktop with an asus A7V133 mb (VIA 82Cxxx chipset), Athlon XP 1600+ CPU and NVidia Geforce2 MX400 graphics. ~~ laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Le 24.02.2005 18:18, Greg KH a écrit : On Thu, Feb 24, 2005 at 06:06:39PM +0100, Laurent Riffard wrote: Le 24.02.2005 00:47, Greg KH a ?crit : On Wed, Feb 23, 2005 at 11:36:50PM +0100, Laurent Riffard wrote: hey, what's this /dev/hds ? digging into /sys/block... ~$ ls -l /sys/block/hds/device lrwxrwxrwx 1 root root 0 f?v 23 22:45 /sys/block/hds/device -> ../../devices/pci:00/:00:04.1/ide1/1.1/ /dev/hdq should be /dev/hdd... ~$ ls -l /proc/ide total 4 -r--r--r-- 1 root root 0 f?v 23 23:28 drivers lrwxrwxrwx 1 root root 8 f?v 23 23:28 hda -> ide0/hda/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdb -> ide0/hdb/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdc -> ide1/hdc/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdd -> ide1/hdd/ dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide0/ dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide1/ -r--r--r-- 1 root root 0 f?v 23 23:28 via ~$ ls -d /sys/block/hd* /sys/block/hda/ /sys/block/hdc/ /sys/block/hdq/ /sys/block/hds/ What does /proc/devices show? Character devices: 1 mem 4 /dev/vc/0 4 tty 5 /dev/tty 5 /dev/console 5 /dev/ptmx 6 lp 7 vcs 10 misc 13 input 14 sound 29 fb 116 alsa 128 ptm 136 pts 171 ieee1394 180 usb Block devices: 1 ramdisk 2 fd 3 ide0 7 loop 22 ide1 253 pktcdvd 254 device-mapper Do you see something strange here ? No, ide0 is 3 and ide1 is 22, which is "standard". Hm, what's that pktcdvd and device-mapper doing there? Do you need those drivers? Can you try it without building them and see if that helps? I do need device-mapper, since I put /usr and /var on LVM filesystems. I use ptkcdvd to copy data to CD-RW. I can remove this one. Anyway, this patch from Andrew fixed the problem : http://lkml.org/lkml/2005/2/23/214. So I won't try to remove pktcdvd and device-mapper driver (except if you _really_ want me to do so). Thanks for your interest. -- laurent signature.asc Description: OpenPGP digital signature
Re: 2.6.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
Le 24.02.2005 00:47, Greg KH a écrit : On Wed, Feb 23, 2005 at 11:36:50PM +0100, Laurent Riffard wrote: hey, what's this /dev/hds ? digging into /sys/block... ~$ ls -l /sys/block/hds/device lrwxrwxrwx 1 root root 0 f?v 23 22:45 /sys/block/hds/device -> ../../devices/pci:00/:00:04.1/ide1/1.1/ /dev/hdq should be /dev/hdd... ~$ ls -l /proc/ide total 4 -r--r--r-- 1 root root 0 f?v 23 23:28 drivers lrwxrwxrwx 1 root root 8 f?v 23 23:28 hda -> ide0/hda/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdb -> ide0/hdb/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdc -> ide1/hdc/ lrwxrwxrwx 1 root root 8 f?v 23 23:28 hdd -> ide1/hdd/ dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide0/ dr-xr-xr-x 4 root root 0 f?v 23 23:28 ide1/ -r--r--r-- 1 root root 0 f?v 23 23:28 via ~$ ls -d /sys/block/hd* /sys/block/hda/ /sys/block/hdc/ /sys/block/hdq/ /sys/block/hds/ What does /proc/devices show? Character devices: 1 mem 4 /dev/vc/0 4 tty 5 /dev/tty 5 /dev/console 5 /dev/ptmx 6 lp 7 vcs 10 misc 13 input 14 sound 29 fb 116 alsa 128 ptm 136 pts 171 ieee1394 180 usb Block devices: 1 ramdisk 2 fd 3 ide0 7 loop 22 ide1 253 pktcdvd 254 device-mapper Do you see something strange here ? -- laurent signature.asc Description: OpenPGP digital signature
