После ухода в suspend или hibernate через 2 секунды включается

vasek	# 8 месяцев назад (отредактировано 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Почитал на свежую голову - и в части того, что значение счетчика wakeup_count не изменилось после выхода из suspend связно скорее всего с тем, что пробуждение вызвало устройство из файла /proc/acpi/wakeup. Давно с этим экспериментировал, все забылось, а проверить не могу - ни одно устройство не связано с пробуждением. Неплохо бы проверить это предположение ... и если это действительно так, то для начала нужно найти это устройство. PS - покапался в DOC, возможно и не прав в понимании wakeup_count, привожу выдержку из DOC в части wakeup_count The 'wakeup_count' attribute, along with the functions defined in drivers/base/power/wakeup.c, provides a means by which wakeup events can be handled in a non-racy way. If a wakeup event occurs when the system is in a sleep state, it simply is woken up. In turn, if an event that would wake the system up from a sleep state occurs when it is undergoing a transition to that sleep state, the transition should be aborted. Moreover, if such an event occurs when the system is in the working state, an attempt to start a transition to the given sleep state should fail during certain period after the detection of the event. Using the 'state' attribute alone is not sufficient to satisfy these requirements, because a wakeup event may occur exactly when 'state' is being written to and may be delivered to user space right before it is frozen, so the event will remain only partially processed until the system is woken up by another event. In particular, it won't cause the transition to a sleep state to be aborted. This difficulty may be overcome if user space uses 'wakeup_count' before writing to 'state'. It first should read from 'wakeup_count' and store the read value. Then, after carrying out its own preparations for the system transition to a sleep state, it should write the stored value to 'wakeup_count'. If that fails, at least one wakeup event has occurred since 'wakeup_count' was read and 'state' should not be written to. Otherwise, it is allowed to write to 'state', but the transition will be aborted if there are any wakeup events detected after 'wakeup_count' was written to. Оказывается не все так просто ... на сухую все очень запутано ... Ошибки не исчезают с опытом - они просто умнеют

# 8 месяцев назад (отредактировано 8 месяцев назад)

Сообщения: 11320

Участник с: 17 февраля 2013

Почитал на свежую голову - и в части того, что значение счетчика wakeup_count не изменилось после выхода из suspend связно скорее всего с тем, что пробуждение вызвало устройство из файла /proc/acpi/wakeup.
Давно с этим экспериментировал, все забылось, а проверить не могу - ни одно устройство не связано с пробуждением.
Неплохо бы проверить это предположение ... и если это действительно так, то для начала нужно найти это устройство.

PS - покапался в DOC, возможно и не прав в понимании wakeup_count, привожу выдержку из DOC в части wakeup_count

The 'wakeup_count' attribute, along with the functions defined in drivers/base/power/wakeup.c, provides a means by which wakeup events can be handled in a non-racy way. If a wakeup event occurs when the system is in a sleep state, it simply is woken up. In turn, if an event that would wake the system up from a sleep state occurs when it is undergoing a transition to that sleep state, the transition should be aborted.  Moreover, if such an event occurs when the system is in the working state, an attempt to start a transition to the given sleep state should fail during certain period after the detection of the event.  Using the 'state' attribute alone is not sufficient to satisfy these requirements, because a wakeup event may occur exactly when 'state' is being written to and may be delivered to user space right before it is frozen, so the event will remain only partially processed until the system is woken up by another event.  In particular, it won't cause the transition to a sleep state to be aborted. This difficulty may be overcome if user space uses 'wakeup_count' before writing to 'state'.  It first should read from 'wakeup_count' and store the read value.  Then, after carrying out its own preparations for the system transition to a sleep state, it should write the stored value to 'wakeup_count'.  If that fails, at least one wakeup event has occurred since 'wakeup_count' was read and 'state' should not be written to.  Otherwise, it is allowed to write to 'state', but the transition will be aborted if there are any wakeup events detected after 'wakeup_count' was written to.

Оказывается не все так просто ... на сухую все очень запутано ...

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 8 месяцев назад (отредактировано 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Не поленился, настроил пробуждение от mouse - похоже сейчас настройка изменилась (то ли уже и забыл), имею для mouse `EHC1 S3 enabled pci:0000:00:1d.0` но этого не достаточно, оказывается самому порту запрещено пробуждать ноут (значение wakeup для порта USB/ mouse имеет значение disabled) … пришлось дать разрешение. А вот после этого разрешения если уйти в suspend, то ноут пробуждается автоматом через 2-3с, даже если ничего не делаю. Но при этом значение счетчика меняется нормально `cat /sys/power/wakeup_count 3 cat /sys/power/wakeup_count 4` И что интересно, если после ухода в suspend нажать несколько раз mouse, то эти нажатия считаются событиями и счетчик их считает `cat /sys/power/wakeup_count 4 cat /sys/power/wakeup_count 7` Vitaly, предположу, что у тебя возможно по какой то причине какому то порту разрешено пробуждать комп. Нужно это проверить, но можно обойтись и проще - как уже писал выше, нужно присвоить значение disable следующим устройствам (для suspend) Vitaly* PEX1 S3 enabled pci:0000:00:1c.1 PEX3 S3 enabled pci:0000:00:1c.3 NPE1 S3 enabled pci:0000:00:01.0 NPE2 S3 enabled pci:0000:00:01.1 NPE3 S3 enabled pci:0000:00:02.0 NPE7 S3 enabled pci:0000:00:03.0 используя следующую команду `echo <DEV> \| sudo tee /proc/acpi/wakeup где <DEV> = устройство в 1-ом столбце /proc/acpi/wakeup` Если это не поможет, тогда нужно будет попробовать изменить по другому. Но остается вопрос - почему у тебя не меняются показания счетчика. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 8 месяцев назад (отредактировано 8 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Не поленился, настроил пробуждение от mouse - похоже сейчас настройка изменилась (то ли уже и забыл), имею для mouse

EHC1	  S3	*enabled   pci:0000:00:1d.0

но этого не достаточно, оказывается самому порту запрещено пробуждать ноут (значение wakeup для порта USB/ mouse имеет значение disabled) … пришлось дать разрешение.
А вот после этого разрешения если уйти в suspend, то ноут пробуждается автоматом через 2-3с, даже если ничего не делаю. Но при этом значение счетчика меняется нормально

cat /sys/power/wakeup_count
3
cat /sys/power/wakeup_count
4

И что интересно, если после ухода в suspend нажать несколько раз mouse, то эти нажатия считаются событиями и счетчик их считает

cat /sys/power/wakeup_count
4
cat /sys/power/wakeup_count
7

Vitaly, предположу, что у тебя возможно по какой то причине какому то порту разрешено пробуждать комп. Нужно это проверить, но можно обойтись и проще - как уже писал выше, нужно присвоить значение disable следующим устройствам (для suspend)

Vitaly
PEX1 S3 *enabled pci:0000:00:1c.1
PEX3 S3 *enabled pci:0000:00:1c.3
NPE1 S3 *enabled pci:0000:00:01.0
NPE2 S3 *enabled pci:0000:00:01.1
NPE3 S3 *enabled pci:0000:00:02.0
NPE7 S3 *enabled pci:0000:00:03.0

используя следующую команду

echo <DEV> | sudo tee /proc/acpi/wakeup
где <DEV> = устройство в 1-ом столбце /proc/acpi/wakeup

Если это не поможет, тогда нужно будет попробовать изменить по другому.
Но остается вопрос - почему у тебя не меняются показания счетчика.

Ошибки не исчезают с опытом - они просто умнеют