Jump to content

Debian 4.9 Odroid C4 + OMV 5 Log Entry Error


Recommended Posts

Posted

I am running an Debian Buster 4.0 with OMV5 - the error logs happens to log this error steadily: 

 

odroidhc4 kernel: [   84.894025@0] drivers/amlogic/efuse/efuse_hw64.c:_efuse_read:202: read error!!!

 

What would this be?

Posted
8 minutes ago, torx said:

I hope this is enough


I don't know and this problem doesn't bother me. This is base procedure - without logs probably nobody will do anything about. I can only give you recommendation to use modern 5.9.y / 5.10.y kernel based images for HC4. Fixing bugs in Hardkernel private kernel is not going to happen.

Posted
9 hours ago, torx said:

noob here

https://www.armbian.com/bugs/

You were asked to follow this form in order to create a proper issue report. Preparing necessary logs is a part of this procedure. Why do you ignore our requests while requesting support for you?

Posted

WernerL Hi - thank you for your reply.  I hope you had a nice day.

 

The reason I ignored your request is to specifically ruin your life.  As:

 

1 I don't know if this is a bug or not because if it a normal process that i just never noticed it would dismissed and everyone would have a nice day, do I never saw the https://www.armbian.com/bugs/ dialogs. as this is a question, i am not reporting a bug.

 

2 Even if I did use the https://www.armbian.com/bugs/ dialog I never would have made it past the "HARDWARE/SOFTWARE ISSUE" dialog because neither of the choices fit the actual question.

 

3 As a "noob", as you quoted, all I really see is "WHAT" you need, not "HOW" to get it.  I used the tool, which gave me a "NOT FOUND" when i pasted a URL, which URL? I tried many that didn't work. So then I have to find out how to download the data to a file, which I did but it turns out it's so long that it doesn't fit into the pastebin service, hence my message about that i had to truncate the logs and I asked if that is enough information to go by.

 

4. Igor had mentioned that the issues in the log where probably not going to be addressed as it seems focus in the 5.9 kernel.  Which I then tried and seems to have solved this issue.  This is fine and good answer. I tried to say thank you and close the issue but I cannot make a second post for 24 hours when you jumped in and I thank you for it.

 

TL:DR Thank you for your time and energy you put into this and I will address my questions to other forums, thank you!

Posted
3 minutes ago, torx said:

Igor had mentioned that the issues in the log where probably not going to be addressed

 

We have to save resources from IMO unimportant cosmetical problems and especially on a dirty private kernels / dead ends. This is probably some smallest problem there and especially when we can provide better community supported modern hardware interface / kernel. Which I highly recommend it to you.

 

Any support request is a direct financial blow for us and there is a big line of people waiting and hoping we will focus on the bug they have problem with. Also not all bugs are a part of our area of (best effort) support https://github.com/armbian/build#support Since you don't support R&D you can't really demand support or file bugs, right?

 

This is forum, not some all-round Linux technical support. Post limits are gone in  a week, if you make a valuable contribution or show that you care. When week of your limited / mainly read mode is around and if you pay attention, you will probably and hopefully realise how things are around here. If you politely and kindly asks for help, you have to wait in any case, since there are 1000x more people that takes, then those that tries to give something to our common community software.

 

Problem will probably not be addressed by Hardkernel neither since its IMO harmful / cosmetic and they are even more limited. But they will probably say "yes". Things as such are usually never fixed, usually just masked - this is common MO with vendor software support ...

 

We provide images (legacy) with that same (dirty) kernel only until they have some significant functional advantage / value that someone could use it for. For NAS use case, stick to our mainline kernel as recommended. Its not fully without problems - no other kernel is - but you won't find anything better.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines