On Tue, 2006-02-07 at 11:46 +0100, Andi Kleen wrote:
> Found this on a box still running 2.6.15-git7 (I know it's a bit old).
> It was under relatively heavy NFS client traffic. Perhaps it's of interest
> for someone.
>
> -Andi
>
>
> nfs_update_inode: inode 961647 mode changed, 0040755 to 0100644
This is weird. The server appears to have magically changed a directory
into a regular file...
Would this be the userland server or is it knfsd?
> ----------- [cut here ] --------- [please bite here ] ---------
> Kernel BUG at /home/lsrc/quilt/linux/lib/radix-tree.c:378
> invalid opcode: 0000 [1] SMP
> CPU 4
> Modules linked in:
> Pid: 3853, comm: cp Tainted: G M 2.6.15-git7 #91
> RIP: 0010:[<ffffffff80239ce1>] <ffffffff80239ce1>{radix_tree_tag_set+93}
> RSP: 0018:ffff810086ee1bf0 EFLAGS: 00010046
> RAX: 0000000000000000 RBX: ffff810101627188 RCX: ffff8100e957e538
> RDX: 0000000000000008 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffff8100f475dd98 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
> R13: 0000000000000282 R14: 0000000000000000 R15: ffff81007e4d0200
> FS: 00002aaaab106b00(0000) GS:ffff810101c58ec0(0000) knlGS:0000000040340da0
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00002aaaab0c1390 CR3: 0000000173034000 CR4: 00000000000006e0
> Process cp (pid: 3853, threadinfo ffff810086ee0000, task ffff8100fb9d54f0)
> Stack: ffffffff801598f2 ffff81011191f678 ffff8100b866c840 ffff81011191f3c0
> ffff81011191f678 0000000000000000 ffffffff802067be 0000000100000004
> 0000000100000002 0000000000000000
> Call Trace: <ffffffff801598f2>{test_set_page_writeback+117}
> <ffffffff802067be>{nfs_flush_inode+1032} <ffffffff80206e2f>{nfs_writepage
> s+97}
> <ffffffff8015952f>{do_writepages+32} <ffffffff801537ad>{__filemap_fdatawr
> ite_range+81}
> <ffffffff80154426>{filemap_write_and_wait+20} <ffffffff801ffee2>{nfs_sync
> _mapping+32}
> <ffffffff801fff35>{nfs_revalidate_mapping+46} <ffffffff802001b7>{__nfs_re
> validate_inode+514}
> <ffffffff80140002>{__dequeue_signal+418} <ffffffff8013fab8>{sigprocmask+1
> 80}
> <ffffffff80206bea>{nfs_sync_inode+79} <ffffffff8020057f>{nfs_getattr+108}
> <ffffffff8017cc18>{vfs_fstat+41} <ffffffff8017d077>{sys_newfstat+17}
> <ffffffff8010f8d2>{system_call+126}
>
> Code: 0f 0b 68 1b a6 43 80 c2 7a 01 41 83 e9 06 41 ff c3 45 39 d3
> RIP <ffffffff80239ce1>{radix_tree_tag_set+93} RSP <ffff810086ee1bf0>
I suspect this might be a consequence of the above weirdness.
Cheers,
Trond
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
