[#3929] Can not generate a big file(more then 5MB)

Submitted By: Vivi Li

Open Date

2008-02-22 04:15:00 Close Date

2008-03-17 18:50:21

Priority:

Medium Assignee:

Sonic Zhang

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

Category:

N/A Board:

N/A

Processor:

N/A Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

Toolchain version or rev.:

08r1

App binary format:

N/A

Summary: Can not generate a big file(more then 5MB)

Details:

In 08r1 branch, can not generate a big file(more then 5MB) in BF548-EZKIT.

I use default configuration of BF548-EZKIT. It's ok with all other boards.

Here I use command:

dd if=/dev/zero of=/vv bs=1M count=16

It stops at this command.

Below is the log in BF548-EZKIT:

Linux version 2.6.22.18-ADI-2008R1-svn4329 (test@uclinux84-bf548-kernel) (gcc version 4.1.2 (ADI sv8

Hardware Trace Active and Enabled

Reset caused by Software reset

Compiled for ADSP-BF548 Rev 0.0

Blackfin Linux support by blackfin.uclinux.org/

Processor Speed: 525 MHz core clock and 131 MHz System Clock

Board Memory: 64MB

Kernel Managed Memory: 64MB

Memory map:

text = 0x00001000-0x00175510

rodata = 0x00176000-0x001ed6d4

data = 0x001ee000-0x00204000

stack = 0x001ee000-0x001f0000

init = 0x00204000-0x005a0000

bss = 0x005a0000-0x005b15d0

available = 0x005b15d0-0x03dff000

DMA Zone = 0x03e00000-0x04000000

Instruction Cache Enabled

Data Cache Enabled (write-through)

Built 1 zonelists. Total pages: 15748

Kernel command line: root=/dev/mtdblock0 rw ip=10.100.4.50:10.100.4.174:10.100.4.174:255.255.255.0:f

Configuring Blackfin Priority Driven Interrupts

PID hash table entries: 256 (order: 8, 1024 bytes)

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory available: 57076k/65536k RAM, (3696k init code, 1489k kernel code, 640k data, 2048k dma, 584)

Blackfin Scratchpad data SRAM: 4 KB

Blackfin Data A SRAM: 16 KB (15 KB free)

Blackfin Data B SRAM: 16 KB (16 KB free)

Blackfin Instruction SRAM: 48 KB (42 KB free)

Security Framework v1.0.0 initialized

Mount-cache hash table entries: 512

NET: Registered protocol family 16

Blackfin GPIO Controller

Blackfin DMA Controller

ezkit_init(): registering device resources

SCSI subsystem initialized

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 2048 (order: 2, 16384 bytes)

TCP bind hash table entries: 2048 (order: 1, 8192 bytes)

TCP: Hash tables configured (established 2048 bind 2048)

TCP reno registered

io scheduler noop registered

io scheduler anticipatory registered (default)

io scheduler cfq registered

bf54x-lq043: FrameBuffer initializing...

dma_alloc_init: dma_page @ 0x030e3000 - 512 pages at 0x03e00000

bfin-otp: initialized

bfin-wdt: initialized: timeout=20 sec (nowayout=0)

Serial: Blackfin serial driver

bfin-uart.1: ttyBF0 at MMIO 0xffc02000 (irq = 48) is a BFIN-UART

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

smsc911x: Driver version 2007-07-13.

scsi0 : pata-bf54x

ata1: PATA max UDMA/66 cmd 0x00000000 ctl 0xffc03800 bmdma 0x00000000 irq 68

ata1.00: ATA-6: TOSHIBA MK4032GAX, AD101A, max UDMA/100

ata1.00: 78140160 sectors, multi 16: LBA48

ata1.00: configured for UDMA/66

blk_queue_max_hw_segments: set to minimum 1

scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK4032GA AD10 PQ: 0 ANSI: 5

sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB)

sd 0:0:0:0: [sda] Write Protect is off

sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB)

sd 0:0:0:0: [sda] Write Protect is off

sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sda: sda1 sda2

sd 0:0:0:0: [sda] Attached SCSI disk

physmap platform flash device: 00400000 at 20000000

physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank

NOR chip too large to fit in mapping. Attempting to cope...

Intel/Sharp Extended Query Table at 0x010A

Using buffer write method

Using auto-unlock on power-up/resume

cfi_cmdset_0001: Erase suspend on write enabled

Reducing visibility of 32768KiB chip to 4096KiB

RedBoot partition parsing not available

bf5xx-nand bf5xx-nand.0: page_size=256, data_width=8, wr_dly=3, rd_dly=3

NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)

