* 2.4.18-rc4-aa1 XFS oopses caused by cpio
@ 2002-03-08 9:46 Svetoslav Slavtchev
2002-03-08 13:01 ` Stephen Lord
0 siblings, 1 reply; 8+ messages in thread
From: Svetoslav Slavtchev @ 2002-03-08 9:46 UTC (permalink / raw)
To: linux-kernel
that's what i got
Unable to handle kernel NULL pointer dereference at virtual address
00000008
801dba4e
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<801dba4e>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: 00000120 ebx: 00000000 ecx: 00000282 edx: 00000000
esi: 8b745a00 edi: 00000008 ebp: 9aa92000 esp: 9ca31904
ds: 0018 es: 0018 ss: 0018
Process cpio (pid: 20435, stackpage=9ca31000)
Stack: 00000282 00000004 8d5f4200 88dc0248 8d65b8c0 801db30d 88dc0248
00000008
00000004 00000001 8d65b980 8d65b8c0 00000004 88dc0248 801db081
88dc0248
8d65b980 8d65b8c0 00000004 8d65ba40 00000000 00000004 00000004
8b745b20
Call Trace: [<801db30d>] [<801db081>] [<801db674>] [<8022db0d>]
[<80209989>]
[<8023bc4d>] [<8022dd94>] [<801db3a2>] [<8022e747>] [<80222538>]
[<8020a412>]
[<8021d4b9>] [<80212496>] [<8020f959>] [<802236ac>] [<802299f5>]
[<80222f71>]
[<80234f0e>] [<801d83bd>] [<80220981>] [<8020e103>] [<8022341a>]
[<8020e103>]
[<80227c17>] [<80235098>] [<80235348>] [<80145966>] [<80145a52>]
[<8010722b>]
Code: 8b 4a 08 85 c9 74 1b 8d 74 26 00 8d bc 27 00 00 00 00 43 83
>>EIP; 801dba4e <xfs_alloc_mark_busy+3e/d0> <=====
Trace; 801db30c <xfs_alloc_put_freelist+cc/e0>
Trace; 801db080 <xfs_alloc_fix_freelist+430/480>
Trace; 801db674 <xfs_alloc_vextent+124/3c0>
Trace; 8022db0c <_pagebuf_get_object+3c/140>
Trace; 80209988 <xfs_ialloc_ag_alloc+1d8/810>
Trace; 8023bc4c <kmem_zone_zalloc+3c/e0>
Trace; 8022dd94 <_pagebuf_free_object+f4/120>
Trace; 801db3a2 <xfs_alloc_read_agf+82/230>
Trace; 8022e746 <pagebuf_rele+66/80>
Trace; 80222538 <xfs_trans_brelse+d8/e0>
Trace; 8020a412 <xfs_dialloc+182/900>
Trace; 8021d4b8 <xfs_mod_incore_sb_batch+48/a0>
Trace; 80212496 <xfs_inode_item_unlock+76/80>
Trace; 8020f958 <xfs_ialloc+58/3e0>
Trace; 802236ac <xfs_dir_ialloc+8c/290>
Trace; 802299f4 <xfs_mkdir+374/640>
Trace; 80222f70 <xfs_trans_free_items+30/90>
Trace; 80234f0e <linvfs_common_cr+1ae/2b0>
Trace; 801d83bc <xfs_acl_iaccess+2c/90>
Trace; 80220980 <xfs_trans_reserve+90/160>
Trace; 8020e102 <xfs_iunlock+32/60>
Trace; 8022341a <xfs_dir_lookup_int+ba/2c0>
Trace; 8020e102 <xfs_iunlock+32/60>
Trace; 80227c16 <xfs_lookup+a6/110>
Trace; 80235098 <linvfs_lookup+68/c0>
Trace; 80235348 <linvfs_mkdir+18/20>
Trace; 80145966 <vfs_mkdir+106/160>
Trace; 80145a52 <sys_mkdir+92/e0>
Trace; 8010722a <system_call+32/38>
Code; 801dba4e <xfs_alloc_mark_busy+3e/d0>
00000000 <_EIP>:
Code; 801dba4e <xfs_alloc_mark_busy+3e/d0> <=====
0: 8b 4a 08 mov 0x8(%edx),%ecx <=====
Code; 801dba50 <xfs_alloc_mark_busy+40/d0>
3: 85 c9 test %ecx,%ecx
Code; 801dba52 <xfs_alloc_mark_busy+42/d0>
5: 74 1b je 22 <_EIP+0x22> 801dba70
<xfs_alloc_mark_busy+60/d0>
Code; 801dba54 <xfs_alloc_mark_busy+44/d0>
7: 8d 74 26 00 lea 0x0(%esi,1),%esi
Code; 801dba58 <xfs_alloc_mark_busy+48/d0>
b: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi
Code; 801dba60 <xfs_alloc_mark_busy+50/d0>
12: 43 inc %ebx
Code; 801dba60 <xfs_alloc_mark_busy+50/d0>
13: 83 00 00 addl $0x0,(%eax)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio
2002-03-08 9:46 2.4.18-rc4-aa1 XFS oopses caused by cpio Svetoslav Slavtchev
@ 2002-03-08 13:01 ` Stephen Lord
2002-03-08 14:24 ` svetljo
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Lord @ 2002-03-08 13:01 UTC (permalink / raw)
To: Svetoslav Slavtchev; +Cc: linux-kernel
Svetoslav Slavtchev wrote:
>that's what i got
>
>Unable to handle kernel NULL pointer dereference at virtual address
>00000008
>801dba4e
>*pde = 00000000
>Oops: 0000
>CPU: 0
>EIP: 0010:[<801dba4e>] Not tainted
>Using defaults from ksymoops -t elf32-i386 -a i386
>EFLAGS: 00010046
>eax: 00000120 ebx: 00000000 ecx: 00000282 edx: 00000000
>esi: 8b745a00 edi: 00000008 ebp: 9aa92000 esp: 9ca31904
>ds: 0018 es: 0018 ss: 0018
>Process cpio (pid: 20435, stackpage=9ca31000)
>Stack: 00000282 00000004 8d5f4200 88dc0248 8d65b8c0 801db30d 88dc0248
>00000008
> 00000004 00000001 8d65b980 8d65b8c0 00000004 88dc0248 801db081
>88dc0248
> 8d65b980 8d65b8c0 00000004 8d65ba40 00000000 00000004 00000004
>8b745b20
>Call Trace: [<801db30d>] [<801db081>] [<801db674>] [<8022db0d>]
>[<80209989>]
> [<8023bc4d>] [<8022dd94>] [<801db3a2>] [<8022e747>] [<80222538>]
>[<8020a412>]
> [<8021d4b9>] [<80212496>] [<8020f959>] [<802236ac>] [<802299f5>]
>[<80222f71>]
> [<80234f0e>] [<801d83bd>] [<80220981>] [<8020e103>] [<8022341a>]
>[<8020e103>]
> [<80227c17>] [<80235098>] [<80235348>] [<80145966>] [<80145a52>]
>[<8010722b>]
>Code: 8b 4a 08 85 c9 74 1b 8d 74 26 00 8d bc 27 00 00 00 00 43 83
>
>>>EIP; 801dba4e <xfs_alloc_mark_busy+3e/d0> <=====
>>>
>Trace; 801db30c <xfs_alloc_put_freelist+cc/e0>
>Trace; 801db080 <xfs_alloc_fix_freelist+430/480>
>Trace; 801db674 <xfs_alloc_vextent+124/3c0>
>Trace; 8022db0c <_pagebuf_get_object+3c/140>
>Trace; 80209988 <xfs_ialloc_ag_alloc+1d8/810>
>Trace; 8023bc4c <kmem_zone_zalloc+3c/e0>
>Trace; 8022dd94 <_pagebuf_free_object+f4/120>
>Trace; 801db3a2 <xfs_alloc_read_agf+82/230>
>Trace; 8022e746 <pagebuf_rele+66/80>
>Trace; 80222538 <xfs_trans_brelse+d8/e0>
>Trace; 8020a412 <xfs_dialloc+182/900>
>Trace; 8021d4b8 <xfs_mod_incore_sb_batch+48/a0>
>Trace; 80212496 <xfs_inode_item_unlock+76/80>
>Trace; 8020f958 <xfs_ialloc+58/3e0>
>Trace; 802236ac <xfs_dir_ialloc+8c/290>
>Trace; 802299f4 <xfs_mkdir+374/640>
>Trace; 80222f70 <xfs_trans_free_items+30/90>
>Trace; 80234f0e <linvfs_common_cr+1ae/2b0>
>Trace; 801d83bc <xfs_acl_iaccess+2c/90>
>Trace; 80220980 <xfs_trans_reserve+90/160>
>Trace; 8020e102 <xfs_iunlock+32/60>
>Trace; 8022341a <xfs_dir_lookup_int+ba/2c0>
>Trace; 8020e102 <xfs_iunlock+32/60>
>Trace; 80227c16 <xfs_lookup+a6/110>
>Trace; 80235098 <linvfs_lookup+68/c0>
>Trace; 80235348 <linvfs_mkdir+18/20>
>Trace; 80145966 <vfs_mkdir+106/160>
>Trace; 80145a52 <sys_mkdir+92/e0>
>Trace; 8010722a <system_call+32/38>
>Code; 801dba4e <xfs_alloc_mark_busy+3e/d0>
>00000000 <_EIP>:
>Code; 801dba4e <xfs_alloc_mark_busy+3e/d0> <=====
> 0: 8b 4a 08 mov 0x8(%edx),%ecx <=====
>Code; 801dba50 <xfs_alloc_mark_busy+40/d0>
> 3: 85 c9 test %ecx,%ecx
>Code; 801dba52 <xfs_alloc_mark_busy+42/d0>
> 5: 74 1b je 22 <_EIP+0x22> 801dba70
><xfs_alloc_mark_busy+60/d0>
>Code; 801dba54 <xfs_alloc_mark_busy+44/d0>
> 7: 8d 74 26 00 lea 0x0(%esi,1),%esi
>Code; 801dba58 <xfs_alloc_mark_busy+48/d0>
> b: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi
>Code; 801dba60 <xfs_alloc_mark_busy+50/d0>
> 12: 43 inc %ebx
>Code; 801dba60 <xfs_alloc_mark_busy+50/d0>
> 13: 83 00 00 addl $0x0,(%eax)
>
This is this chunk of code:
for (bsy = mp->m_perag[agno].pagb_list, n = 0;
c01970e2: 31 db xor %ebx,%ebx
c01970e4: 8b b5 e4 01 00 00 mov 0x1e4(%ebp),%esi
c01970ea: 8b 54 06 20 mov 0x20(%esi,%eax,1),%edx
n < XFS_PAGB_NUM_SLOTS;
bsy++, n++) {
if (bsy->busy_tp == NULL) {
c01970ee: 8b 4a 08 mov 0x8(%edx),%ecx
It looks like bsy is NULL, which means either a corruption problem (agno
too large),
or a memory allocation problem during mount - did you get any error
messages when
you mounted the filesystem? Had you performed much I/O before this
happened, or
was the cpio the first thing you did. If this structure is missing then
chances are you
would not get far before dying. We have already referenced other fields
in the m_perag[agno]
structure, so I lean towards pagb_list itself being NULL.
Can you send me the output of mkfs if you still have it, or failing
that, the output
of xfs_growfs -n /xxx where /xxx is the mounted filesystem.
This chunk of code is new, you may have found a hole in it - although I
have been running
it for a couple of months here without problem. It could also be
something specific to
the aa kernel, I have not looked at this merge of XFS.
Steve
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio
2002-03-08 13:01 ` Stephen Lord
@ 2002-03-08 14:24 ` svetljo
2002-03-08 14:30 ` Stephen Lord
0 siblings, 1 reply; 8+ messages in thread
From: svetljo @ 2002-03-08 14:24 UTC (permalink / raw)
To: Stephen Lord, linux-kernel, linux-xfs
Stephen Lord wrote:
> Svetoslav Slavtchev wrote:
>
>> that's what i got
>>
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 00000008
>> 801dba4e
>> *pde = 00000000
>> Oops: 0000
>> CPU: 0
>> EIP: 0010:[<801dba4e>] Not tainted
>> Using defaults from ksymoops -t elf32-i386 -a i386
>> EFLAGS: 00010046
>> eax: 00000120 ebx: 00000000 ecx: 00000282 edx: 00000000
>> esi: 8b745a00 edi: 00000008 ebp: 9aa92000 esp: 9ca31904
>> ds: 0018 es: 0018 ss: 0018
>> Process cpio (pid: 20435, stackpage=9ca31000)
>> Stack: 00000282 00000004 8d5f4200 88dc0248 8d65b8c0 801db30d 88dc0248
>> 00000008
>> 00000004 00000001 8d65b980 8d65b8c0 00000004 88dc0248 801db081
>> 88dc0248
>> 8d65b980 8d65b8c0 00000004 8d65ba40 00000000 00000004 00000004
>> 8b745b20
>> Call Trace: [<801db30d>] [<801db081>] [<801db674>] [<8022db0d>]
>> [<80209989>]
>> [<8023bc4d>] [<8022dd94>] [<801db3a2>] [<8022e747>] [<80222538>]
>> [<8020a412>]
>> [<8021d4b9>] [<80212496>] [<8020f959>] [<802236ac>] [<802299f5>]
>> [<80222f71>]
>> [<80234f0e>] [<801d83bd>] [<80220981>] [<8020e103>] [<8022341a>]
>> [<8020e103>]
>> [<80227c17>] [<80235098>] [<80235348>] [<80145966>] [<80145a52>]
>> [<8010722b>]
>> Code: 8b 4a 08 85 c9 74 1b 8d 74 26 00 8d bc 27 00 00 00 00 43 83
>>
>>>> EIP; 801dba4e <xfs_alloc_mark_busy+3e/d0> <=====
>>>>
>> Trace; 801db30c <xfs_alloc_put_freelist+cc/e0>
>> Trace; 801db080 <xfs_alloc_fix_freelist+430/480>
>> Trace; 801db674 <xfs_alloc_vextent+124/3c0>
>> Trace; 8022db0c <_pagebuf_get_object+3c/140>
>> Trace; 80209988 <xfs_ialloc_ag_alloc+1d8/810>
>> Trace; 8023bc4c <kmem_zone_zalloc+3c/e0>
>> Trace; 8022dd94 <_pagebuf_free_object+f4/120>
>> Trace; 801db3a2 <xfs_alloc_read_agf+82/230>
>> Trace; 8022e746 <pagebuf_rele+66/80>
>> Trace; 80222538 <xfs_trans_brelse+d8/e0>
>> Trace; 8020a412 <xfs_dialloc+182/900>
>> Trace; 8021d4b8 <xfs_mod_incore_sb_batch+48/a0>
>> Trace; 80212496 <xfs_inode_item_unlock+76/80>
>> Trace; 8020f958 <xfs_ialloc+58/3e0>
>> Trace; 802236ac <xfs_dir_ialloc+8c/290>
>> Trace; 802299f4 <xfs_mkdir+374/640>
>> Trace; 80222f70 <xfs_trans_free_items+30/90>
>> Trace; 80234f0e <linvfs_common_cr+1ae/2b0>
>> Trace; 801d83bc <xfs_acl_iaccess+2c/90>
>> Trace; 80220980 <xfs_trans_reserve+90/160>
>> Trace; 8020e102 <xfs_iunlock+32/60>
>> Trace; 8022341a <xfs_dir_lookup_int+ba/2c0>
>> Trace; 8020e102 <xfs_iunlock+32/60>
>> Trace; 80227c16 <xfs_lookup+a6/110>
>> Trace; 80235098 <linvfs_lookup+68/c0>
>> Trace; 80235348 <linvfs_mkdir+18/20>
>> Trace; 80145966 <vfs_mkdir+106/160>
>> Trace; 80145a52 <sys_mkdir+92/e0>
>> Trace; 8010722a <system_call+32/38>
>> Code; 801dba4e <xfs_alloc_mark_busy+3e/d0>
>> 00000000 <_EIP>:
>> Code; 801dba4e <xfs_alloc_mark_busy+3e/d0> <=====
>> 0: 8b 4a 08 mov 0x8(%edx),%ecx <=====
>> Code; 801dba50 <xfs_alloc_mark_busy+40/d0>
>> 3: 85 c9 test %ecx,%ecx
>> Code; 801dba52 <xfs_alloc_mark_busy+42/d0>
>> 5: 74 1b je 22 <_EIP+0x22> 801dba70
>> <xfs_alloc_mark_busy+60/d0>
>> Code; 801dba54 <xfs_alloc_mark_busy+44/d0>
>> 7: 8d 74 26 00 lea 0x0(%esi,1),%esi
>> Code; 801dba58 <xfs_alloc_mark_busy+48/d0>
>> b: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi
>> Code; 801dba60 <xfs_alloc_mark_busy+50/d0>
>> 12: 43 inc %ebx
>> Code; 801dba60 <xfs_alloc_mark_busy+50/d0>
>> 13: 83 00 00 addl $0x0,(%eax)
>>
>
> This is this chunk of code:
>
> for (bsy = mp->m_perag[agno].pagb_list, n = 0;
> c01970e2: 31 db xor %ebx,%ebx
> c01970e4: 8b b5 e4 01 00 00 mov 0x1e4(%ebp),%esi
> c01970ea: 8b 54 06 20 mov 0x20(%esi,%eax,1),%edx
> n < XFS_PAGB_NUM_SLOTS;
> bsy++, n++) {
> if (bsy->busy_tp == NULL) {
> c01970ee: 8b 4a 08 mov 0x8(%edx),%ecx
>
> It looks like bsy is NULL, which means either a corruption problem
> (agno too large),
> or a memory allocation problem during mount - did you get any error
> messages when
> you mounted the filesystem? Had you performed much I/O before this
> happened, or
> was the cpio the first thing you did. If this structure is missing
> then chances are you
> would not get far before dying. We have already referenced other
> fields in the m_perag[agno]
> structure, so I lean towards pagb_list itself being NULL.
>
> Can you send me the output of mkfs if you still have it, or failing
> that, the output
> of xfs_growfs -n /xxx where /xxx is the mounted filesystem.
>
> This chunk of code is new, you may have found a hole in it - although
> I have been running
> it for a couple of months here without problem. It could also be
> something specific to
> the aa kernel, I have not looked at this merge of XFS.
>
> Steve
i just created LV, formated it with xfs , extended it , mounted it,
extended the fs , and started to transfer my old /opt to the LV with cpio
there were no complains from mount or xfs_growfs
and i have no the output from mkfs.xfs
[root@svetljo log]# xfs_growfs -n /opt
meta-data=/opt isize=256 agcount=12, agsize=33024 blks
data = bsize=4096 blocks=393216, imaxpct=25
= sunit=4 swidth=12 blks, unwritten=0
= imaxbits=24
naming =version 2 bsize=4096
log =internal bsize=4096 blocks=1200
realtime =none extsz=49152 blocks=0, rtextents=0
That is from /var/log/messages
Mar 8 10:34:44 svetljo kernel: XFS mounting filesystem lvm(58,5)
Mar 8 10:35:00 svetljo CROND[20367]: (root) CMD (
/usr/sbin/monitoring.pl)
Mar 8 10:36:11 svetljo kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000008
Mar 8 10:36:11 svetljo kernel: printing eip:
Mar 8 10:36:11 svetljo kernel: 801dba4e
Mar 8 10:36:11 svetljo kernel: *pde = 00000000
Mar 8 10:36:11 svetljo kernel: Oops: 0000
Mar 8 10:36:11 svetljo kernel: CPU: 0
Mar 8 10:36:11 svetljo kernel: EIP:
0010:[xfs_alloc_mark_busy+62/208] Not tainted
Mar 8 10:36:11 svetljo kernel: EIP: 0010:[<801dba4e>] Not tainted
Mar 8 10:36:11 svetljo kernel: EFLAGS: 00010046
Mar 8 10:36:11 svetljo kernel: eax: 00000120 ebx: 00000000 ecx:
00000282 edx: 00000000
Mar 8 10:36:11 svetljo kernel: esi: 8b745a00 edi: 00000008 ebp:
9aa92000 esp: 9ca31904
Mar 8 10:36:11 svetljo kernel: ds: 0018 es: 0018 ss: 0018
Mar 8 10:36:11 svetljo kernel: Process cpio (pid: 20435,
stackpage=9ca31000)
Mar 8 10:36:11 svetljo kernel: Stack: 00000282 00000004 8d5f4200
88dc0248 8d65b8c0 801db30d 88dc0248 00000008
Mar 8 10:36:11 svetljo kernel: 00000004 00000001 8d65b980
8d65b8c0 00000004 88dc0248 801db081 88dc0248
Mar 8 10:36:11 svetljo kernel: 8d65b980 8d65b8c0 00000004
8d65ba40 00000000 00000004 00000004 8b745b20
Mar 8 10:36:11 svetljo kernel: Call Trace:
[xfs_alloc_put_freelist+205/224] [xfs_alloc_fix_freelist+1073/1152]
[xfs_alloc_vextent+292/960] [_pagebuf_get_object+61/320]
[xfs_ialloc_ag_alloc+473/2064]
Mar 8 10:36:11 svetljo kernel: Call Trace: [<801db30d>] [<801db081>]
[<801db674>] [<8022db0d>] [<80209989>]
Mar 8 10:36:11 svetljo kernel: [kmem_zone_zalloc+61/224]
[_pagebuf_free_object+244/288] [xfs_alloc_read_agf+130/560]
[pagebuf_rele+103/128] [xfs_trans_brelse+216/224] [xfs_dialloc+386/2304]
Mar 8 10:36:11 svetljo kernel: [<8023bc4d>] [<8022dd94>]
[<801db3a2>] [<8022e747>] [<80222538>] [<8020a412>]
Mar 8 10:36:11 svetljo kernel: [xfs_mod_incore_sb_batch+73/160]
[xfs_inode_item_unlock+118/128] [xfs_ialloc+89/992]
[xfs_dir_ialloc+140/656] [xfs_mkdir+885/1600] [xfs_trans_free_items+49/144]
Mar 8 10:36:11 svetljo kernel: [<8021d4b9>] [<80212496>]
[<8020f959>] [<802236ac>] [<802299f5>] [<80222f71>]
Mar 8 10:36:11 svetljo kernel: [linvfs_common_cr+430/688]
[xfs_acl_iaccess+45/144] [xfs_trans_reserve+145/352] [xfs_iunlock+51/96]
[xfs_dir_lookup_int+186/704] [xfs_iunlock+51/96]
Mar 8 10:36:11 svetljo kernel: [<80234f0e>] [<801d83bd>]
[<80220981>] [<8020e103>] [<8022341a>] [<8020e103>]
Mar 8 10:36:11 svetljo kernel: [xfs_lookup+167/272]
[linvfs_lookup+104/192] [linvfs_mkdir+24/32] [vfs_mkdir+262/352]
[sys_mkdir+146/224] [system_call+51/56]
Mar 8 10:36:11 svetljo kernel: [<80227c17>] [<80235098>]
[<80235348>] [<80145966>] [<80145a52>] [<8010722b>]
Mar 8 10:36:11 svetljo kernel:
Mar 8 10:36:11 svetljo kernel: Code: 8b 4a 08 85 c9 74 1b 8d 74 26 00
8d bc 27 00 00 00 00 43 83
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio
2002-03-08 14:24 ` svetljo
@ 2002-03-08 14:30 ` Stephen Lord
2002-03-08 15:59 ` Stephen Lord
2002-03-08 18:45 ` Svetoslav Slavtchev
0 siblings, 2 replies; 8+ messages in thread
From: Stephen Lord @ 2002-03-08 14:30 UTC (permalink / raw)
To: svetljo; +Cc: linux-kernel, linux-xfs
svetljo wrote:
>
> i just created LV, formated it with xfs , extended it , mounted it,
> extended the fs , and started to transfer my old /opt to the LV with cpio
> there were no complains from mount or xfs_growfs
> and i have no the output from mkfs.xfs
>
> [root@svetljo log]# xfs_growfs -n /opt
> meta-data=/opt isize=256 agcount=12, agsize=33024 blks
> data = bsize=4096 blocks=393216, imaxpct=25
> = sunit=4 swidth=12 blks,
> unwritten=0
> = imaxbits=24
> naming =version 2 bsize=4096
> log =internal bsize=4096 blocks=1200
> realtime =none extsz=49152 blocks=0, rtextents=0
>
>
Ah, so you ran growfs on the filesystem, thats the key here. It looks
like the new code
does not handle growfs correctly, the structure which is null is not
allocated in the
expansion case. I should have a fix shortly.
Steve
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio
2002-03-08 14:30 ` Stephen Lord
@ 2002-03-08 15:59 ` Stephen Lord
2002-03-10 22:19 ` Pavel Machek
2002-03-08 18:45 ` Svetoslav Slavtchev
1 sibling, 1 reply; 8+ messages in thread
From: Stephen Lord @ 2002-03-08 15:59 UTC (permalink / raw)
To: svetljo; +Cc: linux-kernel, linux-xfs
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Stephen Lord wrote:
>>
> Ah, so you ran growfs on the filesystem, thats the key here. It looks
> like the new code
> does not handle growfs correctly, the structure which is null is not
> allocated in the
> expansion case. I should have a fix shortly.
>
> Steve
Hi,
Can you try and repeat with this patch, it should apply reasonably
cleanly to the aa tree.
Steve
[-- Attachment #2: growfs.patch --]
[-- Type: text/plain, Size: 1218 bytes --]
===========================================================================
Index: linux/fs/xfs/xfs_alloc.c
===========================================================================
2234a2235,2236
> pag->pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS *
> sizeof(xfs_perag_busy_t), KM_SLEEP);
===========================================================================
Index: linux/fs/xfs/xfs_mount.c
===========================================================================
151,152c151,153
< kmem_free(mp->m_perag[agno].pagb_list,
< sizeof(xfs_perag_busy_t) * XFS_PAGB_NUM_SLOTS);
---
> if (mp->m_perag[agno].pagb_list)
> kmem_free(mp->m_perag[agno].pagb_list,
> sizeof(xfs_perag_busy_t) * XFS_PAGB_NUM_SLOTS);
877,881d877
< for (agno = 0; agno < sbp->sb_agcount; agno++) {
< mp->m_perag[agno].pagb_count = 0;
< mp->m_perag[agno].pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS *
< sizeof(xfs_perag_busy_t), KM_SLEEP);
< }
1066,1067c1062,1064
< kmem_free(mp->m_perag[agno].pagb_list,
< sizeof(xfs_perag_busy_t) * XFS_PAGB_NUM_SLOTS);
---
> if (mp->m_perag[agno].pagb_list)
> kmem_free(mp->m_perag[agno].pagb_list,
> sizeof(xfs_perag_busy_t) * XFS_PAGB_NUM_SLOTS);
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio
2002-03-08 14:30 ` Stephen Lord
2002-03-08 15:59 ` Stephen Lord
@ 2002-03-08 18:45 ` Svetoslav Slavtchev
2002-03-08 19:14 ` Martin K. Petersen
1 sibling, 1 reply; 8+ messages in thread
From: Svetoslav Slavtchev @ 2002-03-08 18:45 UTC (permalink / raw)
To: Stephen Lord; +Cc: linux-kernel, linux-xfs
Hi
seems to work now
created a 1 Gib lv, formated it, extended with 2 Gib , extended the fs
and transfered about 1,5 Gib over it
No troubles
thanks for the fix
:)
svetljo
and
a stupid question
is there a way to limit the I/O request that XFS sends to the lower
layer ( soft RAID or lvm ) without need to modify existing fs
just a hack until the raid-0 code in 2.5 is fixed
i'm talking about this:
> raid0_make_request bug: can't convert block across chunks or bigger
> than 16k 23610115 64
i posted already twice to lkml and linux-xfs
and i got answer that the raid is not ready but it's worked on
thanks
svetljo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio
2002-03-08 18:45 ` Svetoslav Slavtchev
@ 2002-03-08 19:14 ` Martin K. Petersen
0 siblings, 0 replies; 8+ messages in thread
From: Martin K. Petersen @ 2002-03-08 19:14 UTC (permalink / raw)
To: Svetoslav Slavtchev; +Cc: Stephen Lord, linux-kernel, linux-xfs
>>>>> "Svetoslav" == Svetoslav Slavtchev <galia@st-peter.stw.uni-erlangen.de> writes:
Svetoslav> and a stupid question is there a way to limit the I/O
Svetoslav> request that XFS sends to the lower layer ( soft RAID or
Svetoslav> lvm ) without need to modify existing fs just a hack until
Svetoslav> the raid-0 code in 2.5 is fixed
Not really. Besides, requests may be merged and that would give the
same result.
I've been busy with IA-64 stuff the last week - I'll try to get back
to the RAID hacking this weekend. I have all of my code merged but
still need to deal with multi-zone setups.
--
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio
2002-03-08 15:59 ` Stephen Lord
@ 2002-03-10 22:19 ` Pavel Machek
0 siblings, 0 replies; 8+ messages in thread
From: Pavel Machek @ 2002-03-10 22:19 UTC (permalink / raw)
To: Stephen Lord; +Cc: svetljo, linux-kernel, linux-xfs
Hi!
> >Ah, so you ran growfs on the filesystem, thats the key here. It looks
> >like the new code
> >does not handle growfs correctly, the structure which is null is not
> >allocated in the
> >expansion case. I should have a fix shortly.
> >
> >Steve
>
> Hi,
>
> Can you try and repeat with this patch, it should apply reasonably
> cleanly to the aa tree.
Please please, diff -u ...
Pavel
>
> ===========================================================================
> Index: linux/fs/xfs/xfs_alloc.c
> ===========================================================================
>
> 2234a2235,2236
> > pag->pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS *
> > sizeof(xfs_perag_busy_t), KM_SLEEP);
>
--
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-03-11 18:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-08 9:46 2.4.18-rc4-aa1 XFS oopses caused by cpio Svetoslav Slavtchev
2002-03-08 13:01 ` Stephen Lord
2002-03-08 14:24 ` svetljo
2002-03-08 14:30 ` Stephen Lord
2002-03-08 15:59 ` Stephen Lord
2002-03-10 22:19 ` Pavel Machek
2002-03-08 18:45 ` Svetoslav Slavtchev
2002-03-08 19:14 ` Martin K. Petersen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox