[KERNEL][19FEB] SiyahKernel v6.0b5

PedroMRP · May 5, 2012

ChilliBo said:
same result,

status: enabled,
LED Timeout: 0 sec
CMLED Timeout 0 sec

BLN doesnt work when sms recieved or missed calls...

Using CM9 and only extweaks, in my case, bln is workin with missed calls and received sms

ChilliBo · May 5, 2012

PedroMRP said:
Using CM9 and only extweaks, in my case, bln is workin with missed calls and received sms

using VK rom as u can see in my signature, using latest siyah 3.2b7 and extweaks, but missed calls and sms doesnt work :/ doesnt work with nstools too. but whatsapp works ...

Cristiano Matos · May 5, 2012

ChilliBo said:
same result,

status: enabled,
LED Timeout: 0 sec
CMLED Timeout 0 sec

BLN doesnt work when sms recieved or missed calls...

Still with BLN control? I If yes, try to uninstall and reboot into recovery and reset extweaks profile.
Reboot and configure extweaks again.

bleuxeon · May 5, 2012

tolis626 said:
Gok,strange problem here.I tried to make a nandroid backup(a normal one,not of the secondary rom) and after backing up data it gave me an error message saying that there was an error when backing up .secondrom/data or something.Dafuq?

EDIT:What chance is there that the kernel panics I was and am still getting(although not nearly as often now) are related to overclocking while having changed the internal voltages?With a little higher that stock internal voltages,my phone is much stabler than it was with low voltages at high frequencies,but if kernel panics are related to that in any way,I will return to my previous quasi-unstable setup.

Could you please give me a sample voltage you did use at a given frequency and the same frequency voltage now with increased internal voltage?

rauschkugl · May 5, 2012

ChilliBo said:
BLN works with EXTweaks but not for sms or missed calls, tried with extweaks and bln pro... doesnt work.. any fix for that?? (3.2b7)

how many times does this have to be repeated? There's a search function for every thread. If it works on one place it's not kernel related. If you want bln for sms use gosms or smspopup. For calls install nstools.
Your screen has to stay off when you receive a sms.
Sent from my GT-I9100 using xda premium

ChilliBo · May 5, 2012

Cristiano Matos said:
Still with BLN control? I If yes, try to uninstall and reboot into recovery and reset extweaks profile.
Reboot and configure extweaks again.

doesnt work

squall458 · May 5, 2012

I am on vk rom too! I struggled for weeks to get bln to work. This is how u solve our prob. If the screen turns on when u receive a txt bln will not work. So use sms popup or go sms and disable notifications from stock messaging app. Sms popup has a setting where the screen will NOT turn on. It also will handle the notifications. Problem solved.

Sent from my GT-I9100 using XDA

steve17360 · May 5, 2012

ChilliBo said:
using VK rom as u can see in my signature, using latest siyah 3.2b7 and extweaks, but missed calls and sms doesnt work :/ doesnt work with nstools too. but whatsapp works ...

Missed calls & SMS both work with 3.2b7 using nstools & Milestone 5 rom. Deep sleep also works if you don't have any notifications.

Sent from my GT-I9100 using xda premium

Gawis · May 5, 2012

Trigger the led with Tasker when you gave a missed call or sms...

Sent from my SGSII CM9 with Tapatalk 2

droidphile · May 5, 2012

AndreiLux said:
As said, ondemand based governors do not visit steps so in an ideal situation there will be no increased transitions at all; if the governor decides to stay at the same frequency. But I doubt this is a real-world situation, the governor would jump either way or another to another frequency unless under heavy load. You have a transition time of 100µS compared to a default sampling rate of 100000µS or minimum 20000µS so we are talking about a loss of computing time two orders of magnitude smaller than a sampling period, versus a possible power gain in clocking of in the most optimistic case of 50% and worst case 7%.

I was thinking of only the time as summed up sampling intervals of each frequencies, rather than transition time of a mere 100uS. That make sense for a large frequency table. But if an heavy op was to be considered where freq has to stay really high, tightness of freq table doesn't matter. Table is big or small, it's all the same. We're talking w.r.t power gain and not performance gain right.

