Transmission locks up when adding torrents

[Piglet]

I'm using Transmission 3.00.8 on a RN104 and I have noticed that after the OS 6.2 install, every time I add a new torrent the NAS locks up and becomes unresponsive for varying amounts of time. Usually about 15 minutes but sometimes up to an hour.

During the lockup nothing works (ssh, afp, web… not even the power button reacts). The length of time the NAS is unresponsive seems to be related to the size of the torrent added because after adding a big (90GB) torrent the NAS didn't recover for over 12h. I had to pull the power and then shut down Transmission before it started up or else it would lock up again.

Any ideas on how to prevent this? Can the settings be used to fix the problem or is it a OS or Transmission problem?


Excerpt from kernel.log (there are multiple messages like this)

Dec 15 05:48:10 Nasse kernel: BUG: soft lockup - CPU#0 stuck for 22s! [transmission-da:6936]
Dec 15 05:48:11 Nasse kernel: Modules linked in: vpd(P)
Dec 15 05:48:11 Nasse kernel: 
Dec 15 05:48:11 Nasse kernel: Pid: 6936, comm:      transmission-da
Dec 15 05:48:11 Nasse kernel: CPU: 0    Tainted: P              (3.0.101.RN_ARM.3 #1)
Dec 15 05:48:11 Nasse kernel: PC is at find_free_extent+0x3a4/0x9cc
Dec 15 05:48:11 Nasse kernel: LR is at find_free_extent+0x3a4/0x9cc
Dec 15 05:48:11 Nasse kernel: pc : [<c02e7a78>]    lr : [<c02e7a78>]    psr: 80000013
Dec 15 05:48:11 Nasse kernel: sp : d816bcb0  ip : d816bcb0  fp : d816bd44
Dec 15 05:48:11 Nasse kernel: r10: 00000000  r9 : 81c00000  r8 : c30787a0
Dec 15 05:48:11 Nasse kernel: r7 : c9c5f300  r6 : c9c5f300  r5 : 00000000  r4 : 00200000
Dec 15 05:48:11 Nasse kernel: r3 : 00000000  r2 : 00200000  r1 : 00000000  r0 : 00000001
Dec 15 05:48:11 Nasse kernel: Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Dec 15 05:48:11 Nasse kernel: Control: 10c5387d  Table: 040a0019  DAC: 00000015
Dec 15 05:48:11 Nasse kernel: [<c0039ec0>] (show_regs+0x0/0x54) from [<c00a3a24>] (watchdog_timer_fn+0x108/0x140)
Dec 15 05:48:11 Nasse kernel:  r4:ee6b2800 r3:00000000
Dec 15 05:48:11 Nasse kernel: [<c00a391c>] (watchdog_timer_fn+0x0/0x140) from [<c0088270>] (hrtimer_run_queues+0xa0/0x1e8)
Dec 15 05:48:11 Nasse kernel: [<c00881d0>] (hrtimer_run_queues+0x0/0x1e8) from [<c0076e18>] (run_local_timers+0x10/0x20)
Dec 15 05:48:11 Nasse kernel: [<c0076e08>] (run_local_timers+0x0/0x20) from [<c0076e58>] (update_process_times+0x30/0x64)
Dec 15 05:48:11 Nasse kernel: [<c0076e28>] (update_process_times+0x0/0x64) from [<c0091d10>] (tick_periodic.constprop.19+0x38/0xac)
Dec 15 05:48:11 Nasse kernel:  r6:00000000 r5:00000000 r4:c082bd70 r3:80000013
Dec 15 05:48:11 Nasse kernel: [<c0091cd8>] (tick_periodic.constprop.19+0x0/0xac) from [<c0091d9c>] (tick_handle_periodic+0x18/0x80)
Dec 15 05:48:11 Nasse kernel:  r7:00000000 r6:00000000 r5:c08083e0 r4:c07d4160
Dec 15 05:48:11 Nasse kernel: [<c0091d84>] (tick_handle_periodic+0x0/0x80) from [<c0045fec>] (axp_timer_interrupt+0x30/0x3c)
Dec 15 05:48:11 Nasse kernel:  r9:c082f364 r8:00000005 r7:00000000 r6:00000000 r5:00000005
Dec 15 05:48:11 Nasse kernel: r4:c07d4160
Dec 15 05:48:11 Nasse kernel: [<c0045fbc>] (axp_timer_interrupt+0x0/0x3c) from [<c00a4394>] (handle_irq_event_percpu+0x54/0x19c)
Dec 15 05:48:11 Nasse kernel: [<c00a4340>] (handle_irq_event_percpu+0x0/0x19c) from [<c00a450c>] (handle_irq_event+0x30/0x44)
Dec 15 05:48:11 Nasse kernel: [<c00a44dc>] (handle_irq_event+0x0/0x44) from [<c00a6038>] (handle_level_irq+0x88/0xd0)
Dec 15 05:48:11 Nasse kernel:  r4:c07d8ca8 r3:00022000
Dec 15 05:48:11 Nasse kernel: [<c00a5fb0>] (handle_level_irq+0x0/0xd0) from [<c00a3d7c>] (generic_handle_irq+0x2c/0x44)
Dec 15 05:48:11 Nasse kernel:  r4:c07ee244 r3:c00a5fb0
Dec 15 05:48:11 Nasse kernel: [<c00a3d50>] (generic_handle_irq+0x0/0x44) from [<c0032038>] (asm_do_IRQ+0x38/0x90)
Dec 15 05:48:11 Nasse kernel: [<c0032000>] (asm_do_IRQ+0x0/0x90) from [<c0038474>] (__irq_svc+0x34/0x1c0)
Dec 15 05:48:11 Nasse kernel: Exception stack(0xd816bc68 to 0xd816bcb0)
Dec 15 05:48:12 Nasse kernel: bc60:                   00000001 00000000 00200000 00000000 00200000 00000000
Dec 15 05:48:12 Nasse kernel: bc80: c9c5f300 c9c5f300 c30787a0 81c00000 00000000 d816bd44 d816bcb0 d816bcb0
Dec 15 05:48:12 Nasse kernel: bca0: c02e7a78 c02e7a78 80000013 ffffffff
Dec 15 05:48:12 Nasse kernel:  r6:0000001a r5:fbb21000 r4:ffffffff r3:80000013
Dec 15 05:48:12 Nasse kernel: [<c02e76d4>] (find_free_extent+0x0/0x9cc) from [<c02e8164>] (btrfs_reserve_extent+0xc4/0x14c)
Dec 15 05:48:12 Nasse kernel: [<c02e80a0>] (btrfs_reserve_extent+0x0/0x14c) from [<c03004b4>] (__btrfs_prealloc_file_range+0xe0/0x444)
Dec 15 05:48:12 Nasse kernel: [<c03003d4>] (__btrfs_prealloc_file_range+0x0/0x444) from [<c030a600>] (btrfs_prealloc_file_range+0x3c/0x44)
Dec 15 05:48:12 Nasse kernel: [<c030a5c4>] (btrfs_prealloc_file_range+0x0/0x44) from [<c030ef50>] (btrfs_fallocate+0x368/0xcfc)
Dec 15 05:48:12 Nasse kernel:  r5:d7285480 r4:4b6bf000
Dec 15 05:48:12 Nasse kernel: [<c030ebe8>] (btrfs_fallocate+0x0/0xcfc) from [<c00e4600>] (do_fallocate+0x110/0x138)
Dec 15 05:48:12 Nasse kernel: [<c00e44f0>] (do_fallocate+0x0/0x138) from [<c00e466c>] (sys_fallocate+0x44/0x5c)
Dec 15 05:48:12 Nasse kernel:  r9:d816a000 r8:c0038c68 r7:00000000 r6:4b6be44c r5:00000000
Dec 15 05:48:12 Nasse kernel: r4:dd2c76e0
Dec 15 05:48:12 Nasse kernel: [<c00e4628>] (sys_fallocate+0x0/0x5c) from [<c0038ac0>] (ret_fast_syscall+0x0/0x30)
Dec 15 05:48:12 Nasse kernel:  r7:00000160 r6:00000000 r5:00000000 r4:4b6be44c

[de_niro]

looks like old Btrfs performance issue,please check btrfs.log(download from System>Logs)to make sure if the nodesize is still 4096

check below lines in btrfs.log
sectorsize 4096
nodesize 4096
leafsize 4096
stripesize 4096

if your volume was created in old ReadyOS and the sectorsize and nodesize are still 4096 then you must backup all data and create a new Btrfs volume in latest ReadyOS.

[Piglet]

It seems this might have been caused by the share having CoW enabled, causing heavy fragmentation. I have disabled CoW, defragged and trying again now.