[JB+][3.0.8/2.6.32 kernel] CM10.1 Android 4.2.2 for the Defy(+)

[thekguy]

Following the exact steps, I have modded transparency for the latest cm10.1 build without this issue. You have tried in a new directory right? And try cross checking the apk itself. If it doesn't work send me the modification and both framework and systemui, I'll compile it(have some free time tomorrow)

Sent from my MB526 using Tapatalk 2

 

[Blechd0se]

Shipping out a new kernel release. This contains many patches for trim in general and the one i was talking about recently.
I did many tests and couldn't crash the kernel anymore, hope you'll see an improvement!

Don't forget to don't interact with the device while its trimming.

Since it's only some sort of bugfix update i am only uploading the cm10.1 release. I put a small guide on my server with the topic
on how to make better bug reports (i will extend this in the future).

Let's just hope no new bugs will raise up and welcome Quarx back with a slightly smarter kernel

 

[measel]

@Blechd0se Do you think its possible to include the usb host mode patch by slugzero in future versions? It probably needs much more testing but it would be an awsome addition and might give the defy a second life for people who already moved on but need a display for their mobile drive.... (not me unfortunately,yet)

 

[justjr]

Shipping out a new kernel release. This contains many patches for trim in general and the one i was talking about recently.
I did many tests and couldn't crash the kernel anymore, hope you'll see an improvement!

Don't forget to don't interact with the device while its trimming.

Since it's only some sort of bugfix update i am only uploading the cm10.1 release. I put a small guide on my server with the topic
on how to make better bug reports (i will extend this in the future).

Let's just hope no new bugs will raise up and welcome Quarx back with a slightly smarter kernel

Can you please release it for CM10.2?
We cant use your last kernel cause we are crashing and loosing data... I would really like to update to that new kernel and help with testing.
Thank you!

 

[Blechd0se]

Can you please release it for CM10.2?
We cant use your last kernel cause we are crashing and loosing data... I would really like to update to that new kernel and help with testing.
Thank you!

You can simply replace the zImage in this release with the last one and flash it. Should work.
Kernel is the same for CM10.1 and CM10.2, the ramdisk is different.
@measel I am not sure, i can't test it. If he makes a pull request i can merge it.

 

[darkvier]

@Blechd0se the lastest kernel works well for me with the fstrim - v /data

Should i make a swap partition?

 

[slimshady76]

You can simply replace the zImage in this release with the last one and flash it. Should work.
Kernel is the same for CM10.1 and CM10.2, the ramdisk is different.

I'm getting a "file damaged" warning when I try to open the last kernel's zip file to replace the zImage with WinRAR. Downloaded the file several times, on two computers and my Defy with the same results. Any chance the zip file is damaged?

 

[justjr]

I'm getting a "file damaged" warning when I try to open the last kernel's zip file to replace the zImage with WinRAR. Downloaded the file several times, on two computers and my Defy with the same results. Any chance the zip file is damaged?

Worked fine at first here.

 

[Antiga Prime]

I'm getting a "file damaged" warning when I try to open the last kernel's zip file to replace the zImage with WinRAR. Downloaded the file several times, on two computers and my Defy with the same results. Any chance the zip file is damaged?

It's most likely your internet connection, not necessarily the computer used for the download. Also, I'd replace the file with 7zip; WinRar sometimes screws these things up and the file can't be flashed.

 

[slimshady76]

It's most likely your internet connection, not necessarily the computer used for the download. Also, I'd replace the file with 7zip; WinRar sometimes screws these things up and the file can't be flashed.

Yup, ended up with an infinite bootloop after flashing the new kernel with 8/31's CM10.2 ramdisk...

I'll try with 7Zip next.

 

[Anton111111]

Shipping out a new kernel release.

How about cm10 version ?

 

[fairxda]

Shipping out a new kernel release. This contains many patches for trim in general and the one i was talking about recently.
I did many tests and couldn't crash the kernel anymore, hope you'll see an improvement!

Don't forget to don't interact with the device while its trimming.

Since it's only some sort of bugfix update i am only uploading the cm10.1 release. I put a small guide on my server with the topic
on how to make better bug reports (i will extend this in the future).

Let's just hope no new bugs will raise up and welcome Quarx back with a slightly smarter kernel

Hi Blechdose!
You mentioned "trimming".
So I thougt I could do it manually too with "fstrim -v /data".
But maybe I am wrong, because the "answer" is: "applet not found".

Now the defy+ runs the new kernel since one hour without directly rebooting as before; (only once directly after installing the kernel).

 

[Blechd0se]

How about cm10 version ?

Not going to happen, have no time for this at the moment and i need feedback if trim
is fixed or not, sorry

