I updated my system to (mostly) RedHat6.2, and it seems in the process the
updatedb for locate has been replaced by a new one. I previously had a
configuration for updatedb that did not go into mounted smbfs directory
(*). But the configuration seems no longer be that way...
Anyway, I had a whole rootfs of another linux machine mounted of smbfs
(for backup, I had forgotten it) when updatedb was run. I got hundreds of
these in my log:
Apr 23 04:47:45 babbage kernel: smb_proc_readdir_long: name=\proc\23901\fd\*, entries=0, rcls=1, err=5
Apr 23 04:47:45 babbage kernel: smb_refill_dircache: readdir failed, result=-13
Apr 23 04:47:45 babbage kernel: smb_proc_readdir_long: name=\proc\26677\fd\*, entries=0, rcls=1, err=5
Apr 23 04:47:45 babbage kernel: smb_refill_dircache: readdir failed, result=-13
Apr 23 04:47:45 babbage kernel: smb_proc_readdir_long: name=\proc\26678\fd\*, entries=0, rcls=1, err=5
Apr 23 04:47:45 babbage kernel: smb_refill_dircache: readdir failed, result=-13
Apr 23 04:47:45 babbage kernel: smb_proc_readdir_long: name=\root\.gnome\*, entries=0, rcls=1, err=5
Apr 23 04:47:45 babbage kernel: smb_refill_dircache: readdir failed, result=-13
Apr 23 04:47:45 babbage kernel: smb_proc_readdir_long: name=\root\.gnome_private\*, entries=0, rcls=1, err=5
Apr 23 04:47:45 babbage kernel: smb_refill_dircache: readdir failed, result=-13
Apr 23 04:47:45 babbage kernel: smb_proc_readdir_long: name=\root\nsmail\*, entries=0, rcls=1, err=5
Apr 23 04:47:45 babbage kernel: smb_refill_dircache: readdir failed, result=-13
And later:
Apr 23 05:56:57 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8196, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8200, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8196, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8204, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8200, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8196, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8208, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8204, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8200, size=8192
Apr 23 05:56:58 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=8212, size=8192
(...)
Apr 24 06:32:55 babbage kernel: smb_setup_header: Aieee, xmit len > packet! len=62232, size=8192
where len went from 8196 to 62232 in 4 byte increments. The next message
was
Apr 24 06:32:55 babbage kernel: grow_inodes: inode-max limit reached
Apr 24 06:32:55 babbage kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000068
Apr 24 06:32:55 babbage kernel: current->tss.cr3 = 02d69000, %cr3 = 02d69000
Apr 24 06:32:55 babbage kernel: *pde = 00000000
Apr 24 06:32:55 babbage kernel: Oops: 0002
Apr 24 06:32:55 babbage kernel: CPU: 1
Apr 24 06:32:56 babbage kernel: EIP: 0010:[<d0b50252>]
Apr 24 06:32:56 babbage kernel: EFLAGS: 00010292
Apr 24 06:32:56 babbage kernel: eax: 00000000 ebx: ce602400 ecx: 0000003b edx: ce88a000
Apr 24 06:32:56 babbage kernel: esi: ce0f7e94 edi: cc110d00 ebp: 00000000 esp: ce0f7e4c
Apr 24 06:32:56 babbage kernel: ds: 0018 es: 0018 ss: 0018
Apr 24 06:32:56 babbage kernel: Process updatedb (pid: 12687, process nr: 120, stackpage=ce0f7000)
Apr 24 06:32:56 babbage kernel: Stack: cc110d00 ce0f7e94 ce0f7e94 ffffffdc cc110d00 d0b4ea53 ce602400 ce0f7e94
Apr 24 06:32:56 babbage kernel: c05e9000 d0b4ea3e 00000001 ce0f7e94 cc1e3000 00000282 fffffff4 cc110d00
Apr 24 06:32:56 babbage kernel: c518cbb0 ce6a5380 00000010 001cc72c 000141ed 00000000 00000000 00000200
Apr 24 06:32:56 babbage kernel: Call Trace: [<d0b4ea53>] [<d0b4ea3e>] [real_lookup+92/180] [<d0b4e7a9>] [lookup_dentry+300/496] [__namei+47/100][filldir+0/132]
Apr 24 06:32:56 babbage kernel: [sys_getdents+226/276] [sys_newlstat+47/164] [error_code+45/64] [system_call+52/64]
Apr 24 06:32:56 babbage kernel: Code: 89 5d 68 66 8b 43 08 66 89 45 20 8b 46 04 89 45 18 8d 9d 9c
So my initial diagnose is that smbfs leaks inodes or something. (I have
not yet ksymoopsed that oops, since even after echo 32000 >
/proc/sys/fs7inode-max (it was ~1600) I can't execute make in
scripts/ksymoops. First it couldn't load libc (due to inode max), but now
it just hangs in __down_failed. Spooky. I'll boot and post the ksymoops
asap.) One cpp even caused an oops:
Apr 24 10:05:24 babbage kernel: Unable to handle kernel NULL pointer dereference at virtual address 000000bc
Apr 24 10:05:24 babbage kernel: current->tss.cr3 = 0b19b000, %cr3 = 0b19b000
Apr 24 10:05:24 babbage kernel: *pde = 00000000
Apr 24 10:05:24 babbage kernel: Oops: 0000
Apr 24 10:05:24 babbage kernel: CPU: 0
Apr 24 10:05:25 babbage kernel: EIP: 0010:[comp_short_keys+16/60]
Apr 24 10:05:25 babbage kernel: EFLAGS: 00010283
Apr 24 10:05:25 babbage kernel: eax: 00000000 ebx: 000000bc ecx: cbd41ea8 edx: cbd40000
Apr 24 10:05:25 babbage kernel: esi: 00000001 edi: cbd41ea8 ebp: cf7a8a00 esp: cbd41de0
Apr 24 10:05:25 babbage kernel: ds: 0018 es: 0018 ss: 0018
Apr 24 10:05:25 babbage kernel: Process cpp (pid: 13824, process nr: 263, stackpage=cbd41000)
Apr 24 10:05:25 babbage kernel: Stack: c015e7cf 000000bc cbd41ea8 00000000 c015c55b cbd41e44 00000001 cbd41e84
Apr 24 10:05:25 babbage kernel: c9172400 cbd41e84 c0241390 cbd41e44 c015c588 cf7a8a00 cbd41ea8 cffd0600
Apr 24 10:05:25 babbage kernel: ffffffe4 fffffff4 c9172400 c5210bb0 c3ef65c0 00000287 0002b0a5 c0241390
Apr 24 10:05:25 babbage kernel: Call Trace: [reiserfs_iget+59/116] [reiserfs_lookup+79/184] [reiserfs_lookup+124/184] [do_anonymous_page+110/128] [real_lookup+92/180] [do_no_page+75/248] [lookup_dentry+300/496]
Apr 24 10:05:25 babbage kernel: [__namei+47/100] [do_page_fault+271/952] [sys_access+163/308] [error_code+45/64] [system_call+52/64]
Apr 24 10:05:25 babbage kernel: Code: 8b 13 8b 01 39 c2 73 08 b8 ff ff ff ff eb 1a 90 39 c2 76 08
I guess that's not a reisefs bug... Dir cache corruption or something?
I tried lsof -p:ing many processes, but none seems to use more files than
it should.
-- v --
(*) Updatedb in smbfs directories used to cause trouble in days 2.2.x,
where x < 8 or so, and it is not that useful anyway.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:07 EST