Re: Kernel OOOPS in 2.6.11.6
On Tue, 2005-03-29 at 19:01 +0200, Christoph Hellwig wrote: > just to check whether it's Nathan's race theory, can you please > disable PREEMPT and PREEMPT_BKL? Ok till now this ooops can not be reproduced. I have been spending some time today copying large chunks of files and subdirs from point A to point B but everything seem to work normally. These errors are hard to trigger specially when happening under strange circumstances. As soon as I hit this issue again I will report again. greetings, Ali Akcaagac - 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/
Re: Kernel OOOPS in 2.6.11.6
On Tue, Mar 29, 2005 at 08:59:23AM -0800, Chris Wright wrote: > * Nathan Scott ([EMAIL PROTECTED]) wrote: > > On Mon, Mar 28, 2005 at 02:44:30PM -0800, Chris Wright wrote: > > > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > > > And happy easter to you all. Just got this while trying to delete some > > > > files on my system. > > > ... > > > > : 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. > > > > *nod*. > > > > Your full .config would be useful too, Ali, thanks. > > Here's .config from Ali. just to check whether it's Nathan's race theory, can you please disable PREEMPT and PREEMPT_BKL? - 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/
Re: Kernel OOOPS in 2.6.11.6
* Nathan Scott ([EMAIL PROTECTED]) wrote: > On Mon, Mar 28, 2005 at 02:44:30PM -0800, Chris Wright wrote: > > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > > And happy easter to you all. Just got this while trying to delete some > > > files on my system. > > ... > > > : 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. > > *nod*. > > Your full .config would be useful too, Ali, thanks. Here's .config from Ali. thanks, -chris # Automatically generated make config: don't edit # Linux kernel version: 2.6.11.6 # Sat Mar 26 17:55:03 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # # CONFIG_ACPI is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PC-card bridges # # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not se
Re: Kernel OOOPS in 2.6.11.6
On Tue, Mar 29, 2005 at 04:30:44PM +1000, Nathan Scott wrote: > On Mon, Mar 28, 2005 at 02:44:30PM -0800, Chris Wright wrote: > > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > > And happy easter to you all. Just got this while trying to delete some > > > files on my system. > > ... > > > : 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. > > *nod*. > > Your full .config would be useful too, Ali, thanks. > > > with eax == . 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. > > Its not currently known. Looks like a possible iget-related race; > does this one ring any bells, Christoph? This means the inode wasn't fully initialized. This looks more like a problem of not unwinding properly on an error than a race to me. I'll take a deeper look. - 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/
Re: Kernel OOOPS in 2.6.11.6
On Mon, Mar 28, 2005 at 02:44:30PM -0800, Chris Wright wrote: > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > And happy easter to you all. Just got this while trying to delete some > > files on my system. > ... > > : 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. *nod*. Your full .config would be useful too, Ali, thanks. > with eax == . 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. Its not currently known. Looks like a possible iget-related race; does this one ring any bells, Christoph? cheers. -- Nathan - 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/
Re: Kernel OOOPS in 2.6.11.6
On Tue, Mar 29, 2005 at 12:27:01PM +1000, Keith Owens wrote: > i386 needs unwind data plus a kernel unwinder to get accurate > backtraces. Without the data and an unwinder, i386 backtraces are > best guess. They often contain spurious addresses, from noise words > that were left on the kernel stack. Nothing to do with > CONFIG_4K_STACKS. XFS will break sometimes with 4K stacks on x86 - 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/
Re: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 18:06:08 -0800, Chris Wedgwood <[EMAIL PROTECTED]> wrote: >On Mon, Mar 28, 2005 at 04:24:15PM -0800, Chris Wright wrote: > >> Imperfect stack trace decoding. > >Is this with CONFIG_4K_STACKS? does it happen w/o it? i386 needs unwind data plus a kernel unwinder to get accurate backtraces. Without the data and an unwinder, i386 backtraces are best guess. They often contain spurious addresses, from noise words that were left on the kernel stack. Nothing to do with CONFIG_4K_STACKS. - 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/
Re: Kernel OOOPS in 2.6.11.6
On Mon, Mar 28, 2005 at 04:24:15PM -0800, Chris Wright wrote: > Imperfect stack trace decoding. Is this with CONFIG_4K_STACKS? does it happen w/o it? - 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/
Re: Kernel OOOPS in 2.6.11.6
On Tue, 2005-03-29 at 08:12 +0800, Coywolf Qi Hunt wrote: > > > > with eax == . 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. > > > > > > I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an > > > invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at > > > address f. > > > eax == 0 is to clear the memory in memset(). > > > > The trace indicates it's in linvfs_open > > (EIP: 0060:[linvfs_open+89/160]) > > and the insturction dump at the end supports that. > > How to explain: > Call Trace: [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 ? I like to let you know that this was all I got as dump. Was simply trying to copy some stuff from A to B on my harddisk using MC on a XFS partition using 2.6.11.6. Though I also detected another really strange thing together with this issue. On a valid XFS partition (no errors or something) I tried to delete about 160 CVS checked out modules (GNOME) and *buff* stuff couldn't be deleted anymore but I wasn't aware of this at that moment. Seconds later I was trying to copy stuff from A to B as described above and this gave me that hit. Luckely the hit caused let me continue using the System. I then tried to delete the stuff again and noticed that it hadn't deleted the CVS checkout in A) properly and that I copied the undeleted stuff to B) as well. I then inserted my own created rescue CD, mounted the partition again, and voila was able to delete the stuff xfs_repair check on it gave no errors or something. Maybe this helps isolating the issue. - 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/
Re: Kernel OOOPS in 2.6.11.6
* Coywolf Qi Hunt ([EMAIL PROTECTED]) wrote: > How to explain: > Call Trace: [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 ? Imperfect stack trace decoding. 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/
Re: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 15:04:16 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > * Coywolf Qi Hunt ([EMAIL PROTECTED]) wrote: > > On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > > > * 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 = > > > > : Oops: [#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: ebx: c77ac06c ecx: 0001 edx: c021f030 > > > > : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 > > > > : ds: 007b es: 007b ss: 0068 > > > > : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) > > > > : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c > > > > d73504c0 > > > > :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c > > > > cbcdff54 > > > > :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 > > > > 0031 > > > > : 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: > > > > > > mov0x8(%eax),%edx > > > > > > with eax == . 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. > > > > I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an > > invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address > > f. > > eax == 0 is to clear the memory in memset(). > > The trace indicates it's in linvfs_open > (EIP: 0060:[linvfs_open+89/160]) > and the insturction dump at the end supports that. How to explain: Call Trace: [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 ? Thanks -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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/
Re: Kernel OOOPS in 2.6.11.6
* Coywolf Qi Hunt ([EMAIL PROTECTED]) wrote: > On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > > * 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 = > > > : Oops: [#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: ebx: c77ac06c ecx: 0001 edx: c021f030 > > > : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 > > > : ds: 007b es: 007b ss: 0068 > > > : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) > > > : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c > > > d73504c0 > > > :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c > > > cbcdff54 > > > :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 > > > 0031 > > > : 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: > > > > mov0x8(%eax),%edx > > > > with eax == . 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. > > I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an > invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address f. > eax == 0 is to clear the memory in memset(). The trace indicates it's in linvfs_open (EIP: 0060:[linvfs_open+89/160]) and the insturction dump at the end supports that. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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/
Re: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > * 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 = > > : Oops: [#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: ebx: c77ac06c ecx: 0001 edx: c021f030 > > : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 > > : ds: 007b es: 007b ss: 0068 > > : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) > > : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c > > d73504c0 > > :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c > > cbcdff54 > > :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 > > 0031 > > : 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: > > mov0x8(%eax),%edx > > with eax == . 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. I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address f. eax == 0 is to clear the memory in memset(). -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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/
Re: Kernel OOOPS in 2.6.11.6
* 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 = > : Oops: [#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: ebx: c77ac06c ecx: 0001 edx: c021f030 > : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 > : ds: 007b es: 007b ss: 0068 > : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) > : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c > d73504c0 > :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c > cbcdff54 > :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 > 0031 > : 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: mov0x8(%eax),%edx with eax == . 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/
