What's new

Asuswrt-Merlin 378.54_2 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I have used minidlna on my nas running debian for maybe 5 years now.
Not once has it ever missed a beat.
I have not used it on my Asus router yet, not plan to.
Do you have example files that crash the scanner?

Any corrupted/incomplete/damaged file runs a risk of causing it to crash.

I don't have a specific example at hand, but it's happened quite frequently in the past with various users, as some people download a bunch of files, not always making sure these files are intact.
 
I solved the DLNA problem on 378.55 alpha 2
I replaced dlna from 378.55 with dlna from 378.4850 and compiled the merlin firmware.

DLNA is working fine but there is a new problem.
378.55 have some ram usage problem.It always use more than 80% of ram.
I checked the processes and ALL processes use more ram than it should.

The firmware was working fine while i tested... but there is something wrong with the ram.

If anyone want's to try it, here it is: https://dl.dropboxusercontent.com/u/20895408/RT-AC68U_378.55_DLNA_OK.zip
That is a problem with me and I haven't touched DLNA. My RAM usage is now upside-down. Instead of using ~28% RAM with my configuration it is now consuming 202MB's with only 19% free. Something is amiss. Going back to 378.54_2.

EDIT: Reverting to 378.54_2 fixed this issue. RAM usage is now at 62MB's or 25%.
 
Last edited:
I noticed that when I'm operating Transmission using its web UI, the kernel goes into some sort of "panic" mode and kill almost all processes. However, when that happened, there are still a lot of free space in the swap file.