Creating 2 MTD partitions on "NAND 256MiB 3,3V 8-bit":

0x00000000-0x00400000 : "Linux Kernel"

0x00400000-0x10000000 : "File System"

bfin-spi bfin-spi.0: Blackfin BF5xx on-chip SPI Contoller Driver, Version 1.0, regs_base@ffc00500, 4

bfin-spi bfin-spi.1: Blackfin BF5xx on-chip SPI Contoller Driver, Version 1.0, regs_base@ffc02300, 5

input: bf54x-keys as /class/input/input0

bf54x-keys: Blackfin BF54x Keypad registered IRQ 76

rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0

i2c /dev entries driver

i2c-bfin-twi i2c-bfin-twi.1: Blackfin BF5xx on-chip I2C TWI Contoller Driver, Version 1.8, regs_bas0

Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).

ASoC version 0.13.1

AD1980 SoC Audio Codec

asoc: AC97 <-> bf5xx-ac97 mapping ok

ALSA device list:

#0: bf5xx-board (AD1980)

TCP cubic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

rtc-bfin rtc-bfin: setting the system clock to 2004-05-31 19:30:18 (1086031818)

eth0: SMSC911x/921x identified at 0x24000000, IRQ: 175

eth0: SMSC911x MAC Address: de:70:75:56:11:28

eth0: link down

IP-Config: Complete:

device=eth0, addr=10.100.4.50, mask=255.255.255.0, gw=10.100.4.174,

host=BF548, domain=, nis-domain=(none),

bootserver=10.100.4.174, rootserver=10.100.4.174, rootpath=

Freeing unused kernel memory: 3696k freed

eth0: link up, 100Mbps, full-duplex, lpa 0x41E1

_____________________________________

a8888b. / Welcome to the uClinux distribution \

d888888b. / _ _ \

8P"YP"Y88 / | | |_| __ __ (TM) |

8|o||o|88 _____/ | | _ ____ _ _ \ \/ / |

8' .88 \ | | | | _ \| | | | \ / |

8`._.' Y8. \ | |__ | | | | | |_| | / \ |

d/ `8b. \ \____||_|_| |_|\____|/_/\_\ |

dP . Y8b. \ For embedded processors including |

d8:' " `::88b \ the Analog Devices Blackfin /

d8" 'Y88b \___________________________________/

:8P ' :888

8a. : _a88P For further information, check out:

._/"Yaa_: .| 88P| - blackfin.uclinux.org/

\ YP" `| 8P `. - docs.blackfin.uclinux.org/

/ \.___.d| .' - www.uclinux.org/

`--..__)8888P`._.' jgs/a:f - www.analog.com/blackfin

Have a lot of fun...

BusyBox v1.4.1 (2008-02-22 16:53:51 CST) Built-in shell (msh)

Enter 'help' for a list of built-in commands.

root:/> mount

rootfs on / type rootfs (rw)

proc on /proc type proc (rw)

ramfs on /var type ramfs (rw)

sysfs on /sys type sysfs (rw)

devpts on /dev/pts type devpts (rw)

debugfs on /sys/kernel/debug type debugfs (rw)

securityfs on /sys/kernel/security type securityfs (rw)

root:/> free

total used free shared buffers

Mem: 60772 12752 48020 0 0

root:/> dd if=/dev/zero of=vv bs=1M count=16

I can telnet to the board and check the info there.

Here is the log:

test@uclinux84-bf548-kernel:~> telnet 10.100.4.50

Trying 10.100.4.50...

Connected to 10.100.4.50.

Escape character is '^]'.

BusyBox v1.4.1 (2008-02-22 16:53:51 CST) Built-in shell (msh)

Enter 'help' for a list of built-in commands.

root:/> ps ax

PID Uid VSZ Stat Command

1 root 104 S /init

2 root SW< [kthreadd]

3 root SWN [ksoftirqd/0]

4 root SW< [events/0]

5 root SW< [khelper]

33 root SW< [kblockd/0]

34 root SW< [ata/0]

35 root SW< [ata_aux]

46 root SW [pdflush]

47 root DW [pdflush]

48 root SW< [kswapd0]

49 root SW< [aio/0]

50 root SW< [cifsoplockd]

51 root SW< [cifsdnotifyd]

85 root SW< [scsi_eh_0]

93 root SW< [mtdblockd]

109 root SW< [bfin-spi.0]

112 root SW< [bfin-spi.1]

149 root 40 S inetd

152 root 576 S -/bin/sh

153 root 32 S /bin/watchdogd -f -s

154 root 476 S /sbin/syslogd -n

155 root 476 S /sbin/klogd -n

