Jump to content

treznorx

Members
  • Content Count

    15
  • Joined

  • Last visited

Posts posted by treznorx


  1. Eduardo,

    We are getting reports of random reboots .. looks like a kernel panic..

    http://pastebin.com/KEUXe5kM

    http://pastebin.com/zrb6pG9J

    Ive received 2 logs on this both with the same problem ... looks like the wifi device is playing up somewhere ..

    Can you take a look ..

    Edit - make that 6 logs .. all the same ....

    edit 2 -- lovely crash when testing out a game ...

    http://pastebin.com/pjJLsi4U

    low memory ?

    Cheers

    Cass

    I had the same problem on Gtab. I solved it by passing the .built-in flag to the mmc stack in the board sdhci file. I no longer get those errors, however I can also no longer turn off the wifi from the rom and turn it back on. Once it's off it stays off.


  2. BTW, I compared treznorx tegra video subsystem with ours in rel-14r7, and they are exactly the same, except for the comments on the global gamma mapping functions. treznorx has the function commented out, but, according to DrMon, and I do believe him, that function, if commented out, makes the framebuffer console work, but makes Android transparency overlays not to work.. So, better keep the tegra video subsystem as the original rel-14r7 is right now., and android won't have problems with it.

    I also will try to redo the USB gadget/host mode switching... There must be something very silly going on here ... :o

    I meant to revert that commit. I overlooked it.

    As far as usb, with the new usb subsystem the device ids are set with the sysfs which is not there if the g_android config is not set in the defconfig. Also I have problems with getting it to work if I try to plug it in after power up and after the tab attempts to sleep, also on boot the vender id that is set is a fail safe in init.rc , not in the init.<device>.usb.rc file.

    Later after boot if I can open the advanced storage menu in android settings and turn on mtp or camera adb begins to work with a normal nvidia vender id. I don't know if any of that helps.

    Treznorx


  3. 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.


  4. 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.


  5. 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


  6. Great news! -- Could you do us a big, big favor and add to your kernel command arguments the following ones:

    initcall_debug ignore_loglevel

    and re capture the kernel log while the CPU resumes ? --- initcall_debug will print out not only the initialization sequence of devices, but most importantly here, the resume sequence ... before trying to call each resume function of each device, it prints out its name (the name of the device driver) ,,, and also prints out if an error was detected.

    I think, after seeing at your log that the kernel core is resuming properly, but some device is preventing the system to complete the resume ;) -- Once we get its name, we will be able to fix it ;)

    Pretty thanks for this piece of information !

    I'll try this tonight, I'm at work right now. Thanks!


  7. Ok so when the tab isn't coming back on its not really crashed. If I plug my usb serial converter in while its sleeping I get errors in the ram console after the reboot. It seems its just sitting there waiting for something to tell teh rest of teh devices to wake up. In the .36 kernel there was a legacy_irq.c file that handles what gic.c does now. I did not port this over when I tried the moto pm.c patch earlier. Have to try again when I have time.


  8. Thanks .. the first patch makes no difference .. actually it needs fixed too in order to compile correctly .. even with that fix its no good for us .. second one needs work too in order to compile in our environment ... not did that yet or not sure i will to be honest as we seem to have many more changes than average .. im not even sure where half our suspend code comes from ... Im comparing the Adams code also and they differ from us in the second patch (pm.c) only by the fact (i think) Eduardo added some L2 cache sync function... They have many changes to the mmc stuff as their bus.c is the same as ours but their core.c is quite a bit changed ... Seems the more i look at this the further down a rat hole i appear .. everyone seems to be using different versions of code ..

    Cheers

    Cass

    I'm working on the gtab and we have the same issue with sod.

    I've tried porting the entire suspend process from that tiamat kernel, basically this goes back to what we all have in the .36 kernel. The tab still wouldn't wake up.

    I have also tried using lp2 and again the tab would not wake up.

    The only time I have seen the tab go all the way to sleep and then wake up is when there was a wake alarm that caused the tab to sleep and wake up over and over on its own, but this only happens occasionally.

    I also have Eduardo's cache sync function in my kernel and I've tried all the above patches to no avail.

    I think the adam, shuttle and gtab are all in the same boat as far as this goes.

    Anyone I have come across who thought they didn't have the problem actually had a wakelock preventing the tab from sleeping.

    Treznorx

×
×
  • Create New...

Important Information

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