Below is the log when this happen,
Code:
Jun 25 12:20:20 kernel: lighttpd invoked oom-killer: gfp_mask=0xd0, order=1, oomkilladj=0
Jun 25 12:20:20 kernel: Call Trace:
Jun 25 12:20:20 kernel: [<8000f42c>] dump_stack+0x8/0x34
Jun 25 12:20:20 kernel: [<80057528>] out_of_memory+0x1fc/0x264
Jun 25 12:20:20 kernel: [<8005939c>] __alloc_pages+0x318/0x360
Jun 25 12:20:20 kernel: [<80079674>] cache_alloc_refill+0x310/0x6b0
Jun 25 12:20:20 kernel: [<8007935c>] kmem_cache_alloc+0xb4/0xbc
Jun 25 12:20:20 kernel: [<8018c040>] sk_alloc+0x38/0x160
Jun 25 12:20:20 kernel: [<80207570>] inet_create+0x14c/0x378
Jun 25 12:20:20 kernel: [<8018a2ac>] __sock_create+0xf4/0x260
Jun 25 12:20:20 kernel: [<8018a448>] sock_create+0x10/0x1c
Jun 25 12:20:21 kernel: Normal per-cpu:
Jun 25 12:20:21 kernel: CPU  0: Hot: hi:  186, btch:  31 usd:  9  Cold: hi:  62, btch:  15 usd:  55
Jun 25 12:20:21 kernel: HighMem per-cpu:
Jun 25 12:20:21 kernel: CPU  0: Hot: hi:  186, btch:  31 usd:  95  Cold: hi:  62, btch:  15 usd:  6
Jun 25 12:20:21 kernel: Active:26736 inactive:12875 dirty:0 writeback:0 unstable:0
Jun 25 12:20:21 kernel:  free:2185 slab:5972 mapped:3007 pagetables:184 bounce:0
Jun 25 12:20:21 kernel: Normal free:2816kB min:2884kB low:3604kB high:4324kB active:20376kB inactive:20256kB present:520192kB pages_scanned:64954 all_unreclaimable? yes
Jun 25 12:20:21 kernel: lowmem_reserve[]: 0 14224
Jun 25 12:20:21 kernel: HighMem free:5924kB min:512kB low:3032kB high:5556kB active:86568kB inactive:31244kB present:1820672kB pages_scanned:0 all_unreclaimable? no
Jun 25 12:20:21 kernel: lowmem_reserve[]: 0 0
Jun 25 12:20:21 kernel: Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2816kB
Jun 25 12:20:21 kernel: HighMem: 365*4kB 170*8kB 98*16kB 36*32kB 0*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5924kB
Jun 25 12:20:21 kernel: Swap cache: add 4921, delete 4865, find 162/281, race 0+0
Jun 25 12:20:21 kernel: Free swap  = 2079872kB
Jun 25 12:20:21 kernel: Total swap = 2097136kB
Jun 25 12:20:21 kernel: Free swap:  2079872kB
Jun 25 12:20:21 kernel: 589823 pages of RAM
Jun 25 12:20:21 kernel: 458751 pages of HIGHMEM
Jun 25 12:20:21 kernel: 529905 reserved pages
Jun 25 12:20:21 kernel: 17347 pages shared
Jun 25 12:20:21 kernel: 56 pages swap cached
Jun 25 12:20:22 kernel: Out of memory: kill process 982 (flexget) score 1402 or a child
Jun 25 12:20:22 kernel: Killed process 982 (flexget)
Jun 25 12:20:22 kernel: ot 5 points
Jun 25 12:20:22 kernel: lighttpd invoked oom-killer: gfp_mask=0xd0, order=1, oomkilladj=0
Jun 25 12:20:22 kernel: Call Trace:
Jun 25 12:20:22 kernel: [<8000f42c>] dump_stack+0x8/0x34
Jun 25 12:20:22 kernel: [<80057528>] out_of_memory+0x1fc/0x264
Jun 25 12:20:22 kernel: [<8005939c>] __alloc_pages+0x318/0x360
Jun 25 12:20:22 kernel: [<80079674>] cache_alloc_refill+0x310/0x6b0
Jun 25 12:20:22 kernel: [<8007935c>] kmem_cache_alloc+0xb4/0xbc
Jun 25 12:20:22 kernel: [<8018c040>] sk_alloc+0x38/0x160
Jun 25 12:20:22 kernel: [<80207570>] inet_create+0x14c/0x378
Jun 25 12:20:22 kernel: [<8018a2ac>] __sock_create+0xf4/0x260
Jun 25 12:20:22 kernel: [<8018a448>] sock_create+0x10/0x1c
Jun 25 12:20:22 kernel: [<8018a660>] sys_socket+0x14/0x50
Jun 25 12:20:22 kernel: [<800111d0>] stack_done+0x20/0x44
Jun 25 12:20:22 kernel: Mem-info:
Jun 25 12:20:22 kernel: Normal per-cpu:
Jun 25 12:20:22 kernel: CPU  0: Hot: hi:  186, btch:  31 usd:  9  Cold: hi:  62, btch:  15 usd:  55
Jun 25 12:20:22 kernel: HighMem per-cpu:
Jun 25 12:20:22 kernel: CPU  0: Hot: hi:  186, btch:  31 usd: 182  Cold: hi:  62, btch:  15 usd:  6
Jun 25 12:20:22 kernel: Active:20612 inactive:12875 dirty:0 writeback:0 unstable:0
Jun 25 12:20:23 kernel:  free:8230 slab:5972 mapped:3006 pagetables:184 bounce:0
Jun 25 12:20:23 kernel: Normal free:2816kB min:2884kB low:3604kB high:4324kB active:20376kB inactive:20256kB present:520192kB pages_scanned:65018 all_unreclaimable? yes
Jun 25 12:20:23 kernel: lowmem_reserve[]: 0 14224
Jun 25 12:20:23 kernel: HighMem free:30104kB min:512kB low:3032kB high:5556kB active:62072kB inactive:31244kB present:1820672kB pages_scanned:0 all_unreclaimable? no
Jun 25 12:20:23 kernel: lowmem_reserve[]: 0 0
Jun 25 12:20:23 kernel: Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2816kB
Jun 25 12:20:23 kernel: HighMem: 1164*4kB 615*8kB 347*16kB 174*32kB 53*64kB 19*128kB 8*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 30104kB
Jun 25 12:20:23 kernel: Swap cache: add 4930, delete 4866, find 164/285, race 0+0
Jun 25 12:20:23 kernel: Free swap  = 2079884kB
Jun 25 12:20:23 kernel: Total swap = 2097136kB
Jun 25 12:20:23 kernel: Free swap:  2079884kB
Jun 25 12:20:23 kernel: 589823 pages of RAM
Jun 25 12:20:23 kernel: 458751 pages of HIGHMEM
Jun 25 12:20:23 kernel: 529905 reserved pages
Jun 25 12:20:23 kernel: 17338 pages shared
Jun 25 12:20:23 kernel: 64 pages swap cached
Jun 25 12:20:23 kernel: Out of memory: kill process 892 (minidlna) score 389 or a child
Jun 25 12:20:23 kernel: Killed process 892 (minidlna)
Jun 25 12:20:23 kernel: lighttpd invoked oom-killer: gfp_mask=0xd0, order=1, oomkilladj=0
Jun 25 12:20:23 kernel: Call Trace:
Jun 25 12:20:23 kernel: [<8000f42c>] dump_stack+0x8/0x34
Jun 25 12:20:23 kernel: [<80057528>] out_of_memory+0x1fc/0x264
Jun 25 12:20:23 kernel: [<8005939c>] __alloc_pages+0x318/0x360
Jun 25 12:20:23 kernel: [<80079674>] cache_alloc_refill+0x310/0x6b0
Jun 25 12:20:23 kernel: [<8007935c>] kmem_cache_alloc+0xb4/0xbc
Jun 25 12:20:23 kernel: [<8018c040>] sk_alloc+0x38/0x160
Jun 25 12:20:23 kernel: [<80207570>] inet_create+0x14c/0x378
Jun 25 12:20:23 kernel: [<8018a2ac>] __sock_create+0xf4/0x260
Jun 25 12:20:23 kernel: [<8018a448>] sock_create+0x10/0x1c
Jun 25 12:20:23 kernel: [<8018a660>] sys_socket+0x14/0x50
Jun 25 12:20:23 kernel: Active:14678 inactive:12874 dirty:0 writeback:0 unstable:0
Jun 25 12:20:23 kernel:  free:14182 slab:5972 mapped:2480 pagetables:159 bounce:0
Jun 25 12:20:23 kernel: Normal free:2816kB min:2884kB low:3604kB high:4324kB active:20352kB inactive:20252kB present:520192kB pages_scanned:65018 all_unreclaimable? yes
Jun 25 12:20:23 kernel: lowmem_reserve[]: 0 14224
Jun 25 12:20:23 kernel: HighMem free:53912kB min:512kB low:3032kB high:5556kB active:38360kB inactive:31244kB present:1820672kB pages_scanned:0 all_unreclaimable? no
Jun 25 12:20:23 kernel: lowmem_reserve[]: 0 0
Jun 25 12:20:23 kernel: Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2816kB
Jun 25 12:20:23 kernel: HighMem: 2280*4kB 1271*8kB 708*16kB 286*32kB 81*64kB 24*128kB 13*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 53912kB
Jun 25 12:20:23 kernel: Swap cache: add 4930, delete 4883, find 164/285, race 0+0
Jun 25 12:20:23 kernel: Free swap  = 2085580kB
Jun 25 12:20:23 kernel: Total swap = 2097136kB
Jun 25 12:20:23 kernel: Free swap:  2085580kB
Jun 25 12:20:23 kernel: 589823 pages of RAM
Jun 25 12:20:23 kernel: 458751 pages of HIGHMEM
Jun 25 12:20:23 kernel: 529905 reserved pages
Jun 25 12:20:23 kernel: 16356 pages shared
Jun 25 12:20:23 kernel: 47 pages swap cached
Jun 25 12:20:24 kernel: init invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Jun 25 12:20:24 kernel: Call Trace:
Jun 25 12:20:24 kernel: [<8000f42c>] dump_stack+0x8/0x34
Jun 25 12:20:24 kernel: [<80057528>] out_of_memory+0x1fc/0x264
Jun 25 12:20:24 kernel: [<8005939c>] __alloc_pages+0x318/0x360
Jun 25 12:20:24 kernel: [<8005940c>] __get_free_pages+0x28/0x4c
Jun 25 12:20:24 kernel: [<800c077c>] proc_info_read+0x58/0x174
Jun 25 12:20:24 kernel: [<8007d8a4>] vfs_read+0xbc/0x164
Jun 25 12:20:24 kernel: [<8007de6c>] sys_read+0x50/0xbc
Jun 25 12:20:24 kernel: [<800111d0>] stack_done+0x20/0x44
Jun 25 12:20:24 kernel: Mem-info:
Jun 25 12:20:24 kernel: Normal per-cpu:
Jun 25 12:20:24 kernel: CPU  0: Hot: hi:  186, btch:  31 usd:  42  Cold: hi:  62, btch:  15 usd:  55
Jun 25 12:20:24 kernel: HighMem per-cpu:
Jun 25 12:20:24 kernel: CPU  0: Hot: hi:  186, btch:  31 usd: 158  Cold: hi:  62, btch:  15 usd:  6
Jun 25 12:20:24 kernel: Active:14678 inactive:12874 dirty:0 writeback:0 unstable:0
Jun 25 12:20:24 kernel:  free:14182 slab:5972 mapped:2480 pagetables:159 bounce:0
Jun 25 12:20:24 kernel: Normal free:2816kB min:2884kB low:3604kB high:4324kB active:20352kB inactive:20252kB present:520192kB pages_scanned:65018 all_unreclaimable? yes
Jun 25 12:20:24 kernel: lowmem_reserve[]: 0 14224
Jun 25 12:20:24 kernel: HighMem free:53912kB min:512kB low:3032kB high:5556kB active:38360kB inactive:31244kB present:1820672kB pages_scanned:0 all_unreclaimable? no
Jun 25 12:20:24 kernel: lowmem_reserve[]: 0 0
Jun 25 12:20:24 kernel: Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2816kB
Jun 25 12:20:24 kernel: HighMem: 2280*4kB 1271*8kB 708*16kB 286*32kB 81*64kB 24*128kB 13*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 53912kB
...
 
