On Thursday 01 April 2010, Parag Warudkar wrote:
>
> On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
>
> > On Thursday 01 April 2010, Parag Warudkar wrote:
> > >
> > > Running Ubuntu Lucid 64-bit I noticed suspending fails with current git.
> > > Unsure since when it started - perhaps a while ago since the stock distro
> > > kernel 2.6.32-18 also fails to suspend - albeit little differently -
> > > git will fail before shutting off the display, distro one succeeds in
> > > shutting off the display and then hangs.
> > >
> > > Any ideas how to go about debugging this?
> >
> > Please first try to suspend after echoing 0 to /sys/power/pm_async.
>
> No change - hangs the same way as before.
>
> I recall it used to work with prior kernels and so I tried 2.6.31 from
> kernel.ubuntu.com/~kernel-ppa/
>
> mainline/v2.6.31/ but that fails similarly.
>
> May be I could try 2.6.30 but from a bisect stand point thats not all that
> attractive even if we find it works..
Yeah, kind of.
Please try:
# echo devices > /sys/power/pm_test
# echo mem > /sys/power/state
and see if that breaks too (it should get back to the command line in about
5-10 seconds).
Rafael
On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
> Please try:
>
> # echo devices > /sys/power/pm_test
> # echo mem > /sys/power/state
>
> and see if that breaks too (it should get back to the command line in about
> 5-10 seconds).
That breaks too - hangs similarly during suspend. I enabled RTC tracing
and every time it prints out different hash matches after reboot -
tty/tty21, pcie04 and latest is
[ 0.865296] pcieport 0000:00:1c.1: hash matches
Also when the suspend fails the immediate boot after that I get a USB
error on startup - unable to enumerate usb device on port 1. This error is
not present on normal boots.
Parag
On Thursday 01 April 2010, Parag Warudkar wrote:
>
> On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
>
> > Please try:
> >
> > # echo devices > /sys/power/pm_test
> > # echo mem > /sys/power/state
> >
> > and see if that breaks too (it should get back to the command line in about
> > 5-10 seconds).
>
> That breaks too - hangs similarly during suspend. I enabled RTC tracing
> and every time it prints out different hash matches after reboot -
> tty/tty21, pcie04 and latest is
>
> [ 0.865296] pcieport 0000:00:1c.1: hash matches
>
> Also when the suspend fails the immediate boot after that I get a USB
> error on startup - unable to enumerate usb device on port 1. This error is
> not present on normal boots.
Well, try the above with the USB controller drivers unloaded.
Rafael
On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
> On Thursday 01 April 2010, Parag Warudkar wrote:
> >
> > On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
> >
> > > Please try:
> > >
> > > # echo devices > /sys/power/pm_test
> > > # echo mem > /sys/power/state
> > >
> > > and see if that breaks too (it should get back to the command line in about
> > > 5-10 seconds).
> >
> > That breaks too - hangs similarly during suspend. I enabled RTC tracing
> > and every time it prints out different hash matches after reboot -
> > tty/tty21, pcie04 and latest is
> >
> > [ 0.865296] pcieport 0000:00:1c.1: hash matches
> >
> > Also when the suspend fails the immediate boot after that I get a USB
> > error on startup - unable to enumerate usb device on port 1. This error is
> > not present on normal boots.
>
> Well, try the above with the USB controller drivers unloaded.
>
Turns out its not the controller drivers but btusb and friends. Once I
removed btusb,sco,bnep,l2cap and family I was able to suspend resume just
like before.
For now I have disabled Bluetooth in BIOS as I don't need it - it is
likely that it was disabled earlier and so the suspend/resume was
working but looks like after a BIOS update/reset I left it enabled.
So this does not seem to be a regression to me.
But may be it should be possible to suspend/resume with bluetooth enabled?
:)
Thanks,
Parag
On Friday 02 April 2010, Parag Warudkar wrote:
>
> On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
>
> > On Thursday 01 April 2010, Parag Warudkar wrote:
> > >
> > > On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
> > >
> > > > Please try:
> > > >
> > > > # echo devices > /sys/power/pm_test
> > > > # echo mem > /sys/power/state
> > > >
> > > > and see if that breaks too (it should get back to the command line in about
> > > > 5-10 seconds).
> > >
> > > That breaks too - hangs similarly during suspend. I enabled RTC tracing
> > > and every time it prints out different hash matches after reboot -
> > > tty/tty21, pcie04 and latest is
> > >
> > > [ 0.865296] pcieport 0000:00:1c.1: hash matches
> > >
> > > Also when the suspend fails the immediate boot after that I get a USB
> > > error on startup - unable to enumerate usb device on port 1. This error is
> > > not present on normal boots.
> >
> > Well, try the above with the USB controller drivers unloaded.
> >
>
> Turns out its not the controller drivers but btusb and friends. Once I
> removed btusb,sco,bnep,l2cap and family I was able to suspend resume just
> like before.
>
> For now I have disabled Bluetooth in BIOS as I don't need it - it is
> likely that it was disabled earlier and so the suspend/resume was
> working but looks like after a BIOS update/reset I left it enabled.
>
> So this does not seem to be a regression to me.
>
> But may be it should be possible to suspend/resume with bluetooth enabled?
> :)
Sure.
Adding CCs to the bluetooth people.
Rafael