Re: [PATCH] Revert "gpss: core: no waiters left behind on deregister"

Am Dienstag, den 03.09.2019, 12:18 +0200 schrieb Oliver Neukum: > This reverts commit f95aec18e46af9d7fb6f312020824d536dd720dd. Please ignore this. Regards Oliver

[PATCH] scsi: ignore a failure to synchronize cache due to lack of authorization

I've got a report about a UAS drive enclosure reporting back Sense: Logical unit access not authorized if the drive it holds is password protected. While the drive is obviously unusable in that state as a mass storage device, it still exists as a sd device and when the system is asked to perform a

[PATCH] Revert "gpss: core: no waiters left behind on deregister"

This reverts commit f95aec18e46af9d7fb6f312020824d536dd720dd. --- drivers/gnss/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gnss/core.c b/drivers/gnss/core.c index 0d13bd2cefd5..e6f94501cb28 100644 --- a/drivers/gnss/core.c +++ b/drivers/gnss/core.c @@ -303,7

Re: [PATCH] SCSI: unconditionally clean was_reset

On Do, 2019-04-04 at 08:51 -0700, Bart Van Assche wrote: > On Thu, 2019-04-04 at 16:47 +0200, Oliver Neukum wrote: > > If a reset of a SCSI device requires no relocking of the door, the > > flag must be reset anyway, lest it trigger unnecessary door action > > later on. &

[PATCH] SCSI: unconditionally clean was_reset

If a reset of a SCSI device requires no relocking of the door, the flag must be reset anyway, lest it trigger unnecessary door action later on. Signed-off-by: Oliver Neukum --- drivers/scsi/scsi_error.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/scsi

Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port

e an error. NACK Sorry Oliver

Re: [PATCH 3/5] uas: Use scsi_[gs]et_resid() where appropriate

On Fr, 2019-02-08 at 13:25 -0800, Bart Van Assche wrote: > This patch does not change any functionality. > > Cc: Oliver Neukum > Signed-off-by: Bart Van Assche Acked-by: Oliver Neukum

Re: scsi_set_medium_removal timeout issue

nc_sub in the device's Mass storage gadget driver. It exists for a reason. The blocks have to be on the medium. It seems to me that your gadget just allows too many dirty pages in the cache. Regards Oliver

Re: [usb-storage] [PATCH] usb: storage: Fix a possible data race in uas_queuecommand_lck

t to protect dev->resetting. I don't see why the scope of the lock would need to be enlarged. Regards Oliver > To fix this data race, the write operations on line 634-635 > should be also protected by the lock. > > Signed-off-by: Jia-Ju Bai Nacked-by: Oliver Neukum

Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

Am Mittwoch, den 14.03.2018, 11:22 +0100 schrieb Kashyap Chamarthy: > I see.  So I ran `dmesg -w`, as I attached the disk & see the following: UAS and no quirk for your device. It looks like it indeed just does not support TRIM. Sorry Oliver

Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

s or result to that degree. Whether UAS or storage are used dmesg will tell you. Regards Oliver

Re: [PATCH] uas: Unblock scsi-requests on failure to alloc streams in post_reset

this? >From 4d1e26154bc5d09913bfba34d7adc39cce98d20a Mon Sep 17 00:00:00 2001 From: Oliver Neukum Date: Wed, 10 Jan 2018 16:16:03 +0100 Subject: [PATCH] usb: uas: unconditionally bring back host after reset Quoting Hans: If we return 1 from our post_reset handler, then our disconnect handler will be called immediately af

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

, that is, to not apply it. Regards Oliver

Re: JMS56x not working reliably with uas driver

PORT OPCODES command, or something of the sort. We > should be able to handle bogus responses without logging ERROR > messages, because such messages indicate a bug in a kernel driver. Indeed. We have two independent issues. We should have two independent fixes. Regards

Re: JMS56x not working reliably with uas driver

