(unknown charset) Re: ATA_FLUSHCACHE failing

From: (unknown charset) Bruce Evans <bde_at_zeta.org.au>
Date: Thu, 6 May 2004 21:36:31 +1000 (EST)
On Wed, 5 May 2004, [ISO-8859-1] Søren Schmidt wrote:

> Mark Santcroos wrote:
> > Hi,
> >
> > I finally took the time to find out why I can't get a coredump on panic:
> >
> > ata_controlcmd(&ch->device[MASTER], ATA_FLUSHCACHE, 0, 0, 0);
> >
> > never returns in ata_shutdown() on my system (dmesg attached).
> >
> > Commenting it out gives me back my coredumps! ;)
> >
> > Have you seen this before?
>
> Nope, but I have seen a few disks that claims to support flush and then
> do wierd things when asked to...
>
> > If not, should we maybe create some blacklist of chips that report that
> > they can flush but in reality can't ...
>
> That would be blacklist of disks then, hmm, I'm not a fan of blacklists
> actually, they tend to always be as incorrect and incomplete as not
> having any. We should find out why it does not return, my guess is that
> it doesn't interrupt and the timeout doesn't fire because we are on the
> way down...

Panic dumps cannot use either device interrupts or timeouts, not to
mention normal locks, since panics may occur in almost any context;
in particular they may occur with all interrupts masked and important
locks in a bad state.  Immediate mode must be used, but it doesn't
seem to be, and a comment says that it is only used for other things:

% void
% ata_queue_request(struct ata_request *request)
% {
%     /* mark request as virgin */
%     request->result = request->status = request->error = 0;
%     if (!request->callback && !(request->flags & ATA_R_REQUEUE))
% 	sema_init(&request->done, 0, "ATA request done");
%
%     /* in IMMEDIATE_MODE we dont queue but call HW directly */
%     /* used only during reinit for getparm and config */
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
%     if ((request->device->channel->flags & ATA_IMMEDIATE_MODE) &&
% 	(request->flags & (ATA_R_CONTROL | ATA_R_IMMEDIATE))) {

Bruce
Received on Thu May 06 2004 - 02:37:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:53 UTC