sdhci driver kills Suspend/Resume on Dell X1

This might be a dup of Bug #32593

Andreas: Can you test if doing a:

  sudo modprobe -r mmc_core sdhci

and then attempting to Suspend results in a successful trip.

If that works, can you try doing:

  sudo modprobe sdhci

and checking the output from:

  /var/log/messages

I tried that on a freshly booted system, but

$ sudo modprobe -r mmc_core sdhci
FATAL: Module mmc_core is in use.

Setting back to Unconfirmed after Andreas' reply.

This bug is still present on the release candidate.

Upping the priority because this bug can cause data loss. If a user uses Standby on unsaved work, it will be lost.

Either this bug should be fixed or the Dell X1 (possibly all systems with SD-card-slot) should be excluded from the list of system allowed to standby.

I'm getting this problem on my Latitude X1 too.

$ sudo modprobe -r mmc_core sdhci

displays "FATAL: Module mmc_core is in use." due to module dependencies. But this works:

$ sudo modprobe -r sdhci mmc_core

Now the modules are unloaded. After that, resume from standby goes fast and doesn't take 20 seconds.

After

$ sudo modprobe sdhci

That's the /var/log/messages output:

May 30 19:46:02 localhost kernel: [4295881.645000] sdhci: Secure Digital Host Controller Interface driver, 0.10
May 30 19:46:02 localhost kernel: [4295881.646000] sdhci: Copyright(c) Pierre Ossman
May 30 19:46:02 localhost kernel: [4295881.647000] ACPI: PCI Interrupt 0000:02:01.2[C] -> GSI 17 (level, low) -> IRQ 201
May 30 19:46:02 localhost kernel: [4295881.756000] mmc0: SDHCI at 0xdfcfe700 irq 201 DMA

***

This has been already reportet in the sdhci-devel list: http://list.drzeus.cx/pipermail/sdhci-devel/2006-May/000852.html -- That's the answer: http://list.drzeus.cx/pipermail/sdhci-devel/2006-May/000855.html

So Pierre Ossman suggests to upgrade to a newer sdhci version: "This is a bit old driver. Bug your distro to upgrade to something newer
or compile one of the 2.6.17-rc:s for yourself."

And what now?

I get exactly the same results as Christian Zeller on my X1.

One simple solution to fix the problem with the long timeout after resume would be to prevent the mentioned modules from getting loaded by the kernel. I added the following two lines to my /etc/modprobe.d/blacklist:

blacklist sdhci
blacklist mmc_core

The downside is that the SD card slot certainly wouldn't run anymore, but that's no problem for me personally because I don't use it.

This bug may be fixed in the current edgy developement system. In an effort to track this bug to our latest distribution, it is being targeted for edgy.

Please confirm whether this bug exists in edgy. If not, then please re-attach all related output (e.g. dmesg, oops output) while under edgy.

Latest Edgy CD's can be downloaded from:

http://cdimage.ubuntu.com/releases/edgy/knot-1/

If this image does not boot fom you, you can also download a current daily build from:

http://cdimage.ubuntu.com/daily-live/current/

Note that it may only be necessary to boot the LiveCD to see if your bug is fixed. In this case, you do not need to upgrade your installed system at all to confirm it. Certain bugs may require that you do an actual installation.

I experienced this very bug in Dapper, but cannot confirm if it is still present in Edgy (fresh install of Knot-2, regularly upgraded since) because the Dell X1 never succeeds in resuming from suspend when running Edgy. I've tried every day between Knot-2 and today after the daily upgrade.

When opening the lid, the power and network lights are turned on, but the monitor remains black (no backlight) and there is no disk activity.

This should probably be reported as a new bug, but I do not yet know what part of the system is causing this error. If anyone is interested in trying to fix this, I'm available for testing on my X1.

Please try latest Edgy kernel 2.6.17-8.22.

Using kernel 2.6.17-8.22 (and with the sdhci module loaded), suspend now works perfectly on the Dell Latitude X1. I regard this bug as solved for Edgy.

Thanks :-)

Setting to confirmed, since there seems to be enough info to decide if it will be fixed in 2.6.15 too.

Installed Edgy on my Dell Latitude X1. The problem is solved in Edgy.

Au contraire: I am using Edgy on my Asus Laptop with kernel 2.6.17-11, but still had the same problem. The workaround described in this thread worked though.

bug still present in feisty. 2.6.20-15-generic kernel. Dell Inspiron E1505

Bernhard: You should file a new bug, as you do not have the same computer and the problem discussed here actually was fixed in Edgy.