search for: filldir64

...00000 00000000 00000000 00000000 ce46f220 Oct 29 12:46:57 box kernel: c6cdd1c0 57770000 008bbf97 206f671c 00000000 00000000 c24c0000 000000ce Oct 29 12:46:57 box kernel: 00000000 ffffffea 00000001 000000d0 c7dba335 cb03f9e0 c29d9fb0 c0140030 Oct 29 12:46:57 box kernel: Call Trace: [filldir64+0/276] [usbcore:usb_devfs_handle+56151073/95263347] [filldir64+0/276] [filldir64+0/276] [usbcore:usb_devfs_handle+56151214/95263206] Oct 29 12:46:57 box kernel: [filldir64+0/276] [usbcore:usb_devfs_handle+56155128/95259292] [filldir64+0/276] [vfs_readdir+97/132] [filldir64+0/276] [sys_getdents6...

...00 00000000 00000000 00000000 c6b1fa40 Oct 4 16:22:39 linux kernel: c6b21920 00000000 00005a7c 00000000 00000000 00000000 c6a57000 0000001b Oct 4 16:22:39 linux kernel: 00000000 00000000 00000001 0000001d c6192335 c567e7a0 c6075fb0 c0140030 Oct 4 16:22:39 linux kernel: Call Trace: [filldir64+0/276] [snd-pcm:__insmod_snd-pcm_S.bss_L256+46219157/139697367] [filldir64+0/276] [filldir64+0/276] [snd-pcm:__insmod_snd-pcm_S.bss_L256+46219298/139697226] Oct 4 16:22:39 linux kernel: [filldir64+0/276] [snd-pcm:__insmod_snd-pcm_S.bss_L256+46223212/139693312] [filldir64+0/276] [vfs_readdir+97/...

...l@vger.kernel.org Got this in the syslog today: VFS: brelse: Trying to free free buffer buffer layer error at fs/buffer.c:1182 Call Trace: [<c014c345>] __brelse+0x35/0x40 [<c0180efe>] ext3_htree_fill_tree+0x14e/0x240 [<c017a809>] ext3_dx_readdir+0x99/0x1e0 [<c015b390>] filldir64+0x0/0xf0 [<c017a3f5>] ext3_readdir+0x465/0x490 [<c015b390>] filldir64+0x0/0xf0 [<c01d5258>] __blk_put_request+0xd8/0x110 [<c01d320f>] elv_queue_empty+0x1f/0x30 [<c01e8d8c>] choose_drive+0x1c/0x190 [<c01e844a>] ide_do_request+0x3a/0x290 [<c015b0ca>] v...

...chn_callback+0xc/0x10 [212521.428003] [<c0195d5c>] ? path_walk+0x4f/0xa3 [212521.428003] [<c0196aa0>] ? do_path_lookup+0x132/0x178 [212521.428003] [<c019732e>] ? getname+0x5e/0xb0 [212521.428003] [<c0197b05>] ? user_path_at+0x37/0x5f [212521.428003] [<c0198e80>] ? filldir64+0x0/0xc5 [212521.428003] [<c019187f>] ? vfs_lstat_fd+0x12/0x3 [212455.928003] [<c0191912>] ? sys_lstat64+0xf/0x23 [212455.928003] [<c0199124>] ? vfs_readdir+0x7c/0x8c [212455.928003] [<c0198e80>] ? filldir64+0x0/0xc5 [212455.928003] [<c01991cf>] ? sys_getdents64+0...

...in kernel: c0180d15 c018097e c48f8fa0 ffffffda 0856a5dc c717f920 00000000 c0180fcb Aug 15 23:01:28 mydomain kernel: 0856a644 0856a62c 00000f98 ffffffea 00000009 0856a5c0 002e8ff4 c48f8000 Aug 15 23:01:28 mydomain kernel: Call Trace: Aug 15 23:01:28 mydomain kernel: [<c0180d15>] filldir64+0x0/0x11a Aug 15 23:01:28 mydomain kernel: [<c0180d15>] filldir64+0x0/0x11a Aug 15 23:01:28 mydomain kernel: [<c018097e>] vfs_readdir+0x8a/0xb7 Aug 15 23:01:28 mydomain kernel: [<c0180fcb>] sys_getdents64+0x80/0xba Aug 15 23:01:28 mydomain kernel: [<c031af83>] syscall_ca...

...d>] journal_start_Rsmp_89deb980 [jbd] 0xbd [<f887297e>] ext3_dirty_inode [ext3] 0x6e [<c0156f2e>] __mark_inode_dirty [kernel] 0x2e [<c01588b1>] update_atime [kernel] 0x51 [<f886dc68>] ext3_readdir [ext3] 0x3e8 [<c015588c>] dput [kernel] 0x1c [<c01519e0>] filldir64 [kernel] 0x0 [<c0151584>] vfs_readdir [kernel] 0x84 [<c01519e0>] filldir64 [kernel] 0x0 [<c0151b6f>] sys_getdents64 [kernel] 0x4f [<c01519e0>] filldir64 [kernel] 0x0 [<c0140b4a>] sys_fchdir [kernel] 0xea [<c0108c6b>] system_call [kernel] 0x33 kjournald is...

Hi all, I installed the samba 3.0.3 on a Fedora Core 2 and then samba 3.0.6-1 and still have the following problem. When I mount a smbfs, it sucesses but processes hang when they access the mount point and smbumount returns "Device busy". Since even system halt fails unmounting the filesystem, I have to switch off the machine. I tested either with smbmount command, or /etc/fstab

...2>] ? htree_dirblock_to_tree+0x33/0x126 [ 4660.188552] [<ffffffff8110a46e>] ? ext3_htree_fill_tree+0x79/0x1d3 [ 4660.188557] [<ffffffff810b5cb7>] ? do_last+0x527/0x59e [ 4660.188561] [<ffffffff81101b36>] ? ext3_readdir+0x179/0x532 [ 4660.188564] [<ffffffff810b813c>] ? filldir64+0xb0/0xb0 [ 4660.188567] [<ffffffff810ae253>] ? cp_new_stat+0xe9/0xfb [ 4660.188570] [<ffffffff810b813c>] ? filldir64+0xb0/0xb0 [ 4660.188573] [<ffffffff810b82ea>] ? vfs_readdir+0x72/0xa4 [ 4660.188576] [<ffffffff810b8454>] ? sys_getdents+0x7a/0xc1 [ 4660.188580] [<f...

...59/0x5f kernel: [<02121350>] put_files_struct+0x57/0xc0 kernel: [<02121f4e>] do_exit+0x227/0x3bd kernel: [<021221d2>] sys_exit_group+0x0/0xd kernel: [<021294f8>] get_signal_to_deliver+0x341/0x369 kernel: [<02105e6c>] do_signal+0x55/0xd5 kernel: [<0216396f>] filldir64+0x0/0x122 kernel: [<0214f08a>] rw_vm+0x27e/0x28c kernel: [<0214f3a5>] put_user_size+0x29/0x2d kernel: [<02163b30>] sys_getdents64+0x9f/0xa9 kernel: [<02105f14>] do_notify_resume+0x28/0x38 kernel: Code: 1c 8b 53 04 8b 03 89 50 04 89 02 31 d2 2b 4b 0c c7 03 00 01 10 00 c7...

...> Trace; fffffc000043fba4 <generic_make_request+204/240> Trace; fffffc000043fcac <submit_bh+cc/1e0> Trace; fffffc000044000c <ll_rw_block+24c/320> Trace; fffffc0000355ba0 <end_buffer_io_sync+0/80> Trace; fffffc0000392b04 <ext3_bread+64/e0> Trace; fffffc000036b5e0 <filldir64+0/1c0> Trace; fffffc000038ee28 <ext3_readdir+a8/4c0> Trace; fffffc000036ac28 <vfs_readdir+e8/1c0> Trace; fffffc000036b5e0 <filldir64+0/1c0> Trace; fffffc000036489c <link_path_walk+d7c/dc0> Trace; fffffc00003648f8 <path_walk+18/40> Trace; fffffc00003634b4 <permiss...

...00001 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,...

mainly question for the intel folks, any chance to rerun the ltp testsuites to see how we are doing these days with all the changes ? thanks :) Wim