BUG at inode.c:1024

BUG at inode.c:1024

[Jesse Barnes]

Ok, I think this backtrace is actually legitimate (different, working hardware 
I hope) :)  I hit this while running aim7, about 20 min. into the run or so, 
probably at a few thousand users.  It was a 64p machine.  The machine stayed 
up and continued running aim7 until it was rebooted by the next user who had 
it reserved.

Thanks,
Jesse

kernel BUG at fs/inode.c:1025!
multitask[32163]: bugcheck! 0 [1]
Modules linked in:

Pid: 32163, CPU 8, comm:            multitask
psr : 0000101008026018 ifs : 800000000000038a ip  : [<a0000001001a9850>]    
Nottainted
ip is at generic_delete_inode+0x310/0x400
unat: 0000000000000000 pfs : 000000000000038a rsc : 0000000000000003
rnat: 00000000f880f5b7 bsps: 000000000001003e pr  : 0000000005aaa959
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0  : a0000001001a9850 b6  : a000000100104cc0 b7  : a0000001004b0d60
f6  : 0ffec89813003a028040c f7  : 0ffe0afb0d00000000000
f8  : 1001be93fe00000000000 f9  : 10011ee4e000000000000
f10 : 10008fa91c79e4f580355 f11 : 1003e00000000000003ea
r1  : a000000100ba6ba0 r2  : 0000000000000000 r3  : 0000000000000001
r8  : 000000000000001f r9  : 0000000000004000 r10 : e0000a3004a4427a
r11 : e0000a3004a44260 r12 : e000083c6c5e7e30 r13 : e000083c6c5e0000
r14 : 0000000000000000 r15 : e000083c6c5e0e70 r16 : e000083c6c5e0e80
r17 : e00008b4789f7de8 r18 : 0000000000020220 r19 : 0fd0000000000000
r20 : 0000088000000000 r21 : 8000000910000380 r22 : 0000000000020220
r23 : 0000000000000000 r24 : 0000000000000000 r25 : 0000000000000004
r26 : e000083c67f98e70 r27 : e000083c6c5e0e74 r28 : e000083c67f98e74
r29 : e000083c67f9802c r30 : e00008b4789f002c r31 : e00008b004a24968

Call Trace:
 [<a000000100017380>] show_stack+0x80/0xa0
                                sp=e000083c6c5e79c0 bsp=e000083c6c5e1110
 [<a00000010003d4b0>] die+0x150/0x200
                                sp=e000083c6c5e7b90 bsp=e000083c6c5e10d0
 [<a00000010003d9f0>] ia64_bad_break+0x430/0x4c0
                                sp=e000083c6c5e7b90 bsp=e000083c6c5e10a8
 [<a00000010000f660>] ia64_leave_kernel+0x0/0x270
                                sp=e000083c6c5e7c60 bsp=e000083c6c5e10a8
 [<a0000001001a9850>] generic_delete_inode+0x310/0x400
                                sp=e000083c6c5e7e30 bsp=e000083c6c5e1058
 [<a0000001001a72a0>] iput+0x140/0x1e0
                                sp=e000083c6c5e7e30 bsp=e000083c6c5e1030
 [<a0000001001a0570>] dput+0x370/0x660
                                sp=e000083c6c5e7e30 bsp=e000083c6c5e0ff0
 [<a000000100168360>] __fput+0x280/0x320
                                sp=e000083c6c5e7e30 bsp=e000083c6c5e0fa0
 [<a000000100164f40>] filp_close+0xc0/0x1a0
                                sp=e000083c6c5e7e30 bsp=e000083c6c5e0f70
 [<a000000100165170>] sys_close+0x150/0x1a0
                                sp=e000083c6c5e7e30 bsp=e000083c6c5e0ef8
 [<a00000010000f4c0>] ia64_ret_from_syscall+0x0/0x20
                                sp=e000083c6c5e7e30 bsp=e000083c6c5e0ef8

Re: BUG at inode.c:1024 in 2.6.9-rc1-mm5

[Jesse Barnes]

On Monday, September 13, 2004 7:33 pm, Jesse Barnes wrote:
> Ok, I think this backtrace is actually legitimate (different, working
> hardware I hope) :)  I hit this while running aim7, about 20 min. into the
> run or so, probably at a few thousand users.  It was a 64p machine.  The
> machine stayed up and continued running aim7 until it was rebooted by the
> next user who had it reserved.

Umm... err... 2.6.9-rc1-mm5