On Tue, 2016-12-27 at 10:20 -0500, 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 how this patch fixes anything. Unless I'm mistaken, it > > > just avoids the probl

Re: JMS56x not working reliably with uas driver

Please clarify. If a reset leads to a disconnect, isn't that exactly what we want? Regards Oliver -- 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

Re: JMS56x not working reliably with uas driver

On Thu, 2016-12-22 at 15:43 +0530, George Cherian wrote: > dmesg with the patch applied Hi, did you apply both patches, yours and the one I posted? And did you physically disconnect your device? Regards Oliver -- To unsubscribe from this list: send the l

Re: JMS56x not working reliably with uas driver

ed patch and do a SCSI log of the enumeration? Regards Oliver From d4ddac88bbf9cb15e7d8638582f96d31e245f15b Mon Sep 17 00:00:00 2001 From: Oliver Neukum Date: Wed, 21 Dec 2016 15:34:54 +0100 Subject: [PATCH] uas: device crashes on reset We avoid resetting it. Signed-of

Re: JMS56x not working reliably with uas driver

On Wed, 2016-12-21 at 17:37 +0530, George Cherian wrote: > > On 12/21/2016 05:12 PM, Oliver Neukum wrote: > > On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote: > >> Hi Oliver, > >> > >> I was working with this JMicron device and using the uas driver.

Re: JMS56x not working reliably with uas driver

On Wed, 2016-12-21 at 12:54 +0100, Hans de Goede wrote: > Hi, > > On 21-12-16 12:42, Oliver Neukum wrote: > > On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote: > >> Hi Oliver, > >> > >> I was working with this JMicron device and using the uas drive

Re: JMS56x not working reliably with uas driver

On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote: > Hi Oliver, > > I was working with this JMicron device and using the uas driver. > I am seeing the following 2 issues. > > 1) On connect I see the following messages. Thanks. Do you want to submit it to Greg? The patch

[PATCH] scsi: introduce a quirk for false cache reporting

Some SATA to USB bridges fail to cooperate with some drives resulting in no cache being present being reported to the host. That causes the host to skip sending a command to synchronize caches. That causes data loss when the drive is powered down. Signed-off-by: Oliver Neukum Reviewed-by: Martin

Re: [PATCH] scsi: introduce a quirk for false cache reporting

On Thu, 2016-08-18 at 22:19 -0400, Martin K. Petersen wrote: > >>>>> "Oliver" == Oliver Neukum writes: > > Oliver> Some SATA to USB bridges fail to cooperate with some drives > Oliver> resulting in no cache being present being reported to the > Oliv

[PATCH] scsi: introduce a quirk for false cache reporting

Some SATA to USB bridges fail to cooperate with some drives resulting in no cache being present being reported to the host. That causes the host to skip sending a command to synchronize caches. That causes data loss when the drive is powered down. Signed-off-by: Oliver Neukum --- Documentation

Re: [PATCH] scsi: introduce a quirk for false cache reporting

On Tue, 2016-08-16 at 00:44 -0400, Martin K. Petersen wrote: > >>>>> "Oliver" == Oliver Neukum writes: > > Oliver, > > Oliver> wce_default_on controls the default if the device provides no > Oliver> indication. The problem here is that the

Re: [PATCH] scsi: introduce a quirk for false cache reporting

On Wed, 2016-08-10 at 22:40 -0400, Martin K. Petersen wrote: > >>>>> "Oliver" == Oliver Neukum writes: > > Oliver> Some SATA to USB bridges fail to cooperate with some drives > Oliver> resulting in no cache being present being reported to the > Oliv

[PATCH] scsi: introduce a quirk for false cache reporting

Some SATA to USB bridges fail to cooperate with some drives resulting in no cache being present being reported to the host. That causes the host to skip sending a command to synchronize caches. That causes data loss when the drive is powered down. Signed-off-by: Oliver Neukum Reviewed-by

