• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

G610X Weird Observations (Kernels, ROMS, Bugs, etc.)

Do you experience the same as well on your on7xelte?

  • Yes, matches with the case/s below!

    Votes: 4 66.7%
  • Problems exist but not matching with the case/s below...

    Votes: 1 16.7%
  • Nope you're on your own! No problems here!

    Votes: 1 16.7%

  • Total voters
    6
Search This thread

andikanexon

Member
Apr 13, 2016
17
4
Current settings with most stability on Ares Kernel on Device A so far:

CPU:
- Big Cluster min 343 and max 1794 with OndemandPlus governor
- Little Cluster min 343 and max 1690 with Interactive governor
- Enable scheduling workqueues to active cores for power efficiency

Hotplug:
- Enable AutoSMP and leave at default settings

HMP:
- Up and Down Threshold both at 1024

GPU:
- Max 1001 min 343

Voltages:
- Keep at default values

Other settings:
- Change to your liking; not likely to affect stability or induce problems on Device A
Even i cant open hktweaks after booting up xD.
Random reboots everywhere
 
  • Like
Reactions: Mightx
Even i cant open hktweaks after booting up xD.
Random reboots everywhere

Yep maybe it's setting cpu speeds on OC on boot. Just use simple kernel lol less headaches and decent performance just lacking in features. I only tried ares to find out all the quirks and nuances when using it on the device that apparently doesn't handle it well despite being one of the main target devices for the kernel.
 
  • Like
Reactions: trinaldi

trinaldi

Senior Member
Apr 19, 2013
142
25
Yep maybe it's setting cpu speeds on OC on boot. Just use simple kernel lol less headaches and decent performance just lacking in features. I only tried ares to find out all the quirks and nuances when using it on the device that apparently doesn't handle it well despite being one of the main target devices for the kernel.

How's the battery time?
 
How's the battery time?

On simple? Pretty much the same as long as you are comparing OneUI to OneUI and AOSP to AOSP ROMs can't actually tell the difference in battery backup between ares and simple. Around 3-4 hours SOT with mixed usage, 4-5 hours on light usage, or if gaming expect 2-3 hours SOT. AOSP ROMs have less standby battery drain though than OneUI...
 
Hmm observing the stats again, I saw that the device didn't necessarily reboot or lock up when temps hit 80c+ so it wasn't that or at least not fully because of that, unless of course the temps hit 90c+ but didn't show up on the monitor since the phone already froze before the UI can display the values from the sensors.

However, once the clocks on the big cluster are set to 1794 either manually or by default when device is woken up from sleep, the device will inevitably freeze a few seconds later, notably when some load is introduced such as turning on wifi, opening an app, etc...

So my suspicion is that since only some devices (Device A) exhibit this, I think it's a voltage issue for the OC clocks 1690 and 1794 on both clusters as I think the kernel might have been undervolted by default and this makes it unstable for some devices, particularly those that might have experienced notable silicon degradation and as such require more voltage to sustain clocks etc.

Possible mitigation might be to increase voltages by default on the higher clocks on future versions of Ares Kernel @bien2004official if that maybe the reason why devices are locking up (considering of course if it would be possible, feasible, and actually help in this regard)
 
  • Like
Reactions: andikanexon

andikanexon

Member
Apr 13, 2016
17
4
Hmm observing the stats again, I saw that the device didn't necessarily reboot or lock up when temps hit 80c+ so it wasn't that or at least not fully because of that, unless of course the temps hit 90c+ but didn't show up on the monitor since the phone already froze before the UI can display the values from the sensors.

However, once the clocks on the big cluster are set to 1794 either manually or by default when device is woken up from sleep, the device will inevitably freeze a few seconds later, notably when some load is introduced such as turning on wifi, opening an app, etc...

So my suspicion is that since only some devices (Device A) exhibit this, I think it's a voltage issue for the OC clocks 1690 and 1794 on both clusters as I think the kernel might have been undervolted by default and this makes it unstable for some devices, particularly those that might have experienced notable silicon degradation and as such require more voltage to sustain clocks etc.

Possible mitigation might be to increase voltages by default on the higher clocks on future versions of Ares Kernel @bien2004official if that maybe the reason why devices are locking up (considering of course if it would be possible, feasible, and actually help in this regard)
Nice observation sir, that might completely help devs to rebuild the kernel.

