Bug 1015800 - SD card not detected and automounted after resume
SD card not detected and automounted after resume
Status: CLOSED DUPLICATE of bug 1055057
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-05 11:56 EDT by Rutger Noot
Modified: 2016-04-23 13:57 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1055057 1286377 (view as bug list)
Environment:
Last Closed: 2015-02-24 10:53:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rutger Noot 2013-10-05 11:56:42 EDT
Description of problem:
After update to kernel-3.10.13-101.fc18, the insertion of the SD card is not detected after a suspend/resume cycle. The card does not get mounted. Things work fine after a fresh boot and also when running kernel-3.10.12-100.fc18
(which appears to be the most stable fedora-18 kernel to date).

Version-Release number of selected component (if applicable):
kernel-3.10.13-101.fc18

How reproducible:
See below

Steps to Reproduce:
1. Boot the computer
2. suspend to disk
3. resume
4. Insert SD card

Actual results:
Nothing happens

Expected results:
An event shows up in /var/log messages like 
mmc0: new high speed SD card at address 6f4a
The card is automounted by the gnome desktop.

Additional info:
Comment 1 Rutger Noot 2013-10-10 16:07:13 EDT
updated kernel to 3.10.14-100.fc18.x86_64 and the bug persists
Comment 2 Justin M. Forbes 2013-10-18 17:09:34 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs.

Fedora 18 has now been rebased to 3.11.4-101.fc18.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19.

If you experience different issues, please open a new bug report for those.
Comment 3 Rutger Noot 2013-10-19 07:53:01 EDT
The issue is still present in kernel 3.11.4-101.fc18.x86_64. 

A possible workaround is to unload and reload the appropriate kernel modules. 

modprobe -r mmc_block b43 ssb  sdhci_pci sdhci mmc_core

