Tests, tests, and more tests.

[Djoga'Ro]

Certainly sounds like a powersave issue. Modules/hardware loaded and trying to work without enough power freezes. Disabling the modules saves some power, but eventually some process needs more power then it gets and freeze.

So, you're saying instead of a powersave issue it's more of a back-to-full-throttle issue?

 

[Xcl4m4t10n]

So Pyra is now vaporware?

 

[Silent-Hunter]

Who said that?

 

[levi]

Well, unfortunately, it improved the situation but it didn't fix it.
This probably also is the reason why the full apt-get upgrade for Nikolaus worked. As long as the Pyra is not idling, it doesn't freeze.
So it could be related to some powersaving that's triggering (with such system, powersaving already triggers when there's only 1ms of idling happening).

You mentioned on the mailing list that the SoC gets quite hot while it's frozen, so it's almost certainly in a tight loop going round and round and doing nothing while stopping the SoC powering down at all. I don't think it's getting stuck in a low power mode, or receiving a dodgy clock that's stopped the pipelines triggering or anything like that, but it could still be preparing to powersave when it hits this loop.

Actually, I don't know if a loop tight enough to fit in the top level cache will be sufficient to make the unit settle on a warm enough equilibrium to feel positively hot. So it might need to be a slightly larger loop that causes cache flushes, or gets some power hungry component within the SoC into some indeterminate state that churns current.

 

[ClockworkCoder]

You mentioned on the mailing list that the SoC gets quite hot while it's frozen.

Took me a couple of reads before I made sense of that!

I wish I had more to offer in terms of useful input. I'm really impressed how hard people are working to resolve this. Times like this show how fantastic the community is here.

 

[PowerGod]

Times like this show how fantastic the community is here.

Because it's like an endless stream of news !! And we can quench our thirst with it !! (...sorry, but I can only contribute with some spam )

 

[Silent-Hunter]

I wish I could help too, but I only know a small amount of C and Fortran, I'm no kernel developer.

 

[Wally]

Have you tried plugging it out/in again?

 

[error]

Have you tried plugging it out/in again?

Once I called my ISP because my Internet connection was down. They asked me to reboot my computer. I politely informed them that none of my computers were turned on. They advised me to please power on a computer, so that I could reboot it.

 

[Coupo]

... impissible ... (35c3).

I like this typo

 

[Djoga'Ro]

How do power state changes work, anyway? Does the software issue a special instruction or write some specific value to a particular register and the SoC does the rest? Or does the software have to handle some management around it, too?

 

[AndiTheBest]

How do you check the kernel log when its freezing? Look at the logfiles, or is a serial port connected? A serial log may put out more infos before freeze than writing a logfile.

 

[bukkit]

Well, unfortunately, it improved the situation but it didn't fix it.
After 3:10 hours, it froze again.

That's sad, but it doesn't make your planned test (loading drivers, trying for 15 minutes) useless. You could still fence in one issue wit that method and reduce the problem's overall complexity.

 

[levi]

@AndiTheBest Serial console out over the microUSB2 charging/debug port, I think I've read.

How do power state changes work, anyway? Does the software issue a special instruction or write some specific value to a particular register and the SoC does the rest? Or does the software have to handle some management around it, too?

As far as I can tell, it's largely implementation dependent. The ARM core spec doesn't provide any commands to suspend anything or change the clock speed, but I guess TI have either implemented coprocessor instructions or a special location on the memory map that allows software to control this stuff. It's not like the i686 world where different suspend modes are implemented in the silicon, so you likely at least need to slow the clock, and bring various subsystems down from live. How much of that is implemented yet remains to be seen though; I remember Notaz got some extra hours of idle out from the Pandora by stopping powering the system's 5V rail (for USB power out mostly). As far as I remember during the OMAP3 days with the Pandora we got the dynamic clock through the ondemand governor, and everything else was coded by Notaz though, and it seems like linux these days is slightly more advanced at scaling things back when running on ARM boards out of the box.

 

[EvilDragon]

...and it could be Tony found the reason. At least it seems to be working fine with his unit now - I'm waiting for Nikolaus to compile me the updated version so I can test it on my unit.

 

[zedr0k]

...keep my fingers crossed... great news

Gesendet von meinem Aquaris M5 mit Tapatalk

 

[Grench]

And thus was the great crossing of fingers and the repeated pressing of F5 with pinkies such that fingers need not be uncrossed...

 

[BeMoreViking]

Not sure I understand the post on the mailing list. Anybody know what "DLL timing" is, or what "disable internal DLL trick" means?

 

[TrashyMG]

DLL in this sense means Delay Locked Loop, not the crap Windows libraries. It's memory timings and what not.

 

[Silent-Hunter]

Here's an article for your convenience.

https://en.m.wikipedia.org/wiki/Delay-locked_loop