Re: MFD USB host: prevents CORE retention in idle
On Wed, Jun 20, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. The suspend/resume was failing even without USB in the mainline kernel image. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB on beagle XM. I suggested using l-o master as a baseline, not -rc2. I just pushed a branch with this baseline so we are sure to be testing the same baseline. Please use the 'tmp/test/usb-host' branch from my tree[1] as the starting point. Build using omap2plus_defconfig, boot, then suspend/resume and send the output of 'cat /debug/pm_debug/count' This baseline is working fine for me on 3430/n900, 3530/Overo and 3630/Beagle-xM. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host' I am seeing only the branch /wip/arm-nohz-cpusets other than master. I didn't any usb-host branch here too: http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
On Thu, Jun 21, 2012 at 10:12 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host' I am seeing only the branch /wip/arm-nohz-cpusets other than master. I didn't any usb-host branch here too: http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary It seems Kevin linked the wrong git tree, try this one: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
Grazvydas Ignotas nota...@gmail.com writes: On Thu, Jun 21, 2012 at 10:12 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host' I am seeing only the branch /wip/arm-nohz-cpusets other than master. I didn't any usb-host branch here too: http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary It seems Kevin linked the wrong git tree, try this one: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git Oops, sorry. Grazvydas is right. It's my linux-omap-pm tree that has this test branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. The suspend/resume was failing even without USB in the mainline kernel image. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin Ok, I will test this. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. The suspend/resume was failing even without USB in the mainline kernel image. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB on beagle XM. but I can see that core retention in suspend/resume is not working . Apply , DSS fixes patch has resolved the the crash in suspend/resume, but retention is not entering. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. The suspend/resume was failing even without USB in the mainline kernel image. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB on beagle XM. I suggested using l-o master as a baseline, not -rc2. I just pushed a branch with this baseline so we are sure to be testing the same baseline. Please use the 'tmp/test/usb-host' branch from my tree[1] as the starting point. Build using omap2plus_defconfig, boot, then suspend/resume and send the output of 'cat /debug/pm_debug/count' This baseline is working fine for me on 3430/n900, 3530/Overo and 3630/Beagle-xM. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
Munegowda, Keshava keshava_mgo...@ti.com writes: On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. Failing in what way? Did you debug any further? It may be failing because of problems with the USB host driver, which is what I'm needing you to debug. I'm convinced now that these USB host PM changes were not very well tested at all as they seem to be causing a variety of different problems on my boards: faults during boot, preventing CORE idle retention, hanging suspend/resume. Anyways... To get current l-o master to succesfully suspend/resume, you need 3 things: 1) the DSS fixes that Jean mentioned above (these are merged in v3.5-rc3, but not yet into l-o master) 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n 3) for for 32k timer which is also preventing CORE retention http://marc.info/?l=linux-omapm=13453229888w=2 With that setup on top of current l-o master, suspend/resume is working for me on several OMAP3/4 platforms. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean thanks Jean I used this patch; this solved the crash issue, but suspend/resume is still failing. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 [ 36.367126] pc : [c003c150] lr : [c02d75e4] psr: a013 [ 36.367126] sp : c5ebfe80 ip : c0a72fc0 fp : 0006 [ 36.379150] r10: c78af4b8 r9 : c0a3607c r8 : c003c13c [ 36.384643] r7 : r6 : r5 : c78af408 r4 : c78af408 [ 36.391479] r3 : r2 : r1 : c78af408 r0 : c78af400 [ 36.398315] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 36.405792] Control: 10c5387d Table: 86280019 DAC: 0015 [ 36.411834] Process sh (pid: 1254, stack limit = 0xc5ebe2f8) [ 36.417785] Stack: (0xc5ebfe80 to 0xc5ec) [ 36.422363] fe80: c78af408 c02d75e4 c0a36020 c0a36040 c78af408 c0f9e4a8 [ 36.430938] fea0: 0010 c0a36014 c0a36074 c02d8178 58566b0d 0008 58566b0d 0008 [ 36.439514] fec0: c0a1df38 0010 0003 c0a4d11c c09da45c [ 36.448089] fee0: 000ed008 c02d8a14 c0a62c28 c0080360 0003 c05b9ce8 0004 [ 36.456665] ff00: c04c9704 c78012c0 c00806a4 c5c8e000 0003 c05b9ce8 c007f8a8 [ 36.465240] ff20: c5c8d4c0 c5c8d4d8 c5ebff80 c7863e00 c02674a8 c02674c0 0004 c016d7fc [ 36.473815] ff40: c5d94a80 0004 b6ff6000 c5ebff80 c010c244 [ 36.482421] ff60: c0014400 c5c92280 c5d94a80 b6ff6000 0004 0004 c010c398 [ 36.490997] ff80: b6f235e8 0004 b6ff6000 b6f235e8 c00144a8 [ 36.499572] ffa0: c5ebe000 c00142e0 0004 b6ff6000 0001 b6ff6000 0004 [ 36.508148] ffc0: 0004 b6ff6000 b6f235e8 0004 0004 0964 000a 000ed008 [ 36.516723] ffe0: b6ff6000 bee815d0 b6e61c70 b6eb1abc 6010 0001 [ 36.525360] [c003c150] (_od_resume_noirq+0x14/0x58) from [c02d75e4] (dpm_run_callback+0x2c/0x74) [ 36.534973] [c02d75e4] (dpm_run_callback+0x2c/0x74) from [c02d8178] (dpm_resume_noirq+0xdc/0x2f4) [ 36.544677] [c02d8178] (dpm_resume_noirq+0xdc/0x2f4) from [c02d8a14] (dpm_resume_start+0xc/0x18) [ 36.554290] [c02d8a14] (dpm_resume_start+0xc/0x18) from [c0080360] (suspend_devices_and_enter+0x114/0x2d8) [ 36.564819] [c0080360] (suspend_devices_and_enter+0x114/0x2d8) from [c00806a4] (pm_suspend+0x180/0x1fc) [ 36.575042] [c00806a4] (pm_suspend+0x180/0x1fc) from [c007f8a8] (state_store+0x90/0x124) [ 36.583953] [c007f8a8] (state_store+0x90/0x124) from [c02674c0] (kobj_attr_store+0x18/0x1c) [ 36.593109] [c02674c0] (kobj_attr_store+0x18/0x1c) from [c016d7fc] (sysfs_write_file+0xfc/0x180) [ 36.602722] [c016d7fc] (sysfs_write_file+0xfc/0x180) from [c010c244] (vfs_write+0xb0/0x134) [ 36.611877] [c010c244] (vfs_write+0xb0/0x134) from [c010c398] (sys_write+0x40/0x70) [ 36.620300] [c010c398] (sys_write+0x40/0x70) from [c00142e0] (ret_fast_syscall+0x0/0x3c) [ 36.629180] Code: e1a04000 e258 01a02000 15902248 (e5d23018) [ 36.635833] ---[ end trace b3b167c1e86e5512 ]--- which kernel version are you using? do you have any good commit on which retention works because of usb host? regards keshava On Fri, Jun 8, 2012 at 7:55 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: yes! I am using the ramfs. regards keshava On Fri, Jun 8, 2012 at 7:31 PM, Kevin Hilman
Re: MFD USB host: prevents CORE retention in idle
Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
Keshava, Felipe, ping. This problem is still preventing CORE retention in mainline. On 05/24/2012 03:13 PM, Kevin Hilman wrote: Kevin Hilmankhil...@ti.com writes: Munegowda, Keshavakeshava_mgo...@ti.com writes: On Thu, May 24, 2012 at 5:55 AM, Kevin Hilmankhil...@ti.com wrote: On 05/23/2012 05:01 PM, Kevin Hilman wrote: Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant: usbhs_omap: alias fck already exists usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 these clocks were specific to omap4 and it should not cause any problem to omap3 boards. OK, they seem unrelated to this CORE retention problem, but the warnings should still be understood and fixed. I will try to reproduce this on 3430 sdp to explore further. Thanks for looking. Note that I only saw this problem on my 3530 platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host AFAICT, so didn't test there. After realizing that the same IP should exist on 3430/n900, I copied some board file support for USBHS host from overo into the n900 board file in order to test on 3430/n900. Problem exists on n900 too. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman khil...@ti.com wrote: On 05/23/2012 05:01 PM, Kevin Hilman wrote: Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant: usbhs_omap: alias fck already exists usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 these clocks were specific to omap4 and it should not cause any problem to omap3 boards. I will try to reproduce this on 3430 sdp to explore further. With debug enabled, I see the runtime resume during init followed by the runtime suspend. [ 0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 [ 0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller [ 0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume [ 0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10 [ 0.944641] usbhs_omap usbhs_omap: OMAP3 ES version ES2.1 [ 0.944671] usbhs_omap usbhs_omap: UHH setup done,ry uhh_hostconfig=8000121d [ 0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend However, later in the boot I see a runtime_resume and never see another suspend. That seems to be the root cause of CORE not hitting retention. From the boot log: [ 2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 [ 2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator [ 2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume [ 3.030639] ehci-omap ehci-omap.0: phy reset operation timed out [ 3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3 [ 3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes 256/512/1024 park [ 3.030761] ehci-omap ehci-omap.0: reset command 0080b02 park=3 ithresh=8 period=1024 Reset HALT [ 3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how this driver is being runtime resumed. Presumably it's due to how the rest of the USB stack works, which I'm not at all familiar with. Hopefully, the above is enough to debug the problem, Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman khil...@ti.com wrote: On 05/23/2012 05:01 PM, Kevin Hilman wrote: Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant: usbhs_omap: alias fck already exists usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 these clocks were specific to omap4 and it should not cause any problem to omap3 boards. OK, they seem unrelated to this CORE retention problem, but the warnings should still be understood and fixed. I will try to reproduce this on 3430 sdp to explore further. Thanks for looking. Note that I only saw this problem on my 3530 platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host AFAICT, so didn't test there. FYI, in order to hit core retention, there's another bug in mainline where the counter_32k IP also prevents retention. You'll need the hack below[1] (on top of l-o master) to workaround this problem (real patch with description will be coming soon.) Also, you'll likely need the UART mux patch from Govindraj[2]. Without this, UARTs in CORE may have runtime PM disabled, and thus also prevent CORE from hitting retention. Kevin [1] diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 840929b..42eb39d 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -292,6 +292,7 @@ static int __init omap2_sync32k_clocksource_init(void) __func__, ret); return ret; } + omap_hwmod_set_slave_idlemode(oh, SIDLE_FORCE); ret = omap_init_clocksource_32k(vbase); if (ret) { [2] http://marc.info/?l=linux-omapm=133672962809100w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
Kevin Hilman khil...@ti.com writes: Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman khil...@ti.com wrote: On 05/23/2012 05:01 PM, Kevin Hilman wrote: Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant: usbhs_omap: alias fck already exists usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 these clocks were specific to omap4 and it should not cause any problem to omap3 boards. OK, they seem unrelated to this CORE retention problem, but the warnings should still be understood and fixed. I will try to reproduce this on 3430 sdp to explore further. Thanks for looking. Note that I only saw this problem on my 3530 platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host AFAICT, so didn't test there. After realizing that the same IP should exist on 3430/n900, I copied some board file support for USBHS host from overo into the n900 board file in order to test on 3430/n900. Problem exists on n900 too. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MFD USB host: prevents CORE retention in idle
Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
On 05/23/2012 05:01 PM, Kevin Hilman wrote: Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant: usbhs_omap: alias fck already exists usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 With debug enabled, I see the runtime resume during init followed by the runtime suspend. [0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 [0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller [0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume [0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10 [0.944641] usbhs_omap usbhs_omap: OMAP3 ES version ES2.1 [0.944671] usbhs_omap usbhs_omap: UHH setup done, uhh_hostconfig=8000121d [0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend However, later in the boot I see a runtime_resume and never see another suspend. That seems to be the root cause of CORE not hitting retention. From the boot log: [2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 [2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator [2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume [3.030639] ehci-omap ehci-omap.0: phy reset operation timed out [3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3 [3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes 256/512/1024 park [3.030761] ehci-omap ehci-omap.0: reset command 0080b02 park=3 ithresh=8 period=1024 Reset HALT [3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how this driver is being runtime resumed. Presumably it's due to how the rest of the USB stack works, which I'm not at all familiar with. Hopefully, the above is enough to debug the problem, Thanks, Kevin [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc7-pm+debug+initramfs-01073-g0ecc382-dirty (khilman@paris) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #20 SMP Wed May 23 17:10:56 PDT 2012 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: Gumstix Overo [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 65280 [0.00] free_area_init_node: node 0, pgdat c09c0dc0, node_mem_map c0f1e000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 64768 pages, LIFO batch:15 [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/331/500 MHz [0.00] PERCPU: Embedded 9 pages/cpu @c1124000 s12992 r8192 d15680 u36864 [0.00] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO2,115200n8 earlyprintk ip=192.168.1.157:192.168.1.5:192.168.1.254:255.255.255.0:overo:eth0:none root=/dev/nfs nfsroot=192.168.1.236:/opt/kjh/rootfs/debian/armel,rsize=4096,wsize=409 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 243328k/243328k available, 18816k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc066da70 (6551 kB) [