34 replies to this topic

[speed]

I have multiple times my solo2 completely freezes

I couldn't find any reason

 

however I just had it happened again now

now I notice I had a timing programmed

the recording is all there

but it seems like it froze on the end when the recording finished?

anyone else also have this issue?

Edited by speed, 12 April 2014 - 21:36.

[mattiL]

You have to look for crash logs and also check for errors in the system.

 

Which version of OpenPLi do you have, is it updated recently?

Perhaps reflash to latest OpenPLi 4 version?

 

I hope you are familiar with using telnet and if so:

- If you have an hard disk connected you should look in the root of the hard drive for crash logs (ls -la /hdd).

- Run something like tail -n2000 /var/log/messages > /hdd/mess.txt

 

 

Upload the files to this thread for the experts to look at them.

[speed]

I have the latest version of openpli4

but versions before have same problem

 

when it freezes it freezes completely and no crash logs are never generated when the freezing happens

[mattiL]

Ok, have you done a disk check yet?

As it seems to happen after recordings it could be disk related (broken hard disk).

 

You can find a tool for this in Settings.

[speed]

no, but when manual recording I have no issues

I cant find him, whats the name of this plugin?

[speed]

just for test I installed last openpli3

and half way a programmed recording box has frozen again

[mattiL]

It is not a plugin,

go to Settings>System>Hard disk>Check Filesystem  (my translation from Swedish to English..)

[mattiL]

By the way, are you using Linux Ext3/4 or perhaps Microsoft FAT32?

[speed]

this filessytem check will not delete anything on the harddisk?

 

if I remember right I did use the option convert ext3 to ext4

however this is long time ago

how can I check this to be sure?

[mattiL]

A filesystem check does not remove anything, but a crashed file system may remove a lot.. 

The filesystem check will check both Ext3 and Ext4,no problem there.

[speed]

[mattiL]

I ran a file system check, it looked like it was successful but it seems I got a little crash (checked via telnet with dmesg):

 

 sda: sda1
mount: page allocation failure: order:5, mode:0xd0
Call Trace:
[<805745c8>] dump_stack+0x8/0x34
[<80087524>] warn_alloc_failed+0xe4/0x12c
[<80089724>] __alloc_pages_nodemask+0x148/0x650
[<80575830>] cache_alloc_refill+0x360/0x650
[<800bc660>] __kmalloc+0x150/0x158
[<8015e34c>] ext4_kvzalloc+0x20/0x64
[<8016274c>] ext4_fill_super+0x153c/0x2bc4
[<800c3b30>] mount_bdev+0x1d8/0x220
[<8015cc28>] ext4_mount+0x1c/0x28
[<800c4854>] mount_fs+0x20/0xec
[<800e118c>] vfs_kern_mount+0x58/0xcc
[<800e214c>] do_kern_mount+0x4c/0x124
[<800e3fa4>] do_mount+0x430/0x798
[<800e4b94>] sys_mount+0x94/0xe4
[<8000e448>] stack_done+0x20/0x44

Mem-Info:
Normal per-cpu:
CPU    0: hi:   90, btch:  15 usd:   0
CPU    1: hi:   90, btch:  15 usd:   0
active_anon:16393 inactive_anon:31 isolated_anon:0
 active_file:1163 inactive_file:283 isolated_file:31
 unevictable:0 dirty:0 writeback:0 unstable:0
 free:10678 slab_reclaimable:605 slab_unreclaimable:2225
 mapped:1255 shmem:174 pagetables:112 bounce:0
Normal free:42712kB min:2036kB low:2544kB high:3052kB active_anon:65572kB inactive_anon:124kB active_file:4652kB inactive_file:1132kB unevictable:0kB isolated(anon):0kB isolated(file):124kB present:260096kB mlocked:0kB dirty:0kB writeback:0kB mapped:5020kB shmem:696kB slab_reclaimable:2420kB slab_unreclaimable:8900kB kernel_stack:632kB pagetables:448kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 1155*4kB 1452*8kB 1003*16kB 268*32kB 26*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 42652kB
1646 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
65536 pages RAM
30995 pages reserved
2567 pages shared
21716 pages non-shared
EXT4-fs (sda1): mounted filesystem with writeback data mode. Opts: (null)

 

 

OpenPLi 4 Version:

root@vuduo:~# uname -a
Linux vuduo 3.1.1 #1 SMP Mon Mar 10 08:13:55 CET 2014 mips GNU/Linux

 

 

Manually unmounting /media/hdd and rerunning fsck reported the disk clean.

 

root@vuduo:~# e2fsck -n /dev/sda1
e2fsck 1.42.9 (28-Dec-2013)
/dev/sda1: clean, 315/267120 files, 42840687/78142805 blocks

[mattiL]

@speed, did you try to restart the receiver and then rerun the filesystem check?

[speed]

ok after disable permanent timeshift I think it started, but I could not find any progress bar or anything?

then after a while

 

root@vusolo2:~# e2fsck -n /dev/sda1
e2fsck 1.42.9 (28-Dec-2013)
/dev/sda1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
 

I think I just need to wait?

Edited by speed, 16 April 2014 - 18:08.

[mattiL]

Yes, just wait. And hope..

 

BTW, '-n' is just a check, if you want to repair you have to use '-p' .

Edited by mattiL, 16 April 2014 - 18:18.

[speed]

didn't work

/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
 

root@vusolo2:~# e2fsck /dev/sda1
e2fsck 1.42.9 (28-Dec-2013)
/dev/sda1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 802305 was part of the orphaned inode list.  FIXED.
Inode 802306 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
 

 

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 4468/953984 files (81.4% non-contiguous), 76895359/244190645 blocks
root@vusolo2:~# e2fsck -n /dev/sda1
e2fsck 1.42.9 (28-Dec-2013)
/dev/sda1: clean, 4468/953984 files, 76895359/244190645 blocks

 

 

root@vusolo2:~# e2fsck -n /dev/sda1
e2fsck 1.42.9 (28-Dec-2013)
/dev/sda1: clean, 4468/953984 files, 76895359/244190645 blocks
root@vusolo2:~#

 

this means now its good?
 

[mattiL]

Yes, it seems to be ok now.

[speed]

ok I hope the problem is gona now

if not I will report back

thanks

[betacentauri]

Yes, looks good, but you should use -f option to force a check. If e2fsck thinks filesystems is error free it don't starts check.

[mattiL]

@betacentauri, If you look at post #16 you will see that fsck actually reported the filesystem as dirty.