Mathias

Members
  • Content Count

    31
  • Joined

  • Last visited

About Mathias

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Schweiz/Suisse/Svizzera/Svizra
  • Interests
    Debian on RockPro64

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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).
  2. 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.
  3. 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
  4. 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...
  5. 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
  6. 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
  7. @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...
  8. @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...
  9. @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...
  10. @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...
  11. @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)).
  12. @soerenderfor with my Armbian dev kernel (ie 5.4.0-rc1-rockchip64), if I do 'cat /sys/devices/platform/pwm-fan/hwmon/hwmon0/pwm1' I get a number (30 right now: I use ATS with a minimum speed of 30). So for me, it works with the dev kernel. I am also using the original nas case with the original fan and the medium or tall heatsink. Most of the time, it does nothing so I leave the fan on 30 as a minimum and it ramps up if things get busy. I usually have cpu temperatures around 38-40C too (I use the hard drives for backups, so the system gets to work more at night and then I want to make sure that there is always some ventilation to keep the drives cool enough even if the cpu does not get too hot).
  13. We talk about test of different parts. It was orginal one topic but split. The other is https://forum.armbian.com/topic/12936-how-to-control-fan-on-rockpro64 @deathisunknown Which kernel are you using? 5.3.xxx? Until this week end, I was using Ayufan's kernel in order to have ats working (I have the nas box with a harddrive so I want to have some ventilation). I've switched to Armbian's current kernel (5.3.xxx, I don't remember the exact subversion) and noticed that the fan would not spin. Then I tried Armbian's dev kernel (5.4.0-rc1) and my fan works fine. I stumbled upon this thread in the mean time, but since as I remember the latest current kernel got compiled in November, it would not have this change included. On the other hand, I did not call "modprobe" while (quickly) testing the "current" kernel so It could have been there but I missed it...
  14. Hi! I'm using Armbian with Ayufan's 5.3.0rc4 kernel (until ~1 month ago when I decided to freeze the dev kernels, they were not able to expose the pwmon for the fan that I need to keep running to cool my nas case). But I've seen lots of updates flying around about uboot. So I am wondering: are there significant improvements to uboot? I am currently using an old version of uboot on the SPI flash (so it is a little painful to test new version) and I am wondering if I should disable my SPI in order to have uboot on my emmc (to boot off the emmc) or if there is even a newer option to reflash my spi with a newer uboot... Thanks, Mathias PS: so far, every time I've reflashed my SPI with Ayufan's sd-card image, it was very, very slow and I never got any visual feedback so I had to leave it for several hours to be sure it would work
  15. By the way, I've found another bug with the dev kernel (5.3.0-rc4): there is no possibility to control the fan anymore (/sys/class/hwmon/hwmon0/ does not exists anymore). It works fine on Ayufan's 5.3rc4 but not with Armbian's dev kernel.