Help getting the resume part of suspend-resume working, possible eMMC issue

[csgordon]

I've installed FreeBSD 13.2 onto a laptop, and am now trying to get suspend-resume working. (It happens to be a Gateway GWTC116-2BL, though there isn't a lot of info on specs online; I've uploaded a probe: https://bsd-hardware.info/?probe=03a8809fe4)

Suspend-resume works perfectly out of the box on this machine under Linux Mint, so I know it is not a hardware issue.

I confirmed that hw.acpi.supported_sleep_state includes S3, so FreeBSD is finding that just fine.

zzz will make the computer suspend successfully; I see console output similar to what I see on my other laptop (where suspend-resume does work) and the pulsing glowing light indicating the machine is sleeping. Upon waking, however, I get one of two possible outcomes.

Normally, when I try to wake the computer, I see a few benign console messages indicating re-enumeration of the USB bus, followed by an unknown number of controller timeout errors plus register dumps for sdhci_pci0-slot0 (see attached image, a photo of an external display that's less reflective than the built-in display). This happens at least twice (I suspect this happens many more times), followed some time later by:

mmc0: No compatible cards found on bus
GEOM_ELI: Device mmcsd0p3.eli destroyed.
GEOM_ELI: Detatched mmcsd0p3.eli on last close.

On this device, the only onboard storage device is a soldered eMMC module (not an nvme) at /dev/mmcsd0. mmc0 is the bus the MMC is on, so this series of events suggests two things are going wrong:

1. On resume, FreeBSD can no longer find the hard drive (even though it was identified without issue initially during boot)
2. During suspend, the encrypted swap device is destroyed

I'm not sure how to disable encrypted swap to see if that makes a difference, though the first issue seems like the real showstopper. Interestingly, I did try a couple live FreeBSD derivatives for comparison:

• NomadBSD (last release from last November) gets the same error about the same sdhci slot *even though it boots from USB*
• GhostBSD (from this summer) doesn't show this complaint about the mmc device, though it also doesn't successfully resume

I'd be grateful for any help resolving this issue, particularly the issues with the sdhci errors.

Way down the list of priorities, the machine doesn't seem to receive a signal when I close the lid, even after setting hw.acpi.lid_close_state to S3, but if I could just get resume from zzz / acpiconf -s 3 working I'd be very happy.

 

[csgordon]

I have tried with swap totally disabled, and hit the same mmc issue as above; but we can safely ignore the swap complaints