LinuxLists.cc - 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 12 November 2006 15:26, Rafael J. Wysocki wrote:
> Hi,
>
> On Sunday, 12 November 2006 12:36, Andrey Borzenkov wrote:
> > This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel
> > when I switch on the system after suspend to disk. Actually, after kernel
> > has been loaded, the whole resuming (up to the point I have usable
> > desktop again) takes about three time less than the process of loading
> > kernel + initrd. During loading disk LED is constantly lit. This almost
> > looks like kernel leaves HDD in some strange state, although I always
> > assumed HDD/IDE is completely reinitialized in this case.
>
> Can you please see what's in the /sys/power/disk file?
>

{pts/0}% cat /sys/power/disk
shutdown

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFVxe1R6LMutpd94wRAgJvAKCMszsHKt2e7uN4h5SHBj7rixFTWgCffGis
2prTVMIdmr6ny1ORFTjO0GQ=
=sZ2j
-----END PGP SIGNATURE-----

2006-11-12 13:37:16

by Rafael J. Wysocki

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Sunday, 12 November 2006 13:46, Andrey Borzenkov wrote:
> On Sunday 12 November 2006 15:26, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Sunday, 12 November 2006 12:36, Andrey Borzenkov wrote:
> > > This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel
> > > when I switch on the system after suspend to disk. Actually, after kernel
> > > has been loaded, the whole resuming (up to the point I have usable
> > > desktop again) takes about three time less than the process of loading
> > > kernel + initrd. During loading disk LED is constantly lit. This almost
> > > looks like kernel leaves HDD in some strange state, although I always
> > > assumed HDD/IDE is completely reinitialized in this case.
> >
> > Can you please see what's in the /sys/power/disk file?
> >
>
> {pts/0}% cat /sys/power/disk
> shutdown

Can you please write "platform" to this file before the suspend and see if
anything changes?

Rafael

--
You never change things by fighting the existing reality.
R. Buckminster Fuller

2006-11-12 18:17:05

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Sun 12-11-06 14:36:41, Andrey Borzenkov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel when
> I switch on the system after suspend to disk. Actually, after kernel has been
> loaded, the whole resuming (up to the point I have usable desktop again)
> takes about three time less than the process of loading kernel + initrd.
> During loading disk LED is constantly lit. This almost looks like kernel
> leaves HDD in some strange state, although I always assumed HDD/IDE is
> completely reinitialized in this case.

Seems like broken hw, really. No state should survive machine
poweroff.

Is it notebook?

Can you try to unplug system for a few minutes / unplug battery if
notebook to see if it helps?
Pavel
--
Thanks for all the (sleeping) penguins.

2006-11-12 19:14:11

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 12 November 2006 16:34, Rafael J. Wysocki wrote:
> On Sunday, 12 November 2006 13:46, Andrey Borzenkov wrote:
> > On Sunday 12 November 2006 15:26, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > On Sunday, 12 November 2006 12:36, Andrey Borzenkov wrote:
> > > > This is rather funny; in 2.6.19-rc5 grub is *really* slow loading
> > > > kernel when I switch on the system after suspend to disk. Actually,
> > > > after kernel has been loaded, the whole resuming (up to the point I
> > > > have usable desktop again) takes about three time less than the
> > > > process of loading kernel + initrd. During loading disk LED is
> > > > constantly lit. This almost looks like kernel leaves HDD in some
> > > > strange state, although I always assumed HDD/IDE is completely
> > > > reinitialized in this case.
> > >
> > > Can you please see what's in the /sys/power/disk file?
> >
> > {pts/0}% cat /sys/power/disk
> > shutdown
>
> Can you please write "platform" to this file before the suspend and see if
> anything changes?
>

No, nothing changes.

I tested a bit more; I currently have 2.6.18.1, 2.6.18.2 and 2.6.19-rc5
installed. Booting after "poweroff" is OK from within all versions - there is
no delay. Resuming after suspend under 2.6.18.x is mostly OK, at least it is
much less obvious (I had some feeling it may have been "a bit slower" under
2.6.18.2 but may be it is just illusion). Resuming after suspend under
2.6.19-rc5 results in noticeable delay and constantly busy HDD LED during
grub phase.

Yes, it is notebook. I will test Pavel's suggestion later.