Hope my device A can use ares kernel as a daily driver 😂
 

TheRealModder

Senior Member
Sep 2, 2018
601
550
16
Denpasar, Bali
i just scrolled at xda and found this thread.

i can only argue about the brightness bug tho.

Ok, there's a file called "framework-res_auto_generated_rro.apk" or similar on /vendor/overlay.

You can add features, theming and even edit the system configuration.

And one of them is brightness.

And since J7 Prime is IPS LCD, the minimal brightness value for this is 4 or more.

And a lot of dev didn't care about this (sometimes even me [i like to call it "privacy protection" instead of bug]) because 80% of samsung phones with Exynos7870 chipset is AMOLED and the minimal brightness value for AMOLED is 0.

You can fix this brightness bug by re-placing it with stock one OR edit the overlay using Apktool X.

for the OC Kernels, for me it's really depends on your phone. One of old Ares testers even can handle OC at 1920mhz. and guess what? his phone is Y variant of J7 Prime (SM-G610Y) while mine (SM-G610F) sometime random reboot, but no more since bien fixed it on AresKernel Reborn.
 
i just scrolled at xda and found this thread.

i can only argue about the brightness bug tho.

Ok, there's a file called "framework-res_auto_generated_rro.apk" or similar on /vendor/overlay.

You can add features, theming and even edit the system configuration.

And one of them is brightness.

And since J7 Prime is IPS LCD, the minimal brightness value for this is 4 or more.

And a lot of dev didn't care about this (sometimes even me [i like to call it "privacy protection" instead of bug]) because 80% of samsung phones with Exynos7870 chipset is AMOLED and the minimal brightness value for AMOLED is 0.

You can fix this brightness bug by re-placing it with stock one OR edit the overlay using Apktool X.

for the OC Kernels, for me it's really depends on your phone. One of old Ares testers even can handle OC at 1920mhz. and guess what? his phone is Y variant of J7 Prime (SM-G610Y) while mine (SM-G610F) sometime random reboot, but no more since bien fixed it on AresKernel Reborn.

Yes I too didn't have any issues with the brightness bug as it is relatively easy to fix. What bugs me on the kernel though is that even if I set max clocks on big cluster to 1586 it stubbornly reverts to 1794 max whenever the phone is waken up from sleep. This causes the instability on phones like mine. Otherwise, oc kernels wouldn't have any other issues as users could set the clocks properly for what their phones can handle, and not auto oc even if not intended to as it causes instability.

As for the ares tester you mentioned, that may be why the Kraken kernel went up to 1920mhz before being brought down to 1794mhz on ares.
 
Last edited:

bien2004official

Senior Member
Sep 30, 2015
811
439
Bình Định
fb.me
Yes I too didn't have any issues with the brightness bug as it is relatively easy to fix. What bugs me on the kernel though is that even if I set max clocks on big cluster to 1586 it stubbornly reverts to 1794 max whenever the phone is waken up from sleep. This causes the instability on phones like mine. Otherwise, oc kernels wouldn't have any other issues as users could set the clocks properly for what their phones can handle, and not auto oc even if not intended to as it causes instability.

As for the ares tester you mentioned, that may be why the Kraken kernel went up to 1920mhz before being brought down to 1794mhz on ares.
kernel seems to be resetting cpu frequency in idle for you, which shouldn't happen by default.
 

bien2004official

Senior Member
Sep 30, 2015
811
439
Bình Định
fb.me
Hmm observing the stats again, I saw that the device didn't necessarily reboot or lock up when temps hit 80c+ so it wasn't that or at least not fully because of that, unless of course the temps hit 90c+ but didn't show up on the monitor since the phone already froze before the UI can display the values from the sensors.

However, once the clocks on the big cluster are set to 1794 either manually or by default when device is woken up from sleep, the device will inevitably freeze a few seconds later, notably when some load is introduced such as turning on wifi, opening an app, etc...

So my suspicion is that since only some devices (Device A) exhibit this, I think it's a voltage issue for the OC clocks 1690 and 1794 on both clusters as I think the kernel might have been undervolted by default and this makes it unstable for some devices, particularly those that might have experienced notable silicon degradation and as such require more voltage to sustain clocks etc.

