xfs
[Top] [All Lists]

Re: Things todo before we announce

To: "Andi Kleen" <ak@xxxxxxx>
Subject: Re: Things todo before we announce
From: lord@xxxxxxx
Date: Thu, 30 Mar 2000 08:46:47 -0600
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Your message of "Thu, 30 Mar 2000 16:38:46 +0200
Sender: owner-linux-xfs@xxxxxxxxxxx
> 
> Even with BUF_META off I got another hang, again while copying a kernel
> tree to it Symlinks seem to be still flakey (they also cannot be removed).
> Looks like file_lock leaked and the NMI oopser killed it. 
> 
> [... lots of similar messages ... ]
> 
> cp: cannot create symbolic link `/xfs/lsrc/sgi/linux-2.3-xfs/cmd/xfs/sim/src/
xfs_vnodeops.c': File exists
> cp: cannot create symbolic link `/xfs/lsrc/sgi/linux-2.3-xfs/cmd/xfs/sim/src/
xfs_uuid.c': File exists
> Unable to handle kernel NULL pointer dereference at virtual address 00000015
> *pde = 00000000
> Entering kdb (0xc6ae6000) on processor 0 Panic: Oops
> due to panic @ 0xc014a8fd
> eax = 0x0000000d  ebx = 0xc14643e0  ecx = 0xc5197a00  edx = 0xc0354fe4  
> esi = 0x0000000d  edi = 0x00008241  esp = 0xc6ae6000  eip = 0xc014a8fd  
> ebp = 0xc6ae7f90   ss = 0x00000002   cs = 0x00000010  eflags = 0x00010207  
>  ds = 0xc0350018   es = 0x00000018  origeax = 0xffffffff  &regs = 0xc6ae7f4c
> [E0]ntkderbi>n g kdb (0xc758c000) on processor 1 due to NonMaskable Interrupt
 @ 0xc012ab7a
> eax = 0xffffffff  ebx = 0xfc3b6021  ecx = 0xc0348a80  edx = 0x00000000  
> esi = 0xc0159b50  edi = 0xc1464ce0  esp = 0xc0348a80  eip = 0xc012ab7a  
> ebp = 0xc758df24   ss = 0x00000000   cs = 0x00000010  eflags = 0x00000297  
>  ds = 0xc0110018   es = 0xc0340018  origeax = 0xffffffff  &regs = 0xc758dee8
> [1]kdb> bt
>     EBP       EIP         Function(args)
> 0xc758df24 0xc012ab7a  _spin_lock_+0x32( 0xc0348a80)
> 0xc758df60 0xc0159b51  do_select+0x115( 0x1, 0xc758dfa4, 0xc758dfa0)
> 0xc758dfbc 0xc015a10b  sys_select+0x34f( 0x1, 0xbffffccc, 0x0, 0x0, 0x0)
> 0xbffffd4c 0xc010bd68  system_call
> [1]kdb> reboot
> 
> 
> -Andi

Oh there is nothing like people using your code.....

If you can make this happen again could you send the back trace from the
panic cpu - kdb always seems to run on the other cpu from a panic, the
system went down on cpu 0 and kdb came up on 1. Just do a cpu x to the 
other cpu and backtrace it.

The symlink stuff is not too surprising, I will add it to the list.

Thanks,

    Steve




<Prev in Thread] Current Thread [Next in Thread>