On Sat, Dec 24, 2005 at 11:03:36PM +0300, Andrey J. Melnikoff (TEMHOTA) wrote:
> Hello.
Hi Andrey,
> Please, CC me, i'm not subscribed.
>
> Kernel 2.6.15-rc6 OOPS:
>
> kernel: general protection fault: 0000 [#1]
> kernel: SMP
> kernel: Modules linked in: ipt_REDIRECT ipt_LOG ipt_TOS ipt_TCPMSS ipt_tos
> ip_nat_ftp ipt_tcpmss iptable_nat ip_nat iptable_mangle iptable_filter
> ipt_multiport ipt_mac ipt_state ipt_limit ipt_conntrack ip_conntrack_ftp
> ip_conntrack ip_tables af_packet ipv6 pcspkr floppy i2c_piix4 i2c_core
> ohci_hcd usbcore aic7xxx scsi_transport_spi psmouse ide_disk ide_cd
> cdrom genrtc
> kernel: CPU: 0
> kernel: EIP: 0060:[<c019d70f>] Not tainted VLI
> kernel: EFLAGS: 00010286 (2.6.15-rc6)
> kernel: EIP is at ext3_find_entry+0x18f/0x3e0
> kernel: eax: ffffffff ebx: 00010001 ecx: 00000002 edx: 00000000
> kernel: esi: 00000000 edi: ffffffff ebp: 00000000 esp: f71b9d60
> kernel: ds: 007b es: 007b ss: 0068
> kernel: Process smbd (pid: 2999, threadinfo=f71b8000 task=f7aee530)
> kernel: Stack: 00000000 f71b9db8 00000000 00000027 000005b4 ffffffff
f71a62e8 00000000
> kernel: f71b9ea8 00001000 f71a636c 00000001 00000001 00010001
00000001 00000000
> kernel: 00000000 00000000 f7caf400 f71b9df0 f71503d4 ffffffff
00000000 f7159c68
> kernel: Call Trace:
> kernel: [<c025eb29>] memcpy_toiovec+0x29/0x50
> kernel: [<c019dbda>] ext3_lookup+0x3a/0xc0
> kernel: [<c0167c8e>] real_lookup+0xae/0xd0
> kernel: [<c0167f35>] do_lookup+0x85/0x90
> kernel: [<c016872f>] __link_path_walk+0x7ef/0xdd0
> kernel: [<c0168d5e>] link_path_walk+0x4e/0xd0
> kernel: [<c016907f>] path_lookup+0x9f/0x170
> kernel: [<c01693cf>] __user_walk+0x2f/0x60
> kernel: [<c0163b5d>] vfs_stat+0x1d/0x60
> kernel: [<c01641df>] sys_stat64+0xf/0x30
> kernel: [<c0121271>] sys_gettimeofday+0x21/0x60
> kernel: [<c0102e59>] syscall_call+0x7/0xb
> kernel: Code: 07 7e 88 89 f6 8d bc 27 00 00 00 00 8b 5c 24 34 8b 44 9c 5c
43 89
> 5c 24 34 85 c0 89 44 24 14 89 44 24 54 0f 84 b7 00 00 00 89 c7 <8b>
00 a8 04 75
> 07 8b 47 0c 85 c0 75 11 8b 44 24 14 e8 fb e1 fb
is this Oops in any way reproducible?
If yes, does it occur in earlier kernels like 2.6.14.x?
> After OOPS system work, but smbd process in 'D' state:
>
> kernel: smbd D 00000000 0 3000 2871 3001 2872
(NOTLB)
> kernel: f71b9dbc 000005b4 000005b4 00000000 00000000 f71b9ea8 c1b70dc0
00000000
> kernel: 7fffffff c031d940 c1807400 00000000 998db100 003d099f
c0300b20 f7aee530
> kernel: f7aee658 f71a63e0 f71a63e8 00000292 f7aee530 c02ba525
00000001 f7aee530
> kernel: Call Trace:
> kernel: [<c02ba525>] __down+0x75/0xe0
> kernel: [<c0118d70>] default_wake_function+0x0/0x10
> kernel: [<c0172804>] __d_lookup+0xa4/0x110
> kernel: [<c02b8e8f>] __down_failed+0x7/0xc
> kernel: [<c016bb42>] .text.lock.namei+0x8/0x1e6
> kernel: [<c0167f35>] do_lookup+0x85/0x90
> kernel: [<c016872f>] __link_path_walk+0x7ef/0xdd0
> kernel: [<c0168d5e>] link_path_walk+0x4e/0xd0
> kernel: [<c017ce14>] __mark_inode_dirty+0x104/0x1b0
> kernel: [<c016907f>] path_lookup+0x9f/0x170
> kernel: [<c01693cf>] __user_walk+0x2f/0x60
> kernel: [<c0163b5d>] vfs_stat+0x1d/0x60
> kernel: [<c017ce14>] __mark_inode_dirty+0x104/0x1b0
> kernel: [<c0121a0f>] current_fs_time+0x5f/0x70
> kernel: [<c01641df>] sys_stat64+0xf/0x30
> kernel: [<c0174832>] update_atime+0x52/0x90
> kernel: [<c016cdc5>] vfs_readdir+0x85/0x90
> kernel: [<c0171891>] dput+0x71/0x1b0
> kernel: [<c01763bb>] mntput_no_expire+0x1b/0x70
> kernel: [<c0159d8c>] filp_close+0x3c/0x80
> kernel: [<c0102e59>] syscall_call+0x7/0xb
>
> kernel: smbd D 00000000 0 3001 2871 3008 3000
(NOTLB)
> kernel: f71fbdbc 000005b4 000005b4 00000000 00000000 f71fbea8 c1b70e60
00000000
> kernel: 7fffffff c031d940 c1807400 00000000 0dfc9800 003d09ad
c0300b20 f7aeea30
> kernel: f7aeeb58 f71a63e0 f71a63e8 00000292 f7aeea30 c02ba525
00000001 f7aeea30
> kernel: Call Trace:
> kernel: [<c02ba525>] __down+0x75/0xe0
> kernel: [<c0118d70>] default_wake_function+0x0/0x10
> kernel: [<c0172804>] __d_lookup+0xa4/0x110
> kernel: [<c02b8e8f>] __down_failed+0x7/0xc
> kernel: [<c016bb42>] .text.lock.namei+0x8/0x1e6
> kernel: [<c0167f35>] do_lookup+0x85/0x90
> kernel: [<c016872f>] __link_path_walk+0x7ef/0xdd0
> kernel: [<c0168d5e>] link_path_walk+0x4e/0xd0
> kernel: [<c017cd72>] __mark_inode_dirty+0x62/0x1b0
> kernel: [<c016907f>] path_lookup+0x9f/0x170
> kernel: [<c01693cf>] __user_walk+0x2f/0x60
> kernel: [<c0163b5d>] vfs_stat+0x1d/0x60
> kernel: [<c017cd72>] __mark_inode_dirty+0x62/0x1b0
> kernel: [<c0121a0f>] current_fs_time+0x5f/0x70
> kernel: [<c01641df>] sys_stat64+0xf/0x30
> kernel: [<c0174832>] update_atime+0x52/0x90
> kernel: [<c016cdc5>] vfs_readdir+0x85/0x90
> kernel: [<c0171891>] dput+0x71/0x1b0
> kernel: [<c01763bb>] mntput_no_expire+0x1b/0x70
> kernel: [<c0159d8c>] filp_close+0x3c/0x80
> kernel: [<c0102e59>] syscall_call+0x7/0xb
>
> kernel: smbd D 00000000 0 3008 2871 3015 3001
(NOTLB)
> kernel: f736bdbc 000005b4 000005b4 00000000 00000000 f736bea8 f79e4e00
00000000
> kernel: 7fffffff c031d940 c1807400 00000000 66f2b100 003d09bd
c0300b20 f7b3b0b0
> kernel: f7b3b1d8 f71a63e0 f71a63e8 00000292 f7b3b0b0 c02ba525
00000001 f7b3b0b0
> kernel: Call Trace:
> kernel: [<c02ba525>] __down+0x75/0xe0
> kernel: [<c0118d70>] default_wake_function+0x0/0x10
> kernel: [<c0172804>] __d_lookup+0xa4/0x110
> kernel: [<c02b8e8f>] __down_failed+0x7/0xc
> kernel: [<c016bb42>] .text.lock.namei+0x8/0x1e6
> kernel: [<c0167f35>] do_lookup+0x85/0x90
> kernel: [<c016872f>] __link_path_walk+0x7ef/0xdd0
> kernel: [<c0168d5e>] link_path_walk+0x4e/0xd0
> kernel: [<c017cd72>] __mark_inode_dirty+0x62/0x1b0
> kernel: [<c016907f>] path_lookup+0x9f/0x170
> kernel: [<c01693cf>] __user_walk+0x2f/0x60
> kernel: [<c0163b5d>] vfs_stat+0x1d/0x60
> kernel: [<c017cd72>] __mark_inode_dirty+0x62/0x1b0
> kernel: [<c0121a0f>] current_fs_time+0x5f/0x70
> kernel: [<c01641df>] sys_stat64+0xf/0x30
> kernel: [<c0174832>] update_atime+0x52/0x90
> kernel: [<c016cdc5>] vfs_readdir+0x85/0x90
> kernel: [<c0171891>] dput+0x71/0x1b0
> kernel: [<c01763bb>] mntput_no_expire+0x1b/0x70
> kernel: [<c0159d8c>] filp_close+0x3c/0x80
> kernel: [<c0102e59>] syscall_call+0x7/0xb
>
> kernel: smbd D C01641BA 0 3015 2871 3036 3008
(NOTLB)
> kernel: f7273f30 bfe3253c 00000000 c01641ba 00000804 00000000 00000000
0048815f
> kernel: 000041c0 00000008 c1807400 00000000 66224500 003d09e6
c0300b20 f7b3bab0
> kernel: f7b3bbd8 f71a63e0 f71a63e8 00000286 f7b3bab0 c02ba525
00000001 f7b3bab0
> kernel: Call Trace:
> kernel: [<c01641ba>] cp_new_stat64+0xea/0x100
> kernel: [<c02ba525>] __down+0x75/0xe0
> kernel: [<c0118d70>] default_wake_function+0x0/0x10
> kernel: [<c02b8e8f>] __down_failed+0x7/0xc
> kernel: [<c016d070>] filldir64+0x0/0xf0
> kernel: [<c016d23f>] .text.lock.readdir+0x8/0x29
> kernel: [<c016d1d7>] sys_getdents64+0x77/0xd7
> kernel: [<c016c36e>] do_fcntl+0x16e/0x1e0
> kernel: [<c0102e59>] syscall_call+0x7/0xb
>
>
> Hardware: IBM eServer xSeries 330, 1Gb memory, ServeRaid 4Mx.
>
> Config, other data - on request.
>
> --
> Best regards, TEMHOTA-RIPN aka MJA13-RIPE
> System Administrator. mailto:temnota at kmv.ru
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed