Guest ejtagle Posted January 17, 2012 Report Posted January 17, 2012 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..
Guest treznorx Posted January 17, 2012 Report Posted January 17, 2012 (edited) 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 January 17, 2012 by treznorx
Guest DrMon Posted January 17, 2012 Report Posted January 17, 2012 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);
Guest treznorx Posted January 17, 2012 Report Posted January 17, 2012 It dies on irq 129 http://pastebin.com/zqLvcJW6
Guest DrMon Posted January 17, 2012 Report Posted January 17, 2012 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?)
Guest treznorx Posted January 17, 2012 Report Posted January 17, 2012 (edited) 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 January 17, 2012 by treznorx
Guest brucelee666 Posted January 17, 2012 Report Posted January 17, 2012 (edited) 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 January 17, 2012 by brucelee666
Guest ejtagle Posted January 17, 2012 Report Posted January 17, 2012 (edited) 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 January 17, 2012 by ejtagle
Guest Cass67 Posted January 17, 2012 Report Posted January 17, 2012 (edited) 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 January 17, 2012 by Cass67
Guest DerArtem Posted January 17, 2012 Report Posted January 17, 2012 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?
Guest treznorx Posted January 17, 2012 Report Posted January 17, 2012 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.
Guest ejtagle Posted January 17, 2012 Report Posted January 17, 2012 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...
Guest ejtagle Posted January 17, 2012 Report Posted January 17, 2012 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...
Guest Cass67 Posted January 17, 2012 Report Posted January 17, 2012 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
Guest Cass67 Posted January 18, 2012 Report Posted January 18, 2012 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
Guest ejtagle Posted January 19, 2012 Report Posted January 19, 2012 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!
Guest brucelee666 Posted January 19, 2012 Report Posted January 19, 2012 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.
Guest Cass67 Posted January 19, 2012 Report Posted January 19, 2012 (edited) 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 January 19, 2012 by Cass67
Guest ejtagle Posted January 19, 2012 Report Posted January 19, 2012 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 :)
Guest DerArtem Posted January 19, 2012 Report Posted January 19, 2012 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 :) Can you share your discoveries with us? :)
Guest Cass67 Posted January 19, 2012 Report Posted January 19, 2012 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.
Guest riggsy Posted January 20, 2012 Report Posted January 20, 2012 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
Guest rvdgeer Posted January 20, 2012 Report Posted January 20, 2012 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.)
Guest riggsy Posted January 20, 2012 Report Posted January 20, 2012 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.
Guest treznorx Posted January 20, 2012 Report Posted January 20, 2012 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 :)
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now