ARCHIVED: [Kernel] Picasticks OC kernel built from LG source

[mxl360]

Seems good so far. And the USB Storage works! That was my main problem with Xionia's. I still can't get mine over 806 without reboots.

I will have to try this... if it can fix USB STORAGE issue with Xionia's

 

[picasticks]

Well, I tried it for half the day and had to revert back to the stock kernel. I tried bumping up the min to a few steps up, and I also tried messing around with the lowmem settings (using lowmem app) . It just seemed to have trouble with freq. Transitions and lock screen lag.

Thanks for the info (and to everyone else!).

Everybody who's had noticed lag: I've built several test kernels to isolate various features (along with retesting stock kernel) and this is the one it would be great if you'd like to test it: picasticks-04-testA.zip (I also added the URL to the top post)

It's actually 100% stock as far as the kernel config goes, with the exception of OC and interactive CPUFreq governor. So, more conservative than the 04 release was. (You'll still need to follow directions from top post to enable interactive.)

I've isolated one problem that was causing lag -- my removal of kernel debugging features caused problems whenever a network interface went up or down (so, once or maybe twice on boot with the TR airplane mode thing, plus wifi on/off, which also means on unlock if you have the default of wifi going down when the display sleeps, because wifi rewakes then). An easy way to see this if you're running 04 is to use the Power Control widget, tap to turn wifi on or off, then try to do anything, like scroll homescreens.

Otherwise I haven't noticed any other problems. There is obviously sluggishness if you peg the CPU, but still performs better than stock in the same situations. MSM7627 is just a lowly single core, so a background process doesn't have to do much to cause a noticeable bump if you're doing something intensive like a game in the foreground.

If you do notice lag or slowdowns please report load averages if possible (one place to see them is the info tab of SetCPU).

Assuming the testA is good, I'll put together an 05 release.

As far as the low-end freq goes, 245760 kHz is the device default and so far seems to have worked best. I know an older TR with the custom kernel experimented with the CPU min and people had issues with that. Anyway ... I'm sticking with 245760 for the time-being.

 

[DoesItMatter]

" Test version posted April 2: picasticks-04-testA.zip (see thread around page 3 for info. should be no problem running this, it is less aggressive than 04 release) "

The test version seems to be WAY smoother and less choppier than 04

I noticed a difference right away

I'm sticking with Test-04 for now!

 

[picasticks]

zefie, thanks for the tips! I appreciate it. And you caught me on the dirty builds. mrproper or out-of-tree builds from now on so I don't get called out again.

Xionia is built with a special buildroot toolchain, then the Makefiles are hacked to add even more optimization.
The special toolchain supports optimizations that the standard Android Toolchain does not. If you have ever tried to compile Xionia from source, you may have gotten build errors. This is why.

I would suggest to pixa to compile using the Android Toolchain compiler v 4.3.3 from the froyo branch to best mimic being exactly like LG.

It's funny you mention this, I just downloaded the "official" ARM toolchain from CodeSourcery earlier today to see what that would do. It's the fall 2010/GCC 4.5.1 release.

Right now I am using the froyo platform's toolchain, along with GCC 4.4.0 which is also what the LG VD kernel was built with.

In the past I haven't found much benefit to compiler optimizations with the Linux kernel, just because so much of the CPU-specific code is already basically assembly. But, we'll see if I get anywhere.

 

[Robchaos_]

I'm installing the test kernel now!

 

[antipunk]

testing now, seems to have worked perfectly. no more unlock jitters or browser jitters. good job!

 

[Robchaos_]

Everything is running smooth with the new test kernel! Thanks

 

[jstntp]

Everything is running smooth with the new test kernel! Thanks

+1. Huge difference. This will be my daily kernal for awhile. Thanks.

Sent by Tapatalk ----- Optimus s

 

[00_wrath_00]

Works good on TR 1.8.2. Will check out v5 when is up

Sent from my LS670 using Tapatalk

 

[mxl360]

Agreed... 4testA kernel works great.

 

[picasticks]

05 is up

Version 05 is up: picasticks-05.zip

If you like the 04-testA kernel, there is no pressing reason to stop using it unless you want to test something new. 04-testA is 100% LG's kernel config + OC and interactive CPUFreq, so it's a good one to keep around either to run or use as a comparison if you run into problems with any other OC kernel.

The bug with 04 causing lag turned out to be memory locking because I was using the preempt tree-based RCU. I thought that the problems with the old preempt RCU had been fixed by the tree-based one, but clearly they haven't in our case, as of 2.6.32.9. Reconciling preempt with RCU is a very hard problem. In our case there aren't any latency issues with the non-preempt tree RCU so I went back to it. Score 1 for LG, -1 for picasticks.

05 brings back most of the other config changes from 04 that are not in 04-testA. For instance, stripping debug features and highmem support (sadly our little phone has no high memory to address) brings minor speed improvements and frees up about a meg of RAM.

I have more testing, benchmarking various things vs. stock LG kernel to do, so let me know if you identify any issues. I figured I might as well go ahead and post it since 04 was clearly flawed.

