* Ali Akcaagac ([email protected]) wrote:
> And happy easter to you all. Just got this while trying to delete some
> files on my system.
I'm curious, what was the virtual address the kernel was "Unable to handle..."
That part was left off this bug report.
> : printing eip:
> : c021f089
> : *pde = 00000000
> : Oops: 0000 [#1]
> : PREEMPT
> : Modules linked in: snd_seq_midi snd_emu10k1_synth snd_emux_synth
> snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1
> snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer
> snd_page_alloc snd_util_mem snd_hwdep snd soundcore parport_pc lp
> parport 8139too mii crc32
> : CPU: 0
> : EIP: 0060:[linvfs_open+89/160] Not tainted VLI
> : EFLAGS: 00010282 (2.6.11.6)
> : EIP is at linvfs_open+0x59/0xa0
Nothing in the -stable series has changed either XFS or the core vfs
path on during file open. Without a chance of reproducing or any more
information, it'll be tough to make much progress here.
> : eax: 00000000 ebx: c77ac06c ecx: 00000001 edx: c021f030
> : esi: 00000000 edi: c77ac050 ebp: dffe41a0 esp: c2d95f14
> : ds: 007b es: 007b ss: 0068
> : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80)
> : Stack: c01561a9 dffe41a0 d73504c0 00000000 c77ac06c c015446b c77ac06c
> d73504c0
> : 00000001 ffffffe9 00008000 00008000 dc364000 c2d94000 c015426c
> cbcdff54
> : dffe41a0 00008000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72
> 00300001
> : Call Trace:
> : [get_empty_filp+89/208] get_empty_filp+0x59/0xd0
> : [dentry_open+491/672] dentry_open+0x1eb/0x2a0
> : [filp_open+92/112] filp_open+0x5c/0x70
> : [get_unused_fd+123/224] get_unused_fd+0x7b/0xe0
> : [sys_open+73/144] sys_open+0x49/0x90
> : [syscall_call+7/11] syscall_call+0x7/0xb
> : Code: 5b 3c b8 01 00 00 00 e8 c6 42 ef ff b8 00 e0 ff ff 21 e0 8b 40
> 08 a8 08 75 4d 85 f6 7c 0a 7f 32 81 fb ff ff ff 7f 77 2a 8b 47 14 <8b>
> 50 08 c7 44 24 04 00 00 00 00 89 04 24 ff 52 04 8b 5c 24 08
Best I can tell, you hit this:
mov 0x8(%eax),%edx
with eax == 00000000. This corresponds to a vp->v_fops (or rather
vp->v_bh.bh_first->bd_ops) deref. So, looks like the vnode has a
NULL v_bh.bh_first (which looks like it's meant to be used to mean
uninitialized). May check with XFS folks if they've seen this type
of bug.
thanks,
-chris
-
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]