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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
