Cornelia Huck wrote:
> On Fri, 30 Mar 2007 22:19:52 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>>> Shouldn't getting/putting the module refcount be solely done in
>>> kobject.c? Grab the module reference when the kobject is created and
>>>
Cornelia Huck wrote:
> On Fri, 30 Mar 2007 22:58:39 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> It's a little bit more convoluted than that. Module reference count of
>> zero doesn't indicate that there is no one referencing the module. It
>>
Cornelia Huck wrote:
> On Sat, 31 Mar 2007 00:08:19 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> (3) make sure all existing kobjects are released by module exit function.
>>
>> For example, let's say there is a hypothetical disk device /dev/dk0
&g
Tejun Heo wrote:
> Cornelia Huck wrote:
>> On Sat, 31 Mar 2007 00:08:19 +0900,
>> Tejun Heo <[EMAIL PROTECTED]> wrote:
>>
>>> (3) make sure all existing kobjects are released by module exit function.
>>>
>>> For example, let's say t
Cornelia Huck wrote:
On Sat, 31 Mar 2007 12:12:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
Hm, but as long as dk0 is registered, it can be looked up and someone
could get a reference on it.
Yeah, exactly. That's why any getting any kobject reference backed by a
module must be
Hello, James, Greg.
On Fri, Mar 30, 2007 at 01:19:34PM -0500, James Bottomley wrote:
> That's sort of what I was reaching for too ... it just looks to me that
> all the sysfs glue is in kobject, so they make a good candidate for the
> pure sysfs objects. Whatever we do, there has to be breakable
Cornelia Huck wrote:
> On Mon, 2 Apr 2007 11:20:48 +0200,
> Cornelia Huck <[EMAIL PROTECTED]> wrote:
>
>> Cool. However, there's something fishy there (not sure whether it's in
>> your patch or a latent bug in the ccw bus code that just has been
>> uncovered):
>
> Similar bug when loading/unloadi
Justin Piszcz wrote:
>
>
> On Thu, 5 Apr 2007, Justin Piszcz wrote:
>
>> Had a quick question, this is the first time I have seen this happen,
>> and it was not even under during heavy I/O, hardly anything was going
>> on with the box at the time.
>
> .. snip ..
>
> # /usr/bin/time badblocks -
James Bottomley wrote:
> On Tue, 2007-04-17 at 11:20 -0400, Jeff Garzik wrote:
>> then, unless there are dependencies in libata-dev, how about Tejun
>> pushes patches 3-4 through scsi-misc as well?
>
> Sure ... as long as there are no dependencies.
James, are you going to rebase scsi-misc-2.6 be
Hello,
Kristen Carlson Accardi wrote:
> static unsigned int ata_print_id = 1;
> @@ -1744,6 +1745,23 @@ int ata_dev_configure(struct ata_device
> }
> dev->cdb_len = (unsigned int) rc;
>
> + /*
> + * check to see if this ATAPI device supports
Kristen Carlson Accardi wrote:
> +static struct disk_attribute disk_attr_capability = {
> + .attr = {.name = "capability_flags", .mode = S_IRUGO },
> + .show = disk_capability_read
> +};
How about just "capability"? I think that would be more consistent with
other attributes.
--
tejun
Kristen Carlson Accardi wrote:
> Send an uevent to user space to indicate that a media change event has
> occurred.
>
> Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
>
> Index: 2.6-git/block/genhd.c
> ===
> --- 2.6-git.
Michal Piotrowski wrote:
> On 01/05/07, Mark Lord <[EMAIL PROTECTED]> wrote:
>> Forwarding to linux-scsi and linux-ide mailing lists.
>>
>> Frank van Maarseveen wrote:
>> > Tested on 2.6.20.6 and 2.6.21.1
>> >
>> > I decided to swich from the old IDE drivers to libata and now there
>> > seems to be
Frank van Maarseveen wrote:
> On Fri, May 04, 2007 at 10:16:32AM +0200, Tejun Heo wrote:
>> Michal Piotrowski wrote:
>>> On 01/05/07, Mark Lord <[EMAIL PROTECTED]> wrote:
>>>> Forwarding to linux-scsi and linux-ide mailing lists.
>>>>
>>>&
Kristen Carlson Accardi wrote:
> This patch series implements Asynchronous Notification (AN) for SATA
> ATAPI devices as defined in SATA 2.5 and AHCI 1.1 and higher. Drives
> which support this feature will send a notification when new media is
> inserted and removed, preventing the need for user
ssleep in the command translation
> path. The commit that did it was this one:
>
> commit 920a4b1038e442700a1cfac77ea7e20bd615a2c3
> Author: Tejun Heo <[EMAIL PROTECTED]>
> Date: Fri May 4 21:28:48 2007 +0200
>
> libata: implement libata.spindown_compat
>
> I'm afr
James Bottomley wrote:
> On Wed, 2007-03-21 at 16:05 +0900, Tejun Heo wrote:
>> This patch breaks the existing libata suspend/resume support and thus
>> should not be applied before libata is updated. So, please don't
>> apply it yet.
>
> I don't have a git t
Hello, Henrique.
Henrique de Moraes Holschuh wrote:
> On Mon, 14 May 2007, Francesco Pretto wrote:
>> Ubuntu [1] ang Gentoo [2] bugs opened. Sent a mail to Miquel van
>> Smoorenburg, dev of sysvinit.
>
> For all Debian sysvinit issues, please send email to
> [EMAIL PROTECTED] (added to CC).
>
>
Alan Stern wrote:
> This patch (as909) fixes a couple of refcounting errors in the sd
> driver's suspend and resume methods.
>
> Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Acked-by: Tejun Heo <[EMAIL PROTECTED]>
Thanks.
--
tejun
-
To unsubscribe from this lis
Kristen Carlson Accardi wrote:
> Hi,
> This series of patches enables Aggressive Link Power Management for AHCI
> devices, as documented in the AHCI spec. On my laptop (a Lenovo X60), this
> saves me a full watt of power. On other systems, reported power savings
> range from .5-1.5 Watts. It ha
Arjan van de Ven wrote:
>> I'm not sure about this. We need better PM framework to support
>> powersaving in other controllers and some ahcis don't save much
>> when only link power management is used,
>
> do you have data to support this?
Yeah, it was some Lenovo notebook. Pavel is more famil
Arjan van de Ven wrote:
>>> The data we have from this patch is that it saves typically a Watt of
>>> power (depends on the machine of course, but the range is 0.5W to
>>> 1.5W). If you want to also have an even more agressive thing where
>>> you want to start disabling the entire controller... I d
Matthew Garrett wrote:
> On Tue, Jun 12, 2007 at 11:17:14AM -0300, Henrique de Moraes Holschuh wrote:
>> On Tue, 12 Jun 2007, Matthew Garrett wrote:
>>> Laptop bays are designed to deal with hotplugging PATA - I don't think
>>> this is too much of an issue :)
>> The new SATA ones use the SATA hard
Kristen Carlson Accardi wrote:
> I'm not sure about this. We need better PM framework to support
> powersaving in other controllers and some ahcis don't save much
> when only link power management is used,
do you have data to support this?
>>> Yeah, it was some Lenovo notebook.
Jens Axboe wrote:
>> 1. It didn't have proper interface with userland. This was mainly
>> because of missing ATA sysfs nodes. I'm not sure whether adding this to
>> scsi node is a good idea.
>>
>> 2. It was focused on SATA link PS and couldn't cover the Lenovo case.
>>
>> I think we need somethin
Salyzyn, Mark wrote:
> Updated patch to address overlap with patches introduced by FUJITA
> Tomonori <[EMAIL PROTECTED]>. Tejun, please inspect.
I'm sorry but this patch is really out of my hand. James?
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body
Michael Tokarev wrote:
> [Offtopic notice: For the first time I demonstrated some
> speed testing results on linux-ide mailinglist, as a
> demonstration how [NT]CQ can help. But later, someone
> becomes curious and posted that email to lkml, asking
> for more details. Since that, I become more cu
Hello,
Michael Tokarev wrote:
> Well. It looks like the results does not depend on the
> elevator. Originally I tried with deadline, and just
> re-ran the test with noop (hence the long delay with
> the answer) - changing linux elevator changes almost
> nothing in the results - modulo some rando
On Mon, Jan 08, 2018 at 10:16:55PM -0500, Martin K. Petersen wrote:
>
> Tejun,
>
> Are you OK with me pulling this change through the SCSI tree?
Sure, yeah, please go ahead.
Thanks.
--
tejun
Hello,
On Wed, Jan 24, 2018 at 09:20:25PM +0800, chenxiang wrote:
> In ata_eh_reset, it will reset three times at most for sata disk. For
> some drivers through libsas, it calls sas_ata_hard_reset at last. When
> device is gone, function sas_ata_hard_reset will return -ENODEV. But
> it will still
On Sat, Feb 03, 2018 at 08:30:56PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> syzkaller reported a crash in ata_bmdma_fill_sg() when writing to
> /dev/sg1. The immediate cause was that the ATA command's scatterlist
> was not DMA-mapped, which causes 'pi - 1' to underflow, resulting in a
On Sat, Feb 03, 2018 at 08:33:27PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0. This
> happened because it issued a READ_6 command with no data buffer.
>
> Just remove the WARN(), as it doesn't appear indicate a kernel bu
On Sat, Feb 03, 2018 at 08:33:51PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> syzkaller hit a WARN() in ata_bmdma_qc_issue() when writing to /dev/sg0.
> This happened because it issued an ATA pass-through command (ATA_16)
> where the protocol field indicated that NCQ should be used -- bu
Hello,
On Tue, Feb 13, 2018 at 09:44:53AM +0800, chenxiang (M) wrote:
> For those drivers using libsas, i think they have the same issue.
> It takes about 1 minute to
> recover but actually device is gone, so this recover is useless for
> this scenario (when enter EH,
> all normal IOs are blocked
Hello,
On Mon, Feb 26, 2018 at 07:45:37PM +0800, chenxiang (M) wrote:
> >So, if there are real consequences, we can definitely add a way to
> >short-circuit the recovery logic but let's do that by adding proper
> >signaling rathr than testing for driver type.
>
> I am not familiar with ata recove
On Tue, Feb 27, 2018 at 03:08:01PM +0800, Jason Yan wrote:
> We've got a kernel panic when using sata disk with sas controller:
>
> [115946.152283] Unable to handle kernel NULL pointer dereference at virtual
> address 07d8
> [115946.223963] CPU: 0 PID: 22175 Comm: kworker/0:1 Tainted: G
On Wed, Feb 28, 2018 at 09:11:10AM +0800, Jason Yan wrote:
> We've got a kernel panic when using sata disk with sas controller:
>
> [115946.152283] Unable to handle kernel NULL pointer dereference at virtual
> address 07d8
> [115946.223963] CPU: 0 PID: 22175 Comm: kworker/0:1 Tainted: G W O
Hello,
On Wed, Feb 28, 2018 at 03:18:39PM +0800, chenxiang (M) wrote:
> If we can introduce a port flags such as ATA_LFLAG_DISABLED or
> ATA_EHI_NO_RECOVERY before ata_eh_recover,
> it will skip recovery. But we only get device status NODEV from
> ata_do_reset which is after ata_eh_recover, i don'
Hello,
On Fri, Mar 02, 2018 at 04:40:24AM +0900, Damien Le Moal wrote:
> For a successful setting of the device transfer speed mode in
> ata_dev_set_mode(), do not print the message
> "ataX.XX: configured for xxx" if the EH context has the quiet flag set.
>
> Signed-off-by: Damien Le Moal
> ---
On Fri, Mar 02, 2018 at 04:40:18AM +0900, Damien Le Moal wrote:
> This series introduces changes to scsi and libata error handling for ZBC and
> ZAC
> devices.
>
> The first patch moves ZBC specific error handling in sd_zbc_complete() to a
> generic scsi error function that can be used also in li
On Fri, Mar 16, 2018 at 10:35:16AM -0700, Bart Van Assche wrote:
> Since blk_queue_enter() uses rcu_read_lock_sched() scsi_device_quiesce()
> must use synchronize_sched().
Is there a reason to use sched-RCU here instead of the regular one?
If not, it'd be better to switch to regular RCU than the o
; No functional change of the device scanning and io path. The ata
> transport class was deleted when destroying the sas devices.
>
> Signed-off-by: Jason Yan
> CC: Dan Williams
> CC: Tejun Heo
Looks good to me on the ata side.
Acked-by: Tejun Heo
Thanks.
--
tejun
On Sun, Jun 04, 2017 at 02:42:19PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series adds support for using our new generic TCG OPAL code with
> SATA disks, and as side effect for SCSI disks (although so far it doesn't
> seem like none of those actually exist).
Applied 1-5 to libata/for-4
On Mon, Jun 26, 2017 at 12:43:27PM -0400, Martin K. Petersen wrote:
>
> Christoph,
>
> > ping?
>
> Looks good to me. I'll queue it up for 4.13 as soon as Linus has pulled
> in the ata bits.
I can route it through libata tree w/ your ack if that's more convenient.
Thanks.
--
tejun
On Mon, Jun 26, 2017 at 12:07:15AM -0700, Christoph Hellwig wrote:
> Tejun, does this look ok to you?
Sure,
Acked-by: Tejun Heo
Thanks.
--
tejun
On Mon, Jun 26, 2017 at 12:07:30AM -0700, Christoph Hellwig wrote:
> Tejun, does this look ok to you?
Acked-by: Tejun Heo
Thanks.
--
tejun
On Sat, Jun 24, 2017 at 03:41:10AM +0900, Minwoo Im wrote:
> SAT-4(SCSI/ATA Translation) supports for an ata pass-thru(32).
> This patch will allow to translate an ata pass-thru(32) SCSI cmd
> to an ATA cmd.
>
> Signed-off-by: Minwoo Im
> Reviewed-by: Bart Van Assche
Applied to libata/for-4.13.
On Mon, Jun 19, 2017 at 02:26:46PM +0200, Christoph Hellwig wrote:
> Just wire up the generic TCG OPAL infrastructure to the SCSI disk driver
> and the Security In/Out commands.
>
> Note that I don't know of any actual SCSI disks that do support TCG OPAL,
> but this is required to support ATA disk
Hello, Joe.
On Thu, Aug 10, 2017 at 10:45:54AM -0400, Joe Lawrence wrote:
> In the case of my USB DVD -> laptop example, there is no media in my
> device, however I still see the DISK_EVENT_MEDIA_CHANGE event. This is
> a bit confusing, and I was wondering if there was an explanation for
> the fo
Hello,
On Thu, Aug 17, 2017 at 11:24:22AM +0200, Bernd Schubert wrote:
> > More concerning is the fact that these undetected errors can make their
> > way even when the higher application consistently calls sync() and/or
> > fsync. In other words, it seems than even acknowledged writes can fail
>
Hello,
On Thu, Aug 17, 2017 at 03:18:06PM +0200, Bernd Schubert wrote:
> So for Gionatan the root cause was an instable power supply, but in my
> case there wasn't any power loss, there were just failed sata commands.
> I'm not sure if this was a port or cable issue - once I changed port and
> sat
Hello,
On Thu, Aug 17, 2017 at 04:15:35PM +0200, Gionatan Danti wrote:
> Ok, so *this* is the root cause of the problem: libata not
> identifying spurious link renegotiations vs brief powerloss/powerup
> events. Out of curiosity: is this a SATA-specific problem (ie: in
> the SATA specification), o
t; reverting 85ef06d1d252f6a2e73b678591ab71caad4667bb).
>
> I'm trying to understand why this commit leads to the issue of i/o
> failing on spun down drives, in hopes of being able to fix it. Meanwhile
> maybe Tejun Heo (author of the commit) or Jens Axboe (the committer) are
> able to shed s
Hello,
On Tue, Jul 17, 2012 at 09:39:41PM +0200, Matthias Prager wrote:
> I could not however reproduce the issue on any other device than a LSI
> SAS controller (using SATA disks) - on a regular ICH10 using AHCI and a
> SATA drive I don't see these i/o errors. But since I'm experiencing
> these i
Hello,
On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote:
> Now I'm not sure this isn't taping over another bug. Which leads me to
> my question: What is the correct behavior?
>
> #1 Issuing a separate spin-up command (START UNIT?) prior to sending i/o
> by setting allow_restart=1 f
Hello,
On Mon, Jul 23, 2012 at 01:14:00AM +0200, Matthias Prager wrote:
> as it turns out my workaround (setting allow_restart=1) isn't all that
> useful after all. There are no more i/o errors because the drive just
> never goes to standby mode anymore (at least 'hdparm -y /dev/sda' does
> not se
Hello, James.
On Wed, Jul 25, 2012 at 06:19:13PM +0400, James Bottomley wrote:
> > I haven't consulted SAT but it seems like a bug in SAS driver or
> > firmware. If it's a driver bug, we better fix it there. If a
> > firmware bug, working around those is one of major roles of drivers,
> > so I t
Hello, Bart, Mike.
On Thu, Sep 06, 2012 at 08:52:09PM +0200, Bart Van Assche wrote:
> >> The purpose of this patch is indeed to make *blk_run_queue() calls from
> >> the block layer safe. There are several direct or indirect
> >> *blk_run_queue() calls in the block layer where a reference on the q
Hello,
On Fri, Sep 07, 2012 at 08:57:10AM +0200, Bart Van Assche wrote:
> I'm not sure it would be a good idea to add a blk_queue_dead() check in
> any of the __blk_run_queue() variants since blk_drain_queue() can invoke
> __blk_run_queue() to drain the queue.
Right, we can't cancel requests from
Hello,
On Fri, Jul 20, 2012 at 06:30:01PM +0200, Paolo Bonzini wrote:
> These commands cannot be issued right now without giving CAP_SYS_RAWIO to
> the process who wishes to send them. These commands can be useful also to
> non-privileged programs who have access to the block devices. For exampl
Hello, Paolo.
On Tue, Sep 11, 2012 at 07:56:53PM +0200, Paolo Bonzini wrote:
> Understood; unfortunately, there is another major user of it
> (virtualization). If you are passing "raw" LUNs down to a virtual
> machine, there's no possibility at all to use a properly encapsulated
Is there still c
Hello, Paolo.
On Tue, Sep 11, 2012 at 08:54:03PM +0200, Paolo Bonzini wrote:
> > On Tue, Sep 11, 2012 at 07:56:53PM +0200, Paolo Bonzini wrote:
> >> Understood; unfortunately, there is another major user of it
> >> (virtualization). If you are passing "raw" LUNs down to a virtual
> >> machine, th
Hello, Paolo.
On Tue, Sep 11, 2012 at 09:24:32PM +0200, Paolo Bonzini wrote:
> > Couldn't it intercept some of them - e.g. RWs and discards?
> > What's the benifit / use case of doing pure bypass?
>
> Basically, using the same storage technology for bare metal and
> virtualized systems. IMHO los
Hello, Paolo.
On Tue, Sep 11, 2012 at 11:50:38PM +0200, Paolo Bonzini wrote:
> > Either way, with or without virtualization, making detailed error
> > information to userland is a valid goal. I *think* we're finally
> > getting there after years of talking via structured printk. I don't
> > know
Hello,
On Tue, Sep 11, 2012 at 3:10 PM, Paolo Bonzini wrote:
> Il 12/09/2012 00:02, Tejun Heo ha scritto:
>> SG_IO itself is a bypassing interface. It bypasses most of block
>> layer and the kernel doesn't have any idea (apart from the adhoc
>> filtering) about what&#
Hello,
On Tue, Sep 11, 2012 at 08:42:28AM +0200, Bart Van Assche wrote:
> Good question. As far as I can see calling request_queue.request_fn() is
> fine as long as the caller holds a reference on the queue. If e.g.
> scsi_request_fn() would get invoked after blk_drain_queue() finished it
> will r
Hello, Bart.
On Thu, Sep 13, 2012 at 09:26:59AM +0200, Bart Van Assche wrote:
> On 09/12/12 22:53, Tejun Heo wrote:
> > The problem at hand IIUC is ->request_fn() being invoked when
> > request_queue itself is alive but the underlying driver is gone. We
> > already make
Hello,
On Thu, Sep 13, 2012 at 08:27:29PM +0200, Bart Van Assche wrote:
> If I do not receive further feedback I'll start testing the patch below
> (on top of the patch at the start of this thread):
Yeah, it generally seems fine to me. This makes Chanho's patch
unnecessary, right? Just some min
Hello,
On Sun, Sep 23, 2012 at 06:17:49PM +0200, Bart Van Assche wrote:
> This patch is the result of running the command below and manually
> fixing up indentation:
>
> git grep -lE 'blk_queue_dead|QUEUE_FLAG_DEAD' |
> xargs sed -i .tmp -e 's/blk_queue_dead/blk_queue_dying/g' \
> -e 's/Q
Hello, Bart.
On Sun, Sep 23, 2012 at 06:20:13PM +0200, Bart Van Assche wrote:
> Some request_fn implementations, e.g. scsi_request_fn(), unlock
> the queue lock. Make sure that blk_cleanup_queue() waits until all
> active request_fn invocations have finished. This fixes a potential
> use-after-fre
ad/blk_queue_dying/g' \
> -e 's/QUEUE_FLAG_DEAD/QUEUE_FLAG_DYING/g'
>
> Cc: James Bottomley
> Cc: Mike Christie
> Cc: Jens Axboe
> Cc: Tejun Heo
> Cc: Chanho Min
> Signed-off-by: Bart Van Assche
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscri
Hello,
On Wed, Oct 10, 2012 at 05:08:01PM +0200, Bart Van Assche wrote:
> A block driver may start cleaning up resources needed by its
> request_fn as soon as blk_cleanup_queue() finished, so request_fn
> must not be invoked after draining finished.
Can you please make the commit message more ver
Hello,
On Wed, Oct 10, 2012 at 05:09:04PM +0200, Bart Van Assche wrote:
> Some request_fn implementations, e.g. scsi_request_fn(), unlock
> the queue lock. Make sure that blk_cleanup_queue() waits until all
> active request_fn invocations have finished. This fixes a potential
> use-after-free at t
Hello,
On Wed, Oct 10, 2012 at 05:10:35PM +0200, Bart Van Assche wrote:
> Avoid that the sdev reference count can drop to zero before
> the queue is run by scsi_run_queue(). Also avoid that the sdev
> reference count can drop to zero in the same function by invoking
> __blk_run_queue().
I think t
Hello, Paolo.
Sorry about the delay. -EWASTRAVELING and it seems Jens was too.
On Thu, Oct 04, 2012 at 12:12:12PM +0200, Paolo Bonzini wrote:
> Il 25/09/2012 17:30, Paolo Bonzini ha scritto:
> > The set of use cases for SG_IO is quite variable that no single filter can
> > accomodate all of them
Hello, Bart.
On Tue, Oct 23, 2012 at 02:16:12PM +0200, Bart Van Assche wrote:
> On 10/17/12 01:51, Tejun Heo wrote:
> >>-void blk_drain_queue(struct request_queue *q, bool drain_all)
> >>+static void blk_drain_queue(struct request_queue *q, bool drain_all)
Hello, Bart.
On Tue, Oct 23, 2012 at 02:11:29PM +0200, Bart Van Assche wrote:
> >__blk_run_queue_uncond() is a cold path and I don't think adding a
> >test there matters but I think it would be better if we avoid an extra
> >branch if possible for __blk_run_queue(). Can't we merge
> >blk_queue_st
Hello,
On Fri, Oct 26, 2012 at 02:01:23PM +0200, Bart Van Assche wrote:
> Code like "drain |= q->nr_rqs[i]" might result in blk_drain_queue()
> to finish early if the expression at the RHS is a multiple of 256
> since the drain variable is only eight bits wide. Avoid this by
> changing the type of
On Sun, Oct 28, 2012 at 06:47:22PM -0700, Tejun Heo wrote:
> Hello,
>
> On Fri, Oct 26, 2012 at 02:01:23PM +0200, Bart Van Assche wrote:
> > Code like "drain |= q->nr_rqs[i]" might result in blk_drain_queue()
> > to finish early if the expression at the RHS
stie
> Cc: Jens Axboe
> Cc: Tejun Heo
> Cc: Chanho Min
> Signed-off-by: Bart Van Assche
Acked-by: Tejun Heo
Nit: probably better to make this change right before the said patch.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
Hello,
On Fri, Oct 26, 2012 at 02:03:45PM +0200, Bart Van Assche wrote:
> A block driver may start cleaning up resources needed by its
> request_fn as soon as blk_cleanup_queue() finished, so request_fn
> must not be invoked after draining finished.
Please be a lot more detailed. Please describe
up resources needed by its request_fn as soon as
> blk_cleanup_queue() finished, so blk_cleanup_queue() must wait
> for all outstanding request_fn invocations to finish.
Ditto. More verbose explanation *please*.
> Reported-by: Chanho Min
> Cc: James Bottomley
> Cc: Mike Christie
&g
move_device() such that it is guaranteed that the newly
> added get_device() call succeeds.
>
> Reported-and-tested-by: Chanho Min
> Reference: http://lkml.org/lkml/2012/8/2/96
> Cc: Jens Axboe
> Cc: Tejun Heo
> Reviewed-by: Mike Christie
> Signed-off-by: Bart Van Assc
o remove the get_device() / put_device() pair from
> scsi_request_fn().
>
> Cc: James Bottomley
> Cc: Mike Christie
> Cc: Jens Axboe
> Cc: Tejun Heo
> Signed-off-by: Bart Van Assche
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the lin
On Mon, Oct 29, 2012 at 05:01:32PM +0800, Aaron Lu wrote:
> ata_exec_internal will preempt the ata link's active_tag and ata port's
> qc_active flags, this is OK for error recovery, but if normal code path
> wants to use ata_exec_internal, there is a problem: we need to check if
> it is OK to issue
Hello,
On Mon, Oct 29, 2012 at 05:01:36PM +0800, Aaron Lu wrote:
> ODD_suspenddisk_events_workfn
> ata_port_suspend check_events
> disk_block_events resume ODD
> cancel_delayed_work_sync resume parent
> (waiting
Hello,
On Tue, Oct 30, 2012 at 11:00:16AM +0800, Aaron Lu wrote:
> > Why not do the discovery from EH?
>
> Do you mean set a device level EH flag and then schedule EH to do the
> discovery?
Yeah, something like that or why can't it be done while probing the
device in the first place?
Thanks.
-
Hello,
On Tue, Oct 30, 2012 at 03:04:17PM +0800, Aaron Lu wrote:
> > check_event() can retry. Just add a per-sr mutex which is try-locked
> > by sr_block_check_events() and grab it when entering zero power.
>
> Good suggestion. I didn't think about solving it this way.
>
> Many people suggest m
Hello,
On Tue, Oct 30, 2012 at 11:09:21AM +0800, Aaron Lu wrote:
> I'm not aware of a place to store such ODD specific information when
> probing the device.
You can always add some fields. :)
> I'm currently storing the loading mech type in structure zpodd, which
> gets created after the corres
Hello, Aaron.
On Thu, Nov 01, 2012 at 10:35:10AM +0800, Aaron Lu wrote:
> > You can always add some fields. :)
>
> OK. My concern is that, such information is only useful to ZPODD
> capable device+platforms, so checking this loading mechanism thing for
> all ATAPI devices during probe time doesn'
Hello,
On Fri, Nov 09, 2012 at 02:51:55PM +0800, Aaron Lu wrote:
> void ata_acpi_unbind(struct ata_device *dev)
> {
> + if (zpodd_dev_enabled(dev))
> + zpodd_deinit(dev);
Maybe zpodd_exit() instead?
> +void zpodd_init(struct ata_device *dev)
> +{
> + int ret;
> + struct
On Fri, Nov 09, 2012 at 02:51:56PM +0800, Aaron Lu wrote:
> Since the ata acpi notification code introduced in commit
> 3bd46600a7a7e938c54df8cdbac9910668c7dfb0 is solely for ZPODD, and we
> now have a dedicated place for it, move these code there.
>
> And the add/remove_pm_notifier code is simpli
On Fri, Nov 09, 2012 at 02:51:57PM +0800, Aaron Lu wrote:
> The atapi_eh_tur and atapi_eh_request_sense can be reused by ZPODD
> code, so separate them out to a file named libata-atapi.c, and the
> Makefile is modified accordingly. No functional changes should result
> from this commit.
Why is thi
Hello,
On Fri, Nov 09, 2012 at 02:51:58PM +0800, Aaron Lu wrote:
> @@ -784,7 +784,13 @@ static int ata_acpi_push_id(struct ata_device *dev)
> */
> int ata_acpi_on_suspend(struct ata_port *ap)
> {
> - /* nada */
> + struct ata_device *dev;
> +
> + ata_for_each_dev(dev, &ap->link, EN
On Fri, Nov 09, 2012 at 02:51:59PM +0800, Aaron Lu wrote:
> A new interface to block disk events is added, this interface is
> meant to eliminate a race between PM runtime callback and disk events
> checking.
>
> Suppose the following device tree:
> device_sata_port (the parent)
> device_ODD
Hello, Alan.
On Mon, Nov 12, 2012 at 02:18:11PM -0500, Alan Stern wrote:
> > Weren't you gonna do something different about this? I mean, if sr
> > knows that autopm kicked in, it can simply tell the block layer that
> > nothing is going on. Wouldn't that be simpler?
>
> It wouldn't work for no
t; Cc: Ric Wheeler
> Cc: Tejun Heo
> Signed-off-by: Paolo Bonzini
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; Cc: James Bottomley
> Cc: Jens Axboe
> Cc: Ric Wheeler
> Cc: Tejun Heo
> Signed-off-by: Paolo Bonzini
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
M
Hello, Aaron.
On Wed, Nov 14, 2012 at 09:32:27AM +0800, Aaron Lu wrote:
> > I don't think you're supposed to use dev->private_data from libata
> > core layer. Just add a new field. Nobody cares about adding 8 more
> > bytes to struct ata_device and spending 8 more bytes is way better
> > than mu
Hello, Aaron.
On Wed, Nov 14, 2012 at 10:18:23AM +0800, Aaron Lu wrote:
> On 11/13/2012 03:13 AM, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Nov 09, 2012 at 02:51:58PM +0800, Aaron Lu wrote:
> >> +#define POWEROFF_DELAY (30 * 1000) /*
401 - 500 of 719 matches
Mail list logo
