From: Pavel Machek <pavel@ucw.cz>
To: Andre Hedrick <andre@linux-ide.org>
Cc: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Fix 2.5.34+swsusp data corruption on IDE
Date: Sat, 14 Sep 2002 12:01:45 +0200 [thread overview]
Message-ID: <20020914100145.GA816@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <Pine.LNX.4.10.10209131537190.6925-100000@master.linux-ide.org>
Hi!
> I spoke with Jens, and he wants us to hold off until we can settle the
> current issues. I have one concern about the model, and maybe you can
> explain away the concern.
Jens, where is the problem? This should have absolutely zero impact on
"interesting" code, making only changes to initialization and
suspend/resume...
> Why are we not blocking read/write requests in the mainloop regardless?
> If the request gets to the subdriver, ide-disk, has it not gotten to far
> down the pipes?
All processes capable of generating requests are safely stopped, so no
request should get down to drivers. That's why I simply BUG_ON(), not
block or anything more sophiscated. It should never ever happen.
> Specifically ls120's and zips.
>
> I understand you are address disk but suspend is more than disk in the
> power management picture. Can you walk me through your process of sole
> concern with platter media? Remember microdrvies are platters too, as are
> flash drives, and memory drives.
High levels are stopped, so there are no new requests coming.
What is needed in idedisk_suspend is to make sure that no requests are
"in flight". DMA scribbling over random memory is not good thing.
idedisk_suspend then sends drive to standby to make sure writeback
caches are flushed.
as ls120s and zips... If they are DMA capable, they badly need
support. If not, they should not kill rest of the system during
suspend-to-disk, but still support would be nice.
> > +static int idedisk_suspend(struct device *dev, u32 state, u32 level)
> > +{
> > + ide_drive_t *drive = dev->driver_data;
> > +
> > + /* I hope that every freeze operations from the upper levels have
> > + * already been done...
> > + */
> > +
> > + BUG_ON(in_interrupt());
> > +
> > + if (level != SUSPEND_SAVE_STATE)
> > + return 0;
> > +
> > + /* wait until all commands are finished */
> > + /* FIXME: waiting for spinlocks should be done instead. */
> > + while (HWGROUP(drive)->handler)
> > + yield();
> > +
> > + /* set the drive to standby */
> > + printk(KERN_INFO "suspending: %s ", drive->name);
> > + if (drive->driver) {
> > + if (drive->driver->standby)
> > + drive->driver->standby(drive);
> > + }
> > + drive->blocked = 1;
> > +
> > + return 0;
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
next prev parent reply other threads:[~2002-09-14 9:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-13 21:15 Pavel Machek
2002-09-13 22:46 ` Andre Hedrick
2002-09-14 10:01 ` Pavel Machek [this message]
2002-09-14 20:40 ` Andre Hedrick
2002-09-15 19:20 ` Pavel Machek
2002-09-16 4:57 ` Andre Hedrick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020914100145.GA816@atrey.karlin.mff.cuni.cz \
--to=pavel@ucw.cz \
--cc=andre@linux-ide.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®