[PATCH] scsi: introduce a quirk for false cache reporting

Some SATA to USB bridges fail to cooperate with some drives resulting in no cache being present being reported to the host. That causes the host to skip sending a command to synchronize caches. That causes data loss when the drive is powered down. Signed-off-by: Oliver Neukum --- Documentation

Re: [PATCH] usb: MAINTAINERS: Oliver Neukum is the new uas maintainer

On Thu, 2016-07-14 at 14:26 +0200, Hans de Goede wrote: > Oliver Neukum is taking over uas maintainership from me and > Gerd Hoffmann. > > Cc: Oliver Neukum > Cc: Gerd Hoffmann > Signed-off-by: Hans de Goede Acked-by: Oliver Neukum -- To unsubscribe from this list: send the

[PATCH] scsi: introduce a quirk for false cache reporting

Some SATA to USB bridges fail to cooperate with some drives resulting in no cache being present being reported to the host. That causes the host to skip sending a command to synchronize caches. That causes data loss when the drive is powered down. Signed-off-by: Oliver Neukum --- Documentation

[PATCH] scsi: introduce a quirk for false cache reporting

Some SATA to USB bridges fail to cooperate with some drives resulting in no cache being present being reported to the host. That causes the host to skip sending a command to synchronize caches. That causes data loss when the drive is powered down. Signed-off-by: Oliver Neukum --- drivers/scsi

Re: [PATCH resend] USB: uas: Fix slave queue_depth not being set

gt; that commit sets to the same value. > > This is incorrect, without the scsi_change_queue_depth() call the slave's > queue_depth defaults to 1, introducing a performance regression. Hans, may I ask what become of this patch? I don't see it in the queue. Regards

Re: [Resend PATCH 3/3] scsi:stex.c Add S3/S4 support

is too early. You will get a HIBERNATE event anyway. If the write out fails you are in trouble if you already reacted to PM_EVENT_FREEZE Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to ma

Re: [usb-storage] Re: [PATCH 04/14] uas: lock the abort handler

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 pretend the abort worked, the tag > > will be reused. > >

Re: [PATCH] USB: storage: add "no SYNCHRONIZE CACHE" quirk

; This causes errors when filesystems try to flush data out to the disk. OK, maybe this is a stupid idea, but could we test the command as we enumerate the slave and store the result? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe lin

Re: [PATCH 4/4 v4] scsi:stex.c Add S3/S4 support

gain while the work scheduled in resume is still running? Furthermore, what happens in the case of a PCI hotunplug while the work is still scheduled? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a

Re: [V3 PATCH 4/4] scsi:stex.c Add S3/S4 support

On Mon, 2014-12-15 at 11:12 +0800, Charles Chiou wrote: > > On 12/10/2014 05:02 PM, Oliver Neukum wrote: > > On Wed, 2014-12-10 at 09:38 +0800, Charles Chiou wrote: > >> From 91868d4afe10533b8a4496075109e411100217bb Mon Sep 17 00:00:00 2001 > >> From: Charles Chi

Re: [V3 PATCH 4/4] scsi:stex.c Add S3/S4 support

ill be asleep. GFP_KERNEL is automatically changed to GFP_NOIO. It would be nice to outright use GFP_NOIO. > + INIT_WORK(&hswork->handshake_work, resume_handshake); Memory allocations can fail. I suggest you allocate the memory in suspend(). There you can just return -ENOMEM in the

Re: [PATCH v2 10/24] uas: zap_pending: data urbs should have completed at this time

, as people, not compilers, like to remove them. Regards Oliver -- 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

Re: [PATCH fix for 3.17] uas: Add a quirk for rejecting ATA_12 and ATA_16 commands

annot. This parameter is an aid to debugging. > I might want to use two different usb-scsi devices that have different > requirements. Indeed. Quirky devices must be added to the quirks file. Regards Oliver -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH 10/21] uas: zap_pending: data urbs should have completed at this time

