On Fri, 27 Sep 2019, Damien Le Moal wrote:
> On 2019/09/26 16:57, Alan Stern wrote:
> > On Fri, 27 Sep 2019, Damien Le Moal wrote:
> >
> >> If a non-passthrough command is terminated with a CHECK CONDITION, the
> >> scsi error recovery code reuses the failed co
On Thu, 26 Sep 2019, Douglas Gilbert wrote:
> On 2019-09-26 7:57 p.m., Alan Stern wrote:
> > PS: The correct term is "residue", not "residual". I know that the
> > code sometimes uses the wrong word.
>
> Digging into my T10 document archive I fou
mand resid to 0
> when there is no residual in usb_stor_Bulk_transport(). Note that
> usb_stor_CB_transport() does not need changes since usb_stor_bulk_srb()
> always sets the resid for a completed command, regardless of the
> residual value.
Exactly the same reasoning shows that usb_sto
On Fri, 20 Sep 2019, Andrea Vai wrote:
> Il giorno gio, 19/09/2019 alle 14.14 +, Damien Le Moal ha scritto:
> > On 2019/09/19 16:01, Alan Stern wrote:
> > [...]
> > > No doubt Andrea will be happy to test your fix when it's ready.
>
> Yes, of course.
>
t be expected to work as well as
an actual disk drive connected over USB.
Alan Stern
eed to do a lot of testing as all block devices are potentially impacted by
> the
> change, including stacked drivers (DM). Performance regression is scary with
> any
> change in that area (see blk_mq_make_request() and use of
> blk_mq_try_issue_directly() vs blk_mq_sched_insert_request()).
No doubt Andrea will be happy to test your fix when it's ready.
Alan Stern
uch worse job of handling non-sequential writes than
sequential ones.
Which leads to a simple question for the SCSI or block-layer
maintainers: Is there a sysfs setting Andrea can tweak which will
effectively restrict a particular disk device down to a single I/O
queue, forcing sequential access?
Alan Stern
On Sun, 7 Jul 2019, Andrea Vai wrote:
> On 03/07/19 10:23:13, Alan Stern wrote:
> >
> > [...]
> > Andrea, another thing you could try is to collect a usbmon trace under
> > one of the "slow" kernels. Follow the instructions in
> > Documentation/usb/u
trace under
one of the "slow" kernels. Follow the instructions in
Documentation/usb/usbmon.txt. I think you could kill the file-copy
operation after just a couple of seconds; that should provide enough
trace information to help see what causes the slowdown.
(If you want, do the same test with a "fast" kernel and then we'll
compare the results.)
Alan Stern
On Mon, 15 Apr 2019, Alan Stern wrote:
> On Mon, 15 Apr 2019 kento.a.kobaya...@sony.com wrote:
>
> > Hi
> >
> > >The unbind happens from inside the SCSI EH callback. If that really is
> > >not allowed, we'll need to change it. Or we can just cha
h the side effects are larger than with your patch, they are
not any worse. Furthermore, they handle correctly some situations that
your patch does not handle.
> So I want to know why the unbind is occurred from eh callback should not be
> allowed.
Ask the SCSI developers.
Alan Stern
On Tue, 9 Apr 2019, Bart Van Assche wrote:
> On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:
> +AD4 On Mon, 8 Apr 2019, Martin K. Petersen wrote:
> +AD4
> +AD4 +AD4
> +AD4 +AD4 Alan,
> +AD4 +AD4
> +AD4 +AD4 +AD4 So it looks as though the SCSI subsystem doesn'
ve_host until after the error
handling is finished?
What about races? In theory, scsi_remove_host could be called just as
the error handler is starting up.
Alan Stern
this is a bug in uas driver.
Actually I was asking James and Martin, not you.
In any case, even assuming the cause of the problem is on the USB side,
it's not clear whether the bug is in uas or in usbcore.
Alan Stern
tem doesn't like to have a reset
handler call scsi_remove_host. Commands dispatched by the removal
routines are forced to wait for the reset recovery to finish, which
won't happen until those commands have been completed.
Is this a bug in the SCSI core? If not, we need to know what is the
right way to do things when a reset handler detects that the SCSI host
has been hot-unplugged.
James, Martin, any suggestions?
Alan Stern
se. And in those cases
> we cannot depend on upper layers doing the right thing, if
> we just ignore an error.
>
> NACK
>
> Sorry
> Oliver
Note that the reset routines in usb-storage do not make any exceptions
for -ENODEV.
Alan Stern
On Thu, 29 Nov 2018, Zengtao (B) wrote:
> Ping?
>
> >-Original Message-----
> >From: Alan Stern [mailto:st...@rowland.harvard.edu]
> >Sent: Wednesday, November 14, 2018 11:35 PM
> >To: Martin Petersen ; Zengtao (B)
> >
> >Cc: j...@linux.vnet.ibm.com;
t; >post the dmesg log, not the SCSI log.
>
> Please refer to the new attachment for dmesg log.
Heh, yes, I see now.
Martin, shouldn't sd_release() call sd_sync_cache() in the same way
that sd_shutdown() does, before it calls scsi_set_medium_removal()?
Alan Stern
s first plugged in?
> >
>
> I have enabled the SCSI log for the host, please refer to the attachment.
The log you attached was incomplete -- it was missing some commands
from the beginning. In any case, it wasn't what I wanted. I asked
you to post the dmesg log, not the SCSI log.
Alan Stern
On Wed, 31 Oct 2018, Zengtao (B) wrote:
> Hi:
>
> >-Original Message-----
> >From: Alan Stern [mailto:st...@rowland.harvard.edu]
> >Sent: Tuesday, October 30, 2018 10:08 PM
> >To: Zengtao (B)
> >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com;
ow a long timeout for
this command. Then when PREVENT-ALLOW MEDIUM REMOVAL is sent, nothing
will need to be flushed.
Alan Stern
> I found there are two methods to workaround the issue:
> 1. Change the timeout value of host scsi command PREVENT_ALLOW_MEDIUM_REMOVAL
> to
> to about 60
On Wed, 2 May 2018, Christoph Hellwig wrote:
> On Fri, Apr 27, 2018 at 10:09:17AM -0400, Alan Stern wrote:
> > On Fri, 27 Apr 2018, Christoph Hellwig wrote:
> >
> > > On Sun, Apr 15, 2018 at 11:24:11AM -0400, Alan Stern wrote:
> > > > On Sun,
On Fri, 27 Apr 2018, Christoph Hellwig wrote:
> On Sun, Apr 15, 2018 at 11:24:11AM -0400, Alan Stern wrote:
> > On Sun, 15 Apr 2018, Christoph Hellwig wrote:
> >
> > > USB host controllers now must handle highmem, so we can get rid of bounce
> > > buffering
that and lack any ability to have separate timeouts.
As far as mass-storage is concerned, USB is merely a transport. It
doesn't impose any timeout rules; the appropriate timeout value is
whatever the device at the end of the USB link needs. Thus, a SCSI
drive connected over USB could use
_do_ handle highmem? Or do you
mean that if they _don't_ handle highmem, we will not support them any
more?
Alan Stern
> Signed-off-by: Christoph Hellwig
> ---
> drivers/usb/storage/scsiglue.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/usb/storag
27;d like to help track this problem down, do you have any suggestions or
> is there some additional details I could provide?
You can try bisecting between the 4.9 and 4.13 kernels to find the
commit which first caused the problem.
Alan Stern
bviously possible to differentiate between cable/hub/endpoint errors.
I don't see how FEC could help in a situation where a device sends a
properly formatted message and then some component closer to the kernel
improperly rejects it.
Alan Stern
o the viewpoint of the xhci-hcd
driver.
In theory it's possible that the drive did respond correctly and the
information get messed up on the USB cable or on the computer's end.
Since we can't see what signals were actually sent on the USB bus,
there's no way to be certain. But
looks like there is no configurable timeout for USB MSC requests.
> > Perhaps the device is not responding in time and this is why it's
> > reset?
Timeouts are set by the SCSI layer. I believe they are rather long (30
seconds, by default). Presumably they are configurable, although I
would have to do some digging to figure out how.
Alan Stern
Then we can remove a whole lot of quirks and we avoid future
> churn when new Seagate device ids show up.
That is a reasonable approach. For what it's worth, usb-storage has
had similar code for many years, affecting devices from Nokia, Nikon,
Pentax, and Motorola.
Alan Stern
On Fri, 22 Sep 2017, Greg Kroah-Hartman wrote:
> On Fri, Sep 22, 2017 at 09:58:15AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Sep 21, 2017 at 03:04:05PM -0400, Alan Stern wrote:
> > > On Thu, 21 Sep 2017, Andrey Konovalov wrote:
> > >
> > > > On T
utine
uses this value as an index to the altsetting array -- which it isn't.
Normally this doesn't cause any problems because the the entries in the
array have bAlternateSetting values 0, 1, etc., so the value is equal
to the index. But in your fuzzed case, that wasn't true.
The pat
t; don't see the driver doing anything wrong. I might be missing
> something, or this might be an issue in USB core altsettings parsing.
My guess is the latter, although I can't see what is going wrong. Can
you provide the code that does this?
Alan Stern
evinfo model string will
> not match
>
> Fixes: 5e7ff2c ("SCSI: fix new bug in scsi_dev_info_list string matching")
> Signed-off-by: Hannes Reinecke
> ---
Aside from the patch description,
Reviewed-by: Alan Stern
> drivers/scsi/scsi_devinfo.c | 29 +
> + * must be larger or equal to devinfo->model
> + */
> + if (!memcmp(devinfo->model, mskip,
> + strlen(devinfo->model)))
> + return devinfo;
It wou
On Tue, 8 Aug 2017, Hannes Reinecke wrote:
> On 08/08/2017 05:25 PM, Alan Stern wrote:
> > On Tue, 8 Aug 2017, Hannes Reinecke wrote:
> >
> >> When checking the model and vendor string we need to use the
> >> minimum value of either string, otherwise we
entry is shorter (this would be a
wildcard match), but not if the list entry is longer. Here
the device string length is after leading and trailing blanks
have been removed.
As a corollary, allow an empty device string to match an empty
list entry but nothing else.
Alan Stern
On Wed, 26 Jul 2017, Christoph Hellwig wrote:
> On Thu, Jul 13, 2017 at 01:00:29PM -0400, Alan Stern wrote:
> > All right. In the meantime, changing usb-storage won't hurt.
> > Arthur, can you test the patch below?
>
> Do you plan to send this fix to Greg for 4.1
On Wed, 26 Jul 2017, Михаил Гаврилов wrote:
> On 25 July 2017 at 02:12, Alan Stern wrote:
> > This is enough for now. The problem is that a USB transfer is started
> > but never stopped, which indicates a problem with the host controller.
> >
> > In this cas
commit caused the problem to occur.
Alan Stern
t4.1 then next
> reboot. After pressing reset button and follow reboot problem not
> reproduced. But sometime kernel may hangs silently.
>
> If I'm wrong with the mailing list, tell me please appropriate mailing list.
These are the right mailing lists.
We need more information to tell what is going wrong. Can you post the
full dmesg log?
Alan Stern
On Wed, 12 Jul 2017, Christoph Hellwig wrote:
> On Wed, Jul 12, 2017 at 12:10:02PM -0400, Alan Stern wrote:
> > This is pretty conclusive. The problem comes about because
> > usb_stor_control_thread() calls scsi_mq_done() while holding
> > shost->host_lock, and then scs
The problem comes about because
usb_stor_control_thread() calls scsi_mq_done() while holding
shost->host_lock, and then scsi_eh_scmd_add() tries to acquire that
same lock.
I don't know why this didn't show up in earlier kernels. I guess some
element of the call chain listed above must be new in 4.12.
Christoph, what's the best way to fix this? Should usb-storage release
the host lock before issuing the ->scsi_done callback? If so, does
that change need to be applied to any kernels before 4.12?
Alan Stern
On Thu, 18 May 2017, Ewan D. Milne wrote:
> On Thu, 2017-05-18 at 13:37 -0400, Alan Stern wrote:
> >
> > I had completely forgotten about this code. :-(
> >
> > Looks like you put your finger on the source of the problem. So if the
> > device sends back esse
On Thu, 18 May 2017, Ewan D. Milne wrote:
> On Thu, 2017-05-18 at 11:34 -0400, Ewan D. Milne wrote:
> > On Thu, 2017-05-18 at 10:35 -0400, Alan Stern wrote:
> > > This is in reference to
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1351305
&
tput to the log. I don't know why the behavior is different.
There are other similar examples, with and without log messages.
Any help would be appreciated.
Alan Stern
On Sun, 29 Jan 2017, Pali Rohár wrote:
> On Wednesday 11 January 2017 16:23:29 Alan Stern wrote:
> > On Tue, 10 Jan 2017, James Bottomley wrote:
> > > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote:
> > > > In theory, I suppose we could change the kernel so th
On Tue, 10 Jan 2017, James Bottomley wrote:
> On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote:
> > In theory, I suppose we could change the kernel so that it would
> > default to READ CAPACITY(16) for devices that report a SCSI level >=
> > 3, or something along tho
On Wed, 11 Jan 2017, Pali Rohár wrote:
> On Tuesday 10 January 2017 15:29:23 Alan Stern wrote:
> > > Tom Yan wrote that smartctl/hdparm "works" because they use the SCSI ATA
> > > PASSTHROUGH command. It is not an option for kernel?
> >
> > No, bec
On Tue, 10 Jan 2017, Dainius Masiliūnas wrote:
> On Tue, Jan 10, 2017 at 9:00 PM, Alan Stern wrote:
> > It is used for preventing the kernel from issuing a READ CAPACITY(16)
> > command to the device. Normally the kernel would do this if the reply
> > to READ CAPACITY(10)
On Tue, 10 Jan 2017, Dainius Masiliūnas wrote:
> (I pressed reply instead of reply to all, sorry. Resending this.)
>
> On Tue, Jan 10, 2017 at 8:29 PM, Alan Stern wrote:
> > There _is_ a quirk for broken models. However, we don't know how
> > complete the set of quir
Since my disk seems to work fine in that regard.
There _is_ a quirk for broken models. However, we don't know how
complete the set of quirk entries is, so we err on the side of caution.
On Tue, 10 Jan 2017, Pali Rohár wrote:
> On Tuesday 10 January 2017 21:02:09 Alan Stern wrote:
&
dparm
> does.
Quick summary: READ CAPACITY(10) does not include physical sector size
information whereas READ CAPACITY(16) does. But the kernel uses READ
CAPACITY(10) by default for USB drives, because quite a few of them die
when given a READ CAPACITY(16) command.
If you can suggest a way to
On Tue, 27 Dec 2016, George Cherian wrote:
> Hi Alan,
>
>
> On Tuesday 27 December 2016 08:50 PM, Alan Stern wrote:
> > On Tue, 27 Dec 2016, Oliver Neukum wrote:
> >
> >> On Thu, 2016-12-22 at 17:44 -0500, Alan Stern wrote:
> >>> I don't see h
On Tue, 27 Dec 2016, Oliver Neukum wrote:
> On Thu, 2016-12-22 at 17:44 -0500, Alan Stern wrote:
> > I don't see how this patch fixes anything. Unless I'm mistaken, it
> > just avoids the problem by preventing the system from issuing the
> > command that provoke
spin_lock_irqsave(shost->host_lock, flags);
> scsi_report_bus_reset(shost, 0);
> spin_unlock_irqrestore(shost->host_lock, flags);
As far as I can tell, adding the "goto reset_scsi" line does not help
at all. There's no reason to report that the bus has been reset after
the device is gone.
Alan Stern
--
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
> unusable. Even an lsusb invocation hangs for ever.
This problem looks pretty simple. uas doesn't check properly to see if
the device was disconnected following a reset.
Try changing the line in uas_post_reset() that says:
if (devinfo->shutdown)
to:
if (de
rive is powered down.
>
> Signed-off-by: Oliver Neukum
> Reviewed-by: Martin K. Petersen
Acked-by: Alan Stern
> ---
> Documentation/kernel-parameters.txt | 2 ++
> drivers/usb/storage/scsiglue.c | 8
> drivers/usb/storage/unusual_devs.h | 7 +++
>
That causes the host to skip sending a command to
> Oliver> synchronize caches. That causes data loss when the drive is
> Oliver> powered down.
>
> Alan?
Oliver originally submitted this at least a month ago. I don't see any
changes since then, so:
Acked-by: Alan Stern
evice_add and after the call to device_add the parent device is
> suspended.
>
> Fix this by using the approach from the mentioned commit and getting
> the runtime pm reference before calling scsi_add_host.
Acked-by: Alan Stern
There's nothing wrong with this patch; it's a wo
#x27;:
> + f |= US_FL_ALWAYS_SYNC;
> + break;
> /* Ignore unrecognized flag characters */
> }
> }
You need to update Documentation/kernel-parameters.txt too.
Alan Stern
--
To unsubscribe from this list: send
list might not be
matched properly if it contained an 8-character vendor name or a
16-character model name. Such entries certainly exist in
scsi_static_device_list.
This patch fixes the problem by adding a check for a maximum-length
string before the '\0' test.
Signed-off-by: Alan Stern
Fix
off-by: Hans de Goede
> ---
> Changes in v2:
> -Document new j quirk in Documentation/kernel-parameters.txt
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo i
ase 'l':
> f |= US_FL_NOT_LOCKABLE;
> break;
You forgot to document this new module parameter flag in
Documentation/kernel-parameters.txt.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi"
port. Something
> in 4.4, most probably 4fd41a8552af ("SCSI: Fix NULL pointer
> dereference in runtime PM") is also needed.
Although that commit isn't in 4.3.x yet, it should be added soon.
Maybe in the next release.
Alan Stern
--
To unsubscribe from this list: send the lin
f ("SCSI: Fix NULL pointer
dereference in runtime PM"), which was added to the mainline kernel
between 4.3 and 4.4. I don't know what the commit ID would be for a
.stable kernel.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the b
On Wed, 3 Feb 2016, Oliver Neukum wrote:
> On Tue, 2016-01-26 at 10:28 -0500, Alan Stern wrote:
> > On Tue, 26 Jan 2016, Oliver Neukum wrote:
>
> > > That is problematic. The ABORT_TMF does need IO for which we need
> > > to wait. And if we just submit and pre
ntime suspend/resume.
This fixes <https://bugs.debian.org/801925>.
Signed-off-by: Alan Stern
Reported-by: Paul Menzel
Reported-by: Erich Schubert
Reported-by: Alexandre Rossi
Tested-by: Paul Menzel
CC: "James E.J. Bottomley"
CC: Ben Hutchings
CC:
---
[as1795]
dri
ow!
The patch I sent to you was merged in August. But then it caused other
problems, so it was reverted in December and a different fix was merged
instead (commit 4fd41a8552af). That new fix hasn't migrated into the
.stable kernels yet.
Alan Stern
--
To unsubscribe from this list: send the
On Tue, 15 Dec 2015, Oliver Neukum wrote:
> On Thu, 2015-12-03 at 13:36 -0500, Alan Stern wrote:
> > This is an old problem, but it was never resolved and it still affects
> > people (Bugzilla #89511). In short, there are USB-(S)ATA bridges that
> > claim to be write-back
n, 22 Jun 2015, James Bottomley wrote:
> On Mon, 2015-06-22 at 13:48 -0400, Alan Stern wrote:
> > On Mon, 22 Jun 2015, James Bottomley wrote:
> >
> > > On Mon, 2015-06-22 at 13:30 -0400, Alan Stern wrote:
> > > > On Mon, 22 Jun 2015, James Bottomley wrote:
&
OR: "__umoddi3" [drivers/scsi/sg.ko] undefined!
It's hard to see how this commit could be the cause of that error.
The commit doesn't touch any of the files involved in building the sg
module; in fact, all its changes are confined to a single function that
isn't part o
On Sat, 31 Oct 2015, Alan Stern wrote:
> I believe the problem shown in that photo was fixed by commit
> 49718f0fb8c9 ("SCSI: Fix NULL pointer dereference in runtime PM"),
> which was merged in 4.2 and has been back-ported to various stable
> releases.
On second thought
more, and using Linux
> 3.19 the drive is detected and the system boots.
>
> Does anything stand out what changed in this area between Linux 3.19 and
> 4.1?
I believe the problem shown in that photo was fixed by commit
49718f0fb8c9 ("SCSI: Fix NULL pointer dereference in runtime P
t the appropriate place in the
scsi_dev_type_resume() routine.
Signed-off-by: Alan Stern
Reported-by: Ken Xue
Tested-by: Ken Xue
CC:
---
[as1785]
block/blk-core.c | 19 +++
drivers/scsi/scsi_pm.c |4 +++-
include/linux/blkdev.h |2 ++
3 files changed, 24 insertions(
ion should explain why that
commit didn't work properly for the sr driver.
The second patch should make the new changes to the block core. The
description should explain why the changes are needed, and it can
reference Bugzilla #101371.
Both patches should be tagged for the -stable kernel
On Tue, 8 Sep 2015, Ken Xue wrote:
> On Mon, 2015-09-07 at 10:48 -0400, Alan Stern wrote:
> > On Mon, 7 Sep 2015, Xue, Ken wrote:
> >
> > > Hi Alan and James,
> > > I found a bug about sr device runtime suspend & resume which is
> > > intr
tch I wrote uses the existence of runtime-PM callbacks as an
indicator for this, but evidently it isn't adequate. A more direct
approach would be to test whether sdev->request_queue->dev is non-NULL,
but this would be a layering violation.
Should we add a SCSI-level flag to indicate that
On Mon, 17 Aug 2015, Alan Stern wrote:
> The routines in scsi_rpm.c assume that if a runtime-PM callback is
> invoked for a SCSI device, it can only mean that the device's driver
> has asked the block layer to handle the runtime power management (by
> calling blk_pm_runtime_in
nter.
This patch fixes the problem by calling the block layer's runtime-PM
routines only if the device's driver really does have a runtime-PM
callback routine. Since ses doesn't define any such callbacks, the
crash won't occur.
This fixes Bugzilla #101371.
Signed-off-by: Ala
th
leading blanks removed) or the device list entry's vendor string is a
substring of the other, and likewise for the product strings. For
example, a device string of "VENDOR12" would match against a list
entry's string of "VENDOR", which obviously is not what we want.
improvement.) Second and more importantly, the
patch removes trailing spaces and adds a check to verify that the two
resulting strings are exactly the same length. This prevents matches
where one entry is a proper substring of the other.
Signed-off-by: Alan Stern
Reported-by: Giulio Bernardi
, scsi_dev_info_list_find().
Signed-off-by: Alan Stern
Suggested-by: Giulio Bernardi
---
[as1782]
drivers/scsi/scsi_devinfo.c | 114
1 file changed, 42 insertions(+), 72 deletions(-)
Index: usb-4.1/drivers/scsi/scsi_devinfo.c
On Mon, 22 Jun 2015, James Bottomley wrote:
> On Mon, 2015-06-22 at 13:48 -0400, Alan Stern wrote:
> > On Mon, 22 Jun 2015, James Bottomley wrote:
> >
> > > On Mon, 2015-06-22 at 13:30 -0400, Alan Stern wrote:
> > > > On Mon, 22 Jun 2015, James Bottomley wrot
On Fri, 10 Jul 2015, yoma sophian wrote:
> hi Alan:
>
> 2015-05-27 22:40 GMT+08:00 Alan Stern :
> > On Wed, 27 May 2015, yoma sophian wrote:
> >
> >> After reading the kernel power document, freezing-of-tasks.txt , can I
> >> get the below conclusion:
&
pinions about whether the FS wants to be informed about flush failure.
>
> So, it is okay to wait for the end of that discussion before I start
> further testing or should I test the patch above?
Please test it now. I'd like to know if it fixes your problem,
regardless of how the di
On Mon, 22 Jun 2015, James Bottomley wrote:
> On Mon, 2015-06-22 at 13:30 -0400, Alan Stern wrote:
> > On Mon, 22 Jun 2015, James Bottomley wrote:
> >
> > > I'm not sure I entirely like this: we are back again treating data
> > > corruption problems
ed if any of those drives support MODE SELECT at
all.
Maybe your patch will be acceptable, though. We'll have to hear from
Markus and Matt.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
s addresses Bugzilla #89511.
Signed-off-by: Alan Stern
Reported-by: Jun Itou
Reported-by: Markus Rathgeb
Reported-by: Matt
Tested-by: Markus Rathgeb
Tested-by: Matt
Fixes: 89fb4cd1f717a871ef79fa7debbe840e3225cd54
CC: James Bottomley
CC:
---
As far as I'm concerned, this can be merge
On Mon, 22 Jun 2015, Joe Lawrence wrote:
> Hi Alan -- last I heard from Stan on this bug was April 14 -- he was on
> "long holidays" at that time :)
>
> -- Joe
Without knowing whether the patch really fixes the problem, I can't
tell whether it should be su
data correctly. Therefore the information in the
kernel will often be wrong.
And consequently, fdisk needs to offer the user an option to override
the default partition-alignment setting.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
Joe or Stanisﾅ^ﾂaw:
I never heard anything back about this. Does the patch fix the crash?
Alan Stern
On Wed, 18 Mar 2015, Alan Stern wrote:
> On Wed, 18 Mar 2015, Alan Stern wrote:
>
> > On Tue, 17 Mar 2015, Joe Lawrence wrote:
> >
> > > On 03/11/2015 12:25 A
e (e.g. if SYNCHRONIZE CACHE command is not working, fallback to write
> through)?
This is up to the SCSI developers.
The real question is what should happen when a drive really does have a
write cache but doesn't recognize the SYNCHRONIZE CACHE command. I
don't know what the kernel can d
erly). After
all, it really was an error in the data-flushing path.
You wrote that the error appears with several different brands and
types of USB drives. Almost certainly these drivers share a bug in the
component that bridges the USB bus to the internal SATA bus.
The real question is what to d
freezable threads?
Threads get frozen and woken up in kernel/power/process.c. The
routines are called from suspend_freeze_processes() and
suspend_thaw_processes() in kernel/power/suspend.c.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
th
river() except that it also
> initializes scsi host template.
>
> Signed-off-by: Akinobu Mita
This looks very good.
Acked-by: Alan Stern
--
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
so that no
SCSI commands will be sent while the system is in suspend or
hibernation, so no checking is needed.
> b. shall we add other flag in usb_stor_port_reset to make sure above
> race condition will not happen?
No. You should fix your thread (or get rid of it and use the existing
kernel thread
it supposed to be done that way? Isn't that less efficient? It
means you have to have a separate copy of the template for each bus
connector driver, instead of letting them all share a common template
in the core.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe l
tected flags, and use this in the uas driver.
>
> Cc: sta...@vger.kernel.org # 3.16
> Signed-off-by: Hans de Goede
For this whole series:
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.ke
ch devices, and implements
> support for it in uas.c, while at it it also adds support for
> US_FL_MAX_SECTORS_64 to uas.c.
>
> Signed-off-by: Hans de Goede
You forgot to update Documentation/kernel-parameters.txt.
Alan Stern
--
To unsubscribe from this list: send the line "unsubs
1 - 100 of 552 matches
Mail list logo
