TheLinuxBug

  • Posts

    58
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    United States of America

Contact Methods

  • Website URL
    https://h3droid.com

Recent Profile Visitors

1962 profile views

TheLinuxBug's Achievements

  1. @piter75 anything I can do to influence you to spend some more time on the RockPi 4c, namely: - Getting all 4 USB ports working on legacy image - Getting mini-DP port working on legacy and / or mainline kernel @TonyMac32already did a good bit of poking and testing at patching mini-DP in mainline for RockPi 4c and I have been helping test as possible. If you get some time to poke at this I am happy to test things (am on IRC ( [TheBug] ) or you can PM me here anytime and I will be happy to test things, have one on my desk). Also, a friend of mine also has one and I can have him test as well if you let me know. I am happy to put some type of bounty either to be donated to Armbian or to your beer fund to get this pushed up the list a bit... I got at least 30$ on it Cheers!
  2. Hey Werner, I went ahead and escalated this issue to Innoscale's NOC and they have been reviewing things this afternoon. It looks like at this time the NOC has pushed out some new routes which looks to have helped to resolve the loss being seen there and causing latent loading of the forum / site. Can you test a bit and let us know if things still continue to see issue via IPv6? I will sub to this so that and updates come to my inbox and can be addressed. Have a great day! Regards, TheBug
  3. Correct, though my idea would be that something happens with power delivery that either starves the board or the drives -- though that is hard to prove one way or the other without using a different power supply for the hard drives. Could be wrong, though, would help to eliminate that as a possibility in these cases. my 2 cents. Cheers!
  4. Interesting. Though as others are seeing freezes during heavy load, I am still curious based on all these descriptions if indeed there is some issue with the power supply there. However, someone will need to actually test that so it can be marked off as a possibility -- even in your situation it would likely be worth a test just to see. If there weren't so many saying there are lock-ups or freezes related to drives under load I would be leaning more towards the SATA controller -- though one would hope that it isn't that since it isn't something you can easily replace or test. Maybe attaching 1 drive via USB 3.0 to the board and perform the same functions -- though if 3.5 inch drives you would obviously need to have an adapter that provide will provide 12v power? my 2 cents. Cheers!
  5. @jbergler Do you have an ATX power supply you can hook the drives to and test powering them that way? As I mentioned in a few other threads, including: I believe this may be a power delivery issue under load. Someone will need to test using alternative power supply to confirm this though as I do not have one (Helios64). I have 2x RockPi 4c w/ m.2 to PCIe x4 adapter and an 8 port SATA card, one running 6x3TB mdadm raid other 9x2TB drive mdadm raid with one drive via USB 3.0 running 24/7 but I am using an actual ATX power supply to power all my drives, not a built on power supply like the Helios has. Of all the people reporting this, someone will need to test and confirm. -- root@rockpi-4c:~# uname -a Linux rockpi-4c 5.8.6-rockchip64 #20.08.1 SMP PREEMPT Thu Sep 3 18:03:42 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux root@rockpi-4c:~# uptime 13:13:59 up 10 days, 21:11, 7 users, load average: 0.10, 0.09, 0.09 root@rockpi-4c:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md127 : active raid5 sdi[0] sdg[1] sdf[3] sdh[8] sda[4] sdc[6] sde[2] sdb[5] sdd[7] 15627059200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [9/9] [UUUUUUUUU] bitmap: 0/15 pages [0KB], 65536KB chunk -- root@rockpi-4c:~# uname -a Linux rockpi-4c 5.8.6-rockchip64 #20.08.2 SMP PREEMPT Fri Sep 4 20:23:22 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux root@rockpi-4c:~# uptime 13:15:55 up 7 days, 8:05, 6 users, load average: 0.64, 0.21, 0.07 root@rockpi-4c:~# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] md127 : active raid5 sdc[2] sdb[1] sde[4] sda[0] sdd[7] sdf[6] 14650670080 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU] -- My 2 cents. Cheers!
  6. @kratz00 @FredK Actually, let me revise this after re-reading again. To note that when you have 5 or more drives running on the Armada 3700 series SoC like in ESPRESSOBin there are bugs in the DMA transaction process that can be hit which will trigger some weird events such as kswapd using 100% CPU and terminating all IO access, Kernel Panic, Drive failures reports by sata controller or a freeze. I have seen this predominantly occur during a raid reshape but it can happen at other times as well. On the ESPRESSOBin one of the things that can help get around this is if you are using mdadm and raid5 you can use the xor engine in the chip to handle DMA calculations and this will help to offload it under a lot of conditions. The module is 'marvell-cesa' on ESPRESSOBin, I would guess its is names similarly here. Especially with 5.x.y series kernels I have had to use this. I am currently running a raid of 7x3TB drives on a 8 port PCIe adapter placed into a mini-pcie to PCIEx1 adapter slot attached to the mini-pcie on the board. It is stable under 5.4.y or newer with that module inserted, otherwise under high load from NFS or local system for extended periods I will see errors first where it will fail to allocate dma requests in time and then shortly after system instability, usually resulting in any of the above mentioned outcomes. Maybe if you are not using that module you could compile it and see if it helps with this issue in the newer kernels. Past that it did sound possible if this isn't specifically something caused by change in kernel version like it could be related to bad SATA cable or under power. my 2 cents. Cheers!
  7. I hate to say this cause it won't be what you want to hear -- however, generally these errors are caused by only a few things: 1. Bad SATA cable 2. Bad hard drive 3. Bad SATA controller 4. Under powering the drives 5. Some really bad bug in sata drivers that causes reset (least likely as others are not reporting the same) A good test would be to see if you can use a hard drive you haven't tested with yet and using a new SATA cable to the drive to make sure. Also, you could try alternatively supplying power to the drives via an ATX power supply or bench supply and see if the same thing continues. It could be over drawing power under heavy load and causing the drives to reset when they don't get the right amount of power. You could also test this by running less drives at once and see if this helps to lower your power budget. I have seen this issue my self in a few deployments where I was using a power supply that was too weak to put out the needed 12v rail requirements under load and would cause the drives to drop out and the raid to fail them, so this is actually a real possibility. It could be that your drives are pulling more power than was expected in the spec. Hope this helps some. my 2 cents. Cheers!
  8. I am sure the community will be happy to review this in more detail for you. However, since you wanted to outline this I wanted to point out that this is a volunteer community of people, you are not paying for support and we all live in different countries and time zones as well, so your expectation of an immediate response and help on your issue in a short amount of time is a bit unrealistic. One of the main reasons I came here to open this interaction more is to help you maybe to understand this. You will get more assistance here by trying to be part of the community and being patient than bad mouthing those who do help here, for free, on twitter. As I have time this evening I will check through what you reported here. For someone to better troubleshoot would you be able to supply the software you are compiling / running there so that someone could actually possibly replicate the issue if time allowed? That would obviously be the most productive way to troubleshoot something like this. Unfortunately, while I have a few A20 boards I do not have the one you have, so that may also have something to do with it -- it could be that a setting in the DTS is too aggressive for the clocks or memory timings are set too fast for your board, for example. One thing you could test your self is getting the DTS from your previous working image and copying it over to the new one and see if with the older DTS you have the same stability issues. If one of the engineers made tweaks they thought would be stable, however the memory you have on your board just isn't up to handling that, it could potentially cause what you are seeing. Additionally, another suggestion that has worked for some people in buggy situations is enable the 'performance' governor instead of 'ondemand' and see if stability improves. In some cases there have been reports on some boards that because of possible settings introduced in the DTS you could be seeing instability at the lower OPP levels. Please feel free to try the above as well as provide additional feedback here and we will try to help you, as a community, as we are able. Have a great day! Regards, TheLinuxBug
  9. @destroyedlolo So I guess the twitter post was just to get attention and you weren't really serious about wanting help here, huh? *sigh* Cheers!
  10. @destroyedlolo Before you start complaining about us not supporting you on twitter, how about you actually give us some usable information to go from? Such as: - Which Armbian image are you running - you have stated this no where in your request? - Which kernel is it using - What are you doing when the Kernel panic occurs The only information you have given so far that is even reasonably helpful is the information about the libraries you installed. When not using those libraries and other (custom) software on the board, does this issue still occur? What additional steps did you take to debug this on your own? Did you hook up a UART serial adapter and review the console? All of these things are important if you want people here to respond and help you. Additionally, you are always welcome to come to IRC and ask for help, #Armbian on Freenode IRC network, there are a lot of active people there that may be able to help. You may also, since this is Allwinner, want to report the issue to #linux-sunxi as well as they work on the mainline kernel for Allwinner boards. Look forward to hearing back with more details and less accusations that we are unhelpful! my 2 cents. Cheers!
  11. My friend, I think I can propose what is your issue here, please do let me know how close I get: #1. When a sdcard is not booting and you boot from the onboard 8GB eMMc on the Sunvell R69 you will get the error you are seeing above, this is because the u-boot on the eMMc from factory is not made to boot from sdcard #2. While you downloaded the h3droid_installer.img.xz file, you did not decompress the image file with the program 'xz' or similar decompression program for your operating system #3. If you will try again and first decompress the file, then write it to the Sdcard with etcher and place it into the Sunvell R69 I think you will see a different outcome at boot time #4. My guess is also when using other images you may have also failed to decompress them as well. You may want to revisit Armbian images and make sure you have decompressed them with '7zip' or '7z' on Linux before you write them to the card. To clarify, if you fail to decompress the image and write it to the card there will be no u-boot and the data on the card unusable, so it will not boot from the card. If you have written the sdcard correctly, the uboot (bios) will be there and should start when you plug the power in for the board. It is understandable for someone new at this to miss this step, so don't feel too much shame if I hit the nail on the head. My hope is you will at least be able to get something booted. Good Luck! Cheers!
  12. Unfortunately this not the right place to discuss these issues. However, I would suggest you actually read the website instead of just randomly doing things. If you would have read, you would have use the H3ii image and used etcher or similar to write it to an SDcard instead of using the full installation package. If you read the site we have documentation for H3ii and H3resc on the site which you can use for a better understanding of those tools Cheers!
  13. Use H3Droid (h3droid.com) and install Armbian from H3resc menu. We provide the correct fex/uboot for the old h2+ 1Gb ram version in the H3resc uboot/fex selector. Cheers!
  14. Before I got a headache and quit the other night I was dealing with a similar issue. It looks like in the DTBs I was reviewing that the analog codec seems to want to use similar pins as the ethernet adapter. I am not well versed enough in how the DTB is to be formatted and how to map this differently as needed. I had one DTB hacked together which seemed to provide most things except USB and analog audio, but not confident enough in it to really give it out till I know its right. My hope is next time I get a chance to bug a few devs I know and get it working as expected. When I get there, I will share that with you as well. RE: @martinayotte this is actually the info I was looking for, thanks for that! At least got me pointed in the right direction of what to look at. @guidol if you want to mess with it your self, what @martinayotte said should get you started. Cheers!
  15. Yes, most of the devices are controlled by the DTB file, in fact, I compiled the 'staging' wifi driver and played around with enabling WIFi in the new DTB. I actually added the wrong DTB to that tar.gz after all was said and done, like you noticed, sorry about that. I was kinda rushed when I put that up. I did compile a few more kernels and was talking to some devs about trying to get some help with getting devices enabled correctly in the DTB. I actually have a DTB that works for enabling vga framebuffer, ethernet and wifi however ends up breaking USB (assuming your powering through pins, you can actually connect a USB device) and the staging driver in 4.12.y is trash and the kernel panics when you inset the WiFi driver. Glad to hear you found a working dtb for your needs, supposedly there were a few in the packages as you noticed with different things enabled. As I get time I will probably compile a few more kernels and work on the DTB and will post back here if I come up with something better. Though glad to hear what I provided gave you a good start! Cheers!