regards

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFV3J3R6LMutpd94wRAjBoAJ9UBc0KXM4/8ANCwUn17gbHrhTKawCgiJjg
qdsJw+JV4LLL4mP5hz+NYVI=
=Y1of
-----END PGP SIGNATURE-----

2006-11-13 03:42:23

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 12 November 2006 17:55, Pavel Machek wrote:
> On Sun 12-11-06 14:36:41, Andrey Borzenkov wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel
> > when I switch on the system after suspend to disk. Actually, after kernel
> > has been loaded, the whole resuming (up to the point I have usable
> > desktop again) takes about three time less than the process of loading
> > kernel + initrd. During loading disk LED is constantly lit. This almost
> > looks like kernel leaves HDD in some strange state, although I always
> > assumed HDD/IDE is completely reinitialized in this case.
>
> Seems like broken hw, really. No state should survive machine
> poweroff.
>

Well, we do have NVRAM do not we?

> Is it notebook?
>

Yes.

> Can you try to unplug system for a few minutes / unplug battery if
> notebook to see if it helps?

No. I unplugged power, removed battery and left it over night. Today morning
it has shown exactly the same behavior upon resuming (well, upon power-on
after suspend to disk :))

To recap - this never happens upon simple power off; I do not remember this to
happen upon suspend to disk until 2.6.19 (I won't claim it never happened,
just that I do not remember it). This happens consistently in 2.6.19-rc5. I
am very curious which hardware issue may have such pattern. And in any case
this does smell like regression (earlier version not triggering this HW issue
if any)

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFV+maR6LMutpd94wRAmhxAKDCZvzoUtqQguQL1+WmdT/wi3Y3RACgnXep
ra/Qr0wUO43MTAZB2qGWiS0=
=pICz
-----END PGP SIGNATURE-----

2006-11-13 08:18:21

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

Hi,

On Mon, Nov 13, 2006 at 06:42:15AM +0300, Andrey Borzenkov wrote:
> On Sunday 12 November 2006 17:55, Pavel Machek wrote:
> > On Sun 12-11-06 14:36:41, Andrey Borzenkov wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel
> > > when I switch on the system after suspend to disk. Actually, after kernel
> > > has been loaded, the whole resuming (up to the point I have usable

The most important question:
What filesystem is your /boot on? I'd bet quite some money that it is reiser
or some other journaling FS (not ext3).

> > > desktop again) takes about three time less than the process of loading
> > > kernel + initrd. During loading disk LED is constantly lit. This almost
> > > looks like kernel leaves HDD in some strange state, although I always
> > > assumed HDD/IDE is completely reinitialized in this case.
> >
> > Seems like broken hw, really. No state should survive machine
> > poweroff.

No. Broken FS / crappy GRUB.

> To recap - this never happens upon simple power off; I do not remember this to

I am pretty sure that it will also happen if you do "updatedb &", wait a
minute and then do a _HARD_ power off.

I am pretty sure that it has nothing to do with the kernel version, just with
the layout of your /boot partition (which of course changes with every kernel
update). In other words: until now, you just have been lucky.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."

2006-11-13 18:54:47

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 13 November 2006 11:15, Stefan Seyfried wrote:
> Hi,
>
> On Mon, Nov 13, 2006 at 06:42:15AM +0300, Andrey Borzenkov wrote:
> > On Sunday 12 November 2006 17:55, Pavel Machek wrote:
> > > On Sun 12-11-06 14:36:41, Andrey Borzenkov wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > This is rather funny; in 2.6.19-rc5 grub is *really* slow loading
> > > > kernel when I switch on the system after suspend to disk. Actually,
> > > > after kernel has been loaded, the whole resuming (up to the point I
> > > > have usable
>
> The most important question:
> What filesystem is your /boot on? I'd bet quite some money that it is
> reiser or some other journaling FS (not ext3).
>

there is no /boot, I use single / which is reiser.

> > > > desktop again) takes about three time less than the process of
> > > > loading kernel + initrd. During loading disk LED is constantly lit.
> > > > This almost looks like kernel leaves HDD in some strange state,
> > > > although I always assumed HDD/IDE is completely reinitialized in this
> > > > case.
> > >
> > > Seems like broken hw, really. No state should survive machine
> > > poweroff.
>
> No. Broken FS / crappy GRUB.
>
> > To recap - this never happens upon simple power off; I do not remember
> > this to
>
> I am pretty sure that it will also happen if you do "updatedb &", wait a
> minute and then do a _HARD_ power off.
>
> I am pretty sure that it has nothing to do with the kernel version, just
> with the layout of your /boot partition (which of course changes with every
> kernel update). In other words: until now, you just have been lucky.