I noticed something and please excuse if it has been addressed previously. On the latest Merlin you can be downloading at max speed in Download Master but this is not reflected when you go to QOS Bandwidth Monitor. It happily shows 0.00 up and down. Is this a feature or something borked?
 
@programatix
Your problem seems to be related to flexget as it's the first process killed, not transmission.
Code:
Jun 25 12:20:22 kernel: Out of memory: kill process 982 (flexget) score 1402 or a child
Jun 25 12:20:22 kernel: Killed process 982 (flexget)
Transmission works ok for me. I don't use flexget though, so I can't help you with that.
 
I noticed that when I'm operating Transmission using its web UI, the kernel goes into some sort of "panic" mode and kill almost all processes. However, when that happened, there are still a lot of free space in the swap file.

Below is the log when this happen,
Code:
Jun 25 12:20:20 kernel: lighttpd invoked oom-killer: gfp_mask=0xd0, order=1, oomkilladj=0

oom = Out Of Memory. Your router is running out of memory.
 
oom = Out Of Memory. Your router is running out of memory.
Hi Merlin,

I'm aware of that. After some experimenting, I noted that swap partition loaded via "swapon" doesn't seems to work properly. As seen in the log I posted above, there are plenty of free space in the swap partition but it is not used.

I then try mounting the swap partition using "fstab" and for the last 6 minutes, everything is stable at around 73% RAM used. I'll monitor the behaviour and report back if there is anything wrong.