157 root 1504 D dd if=/dev/zero of=/vv bs=1M count=16

158 root 56 S /bin/telnetd

159 root 576 S sh

160 root 480 R ps ax

root:/> free

total used free shared buffers

Mem: 60772 20820 39952 0 0

root:/> ls -lh vv

-rw-r--r-- 1 root root 4.7M May 31 19:30 vv

root:/>

Follow-ups

--- Michael Hennerich 2008-02-22 07:03:02

Same issue as:

[#3850] rcp, ftpd, USB Mass storage not working

-Michael

--- Michael Hennerich 2008-02-22 10:58:33

Obviously the limit pagecache patch is causing this problem.

Introduced between svn rev. 2973:2974

Sonic,

please assign to someone else.

-Michael

--- Michael Hennerich 2008-02-22 11:49:54

There was a follow up patch posted here:

lkml.org/lkml/2007/1/17/96

Maybe this one works better

--- Sonic Zhang 2008-02-25 02:07:17

This bug is not against bf548 only. The default pagecache_ratio on bf548 is set

to 20%, while it is 100% on all other boards.

In this case, if you set pagecache_ratio to be less than 41%(about 23M of 55M

total memory) on bf537, following command blocks. This is because the VFS cache

pages asked by dd exceeds the limiation (23M).

dd if=/dev/zero of=/vv bs=1M count=16

This looks not a bug. It is just caused by the limitation of NOMMU arch.

--- Sonic Zhang 2008-02-25 02:11:14

A fixed cachepage_ratio value may not fit all kinds of application. How about

remove the default 20% in bf548 and ask user to set it when they want to run

fsck.ext2 and mplayer?

--- Mike Frysinger 2008-02-25 13:18:40

while that is worth looking into separately, pagecache limiting should not cause

indefinite blocking of any application. if it does, then it's broken.

--- Michael Hennerich 2008-02-25 16:18:29

I’m pretty sure the limit pagecache support is not longer working correctly.

It prevents memory allocations to fail. It should just operate on file cache

pages.

See below how this should work.

As a side note – we’re not using this patch described below – we’re

using an initial try done by Aubrey and Roy.

Maybe we should implement Vaidyanathan approach.

lkml.org/lkml/2007/1/17/96

"Hi Roy,

I have added a different pagecache reclaim logic around your

sysctl interface. This would ensure that only pagecache pages are

reclaimed if the limit is exceeded.

--Vaidy

Pagecache pages in memory can be limited to a percentage of total

RAM using this patch.

New sysctl entry /proc/sys/vm/pagecache_ratio has been added that

holds the total percentage of RAM that the user wants as pagecache.

The default percentage is 90.

Depending on the work load, any percentage value can be set to derive

optimum overall performance. Minimum is 5 and max is 100.

balance_pagecache() routine is called on file backed access and the

current pagecache_limit is checked against utilisation.

If the limit is exceeded, then shrink_all_pagecache_memory() is

called that will walk the LRU list and remove unmapped pagecache

pages. New scancontrol fields have been added to make decisions

in shrink_page_list() and shrink_active_list().

Pages counted under pagecache limit are file pages that are not mapped.

Shared memory is mapped and not counted in the limit.

Test:

echo 40 > /proc/sys/vm/pagecache_ratio

(that is around 400MB on a 1GB RAM machine)

dd if=/dev/zero of=/tmp/foo bs=1M count=1024

cat /proc/meminfo

The "Cached: xxx" count should hit the set limit and not consume all

available memory.

Any feedback is appreciated."

--- Robin Getz 2008-02-25 23:41:48

Michael:

I don't think it is necessary to post this in every bug report?

Sonic:

I think this needs to get fixed. It is not just mplayer and fsck - but every

person/application who will soon be using large MMC & USB & PATA &

NAND file systems in real world systems. We enabled this - now we need to make

sure it is stable in all conditions. Right now, it is not.

-Robin

--- Robin Getz 2008-02-25 23:46:02

Sonic:

You wrote:

>This looks not a bug. It is just caused by the limitation of NOMMU arch.

This is a bug - if the page cache limit is hit - the VFS should write out to

the disk - and free something up - not hang. This is a bug of the page cache

limiting code - it looks like it was not updated to the latest kernel version

properly.

-Robin

--- Sonic Zhang 2008-02-26 04:27:40

Fixed.

--- Vivi Li 2008-03-03 02:44:41

root:/> cat /proc/sys/vm/pagecache_ratio

root:/> cat /proc/meminfo

MemTotal: 60700 kB

MemFree: 47988 kB

Buffers: 0 kB

Cached: 7792 kB

SwapCached: 0 kB

Active: 1488 kB

Inactive: 6304 kB

SwapTotal: 0 kB

SwapFree: 0 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages: 0 kB

Mapped: 0 kB

Slab: 2220 kB

SReclaimable: 1428 kB

SUnreclaim: 792 kB

PageTables: 0 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

CommitLimit: 30348 kB

Committed_AS: 0 kB

VmallocTotal: 0 kB

VmallocUsed: 0 kB

VmallocChunk: 0 kB

root:/> free

total used free shared buffers

Mem: 60700 12712 47988 0 0

root:/> time dd if=/dev/zero of=/5M.bin bs=1M count=5

dd: page allocation failure. order:0, mode:0xa00d2

Hardware Trace:

0 Target : <0x00004740> { _dump_stack + 0x0 }

Source : <0x0002cb52> { ___alloc_pages + 0x186 }

1 Target : <0x0002cb52> { ___alloc_pages + 0x186 }

Source : <0x0000ce12> { _printk + 0x16 }

2 Target : <0x0000ce0e> { _printk + 0x12 }

Source : <0x0000ccc4> { _vprintk + 0x1b8 }

3 Target : <0x0000ccb8> { _vprintk + 0x1ac }

Source : <0xffa00c82> { __common_int_entry + 0xca }

4 Target : <0xffa00c20> { __common_int_entry + 0x68 }

Source : <0xffa00a60> { _return_from_int + 0x58 }

5 Target : <0xffa00a60> { _return_from_int + 0x58 }

Source : <0xffa00a36> { _return_from_int + 0x2e }

6 Target : <0xffa00a08> { _return_from_int + 0x0 }

Source : <0xffa00c1c> { __common_int_entry + 0x64 }

7 Target : <0xffa00c1a> { __common_int_entry + 0x62 }

Source : <0xffa003a0> { _asm_do_IRQ + 0x68 }

8 Target : <0xffa00398> { _asm_do_IRQ + 0x60 }

Source : <0x00010f02> { __local_bh_enable + 0x3e }

9 Target : <0x00010ec4> { __local_bh_enable + 0x0 }

Source : <0x0001100c> { ___do_softirq + 0x94 }

10 Target : <0x00011004> { ___do_softirq + 0x8c }

Source : <0x00010fe4> { ___do_softirq + 0x6c }

11 Target : <0x00010fd8> { ___do_softirq + 0x60 }

Source : <0x00013de0> { _run_timer_softirq + 0x84 }

12 Target : <0x00013d70> { _run_timer_softirq + 0x14 }

Source : <0x0001ed54> { _hrtimer_run_queues + 0xc8 }

13 Target : <0x0001ed24> { _hrtimer_run_queues + 0x98 }

Source : <0x0001ed1a> { _hrtimer_run_queues + 0x8e }

14 Target : <0x0001ed0c> { _hrtimer_run_queues + 0x80 }

Source : <0x0001ed4a> { _hrtimer_run_queues + 0xbe }

15 Target : <0x0001ed44> { _hrtimer_run_queues + 0xb8 }

Source : <0x0001ed10> { _hrtimer_run_queues + 0x84 }

Stack from 0022dc58:

00080000 0002cb56 002085f0 00080000 000a00d2 03d854cc 00000000

000a00d2

0002ec68 002085ec 005e4aa0 000a00d2 00000000 00000000 000004b1

034b2004

0002a11c 00673f14 00000000 00000000 000004b2 00000000 00001000

0004e000

9aca0000 00000008 002085e8 00001000 00001000 00000001 00001000

03a719e0

00189a94 00673e80 000b2000 00000100 00001000 0022de9c 0000000a

00000000

005e4980 005e49a0 005e49c0 005e49e0 005e4a00 005e4a20 005e4a40

005e4a60

Call Trace:

[<0002a5ae>] ___generic_file_aio_write_nolock+0x1e2/0x3a0

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<0022de14>] _alloc_large_system_hash+0xc8/0x2b4