AndreiLux said:
I did not say they jump to the highest frequency too much, they jump as much as they need to. You have smoothing of load spikes through larger sampling periods and as you said through smooth scaling. I think interactive governors are a bad choice for this device and I haven't seen the point in using them; they may be good for battery use but the lags they introduce even with a tight frequency table is too noticeable for my taste. Use a smaller frequency table for all you want and then use them and disregard the whole discussion. I will be sticking with ondemand though. Frequency steps in the GS3 have no correlation with the number of cores, so I don't know why you'd bring that up, it doesn't change anything in terms of scaling, as in that regard Pegasus has the same logic as classic ondemand.

I'm not using interactive governors either, but ondemand. Anyway original interactive governor doesn't lag compared to smartass2 or luzactive. I brought GS3 just to say that pegagusq should handle a large freq table better. As in, there's a better chance for a freq F and F*2 to exist in a large freq table - When a multi core aware governor tries to hotplug in second core by setting a frequency F instead of clocking at F*2. I'm not here to upset anyone or disregard discussion. Even though i have no ammeters, i'm also an enthusiast always looking to learn more.

AndreiLux said:
100mV is almost guaranteed for 100 and 200MHz, the rest depends on the device. I wrote it just as an example of measurement, it's up to the user to decide what to do with it. I also measured underclocking and undervolting GPU, it has almost not measurable difference in light load. The Mali GPU also has internal power management that I think clock-gates part of the digital core when under low load, you can see this in the drivers. Undervolting GPU under load in games will bring a big decrease in power though, undervolting 200mV will bring down the total power consumption down 15% (that includes the whole device, screen on, CPU locked at 800), so the percentage is even greater I one would be able to solely measure the GPU.

Hmm, there are devices which doesn't guarantee 100mv UV on lower freqs. You said it yourself - under heavy GPU load, GPU UV could bring in power savings. If someone is into tasks that involves a lot of GPU, the best they can do is uv GPU and reduce screen brightness.

AndreiLux said:
I don't see what you want to say. The W/GHz value is only a theoretical calculation derived from his measurements under full load which is not realistic in a low load scenario. For playing music our devices don't even hit deep idle, ever. At least mine didn't, no matter what frequency you'd be playing music at, 100, 200 or 500MHz, the load is too fine-grained to let the CPU enter any clock-gating. There is no case in which 100MHz stays at high load because the governor will simply up the frequency and that situation will never realistically happen.

I didn't say device can hit didle while playing music. What i meant to say was - a) CPU idling on screen off - we're bound to hit didle very soon. So what's the point of using 100 instead of 200. b) CPU idling on screen on - How many tasks are there where CPU can stay low loaded at 100mhz. Like you say, 100% load on 100 mhz is not possible since governor will jump it to higher freqs. Then why use 100.

AndreiLux said:
Static power consumption is completely irrelevant in our device, it varies from 55mW to 60mW from 200MHz to 1400MHz. I'm getting the best W/GHz measurements at 800MHz so 800 is more efficient than 500.

800 may be sweet. But atleast, dynamic power consumption increases about 60% between 500 and 800 mhz. So 500mhz or lower running single core during screen-off is not bad.

AndreiLux said:
500MHz uses up 488mW power in screen-on idle versus 400mW for 200MHz, so you're wasting almost 20% power for "snappiness", which I honestly don't get since when you touch the screen it clocks to 500MHz anyway...

We can skip a transition if min is 500. Since every screen touch clocks CPU to 500, if an usage scenario involves too much of screen-touches, what's the point of having a frequency step below it. I like 500-1200 with 200-500 scr-off. Another thing to note is that 500mhz uses the core voltage of 800mhz if 500 was clocked from a frequency below it. And uses it's own core voltage if frequency was clocked from a frequency above it(500). When i'm using 500 as minimum, after a clock-up, 500 could be met only by clocking down from a higher frequency. This means i will have core voltage of 500 itself whenever it's used. This is not true if scr-on min was 200. So there's some power saving from one side when there's power dissipation on the other.

Past midnight here. Good night.

tolis626 · May 5, 2012

bleuxeon said:
Could you please give me a sample voltage you did use at a given frequency and the same frequency voltage now with increased internal voltage?

