On Tue, Aug 11, 2020 at 09:55:54AM +0200, Martin Kepplinger wrote:
> On 10.08.20 16:13, Alan Stern wrote:
> > This may not matter... but it's worth pointing out that
> > expecting_media_change doesn't get cleared if ++scmd->retries >
> > scmd->allowed.
>
> absolutely worth pointing out and I'm
On 10.08.20 16:13, Alan Stern wrote:
> On Mon, Aug 10, 2020 at 02:03:17PM +0200, Martin Kepplinger wrote:
>> On 09.08.20 17:26, Alan Stern wrote:
>>> This is a somewhat fragile approach. You don't know for certain that
>>> scsi_noretry_cmd will be called. Also, scsi_noretry_cmd can be called
On Mon, Aug 10, 2020 at 02:03:17PM +0200, Martin Kepplinger wrote:
> On 09.08.20 17:26, Alan Stern wrote:
> > This is a somewhat fragile approach. You don't know for certain that
> > scsi_noretry_cmd will be called. Also, scsi_noretry_cmd can be called
> > from other places.
> >
> > It would
On 09.08.20 17:26, Alan Stern wrote:
> On Sun, Aug 09, 2020 at 11:20:22AM +0200, Martin Kepplinger wrote:
>> Hey Alan, I'm really glad for that, I suspected some of this but I have
>> little experience in scsi/block layers, so that is super helpful.
>>
>> I'd appreciate an opinion on the below
On Sun, Aug 09, 2020 at 11:20:22AM +0200, Martin Kepplinger wrote:
> Hey Alan, I'm really glad for that, I suspected some of this but I have
> little experience in scsi/block layers, so that is super helpful.
>
> I'd appreciate an opinion on the below workaround that *seems* to work
> now (let's
On 08.08.20 17:05, Alan Stern wrote:
> On Sat, Aug 08, 2020 at 08:59:09AM +0200, Martin Kepplinger wrote:
>> On 07.08.20 16:30, Alan Stern wrote:
>>> On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote:
it's really strange: below is the change I'm trying. Of course that's
On Sat, Aug 08, 2020 at 08:59:09AM +0200, Martin Kepplinger wrote:
> On 07.08.20 16:30, Alan Stern wrote:
> > On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote:
> >> it's really strange: below is the change I'm trying. Of course that's
> >> only for testing the functionality,
On 07.08.20 16:30, Alan Stern wrote:
> On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote:
>> it's really strange: below is the change I'm trying. Of course that's
>> only for testing the functionality, nothing how a patch could look like.
>>
>> While I remember it had worked, now
On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote:
> it's really strange: below is the change I'm trying. Of course that's
> only for testing the functionality, nothing how a patch could look like.
>
> While I remember it had worked, now (weirdly since I tried that mounting
> via
On 04.08.20 11:39, Martin Kepplinger wrote:
> On 30.07.20 17:10, Alan Stern wrote:
>> On Thu, Jul 30, 2020 at 10:52:14AM +0200, Martin Kepplinger wrote:
>>> Maybe I should just start a new discussion with a patch, but the below
>>> is what makes sense to me (when I understand you correctly) and
On 30.07.20 17:10, Alan Stern wrote:
> On Thu, Jul 30, 2020 at 10:52:14AM +0200, Martin Kepplinger wrote:
>> Maybe I should just start a new discussion with a patch, but the below
>> is what makes sense to me (when I understand you correctly) and seems to
>> work. I basically add a new flag, so
On Thu, Jul 30, 2020 at 10:05:50AM +0200, Martin Kepplinger wrote:
> On 29.06.20 18:15, Alan Stern wrote:
> > On Mon, Jun 29, 2020 at 11:42:59AM +0200, Martin Kepplinger wrote:
> >>
> >>
> >> On 26.06.20 17:44, Alan Stern wrote:
> >>> Martin's best approach would be to add some debugging code to
On Thu, Jul 30, 2020 at 10:52:14AM +0200, Martin Kepplinger wrote:
> Maybe I should just start a new discussion with a patch, but the below
> is what makes sense to me (when I understand you correctly) and seems to
> work. I basically add a new flag, so that the old flags behave unchanged
> and
On 30.07.20 10:52, Martin Kepplinger wrote:
> On 29.07.20 20:29, James Bottomley wrote:
>> On Wed, 2020-07-29 at 14:25 -0400, Alan Stern wrote:
>>> On Wed, Jul 29, 2020 at 06:43:48PM +0200, Martin Kepplinger wrote:
>> [...]
>> --- a/drivers/scsi/scsi_error.c
>> +++
On 29.07.20 20:29, James Bottomley wrote:
> On Wed, 2020-07-29 at 14:25 -0400, Alan Stern wrote:
>> On Wed, Jul 29, 2020 at 06:43:48PM +0200, Martin Kepplinger wrote:
> [...]
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -554,16 +554,8 @@ int
On 29.06.20 18:15, Alan Stern wrote:
> On Mon, Jun 29, 2020 at 11:42:59AM +0200, Martin Kepplinger wrote:
>>
>>
>> On 26.06.20 17:44, Alan Stern wrote:
>>> Martin's best approach would be to add some debugging code to find out why
>>> blk_queue_enter() isn't calling bkl_pm_request_resume(), or
On Wed, 2020-07-29 at 14:25 -0400, Alan Stern wrote:
> On Wed, Jul 29, 2020 at 06:43:48PM +0200, Martin Kepplinger wrote:
[...]
> > > > --- a/drivers/scsi/scsi_error.c
> > > > +++ b/drivers/scsi/scsi_error.c
> > > > @@ -554,16 +554,8 @@ int scsi_check_sense(struct scsi_cmnd
> > > > *scmd)
> > > >
On Wed, Jul 29, 2020 at 06:43:48PM +0200, Martin Kepplinger wrote:
>
>
> Am 29. Juli 2020 17:44:42 MESZ schrieb James Bottomley
> :
> >On Wed, 2020-07-29 at 17:40 +0200, Martin Kepplinger wrote:
> >> On 29.07.20 16:53, James Bottomley wrote:
> >> > On Wed, 2020-07-29 at 07:46 -0700, James
On 2020-07-29 10:32 a.m., Alan Stern wrote:
On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
On 28.07.20 22:02, Alan Stern wrote:
On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger wrote:
Hi Alan,
Any API cleanup is of course welcome. I just wanted to remind you
Am 29. Juli 2020 17:44:42 MESZ schrieb James Bottomley
:
>On Wed, 2020-07-29 at 17:40 +0200, Martin Kepplinger wrote:
>> On 29.07.20 16:53, James Bottomley wrote:
>> > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
>> > > On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
>[...]
On Wed, Jul 29, 2020 at 08:49:34AM -0700, James Bottomley wrote:
> On Wed, 2020-07-29 at 11:40 -0400, Alan Stern wrote:
> > On Wed, Jul 29, 2020 at 07:53:52AM -0700, James Bottomley wrote:
> > > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> [...]
> > > > That sense code means "NOT
On 29.07.20 17:40, Alan Stern wrote:
> On Wed, Jul 29, 2020 at 07:53:52AM -0700, James Bottomley wrote:
>> On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
>>> On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
On Wed, 2020-07-29 at 11:40 -0400, Alan Stern wrote:
> On Wed, Jul 29, 2020 at 07:53:52AM -0700, James Bottomley wrote:
> > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
[...]
> > > That sense code means "NOT READY TO READY CHANGE, MEDIUM MAY HAVE
> > > CHANGED" so it sounds like it
On Wed, 2020-07-29 at 17:40 +0200, Martin Kepplinger wrote:
> On 29.07.20 16:53, James Bottomley wrote:
> > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> > > On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
[...]
> > > > This error report comes from the SCSI layer, not the block
On 29.07.20 16:53, James Bottomley wrote:
> On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
>> On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
>>> On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
On 28.07.20 22:02, Alan Stern wrote:
> On Tue, Jul 28, 2020
On Wed, Jul 29, 2020 at 07:53:52AM -0700, James Bottomley wrote:
> On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> > On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
> > > On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
> > > > On 28.07.20 22:02, Alan Stern
On Wed, Jul 29, 2020 at 10:44:26AM -0400, Martin K. Petersen wrote:
>
> Alan,
>
> >> [ 77.474632] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result:
> >> hostbyte=0x00 driverbyte=0x08 cmd_age=0s
> >> [ 77.474647] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current]
> >> [ 77.474655] sd 0:0:0:0:
On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
> > On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
> > > On 28.07.20 22:02, Alan Stern wrote:
> > > > On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger
> >
On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
> On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
> > On 28.07.20 22:02, Alan Stern wrote:
> > > On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger
> > > wrote:
> > > > Hi Alan,
> > > >
> > > > Any API cleanup is of
Alan,
>> [ 77.474632] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result:
>> hostbyte=0x00 driverbyte=0x08 cmd_age=0s
>> [ 77.474647] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current]
>> [ 77.474655] sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0
>> [ 77.474667] sd 0:0:0:0: [sda] tag#0 CDB:
On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
> On 28.07.20 22:02, Alan Stern wrote:
> > On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger wrote:
> >> Hi Alan,
> >>
> >> Any API cleanup is of course welcome. I just wanted to remind you that
> >> the underlying
On 28.07.20 22:02, Alan Stern wrote:
> On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger wrote:
>> Hi Alan,
>>
>> Any API cleanup is of course welcome. I just wanted to remind you that
>> the underlying problem: broken block device runtime pm. Your initial
>> proposed fix "almost" did it
On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger wrote:
> Hi Alan,
>
> Any API cleanup is of course welcome. I just wanted to remind you that
> the underlying problem: broken block device runtime pm. Your initial
> proposed fix "almost" did it and mounting works but during file access,
On 06.07.20 18:41, Alan Stern wrote:
> On Tue, Jun 30, 2020 at 20:49:58PM -0400, Alan Stern wrote:
>> On Tue, Jun 30, 2020 at 04:31:58PM -0700, Bart Van Assche wrote:
>>> On 2020-06-30 12:38, Alan Stern wrote:
Assume that BLK_MQ_REQ_PREEMPT is set in flags. Then where exactly
does
On Tue, Jun 30, 2020 at 20:49:58PM -0400, Alan Stern wrote:
> On Tue, Jun 30, 2020 at 04:31:58PM -0700, Bart Van Assche wrote:
> > On 2020-06-30 12:38, Alan Stern wrote:
> > > Assume that BLK_MQ_REQ_PREEMPT is set in flags. Then where exactly
> > > does blk_queue_enter(q, flags) call
On Tue, Jun 30, 2020 at 04:31:58PM -0700, Bart Van Assche wrote:
> On 2020-06-30 12:38, Alan Stern wrote:
> > Assume that BLK_MQ_REQ_PREEMPT is set in flags. Then where exactly
> > does blk_queue_enter(q, flags) call blk_pm_request_resume(q)?
>
> Please take a look at how the *current*
On 2020-06-30 12:38, Alan Stern wrote:
> Assume that BLK_MQ_REQ_PREEMPT is set in flags. Then where exactly
> does blk_queue_enter(q, flags) call blk_pm_request_resume(q)?
Please take a look at how the *current* implementation of runtime power
management works. Your question is relevant for the
On Tue, Jun 30, 2020 at 12:23:12PM -0700, Bart Van Assche wrote:
> On 2020-06-30 11:02, Alan Stern wrote:
> > Right now there doesn't seem to be any mechanism for resuming the queue
> > if an REQ_PREEMPT request is added while the queue is suspended.
>
> I do not agree with the above statement.
On 2020-06-30 11:02, Alan Stern wrote:
> Right now there doesn't seem to be any mechanism for resuming the queue
> if an REQ_PREEMPT request is added while the queue is suspended.
I do not agree with the above statement. My understanding is that resuming
happens as follows if a request is
On Tue, Jun 30, 2020 at 08:59:00AM -0700, Bart Van Assche wrote:
> On 2020-06-29 09:15, Alan Stern wrote:
> > Aha. Looking at this more closely, it's apparent that the code in
> > blk-core.c contains a logic bug: It assumes that if the BLK_MQ_REQ_PREEMPT
> > flag is set then the request can be
On 2020-06-29 09:15, Alan Stern wrote:
> Aha. Looking at this more closely, it's apparent that the code in
> blk-core.c contains a logic bug: It assumes that if the BLK_MQ_REQ_PREEMPT
> flag is set then the request can be issued regardless of the queue's
> runtime status. That is not correct
On Tue, Jun 30, 2020 at 05:33:25AM +0200, Martin Kepplinger wrote:
> > Martin, does this fix the problem?
> >
>
> not quite: mounting works and resuming itself indeed happens now when
> copying a file, but the I/O itself doesn't, but says "device offline or
> changed":
>
> [ 167.167615] sd
On 29.06.20 18:15, Alan Stern wrote:
> On Mon, Jun 29, 2020 at 11:42:59AM +0200, Martin Kepplinger wrote:
>>
>>
>> On 26.06.20 17:44, Alan Stern wrote:
>>> Martin's best approach would be to add some debugging code to find out why
>>> blk_queue_enter() isn't calling bkl_pm_request_resume(), or
On Mon, Jun 29, 2020 at 09:56:49AM -0700, Bart Van Assche wrote:
> On 2020-06-29 09:15, Alan Stern wrote:
> > Aha. Looking at this more closely, it's apparent that the code in
> > blk-core.c contains a logic bug: It assumes that if the BLK_MQ_REQ_PREEMPT
> > flag is set then the request can be
On 2020-06-29 09:15, Alan Stern wrote:
> Aha. Looking at this more closely, it's apparent that the code in
> blk-core.c contains a logic bug: It assumes that if the BLK_MQ_REQ_PREEMPT
> flag is set then the request can be issued regardless of the queue's
> runtime status. That is not correct
On 26.06.20 17:44, Alan Stern wrote:
> On Fri, Jun 26, 2020 at 08:07:51AM -0700, Bart Van Assche wrote:
>> On 2020-06-25 01:16, Martin Kepplinger wrote:
>>> here's roughly what happens when enabling runtime PM in sysfs (again,
>>> because sd_probe() calls autopm_put() and thus allows it:
>>>
On Mon, Jun 29, 2020 at 11:42:59AM +0200, Martin Kepplinger wrote:
>
>
> On 26.06.20 17:44, Alan Stern wrote:
> > Martin's best approach would be to add some debugging code to find out why
> > blk_queue_enter() isn't calling bkl_pm_request_resume(), or why that call
> > doesn't lead to
On Sat, Jun 27, 2020 at 07:37:54PM -0700, Bart Van Assche wrote:
> On 2020-06-26 08:44, Alan Stern wrote:
> > On Fri, Jun 26, 2020 at 08:07:51AM -0700, Bart Van Assche wrote:
> >> As far as I know runtime power management support in the sd driver is
> >> working
> >> fine and is being used
On 2020-06-26 08:44, Alan Stern wrote:
> On Fri, Jun 26, 2020 at 08:07:51AM -0700, Bart Van Assche wrote:
>> As far as I know runtime power management support in the sd driver is working
>> fine and is being used intensively by the UFS driver. The following commit
>> was
>> submitted to fix a bug
On Fri, Jun 26, 2020 at 08:07:51AM -0700, Bart Van Assche wrote:
> On 2020-06-25 01:16, Martin Kepplinger wrote:
> > here's roughly what happens when enabling runtime PM in sysfs (again,
> > because sd_probe() calls autopm_put() and thus allows it:
> >
> > [ 27.384446] sd 0:0:0:0:
On 2020-06-25 01:16, Martin Kepplinger wrote:
> here's roughly what happens when enabling runtime PM in sysfs (again,
> because sd_probe() calls autopm_put() and thus allows it:
>
> [ 27.384446] sd 0:0:0:0: scsi_runtime_suspend
> [ 27.432282] blk_pre_runtime_suspend
> [ 27.435783]
On 2020-06-25 01:16, Martin Kepplinger wrote:
> Also, why isn't "autopm" used in its ioctl() implementation
> (as opposed to in "sr")?
Some of the scsi_autopm_{get,put}_device() calls in the sr driver
have been introduced by me before I fully understood runtime pm.
I will have a another look to
On Thu, Jun 25, 2020 at 10:16:06AM +0200, Martin Kepplinger wrote:
> On 24.06.20 15:33, Bart Van Assche wrote:
> > On 2020-06-23 04:10, Martin Kepplinger wrote:
> >> This add a very conservative but simple implementation for runtime PM
> >> to the sd scsi driver:
> >> Resume when opened (mounted)
On 24.06.20 15:33, Bart Van Assche wrote:
> On 2020-06-23 04:10, Martin Kepplinger wrote:
>> This add a very conservative but simple implementation for runtime PM
>> to the sd scsi driver:
>> Resume when opened (mounted) and suspend when released (unmounted).
>>
>> Improvements that allow
On 2020-06-23 04:10, Martin Kepplinger wrote:
> This add a very conservative but simple implementation for runtime PM
> to the sd scsi driver:
> Resume when opened (mounted) and suspend when released (unmounted).
>
> Improvements that allow suspending while a device is "open" can
> be added
This add a very conservative but simple implementation for runtime PM
to the sd scsi driver:
Resume when opened (mounted) and suspend when released (unmounted).
Improvements that allow suspending while a device is "open" can
be added later, but now we save power when no filesystem is mounted
and
56 matches
Mail list logo