[<0022de5c>] _alloc_large_system_hash+0x110/0x2b4

[<0004e000>] ___writeback_single_inode+0xa4/0x2bc

[<000b2000>] _blk_queue_make_request+0x3c/0xb4

[<00032000>] _do_munmap+0x48/0x10c

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<0002a7c0>] _generic_file_aio_write+0x54/0xe4

[<0022de14>] _alloc_large_system_hash+0xc8/0x2b4

[<0022de9c>] _alloc_large_system_hash+0x150/0x2b4

[<0022de14>] _alloc_large_system_hash+0xc8/0x2b4

[<0022de9c>] _alloc_large_system_hash+0x150/0x2b4

[<0022de5c>] _alloc_large_system_hash+0x110/0x2b4

[<000c7d82>] _read_zero+0x2a/0x40

[<00036234>] _do_sync_write+0xac/0xe4

[<0022def0>] _alloc_large_system_hash+0x1a4/0x2b4

[<0022de14>] _alloc_large_system_hash+0xc8/0x2b4

[<0022de9c>] _alloc_large_system_hash+0x150/0x2b4

[<0001caf0>] _autoremove_wake_function+0x0/0x30

[<0022de54>] _alloc_large_system_hash+0x108/0x2b4

[<00001000>] _run_init_process+0x0/0x18

