[OpenAFS] Regulary Ooups'es on 2.4.29 + OpenAFS 1.2.13

[David Botsch]

Here is more info:

Here is the full panic log:

Starting AFS cache scan...osi_AllocSmallS: size=268
Unable to handle kernel paging request at virtual address ffffffff
 printing eip:
c8962ad0
*pde = 00001063
*pte = 00000000
Oops: 0002
libafs-2.4.20-29.8.progeny.9-i586 sd_mod autofs 8139too mii iptable_filter ip_tables ide-scsi scsi_mod ide-cd cdrom mousedev keybdev hid input usb-ohci usbcor
CPU:    0
EIP:    0010:[<c8962ad0>]    Tainted: PF
EFLAGS: 00010282

EIP is at osi_Panic [libafs-2.4.20-29.8.progeny.9-i586] 0x20 (2.4.20-29.8.progeny.9)
eax: 0000001a   ebx: 00000000   ecx: 00000000   edx: c7154000
esi: 00000001   edi: c7f6a29b   ebp: 0000000c   esp: c6f9fbd4
ds: 0018   es: 0018   ss: 0018
Process afsd (pid: 634, stackpage=c6f9f000)
Stack: c897fb6c 0000010c 00000000 00000000 0000000a fdf650ec c8a3e000 c893883d 
       c897fb6c 0000010c 00000000 00000000 00000000 00000000 00000000 c896ca59 
       0000010c 00000007 0806f1e0 c896d269 c54a1960 c899c700 00000000 00000007 
Call Trace:   [<c897fb6c>] .rodata.str1.1 [libafs-2.4.20-29.8.progeny.9-i586] 0x29c (0xc6f9fbd4))
[<c893883d>] osi_AllocSmallSpace [libafs-2.4.20-29.8.progeny.9-i586] 0xfd (0xc6f9fbf0))
[<c897fb6c>] .rodata.str1.1 [libafs-2.4.20-29.8.progeny.9-i586] 0x29c (0xc6f9fbf4))
[<c896ca59>] osi_UFSOpen [libafs-2.4.20-29.8.progeny.9-i586] 0x49 (0xc6f9fc10))
[<c896d269>] osi_InitCacheInfo [libafs-2.4.20-29.8.progeny.9-i586] 0x79 (0xc6f9fc20))
[<c899c700>] afs_cacheNd [libafs-2.4.20-29.8.progeny.9-i586] 0x0 (0xc6f9fc28))
[<c8935125>] afs_InitCacheInfo [libafs-2.4.20-29.8.progeny.9-i586] 0x45 (0xc6f9fc40))
[<c01b8d16>] __ide_dma_read [kernel] 0xd6 (0xc6f9fc54))
[<c89372d2>] afs_osi_Alloc [libafs-2.4.20-29.8.progeny.9-i586] 0x42 (0xc6f9fc60))
[<c89710b9>] afs_syscall_call [libafs-2.4.20-29.8.progeny.9-i586] 0x519 (0xc6f9fc80))
[<c018dac9>] req_new_io [kernel] 0x49 (0xc6f9fc9c))
[<c018e0bf>] __make_request [kernel] 0x40f (0xc6f9fcc4))
[<c01b85bc>] ide_build_sglist [kernel] 0x17c (0xc6f9fcf0))
[<c013ea18>] getblk [kernel] 0x38 (0xc6f9fd20))
[<c013ea3f>] getblk [kernel] 0x5f (0xc6f9fd2c))
[<c013ea18>] getblk [kernel] 0x38 (0xc6f9fd40))
[<c013ea3f>] getblk [kernel] 0x5f (0xc6f9fd4c))
[<c013ec3a>] bread [kernel] 0x1a (0xc6f9fd64))
[<c881d616>] ext3_get_branch [ext3] 0x66 (0xc6f9fd78))
[<c881dc3c>] ext3_get_block_handle [ext3] 0x5c (0xc6f9fd98))
[<c880da55>] do_get_write_access [jbd] 0x255 (0xc6f9fdb0))
[<c880e2aa>] journal_dirty_metadata_Re0ca952f [jbd] 0x12a (0xc6f9fde4))
[<c881fe3f>] ext3_do_update_inode [ext3] 0x14f (0xc6f9fe08))
[<c881fe6e>] ext3_do_update_inode [ext3] 0x17e (0xc6f9fe0c))
[<c880dcfc>] journal_get_write_access_R42eadfcc [jbd] 0x3c (0xc6f9fe24))
[<c8820410>] ext3_reserve_inode_write [ext3] 0x50 (0xc6f9fe48))
[<c8820391>] ext3_mark_iloc_dirty [ext3] 0x21 (0xc6f9fe5c))
[<c88203a2>] ext3_mark_iloc_dirty [ext3] 0x32 (0xc6f9fe64))
[<c0130d9a>] kfree [kernel] 0x2a (0xc6f9fe78))
[<c880e64c>] journal_stop_Rcd8953b6 [jbd] 0x16c (0xc6f9fe88))
[<c8820523>] ext3_dirty_inode [ext3] 0x73 (0xc6f9fea4))
[<c014feba>] __mark_inode_dirty [kernel] 0x7a (0xc6f9feb8))
[<c01512b3>] update_atime [kernel] 0x53 (0xc6f9fecc))
[<c881bbcb>] ext3_readdir [ext3] 0x2cb (0xc6f9fedc))
[<c89716bf>] afs_syscall [libafs-2.4.20-29.8.progeny.9-i586] 0x18f (0xc6f9ff40))
[<c013da88>] fput [kernel] 0xb8 (0xc6f9ff78))
[<c013c143>] sys_close [kernel] 0x43 (0xc6f9ffb0))
[<c0108ca3>] system_call [kernel] 0x33 (0xc6f9ffc0))


Code: c6 05 ff ff ff ff 2a 83 c4 1c c3 90 8d 74 26 00 b8 be 03 98 



On Sun, Feb 20, 2005 at 03:13:31PM -0500, chas williams - CONTRACTOR wrote:
> In message <20050217190130.GF27308@ccmr.cornell.edu>,David Botsch writes:
> >kernel: Starting AFS cache scan...osi_AllocSmallS: size=268
> >kernel: Unable to handle kernel paging request at virtual address ffffffff
> >
> >I can send more detailed logs upon request.
> 
> this panic is different.  its caused by:
> 
>     if (size > AFS_SMALLOCSIZ)
>         osi_Panic("osi_AllocSmallS: size=%d\n", size);
> 
> in afs_osi_alloc.c  if you get get a meaningful stack trace that
> would be useful in determining who/what is allocating too much space
> using the small allocator. 
> 

-- 
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
dwb7@ccmr.cornell.edu
********************************