Hi!
Well, but if some data structures are different than the tmpfs driver
thinks
they are, the kernel could oops/panic at umount, couldn't it?
Yes, it could, but they won't be. After a successful resume the tmpfs
will
be in the same state as before the suspend, won't
On Wed 2006-11-01 11:10:46, Rafael J. Wysocki wrote:
Hi,
On Wednesday, 1 November 2006 10:57, Pavel Machek wrote:
Hi!
Well, but if some data structures are different than the tmpfs
driver thinks
they are, the kernel could oops/panic at umount, couldn't it?
On Wednesday, 1 November 2006 11:13, Pavel Machek wrote:
On Wed 2006-11-01 11:10:46, Rafael J. Wysocki wrote:
Hi,
On Wednesday, 1 November 2006 10:57, Pavel Machek wrote:
Hi!
Well, but if some data structures are different than the tmpfs
driver thinks
they are,
On Mon, Oct 30, 2006 at 10:36:46AM +0100, Tim Dijkstra wrote:
On Mon, 30 Oct 2006 00:20:50 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Unfortunately in its current form s2disk causes the access time of the
resume
device special file to be updated after the suspend image has been
On Monday, 30 October 2006 09:37, Stefan Seyfried wrote:
On Mon, Oct 30, 2006 at 12:20:50AM +0100, Rafael J. Wysocki wrote:
Hi,
Unfortunately in its current form s2disk causes the access time of the
resume
device special file to be updated after the suspend image has been created,
On Mon, Oct 30, 2006 at 11:57:47AM +0100, Rafael J. Wysocki wrote:
On Monday, 30 October 2006 09:37, Stefan Seyfried wrote:
On Mon, Oct 30, 2006 at 12:20:50AM +0100, Rafael J. Wysocki wrote:
Hi,
Unfortunately in its current form s2disk causes the access time of the
resume
On Mon, Oct 30, 2006 at 12:26:55PM +0100, Rafael J. Wysocki wrote:
Well, but if some data structures are different than the tmpfs driver thinks
they are, the kernel could oops/panic at umount, couldn't it?
Yes, it could, but they won't be. After a successful resume the tmpfs will
be in