> - uas_try_complete(cmnd, __func__); > + WARN_ON(uas_try_complete(cmnd, __func__) != 0); That looks like very bad style. WARN_ON() shouldn't have side effects. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 20/21] uas: Remove support for old sense ui as used in pre-production hardware

assing through the sense data. Regards Oliver -- 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

Re: [PATCH 17/21] uas: Do not log urb status error on cancellation

On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote: > Check for both type of cancellation codes for sense and data urbs. Then you should also check for -ESHUTDOWN (unplug of HC) Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe li

Re: [PATCH 03/21] uas: Fix resetting flag handling

ork Why is the checking for stat and data inconsistent? Regards Oliver -- 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

Re: [PATCH 02/21] uas: Remove task-management / abort error handling code

the conservative choice. Regards Oliver -- 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

Re: [PATCH 01/21] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

On Wed, 2014-09-10 at 14:00 +0200, Hans de Goede wrote: > Hi, > > On 09/10/2014 01:56 PM, Oliver Neukum wrote: > > On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote: > >> Hi, > >> > >> Note this series is NOT intended for stable, but I accidentally

Re: [PATCH 01/21] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

this is not for stable, what do you intend to do about the problems in stable? For example patch#01 of this series looks like clear stable material to me. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a

Re: RES: RES: AS2105-based enclosure size issues with >2TB HDDs

On Tue, 2014-08-26 at 10:47 -0400, Alan Stern wrote: > On Mon, 25 Aug 2014, Oliver Neukum wrote: > > Just set US_FL_NEEDS_CAP16. If READ CAPACITY(16) fails in that case, > > it is clear that something is wrong. It must be set or READ CAPACITY(10) > > alone would be taken as

Re: RES: RES: AS2105-based enclosure size issues with >2TB HDDs

> > CAPACITY(10) to report a value less than 2 TB. > > Could the code try READ CAPACITY(16) first? Yes. It does already. That fails as the device doesn't support this version. In a way we are discussing error handling here. Regards Oliver -- To unsubscri

Re: RES: RES: AS2105-based enclosure size issues with >2TB HDDs

capacity, so we don't make matters worse if we crash it. Is there an easy way for Alfredo to determine what happens if we read beyond the end? Regards Oliver -- 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

Re: AS2105-based enclosure size issues with >2TB HDDs

; will be invalid when user plugs a <2TB HDD. An idea (bring by Oliver) is: It is worse than that. Pretty soon a 4.7TB disk will also be plausible. > first guess reading last sector using modulus result to check if size is > valid. It is necessary that a virgin disk also be handled c

Re: [PATCH] scsi: dc395x.c: Fix for possible null pointer dereference

_qtag: (0x%p) tag=%i srb=%p\n", > > - srb->cmd, tag, srb); > > + srb ? srb->cmd : 0, tag, srb); > > There's not just a risk, it is a NULL-pointer dereference, so, just remove > it, e.g. like Indeed. Thank you both for catching

Re: Disk spin-up optimization during system resume

> sent out unless they have the REQ_PM flag set.) > > Does this plan sound reasonable to everyone? Are there important > aspects I haven't considered (such as interactions between the SCSI > and > ATA layers)? The START-STOP may result in an error. What do you d

Re: [RFC] drivers/scsi/dc395x.c - msgin_qtag()

> If not, what approach do you suggest me for a patch? Merge it with dprintkdbg(DBG_0, "msgin_qtag: (0x%p) <%02i-%i>\n", srb->cmd, srb->dcb->target_id, srb->dcb->target_lun); later in the function. Regards Oliver

Re: READ_CAPACITY_16 vs. READ_CAPACITY_10

On Thu, 2013-09-12 at 07:47 +0200, Hannes Reinecke wrote: > On 09/11/2013 04:14 PM, Alan Stern wrote: > > On Tue, 10 Sep 2013, Oliver Neukum wrote: > >> I think we can be sure that no drive enclosure will crash > >> with READ_CAPACITY_16. > > > > I wouldn