etc
Comment 4 Rutger Noot 2013-11-14 02:32:23 EST
No improvement after update to kernel 3.11.7-100.fc18.x86_64
Comment 5 Rutger Noot 2013-11-30 15:57:23 EST
Just updates to kernel-3.11.9-100.fc18.x86_64 and the bug persists
Comment 6 aaronsloman 2013-11-30 17:51:14 EST
(In reply to Rutger Noot from comment #3)
> A possible workaround is to unload and reload the appropriate kernel modules. 
> modprobe -r mmc_block b43 ssb  sdhci_pci sdhci mmc_core
> etc

I had a variant of this bug: I leave my sd card in its slot in my laptop
Dell Latitude E5410

I found that after the first thaw after hibernate (though not after first boot) there were always messages in /var/log/messages about waiting for mmc0

They continue for about 2 minutes, and after that the sd drive becomes available and pm-hibernate works. An attempt to hibernate earlier causes the machine to freeze until the drive becomes available (as indicated in the messages file) and then hibernation starts.

This can give the impression that hibernation does not work if it is attempted less than two minutes after thaw.

> The issue is still present in kernel 3.11.4-101.fc18.x86_64. 

and in 3.11.9-100.fc18.x86_64

The suggested workaround works.

I tried doing this via a script /etc/pm/sleep.d/99-sdcard
(There's nothing else in the directory. I am not sure whether the prefix should be 99 or 00, but it works as 99.)

I am not an expert bash programmer. This is my script

#!/bin/bash

if [ "$1" == "hibernate" ] ; then

    echo "umount /sdlinux"

    umount /sdlinux

    echo "modprobe -r sdhci_pci"

    modprobe -r sdhci_pci

elif [ "$1" == "thaw" ] ; then

   echo "modprobe sdhci_pci"

   modprobe sdhci_pci

   sleep 1

   echo "mount /sdlinux"

   mount /sdlinux

fi

(I presume a 'case' format would be more compact.)

/sdlinux is where I mount my SD card.

The 'echo' commands produce trace printing in /var/log/pm-suspend.log

The first time I tried this withoug the 'sleep 1' command during thaw, and the mount failed.

This workaround also solves Bug #1034457
(Changed) Delay in accepting SDHC card (mmc0: Timeouts) interferes with hibernation

Presumably there should be a default script doing this for suspend and hibernate?

(I don't normally use 'suspend', but I had the same problem when I tried it.)
Comment 7 aaronsloman 2013-11-30 18:27:53 EST
A modified version of the above script, to cope with suspend as well as hibernate is now in Bug #1034457

It also unmounts and mounts the device rather than the mount point, but that assumes that the mount point is specified in /etc/fstab

Because this bug is very obscure for users, there should be a script that prevents the most common cases, included in pm-utils.
Comment 8 Fedora End Of Life 2013-12-21 09:38:38 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Fedora End Of Life 2014-02-05 17:26:40 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 10 Rutger Noot 2014-04-04 01:48:40 EDT
I still have this bug in Fedora 20, kernel-3.13.7-200.fc20.x86_64
Comment 11 Rutger Noot 2014-04-09 16:39:50 EDT
As gnome now uses systemd to hibernate, a hook in /etc/pm/sleep will not be executed. I now use these files:

============
/etc/systemd/system/root-suspend.service

[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/sbin/modprobe -r mmc_block b43 ssb  sdhci_pci sdhci mmc_core

[Install]
WantedBy=sleep.target

===================
/etc/systemd/system/root-resume.service

[Unit]
Description=Local system resume actions
After=hibernate.target

[Service]
Type=oneshot
ExecStart=-/usr/sbin/modprobe mmc_block ; -/usr/sbin/modprobe b43 ; -/usr/sbin/modprobe sdhci_pci

[Install]
WantedBy=hibernate.target


And then enable those services:

sudo systemctl enable root-suspend.service
sudo systemctl enable root-resume.service
Comment 12 Justin M. Forbes 2014-05-21 15:38:49 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.14.4-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 13 Rutger Noot 2014-05-21 16:09:58 EDT
Running kernel 3.14.4-200.fc20.x86_64 the bug is still present. 
But the hooks in systemd still work. 

This bug looks like a duplicate of 1055057.
Comment 14 Justin M. Forbes 2014-11-13 10:59:36 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.
Comment 15 Rutger Noot 2014-11-13 13:42:47 EST
The workaround with root-resume.service root-suspend.service is still necessary to have the card reader function after a suspend-resume cycle.

[rutger@polyphemus ~]$ uname -a
Linux polyphemus.home 3.17.2-200.fc20.x86_64 #1 SMP Tue Nov 4 18:04:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Comment 16 aaronsloman 2014-11-13 16:23:41 EST
(In reply to Rutger Noot from comment #15)
> The workaround with root-resume.service root-suspend.service is still
> necessary to have the card reader function after a suspend-resume cycle.

Same here (on Dell Latitude E6410). Despite the remark in comment #11 I can still work around the problem using a script in /etc/pm/sleep.d

# uname -a
Linux lape 3.17.2-200.fc20.x86_64 #1 SMP Tue Nov 4 18:04:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I had been using this file:

     /etc/pm/sleep.d/99-sdcard

Without it

After pm-hibernate the system froze for some time
 Nov 13 20:35:33 lape kernel: [  107.388727] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:35:33 lape kernel: [  117.399112] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:35:33 lape kernel: [  127.409495] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:35:33 lape kernel: [  137.419875] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:35:33 lape kernel: [  147.430261] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:35:33 lape kernel: [  157.440644] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:35:33 lape kernel: [  157.442677] mmc0: error -110 during resume (card was removed)
...
 Nov 13 20:35:43 lape kernel: [  167.579079] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:35:53 lape kernel: [  177.590174] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:36:03 lape kernel: [  187.601165] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:36:13 lape kernel: [  197.612162] mmc0: Timeout waiting for hardware interrupt.
 Nov 13 20:36:13 lape kernel: [  197.614350] mmc0: card 0001 removed
 Nov 13 20:36:13 lape kernel: [  197.709098] mmc0: new high speed SDHC card at address 0001
 Nov 13 20:36:13 lape kernel: [  197.709309] mmcblk0: mmc0:0001 00000 7.46 GiB
 Nov 13 20:36:13 lape kernel: [  197.710519]  mmcblk0: p1

Eventually resume was completed.

When I restored the work-around /etc/pm/sleep.d/99-sdcard the hibernate/resume and suspend/resume worked fine.

But uses should not have to do that.
Comment 17 Fedora Kernel Team 2015-02-24 10:53:33 EST

*** This bug has been marked as a duplicate of bug 1055057 ***
Comment 18 aaronsloman 2015-06-29 18:02:40 EDT
I tried to clone this as a F22 bug, but came out as a F20 bugreport duplicating this one here: https://bugzilla.redhat.com/show_bug.cgi?id=1055057

I'll have to leave this to someone who knows how to do it. My repot that the bug persists in F22 is in 
https://bugzilla.redhat.com/show_bug.cgi?id=1055057#c19 which is still classed as a F20 bug.

Note You need to log in before you can comment on or make changes to this bug.