Possible mitigation might be to increase voltages by default on the higher clocks on future versions of Ares Kernel @bien2004official if that maybe the reason why devices are locking up (considering of course if it would be possible, feasible, and actually help in this regard)
AresKernel has high voltages set on clocks that are higher than 1.6, and it can run on many devices, so your chipset seems not being able to run in that voltage.
 
  • Like
Reactions: Mightx
AresKernel has high voltages set on clocks that are higher than 1.6, and it can run on many devices, so your chipset seems not being able to run in that voltage.

Must be so. Helios seems to work fine on mine though at 1690MHz but that kernel is for Android 9. So to everybody in the same pickle as me, just use Simple Kernel xd since it performs just as well if not better than ares (at least based on antutu scores) :)
 
Last edited:
kernel seems to be resetting cpu frequency in idle for you, which shouldn't happen by default.


Welp then why is it happening? Something device-specific perhaps or kernel bug? Flash-wise and scenario-wise didn't do anything abnormal...

And I bet that some others are in the same situation as I am, as evidenced by the constant freezing and rebooting of ares. Indeed if the freq reset shouldn't happen and this is to be the normal behavior but why is it happening on select target devices while others no? I fully understand and embrace the existence of hardware-level variability between similarly-modeled devices but kernel behavior being this erratic? Must be a bug or something...
 
Last edited:

bien2004official

Senior Member
Sep 30, 2015
811
439
Bình Định
fb.me
Must be so. Helios seems to work fine on mine though at 1690MHz but that kernel is for Android 9. So to everybody in the same pickle as me, just use Simple Kernel xd since it performs just as well if not better than ares (at least based on antutu scores) :)
Helios has lower voltages as i remember, compared to Ares/Kraken which is pretty higher for overclocking.
Welp then why is it happening? Something device-specific perhaps or kernel bug? Flash-wise and scenario-wise didn't do anything abnormal...

And I bet that some others are in the same situation as I am, as evidenced by the constant freezing and rebooting of ares. Indeed if the freq reset shouldn't happen and this is to be the normal behavior but why is it happening on select target devices while others no? I fully understand and embrace the existence of hardware-level variability between similarly-modeled devices but kernel behavior being this erratic? Must be a bug or something...
Unclear why, but i'll make some checks related to it.
 
  • Like
Reactions: Mightx
Helios has lower voltages as i remember, compared to Ares/Kraken which is pretty higher for overclocking.

Unclear why, but i'll make some checks related to it.

Yeah that's part of the "weird" things I've pointed out with the recent oc kernels like ares and kraken which it was based on. But helios came from the same family of kernels as well so to speak so yeah we would greatly appreciate knowing what's going on. Helios I think ran on 1000mv at 1690 while Ares ran at 1060mv more or less at the same frequency of 1690 but I may be wrong....
 
Sorry was busy lately. But just tested the recent Ares kernels, and OG series as well as v2 and v4.1 work well on both of my G610's. Both with 1.2-1.3 GPU max frequencies and 1794 max CPU frequencies. However, do note that on the inferior device, v4.1 does not like to run at 1794 on the little cores as it would lock it up instantly but running the same max clock on the big cores is fine. But this issue isn't present in my other device.
 

tytfusokhszxc

