headers
Sachin Sant | 16 Mar 2009 08:10
Picon

[BUG/JFS/2.6.29-rc8] kernel BUG at fs/mpage.c:473!

While running file system stress (fsstress) on a JFS partition
with 2.6.29-rc8, i hit the following BUG.

------------[ cut here ]------------
kernel BUG at fs/mpage.c:473!
cpu 0x0: Vector: 700 (Program Check) at [c0000000be9daba0]
    pc: c00000000014e3a0: .__mpage_writepage+0xd0/0x630
    lr: c0000000000dfedc: .write_cache_pages+0x288/0x42c
    sp: c0000000be9dae20
   msr: 8000000000029032
  current = 0xc00000003f30dd10
  paca    = 0xc000000000753400
    pid   = 27402, comm = fsstress
kernel BUG at fs/mpage.c:473!
enter ? for help
[c0000000be9db3a0] c0000000000dfedc .write_cache_pages+0x288/0x42c
[c0000000be9db530] c00000000014e298 .mpage_writepages+0x54/0x8c
[c0000000be9db5d0] d0000000032f1720 .jfs_writepages+0x1c/0x34 [jfs]
[c0000000be9db650] c0000000000e0120 .do_writepages+0x68/0xa4
[c0000000be9db6d0] c0000000000d764c .__filemap_fdatawrite_range+0x8c/0xbc
[c0000000be9db7c0] c0000000000d76bc .filemap_write_and_wait_range+0x40/0x8c
[c0000000be9db860] c0000000000d79f4 .generic_file_buffered_write+0x2ec/0x358
[c0000000be9db9a0] c0000000000d7f88
.__generic_file_aio_write_nolock+0x300/0x3ec
[c0000000be9dbaa0] c0000000000d8390 .generic_file_aio_write+0x80/0x114
[c0000000be9dbb60] c000000000118a24 .do_sync_write+0xc4/0x124
[c0000000be9dbcf0] c00000000011959c .vfs_write+0xd8/0x1a4
[c0000000be9dbd90] c000000000119768 .SyS_write+0x50/0x90
[c0000000be9dbe30] c000000000008534 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff0d8c8
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Kleikamp | 17 Mar 2009 15:21
Picon

Re: [BUG/JFS/2.6.29-rc8] kernel BUG at fs/mpage.c:473!

On Mon, 2009-03-16 at 12:40 +0530, Sachin Sant wrote:
> While running file system stress (fsstress) on a JFS partition
> with 2.6.29-rc8, i hit the following BUG.

I tried reproducing this yesterday, but was unsuccessful.  Maybe I
didn't let it run long enough.  Have you run this successfully on
earlier kernels?  If so, what was the most recent that worked for you.
Have you seen it more than once?  I'm not sure how easy it is to
reproduce.

Thanks,
Shaggy

> ------------[ cut here ]------------
> kernel BUG at fs/mpage.c:473!
> cpu 0x0: Vector: 700 (Program Check) at [c0000000be9daba0]
>     pc: c00000000014e3a0: .__mpage_writepage+0xd0/0x630
>     lr: c0000000000dfedc: .write_cache_pages+0x288/0x42c
>     sp: c0000000be9dae20
>    msr: 8000000000029032
>   current = 0xc00000003f30dd10
>   paca    = 0xc000000000753400
>     pid   = 27402, comm = fsstress
> kernel BUG at fs/mpage.c:473!
> enter ? for help
> [c0000000be9db3a0] c0000000000dfedc .write_cache_pages+0x288/0x42c
> [c0000000be9db530] c00000000014e298 .mpage_writepages+0x54/0x8c
> [c0000000be9db5d0] d0000000032f1720 .jfs_writepages+0x1c/0x34 [jfs]
> [c0000000be9db650] c0000000000e0120 .do_writepages+0x68/0xa4
> [c0000000be9db6d0] c0000000000d764c .__filemap_fdatawrite_range+0x8c/0xbc
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sachin Sant | 18 Mar 2009 06:29
Picon

Re: [BUG/JFS/2.6.29-rc8] kernel BUG at fs/mpage.c:473!