Update #1: 15 minutes passed and free RAM is still around 73%. I see the swap file used space increases over time. I think the issue has been resolved.
Update #2: Darn the problem returns. At least it is better than before. Perhaps I need to play around with the vm swappiness.
Update #3: Nope, nothing works. Setting vm swappiness too high and the system would just auto restart when things get nasty. I wonder why the RT-N65U which has half the RAM of RT-N66U never have this problem...
Update #4: Nothing is firmed yet, but I'm beginning to suspect the problem is with the ext2/3 driver. In the OOM error message, I'm starting to see that the fsck is throwing out of memory error. I noted that I cannot successfully execute fsck manually too because it ended up with out of memory. My HDD is a 4TB HDD. On my previous router RT-N65U, there's no issue running fsck on the 4TB HDD. I'll perform the disk checking on my PC and resolve the disk error issue first and then see if the problem persists on the router.
 
Last edited:
is the openssl a sercurity update of sorts?

While it includes a few minor security fixes, the move to 1.0.2 was mostly to make it easier to maintain future releases, as 1.0.0 is going to be EOL by the end of the year.
 
I'm still stuck with the OOM. From the log below, the last 2 lines seem to show that the ext3 driver is also out of memory. Anyway to force the system to use the SWAP file/partition?

Code:
Jun 26 12:31:37 kernel: init invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Jun 26 12:31:37 kernel: Call Trace:
Jun 26 12:31:37 kernel: [<8000f42c>] dump_stack+0x8/0x34
Jun 26 12:31:37 kernel: [<800111d0>] stack_done+0x20/0x44
Jun 26 12:31:37 kernel: Mem-info:
Jun 26 12:31:37 kernel: Normal per-cpu:
Jun 26 12:31:37 kernel: CPU    0: Hot: hi:  186, btch:  31 usd:  40   Cold: hi:   62, btch:  15 usd:  54
Jun 26 12:31:37 kernel: HighMem per-cpu:
Jun 26 12:31:37 kernel: CPU    0: Hot: hi:  186, btch:  31 usd: 172   Cold: hi:   62, btch:  15 usd:   2
Jun 26 12:31:37 kernel: Active:14966 inactive:9026 dirty:0 writeback:0 unstable:0
Jun 26 12:31:37 kernel:  free:18722 slab:5840 mapped:2184 pagetables:149 bounce:0
Jun 26 12:31:37 kernel: Normal free:10144kB min:10240kB low:12800kB high:15360kB active:18536kB inactive:18676kB present:520192kB pages_scanned:64951 all_unreclaimable? yes
Jun 26 12:31:37 kernel: lowmem_reserve[]: 0 14224
Jun 26 12:31:37 kernel: HighMem free:64744kB min:512kB low:9472kB high:18432kB active:41328kB inactive:17428kB present:1820672kB pages_scanned:0 all_unreclaimable? no
Jun 26 12:31:37 kernel: lowmem_reserve[]: 0 0
Jun 26 12:31:37 kernel: Normal: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 2*4096kB = 10144kB
Jun 26 12:31:37 kernel: HighMem: 1324*4kB 983*8kB 554*16kB 317*32kB 145*64kB 62*128kB 18*256kB 9*512kB 6*1024kB 0*2048kB 0*4096kB = 64744kB
Jun 26 12:31:37 kernel: Swap cache: add 1687, delete 1682, find 43/62, race 0+0
Jun 26 12:31:37 kernel: Free swap  = 2092980kB
Jun 26 12:31:37 kernel: Total swap = 2097136kB
Jun 26 12:31:37 kernel: Free swap:       2092980kB
Jun 26 12:31:37 kernel: 589823 pages of RAM
Jun 26 12:31:37 kernel: 458751 pages of HIGHMEM
Jun 26 12:31:37 kernel: 529905 reserved pages
Jun 26 12:31:37 kernel: 22454 pages shared
Jun 26 12:31:37 kernel: 5 pages swap cached
Jun 26 12:31:37 kernel: httpd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Jun 26 12:31:37 kernel: Call Trace:
Jun 26 12:31:37 kernel: [<8000f42c>] dump_stack+0x8/0x34
Jun 26 12:31:37 kernel: [<80057528>] out_of_memory+0x1fc/0x264
Jun 26 12:31:37 kernel: [<8005939c>] __alloc_pages+0x318/0x360
Jun 26 12:31:37 kernel: [<801e6860>] tcp_sendmsg+0x6ec/0xcf0
Jun 26 12:31:37 kernel: [<8018843c>] sock_aio_write+0xf0/0x118
Jun 26 12:31:38 kernel: [<8007cc9c>] do_sync_write+0xd8/0x15c
Jun 26 12:31:38 kernel: [<8007d7d8>] vfs_write+0x154/0x164
Jun 26 12:31:38 kernel: [<8007df28>] sys_write+0x50/0xbc
Jun 26 12:31:38 kernel: [<800111d0>] stack_done+0x20/0x44
Jun 26 12:31:38 kernel: Mem-info:
Jun 26 12:31:38 kernel: Normal per-cpu:
Jun 26 12:31:38 kernel: CPU    0: Hot: hi:  186, btch:  31 usd:  40   Cold: hi:   62, btch:  15 usd:  54
Jun 26 12:31:38 kernel: HighMem per-cpu:
Jun 26 12:31:38 kernel: CPU    0: Hot: hi:  186, btch:  31 usd: 172   Cold: hi:   62, btch:  15 usd:   2
Jun 26 12:31:38 kernel: Active:14966 inactive:9026 dirty:0 writeback:0 unstable:0
Jun 26 12:31:38 kernel:  free:18722 slab:5840 mapped:2184 pagetables:149 bounce:0
Jun 26 12:31:38 kernel: Normal free:10144kB min:10240kB low:12800kB high:15360kB active:18536kB inactive:18676kB present:520192kB pages_scanned:65015 all_unreclaimable? yes
Jun 26 12:31:38 kernel: lowmem_reserve[]: 0 14224
Jun 26 12:31:38 kernel: HighMem free:64744kB min:512kB low:9472kB high:18432kB active:41328kB inactive:17428kB present:1820672kB pages_scanned:0 all_unreclaimable? no
Jun 26 12:31:38 kernel: lowmem_reserve[]: 0 0
Jun 26 12:31:38 kernel: Normal: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 2*4096kB = 10144kB
Jun 26 12:31:38 kernel: HighMem: 1324*4kB 983*8kB 554*16kB 317*32kB 145*64kB 62*128kB 18*256kB 9*512kB 6*1024kB 0*2048kB 0*4096kB = 64744kB
Jun 26 12:31:38 kernel: Swap cache: add 1687, delete 1682, find 43/62, race 0+0
Jun 26 12:31:38 kernel: Free swap  = 2092980kB
Jun 26 12:31:38 kernel: Total swap = 2097136kB
Jun 26 12:31:38 kernel: Free swap:       2092980kB
Jun 26 12:31:38 kernel: 589823 pages of RAM
Jun 26 12:31:38 kernel: 458751 pages of HIGHMEM
Jun 26 12:31:38 kernel: 529905 reserved pages
Jun 26 12:31:38 kernel: 22454 pages shared
Jun 26 12:31:38 kernel: 5 pages swap cached
Jun 26 12:31:54 kernel: EXT3-fs error (device sdb5) in ext3_delete_inode: Out of memory
Jun 26 12:31:56 kernel: EXT3-fs error (device sdb5) in ext3_mkdir: Out of memory

