Re: Disc driver is module, software suspend fails

2005-04-14 Thread Jim Carter
On Wed, 13 Apr 2005, Pavel Machek wrote: > > This patch makes software_resume not a late_initcall but rather an > > external subroutine similar to software_suspend, and calls it at the > > beginning of mount_root (in init/do_mounts.c), just _after_ the initrd > > (if any) and its driver have been

Re: Disc driver is module, software suspend fails

2005-04-10 Thread Jim Carter
On Wed, 30 Mar 2005, Pavel Machek wrote: > You do not want to mount journaling filesystems; they tend to write to > disks even during read-only mounts... But doing it from initrd should > be okay. ext2 and init=/bin/bash should do the trick, too. I did give it a try -- successfully. For refere

Re: Disc driver is module, software suspend fails

2005-03-29 Thread Jim Carter
On Tue, 29 Mar 2005, Pavel Machek wrote: > You insmod driver for your swap device, then you echo device numbers > to /sys... then initiate resume. So you're saying, let the machine come all the way up, log in as root, "echo 8:5 > /sys/power/resume" (I think that was the name), then "echo resume

Re: Disc driver is module, software suspend fails

2005-03-27 Thread Jim Carter
On Fri, 25 Mar 2005, Pavel Machek wrote: > There's another feature that enables you to start resume manually with > some echo to /sys... Perhaps it needs to be documented better, I'm > looking for a patch ;-). But how can it resume from a swap device for which it has no driver? Even if you copied

Re: Disc driver is module, software suspend fails

2005-03-24 Thread Jim Carter
On Wed, 23 Mar 2005, Pavel Machek wrote: > This is WONTFIX for 2.6.11, but you can be pretty sure it is going to > be fixed for SuSE 9.3, and patch is already in 2.6.12-rc1. Feel free > to betatest SuSE 9.3 ;-). Unfortunately the celebration was premature. I compiled 2.6.12-rc1, noticing the

Re: Disc driver is module, software suspend fails

2005-03-23 Thread Jim Carter
On Wed, 23 Mar 2005, Pavel Machek wrote: > > I put some printk's into 2.6.11.5 and found out the reason for this > > behavior: in kernel/power/swsusp.c, static resume_device == 0. The > > reason it's 0 is that swsusp_read uses name_to_dev_t to interpret > > resume=/dev/sda5, a bogus block device

Disc driver is module, software suspend fails

2005-03-22 Thread Jim Carter
Distro: SuSE Linux 9.2 Kernel: 2.6.8 (kernel-default-2.6.8-24.11), also 2.6.11.5 Hardware: Dell Inspiron 6000d, Intel Pentium-M, 915PM chipset, disc is Fujitsu MHT2040AH, SATA via ata_piix driver Kernel cmdline: root=/dev/sda3 vga=0x317 selinux=0 resume=/dev/sd