Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*latest\s+\-git\:\s+kernel\s+BUG\s+at\s+fs\/xfs\/support\/debug\.c\:54\!\s*$/: 15 ]

Total 15 documents matching your query.

1. latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author:
Date: Thu, 17 Jul 2008 19:46:42 +0200
I got this with an intentionally corrupted filesystem: Filesystem "loop1": Disabling barriers, not supported by the underlying device XFS mounting filesystem loop1 Ending clean XFS mount for filesys
/archives/xfs/2008-07/msg00261.html (11,625 bytes)

2. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author:
Date: Thu, 17 Jul 2008 21:18:59 +0200
Thanks, you are right. I have adjusted my configuration, but I am still able to produce this: BUG: unable to handle kernel paging request at b62a66e0 IP: [<c030ef88>] xfs_alloc_fix_freelist+0x28/0x49
/archives/xfs/2008-07/msg00262.html (13,341 bytes)

3. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author:
Date: Thu, 17 Jul 2008 21:29:39 +0200
FWIW, this is fs/xfs/xfs_alloc.c:1817: if (!pag->pagf_init) { Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest
/archives/xfs/2008-07/msg00263.html (10,250 bytes)

4. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author:
Date: Fri, 18 Jul 2008 08:40:12 +1000
Which kind of implies that we've got a bogus fsbno that we're using as the basis of allocation..... What is the corruption you are inducing? Can you produce a xfs_metadump image of the filesystem and
/archives/xfs/2008-07/msg00265.html (10,290 bytes)

5. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author:
Date: Sat, 19 Jul 2008 15:16:03 +0200
The method of corruption is quite crude (but efficient); just flip a number of bits at random before mounting. I got a different crash (NULL pointer) now, and I have a reproducible case with a full d
/archives/xfs/2008-07/msg00272.html (13,668 bytes)

6. latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: xxxxxx>
Date: Thu, 17 Jul 2008 19:46:42 +0200
I got this with an intentionally corrupted filesystem: Filesystem "loop1": Disabling barriers, not supported by the underlying device XFS mounting filesystem loop1 Ending clean XFS mount for filesys
/archives/xfs/2008-07/msg00884.html (11,625 bytes)

7. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: xxxxxx>
Date: Thu, 17 Jul 2008 21:18:59 +0200
Thanks, you are right. I have adjusted my configuration, but I am still able to produce this: BUG: unable to handle kernel paging request at b62a66e0 IP: [<c030ef88>] xfs_alloc_fix_freelist+0x28/0x49
/archives/xfs/2008-07/msg00885.html (13,341 bytes)

8. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: xxxxxx>
Date: Thu, 17 Jul 2008 21:29:39 +0200
FWIW, this is fs/xfs/xfs_alloc.c:1817: if (!pag->pagf_init) { Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest
/archives/xfs/2008-07/msg00886.html (10,250 bytes)

9. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: xxxxxx>
Date: Fri, 18 Jul 2008 08:40:12 +1000
Which kind of implies that we've got a bogus fsbno that we're using as the basis of allocation..... What is the corruption you are inducing? Can you produce a xfs_metadump image of the filesystem and
/archives/xfs/2008-07/msg00888.html (10,290 bytes)

10. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: xxxxxx>
Date: Sat, 19 Jul 2008 15:16:03 +0200
The method of corruption is quite crude (but efficient); just flip a number of bits at random before mounting. I got a different crash (NULL pointer) now, and I have a reproducible case with a full d
/archives/xfs/2008-07/msg00895.html (13,668 bytes)

11. latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: "Vegard Nossum" <vegard.nossum@xxxxxxxxx>
Date: Thu, 17 Jul 2008 19:46:42 +0200
Hi, I got this with an intentionally corrupted filesystem: Filesystem "loop1": Disabling barriers, not supported by the underlying device XFS mounting filesystem loop1 Ending clean XFS mount for file
/archives/xfs/2008-07/msg01507.html (11,625 bytes)

12. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: "Vegard Nossum" <vegard.nossum@xxxxxxxxx>
Date: Thu, 17 Jul 2008 21:18:59 +0200
Thanks, you are right. I have adjusted my configuration, but I am still able to produce this: BUG: unable to handle kernel paging request at b62a66e0 IP: [<c030ef88>] xfs_alloc_fix_freelist+0x28/0x49
/archives/xfs/2008-07/msg01508.html (13,512 bytes)

13. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: "Vegard Nossum" <vegard.nossum@xxxxxxxxx>
Date: Thu, 17 Jul 2008 21:29:39 +0200
FWIW, this is fs/xfs/xfs_alloc.c:1817: if (!pag->pagf_init) { Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest
/archives/xfs/2008-07/msg01509.html (10,458 bytes)

14. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 18 Jul 2008 08:40:12 +1000
Which kind of implies that we've got a bogus fsbno that we're using as the basis of allocation..... What is the corruption you are inducing? Can you produce a xfs_metadump image of the filesystem and
/archives/xfs/2008-07/msg01511.html (10,550 bytes)

15. Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! (score: 1)
Author: "Vegard Nossum" <vegard.nossum@xxxxxxxxx>
Date: Sat, 19 Jul 2008 15:16:03 +0200
The method of corruption is quite crude (but efficient); just flip a number of bits at random before mounting. I got a different crash (NULL pointer) now, and I have a reproducible case with a full d
/archives/xfs/2008-07/msg01518.html (14,007 bytes)

Current List: 1 - 15
Page: [1]
This search system is powered by Namazu