Example:
At default internal voltages,1500MHz need 1375mV.Give it 1350mV and it crashes.If I increase the internal voltage for 400MHz bus by 25mV,1500MHz is rock stable at 1350mV and semi-stable at 1325mV.+50mV in internal voltages changes nothing.At +75mV internal it's stable at 1325mV too,but I am kind of afraid that such an increase may cause problems to some peripherals,like the SD card.I was going to ask about that,so does anyone know if anything bad can happen to my data?

gokhanmoral · May 5, 2012

good news: I managed to flash CWM zip directly to secondrom.
you can even install a ROM directly as second rom.
I will try to complete the implementation tonight and test it tomorrow.

another good news is that I had my sgs2 lcd (actually full body) replaced today.
it means I am not leaving sgs2 any time soon

pilgrim011 · May 5, 2012

From v3.2b8 changelog:

new feature: “install zip to secondrom from internal sdcard” and “install zip to secondrom from external sdcard”

Gokhan, it seems nothing is impossible for you.

Can't wait for new beta release.

Cristiano Matos · May 5, 2012

gokhanmoral said:
good news: I managed to flash CWM zip directly to secondrom.
you can even install a ROM directly as second rom.
I will try to complete the implementation tonight and test it tomorrow.

another good news is that I had my sgs2 lcd (actually full body) replaced today.
it means I am not leaving sgs2 any time soon

Thanks for the great news.

Even not going to S3 for now, do you have plans to develop for new device?

Your answer will be crucial for my decision of buying S3 when release.

hawkerpaul · May 5, 2012

I've found a problem with b7.
I cant perform a backup any more.

It backs up boot image, system and data, then it crashes with "can't mount /secondrom_data"

All I have in the backup folder are:
boot.img
system.ext4.tar

so its missing nandroid.md5, cache.ext4.tar and system.ext4.tar

I dont use the dual boot feature at all so perhaps it has something to do with this.

rauschkugl · May 5, 2012

hawkerpaul said:
I've found a problem with b7.
I cant perform a backup any more.

It backs up boot image, system and data, then it crashes with "can't mount /secondrom_data"

All I have in the backup folder are:
boot.img
system.ext4.tar

so its missing nandroid.md5, cache.ext4.tar and system.ext4.tar

I dont use the dual boot feature at all so perhaps it has something to do with this.

this was already reported and gokhan is aware of it. Will be fixed in the next version. Backup to internal sd should work.

Sent from my GT-I9100 using xda premium

confusedmuse · May 5, 2012

hawkerpaul said:
I've found a problem with b7.
I cant perform a backup any more.

It backs up boot image, system and data, then it crashes with "can't mount /secondrom_data"

All I have in the backup folder are:
boot.img
system.ext4.tar

so its missing nandroid.md5, cache.ext4.tar and system.ext4.tar

I dont use the dual boot feature at all so perhaps it has something to do with this.

This has been discussed some pages back.
You can use "backup to internal sd" for now.
Will be fixed in b8.

chubby65 · May 5, 2012

confusedmuse said:
This has been discussed some pages back.
You can use "backup to internal sd" for now.
Will be fixed in b8.

I've already made an nandroid backup to external sd card using b7 so must be working for some of us

Sent from my GT-I9100 using xda premium

AndreiLux · May 5, 2012

droidphile said:
I was thinking of only the time as summed up sampling intervals of each frequencies, rather than transition time of a mere 100uS. That make sense for a large frequency table. But if an heavy op was to be considered where freq has to stay really high, tightness of freq table doesn't matter. Table is big or small, it's all the same. We're talking w.r.t power gain and not performance gain right.

I still do not understand the point you're trying to make...? I repeat you post:

When there are more frequency steps, there are more transitions. So lesser time to do the actual work because of clocking up/down through multiple frequencies? I mean, the delay as a function of sum-of-sampling-intervals increases if we have more transitions. (ondemand based governors may not visit every step before clocking to the highest freq, nevertheless)

If you are not talking about computing time lost during transition times (100µS), then I don't know what you're aiming at. Summed up sampling interval count for each frequency will indeed be lower, but what does it change at all? There is nothing lost.

My original power advantage assumption was aimed at, that for example that if a load needs 550MHz of computing power, we can clock the CPU at 600MHz and avoid the additional power usage of clocking the transistors another 200MHz higher to reach 800MHz.