The idea is nice; unfortunately it fails to explain the difference
between 'poweroff' and 'suspend disk' cases. I doubt disk layout is changed
between them.

regards

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFWL9uR6LMutpd94wRAh0NAJ4o2hU4E/BsMOJXPxqX8OSH8OR/nwCfdLPz
DWHM1gAFYTvc9WtyNv+qq08=
=EaDe
-----END PGP SIGNATURE-----

2006-11-13 22:03:22

by Zan Lynx

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Mon, 2006-11-13 at 21:54 +0300, Andrey Borzenkov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 13 November 2006 11:15, Stefan Seyfried wrote:
> > Hi,
> >
> > On Mon, Nov 13, 2006 at 06:42:15AM +0300, Andrey Borzenkov wrote:
> > > On Sunday 12 November 2006 17:55, Pavel Machek wrote:
> > > > On Sun 12-11-06 14:36:41, Andrey Borzenkov wrote:
> > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > Hash: SHA1
> > > > >
> > > > > This is rather funny; in 2.6.19-rc5 grub is *really* slow loading
> > > > > kernel when I switch on the system after suspend to disk. Actually,
> > > > > after kernel has been loaded, the whole resuming (up to the point I
> > > > > have usable
> >
> > The most important question:
> > What filesystem is your /boot on? I'd bet quite some money that it is
> > reiser or some other journaling FS (not ext3).
> >
>
> there is no /boot, I use single / which is reiser.
>
> > > > > desktop again) takes about three time less than the process of
> > > > > loading kernel + initrd. During loading disk LED is constantly lit.
> > > > > This almost looks like kernel leaves HDD in some strange state,
> > > > > although I always assumed HDD/IDE is completely reinitialized in this
> > > > > case.
> > > >
> > > > Seems like broken hw, really. No state should survive machine
> > > > poweroff.
> >
> > No. Broken FS / crappy GRUB.
> >
> > > To recap - this never happens upon simple power off; I do not remember
> > > this to
> >
> > I am pretty sure that it will also happen if you do "updatedb &", wait a
> > minute and then do a _HARD_ power off.
> >
> > I am pretty sure that it has nothing to do with the kernel version, just
> > with the layout of your /boot partition (which of course changes with every
> > kernel update). In other words: until now, you just have been lucky.
>
> The idea is nice; unfortunately it fails to explain the difference
> between 'poweroff' and 'suspend disk' cases. I doubt disk layout is changed
> between them.

I have not checked if this is true, but it is a possible explanation:

Perhaps the filesystem is not properly unmounted during a suspend? That
would mean GRUB is reading from a incoherent filesystem on resume.
GRUB's filesystem drivers are not very fancy. It could be it does
something silly like check the journal before returning each block.

Maybe its a journal size thing, you could try "sync" before suspend and
see if it helps. Another thing would be to create /boot as a separate
partition.
--
Zan Lynx <[email protected]>

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2006-11-13 22:59:17

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Mon, Nov 13, 2006 at 09:54:38PM +0300, Andrey Borzenkov wrote:
> Hash: SHA1
>
> On Monday 13 November 2006 11:15, Stefan Seyfried wrote:
> > The most important question:
> > What filesystem is your /boot on? I'd bet quite some money that it is
> > reiser or some other journaling FS (not ext3).
> >
>
> there is no /boot, I use single / which is reiser.

ok, so your /boot is on reiser. Q.E.D.

> > I am pretty sure that it will also happen if you do "updatedb &", wait a
> > minute and then do a _HARD_ power off.
> >
> > I am pretty sure that it has nothing to do with the kernel version, just
> > with the layout of your /boot partition (which of course changes with every
> > kernel update). In other words: until now, you just have been lucky.
>
> The idea is nice; unfortunately it fails to explain the difference
> between 'poweroff'

filesystem cleanly unmounted