Senior Member
Feb 24, 2017
333
71
Tested v5 of the latest Ares lineup and 1794 runs good on both devices on both little and big cores. Do note that on the device with the weaker SOC, 1794 on both little and big cores still lead to occasional freezes but nothing like the mayhem that was Ares before these recent releases.
Is it on Beta Testing phase or fully released kernel? Definitely, want to use it on my device.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    I own two (2) G610Y devices. One is a Black/Blue bought in early 2017 (Device A) and the other one is a White/Gold bought in late 2017 (Device B). Here are my observations on the devices:

    Kernel:
    - Device A and Device B both work fine with most kernels developed for Android 6 to Android 9 (e.g. Oxygen Kernel, Helios Kernel, etc.)
    - However, Device A cannot properly boot up on Treble and/or Android Q-R using Ares Kernel and H-Kernel as it gets frozen up 3-5 seconds after boot and would auto-reboot while Device B has no such issues
    - On the other hand, Device B could indeed run 1690MHz on little cluster, 1794MHz on big cluster, and 1146MHz on GPU as per the specs of the custom OC'ed kernels such as Ares while Device A when set to run at these would just insta-lock and freeze up
    - Device A can only run stable at 1586MHz on the CPU and 1001MHz on the GPU. While it might be possible to push it to 1690MHz and 1146MHz respectively, there is a high chance that the device would auto-reboot and crash
    - This is because Device A can't handle the OC'ed kernels that well and it would tend to ramp up to 70 degrees Celsius and beyond on the CPU when the frequencies are OC'ed beyond 1586MHz even on relatively light workloads
    - Exact reason as to why these are happening (also for other G610Y users) is currently unknown. But based on observation and of the other G610Y users as well, most probably those who cannot work on Kernels other than Simple Kernel for treble/GSI roms have Device A while those who can boot up Ares Reborn fitted onto the ROMS have most likely Device B (please confirm)

    ROM:
    - Aside from the kernel issues, Device A doesn't have any other problems in terms of Treble/GSI roms when it comes to bugs
    - However, Device B can usually get the zero brightness bug when the slider is set to lowest while Device A has no such issues
    - There also might be another bug present in Device B when you go to "About Phone" and "Battery Information" you would see that the battery capacity is 3000mAh while on Device A it is the normal 3300mAh
    - With these, more bugs can be expected from those with Device B while less bugs from those on Device A when it comes to roms. However, Device A is bad with kernels other than Simple kernel while Device B can handle the custom kernels just fine and as such no booting problems on Device B (please confirm as well)


    *Feel free to tell me if there are any other issues and/or discrepancies between the two types of G610Y devices based on your own observations or if the same issues exist for other models such as G610F and G610M
    *This might serve as an eye-opener for devs as well for when testers report certain problems, particularly if they are on a G610X device.
    3
    i just scrolled at xda and found this thread.

    i can only argue about the brightness bug tho.

    Ok, there's a file called "framework-res_auto_generated_rro.apk" or similar on /vendor/overlay.

    You can add features, theming and even edit the system configuration.

    And one of them is brightness.

    And since J7 Prime is IPS LCD, the minimal brightness value for this is 4 or more.

    And a lot of dev didn't care about this (sometimes even me [i like to call it "privacy protection" instead of bug]) because 80% of samsung phones with Exynos7870 chipset is AMOLED and the minimal brightness value for AMOLED is 0.

    You can fix this brightness bug by re-placing it with stock one OR edit the overlay using Apktool X.

    for the OC Kernels, for me it's really depends on your phone. One of old Ares testers even can handle OC at 1920mhz. and guess what? his phone is Y variant of J7 Prime (SM-G610Y) while mine (SM-G610F) sometime random reboot, but no more since bien fixed it on AresKernel Reborn.
    1
    can confirm with G610f model too, only simple kernel boots for treble roms.
    For Pie roms" kernel, My device can boot upto helios 3.1 but not 3.6 , as it gives random reboot . (cronos kernel was perfect for me).
    Nice observations and research though.
    1
    Except from Simple Kernel my 610M bootloops with Treble ROMs!

    Good idea to open this discussion.
    Whatever info you guys need about my HW, feel free to ask.
    1
    Must be so. Helios seems to work fine on mine though at 1690MHz but that kernel is for Android 9. So to everybody in the same pickle as me, just use Simple Kernel xd since it performs just as well if not better than ares (at least based on antutu scores) :)
    Helios has lower voltages as i remember, compared to Ares/Kraken which is pretty higher for overclocking.
    Welp then why is it happening? Something device-specific perhaps or kernel bug? Flash-wise and scenario-wise didn't do anything abnormal...

    And I bet that some others are in the same situation as I am, as evidenced by the constant freezing and rebooting of ares. Indeed if the freq reset shouldn't happen and this is to be the normal behavior but why is it happening on select target devices while others no? I fully understand and embrace the existence of hardware-level variability between similarly-modeled devices but kernel behavior being this erratic? Must be a bug or something...
    Unclear why, but i'll make some checks related to it.