xfs
[Top] [All Lists]

Re: kernel BUG at buffer.c

To: Соколов Сергей <s_sokolov@xxxxxxxxxxxxxxxx>
Subject: Re: kernel BUG at buffer.c
From: Danny Cox <DCox@xxxxxxxxxxxxxx>
Date: Mon, 15 Jul 2002 07:46:02 -0400
Cc: XFS Mailing List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <1662520654.20020715082500@avtodor.gorny.ru>
References: <1662520654.20020715082500@avtodor.gorny.ru>
Sender: owner-linux-xfs@xxxxxxxxxxx
Sergei,

On Sun, 2002-07-14 at 21:25, Соколов Сергей wrote:
> Hello!
> I have linux kernel 2.4.19-rc1 with xfs enabled.
> My xfs partition locate on /dev/ataraid device (Promise FastTrak Tx4).
> I have two problems:
> 
> 1) [root@ws188 linux-2.4.19-rc1-xfs]# mkfs.xfs /dev/ataraid/d1p2
>    mkfs.xfs: warning - cannot set blocksize on block device 
> /dev/ataraid/d1p2: Invalid argument
> 
> 2)When i copying files between partitions, I receive message.
> 
> Jul 12 17:01:19 ws188 kernel: kernel BUG at buffer.c:549!
> Jul 12 17:01:19 ws188 kernel: invalid operand: 0000
> Jul 12 17:01:19 ws188 kernel: CPU:    0
> Jul 12 17:01:19 ws188 kernel: EIP:    0010:[__insert_into_lru_list+37/112]    
> Not tainted
> Jul 12 17:01:19 ws188 kernel: EIP:    0010:[<c012f335>]    Not tainted
> Jul 12 17:01:19 ws188 kernel: EFLAGS: 00010206
> Jul 12 17:01:19 ws188 kernel: eax: 00000000   ebx: 00000008   ecx: d6e297c0   
> edx: c02ec594
> Jul 12 17:01:19 ws188 kernel: esi: 00000002   edi: 00001000   ebp: 00000000   
> esp: df0ebe18
> Jul 12 17:01:19 ws188 kernel: ds: 0018   es: 0018   ss: 0018
> Jul 12 17:01:19 ws188 kernel: Process mc (pid: 872, stackpage=df0eb000)
> Jul 12 17:01:19 ws188 kernel: Stack: 00000002 d6e297c0 c012fb64 d6e297c0 
> 00000002 d6e297c0 00001000 c012fb7a
> Jul 12 17:01:19 ws188 kernel:        d6e297c0 c01305a5 d6e297c0 00000000 
> d09b22c0 484cc000 00000000 d6e297c0
> Jul 12 17:01:19 ws188 kernel:        c0130c56 d09b22c0 c10acf20 00000000 
> 00001000 00001000 00001000 00000000
> Jul 12 17:01:19 ws188 kernel: Call Trace: [__refile_buffer+84/96] 
> [refile_buffer+10/16] [__block_commit_write+
> 117/192] [generic_commit_write+54/96] [pagebuf_generic_file_write+613/768]
> Jul 12 17:01:19 ws188 kernel: Call Trace: [<c012fb64>] [<c012fb7a>] 
> [<c01305a5>] [<c0130c56>] [<c01cea75>]
> Jul 12 17:01:19 ws188 kernel:    [xfs_write+1032/1808] [linvfs_pb_bmap+0/208] 
> [linvfs_write+812/864] [sys_writ
> e+150/240] [system_call+51/56]
> Jul 12 17:01:19 ws188 kernel:    [<c01d44a8>] [<c01d30b0>] [<c01cfe5c>] 
> [<c012e026>] [<c01089bb>]
> Jul 12 17:01:19 ws188 kernel:
> Jul 12 17:01:19 ws188 kernel: Code: 0f 0b 25 02 60 9e 26 c0 8b 02 85 c0 75 07 
> 89 0a 89 49 24 8b  

        I've seen this type of bug before.  Then, it was an inappropriate
interaction between XFS and fs.h macros.  XFS uses it's pagebuf routines
to perform I/O, and pagebuf allocates it's own buffer headers.  When
certain macros are called, they not only set/reset bits, but they also
remove the bh from one list, and add it to another.  Since these bhs
belong to XFS/pagebuf alone, this leads to problems.  __refile_buffer
does just this sort of action with bhs.  See the macro
'mark_buffer_clean' in linux/include/linux/fs.h for an example.

        If you have the source to the ataraid driver, you want to make sure
that it avoids any calls that eventually call refile_buffer, because
these buffers belong to XFS, and should not appear on any of buffer.c's
LRU lists.

        Hope this helps!

-- 
kernel, n.: A part of an operating system that preserves the
medieval traditions of sorcery and black art.

Danny



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