> and 'suspend disk'

filesystem unclean.

> cases. I doubt disk layout is changed
> between them.

Try the "updatedb &, then _HARD_ poweroff" test described above. It will take
long to load grub afterwards.

--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."

2006-11-13 22:59:12

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Mon, Nov 13, 2006 at 03:03:16PM -0700, Zan Lynx wrote:

> I have not checked if this is true, but it is a possible explanation:
>
> Perhaps the filesystem is not properly unmounted during a suspend? That

Of course not.

> would mean GRUB is reading from a incoherent filesystem on resume.

Exactly.

> GRUB's filesystem drivers are not very fancy. It could be it does
> something silly like check the journal before returning each block.

GRUB must not write to the fs, so it probably plays back the journal in
memory only and it does this for every file it reads (at least that's how
it feels :-)

> Maybe its a journal size thing, you could try "sync" before suspend and
> see if it helps.

We already sync inside the kernel, it does not help here, though.
Blockdev freezing might help.

> Another thing would be to create /boot as a separate partition.

Yes, that's what i always advise: /boot on separate ext2 partition. Then
GRUB resumes fast.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."

2006-11-13 23:09:52

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

Hi!

> > The idea is nice; unfortunately it fails to explain the difference
> > between 'poweroff' and 'suspend disk' cases. I doubt disk layout is changed
> > between them.
>
> I have not checked if this is true, but it is a possible explanation:
>
> Perhaps the filesystem is not properly unmounted during a suspend?

We do not/can not unmount filesystems during suspend. But we do sync
them.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2006-11-13 23:13:40

by Rafael J. Wysocki

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Monday, 13 November 2006 23:55, Stefan Seyfried wrote:
> On Mon, Nov 13, 2006 at 09:54:38PM +0300, Andrey Borzenkov wrote:
> > Hash: SHA1
> >
> > On Monday 13 November 2006 11:15, Stefan Seyfried wrote:
> > > The most important question:
> > > What filesystem is your /boot on? I'd bet quite some money that it is
> > > reiser or some other journaling FS (not ext3).
> > >
> >
> > there is no /boot, I use single / which is reiser.
>
> ok, so your /boot is on reiser. Q.E.D.
>
> > > I am pretty sure that it will also happen if you do "updatedb &", wait a
> > > minute and then do a _HARD_ power off.
> > >
> > > I am pretty sure that it has nothing to do with the kernel version, just
> > > with the layout of your /boot partition (which of course changes with every
> > > kernel update). In other words: until now, you just have been lucky.
> >
> > The idea is nice; unfortunately it fails to explain the difference
> > between 'poweroff'
>
> filesystem cleanly unmounted
>
> > and 'suspend disk'
>
> filesystem unclean.
>
> > cases. I doubt disk layout is changed
> > between them.
>
> Try the "updatedb &, then _HARD_ poweroff" test described above. It will take
> long to load grub afterwards.

Alternatively, you can use a recent -mm kernel with the bdevs freezing patch
and see if that helps GRUB. ;-)

Greetings,
Rafael

--
You never change things by fighting the existing reality.
R. Buckminster Fuller

2006-11-14 04:07:22

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 14 November 2006 01:58, Stefan Seyfried wrote:
> On Mon, Nov 13, 2006 at 03:03:16PM -0700, Zan Lynx wrote:
> > I have not checked if this is true, but it is a possible explanation:
> >
> > Perhaps the filesystem is not properly unmounted during a suspend? That
>
> Of course not.
>
> > would mean GRUB is reading from a incoherent filesystem on resume.
>
> Exactly.
>
> > GRUB's filesystem drivers are not very fancy. It could be it does
> > something silly like check the journal before returning each block.
>
> GRUB must not write to the fs, so it probably plays back the journal in
> memory only and it does this for every file it reads (at least that's how
> it feels :-)
>

Ah, OK, that makes sense. I did not expect GRUB to be *that* sophisticated :)

> > Maybe its a journal size thing, you could try "sync" before suspend and
> > see if it helps.
>
> We already sync inside the kernel, it does not help here, though.
> Blockdev freezing might help.
>

is there patch applicable to vanilla kernel? After repairing reiser several
times (due to hard lockups during suspend-to-RAM) that sounds even more
interesting.