[<00032000>] _do_munmap+0x48/0x10c

[<00001000>] _run_init_process+0x0/0x18

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<000c7d86>] _read_zero+0x2e/0x40

[<00036aee>] _vfs_read+0xce/0xfc

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<000369a6>] _vfs_write+0x82/0xfc

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<0022def0>] _alloc_large_system_hash+0x1a4/0x2b4

[<0003502a>] _do_sys_open+0x92/0xac

[<0022def0>] _alloc_large_system_hash+0x1a4/0x2b4

[<00036e2a>] _sys_write+0x32/0x64

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<00035048>] _sys_open+0x0/0x24

[<0022def0>] _alloc_large_system_hash+0x1a4/0x2b4

[<00036df8>] _sys_write+0x0/0x64

[<00008000>] _bfin_demux_gpio_irq+0x54/0x94

[<00002000>] _get_sclk+0x4/0x58

[<0022e000>] ___free_pages_bootmem+0x0/0x34

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

Mem-info:

DMA per-cpu:

CPU 0: Hot: hi: 18, btch: 3 usd: 2 Cold: hi: 6, btch: 1 usd:

Active:372 inactive:2768 dirty:0 writeback:0 unstable:0

free:10152 slab:558 mapped:0 pagetables:0 bounce:0

DMA free:40608kB min:1000kB low:1248kB high:1500kB active:1488kB

inactive:11072kB present:62992kB po

lowmem_reserve[]: 0 0

DMA: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 0*256kB 1*512kB 1*1024kB 1*2048kB

1*4096kB 0*8192kB 2B

15871 pages of RAM

10185 free pages

696 reserved pages

10 pages shared

0 pages swap cached

...

root:/> free

total used free shared buffers

Mem: 60700 17536 43164 0 0

root:/> cat /proc/meminfo

MemTotal: 60700 kB

MemFree: 43164 kB

Buffers: 0 kB

Cached: 12600 kB

SwapCached: 0 kB

Active: 1492 kB

Inactive: 11108 kB

SwapTotal: 0 kB

SwapFree: 0 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages: 0 kB

Mapped: 0 kB

Slab: 2232 kB

SReclaimable: 1432 kB

SUnreclaim: 800 kB

PageTables: 0 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

CommitLimit: 30348 kB

Committed_AS: 0 kB

VmallocTotal: 0 kB

VmallocUsed: 0 kB

VmallocChunk: 0 kB

root:/> ls -lh 5M.bin

-rw-r--r-- 1 root root 4.7M Jan 13 23:12 5M.bin

root:/>

--- Sonic Zhang 2008-03-12 05:13:28

Finally, I found this is not a real bug as described. Our default file system is

ram and VFS backed. All files are created in VFS cache. That means the value

pagecache_ratio controls the size of this file system. If we set it to 20%, the

totol memory is 56M and initial FS size is 6M, the available space to create new

file is only 55M x 20% - 6M = 5M.

Anyway, there is improvement space in the pagecache limit patch to drop page

cache when the limit is met. But, this doesn't help to this bug. I added this

improvement in the kernel.

--- Robin Getz 2008-03-12 09:31:27

OK - that makes sense - when page cache is limited, and we fill initfs file

system, we get an error - but shouldn't we get "disk full" error - not

a OOM?

& I would also expect this not to occur on creating a nMeg file on

/dev/sda1?

-Robin

--- Yi Li 2008-03-14 05:33:00

Documents/filesystem/ramfs-rootfs-initramfs.txt reads that:

ramfs is based on page cache/dentry cache. and "One downside of ramfs is

you can keep writing data into it until you fill up all memory, and the VM can't

free it because the VM thinks that files should get written to backing store

(rather than swap space), but ramfs hasn't got any backing store." And

tmpfs add size limit.

But I am not sure whether tmpfs can be used as initramfs.

--- Mike Frysinger 2008-03-17 18:50:21

using ramfs for / is fine ... dont fill it up

pagecache is no longer in the tree

Files

Changes

Commits

Dependencies

Duplicates

Associations