Jump to content

TheLinuxBug

Administrators
  • Posts

    97
  • Joined

  • Last visited

Everything posted by TheLinuxBug

  1. Hello, Thanks for reporting this, it should now be resolved. Please do let us know if you see any further issues. Cheers!
  2. Hello @mcfo Thanks for your interest in Armbian! We are currently working on making changes to allow for more (internal) man hours to be spent on reviewing and updating things like Distrowatch, providing more regular updates to our media partners and working with the community to help improve Armbians public facing image. We always welcome help from our community and I would be happy to discuss with you your ideas on how we can more proactively provide announcements and updates to media outlets (such as Distrowatch) and/or how you could help Armbian in this aspect. Please feel free to drop me a private message and we can discuss this in more detail. I hope to pick up and work more actively on issues like this for Armbian, so maybe we could find a way to work together on this issue? Cheers!
  3. @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!
  4. 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
  5. 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!
  6. 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!
  7. @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!
  8. @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!
  9. 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!
  10. 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
  11. @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!
  12. @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!
  13. 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!
  14. 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!
  15. 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!
  16. 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!
  17. 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!
  18. @guidol Good news and medium good news. Here is u-boot, kernel and dtb needed to enable eth0 and have it work: https://licheepizero.us/licheepizero.linux-4.12.with.vga.and.eth0.tar.gz http://prntscr.com/nhuq6f http://prntscr.com/nhupqd http://prntscr.com/nhupv3 The uboot has vga and eth0 enabled, however, the current versions of the WiFi module that are around do not work with this kernel and while VGA is in the uboot, it isn't active in the kernel in this. If your goal is to boot up and have eth0 up and access, this should work for you. I am going to test building 4.14.y and 4.13.y branch to see if the WiFi driver is incorporated at any point, the github repos are not very specific about whats been updated and my attempts to build the driver seperately have so far failed for the 4.12.y repo I used to generate this. This should at least be enough to get you started. Once i test a bit more I will upload my .config and provide a link as well. Cheers!
  19. Yeah, having a serial UART is pretty important for working with this board unless you have one of the VGA breakouts or something where you can see whats going on. Cause I don't think these images are setup in any way to otherwise be default accessible. I doubt you will get any feedback on the USB port with the image, however, it may bring up ethernet... can't recall though and if it does, it is likely with a predefined static IP. You can probably mount the image using a loop device on your local Linux machine and take a look at things inside to get a better idea. Maybe a little later today I can pull it out and play with it and see if I can come up with something better for you. If you really want to motivate me to test it, you are best to come to IRC and bug me about it, lol. Otherwise I do have a huge list of 'other things' I will probably start working on first. Cheers!
  20. @guidol You will need to use Google translate but the document you want for ethernet is: https://www.kancloud.cn/lichee/lpi0/327886 It may take compiling your own kernel with the driver built in. To be honest I think I got around this at the time I was testing by using an image produced by Zeepan for my use with Cameras which I believe had ethernet already enabled. Don't quote me as saying this should work, but you could test this image: https://licheepizero.us/lpi_zero_cam.zip You should be able to unzip and then DD that to an SDcard and boot it. It should provide, I believe, ethernet, VGA and camera interfaces already in the kernel if I recall correctly. (I have a VGA adapter board and a few other items I still need to add to the site for reference when I have time). P.S. If you don't have an irc client installed but wish to join the irc room briefly there are now web based clients you can use, you can follow this link: https://h3droid.com/chat-with-us to and it will tell you what to do. Maybe this will help you? Cheers!
  21. Hey Guys, I spent time over the past two days updating https://licheepizero.us and if you visit the site and use the navigation at the top right I have added some simple how-tos for certain things as well as have included better links to the resources you need. This includes the dock.dtb file your looking for, if you look through the wifi setup page, I believe it is linked at the bottom: https://licheepizero.us/setup-wifi-for-licheepi-zero As some of the Chinese resources have been slowly going down, I am trying to replicate the how-tos into English and add pages so that they will not be lost. If you guys come up with anything that would be good to keep on there that I am missing, please PM me here or send me info using the Feedback form on the page. Also if you get stuck on something, I will try to keep checking back here and offer suggestions as I can. @guidol if you get stuck and your familiar with IRC you can come on Freenode irc network and join #H3Droid and I will be happy to try and help you some with getting things working, as I know just how frustrating the thing can be. Have a great weekend! Cheers!
  22. Assuming you are not talking about the OLD Sunvell R69 model with 1gb ram, 8gb eMMc and you are talking about the newest version with 2GB of ram: You must have gotten lucky, mine won't boot normal images with regular settings, seems I got one with shitty ram modules that are way under-clocked like some others have. Additionally, the board has NAND not eMMc, this is why you can't see it and you won't be able to. There is no support for NAND in Linux, there is only a proprietary FTL driver implementation that is licensed which Android manufacturers use, such as in this case. So while you can boot other Linux images and such off SDcard you won't be able to use the NAND except with their specific image, sadly. Cheers!
  23. To note, if you check that Youtube video there seem to be a lot of people in the comments there observing the same issue. They state they also have this exact same board and it won't boot at all either. I am guessing bad quality memory, like in the last box, except in the last box it simply prevented any good use of 1080p cause the DRAM wasn't fast enough. In this version is seems it causes the need to likely set DRAM super low for it to boot. Will probably take using uboot/fex for OPi Zero +2 and trying to figure out something usable from that. I really wanted to get H3Droid working with this board for our next release but at this point with the mix of quality / revisions that are possible this may be in vain, because even if I get it working, may not work for others. No going back now though... will just have to keep at it! Cheers!
  24. Super odd! They must have made revisions of this board and some are different. I promise you mine will not even boot that Beelink X2 image mention in the video. The ONLY think I have gotten to boot was OPi Zero +2 image and its severely crippled. I will post images of mine below, maybe there is some subtle difference I am missing? So far my link seems limited so I am guessing they made some change mid-run of these, like using sub-standard memory that needs an extremely low DRAM setting to operate. Only thing that seems to make sense as to why all other images won't boot. Will continue to update if I make any progress here. Cheers!
  25. @Jani-Matti Thanks for the video, I now understand what you were saying better, the Armbian image for Beelink X2 should supposedly work. I am actually going to test that one now and will report back if I am successful or not. Thanks!
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines