Jump to content
PaulOBrien

Advent Vega kernel source code now available!

Recommended Posts

Here is the dmesg with those enabled. My kernel config has smp, earlysuspend, and caches disabled. This should eliminate any of those as the cause. http://pastebin.com/635KPxUX

It looks like the memory is not being restored, it gets copied into iram but the next step of the restore should be to copy it back and it fails to do so.

Just after the "PM: early resume of devices...", the next thing done is to reenable all the interrupts that were disabled when suspend was entered by calling resume_device_irqs() ... And then, calls tegra_suspend_finish() (noop in our case) , then calls dpm_resume_end() that should complete the resuming of the devices... and print several messages in the process. As we are not seeing them, i presume the problem lies in the interrupt restoring and enabling code... Perhaps it is time to add several pr_info() s to the kernel code to exactly know where the process is failing... Regarding IRAM, don-t forget to properly initialize nvmap platform data. Please take a look at my latests patchset for shuttle (board-shuttle-gpu..c) ... and the usage of the special macro NVMAP_HEAP_CARVEOUT_IRAM_INIT..

Share this post


Link to post
Share on other sites

Just after the "PM: early resume of devices...", the next thing done is to reenable all the interrupts that were disabled when suspend was entered by calling resume_device_irqs() ... And then, calls tegra_suspend_finish() (noop in our case) , then calls dpm_resume_end() that should complete the resuming of the devices... and print several messages in the process. As we are not seeing them, i presume the problem lies in the interrupt restoring and enabling code... Perhaps it is time to add several pr_info() s to the kernel code to exactly know where the process is failing... Regarding IRAM, don-t forget to properly initialize nvmap platform data. Please take a look at my latests patchset for shuttle (board-shuttle-gpu..c) ... and the usage of the special macro NVMAP_HEAP_CARVEOUT_IRAM_INIT..

void resume_device_irqs(void)

{

	struct irq_desc *desc;

	int irq;


	for_each_irq_desc(irq, desc) {

		unsigned long flags;


		raw_spin_lock_irqsave(&desc->lock, flags);

		__enable_irq(desc, irq, true);

		raw_spin_unlock_irqrestore(&desc->lock, flags);

	}

	pr_info("Resume Device Irqs -function end");

}

It never makes it to the end of that function. how do I have the pr_info() print out the iterations through that look. I know you pass it variables, but could you give me something to try here. Thanks, Treznorx

Edited by treznorx

Share this post


Link to post
Share on other sites

void resume_device_irqs(void)

{

	struct irq_desc *desc;

	int irq;


	for_each_irq_desc(irq, desc) {

		unsigned long flags;


		raw_spin_lock_irqsave(&desc->lock, flags);

		__enable_irq(desc, irq, true);

		raw_spin_unlock_irqrestore(&desc->lock, flags);

	}

	pr_info("Resume Device Irqs -function end");

}

It never makes it to the end of that function. how do I have the pr_info() print out the iterations through that look. I know you pass it variables, but could you give me something to try here. Thanks, Treznorx

I imagine something like pr_info("--- DEBUG: Irq: %d", irq);

Share this post


Link to post
Share on other sites

It dies on irq 129 http://pastebin.com/zqLvcJW6

An idea might be to run cat /proc/interrupts, save the output and see if it's the same IRQ that it stops on.

Did you put that pr_info at the beginning or end of the function? (I.e was it about to work on 129, or was it moving on to 130?)

Share this post


Link to post
Share on other sites

An idea might be to run cat /proc/interrupts, save the output and see if it's the same IRQ that it stops on.

Did you put that pr_info at the beginning or end of the function? (I.e was it about to work on 129, or was it moving on to 130?)

More Interesting dmesg http://pastebin.com/zD8rUwu1 For Some Reason this one exploded and gave a lot of data.

It was about to work on 129 which on my kernel is 129: 35 GIC ehci_hcd:usb1

Going to try and skip the enable of that irq.

Ok it went farther on the restore skipping that irq.

http://pastebin.com/TNk821eQ

Ok So now turned smp back on and it no longer gets the wake alarm to wake up.

Edited by treznorx

Share this post


Link to post
Share on other sites

Not sure if its any use as it is for the transformer prime but asus just released the kernel code for ics is ver 2.6.39.4.

Goto prime ics kernel select android as os, click source code and download v9.4.2.7

edit:- system update blob now also released on above link

Edited by brucelee666

Share this post


Link to post
Share on other sites

More Interesting dmesg http://pastebin.com/zD8rUwu1 For Some Reason this one exploded and gave a lot of data.

It was about to work on 129 which on my kernel is 129: 35 GIC ehci_hcd:usb1

Going to try and skip the enable of that irq.

Ok it went farther on the restore skipping that irq.

http://pastebin.com/TNk821eQ

Ok So now turned smp back on and it no longer gets the wake alarm to wake up.

Interpretation of logs:

1st log: The kernel dies while enabling the USB interrupt...

2nd log: The kernel aborted the suspend, as while it was trying to suspend, it received a wakeup event from the RTC...

3rd log: USB bus resume failed or it was skipped... That is why we are getting

  • [ 299.686703] usb 1-1: reset high speed USB device number 2 using tegra-ehci
  • [ 310.126626] usb 1-1: device not accepting address 2, error -110
  • [ 310.246644] usb 1-1: reset high speed USB device number 2 using tegra-ehci

So, all evidence points to a problem in the USB driver... ehci-tegra.c, to be exact... Perhaps, when the USB IRQ is reenabled, it starts to conrinuously generate interrupts, without pause, locking the kernel... If i remember it well, there was a change on the way interrupts were handled from .36 to .39... They initially ACKd them, then called the ISR (done in tegra_legacy.c/irq.c) but now their are ACKd in a different way (gic.c/irq.c) ... I will try to check both the ehci-tegra.c and irq handling, to try to spot the cause..

Edit1: Comparing ehci-tegra.c from .36 and .39, besides some extra configurations supported, and some slight rearrangement of code, both seems to be the same. The only thing i can spot is that CONFIG_USB_HOTPLUG should not be defined... otherwise, some clocks are not managed in the same way as in the .36 kernel ...

Edited by ejtagle

Share this post


Link to post
Share on other sites

Sorry and this may be just language difference for my not understanding but at the end do you mean 2 things, USB hotplug should be disabled because if enabled, clocks are handled different or indeed it should be disabled anyway and there is another difference with clock handling between 36 and 39? just for my understanding properly.

Cheers

Cass

Edited by Cass67

Share this post


Link to post
Share on other sites

So, all evidence points to a problem in the USB driver... ehci-tegra.c, to be exact... Perhaps, when the USB IRQ is reenabled, it starts to conrinuously generate interrupts, without pause, locking the kernel... If i remember it well, there was a change on the way interrupts were handled from .36 to .39... They initially ACKd them, then called the ISR (done in tegra_legacy.c/irq.c) but now their are ACKd in a different way (gic.c/irq.c) ... I will try to check both the ehci-tegra.c and irq handling, to try to spot the cause..

So if I understand you correctly then disableling USB should allow wakeup from suspend, right?

Share this post


Link to post
Share on other sites

So if I understand you correctly then disableling USB should allow wakeup from suspend, right?

The only thing is that those dmesg were taken with smp and early_suspend disabled in the kernel config. This simplified the process.

After re-enabling these items I no longer see any activity after the suspend. It just never wakes up.

So I think USB is one of the problems it however may not be the only problem. I'm going to do some more testing tonight.

Share this post


Link to post
Share on other sites

So if I understand you correctly then disableling USB should allow wakeup from suspend, right?

theoretically, yes... I can't confirm it , as i cant recover the ram console after a crash ... Or, it could be the handling of the interrupt controller... Will try to do some experiments to be sure...

Cass... There is an option in the kernel config called USB hot plug ... It is enabled by default, but i think it should be disabled...

Share this post


Link to post
Share on other sites

The only thing is that those dmesg were taken with smp and early_suspend disabled in the kernel config. This simplified the process.

After re-enabling these items I no longer see any activity after the suspend. It just never wakes up.

So I think USB is one of the problems it however may not be the only problem. I'm going to do some more testing tonight.

It could also be the interrupt controller...

Share this post


Link to post
Share on other sites

theoretically, yes... I can't confirm it , as i cant recover the ram console after a crash ... Or, it could be the handling of the interrupt controller... Will try to do some experiments to be sure...

Cass... There is an option in the kernel config called USB hot plug ... It is enabled by default, but i think it should be disabled...

Thanks, yes i do have that enabled .. was just confused about if it was the cause of the clock differences or an addition to the clock differences ... either way ill get rid of it and see what occurs ..

Cheers

Cass

Share this post


Link to post
Share on other sites

Thanks, yes i do have that enabled .. was just confused about if it was the cause of the clock differences or an addition to the clock differences ... either way ill get rid of it and see what occurs ..

Edit, yep as expected this is not the route cause of our suspend issues .. removing does nothing visible for us.

Cheers

Cass

Share this post


Link to post
Share on other sites

Did anyone notice that the 2.6.39 nvidia git has not been updated since 2 months ago ? -- I do suspect that Nvidia is still developing this branch, but not in their public git, for commercial reasons (so the tegra3 devices start selling before more tegra2 devices gets the ics update). And, if we inspect the asus prime released kernel, you will notice that kernel is based on our .2.6.39 kernel, not on the .39 xoom kernel, but several files are more advanced and newer versions from the files present in nvidia git.. i found out that while doing a compare between our git and asus kernel. There is also updated code for the tegra2 variants of the chip, and updated code for the suspend/resume of that chip. Perhaps that kernel is a better starting point for our porting efforts.

Unfortunately, the asus kernel is not a clean kernel snapshot, as there are customizations for the asus prime nearly everywhere. I am working in cleaning up that kernel, removing the prime customizations, and then we will see if this solves the suspend problems we are getting right now ... and also, i would not be surprised if it also solves the omx acceleration issues we are also experiencing ... I am at it, cleaning up things.. Will post the patch against our git later ;) -- Let's hope it improves on what we have right now!