EDIT: It turns out that the out of memory occurs when transmission is accepting new Torrent and is creating the files for the new torrent. Once it accept the torrent, memory usage increases tremendously and end with out of memory.
 
Last edited:
If you have file preallocation enabled in transmission, maybe it'll help to disable it (reasoning is it starts to download, but I/O being blocked with the preallocation, it buffers the downloaded data to RAM):
  1. /opt/etc/init.d/S88transmission stop
  2. edit /opt/etc/transmission/settings.json
  3. set preallocation: 0
  4. /opt/etc/init.d/S88transmission start
I only have 512MB of swap, compared to your 2GB, and never had memory problems, even with 5 simultaneous downloads. I don't think going over this limit of active downloads is a good idea, these routers are what they are - slow I/O, slow CPU, small RAM and so on.
 
If you have file preallocation enabled in transmission, maybe it'll help to disable it (reasoning is it starts to download, but I/O being blocked with the preallocation, it buffers the downloaded data to RAM):
  1. /opt/etc/init.d/S88transmission stop
  2. edit /opt/etc/transmission/settings.json
  3. set preallocation: 0
  4. /opt/etc/init.d/S88transmission start
I only have 512MB of swap, compared to your 2GB, and never had memory problems, even with 5 simultaneous downloads. I don't think going over this limit of active downloads is a good idea, these routers are what they are - slow I/O, slow CPU, small RAM and so on.