[PATCH] sd: error handling during flushing caches

From: Oliver Neukum It makes no sense to flush the cache of a device without medium. Errors during suspend must be handled according to their causes. Errors due to missing media or unplugged devices must be ignored. Errors due to devices being offlined must also be ignored. The error returns

Re: Ejected Nook (usb mass storage) prevents suspend

I'll push upstream in a form that Alan likes. Regards Oliver -- 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

Re: READ_CAPACITY_16 vs. READ_CAPACITY_10

? > > Not me. It probably varies with different versions of Windows. I'll try to get a Windows machine for a trace. Can you suggest a tracer for Win7? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in

Re: READ_CAPACITY_16 vs. READ_CAPACITY_10

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 > > HS devices may also need this feature, which would require > >

READ_CAPACITY_16 vs. READ_CAPACITY_10

uirks? Regards Oliver +++ b/drivers/usb/storage/scsiglue.c @@ -211,8 +211,11 @@ static int slave_configure(struct scsi_device0*sdev) /* * Many devices do not respond properly to READ_CAPACITY_16. * Tell the SCSI layer to try READ_CAPACI

Re: [PATCH 4/5] uas: add dead request list

emp, &list, dead) { > + What happens if list entries are on the private list, when the function is called for another device? It looks to me like the di==devinfo test could put them back on the list although they would need to be canceled. Regards Oliver -- To uns

Geschaftsvorschlag.

Arbeitskollegen, die mich bei dieser Transaktion ebenfalls unterstützen. Wenn Sie interessiert sind, können Sie mir bitte eine E-Mail auf meinen prtivat E-Mail zuschicken oliver_ekm...@live.com, damit ich Ihnen mehr Details zukommen lassen kann. Mit freundlichen Grüßen Oliver Ekmann. -- To

Re: [PATCH v3 2/2] Hard disk S3 resume time optimization

rm > to the proper style guidelines. Hi, you are changing the generic resume for all sd disks. In particular, you are dropping the check of sdkp->device->manage_start_stop What happens if you use this patch on a real SCSI disk? Regards Oliver -- To unsubscr

Re: [PATCH v2] Hard disk S3 resume time optimization

s go to the device before this has finished? Especially should it fail. Regards Oliver -- 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

Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0

On Wed, 2013-08-07 at 15:58 +0900, Jingoo Han wrote: > On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote: > > On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote: > > > > > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType > > &g

Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0

g default values and > options.\n"); > - eeprom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM; > + eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 0xff); Hi, if you are fixing these issues please use the proper macros for conversion of endianness.

Re: [PATCH] Hard disk S3 resume time optimization

Regards Oliver -- 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

Re: Ejected Nook (usb mass storage) prevents suspend

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: > > > > > > > On Wed, 2013-07-31 at 11:13 -0400,

Re: [PATCH] Hard disk S3 resume time optimization

e > underlying code is identical to sd_resume, but is changed to non-blocking). But how do we know the command has succeeded? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to major

Re: Ejected Nook (usb mass storage) prevents suspend

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 already know that the medium is not present or > > > has been changed

Re: Ejected Nook (usb mass storage) prevents suspend

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_cache() at all. Like this? Regards O

Re: Ejected Nook (usb mass storage) prevents suspend

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 earlier comment, the patch below should be applied. > > > It will fix you

Re: Ejected Nook (usb mass storage) prevents suspend

genuine error while flushing a drive's cache is one of the few things actual worth aborting a system suspend for. > If you would like to handle the problems in sd.c concerning the > sync-cache and spin-down stuff, that will be fine with me. Yes. The problem is not limited to USB.

Re: Ejected Nook (usb mass storage) prevents suspend

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 earlier comment, the patch below should be applied. > > > It will fix you

Re: Ejected Nook (usb mass storage) prevents suspend

se. We might lose data if the flush is not done. Regards Oliver -- 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

Re: Ejected Nook (usb mass storage) prevents suspend

in device (so it's working). Suspend works. > - eject /dev/sdb. Suspend fails. > - Physically unplug the device. Suspend works again. Hi, this looks like a logical error in sd_suspend(). It should ignore errors due to missing media (or offlined devices) Regards Oliver

Re: [patch] [SCSI] dc395x: uninitialized variable in device_alloc()

On Monday 11 February 2013 22:03:18 Dan Carpenter wrote: > This bug was introduced back in bitkeeper days in 2003. We use > "dcb->dev_mode" before it has been initialized. > > Signed-off-by: Dan Carpenter Acked-by: Oliver Neukum -- To unsubscribe from this list: s

Re: Fwd: 2TB USB hard drive for backing up

ssociated flag? Regards Oliver -- 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

Re: [PATCH v13 1/9] scsi: sr: support runtime pm

On Tuesday 22 January 2013 10:25:31 Aaron Lu wrote: > On Mon, Jan 21, 2013 at 03:56:43PM +0100, Oliver Neukum wrote: > > On Monday 21 January 2013 17:11:04 Aaron Lu wrote: > > > It is not easy for the OS to tell if the drive is being used or not > > > sometimes > &

Re: [PATCH v13 1/9] scsi: sr: support runtime pm

ile. > From the OS' point of view, we think nobody is using it. But actually, > the drive is playing cd for the user, so we can't suspend the device. Are there drives that support ZPODD and have an audio output? Regards Oliver -- To unsubscribe from this l

Re: [PATCH v6 4/4] sd: change to auto suspend mode

, as we know there is > no request to quiesce for the device. How does this handle ioctl() ? Regards Oliver -- 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 h

Re: [PATCH v7 2/6] scsi: sr: support runtime pm

ces. You know that it hasn't been changed. We should notify the upper layers that we can do medium change detection on our own. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.

Re: [PATCH v7 2/6] scsi: sr: support runtime pm

On Tuesday 25 September 2012 22:46:06 Aaron Lu wrote: > On 09/25/2012 10:23 PM, Oliver Neukum wrote: > >> BTW, if sr_suspend should be generic, that would suggest I shouldn't > >> write any ZPODD related code there, right? Any suggestion where these > >> c

Re: [PATCH v7 2/6] scsi: sr: support runtime pm

t I shouldn't > write any ZPODD related code there, right? Any suggestion where these > code should go then? libata. Maybe some generic hooks can be called in sr_suspend(). Regards Oliver PS: Are you sure sr_suspend() handles DVD-RAMs correctly? -- To unsubscr

Re: [PATCH v7 0/6] ZPODD patches

e the feature in question. > Why do you think the new interface is needed? Because this is not equivalent to doing no runtime PM at all. SCSI now defines some powersaving states which do not involve powering down and thus losing state. Regards Oliver -- To unsubscribe

Re: [PATCH v7 0/6] ZPODD patches

t > how we power off the device until you get all the way down to the ACPI > controller. The SCSI layer however needs to know whether the cache is handled by the OS or in the device and under which circumstances a device can detect media change events. Regards Oliver

Re: [PATCH v2 1/4] scsi: introduce sync_before_stop flag

he for ATA device, so to issue stop command to ATA > device, an additional flush cache has to be issued. Why not just set WCE? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.ker

Re: [PATCH 1/2] scsi: sd: set ready_to_power_off for scsi disk

On Thursday 13 September 2012 12:24:46 Alan Stern wrote: > On Thu, 13 Sep 2012, Oliver Neukum wrote: > > Yes, but this confusion is necessary. The driver core is supposed to > > be generic and knows strictly speaking only suspended and active. > > It is a driver's job t

Re: [PATCH 1/2] scsi: sd: set ready_to_power_off for scsi disk

On Thursday 13 September 2012 11:51:07 James Bottomley wrote: > On Thu, 2012-09-13 at 12:16 +0200, Oliver Neukum wrote: > > On Thursday 13 September 2012 10:26:44 James Bottomley wrote: > > > On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote: > > > > > > So I t

Re: [PATCH 1/2] scsi: sd: set ready_to_power_off for scsi disk

nto the code and has been so for a long time. Though it wouldn't hurt to add a comment that says that the system going to S3 or S4 will cut power to a lot of disk so that the cache needs to be synced even if the spec says we need not. Runtime PM doesn't much alter the situation.

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

er runtime suspend state. > > Looks like I need to record if the door is locked in scsi_cd structure > so that I did not mistakenly eject the door. Does this sound OK? Yes, that will do. Regards Oliver -- To unsubscribe from this list: send the line "unsubscr

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

On Tuesday 11 September 2012 19:11:08 Aaron Lu wrote: > On Tue, Sep 11, 2012 at 11:30:35AM +0200, Oliver Neukum wrote: > > On Tuesday 11 September 2012 17:24:13 Aaron Lu wrote: > > Yes, but because the whole system had been suspended. > > In that case you can have a locked

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

On Tuesday 11 September 2012 17:24:13 Aaron Lu wrote: > On Tue, Sep 11, 2012 at 10:55:44AM +0200, Oliver Neukum wrote: > > On Tuesday 11 September 2012 14:44:30 Aaron Lu wrote: > > > On Mon, Sep 10, 2012 at 12:45:51PM +0200, Oliver Neukum wrote: > > > > On Monday 10

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

On Tuesday 11 September 2012 14:44:30 Aaron Lu wrote: > On Mon, Sep 10, 2012 at 12:45:51PM +0200, Oliver Neukum wrote: > > On Monday 10 September 2012 17:16:22 Aaron Lu wrote: > > > > > +static int sr_resume(struct device *dev) > > > +{ > > > + struct

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

e->need_eject = 0; > + if (!(cd->cdi.mask & CDC_CLOSE_TRAY)) > + sr_tray_move(&cd->cdi, 1); 1. Even if the door is locked? 2. sr_tray_move allocates memory with GFP_KERNEL. This smells of a deadlock. Regards Oliver -- To unsubscr

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

On Thursday 06 September 2012 13:08:18 Alan Stern wrote: > On Thu, 6 Sep 2012, Oliver Neukum wrote: > > > On Thursday 06 September 2012 11:06:49 Alan Stern wrote: > > > On Thu, 6 Sep 2012, Aaron Lu wrote: > > > > > > > > That's why we ha

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

g interval. > > But in the long run that wouldn't be a good solution. What I'd really > like is a way to do the status polling without having it reset the > idle timer. > > Oliver, what do you think? Would that be a good solution? Well, we could introduce a flag i

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

On Wednesday 05 September 2012 23:22:55 Aaron Lu wrote: > On Tue, Sep 04, 2012 at 08:47:15PM +0200, Oliver Neukum wrote: > > On Tuesday 04 September 2012 13:59:38 Alan Stern wrote: > > > What requirement are you talking about? The "no media and door closed" > >

Re: [PATCH v6 1/7] scsi: sr: support runtime pm for ODD

On Tuesday 04 September 2012 13:59:38 Alan Stern wrote: > On Tue, 4 Sep 2012, Oliver Neukum wrote: > > > On Tuesday 04 September 2012 22:24:34 Aaron Lu wrote: > > > From: Aaron Lu > > > > > > The ODD will be placed into suspend state when: > > &g

Re: [PATCH v6 5/7] scsi: pm: add may_power_off flag

ered off(reflected by can_power_off flag, > determined by individual driver), create a sysfs entry named > may_power_off to let user control the flag. Do we really need yet another interface to user space? Regards Oliver -- To unsubscribe from this list: send the line

  1   2   3   >