droidphile said:
I'm not using interactive governors either, but ondemand. Anyway original interactive governor doesn't lag compared to smartass2 or luzactive. I brought GS3 just to say that pegagusq should handle a large freq table better. As in, there's a better chance for a freq F and F*2 to exist in a large freq table - When a multi core aware governor tries to hotplug in second core by setting a frequency F instead of clocking at F*2. I'm not here to upset anyone or disregard discussion. Even though i have no ammeters, i'm also an enthusiast always looking to learn more.

The S3 is supposed to have asynchronous capable CPU cores, so (while unconfirmed) it can clock up a core up to an optimal W/GHz frequency, say 800MHz, and then start clocking up another core on a different frequency up until it reaches that point again, and again until you actually fire up all the cores, and only then start to go over the optimal frequency. This is all theorycrafting based on what Samsung claims the chip is capable of at the 4412 launch, if it's really like that then we need to see. The resolution of the frequency table would not matter even in this case, F & F*2 needs not to be a requirement for that device to scale well. And you're not upsetting anybody, I'm just trying to understand the point you're trying to get across.

droidphile said:
Hmm, there are devices which doesn't guarantee 100mv UV on lower freqs. You said it yourself - under heavy GPU load, GPU UV could bring in power savings. If someone is into tasks that involves a lot of GPU, the best they can do is uv GPU and reduce screen brightness.

Sure, agree, but heavy GPU load is only anything involving 3D. GPU rendering for 2D stuff takes up nothing at all and is trivial work.

droidphile said:
I didn't say device can hit didle while playing music. What i meant to say was - a) CPU idling on screen off - we're bound to hit didle very soon. So what's the point of using 100 instead of 200. b) CPU idling on screen on - How many tasks are there where CPU can stay low loaded at 100mhz. Like you say, 100% load on 100 mhz is not possible since governor will jump it to higher freqs. Then why use 100.

Because of time-based loads like music! Then 100MHz will use less than 200MHz, because it is disregarding deep idle states. The difference is minimal, 5%, but when taken over a long period of time, it's something. That's when having screen off; when having screen on, most tasks stay low at 100MHz, and since we're not racing-to-idle when the screen is on, then the difference comes solely from feeding the processor a lower clock.

800 may be sweet. But atleast, dynamic power consumption increases about 60% between 500 and 800 mhz. So 500mhz or lower running single core during screen-off is not bad.

But we don't care about dynamic power when the screen is off because dynamic leakage gets wiped out by deep idle and clock gating the CPU, 800MHz gets 1445mW/GHz versus 1540mW/GHz for 500MHz, so you're better off to race-to-idle at 800MHz. If you are I/O or time-bound then you can do nothing against that other than scaling to an adequate frequency, and that's why a fine-grained frequency table provides an advantage.

droidphile said:
We can skip a transition if min is 500. Since every screen touch clocks CPU to 500, if an usage scenario involves too much of screen-touches, what's the point of having a frequency step below it. I like 500-1200 with 200-500 scr-off. Another thing to note is that 500mhz uses the core voltage of 800mhz if 500 was clocked from a frequency below it. And uses it's own core voltage if frequency was clocked from a frequency above it(500). When i'm using 500 as minimum, after a clock-up, 500 could be met only by clocking down from a higher frequency. This means i will have core voltage of 500 itself whenever it's used. This is not true if scr-on min was 200. So there's some power saving from one side when there's power dissipation on the other.

Why are you putting weight into transitions? They cost nothing so to speak. Having a frequency point below it, will as I said, reduces dynamic power wasted on clocking the CPU higher than needed... 488mW vs 400mW. Also that nonsense with the voltage of 500MHz was in the Gingerbread kernels and is no longer in the new CPUFreq driver, each frequency has its own voltage, so what you're saying would be correct for GB, it's not for ICS.

hawkerpaul · May 5, 2012

rauschkugl said:
this was already reported and gokhan is aware of it. Will be fixed in the next version. Backup to internal sd should work.

Sent from my GT-I9100 using xda premium

ok thanks.
I must have missed that amongst all these huge frequency step posts!

[KERNEL][19FEB] SiyahKernel v6.0b5

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Retired Senior Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts