Ах да, ситуация одинакова на стандартных ядрах Arch Linux, ядрах linux-pf и самосборных ядрах linux-pf с жестко указанным параметром CONFIG_MMC_UNSAFE_RESUME=Y.

Впиши хук, который будет автоматически делать саспенд виртуалке.

Впиши хук, который будет автоматически делать саспенд виртуалке.

Я понимаю, что так можно, но тогда каждый саспенд будет хз сколько времени занимать - просто так крышку не захлопнешь и не пойдешь.

Меня больше интересует, почему опция модуля не работает. Или я что-то делаю неправильно?

Модуль создаёт что-либо в /proc и/или /dev? Проверить бы значения там.

Модуль создаёт что-либо в /proc и/или /dev? Проверить бы значения там.

В /dev/ создается устройство вставленной карты - /dev/mmcblk0, больше ничего. В /proc/ я тоже ничего не вижу.

Если проверять параметр по /sys/module/mmc_core/parameters/removable, то там корректно выставляется N, но делу это не помогает.

Ну есть ещё подозрение, что автоматически выгружается хостовый модуль mmc. Ты как suspend делаешь?

Ну есть ещё подозрение, что автоматически выгружается хостовый модуль mmc. Ты как suspend делаешь?Ну есть ещё подозрение, что автоматически выгружается хостовый модуль mmc. Ты как suspend делаешь?

systemctl suspend

Т.е. вы хотите сказать, что сам модуль mmc_core выгружается перед саспендом и его параметры не учитываются?

Вот мне так почему-то кажется. Сделай вот так:

# echo mem >/sys/power/state

Вот мне так почему-то кажется.

[ 8697.053842] mmc0: card aaaa removed

:(

да, в скриптах саспенда systemd была выгрузка модуля sdhci, но после того, как я ее оттуда убрал, ничего не изменилось.

Такое поведение было изначально или проявилось после какого-то апдейта ядра?

Такое поведение было изначально или проявилось после какого-то апдейта ядра?

Сколько я себя помню. Меня эта проблема уже очень давно беспокоила, но я все пытался найти что-то в интернете. Сейчас окончательно задолбало и решил написать сюда.

Я так понимаю, надо оформлять баг?

Да. И дашь потом ссылку сюда, мне стало интересно после ковыряния в коде. Там вызов функции, которая удаляет карту, находится всего в пяти местах, хочется узнать, кто неправ.

Да.

Я так понимаю, баг надо сабмитить в трекер своего дистрибутива, не в kernel.org?

И дашь потом ссылку сюда

Это приказ? :)

Посмотрел вывод dmesg еще раз. Странная вещь наблюдается - карта отмонтируется уже после вывода системы из саспенда и тут же монтируется обратно:

[  180.546234] PM: resume of devices complete after 971.469 msecs
[  180.547640] PM: Finishing wakeup.
[  180.547643] Restarting tasks ... done.
[  180.624372] mmc0: card aaaa removed
[  180.626086] sdhci-pci 0000:15:00.2: Will use DMA mode even though HW doesn't fully claim to support it.
[  180.656242] radeon: switched off
[  180.721644] mmc0: new high speed SDHC card at address aaaa

Я так понимаю, баг надо сабмитить в трекер своего дистрибутива, не в kernel.org?

Сначала да, потом по обстоятельствам.

Это приказ? :)

Нижайшая просьба.

О, это уже прикольнее. Может, виноват udev/udisks.

О, это уже прикольнее. Может, виноват udev/udisks.

Вот-вот, я тоже на него сразу подумал. Но осмотр правил в /usr/lib/udev/rules.d и в /etc/udev/rules.d ничего не дал - единственное место, где упоминается mmc - это создание устройств типа /dev/mmcblk и список устройств для автомонтирования.

Снова не знаю, куда смотреть. Что характерно, баг повторяется на всех дистрибутивах, что я пробовал - Чакра, последние несколько версий убунт, мой Арч. Т.е. это точно не systemd.

Может, попробовать загрузиться с live-cd чего-нибудь совсем старого, типа Убунты 8.04 и проверить, не регрессия ли это?

Если есть возможность — проверь.

Если есть возможность — проверь.

Ничего не вышло - Ubuntu 8.04 запустить не получилось, а в 10.04 вообще не используется модуль mmc_core, которому надо передавать параметр. Т.е. единственный способ - пересобрать ядро с CONFIG_MMC_UNSAFE_RESUME, что с live cd у меня, естественно, не выйдет.

Интересно другое - в 10.04 модуль mmc_core не загружается, но карта успешно определяется и без него. Что дает основания подозревать, что и в современном арче его параметры могут игнорироваться. Хотя выгрузить его система не дает.

Ну мы же вроде как поняли, что проблема не в модуле.

Ну мы же вроде как поняли, что проблема не в модуле.

Тогда я вообще запутался. Потому что по идее параметр ядра CONFIG_MMC_UNSAFE_RESUME должен делать именно то же самое, что и загрузка mmc_core с параметром removable=0. Но если модуль вообще не загружается - что тогда делает этот параметр?

Только что посмотрел sdio.c. Я правильно понимаю, что при саспенде вызывается mmc_sdio_suspend, который именно что отмонтирует карту? Т.е. ожидаемое поведение - что карта обязательно будет отмонтирована до саспенда?

Но у тебя же по логам она отваливается поле саспенда.

Чтоб и выгружать нечего было, не?

 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PCI=y
 CONFIG_MMC_RICOH_MMC=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_WBSD=y
 CONFIG_MMC_TIFM_SD=y
 CONFIG_MMC_CB710=m
 CONFIG_MMC_VIA_SDMMC=y
 CONFIG_MMC_VUB300=y
 CONFIG_MMC_USHC=y

Именно. Ибо кой чёрт тебя знает, что ты будешь делать с картой, пока ядро в спячке?

Не нарвится - правь код.

Именно. Ибо кой чёрт тебя знает, что ты будешь делать с картой, пока ядро в спячке?
Не нарвится - правь код.

Все понятно, это поведение по дефолту. Параметр модуля или параметр ядра должны это поведение менять на нужное мне. Иначе как быть пользователям eee-pc и всяких эмбеддедов, где система загружается с SD-карты?

И пары часов не продержался. Злобный tazhate закидал соплями.

Править код, полезать в Форточки, либо дожидаться, пока кто-то решится на правку кода.