Share this post


Link to post
Share on other sites

Yes after I posted the link yesterday just visually checked a few files and noticed a number of changes for t2 files not just t3, glad you managed to do a proper compare.

Look forward to your next patch, hopefully this more upto date kernel base will help solve suspend/resume and omx issues.

Share this post


Link to post
Share on other sites

Forget about the EGL HQ .. works .. secret sauce ftw,

eduardo .. its not kernel, or indeed libs per se .. but some framework diffs it seems ....

http://pastebin.com/GLh79JzQ

http://pastebin.com/wWjZkfGQ

ill disclose how when i can :)

now we just need the logs from the suspend hang ..

edit .. ohh and i cant make it suspend right now .. wakelock ??

http://pastebin.com/JyJ6YMk9

yep wakelocks

<6>[ 518.179050] active wake lock PowerManagerService

<6>[ 518.179364] active wake lock tegra_otg

<6>[ 518.179530] wake lock mmc0_detect, expired

<6>[ 518.179694] wake lock mmc1_detect, expired

otg will be when i put the usb back in ... the rest is up for auction !

Rgds

Cass

Edited by Cass67

Share this post


Link to post
Share on other sites

Forget about the EGL HQ .. works .. secret sauce ftw,

eduardo .. its not kernel, or indeed libs per se .. but some framework diffs it seems ....

http://pastebin.com/GLh79JzQ

http://pastebin.com/wWjZkfGQ

ill disclose how when i can :)

now we just need the logs from the suspend hang ..

edit .. ohh and i cant make it suspend right now .. wakelock ??

http://pastebin.com/JyJ6YMk9

yep wakelocks

<6>[ 518.179050] active wake lock PowerManagerService

<6>[ 518.179364] active wake lock tegra_otg

<6>[ 518.179530] wake lock mmc0_detect, expired

<6>[ 518.179694] wake lock mmc1_detect, expired

otg will be when i put the usb back in ... the rest is up for auction !

Rgds

Cass

There is an intentional wakelock when the USB is in gadget mode ... Remember there was a complaint about interrupted transfers while copying data to the device ad the device was seen as a usb mass storage ? -- That is th reason of the wakelock... The other wakelock (PowerManagerService) is a user managed wakelock from the Android Power Manager service... Not a kernel thing ;)

So, we are much closer ;) -- We need suspend to work ... that should be all needed :)

Share this post


Link to post
Share on other sites

Can you share your discoveries with us? :)

As soon as i am able to.. not being obtuse, just have some things that has been deemed non shareable right now and need to wait on others catching up to the same state before it can be worked out what can be done to get the info out there for others to benefit... sorry for vagueness but its all i can say for the moment.

Share this post


Link to post
Share on other sites

Fantastic rom for alpha, really good work chaps, keep up the great work.

Just a couple of obserations and by no means criticisms.

1. There is no photo sync option under Setting>Accounts &Sync, I usually use this to sync to my picassa account, any suggestions to reinstate this option under the google account, works fine on all previous roms.

2. Triangle icon permanently displayed in sys tray next to battery icon, can't for the life of me figure out what this represents?

3. A few keyboard sensitivity issues, being one of the orginl vega owners I'm fully aware of the history surrounding this however it is rom related, no such issues with vegacomb.

Donation on the way after next release, can't wait.

Cheers

Share this post


Link to post
Share on other sites

Fantastic rom for alpha, really good work chaps, keep up the great work.

Just a couple of obserations and by no means criticisms.

1. There is no photo sync option under Setting>Accounts &Sync, I usually use this to sync to my picassa account, any suggestions to reinstate this option under the google account, works fine on all previous roms.

2. Triangle icon permanently displayed in sys tray next to battery icon, can't for the life of me figure out what this represents?

3. A few keyboard sensitivity issues, being one of the orginl vega owners I'm fully aware of the history surrounding this however it is rom related, no such issues with vegacomb.

Donation on the way after next release, can't wait.

Cheers

I think it's best of you post this on the ROM thread.

This is the kernel dev thread...

When bugs are ROM related (not kernel related), the kernel devs probably can't help you...

(Cass is both a kernel dev and ROM dev, so I understand the confusion.)

Share this post


Link to post
Share on other sites

I think it's best of you post this on the ROM thread.

This is the kernel dev thread...

When bugs are ROM related (not kernel related), the kernel devs probably can't help you...

(Cass is both a kernel dev and ROM dev, so I understand the confusion.)

Sorry, I couldn't actually see a dedicated ICS thread and didn't want to start a new one unnecessarily, also as Cass mainly posts on this particular thread re ICS and is probably busy fixing all manner of things on ICS I thought this would be the correct place to post these little issues as I have not seen them raised by any other users.

I will post the same questions on the main board so as any responses do not clog this Kernel thread.

Share this post


Link to post
Share on other sites

I have the Prime Kernel booting on gtab, tons of errors but it boots and loads the egl drivers at least. Then it just starts boot looping, but it boots at least :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.