[LG Optimus 2x] Pxoeb6mU:
Ok. Thanks. But.

1) it wasn't a hard reboot. I could still connect via usb and do an adb shell, that's how I generated that dmesg output.

2) The instructions above seem to assume that if you connect USB while inside recover adb can see the device and you can do an adb shell? That has never worked for me on my LG O2X (using the CWM 3.0.2.8 installed by ROM Manager, adb devices does not show any connected devices while in recovery).

3) Doing a cat /proc/kmsg seems to give me exactly the same output as dmesg does. I assume /proc/last_kmsg is simply the /proc/kmsg from the previous boot? In which case, how would that differ from the dmesg that I already posted? Or am I misunderstanding this and /proc/last_kmsg is something totally different?

In case it wasn't clear, the point where things go wrong is *not* at the end of the dmesg log. It is this point:

<7>[ 1761.661920] mmc0: queuing CIS tuple 0x80 length 50

<7>[ 1761.695719] mmc0: queuing CIS tuple 0x80 length 7

<7>[ 1761.701159] mmc0: queuing CIS tuple 0x80 length 2

<7>[ 1761.716082] mmc0: queuing CIS tuple 0x80 length 9

<7>[ 1761.722871] mmc0: queuing CIS tuple 0x80 length 3

<7>[ 1761.821825] mmc0: queuing CIS tuple 0x02 length 1

<6>[ 1761.828240] mmc0: new SDIO card at address 0001

<4>[ 1761.833656] DHD: dongle ram size is set to 294912(orig 294912)

<4>[ 1773.482259] dhd_module_init: sdio_register_driver timeout

<6>[ 2785.575336] binder: 1121:1330 transaction failed 29189, size 260264-40

If you look at the log:

<4>[ 1716.611157] *** Wakeup from LP0 *** wake-source: 0x40000

...

<6>[ 1722.872127] power_suspend_late return 0

<4>[ 1722.893567] RM power state before suspend: Idle (4)

<4>[ 1722.903674] Disabling non-boot CPUs ...

<6>[ 1722.904258]

seems to be one "wake...suspend" cycle. There were many more of these above that point in the dmesg, but as they all looked fine (and pretty much the same) I figured there isn't much point in keeping them in the log.

The wake cycle that starts here:

<4>[ 1760.613004] *** Wakeup from LP0 *** wake-source: 0x40000

is exactly identical like for like with the one that started at

<4>[ 1716.611157] *** Wakeup from LP0 *** wake-source: 0x40000

up to this point:

<6>[ 1761.162276] suspend: enter suspend

<6>[ 1761.162287] PM: Syncing filesystems ... [Wi-Fi] CONFIG_BCM4329_GPIO_WL_RESET : 0

<3>[ 1761.325357] BRCM_LPM: host_wake_isr schedule

<3>[ 1761.325379] BRCM_LPM: BRCM_WAKELOCKTIMEOUT host wake=1

<4>[ 1761.332864] [Wi-Fi] do_wifi_cardetect:167

<4>[ 1761.332872] [Wi-Fi] card_present value is 1

<4>[ 1761.491181]

<4>[ 1761.491185] Dongle Host Driver, version 4.218.248.21

<4>[ 1761.652290] done.

<6>[ 1761.652312] tegra_pm_notifier: start processing event=3

In the previous cycle, these lines where:

<6>[ 1717.055833] PM: Syncing filesystems ... done.

<6>[ 1717.215858] tegra_pm_notifier: start processing event=3

So something happened between the

PM: Syncing filesystems ...

and the

done.

that caused this:

[Wi-Fi] CONFIG_BCM4329_GPIO_WL_RESET : 0

<3>[ 1761.325357] BRCM_LPM: host_wake_isr schedule

<3>[ 1761.325379] BRCM_LPM: BRCM_WAKELOCKTIMEOUT host wake=1

<4>[ 1761.332864] [Wi-Fi] do_wifi_cardetect:167

<4>[ 1761.332872] [Wi-Fi] card_present value is 1

<4>[ 1761.491181]

<4>[ 1761.491185] Dongle Host Driver, version 4.218.248.21

And that's something that hadn't happened in any of the previous wake...suspend cycles.

Is it really just coincidence that this happened in the one wake/suspend cycle that never managed to get back to suspending and instead started spamming binder ... transaction failed messages from then on?