Leaderboard

Ok it was a success. So I ended up editing 2 databases but without deleting all the entries relating to my drive serial number. I only deleted the entries that showed an error. I initially tried the normal .dump command with sqlite but ended up with some encrypted database 🤷‍♂️ so I went animalistic and simply copied over the databases to my Mac, opened them with 'DB Browser for SQlite' and deleted the entries that were offending me. I then copied over the database back to their original location in the NAS. Needless to say I obviously kept the original databases as backup in case my little stunt wouldn't work. .SYNODISKTESTDB: contains what type of test was done (quick or extended or was aborted) .SYNODISKDB: shows the status of the disk (warning, critical etc) the third one: SYNODISKHEALTHDB: contains the disks error count. I didn't see the need to edit this database since all disks are showing 0 errors. Now, running an extended SMART test for good measure. As if it had never happened 😁 Problem solved!

Let Me know if this is Allowed I will delete if not allowed @Polanskiman , @fbelavenuto

Here's the method for deleting your matched serial numbers from the DSM 7 databases: https://community.synology.com/enu/forum/2/post/151784

Sorry for the quick response. No further information is needed, but I am investigating the issue.

https://xpenology-com.translate.goog/forum/topic/30678-using-docker-wireguard-vpn-on-xpenologydsm?_x_tr_sl=auto&_x_tr_tl=ru&_x_tr_hl=ru https://www.ixbt.com/live/sw/prostoy-sposob-sdelat-svoy-vpn-server-s-wireguard-i-trafikom-32-tb-prigoditsya-esli-zablokiruyut-youtube.html Ну как то так ......

my DSM (ESXI 6.7u3 DS3617xs) also had this problem and i did some research: in my case i found a lot log "Can't get Core 2 temperature data" in scemd.log and a crash in kern.log: 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.690107] CPU: 1 PID: 12167 Comm: scemd Tainted: PF C O 3.10.105 #25426 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.691007] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.692337] task: ffff88007c5e7040 ti: ffff88007a0e4000 task.ti: ffff88007a0e4000 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.693250] RIP: 0010:[<ffffffff814c0ff3>] [<ffffffff814c0ff3>] __mutex_lock_slowpath+0xe3/0x1d0 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.694354] RSP: 0018:ffff88007a0e7b40 EFLAGS: 00010246 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.695016] RAX: 0000000000000000 RBX: ffff880078cd5cf8 RCX: 0000000000000000 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.695882] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff880078cd5cfc 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.696748] RBP: ffff88007a0e7b88 R08: 0000000000000000 R09: 0000000000000000 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.697629] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880078cd5cfc 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.698503] R13: ffff880078cd5d18 R14: ffff88007c5e7040 R15: ffff880078cd5d00 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.699385] FS: 00007f4135e53b80(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.700376] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.701093] CR2: 0000000000000000 CR3: 000000007af18000 CR4: 00000000003607e0 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.701990] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.702886] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.703772] Stack: 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.704034] ffff880078cd5d00 0000000000000000 ffff88007a0e7bf8 00000000000117c0 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.705028] ffff880078cd5cf8 ffffffff818514f0 ffff88007a0e7bf8 00000000000117c0 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.706095] ffff880078cd5cf8 0000000000000001 ffffffff814c029e ffff880078cd5ba0 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.707067] Call Trace: 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.707380] [<ffffffff814c029e>] ? mutex_lock+0xe/0x20 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.708027] [<ffffffff8138c29b>] ? syno_cpu_temperature+0xfb/0x1d0 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.708798] [<ffffffffa0dc6824>] ? synobios_ioctl+0x444/0x17e0 [broadwell_synobios] 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.709746] [<ffffffff811a3b7f>] ? ext4_dentry_hash+0x2f/0x80 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.710481] [<ffffffff8111326a>] ? do_vfs_ioctl+0x4aa/0x990 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.711187] [<ffffffff811137d0>] ? SyS_ioctl+0x80/0xa0 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.711837] [<ffffffff814c4dc4>] ? system_call_fastpath+0x22/0x27 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.712592] Code: 08 75 07 41 83 7e 30 63 7f 96 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 8e 2c 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 8b 03 4c 89 74 24 10 85 c0 78 0c b8 ff ff ff ff 87 03 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.716169] RIP [<ffffffff814c0ff3>] __mutex_lock_slowpath+0xe3/0x1d0 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.717257] RSP <ffff88007a0e7b40> 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.717808] CR2: 0000000000000000 2022-10-11T15:36:33+08:00 DSM6 kernel: [ 17.718250] ---[ end trace 40d10dac8f397b6a ]--- i think maybe something wrong with vm cpu config so i shutdown DSM and change the "Cores per Socket" to 2 (which was 1 by default) and restart DSM then the error log is gone and nothing crash and the Info Center/General tab is back again i hope this helps

The experimental platforms are not in the Loaders and Platforms matrix. But I would think it would be equivalent to the 1621+ which is Ryzen 4-core/8-threads, and 16 threads in the kernel. So it's probably that they are trying to do too much on the limited 2-core CPU.

Good luck with that! 5.2 -> 7.x is quite a big jump. I'd be tempted to go to 6.x as an intermediate step to be on the safe side.

For some reason the e1000e driver does not work with this card. Other users have reported the same problem. I still haven't figured out the reason but I'll let you know if I can fix it.

sorry about that , i get it now

This is not correct. There is a finite number of threads configured by kernel parameter for each platform. These are specifically highlighted in the table. The kernel thread limit is almost always larger than the number of physical threads on the DSM platform. In the case of the DS3622xs+ we can use 24 threads, even though the actual hardware only offers 12 threads. Any additional threads available with your hardware (beyond 24) will be ignored.

Also, re. SHR, it's not a proprietary Synology thing, it's just their custom implementation of some of the features of mdadm (e.g. linux software RAID) that allows you to mix disks of different sizes. It's not hard to roll it yourself on a non-Synology system, it's just DSM does the heavy-lifting of setting it up for you. FYI, SHR support is still in DSM 7: you can add a set of disks from a DSM6 device and it will use them, you just can't create new SHR volumes.

Re. RAM compatibility: it's tied to the North Bridge chipset, not the CPU. Although the CPU also has to be compatible with the North Bridge, it's the North Bridge that dictates what RAM you can use on a given motherboard, I believe.

Тестирование окончено. Жалоб не было ни от кого. Спасибо все кто тестировал