> > Another thing would be to create /boot as a separate partition.
>
> Yes, that's what i always advise: /boot on separate ext2 partition. Then
> GRUB resumes fast.

well, this is small system, using yet another partition looked like useless
waste :)

thank you for explanation

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFWUD1R6LMutpd94wRAtWFAJ92STsDVby88UUWmNVK1q41X96RXgCeN6o4
ilUTLBdKZPsWPkWi5LOKsbg=
=U1xV
-----END PGP SIGNATURE-----

2006-11-14 14:24:11

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

Hi!

> > > Maybe its a journal size thing, you could try "sync" before suspend and
> > > see if it helps.
> >
> > We already sync inside the kernel, it does not help here, though.
> > Blockdev freezing might help.
>
> is there patch applicable to vanilla kernel? After repairing reiser several
> times (due to hard lockups during suspend-to-RAM) that sounds even more
> interesting.

Could you do the test Stefan asked? I do not think you'll kill
reiserfs by single forced powerdown.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2006-11-14 20:47:33

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 14 November 2006 17:23, Pavel Machek wrote:
> Hi!
>
> > > > Maybe its a journal size thing, you could try "sync" before suspend
> > > > and see if it helps.
> > >
> > > We already sync inside the kernel, it does not help here, though.
> > > Blockdev freezing might help.
> >
> > is there patch applicable to vanilla kernel? After repairing reiser
> > several times (due to hard lockups during suspend-to-RAM) that sounds
> > even more interesting.
>
> Could you do the test Stefan asked? I do not think you'll kill
> reiserfs by single forced powerdown.
>

well, I did it accidentally :) (forgot to plug in power and after 2 hours on
battery notebook simply switched off) and yes, there was some noticeable
delay loading grub. I also tried fs freezer without any visible effect. The
patches from mm I applied to vanilla kernel:

add-include-linux-freezerh-and-move-definitions-from.patch
swsusp-cleanup-whitespace-in-freezer-output.patch
swsusp-freeze-filesystems-during-suspend-rev-2.patch
swsusp-thaw-userspace-and-kernel-space-separately.patch

Do I need some more patches for this to work?

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFWitgR6LMutpd94wRAjh4AKCnGvpzxHuTEj+xKvEP7YhmESkD1wCffCm3
z0ZM59BV8FZUTy/onowVyW8=
=Vt7w
-----END PGP SIGNATURE-----

2006-11-14 22:57:54

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Tue 2006-11-14 23:47:27, Andrey Borzenkov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 14 November 2006 17:23, Pavel Machek wrote:
> > Hi!
> >
> > > > > Maybe its a journal size thing, you could try "sync" before suspend
> > > > > and see if it helps.
> > > >
> > > > We already sync inside the kernel, it does not help here, though.
> > > > Blockdev freezing might help.
> > >
> > > is there patch applicable to vanilla kernel? After repairing reiser
> > > several times (due to hard lockups during suspend-to-RAM) that sounds
> > > even more interesting.
> >
> > Could you do the test Stefan asked? I do not think you'll kill
> > reiserfs by single forced powerdown.
> >
>
> well, I did it accidentally :) (forgot to plug in power and after 2 hours on
> battery notebook simply switched off) and yes, there was some noticeable
> delay loading grub. I also tried fs freezer without any visible effect. The
> patches from mm I applied to vanilla kernel:
>
> add-include-linux-freezerh-and-move-definitions-from.patch
> swsusp-cleanup-whitespace-in-freezer-output.patch
> swsusp-freeze-filesystems-during-suspend-rev-2.patch
> swsusp-thaw-userspace-and-kernel-space-separately.patch
>
> Do I need some more patches for this to work?

