Mailinglist Archive: opensuse-bugs (5398 mails)
| < Previous | Next > |
[Bug 269741] Normal boot procedure altered by presence past Suspend to Disk Operation
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Wed, 6 Jun 2007 07:10:29 -0600 (MDT)
- Message-id: <20070606131029.1F9181123@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=269741
------- Comment #21 from seife@xxxxxxxxxx 2007-06-06 07:10 MST -------
(In reply to comment #19)
> Now that you begin to understand you could please confirm that you are NOT ABLE
> to see the same difference in boot procedure as I have now described more
> clearly.
Yes, i am not able to see the same difference, and my machine crashes rather
often due to me using an (very :-) experimental X driver.
> Comment#17 the image (file) whatever you would like to call in written to the
> swap partition of the Disk "be cleared after resume.
>
> Please clarify "but it should only happen if you pull the plug very
> soon after resuming.". Is there a time delay feature set to delete at a
> specified time or is there a reliance on during normal operation /swap space is
> utilised by normal O/S application usage. I have noticed before hibernation,
> sometimes on my PC 1.5GB RAM /swap must be used as there is a text statement in
> the preparing for hibernation of ""Free Swap.....:
>
> OR
>
> Is this time delay a set parameter similar to a "flash dirty cache buffers"
> but in this case its "flush unneeded virtual memory"
No, the reason i was thinking this could be a problem is, that on a journaling
filesystem (like reiser), not everything that is written to disk is immediately
written to the final place where it will end up. So what i was thinking was "we
reset the preselected grub entry, but then the machine crashes, and the reset
entry actually does not get written to disk. On the next boot, the journal is
replayed and the old boot preference is restored" Torsten explained to me that
this cannot happen in this case, since the bootloader restores the old default
setting without going through the filesystem journal code, and without any
caching effects etc. So this thought of mine was going into the wrong
direction.
> Please clarify also slightly as an aside :
>
> If Suspend to disk created an image in Virtual RAM why we have so many issues*
It does not.
It merely uses the same medium that is also used vor virtual memory (the swap
partition) to store the data.
> with suspend to RAM and Suspend to Disk (RAM is RAM weather it be virtual or
> simulated.
No, suspend to RAM is absolutely totally different from suspend to disk. They
have basically nothing in common (apart from driver issues and stuff)
Anyway, i'm getting the feeling that we won't be able to fix this problem
without a setup where we can reproduce this nearby. So if you could name the
suse.de guy, this would be very helpful.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
------- Comment #21 from seife@xxxxxxxxxx 2007-06-06 07:10 MST -------
(In reply to comment #19)
> Now that you begin to understand you could please confirm that you are NOT ABLE
> to see the same difference in boot procedure as I have now described more
> clearly.
Yes, i am not able to see the same difference, and my machine crashes rather
often due to me using an (very :-) experimental X driver.
> Comment#17 the image (file) whatever you would like to call in written to the
> swap partition of the Disk "be cleared after resume.
>
> Please clarify "but it should only happen if you pull the plug very
> soon after resuming.". Is there a time delay feature set to delete at a
> specified time or is there a reliance on during normal operation /swap space is
> utilised by normal O/S application usage. I have noticed before hibernation,
> sometimes on my PC 1.5GB RAM /swap must be used as there is a text statement in
> the preparing for hibernation of ""Free Swap.....:
>
> OR
>
> Is this time delay a set parameter similar to a "flash dirty cache buffers"
> but in this case its "flush unneeded virtual memory"
No, the reason i was thinking this could be a problem is, that on a journaling
filesystem (like reiser), not everything that is written to disk is immediately
written to the final place where it will end up. So what i was thinking was "we
reset the preselected grub entry, but then the machine crashes, and the reset
entry actually does not get written to disk. On the next boot, the journal is
replayed and the old boot preference is restored" Torsten explained to me that
this cannot happen in this case, since the bootloader restores the old default
setting without going through the filesystem journal code, and without any
caching effects etc. So this thought of mine was going into the wrong
direction.
> Please clarify also slightly as an aside :
>
> If Suspend to disk created an image in Virtual RAM why we have so many issues*
It does not.
It merely uses the same medium that is also used vor virtual memory (the swap
partition) to store the data.
> with suspend to RAM and Suspend to Disk (RAM is RAM weather it be virtual or
> simulated.
No, suspend to RAM is absolutely totally different from suspend to disk. They
have basically nothing in common (apart from driver issues and stuff)
Anyway, i'm getting the feeling that we won't be able to fix this problem
without a setup where we can reproduce this nearby. So if you could name the
suse.de guy, this would be very helpful.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
| < Previous | Next > |