Date suddenly changed to 2114

Started by mossroy, October 16, 2019, 12:42:30 pm

Previous topic - Next topic

LubOlimex

Technical support and documentation manager at Olimex

mossroy

Sorry, but I can't help without a proper changelog, and some cooperation.

Thanks for the 2 URLs you provided but :

I'm asking for some communication when a new release is out : give us the information, and a changelog. For now, I did not find any other solution than manually "polling" http://images.olimex.com/release/a64/ , and test random things.

The ping issue seems to be fixed in this release. That's good news, and would be worth mentioning in a changelog, don't you think?

It seems that the default governor is "performance" in this A64-OLinuXino-buster-minimal-20210127-100834 release (probably as a workaround for the time issue, like you mentioned earlier)
I wanted to test it with "ondemand" governor, to check if the sluggishness was gone with it or not, but this governor is not available any more :
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative userspace powersave performance schedutil

On older versions, it was there :
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative userspace powersave ondemand performance schedutil

Is it on purpose? Did you check that the symptoms of https://www.olimex.com/forum/index.php?topic=7976.0 are still there with this release if the governor is set to ondemand? We can not test by ourself any more.

NB : I'm still available for the discussion you mentioned, but you need to help us to help you. Else I'll give up

LubOlimex

5.10.10 branch was removed because it had critical bug and new 5.10.12 branch was made. Maybe just go here:

https://github.com/OLIMEX/linux-olimex/commits/

As far as I understood from the developers, there are two options:

- different scaling governors and date jump bug present
- only performance scaling governor and no date jump bug present

We went for #2 in this release.

Change log is not coming, it would be the same as commit log. It makes no sense.

QuoteI'm still available for the discussion you mentioned, but you need to help us to help you. Else I'll give up

What do you mean or expect? I thought this exchange is the discussion.
Technical support and documentation manager at Olimex

mossroy

I'll try to rephrase.

The boards I bought are used in production.
After 2 years, some of them are still not stable, and the other ones use old versions (without security patches on the kernel)

Yesterday another board became unreachable because of a time jump (I had to reinstall it last month with A64-OLinuXino-buster-minimal-20200601-131837.img, it used kernel 5.6.14, which I thought had the time jump fix)
I have another board that I reinstalled recently with A64-OLinuXino-buster-minimal-20201207-193928.img (kernel 5.10.10), but you just said here that it has a "critical bug" (what is it? which impact? which workaround?), and that we should use A64-OLinuXino-buster-minimal-20210203-221802.img (kernel 5.10.12) instead.
Now I see that the 5.10.12 branch has been removed too, and the image has been replaced by A64-OLinuXino-buster-minimal-20210210-151806.img (kernel 5.10.14), with no explanation. Did it have a critical bug, too? When should I expect to have a good image?

Please try to put yourself in my shoes : images and branches appear and disappear, some have critical bugs but I don't have more information. Existing boards have some kernel upgrades through your repository, so they will probably get the critical bugs if I upgrade them?
What should I do? Reinstalling them with the latest image seems unsafe for the moment, plus I can't do that every 2 weeks! Upgrading the existing boards might be unsafe too (plus regressions happened in the past), but I can't keep old kernels because I also need security updates.

This situation puts me in the state of a beta-tester (which is not expected after 2 years, and not compatible with production), without even enough information to beta-test (see below). As I said earlier, I was an Olimex supporter, but this situation is not acceptable.

Having a change log (sometimes called "release notes") would make sense IMHO. It's good to have the commit log, but it does not seem to provide some other crucial information :
  • the fact that some images have a critical bug, and what people using it should do (we can't reinstall all the time)
  • the changes between 2 images : the commit log seems to be a rebase of your patches on each kernel version. So it's almost the same between 2 releases : it does not provide a summary of the changes between 2 releases (especially when the previous branches are removed)
  • the changes that are not in the kernel, like removing a scaling governor and forcing another one
  • the intentions behind these changes. A commit log on github is very technical and does not explain why these changes are done, what is the expected result etc
  • the steps that are required to have a working board after installation, like disabling the display to have a stable network, as mentioned here : https://www.olimex.com/forum/index.php?topic=7921.msg29820#msg29820
Release notes might also avoid some questions asked in this forum, and time wasted on both sides.

If a stable image is finally released, the subsequent kernel upgrades should be safe too (i.e provide only the security patches, or be very carefully tested before putting them in your repo)

If you think all of this is out of reach in a short delay, I'm asking for a refund and will stop bugging you here.

NB : Regarding the "performance" governor, I'm concerned about its impact on CPU temperature (in the summer) and lifespan, but I might be wrong.

olimex

Hi,

Your questions have reason, and I ordered change log to be add to the images.

The time jump is hardware processor related. The random nature of appearance means that this will be hard to impossible to work around. All A64 boards on the market suffer from it.

Our developers do their the best. Having your feed back help us to improve things. They are notified about this post.

Tsvetan

mossroy

I saw that there is now a changelog here : http://images.olimex.com/changelog.txt

That's good news, thanks.

Unfortunately, you're still trying to rewrite history : the changelog of an image has been removed :

Yesterday, there was an image called A64-OLinuXino-buster-minimal-20210317-113356.img.7z in http://images.olimex.com/release/a64/, and it was appearing in your new changelog. By memory, it was mentioning the kernel upgrade to 5.10.23 and another change regarding stm32.
Today, there is another image called A64-OLinuXino-buster-minimal-20210318-122357.img.7z, and the changelog has been rewritten : there is no mention of 20210317 any more. Its changes have been apparently "merged" with the changes of 20210318.
And the corresponding branch has also disappeared from github :-(

Why do you do such thing?
When your users have downloaded and installed 20210317, what should they do when they discover that their version is not in the changelog any more, not in github any more, like if it never existed?

I suppose there was a problem in this image, and you quickly replaced it with 20210318? In this case, leave version 20210317 in the changelog, add an explanation of what was wrong with it, and explain us what we should do if we already installed it : is an "apt update && apt upgrade" enough, for example?

Again, put yourself in our shoes : your images are installed, they are used by real people that need to maintain the software running on it, and that can not reinstall all their boards every day.

I don't blame the developers here. I blame the poor communication, especially when you repeat the same mistake I explained in my previous post here (making a released image "disappear" with no information on what to do for people who used it, just like if it was a temporary beta version)

mossroy

By the way, the dates seem wrong in your http://images.olimex.com/changelog.txt : they are all in 2020. I suppose you meant 2021.

I would also advise to make this changelog more easy to find. For example you could put a link to it in the pages where you provide links to images (like https://www.olimex.com/Products/OLinuXino/A64/A64-OLinuXino/open-source-hardware)