Dave Kleikamp wrote:
> On Mon, 2009-03-16 at 12:40 +0530, Sachin Sant wrote:
>   
>> While running file system stress (fsstress) on a JFS partition
>> with 2.6.29-rc8, i hit the following BUG.
>>     
>
> I tried reproducing this yesterday, but was unsuccessful.  Maybe I
> didn't let it run long enough.  Have you run this successfully on
> earlier kernels?  If so, what was the most recent that worked for you.
> Have you seen it more than once?  I'm not sure how easy it is to
> reproduce.
I haven't tried to test with earlier kernels. This was the first
time i ran these tests on this particular box.I run the fsstress
on different type of file systems one after the another (in no
particular order ). Something like ..

* create ext2 filesystem on a device
* run fsstress.
* unmount the device.

I repeat the above steps with ext3, reiserfs and jfs. May be this
combination is causing this problem.

I have seen this problem on two partitions of a power box. Same problem
seem to have been reported earlier against 2.6.25-rcx kernel.

http://lkml.indiana.edu/hypermail/linux/kernel/0803.2/1418.html

Thanks
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Kujau | 18 Mar 2009 11:05
Picon

Re: [BUG/JFS/2.6.29-rc8] kernel BUG at fs/mpage.c:473!

On Mon, 16 Mar 2009, Sachin Sant wrote:
> autorun: reading command 85 /usr/local/autobench/scripts/autobench.dat
> autorun: run test fsstress -d $scratchdir -l $iterations: command read
> autorun: run test fsstress -d /mnt/tmp -l 1: was expanded
> 03/15/2009-19:36:37 processing command: (1) 'run test fsstress -d /mnt/tmp -l 1'

How many iterations were really run to hit this BUG? When I specify "-l 
1", fsstress[0] comes back instantly (and no error of course)...

Thanks,
Christian.

[0] http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/fs/fsstress/
--

-- 
Bruce Schneier's passphrase is used to etch diamonds

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Permalink | Reply | 0 comments |
headers
Sachin Sant | 19 Mar 2009 07:33
Picon

Re: [BUG/JFS/2.6.29-rc8] kernel BUG at fs/mpage.c:473!

Christian Kujau wrote:
> On Mon, 16 Mar 2009, Sachin Sant wrote:
>   
>> autorun: reading command 85 /usr/local/autobench/scripts/autobench.dat
>> autorun: run test fsstress -d $scratchdir -l $iterations: command read
>> autorun: run test fsstress -d /mnt/tmp -l 1: was expanded
>> 03/15/2009-19:36:37 processing command: (1) 'run test fsstress -d /mnt/tmp -l 1'
>>     
>
> How many iterations were really run to hit this BUG? When I specify "-l 
> 1", fsstress[0] comes back instantly (and no error of course)...
>   
Sorry for the late reply. Somehow i missed this mail.

Yeah with default option values fsstress completes in a jiffy. I generally
invoke fsstress with 1000 operations per process (-n 1000) and 1000
processes (-p 1000).

fsstress -d /mnt/tmp -l 1 -n 1000 -p 1000

Thanks
-Sachin

--

-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Kujau | 20 Mar 2009 02:50
Picon

Re: [BUG/JFS/2.6.29-rc8] kernel BUG at fs/mpage.c:473!

On Thu, 19 Mar 2009, Sachin Sant wrote:
> Yeah with default option values fsstress completes in a jiffy. I generally
> invoke fsstress with 1000 operations per process (-n 1000) and 1000
> processes (-p 1000).

Ah! I was curious if I could reproduce this on amd64 and started 
with 100, 1000, 10000 *iterations* (-l), will try with -n/-p now...

Thanks,
Christian.
--

-- 
My firewall cannot block www.schneier.com.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Permalink | Reply | 0 comments |
headers
Christian Kujau | 20 Mar 2009 03:13
Picon

BUG at /fs/jfs/jfs_txnmgr.c:940

Hi there,

While playing around with fsstress[0] I've received the trace below when 
starting fsstress with 1000 ops/process and 1000 process. Sachin Sant 
reported an fsstress-triggered problem in [1], but as my somehwat 
different, I'll open a new list thread.

Full dmesg and .config: http://nerdbynature.de/bits/2.6.29-rc8/

Btw, in the trace below it says:

  last sysfs file: /sys/devices/system/clocksource/clocksource0/current_clocksource

Indeed, I've set the clocksource to "acpi_pm", as tsc (default) and hpet 
made the clock go too slow (it's a Xen DomU).

Thanks,
Christian.

[0] http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/fs/fsstress/
[1] http://lkml.org/lkml/2009/3/16/25

[334518.774623] BUG: Bad page state in process fsstress  pfn:0428b
[334518.775347] page:ffffe200000e8e68 flags:0100000000000808 count:0 mapcount:0
mapping:ffff88000752ece8 index:6c00f
[334518.776631] Pid: 32266, comm: fsstress Not tainted 2.6.29-rc8 #2
[334518.777244] Call Trace:
[334518.777689]  [<ffffffff802943e9>] bad_page+0x102/0x113
[334518.778339]  [<ffffffffa024df5d>] diWrite+0x449/0x45a [jfs]
[334518.778963]  [<ffffffff802987c9>] pagevec_lookup_tag+0x1a/0x21
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sandon Van Ness | 21 Mar 2009 12:43

jfscommit high CPU usage when writing large files.

I really like JFS and have been using it on all my systems for the last 
couple years but I only have a single issue with it which is when I am 
doing large file writes (30GB+ files) jfscommit will start using 100% 
cpu and my write speed will continuously decrease as time goes on.

Here is a post I made which goes a bit more into the details.

http://www.dslreports.com/forum/r20737283-weird-JFS-behavior

Its reproduce able but doesn't seem to occur as frequently or soon on 
recently booted system. I have also seen this issue occur on a 
completely different system as well. I don't know if this matters but 
both systems I see this behavior on have file-systems over 5TB. Anyone 
have an idea what might be causing it?

This isn't that big of a deal for me since Its very rare that I need to 
write files that large (usually only doing when dumps of my smaller 
partitions but I would like to know whats causing it.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Permalink | Reply | 1 comment |
headers
Mr. Peter Wong | 23 Mar 2009 00:24

Take comfort

ATTENTION

An iraqi made a fixed deposit of 44.5m- usd in my
bank branch and he dead with his entire family leaving
behind no next of kin,am ready to share 50/50 with you if
you choose to stand as my deceased client next of kin.

Pls indicate by sending the following below to
show your interest.

1.YOUR NAME 
2.YOUR RESIDENT ADDRESS 
3.YOUR OCCUPATION 
4.YOUR PHONE NUMBER 
5.DATE OF BIRTH 
6.COUNTRY OF RESIDENT

Your response with the requested information
should be sent to reach me at 
my personal email address below: 
wngpeter <at> yahoo.com-.hk-

Yours Truly,
Mr. Peter Wong.

____________________________________________________________

The following appeared on Boston.com:
Headline: Take comfort
Date:     Mar 22, 2009
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Kujau | 23 Mar 2009 11:20
Picon

Re: jfscommit high CPU usage when writing large files.

On Sat, 21 Mar 2009, Sandon Van Ness wrote:
> I really like JFS and have been using it on all my systems for the last 
> couple years but I only have a single issue with it which is when I am 
> doing large file writes (30GB+ files) jfscommit will start using 100% 

Out of curiosity (and no offense to JFS, as I'm using it too), but when I 
hear "large, contiguous files" I seem to remember that XFS is
believed to excel on this particular usecase.

> This isn't that big of a deal for me since Its very rare that I need to 
> write files that large (usually only doing when dumps of my smaller 
> partitions but I would like to know whats causing it.

Not really an answer to your question, but this came up last year on this 
list as well, but as it wasn't as easily reproducible as in your case, 
there wasn't much of an outcome:

  http://kerneltrap.org/mailarchive/linux-kernel/2008/5/20/1883444

Christian.
--

-- 
Albert Einstein wears Bruce Schneier pajamas

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
(Continue reading)

Permalink | Reply | 0 comments |

Gmane