Re: [PATCH] Avoid that a kernel warning appears during system resume

Hi Bart. Bart Van Assche - 16.03.19, 22:28: > On 3/16/19 3:43 AM, Martin Steigerwald wrote: > > Bart Van Assche - 16.03.19, 00:27: > >> Since scsi_device_quiesce() skips SCSI devices that have another > >> state than RUNNING, OFFLINE or TRANSPORT_OFFLINE, > >

Re: [PATCH] Avoid that a kernel warning appears during system resume

0 > ? ret_from_fork+0x1f/0x30 > > Cc: Christoph Hellwig > Cc: Hannes Reinecke > Cc: Ming Lei > Cc: Johannes Thumshirn > Cc: Oleksandr Natalenko > Cc: Martin Steigerwald > Cc: > Reported-by: Jisheng Zhang > Tested-by: Jisheng Zhang > Fixes: 3a0a529971ec

Re: [PATCH] Change synchronize_rcu() in scsi_device_quiesce() into synchronize_sched()

Hi Bart. Bart Van Assche - 16.03.18, 22:51: > On 03/16/18 14:42, Martin Steigerwald wrote: > > What is this one about? > > > > Fix for the regression I (and others?) reported?¹ > > > > [1] [Bug 199077] [Possible REGRESSION, 4.16-rc4] Error updating SMART

Re: [PATCH] Change synchronize_rcu() in scsi_device_quiesce() into synchronize_sched()

gned-off-by: Bart Van Assche > Cc: Hannes Reinecke > Cc: Ming Lei > Cc: Christoph Hellwig > Cc: Johannes Thumshirn > Cc: Tejun Heo > Cc: Oleksandr Natalenko > Cc: Martin Steigerwald > Cc: sta...@vger.kernel.org # v4.15 > --- > drivers/scsi/scsi_lib.c | 2 +- >

Re: [LSF/MM TOPIC] Two blk-mq related topics

Ming Lei - 30.01.18, 02:24: > > > SCSI_MQ is enabled on V3.17 firstly, but disabled at default. In > > > V4.13-rc1, it is enabled at default, but later the patch is reverted > > > in V4.13-rc7, and becomes disabled at default too. > > > > > > Now both the original reported PM issue(actually SCSI q

Re: [PATCH v7 9/9] block, scsi: Make SCSI quiesce and resume work reliably

Bart Van Assche - 10.10.17, 15:27: > On Tue, 2017-10-10 at 09:57 +0200, Martin Steigerwald wrote: > > > Bart Van Assche - 09.10.17, 16:14: > > > > > The contexts from which a SCSI device can be quiesced or resumed are: > > > [ ... ] > > > >

Re: [PATCH v7 9/9] block, scsi: Make SCSI quiesce and resume work reliably

Bart Van Assche - 09.10.17, 16:14: > The contexts from which a SCSI device can be quiesced or resumed are: > * Writing into /sys/class/scsi_device/*/device/state. > * SCSI parallel (SPI) domain validation. > * The SCSI device power management methods. See also scsi_bus_pm_ops. > > It is essential

Re: [PATCH V7 0/6] block/scsi: safe SCSI quiescing

Hi Ming. Ming Lei - 30.09.17, 14:12: > Please consider this patchset for V4.15, and it fixes one > kind of long-term I/O hang issue in either block legacy path > or blk-mq. > > The current SCSI quiesce isn't safe and easy to trigger I/O deadlock. Isn´t that material for -stable as well? I´d love

Re: [PATCH V6 0/6] block/scsi: safe SCSI quiescing

Ming Lei - 27.09.17, 16:27: > On Wed, Sep 27, 2017 at 09:57:37AM +0200, Martin Steigerwald wrote: > > Hi Ming. > > > > Ming Lei - 27.09.17, 13:48: > > > Hi, > > > > > > The current SCSI quiesce isn't safe and easy to trigger I/O deadlock. >

Re: [PATCH V6 0/6] block/scsi: safe SCSI quiescing

#x27;s idea of preempt only, with clean > implementation(patch 5/patch 6) > - needn't any external driver's dependency, such as MD's > change Do you want me to test with v6 of the patch set? If so, it would be nice if you´d make a v6 branch in your git repo.

Re: Race to power off harming SATA SSDs

Am Dienstag, 11. April 2017, 11:31:29 CEST schrieb Henrique de Moraes Holschuh: > On Tue, 11 Apr 2017, Martin Steigerwald wrote: > > I do have a Crucial M500 and I do have an increase of that counter: > > > > martin@merkaba:~[…]/Crucial-M500> grep "^174" smartct

Re: Race to power off harming SATA SSDs

Am Dienstag, 11. April 2017, 08:52:06 CEST schrieb Tejun Heo: > > Evidently, how often the SSD will lose the race depends on a platform > > and SSD combination, and also on how often the system is powered off. > > A sluggish firmware that takes its time to cut power can save the day... > > > > >