Hi Blechdose!
You mentioned "trimming".
So I thougt I could do it manually too with "fstrim -v /data".
But maybe I am wrong, because the "answer" is: "applet not found".

Now the defy+ runs the new kernel since one hour without directly rebooting as before; (only once directly after installing the kernel).

Hello
This is the output from terminal? Which busybox version are you using?

No freezes/random reboots? No kernel panics?


Send from my Nexus 4

 

[fairxda]

Hello
This is the output from terminal? Which busybox version are you using?

No freezes/random reboots? No kernel panics?

Send from my Nexus 4

BusyboxPro is 1.21.1 and yes: until now no freezes, no random reboots (only as I said directly after the first boot after installing the kernel one soft-reboot) and no kernel panics.
And smooth and fast ...

Edit: Oh, ups, I forgot to mention that I am running on 4.3 with the zip slimshady made from your kernel. Maybe there is the fault.
Pardonnez moi ...

fstrim was found unter /system/xbin ..., but running with full path the same answer as before.

 

[ccav2000]

Sorry to spoil the party but the new kernel causes random hard reboot a little after the device enters deep sleep. As I am in CM10.1 now I can use the fstrim command successfully, but when I use it I see some error in dmesg, says "BUG: ext4_fstrim scheduling while atomic". My guess is that the system tries to turn off the screen and suspend while the trim is still ongoing and this error is triggered. But at least this is not causing a crash.

So currently I still cannot the discard option, but at least I can do a manual trim.

Sent from my Nexus 7 using xda app-developers app

 

[cyrusct82]

One question for TRIM to work perfectly we have to format the data and cache to EXT4 from boot menu or do we have to use only the wipe option (I use the fast wipe zip EXT3).

Sent from my MB526 using xda app-developers app

 

[ccav2000]

One question for TRIM to work perfectly we have to format the data and cache to EXT4 from boot menu or do we have to use only the wipe option (I use the fast wipe zip EXT3).

Sent from my MB526 using xda app-developers app

Whenever I need to format /data I just do it from the bootmenu in ext4. Only a few times when I was testing @Blechd0se's previous kernel my /data partition became so corrupt that I had to format it first in the Stock recovery and then to ext4 in bootmenu.

Sent from my Nexus 7 using xda app-developers app

 

[Blechd0se]

Sorry to spoil the party but the new kernel causes random hard reboot a little after the device enters deep sleep. As I am in CM10.1 now I can use the fstrim command successfully, but when I use it I see some error in dmesg, says "BUG: ext4_fstrim scheduling while atomic". My guess is that the system tries to turn off the screen and suspend while the trim is still ongoing and this error is triggered. But at least this is not causing a crash.

So currently I still cannot the discard option, but at least I can do a manual trim.

Sent from my Nexus 7 using xda app-developers app

Did you interact with it while it was still trimming?
Furthermore can you provide me a log with this error and the steps so i can reproduce it?
Do you have discard disabled?

As i said, just run trim and don't let the device do anything. After its completed you don't have to rerun it (only after a reboot)

One question for TRIM to work perfectly we have to format the data and cache to EXT4 from boot menu or do we have to use only the wipe option (I use the fast wipe zip EXT3).

Sent from my MB526 using xda app-developers app

Doesn't really matter. I have added to ability to load ext3/4 with the ext4 driver for
some additional performance.

Send from my Nexus 4

 

[ccav2000]

@Blechd0se no, I have discard disabled because it leads to guaranteed hard reboot. To reproduce, just make sure you have the screen timeout set to 30 seconds, and just trim. That's all I did, I didn't touch it while it was working, and it was already idle with all networks off for more than 10 minutes. I'll try to get a log later when I'm at home and have some time.

Sent from my Nexus 7 using xda app-developers app

 

[Blechd0se]

@Blechd0se no, I have discard disabled because it leads to guaranteed hard reboot. To reproduce, just make sure you have the screen timeout set to 30 seconds, and just trim. That's all I did, I didn't touch it while it was working, and it was already idle with all networks off for more than 10 minutes. I'll try to get a log later when I'm at home and have some time.

Sent from my Nexus 7 using xda app-developers app

Hmm thats to much. With no interaction i mean really no interaction. Not even display off during that time. :cyclops:

Maybe log isn't even needed anymore, but feel free to post it on pastie.org anyway.

The problem is; to fix the kernel crash i locked the trim process. If the device wants to sleep in that very moment the scheduler
gets confused and produces the error you did get. I may have to work again on this patch and add some sort of check if its
sleeping. I guess it gets only triggered if you manually fire the trim command.

Can you get me a log about this discard thing (look at my server for how to grap it)?
Otherwise i won't be able to fix it