I guess reiserfs would need to respond to filesystem freezing.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2006-11-15 04:01:49

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 15 November 2006 01:57, Pavel Machek wrote:
> On Tue 2006-11-14 23:47:27, Andrey Borzenkov wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Tuesday 14 November 2006 17:23, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > > Maybe its a journal size thing, you could try "sync" before
> > > > > > suspend and see if it helps.
> > > > >
> > > > > We already sync inside the kernel, it does not help here, though.
> > > > > Blockdev freezing might help.
> > > >
> > > > is there patch applicable to vanilla kernel? After repairing reiser
> > > > several times (due to hard lockups during suspend-to-RAM) that sounds
> > > > even more interesting.
> > >
> > > Could you do the test Stefan asked? I do not think you'll kill
> > > reiserfs by single forced powerdown.
> >
> > well, I did it accidentally :) (forgot to plug in power and after 2 hours
> > on battery notebook simply switched off) and yes, there was some
> > noticeable delay loading grub. I also tried fs freezer without any
> > visible effect. The patches from mm I applied to vanilla kernel:
> >
> > add-include-linux-freezerh-and-move-definitions-from.patch
> > swsusp-cleanup-whitespace-in-freezer-output.patch
> > swsusp-freeze-filesystems-during-suspend-rev-2.patch
> > swsusp-thaw-userspace-and-kernel-space-separately.patch
> >
> > Do I need some more patches for this to work?
>
> I guess reiserfs would need to respond to filesystem freezing.
>

OK the I guess it would have not worked in mm either. As far as I can tell the
only FS supporting it so far is XFS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFWpElR6LMutpd94wRApSWAJ0Wm2Yey6k0Lf0tMO5gBsOBYS5qLACgw8Xj
1rTy08rdsktGkvneKrweENM=
=xUbx
-----END PGP SIGNATURE-----

2006-12-16 19:38:46

by Lee

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

Andrey Borzenkov wrote:
> [...]
> This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel when
> I switch on the system after suspend to disk. Actually, after kernel has been
> loaded, the whole resuming (up to the point I have usable desktop again)
> takes about three time less than the process of loading kernel + initrd.
> During loading disk LED is constantly lit. This almost looks like kernel
> leaves HDD in some strange state, although I always assumed HDD/IDE is
> completely reinitialized in this case.
> [...]

I had the same problem (/boot on reiserfs, grub hanging for ages
after resume with 2.6.19), but in 2.6.19.1 it seems fixed. Do you
still have this bug, Andrey? I didn't find an update on this issue
on LKML.

Greetings, Lee

2007-01-02 10:05:33

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Sat, Dec 16, 2006 at 08:05:24PM +0100, Lee Garrett wrote:
> Andrey Borzenkov wrote:
> > [...]
> >This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel when I switch on the
> >system after suspend to disk. Actually, after kernel has been loaded, the whole resuming (up to
> >the point I have usable desktop again) takes about three time less than the process of loading
> >kernel + initrd. During loading disk LED is constantly lit. This almost looks like kernel leaves
> >HDD in some strange state, although I always assumed HDD/IDE is completely reinitialized in this
> >case.
> > [...]
>
> I had the same problem (/boot on reiserfs, grub hanging for ages after resume
> with 2.6.19), but in 2.6.19.1 it seems fixed. Do you still have this bug,
> Andrey? I didn't find an update on this issue on LKML.

I'm pretty sure this is just a coincidence, an issue about how the kernel
image is actually layed out on your filesystem. I don't think it actually
has to do anything with the version.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."

2007-01-02 10:58:10

by Xavier Bestel

[permalink] [raw]

Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

On Tue, 2007-01-02 at 11:05 +0100, Stefan Seyfried wrote:
> On Sat, Dec 16, 2006 at 08:05:24PM +0100, Lee Garrett wrote:
> > Andrey Borzenkov wrote:
> > > [...]
> > >This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel when I switch on the
> > >system after suspend to disk. Actually, after kernel has been loaded, the whole resuming (up to
> > >the point I have usable desktop again) takes about three time less than the process of loading
> > >kernel + initrd. During loading disk LED is constantly lit. This almost looks like kernel leaves
> > >HDD in some strange state, although I always assumed HDD/IDE is completely reinitialized in this
> > >case.
> > > [...]
> >
> > I had the same problem (/boot on reiserfs, grub hanging for ages after resume
> > with 2.6.19), but in 2.6.19.1 it seems fixed. Do you still have this bug,
> > Andrey? I didn't find an update on this issue on LKML.
>
> I'm pretty sure this is just a coincidence, an issue about how the kernel
> image is actually layed out on your filesystem. I don't think it actually
> has to do anything with the version.

Isn't the cause just that with that kernel the fs image is left unclean,
and grub has to replay the journal, which is slow ?

Xav

2007-01-02 12:14:47