Mathias

@soerenderforSo, you have the pine store pcie <-> sata adapter, the pine store cables and then 5 drives into your nas box and the whole thing is rock solid, if I understand correctly?

@soerenderforFrom what you write, I have a feeling that an old problem of mine could be solved... I currently have an HDD connected to the Pine Sata adapter and an SSD connected to the USB3 port since putting these two drive on the sata adapter lead to catastrophic failures (major file system corruption). At the time, I got convinced that my HDD was drawing too much power, so it could not share the power lines with the SSD: see So, it now seems that by buying a different sata adapter (like the one that was mentioned based on the marvell 88SE9230), I should be able to have both drives connected to the sata adapter in my nas box? (I'm still kind of scared of trying, since last time I had to restore huge amounts of data from backups, the drives were totally messed up).

@soerenderfor Sorry for my late reply (homeoffice with kids is not the easiest way of debugging a system that I also use as a dns proxy). Yes, it now works. Basically, as I now understand it, I had been relying on hdparm setting parameters to the disk and the disk keeping them between reboots. I did not realize that there is a hdparm.conf file... So now that I have written my parameters into hdparm.conf, it does behave the way I have configured it (initially with a spin-down tiome of 24 (so 120 seconds), now 60 (so 5 minutes)). Thanks a lot for your help!!

I've tried to blacklist snd-mtpav, and besides not having the module loaded (lsmod shows that the module is not loaded), I still have the crash at boot... It does not makes sense to me...

I have tried OpenSeaChest, but this makes no difference (compared to using hdparm to set up power management parameters). I set the disk to spin down after 25s and it does not... Right now, I have to use a cron job to put it in standby every half an hour (since I only use this disk to do backups, it does not need to wake up beside in the middle of the night where the cron job does not run).

For me, it seems to be working perfectly fine. I've just transferred more than 250G of backups back on my sata drive, no issues.

After a cold boot, I don't have cpuerrors anymore (on 5.4.27). I've waited ~30s before restarting the system. I still have a crash but the kernel can recover (see http://ix.io/2fDO): [ 41.902116] ------------[ cut here ]------------ [ 41.902135] WARNING: CPU: 4 PID: 1 at kernel/irq/manage.c:1990 request_threaded_irq+0x144/0x180 [ 41.902138] Modules linked in: [ 41.902149] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.4.27-rockchip64 #20.02.6 [ 41.902153] Hardware name: Pine64 RockPro64 (DT) [ 41.902158] pstate: a0000005 (NzCv daif -PAN -UAO) [ 41.902165] pc : request_threaded_irq+0x144/0x180 [ 41.902171] lr : request_threaded_irq+0x6c/0x180 [ 41.902174] sp : ffff80001004b9b0 [ 41.902178] x29: ffff80001004b9b0 x28: 0000000000000000 [ 41.902185] x27: ffff0000ef2428c0 x26: ffff8000111c8d98 [ 41.902190] x25: 0000000000000000 x24: 0000000000000007 [ 41.902195] x23: ffff0000f0d77870 x22: ffff800010b2dd80 [ 41.902201] x21: ffff0000f142a000 x20: 0000000000000000 [ 41.902206] x19: ffff80001141bee0 x18: 0000000000000001 [ 41.902211] x17: ffff0000f0d75a00 x16: ffff800010aa6aa0 [ 41.902216] x15: ffffffffffffffff x14: ffff80001137b508 [ 41.902222] x13: ffff00016f291b37 x12: ffff0000ef291b43 [ 41.902227] x11: ffff0000f67c2268 x10: 0000000000000040 [ 41.902232] x9 : ffff80001139f028 x8 : ffff80001139f020 [ 41.902238] x7 : ffff0000f10002a8 x6 : 0000000000000000 [ 41.902243] x5 : ffff0000f1000248 x4 : 0000000000000000 [ 41.902248] x3 : 0000000000000000 x2 : 0000000000000000 [ 41.902253] x1 : 0000000000000007 x0 : 0000000000031600 [ 41.902258] Call trace: [ 41.902265] request_threaded_irq+0x144/0x180 [ 41.902274] snd_mtpav_probe+0x15c/0x3d8 [ 41.902281] platform_drv_probe+0x50/0xa0 [ 41.902288] really_probe+0xd8/0x300 [ 41.902293] driver_probe_device+0x54/0xe8 [ 41.902297] __device_attach_driver+0x80/0xb8 [ 41.902303] bus_for_each_drv+0x78/0xc8 [ 41.902309] __device_attach+0xd4/0x130 [ 41.902313] device_initial_probe+0x10/0x18 [ 41.902319] bus_probe_device+0x90/0x98 [ 41.902324] device_add+0x3c4/0x5f0 [ 41.902329] platform_device_add+0x10c/0x230 [ 41.902334] platform_device_register_full+0xc8/0x140 [ 41.902341] alsa_card_mtpav_init+0x74/0xd0 [ 41.902348] do_one_initcall+0x74/0x1b0 [ 41.902354] kernel_init_freeable+0x194/0x22c [ 41.902361] kernel_init+0x10/0xfc [ 41.902367] ret_from_fork+0x10/0x18 [ 41.902374] ---[ end trace f53d3c1ec0afdd56 ]--- Mathias

I have installed the latest stale kernel from Armbian (5.4.27) and this does exactly the same... I will try to power down the system, leave it off for a few seconds and then restart, just in case...

Has anybody seen this message at boot: [ 5.352826] CPU4: failed to come online [ 5.352835] CPU4: failed in unknown state : 0x0 [ 10.481328] CPU5: failed to come online [ 10.481336] CPU5: failed in unknown state : 0x0 Then, the A72 cores don't show up (unsurprisingly since these are the two cores that somehow did not come online). On top of that, the kernel throws a backtrace (related to sound if I understand correctly): ------------[ cut here ]------------ [ 13.014782] WARNING: CPU: 3 PID: 1 at kernel/irq/manage.c:1990 request_threaded_irq+0x144/0x180 [ 13.014784] Modules linked in: [ 13.014793] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.4.26-rockchip64 #20.02.5 [ 13.014795] Hardware name: Pine64 RockPro64 (DT) [ 13.014799] pstate: a0000005 (NzCv daif -PAN -UAO) [ 13.014804] pc : request_threaded_irq+0x144/0x180 [ 13.014808] lr : request_threaded_irq+0x6c/0x180 [ 13.014810] sp : ffff80001004b9b0 [ 13.014813] x29: ffff80001004b9b0 x28: 0000000000000000 [ 13.014817] x27: ffff0000ef78c0c0 x26: ffff8000111c8d98 [ 13.014822] x25: 0000000000000000 x24: 0000000000000007 [ 13.014826] x23: ffff0000f0914870 x22: ffff800010b2dce0 [ 13.014830] x21: ffff0000f142a000 x20: 0000000000000000 [ 13.014834] x19: ffff80001141bee0 x18: 0000000000000001 [ 13.014838] x17: ffff800011188d00 x16: ffff800011188d08 [ 13.014843] x15: ffffffffffffffff x14: ffff80001137b508 [ 13.014847] x13: ffff00016f1e14b7 x12: ffff0000ef1e14c3 [ 13.014851] x11: ffff0000f67ac268 x10: 0000000000000040 [ 13.014855] x9 : ffff80001139f028 x8 : ffff80001139f020 [ 13.014859] x7 : ffff0000f10002a8 x6 : 0000000000000000 [ 13.014863] x5 : ffff0000f1000248 x4 : 0000000000000000 [ 13.014867] x3 : 0000000000000000 x2 : 0000000000000000 [ 13.014871] x1 : 0000000000000007 x0 : 0000000000031600 [ 13.014875] Call trace: [ 13.014880] request_threaded_irq+0x144/0x180 [ 13.014887] snd_mtpav_probe+0x15c/0x3d8 [ 13.014893] platform_drv_probe+0x50/0xa0 [ 13.014899] really_probe+0xd8/0x300 [ 13.014902] driver_probe_device+0x54/0xe8 [ 13.014906] __device_attach_driver+0x80/0xb8 [ 13.014910] bus_for_each_drv+0x78/0xc8 [ 13.014915] __device_attach+0xd4/0x130 [ 13.014918] device_initial_probe+0x10/0x18 [ 13.014922] bus_probe_device+0x90/0x98 [ 13.014927] device_add+0x3c4/0x5f0 [ 13.014930] platform_device_add+0x10c/0x230 [ 13.014934] platform_device_register_full+0xc8/0x140 [ 13.014940] alsa_card_mtpav_init+0x74/0xd0 [ 13.014945] do_one_initcall+0x74/0x1b0 [ 13.014950] kernel_init_freeable+0x194/0x22c [ 13.014957] kernel_init+0x10/0xfc [ 13.014961] ret_from_fork+0x10/0x18 [ 13.014969] ---[ end trace 34ce35f0c45c0a90 ]--- Mathias

Hi! On the Rockpro64, with the latest Amrbian dev kernel (5.4.0-rc1-rockchip64 updated on 19th of January), the sata hard drive connected to PCIe through the pine store adapter does not go to sleep anymore. It is properly set with hdparm and a udev rule, it used to work fine with the dev kernel before the 19th of January update. Now, if I issue a sleep commd (hdpram -y /dev/sda) it goes to sleep properly but not by itself after the 5 minutes inactivity I have set up. Mathias

@chwe Oops, I'd never looked at the specs sheet. I've always assumed that the numbers written on the disk itself were the max. consumption. I also did not understand that it was drawing both 5V and 12V (I though it was one or the other one). So, it takes up to 21W. But even if you add the board itself and the ssd (this one has for sure a low peak power, max 4W (from the spec sheet), the PSU should still have enough margin (my psu is not even 1 year old). I understand 21W is already consistent, but still way off what one could expect in a PC...

@soerenderfor i guess you have to test with an ssd, not "just" hdds: the WD hdd draws 700mA while the Samsung 860 draws a maximum of 1.2A and the 840 Pro up to 1.4A (and in fact it seems that this maximum is very unregularly reached, leading to the observed behavior: it works for hours and then hell breaks through...) @chwe i doubt this is related: my board is from 04.2019 and if i don't use more than one hdd on the pcie, it works fine...

@soerenderfor The HDD is a Western Digital Red (sata III, 4T, 3.5": WD40EFRX-68WT0N0). The SSD is a Samsung 860 EVO 1TB either directly connected in sata or through a JMicron JMS567 enclosure. If both drives are connected to the sata adapter (and nothing on usb), I get filesystem corruptions at random intervals (ie it looks like a power failure). If the HDD is on sata and the SSD on usb3, everything works fine (as for the last 5 months). My power supply is the 12V, 5A from the pine store. I also had major power issues in the past only using a Samsung 840 Pro in the same JMicron enclosure connected to usb3 (and without any sata adapter connected to the system). It would work fine for a few hours/days and then I would have a major filesystem corruption (where the only practical option was to restore everything from backups since most of the directory structure and files names had been lost). And by the way, I use the system headless and I don't have any wifi/bt card. So the power supply should be able to deliver enough power for these two disks and the main board (it could in theory go all the way to 60W!) but somehow, the power delivery to either usb3 or sata is limited...

@soerenderfor My ASM1062 sata controller works fine, I have used it for 5 months now with a few different kernels (Ayufan's 5.3 kernel, Armbian's 5.4 and Armbian's 5.3). The only problems that I've had are related to power delivery: with one hdd, everything works fine. With one hdd on sata and one ssd one usb3, no problems. But with one hdd and one ssd on sata, major filesystem corruptions on the ssd more or less at random. This really mirrors the issues I had with some ssd drawing too much power off the usb3 port. So I understood it as yet another voltage regulation problem: on average, the ssd fits within what the voltage regulator can deliver. But every now and then, it draws a little more, the voltage regulator can not keep up and lets the voltage drop too much and the ssd stops working because the voltage is below a given threshold, leading to a possibly massive filesystem corruption (if the ssd was shuffling files around, it'd be the worst time to suddenly loose power). Of course, the whole things still fits within USB3's specs... So, my take remains: SBCs like the rockpro64 are great little beasts but there is no good voltage regulator to be seen anywhere, so you can not expect a usb or now even sata device that works in the traditional pc world to certainly work in the sbc world...

@soerenderfor I have this PCIe -> Sata adapter: https://store.pine64.org/?product=rockpro64-pci-e-to-dual-sata-ii-interface-card (and lspci gives me: SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)).