I use my built in card reader very rarely so I don't know if the issue appeared after the last kernel upgrade or was already there when I bought the laptop. Anyway, my SD card didn't get mounted after hibernation so I built sdhci as a module and two others below it need to be modules as well. I just checked that reloading the sdhci module is all it takes to get the functionality back after resume form hibernation. So I blacklisted it and now it all seems to work. I have a Lenovo 300 N200 0769-EAG and that's the relevant part of lspci output: 08:06.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller 08:06.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 08:06.2 System peripheral: Ricoh Co Ltd Device 0843 (rev 0a) 08:06.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 05) 08:06.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff) I don't have any other cards or a firewire device so I can't check if the other functionality provided by this device works fine. Reproducible: Always Steps to Reproduce:
sdhci{,_pci} added to black list.
But sdhci is enough. No need (unless tested and proven otherwise) to reload the sdhci_pci aswell. After all it's precious time ;] (I guess...)
Please don't add to blacklist without notifying upstream, especially if added due to regression. Mainline drivers should not be blacked listed these days. Also please note the version so that only affected versions will be blacked listed.
Alon: Nigel (maintainer of TOI and hibernate-script) has been notified. Maciej: sdhci_pci needs sdhci.
Hi! Upstream is the kernel module originator... :)
Maciej: what kernel are you running? I've assumed TOI -- in which case it's better to wait for Nigel to determine whenever it's in vanilla or TOI related.
Yes, I'm running tuxonice-sources-2.6.28. If you think that it is necessary to reload sdhci_pci aswell then I'm sure you have valid reasons and know a lot more about this. Just wanted to notify that I tested it and for me blacklisting just the sdhci module was enough for it to work flawlessly.
Hello Maciej, As linux developers try harder these days to make Linux safe to suspend, it would be great if you could have reported the problem upstream. The problem is that tuxonice additions are unsupported. And may cause the problem. In order to solve this (blacklist is not a solution), it would be great if you could reproduce this using vanilla kernel using uswsusp. Then the module maintainer may be more willing to help. BTW: Is there any good reason for you to use tuxonice and not uswsusp?
I just tested the vanilla-sources (2.6.28) and it also suffers from this problem. So where should I report it? BTW. I use TOI because it looks better ;] and I think that it's faster because of compression...didn't notice though.
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) DRIVER P: Pierre Ossman M: drzeus-sdhci@drzeus.cx L: sdhci-devel@list.drzeus.cx S: Maintained Send to the list and CC the maintainer, provide full description and how to reproduce. What do you mean TOI looks better? I have added fbsplash support into uswsusp, so it looks the same... And uswsusp also uses compression... The main difference between the two is that TOI stores the caches while uswsusp drops them, so after TOI resume the system is somewhat more responsive (In theory).
I just sent it there. Will your fbsplash patch for uswsusp get included in the Gentoo patchset? Then I would be glad to start using gentoo-sources again. I actually prefer the caches to be flushed - I get to my desktop faster and I prefer all the needed files get loaded back to caches at this point.
It all in upstream uswsusp ready for you to use. Just emerge suspend with fbsplash USE. Set splash = y in /etc/suspend.conf
I can't get uswsusp to use fbsplash. I don't want to write any more OT here, so when you have some time please take a look here: http://forums.gentoo.org/viewtopic-t-728222.html
Maciej: if/when you get more from upstream feel free to reopen the bug.