Ok, I tried disabling preallocation. It still seems to OOM though and I'm getting more and more ext3 errors,
Code:
Jun 26 13:47:23 kernel: EXT3-fs error (device sdb5) in ext3_dirty_inode: Out of memory
Jun 26 13:47:24 kernel: EXT3-fs error (device sdb5) in ext3_reserve_inode_write: Readonly filesystem
Jun 26 13:47:24 kernel: EXT3-fs error (device sdb5) in ext3_reserve_inode_write: Readonly filesystem
Jun 26 13:47:25 kernel: EXT3-fs error (device sdb5) in ext3_delete_inode: Out of memory
Jun 26 13:47:25 kernel: EXT3-fs error (device sdb5) in ext3_mkdir: Out of memory

Please note that I had just repaired the partition using my PC.

UPDATE:
Now it's getting worse,
Code:
Jun 26 13:55:48 kernel: journal_get_undo_access: No memory for committed data
Jun 26 13:55:48 kernel: ext3_try_to_allocate_with_rsv: aborting transaction: Out of memory in __ext3_journal_get_undo_access
Jun 26 13:55:48 kernel: EXT3-fs error (device sda5) in ext3_new_blocks: Out of memory
Jun 26 13:55:48 kernel: EXT3-fs error (device sda5) in ext3_reserve_inode_write: Readonly filesystem
Jun 26 13:55:48 kernel: EXT3-fs error (device sda5) in ext3_dirty_inode: Out of memory
Jun 26 13:55:48 kernel: EXT3-fs error (device sda5) in ext3_reserve_inode_write: Readonly filesystem
Jun 26 13:55:48 kernel: EXT3-fs error (device sda5) in ext3_reserve_inode_write: Readonly filesystem
Jun 26 13:55:48 kernel: EXT3-fs error (device sda5) in ext3_delete_inode: Out of memory
Jun 26 13:55:48 kernel: EXT3-fs error (device sda5) in ext3_mkdir: Out of memory

