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
> > > > > > > driv
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, co
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?
> > > >
> > > > Yes, it could, but they won't be. After
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 befo
On Monday, 30 October 2006 17:23, Stefan Seyfried wrote:
> 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, i
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
On Monday, 30 October 2006 12:08, Stefan Seyfried wrote:
> 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,
> > > >
> > > > Unfortunat
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
> > > r
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 cr
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
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 created,
> which is potentially dangerous.
Why is that dangerous?
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,
> which is potentially dangerous.
>
> We can fix this by mountin
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,
which is potentially dangerous.
We can fix this by mounting a tmpfs, creating the special device file on it
and using this file for the sus
13 matches
Mail list logo
