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
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
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
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
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
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
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
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
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
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
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
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
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 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:
&
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
, 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
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
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.
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
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
> 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
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
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
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
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
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:
&
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
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 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, 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 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
.16.rc6
> the 'Invalid field in cdb' errors disappeared but still not ok.
Since your device uses the uas driver, you might get more help on the
linux-usb mailing list. (You don't have to subscribe to the list in
order to post to it.)
Alan Stern
--
To unsubscribe from this list: se
s?
Most likely it varies with the version of Windows and the INQUIRY data
returned by the device.
I can obtain hardware traces for the kinds of devices and computers
lying around here. But what sort of combinations should I test?
Alan Stern
--
To unsubscribe from this list: send the line &q
#x27;t that what you want it to do? Doesn't the flash drive
use those bits to hold the LUN number?
Alan Stern
> Il 06/ago/2014 22:02 "Alan Stern" ha scritto:
>
> > On Wed, 6 Aug 2014, Christoph Hellwig wrote:
> >
> > > On Wed, Aug 06, 2014 at 03:29:47PM
On Wed, 6 Aug 2014, Christoph Hellwig wrote:
> On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote:
> > > I doubt either of them forces users to hack up flags for these cases.
> >
> > Why was this change needed in the first place? There's no explana
On Tue, 19 Aug 2014, Christoph Hellwig wrote:
> On Thu, Aug 07, 2014 at 11:58:37AM -0400, Alan Stern wrote:
> > > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote:
> > > > > I doubt either of them forces users to hack up flags for these cases.
> > > &
I don't know if there are any multi-LUN USB devices that
don't use the Bulk-Only transport, but if there are then they won't
work if the LUN isn't stored in CDB[1].
Tiziano, does this do what you want?
Alan Stern
Index: usb-3.16/include/scsi/scsi_host.h
==
the default level in the
scsi_target, but forgets to copy it back into each newly allocated
scsi_device! I added a line to do that into the patch.
Alan Stern
Index: usb-3.16/include/scsi/scsi_host.h
===
--- usb-3.16.orig/include/
On Fri, 22 Aug 2014, Christoph Hellwig wrote:
> On Fri, Aug 22, 2014 at 10:53:42AM -0400, Alan Stern wrote:
> > Good idea. An enhanced patch is below. If I can get a Tested-By: from
> > Tiziano and one or two Acked-By: responses, I'll submit this for the
> >
On Fri, 22 Aug 2014, James Bottomley wrote:
> On Fri, 2014-08-22 at 10:53 -0400, Alan Stern wrote:
> > Sending the initial INQUIRY command to LUNs larger than 0 involves a
> > chicken-and-egg problem -- we don't know whether to fill in the LUN
> > bits in the command un
NITY_LIMIT)
> return (i - 1) * 2TB + lower_limit;
> else
> return ERROR;
Don't forget that lots of disks go crazy if you try to read from a
nonexistent block, that is, one beyond the end of the disk.
IMO, this bug cannot be worked around in any reas
On Sun, 24 Aug 2014, Christoph Hellwig wrote:
> On Fri, Aug 22, 2014 at 01:29:32PM -0400, Alan Stern wrote:
> > > Other than this, I'm fine with the code ... you can add the acked by
> > > from me when we resolve the above question.
> >
> > Okay. It'
On Mon, 25 Aug 2014, Alfredo Dal Ava Junior wrote:
> On Mon, 25 Aug 2014, Alan Stern wrote:
> >
> > Don't forget that lots of disks go crazy if you try to read from a
> > nonexistent
> > block, that is, one beyond the end of the disk.
> > IMO, this bug can
On Mon, 25 Aug 2014, James Bottomley wrote:
> On Mon, 2014-08-25 at 10:44 -0400, Alan Stern wrote:
>
> > James, can you explain how the INQUIRY command in scsi_probe_lun()
> > managed to work back in the days when multi-lun SCSI-2 devices were
> > common? sdev->scsi
t a very satisfactory solution. After all, if you have a SATA
connection available then why would you be using a USB enclosure in the
first place?
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
On Mon, 25 Aug 2014, Alan Stern wrote:
> On Mon, 25 Aug 2014, James Bottomley wrote:
>
> > On Mon, 2014-08-25 at 10:44 -0400, Alan Stern wrote:
> >
> > > James, can you explain how the INQUIRY command in scsi_probe_lun()
> > > managed to work back in th
On Mon, 25 Aug 2014, Oliver Neukum wrote:
> On Mon, 2014-08-25 at 16:21 -0400, Alan Stern wrote:
> > On Mon, 25 Aug 2014, Alfredo Dal Ava Junior wrote:
> >
> > > Well, it is causing problems anyway... from user perspective, it's a
> > > Linux compatibilit
> > is set to some random value.)
>
> Yes, but clipping has its own dangers. Suppose you use the medium
> without a partition table.
What would Windows do? In the absence of a partition table, it would
believe the value from READ CAPACITY, right? Isn't that the same as
clipp
nal behavior if the device isn't a cdrom
drive.
That's not a complete fix (it won't help when a CD drive is attached
via USB), but maybe it's better than nothing.
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
ng taken out and put back in.
Or maybe this functionality belongs in the block layer rather than in
sd.
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
with Windows show that it does essentially the same
things as Linux does. The important difference is not what commands
and data get sent, but whether the OS pays attention to the result.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the bod
ity? Unless
the drive had been hooked up to a different computer and the user
manually noted the correct capacity and typed it in, it would have to
be guesswork.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vg
On Sat, 30 Aug 2014, Douglas Gilbert wrote:
> On 14-08-30 05:15 PM, Alan Stern wrote:
> > On Fri, 29 Aug 2014, Matthew Dharm wrote:
> >
> >> Is there an 'easy' way to override the detected size of a storage
> >> device from userspace? If we had that, so
structure. The test for
whether to stick the LUN value in the CDB can be made when the device
is probed, and stored for future use rather than being made over and
over in the fast path.
Signed-off-by: Alan Stern
Reported-by: Tiziano Bacocco
Acked-by: Christoph Hellwig
Acked-by: Martin K. Peter
On Wed, 3 Sep 2014, Dale R. Worley wrote:
> > From: Alan Stern
> >
> > On Fri, 29 Aug 2014, Matthew Dharm wrote:
> > > Is there an 'easy' way to override the detected size of a storage
> > > device from userspace? If we had that, someone could wri
ce as a udev rule.
That's what I'm working on. Except that I don't know where to do it in
the block layer, so for now I'm adding the attribute to sd.c.
Where in the block layer would the right place be? We want this to
apply only to entire devices, not to individual partitions
On Wed, 3 Sep 2014, James Bottomley wrote:
> On Wed, 2014-09-03 at 16:30 -0400, Alan Stern wrote:
> > On Wed, 3 Sep 2014, James Bottomley wrote:
> >
> > > Before we embark on elaborate hacks, why don't we just make the capacity
> > > writeable (by root)
's going on here, but it looks like something doesn't
get cleaned up properly during the unbind operation.
This was in vanilla 3.17-rc3.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.ker
to reboot and try new
> kernels on, and the drive is brand new and completely empty so it's
> pretty much impossible to mess up!
Please post a usbmon trace showing what happens when the drive binds to
usb-storage. To prevent extraneous data from cluttering the trace, you
should unpl
t looks like the code should be:
if (!queue_flag_test_and_set(QUEUE_FLAG_INIT_DONE, q))
blk_queue_bypass_end(q);
Do you agree? If so, I'll send in patch.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of
draining can't be skipped even if bypass_depth was
> non-zero
>
> Your hack seems to indicate that this doesn't work on the add->del->add
> transtion of a gendisk.
Indeed, it does not work.
Tejun, for more details about the failure see the initial message in
th
On Tue, 9 Sep 2014, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 01:42:44PM -0400, Alan Stern wrote:
> > > This looks like a nasty hack. In theory the QUEUE_FLAG_INIT_DONE should
> > > be unset on blk_unregister_queue() to match the teardown; it
ORE_UAS;
> + }
> + }
> +
> + usb_stor_adjust_quirks(udev, &flags);
This won't work. usb_stor_adjust_quirks masks out all the quirks that
it handles before applying the user-specified quirks. Therefore it
will erase your US_FL_IGNORE_UAS flag.
You migh
This patch fixes the problem by making blk_register_queue() call
blk_queue_bypass_end() only the first time the queue is registered.
Signed-off-by: Alan Stern
CC: Tejun Heo
CC: James Bottomley
CC: Jens Axboe
---
[as1765]
block/blk-sysfs.c |6 --
1 file changed, 4 insertions(+), 2 dele
break;
> + case 't':
> + f |= US_FL_NO_ATA_1X;
> + break;
> case 'u':
> f |= US_FL_IGNORE_UAS;
> break;
You must not add an aditional value for a module parame
On Mon, 15 Sep 2014, Oliver Neukum wrote:
> On Mon, 2014-09-15 at 08:42 +, David Laight wrote:
> > From: Alan Stern
> >
> > > You must not add an aditional value for a module parameter without
> > > documenting it in Documentation/kernel-parameters.txt
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"
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
rs/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2924,6 +2924,9 @@ static int sd_probe(struct device *dev)
> sdkp->dev.class = &sd_disk_class;
> dev_set_name(&sdkp->dev, dev_name(dev));
>
> + if (dev)
> + sdkp->dev.power.async_suspend = dev->power.async_suspend;
> +
> if (device_add(&sdkp->dev))
> goto out_free_index;
Why not call device_enable_async_suspend() always?
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
approach would be to modify the SCSI disk driver to carry out
the spin-up operation asynchronously with respect to the resume
callback. Then the disk could be reported as back to full power while
the spin-up is taking place.
Alan Stern
--
To unsubscribe from this list: send the line "unsu
;ed?
No need, since I am subscribed to the linux-pm mailing list.
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
n changed.
In addition, scsi_start_stop_device() should return immediately if no
media is present. Or at least, it shouldn't treat "medium not present"
responses as errors.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body
38.525007] PM: resume of devices complete after 38.132 msecs
> [50138.525315] pci_pm_runtime_suspend():
> hcd_pci_runtime_suspend+0x0/0x50 returns -16
> [50138.536357] PM: Finishing wakeup.
In addition to my earlier comment, the patch below should be applied.
It will fix your immediate p
On Sat, 27 Jul 2013, Stuart Foster wrote:
> On 07/27/13 20:34, Alan Stern wrote:
> > On Sat, 27 Jul 2013, Stuart Foster wrote:
> >
> >> On 07/27/13 15:58, Alan Stern wrote:
> >>> On Sat, 27 Jul 2013, Stuart Foster wrote:
> >>>
> >>&g
On Mon, 29 Jul 2013, Oliver Neukum wrote:
> On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
>
> > In addition to my earlier comment, the patch below should be applied.
> > It will fix your immediate problem, although not in the best way.
>
> Alan,
>
> I t
On Mon, 29 Jul 2013, Martin K. Petersen wrote:
> >>>>> "Alan" == Alan Stern writes:
>
> Alan,
>
> Alan> It was introduced by commit 98dcc2946adb (SCSI: sd: Update WRITE
> Alan> SAME heuristics). This commit adds a call to scsi_get_vpd_pag
On Tue, 30 Jul 2013, Oliver Neukum wrote:
> On Mon, 2013-07-29 at 10:21 -0400, Alan Stern wrote:
> > On Mon, 29 Jul 2013, Oliver Neukum wrote:
> >
> > > On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
> > >
> > > > In addition to my earli
On Mon, 29 Jul 2013, Stuart Foster wrote:
> > Stuart and Ed, does Martin's patch fix your problem?
> >
> > Alan Stern
> >
> >
> Hi Alan,
>
> The patch is good for me.
>
> thanks
There also have been positive reports from Marc Meledandri and Ph
igned-off-by: Martin K. Petersen
> Acked-by: Alan Stern
> Tested-by: Stuart Foster
> Cc: sta...@vger.kernel.org
>
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 3b1ea34..eaa808e 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -1031,6 +1
h contains a couple of trivial whitespace errors (space added
to the end of a line, or spaces used instead of a tab).
More importantly, if we already know that the medium is not present or
has been changed since it was last used, then there's no reason to call
sd_sync_cache() at all.
Alan Stern
--
On Thu, 1 Aug 2013, Oliver Neukum wrote:
> On Wed, 2013-07-31 at 11:13 -0400, Alan Stern wrote:
>
> > More importantly, if we already know that the medium is not present or
> > has been changed since it was last used, then there's no reason to call
> > sd_sync_c
On Fri, 2 Aug 2013, Oliver Neukum wrote:
> On Thu, 2013-08-01 at 11:53 -0400, Alan Stern wrote:
> > On Thu, 1 Aug 2013, Oliver Neukum wrote:
> >
> > > On Wed, 2013-07-31 at 11:13 -0400, Alan Stern wrote:
> > >
> > > > More importantly, if we a
On Fri, 2 Aug 2013, Oliver Neukum wrote:
> On Fri, 2013-08-02 at 09:54 -0400, Alan Stern wrote:
> > On Fri, 2 Aug 2013, Oliver Neukum wrote:
> >
> > > On Thu, 2013-08-01 at 11:53 -0400, Alan Stern wrote:
> > > > On Thu, 1 Aug 2013, Oliver Neukum wrote:
> &g
(!scsi_device_online(...)) {
rc = -ENODEV;
goto err_online;
}
if (!req) {
retval = DRIVER_ERROR << 24;
goto err_get_request;
}
if (!sense) {
retval = DRIVER_ERROR << 24;
while loop, offset >= len, so buffer[offset]
> reads random garbage out-of-bounds.
> It the worst case it can lead to crash, or if (buffer[offset] & 0x3f)
> happen to be == modepage, then it will read more garbage.
>
> Please help validate and triage this.
The tool's o
ight. I didn't realize it at first, but the only way to get
here is if the next page offset lies beyond the end of the data in the
buffer. Therefore the patch can be simplified as follows.
Alan Stern
Index: usb-3.11/drivers/scsi/sd.c
=
On Wed, 4 Sep 2013, Dmitry Vyukov wrote:
> Thanks, Alan!
>
> I agree with Paolo that the branch can be removed.
>
> Will you take care of landing the patch?
I will when everyone agrees it is ready.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscrib
led. The
scsi_dev_type_suspend and scsi_dev_type_resume routines will be defined
but not used.
Otherwise it seems okay.
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
at due to ODD will be polled every 2 seconds, for suspend to
> actually happen, the autosuspend_delay can not be set to more than 2
> seconds or the polling interval has to be increased.
>
> Signed-off-by: Aaron Lu
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line &
ver suspend.
The default polling done by the kernel uses 2-second intervals. Of
course, distributions and users can change this or disable it entirely.
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
limited to 512 bytes.
Signed-off-by: Alan Stern
Reported-by: Dmitry Vyukov
CC:
---
[as1709]
drivers/scsi/sd.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
Index: usb-3.11/drivers/scsi/sd.c
===
--
> longer than the polling interval otherwise the device will never suspend.
Well, I wouldn't say "cannot" -- people can set the delay to whatever
they want. Just: If the autosuspend delay is set longer than the
polling interval then the device will never suspend.
Also, the act
ortant enough to merit a new quirk flag, but people experiencing the
problem may have some strong opinions.
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
On Tue, 10 Sep 2013, Oliver Neukum wrote:
> On Tue, 2013-09-10 at 13:25 -0400, Alan Stern wrote:
> > On Tue, 10 Sep 2013, Oliver Neukum wrote:
> >
> > > Hi Hannes,
> > >
> > > you objected to this patch saying there's a possibilty that
> >
On Wed, 11 Sep 2013, Oliver Neukum wrote:
> On Wed, 2013-09-11 at 10:14 -0400, Alan Stern wrote:
>
> > There are three possibilities: nothing, your proposed patch, and a new
>
> Nothing is feasible only if Windows uses READ_CAPACITY_10.
It seems clear that your patch isn
ors due to devices being offlined must also be ignored.
> The error returns must be modified so that the generic layer
> understands them.
>
> Signed-off-by: Oliver Neukum
Acked-by: Alan Stern
You might want to change the formatting slightly...
> @@ -1448,12 +1448,31 @@ static i
call? The dev->driver->owner
calculation would dereference a NULL pointer.
On Thu, 15 Jan 2015, Christoph Hellwig wrote:
> On Wed, Jan 14, 2015 at 10:07:00AM -0500, Alan Stern wrote:
> > and the kernfs core insures that the underlying device won't be
> > deallocated
On Mon, 19 Jan 2015, Kenneth R. Crudup wrote:
> Sorry for taking so long to get back to you guys about this (the 3.19-rc
> series has been
> problematic for me in a couple of areas, so I'd let it go for a while):
>
> On Mon, 5 Jan 2015, Alan Stern wrote:
>
> > The
On Wed, 14 Jan 2015, Christoph Hellwig wrote:
> On Mon, Jan 12, 2015 at 11:29:15AM -0500, Alan Stern wrote:
> > This seems like a good idea and the obvious (once it has been pointed
> > out!) approach.
> >
> > Perhaps not directly related to the issue a
e field. It also means changing all the subdrivers to
make them call the new function.
(1) is the simplest. Since the use of subdrivers in general tends to
be a special case (most SCSI drivers don't do it), I prefer to keep the
code optimized for it. In other words, I prefer option (1). If people
think (2) is better, it can always be layered on top of (1).
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
1 - 100 of 552 matches
Mail list logo