Would converting the partition from ext3 to ext2 help?
 
Last edited:
Pls ignore my previous post on Apple TV, I *think* this is due to the new igmp settings under LAN -> IPTV. Since enabling IGMP snooping there all has been good even on the latest test build, pretty sure this option was not present in previous fw versions.
 
Wanted to report a few issues with this version of the firmware and the ASUS N66U router. Since upgrading to 378.54_2 (from 374.x, doing a factory reset and rebuilding settings from scratch as recommended in the changelog), I have been experiencing several weird issues, most frequent of which is an inexplicable slowdown on throughput each night, which makes even local resources like my server and the router's web interface take minutes to load or just time out) forces me to reboot the router each morning (details in this thread), but also completely weird issues with connectivity, at one point first losing connection to certain game servers, then all web connectivity (I use a local DNS rather than the router, so it wasn't a DNS issue), but through it all I was talking with a friend on Skype without issues. All issues I have seen has been temporarily solved with a reboot, but the connectivity issue mentioned last did not exist in previous firmware and the throughput slowdown occurred very rarely in older firmwares. I hope these issues can be identified and solved.
 
While it includes a few minor security fixes, the move to 1.0.2 was mostly to make it easier to maintain future releases, as 1.0.0 is going to be EOL by the end of the year.

ok , Cause i was look at change log to see if there "Security" Then I realize the change log dont actual state "Security Fix" just states Changed/Fix /New is possible to note "security fix" for security fixes only reason i ask is cause i only upgrade firmware for security fix at this point or if i find some broke that got fix.

Thanks for all your work though
 
ok , Cause i was look at change log to see if there "Security" Then I realize the change log dont actual state "Security Fix" just states Changed/Fix /New is possible to note "security fix" for security fixes only reason i ask is cause i only upgrade firmware for security fix at this point or if i find some broke that got fix.

I already do that if it's an important security update. As I said, there was nothing major in this particular OpenSSL update, hence the lack of mention.

I take the time to specify which version I update to (which is more than many other developers do), it's up to endusers to do the remaining legwork and check those version's own changelog if they want to know more. Otherwise, people would also start expecting me to also report bugfixes from those particular updates, and just a simple changelog would become a chore in itself (and a maze to read through), and a waste of my time. I don't think it's too difficult for anyone to look on the web for the specific version I mentioned.
 
Status
Not open for further replies.

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top