LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Mark Lord <liml@rtr.ca>, Matthew Wilcox <matthew@wil.cx>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jeff Garzik <jeff@garzik.org>
Subject: Re: ata_ram driver
Date: Fri, 07 Mar 2008 08:55:36 +0900	[thread overview]
Message-ID: <47D08478.8010700@gmail.com> (raw)
In-Reply-To: <1204817301.3062.3.camel@localhost.localdomain>

James Bottomley wrote:
>> It's because of the sequence of events.  Currently, driver unload
>> sequence is the same as when the device is hot unplugged.  libata
>> detects that the device is gone and disables it and report it to SCSI
>> layer.  SCSI layer takes over and tries to kill the SCSI device and tell
>> sd to shutdown and sd issues START_STOP to shutdown which fails w/
>> DID_BAD_TARGET because the matching ATA device is already gone.  I've
>> left it that way because I'm not sure whether spinning down the drive on
>> driver unload is the correct thing to do.  The message is annoying tho.
> 
> Um, it's not supposed to happen that way.  Your signal that a disk is
> gone is slave destroy ... and we don't call that until after the target
> has been processed.  Devices are supposed to stay online (if possible)
> from slave alloc to slave destroy.

Currently, it's like the following.

* Explicit unplug request via sysfs or whatever: ATA device stays online
till slave_destroy finishes.

* Hot unplugging: Nothing much libata can do.  ATA device is yanked out
by the user.

* Driver unload: Dealt the same way as hot unplugging.

Making driver unload like explicit unplug request is possible but it
will mean that drives will be spun down on driver unload, which can be
annoying to developers.  In addition, the code path is shared with
controller hot unplug in which case it's probably best not to issue any
new command.  So, I've been reluctant to make the change.  If the change
is required, I think it can be done by adding a few lines at the top of
ata_port_detach().  Jeff, what do you think?

-- 
tejun

  reply	other threads:[~2008-03-06 23:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-22 20:09 Matthew Wilcox
2008-02-22 21:27 ` Mark Lord
2008-03-06  8:21   ` Tejun Heo
2008-03-06 15:28     ` James Bottomley
2008-03-06 23:55       ` Tejun Heo [this message]
2008-03-07  0:01         ` James Bottomley
2008-03-07  0:13           ` Tejun Heo
2008-03-07  0:22             ` James Bottomley
2008-03-07  0:28               ` Tejun Heo
2008-03-07  0:39                 ` James Bottomley
2008-03-07  0:43                   ` Tejun Heo
2008-03-07  3:08                     ` [PATCH 1/2] scsi: export scsi_forget_host() Tejun Heo
2008-03-07  3:11                       ` [PATCH 2/2] libata: kill SCSI devices before detaching ata_host Tejun Heo
2008-03-07  2:16                 ` ata_ram driver Jeff Garzik
2008-03-07  2:44                   ` James Bottomley

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=47D08478.8010700@gmail.com \
    --to=htejun@gmail.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=jeff@garzik.org \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --subject='Re: ata_ram driver' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).