LINUX.ORG.RU

Перестал просыпатся..…


0

0

Проблемка тут возникла... Раньше комп засыпал просыпался нормально. Но вчера поменял веник (был 160ГБ, перенес систему на 500ГБ ибо последний быстрей). Систему перенес без проблем, все как надо поправил (fstab и menu.lst). Только от засыпать засыпает, а когда надо проснутся, то грузится обычно и проверяет файловую систему. В dmesg ничего про это не говорит. Раньше был своп на sda1 и загрузчик lilo, сейчас своп sda7 и grub. При такой же конфигурации на ноуте и на работе комп отлично засыпают и просыпаются... А тут как будто ядро и не подозревает что комп был усыплен. В принципе мне только нужна наводка куда копать и информацию на тему "Как происходит resume". Есть подозрение что свап сильно далеко на диске... Хотя при загрузке ж то маунтит свап и при засыпании нормально образ на своп пишет... В общем у кого какие идеи?

PS: openSUSE 11

Ответ на: комментарий от SilentLexx

> Ну конечно.. Без неё б не засыпал бы ;)

Это шутка? При засыпании никто не смотрит на эту (и вообще на любую) опцию в загрузчике ядра.
Может у вас своп уехал в другое место? Что прописано в загрузчике и что прописано в конфиге ядра (параметр PM_STD_PARTITION)?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

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

> При засыпании никто не смотрит на эту (и вообще на любую) опцию в загрузчике ядра.

А куда смотрят? Может там UUID старого своповского раздела, который ныне именуется как sdb1...

> Может у вас своп уехал в другое место?

ага, я же писал что переехал, раньше был sda1, а сейчас sda7

> Что прописано в загрузчике и что прописано в конфиге ядра (параметр PM_STD_PARTITION)?

в загрузчике все как положено resume=/dev/sda7 , а в конфиге ничего...

SilentLexx
() автор топика
Ответ на: комментарий от SilentLexx

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

Неужели KPowersave? Так он не в загрузчик смотрит, он на версию ядра смотрит. В конфиге есть параметр, который отключает проверку.

> в загрузчике все как положено resume=/dev/sda7 , а в конфиге ничего...

Что в вашем случае мне не понятно. Но я ничего не прописываю в загрузчике, зато в ядре жестко указан своп. Может и вы так попробуете?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

> Неужели KPowersave? Так он не в загрузчик смотрит, он на версию ядра смотрит. В конфиге есть параметр, который отключает проверку.

Ага, он самый... От тут то может быть собака и порылась! Вполне возможно что оно на sdb1 засыпает... А при пробуждении указан то sda7. Второй веник я пока не форматил. Приду с работы, форматну sdb1 в ext2 например и посмотрю что будет ;)

SilentLexx
() автор топика

Неа... Тут  чтото другое...

Вот лог ноута при просыпании:
sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
ata6.00: configured for UDMA/33
sd 0:0:0:0: [sda] Starting disk
usb 2-3: reset low speed USB device using ohci_hcd and address 34
Restarting tasks ... done.

а вот комп (и при загрузке долго думает, затем грузится обычно):

sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 <<6>ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.1: EHCI Host Controller
 sda5<6>ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.1: debug port 1
PCI: cache line size of 64 is not supported by device 0000:00:02.1
ehci_hcd 0000:00:02.1: irq 22, io mem 0xf0209000
 sda6<7>ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 10 ports detected
 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk

вобщем каша (

SilentLexx
() автор топика
Ответ на: комментарий от SilentLexx

Пытался уложить на sdb1, заснул нормально, а вот проснутся не захотел опять.... где ж тут бага?

SilentLexx
() автор топика

Если используется uswsusp с его s2disk/s2ram/s2both, то тогда, наверное, надо курить его документацию и первым делом проверить актуальность initrd.

Если TuxOnIce, то проверить в файлах, лежащих в /etc/hibernate/, опцию SuspendDevice и настройки в самом ядре — там указывается раздел по умолчанию.

Если что-то другое — смотреть в сторону Documentation/power/. Например, в Documentation/power/swsusp-and-swap-files.txt пишут, что одного resume= мало, и что надо добавить resume_offset= Наверное, копать надо в этом направлении.

Как вариант — переставить новый винт так, чтобы он находился вместо старого… Больше ничего не придумал…

Sergius256
()
Ответ на: комментарий от Sergius256

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

SilentLexx
() автор топика
Ответ на: комментарий от SilentLexx

> Может пойти простым путем, переустановить пакеты ядра и uswsusp?
Хоть и не-Ъ оффтопик-way, но если сработает, то почему бы и нет?

Не связывался я с uswsusp — в свое время решил, что оно слишком сложно, так что сорри, помочь делом не могу. Пробовал, но деталей не помню. Вроде, были проблемы с самим своп-файлом — не мог определить resume_offset определить (этот параметр ядру, вроде бы, требовалось передать при загрузке) специальной софтиной. Точно не помню, но, вроде, софтина эта ругалась на то, что своп-файл какой-то неподходящий (в man mkswap упоминается по SWAP_SPACE и SWAPSPACE2) и она resume_offset определить не может.

От себя могу порекомендовать попробовать tuxonice — у меня оно работает, и никаких userspace-утилит (и, соответственно, initrd) не требует — только скрипт.

Sergius256
()

вот нашол это в бутлоге:

Creating device nodes with udev
Trying manual resume from /dev/disk/by-id/scsi-SATA_WDC_WD5000AACS-_WD-WCASU4599032-part7
Invoking userspace resume from /dev/disk/by-id/scsi-SATA_WDC_WD5000AACS-_WD-WCASU4599032-part7
/sbin/resume: error while loading shared libraries: liblzo2.so.2: cannot open shared object file: No such file or directory
/sbin/resume: error while loading shared libraries: liblzo2.so.2: cannot open shared object file: No such file or directory
Trying manual resume from /dev/disk/by-id/scsi-SATA_WDC_WD5000AACS-_WD-WCASU4599032-part7
Invoking in-kernel resume from /dev/disk/by-id/scsi-SATA_WDC_WD5000AACS-_WD-WCASU4599032-part7
Waiting for device /dev/disk/by-id/scsi-SATA_WDC_WD5000AACS-_WD-WCASU4599032-part5 to appear:  ok
fsck 1.40.8 (13-Mar-2008)
[/sbin/fsck.reiserfs (1) -- /] fsck.reiserfs -a /dev/disk/by-id/scsi-SATA_WDC_WD5000AACS-_WD-WCASU4599032-part5 
Reiserfs super block in block 16 on 0x805 of format 3.6 with standard journal
Blocks (total/free): 8004368/2296237 by 4096 bytes
Filesystem is NOT clean

SilentLexx
() автор топика
Ответ на: комментарий от SilentLexx

Все исправил... Просто после переноса стало вот так:

ldd /usr/sbin/resume
linux-gate.so.1 =>  (0xffffe000)
liblzo2.so.2 => /usr/X11R6/lib/liblzo2.so.2 (0xb7ee0000)
....

а там символическая ссылка и в initrd оно не добавлялось


исправил:

ldd /usr/sbin/resume
linux-gate.so.1 =>  (0xffffe000)
liblzo2.so.2 => /usr/lib/liblzo2.so.2 (0xb8011000)
....

и все  заработало....

SilentLexx
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.