We didn't identified this situation. We would be glad to get reports on Github, but anyway we will try to bisect problem and see what is going on. We probably will not manage to introduce that in coming release (10 Dec). Sorry for delay, but we had higher priority issues.

---

pietrushnic - Posted 25 Hours Ago

 

We didn't identified this situation. We would be glad to get reports on Github, but anyway we will try to bisect problem and see what is going on. We probably will not manage to introduce that in coming release (10 Dec). Sorry for delay, but we had higher priority issues.

 

---

I can't wait to see the release notes to see what was a higher priority than "no current firmware can reliably reboot"!

VAMike,

feel free to read those here: https://github.com/pcengines/coreboot/blob/release/CHANGELOG.md#v4807---2018-12-03

and here: https://github.com/pcengines/coreboot/blob/coreboot-4.0.x/CHANGELOG.md#v4022---2018-12-03

Please note we working on reboot issue, but using big generalization and saying all reboot issues for PC Engines are the same is wrong. Please follow this thread for better understand of topic: https://github.com/pcengines/apu2-documentation/issues/64

Also here: https://github.com/pcengines/apu2-documentation/pull/108/files

If you have constructive critique we are open to that. As I already informed we feel free to contribute, this can be anything documentation, debugging, testing or code.

---

pietrushnic - Posted 7 Minutes Ago

 

feel free to read those here: https://github.com/pcengines/coreboot/blob/release/CHANGELOG.md#v4807---2018-12-03

and here: https://github.com/pcengines/coreboot/blob/coreboot-4.0.x/CHANGELOG.md#v4022---2018-12-03

Please note we working on reboot issue, but using big generalization and saying all reboot issues for PC Engines are the same is wrong. Please follow this thread for better understand of topic: https://github.com/pcengines/apu2-documentation/issues/64

Also here: https://github.com/pcengines/apu2-documentation/pull/108/files

If you have constructive critique we are open to that. As I already informed we feel free to contribute, this can be anything documentation, debugging, testing or code.

 

---

My main critique is that whoever is setting the priorities needs to put "sometimes hangs on reboot" much higher than things like

• experimental option for adding microcode update
• enabled PCIe ACS and AER capabilities
• COM2 redirection runtime configuration

Yeah, it's hard to reproduce--but all that means is that anybody who's trying to take advantage of any of the work done in the past months could at any time render the system non-responsive if they reboot, even if it's never happened to them before. What's the point of adding new features or fixing other bugs if it isn't safe to reboot the system if you install the firmware that adds those features or fixes those bugs? It's been more than a year since this problem was introduced, and months since it was added to release notes as a known issue. "Sometimes hangs on reboot" is a showstopper, "drop everything else until it's fixed" bug, and as usual for pcengines there hasn't been any sign that this is being taken seriously.

 

VAMike,

I'm not PC Engines employee: https://pcengines.github.io/about.html

I'm setting priorities for PC Engines firmware development. I'm fine with your opinion about setting priorities incorrectly, but still it is subjective opinion.

I wonder if users who wanted to get rid of Spectre problem agree with your judgment about setting priorities.

Anyone can always try take over firmware maintainership for PC Engiens and set prioriteis "correctly". Also if you feel personally you can provide better support I'm fine to talk about some agreement. Just book a call https://calendly.com/3mdeb.

As I wrote we are not ignoring reboot issue. And TBH I can't burn all resources on issue that has no reasonable reproducibility I have to move also other things.

Please note we are not working on PC Engines firmware full time.

---

pietrushnic - Posted 60 Minutes Ago

 

VAMike,

I'm not PC Engines employee: https://pcengines.github.io/about.html

I'm setting priorities for PC Engines firmware development. I'm fine with your opinion about setting priorities incorrectly, but still it is subjective opinion.

I wonder if users who wanted to get rid of Spectre problem agree with your judgment about setting priorities.

Anyone can always try take over firmware maintainership for PC Engiens and set prioriteis "correctly". Also if you feel personally you can provide better support I'm fine to talk about some agreement. Just book a call https://calendly.com/3mdeb.

As I wrote we are not ignoring reboot issue. And TBH I can't burn all resources on issue that has no reasonable reproducibility I have to move also other things.

Please note we are not working on PC Engines firmware full time.

 

---

I'm confused. So you're doing this as a volunteer effort? PC Engines is doing nothing to support the firmware on their products? In that case clearly the criticism should go elsewhere--I'd thought that PC Engines had finally realized that abandoning the responsibility for firmware support was unacceptable and had contracted out the support, but if it's still the case that they're just doing nothing that's a real ongoing problem that needs to factor into future purchase decisions.

As far as spectre--yes, I'd expect that those users would agree with my priorities. 1) microcode was already runtime-updatable on the OSs likely to run on this hardware making this a "nice to have" rather than a "must have" and 2) they still have to decide if they want boot-time microcode updating or the ability to reboot. If they do disagree they may not realize that "platforms happen to hang after reboot" means that it's not safe to ever reboot unless prepared to power cycle the machine.

VAMike,

as written on "about" page we provide support as part of coreboot Maintainership Package, which is paid service. And your correctly address your complains for almost 3 years we are fully responsible for PC Engines firmware.

I think if you can convince PC Engines to not provide any firmware update until reboot issue will be root caused and fixed then we are fine going your path and burn all cycles on that.

We always trying to do research in open and provide as much details of our discoveries to the public - anyone can pick that. We always try to be honest and provide high quality support. I understand your arguments and will do anything we can to adress things, but I hardly see how your offensive posts help solving the problem (and probably I would gave up if this would be first time). There are many that helping us narrow down the problem on Github. If we can count on your help then please involve, if we can't  then I have nothing more to say.

Don't worry, I think I've resolved any lingering questions about whether to keep buying pcengines products or whether it's time to find another solution. Sorry to have offended.

First of all:

I'm writing from a private user perspective,
so my wishes and expectations obviously differ from those, who use PCEngines
products in a commercial environment.

That aside: Thank you very much for your work, it is appreciated.

I'm using a few APU2 Boards for AccessPoints and Routers with Linux and BSD.
So many of those improvements will also help me.

What's confusing me about the new 4.8.0.7 release: There are NO "known issues".
While an error-free firmware might be the goal, I find it highly unlikely,
that you squashed all those bugs.
On the other hand, you really did apply your regression tester, so it may be
the truth.

I'm looking forward for new releases!

publnamme,

thank you for words of support we definitely appreciate that and will continue good job since community feedback drives us positively.

In case of known bugs defintely we didn't fixed all bugs :) That's new bug introduced by our content marketing team :) We will fix that ASAP.

BTW for others tracing this thread we have 2 new releases:

v4.0.22

v4.8.0.7

Main achivements are:

- runtime COM2 redirection

- custom microcode patching for spectre mitigation

We still working on reboot issue, it is very hairy. If theory about working legacy firmware v4.0.x series is true (there are no real evidence for that) we may be able to port and validate some changes that are present in legacy but not in mainline. Stay tuned. More info:  https://github.com/pcengines/apu2-documentation/issues/64