Thanks for all the feedback on 04-testA.

 

[antipunk]

Testing out 5 now. No problems yet.

Sent from my LS670 using Tapatalk

 

[Robchaos_]

I shall be flashing this shortly

 

[00_wrath_00]

running v5 on thunderom 1.8.2 now very smooth clocked at 844 with no force closes or reboots.

 

[DoesItMatter]

Running v5 on nRom 1.6 768/480 interactive

Nice and smooth - no lag issues so far

 

[jcwxguy]

i was getting a lot of force closes on 04-testA kernel, glad i had a backup now to try 05 to see if fixed for my phone

-running ThundeRom 1.8.2

 

[picasticks]

i was getting a lot of force closes on 04-testA kernel, glad i had a backup now to try 05 to see if fixed for my phone

If you were getting force-closes on 04-testA, they are probably not kernel-related (or at least I don't yet know how they could be.) You're on VD (sorry for dumb question)? Give dalvik and cache a wipe I guess.

Anyways if you still have problems please give me more info (like what apps were hanging, how long did they run, what clock speed you're using). If you want you can use SetCPU and set (or leave) the governor at ondemand and set the max clock to 600, then 04-testA is basically identical to the LG kernel.

 

[sfhub]

I don't want to blame the kernel because I haven't done any extensive testing to isolate the problem(s).

When I initially installed the kernel and setcpu, nothing was explicitly set by me so everything was set to defaults (ie 748 and ondemand) I had an adb shell session ongoing and every once in a while the USB would act like I disabled USB debugging and subsequently enabled. Maybe adb was dying. Don't know, didn't look that closely. I don't think it was a USB problem because I didn't hear the USB sounds on the PC-side. I changed the max OC to 600 and it seemed to go away. Possibly this is just my phone not liking 748.

My second problem was I wasn't able to get my battery charged to 100%, for some reason, after installing the pica kernel. It would stay stuck at 98%. I tried clearing the battery states, draining the battery, etc. I had OC set to 600 with ondemand CPUfreq governor and the same problem continued.

I had a backup of stock vd mtd0-boot which I flashed back and was able to charge to 100% again.

Anyway, not saying any of this is pica's fault, just mentioning it in case someone else saw the same thing and if so, hopefully see some pattern develop.

 

[zefie]

zefie, thanks for the tips! I appreciate it. And you caught me on the dirty builds. mrproper or out-of-tree builds from now on so I don't get called out again.



It's funny you mention this, I just downloaded the "official" ARM toolchain from CodeSourcery earlier today to see what that would do. It's the fall 2010/GCC 4.5.1 release.

Right now I am using the froyo platform's toolchain, along with GCC 4.4.0 which is also what the LG VD kernel was built with.

In the past I haven't found much benefit to compiler optimizations with the Linux kernel, just because so much of the CPU-specific code is already basically assembly. But, we'll see if I get anywhere.

Mainly my toolchain by whatever means (buildroot) allows me to force the vfp to use hardware acceleration opposed to software emulation wherever possible. The standard Android Compiler says this is impossible, whereas the buildroot toolchain (and possibly others) accept this flag and there is a noticeable increase in responsiveness.

The VFP is similar to the FPU in a PC. It accelerates Vector Floating Point operations.

This was also the secret to my kernel on the Moment

 

[picasticks]

When I initially installed the kernel and setcpu, nothing was explicitly set by me so everything was set to defaults (ie 748 and ondemand) I had an adb shell session ongoing and every once in a while the USB would act like I disabled USB debugging and subsequently enabled. Maybe adb was dying. Don't know, didn't look that closely. I don't think it was a USB problem because I didn't hear the USB sounds on the PC-side. I changed the max OC to 600 and it seemed to go away. Possibly this is just my phone not liking 748.

I've seen similar weirdness with this (the USB connection notification and USB debug notification in the notification bar dropping, then returning) and also haven't really investigated. Switched USB cables and it seemed to go away.

But, this makes it more likely it was something else so I'll do a little more looking, and try clocking down to 600 while in debug and see what that does. Can you still connect via adb when the USB and debug USB connected notifications are gone? In my case, the fact that they were gone made no difference -- my connected shells stayed connected and I was able to make new connections via adb with no problem or delay despite what the phone's status bar said.

My second problem was I wasn't able to get my battery charged to 100%, for some reason, after installing the pica kernel. It would stay stuck at 98%. I tried clearing the battery states, draining the battery, etc. I had OC set to 600 with ondemand CPUfreq governor and the same problem continued.

On the battery notification I've noticed something slightly different but analogous to what I saw with the USB status notification. Basically, the "charging" indicator comes and goes even though the phone stays plugged in. So, it's basically something with the overall USB notification (i.e. notification system believes USB is disconnected and removes the USB connect, USB debug and charging indicators). In my case, battery level doesn't drop. Anyway, I'll look more into this. I found the same problem with the 04-testA kernel, with its 100% LG kernel config, so maybe it's clock-related (or a bug in the OC or cpufreq patches). Anyway I'll look into it.

Your battery problem is stranger, maybe somebody else has run into this?