Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

On Thu, 2018-05-10 at 09:25 -0500, David R. Bild wrote: > On Tue, May 8, 2018 at 10:36 AM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > > > On Tue, 2018-05-08 at 10:29 -0500, David R. Bild wrote: > > > On Tue, May 8, 2018 at 10:25 AM, Ja

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

On Tue, 2018-05-08 at 10:29 -0500, David R. Bild wrote: > On Tue, May 8, 2018 at 10:25 AM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > > > > On Fri, May 04, 2018 at 02:56:25PM -0500, David R. Bild wrote: > > > > [...] > &g

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

On Tue, 2018-05-08 at 13:55 +0300, Jarkko Sakkinen wrote: > On Fri, May 04, 2018 at 02:56:25PM -0500, David R. Bild wrote: [...] > > In particular, it sets the credentials for the platform hierarchy. > > The platform hierarchy is essentially the "root" account of the > > TPM, so it's critical that

Re: Seagate External SMR drive USB resets (was: Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device)

On Wed, 2017-11-15 at 17:02 -0500, Alan Stern wrote: > On Wed, 15 Nov 2017, Jérôme Carretero wrote: > > >   Because with several of these drives / lots of activity / > occasional > > >   issues, it looks like it will be hard to catch (yes I can use > > > usbmon). > > >  > > > - It looks like there

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote: > > Elena Reshetova writes: > > > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid accidental > > >

Re: Advanced Format SAT devices show incorrect physical block size

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 those lines. In general we hesitate to make > changes of this sort, because they

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

On Tue, 2016-05-24 at 08:53 +0200, Hans de Goede wrote: > Hi, > > On 23-05-16 19:36, James Bottomley wrote: > > On Mon, 2016-05-23 at 13:49 +0200, Hans de Goede wrote: > > > Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host > > > level"

Re: [PATCH 1/1] uas: leave can_queue as MAX_CMNDS if device reports larger qdepth

On Tue, 2016-05-24 at 01:23 +0800, Tom Yan wrote: > Nothing wrong. It's just .can_queue = MAX_CMNDS in the host template > is no longer neceesary, since with his patch, uas will set can_queue > again later (to devinfo->qdepth - 2). > > Originally I thought .can_queue = MAX_CMNDS can hence be

Re: [regression] uas no longer queues commands since v4.5.2

On Mon, 2016-05-23 at 13:48 +0200, Hans de Goede wrote: > Hi, > > On 22-05-16 12:39, Tom Yan wrote: > > With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas no longer > > set `queue_depth` with scsi_change_queue_depth(), so now > > `queue_depth` > > of UAS drives are 1. Even though

Re: raid 5 creation fails on usb3 connected drives kernel 4.4.x, 4.5

fault or if its the USB > > > > > > > > > > Attached SCSI driver uas.ko, > > > > > > > > > > or maybe the host driver xhci-hcd. > > > > > > > > > Can you run 'git bisect' to try to track down the > > &

Re: [-next] BUG_ON in scsi_target_destroy()

On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote: > Hi Sergey, Xiong, > > Can you try below patch? > > On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: > > Hello, > > > > commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96 > > Author: Johannes Thumshirn

Re: [PATCH] uas: Add a new NO_REPORT_LUNS quirk

On Thu, 2016-03-31 at 17:03 +0200, Hans de Goede wrote: > Hi, > > On 31-03-16 16:48, James Bottomley wrote: > > On Thu, 2016-03-31 at 14:22 +0200, Hans de Goede wrote: > > > Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with > > > an usb-id

Re: [PATCH] uas: Add a new NO_REPORT_LUNS quirk

On Thu, 2016-03-31 at 14:22 +0200, Hans de Goede wrote: > Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with > an usb-id of: 0bc2:331a, as these will fail to respond to a > REPORT_LUNS command. Actually, if we're sending them a report luns command, they must be reporting in at

Re: [PATCH] uas: Limit qdepth at the scsi-host level

On Sat, 2016-03-19 at 09:59 +0100, Hans de Goede wrote: > Commit 64d513ac31bd ("scsi: use host wide tags by default") causes > the scsi-core to queue more cmnds then we can handle on devices with > multiple LUNs, limit the qdepth at the scsi-host level instead of > per slave to fix this. Help me

Re: Multiple drives on JMS56x-based sata-usb docking station.

On Tue, 2015-10-06 at 14:46 -0400, Alan Stern wrote: > On Tue, 6 Oct 2015, Daniel Ranger wrote: > > > Alan Stern writes: > > > > > > > > On Fri, 31 Jul 2015, Giulio Bernardi wrote: > > > > > > > P.S: it looks like scsi_dev_info_list_del_keyed() shares the same > > code, so maybe

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On Mon, 2015-09-28 at 14:50 +, David Laight wrote: > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > > Sent: 28 September 2015 15:27 > > On Mon, 2015-09-28 at 08:58 +, David Laight wrote: > > > From: Rafael J. Wysocki > > >

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On Mon, 2015-09-28 at 08:58 +, David Laight wrote: > From: Rafael J. Wysocki > > Sent: 27 September 2015 15:09 > ... > > > > Say you have three adjacent fields in a structure, x, y, z, each one > > > > byte long. > > > > Initially, all of them are equal to 0. > > > > > > > > CPU A writes 1 to

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote: > On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote: > > On 25 September 2015 at 13:33, Rafael J. Wysocki wrote: > > > You're going to change that into bool in the next patch, right? > > > > Yeah. > > > >

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

On Fri, 2015-06-26 at 11:43 +0200, Stefan Richter wrote: On Jun 22 James Bottomley wrote: On Mon, 2015-06-22 at 13:30 -0400, Alan Stern wrote: On Mon, 22 Jun 2015, James Bottomley wrote: Obviously, for a disk with a writeback cache that can't do flush, that window is much wider

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

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 silently. However, I also believe treating a single flush failure as a critical filesystem error

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

On Mon, 2015-06-22 at 10:55 -0400, Alan Stern wrote: Some USB mass-storage devices claim to have a write-back cache but don't support the SYNCHRONIZE CACHE command, which means there is no way to tell these devices to flush their caches out to permanent storage. Unfortunately, there is

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

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: I'm not sure I entirely like this: we are back again treating data corruption

Re: [PATCH v6 0/4] scsi: ufs ums-* esp_scsi: fix module reference counting

On Tue, 2015-05-05 at 10:25 -0400, Alan Stern wrote: On Mon, 4 May 2015, James Bottomley wrote: On Mon, 2015-05-04 at 16:09 -0400, Alan Stern wrote: On Mon, 4 May 2015, James Bottomley wrote: However, it does also strike me that these three drivers have problems because they're

Re: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)

On Tue, 2014-12-30 at 10:34 -0500, Alan Stern wrote: On Tue, 30 Dec 2014, Christoph Hellwig wrote: The only limits usb-storage imposes on max_sectors are those needed to work around bugs in the devices' USB bridges. (Okay, there's also something for tape drive devices, but it probably

Re: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)

On Tue, 2014-12-30 at 11:12 -0500, Alan Stern wrote: On Tue, 30 Dec 2014, James Bottomley wrote: _Is_ there any way to communicate the maximum transfer size? I'm not aware of any SCSI command for it. It isn't part of the USB mass-storage spec. For the device, it's in the Block

Re: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)

On Tue, 2014-12-30 at 11:45 -0500, Alan Stern wrote: PS: What's the current situation of my SCSI: fix regression in scsi_send_eh_cmnd() patch: http://marc.info/?l=linux-scsim=141658469207765w=2 submitted on November 21? Since it was a bug-fix, I rather expected it to get merged

Re: [patch] usb: storage: debug: uninitialized var in usb_stor_show_sense()

On Sat, 2014-11-29 at 15:48 +0300, Dan Carpenter wrote: The fmt variable might be used uninitialized, it should be set to NULL at the start. Fixes: d811b848ebb7 ('scsi: use sdev as argument for sense code printing') Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Hm, that' falls into

Re: Large disk drives

On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote: On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote: Sorry, meant to. In principle I'm OK with this as the lever for the hack (largely because it means we don't need to do anything) but will the distributions support it?

Re: Large disk drives

On Thu, 2014-11-06 at 16:33 +0200, Boaz Harrosh wrote: On 11/06/2014 12:30 PM, James Bottomley wrote: On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote: On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote: Sorry, meant to. In principle I'm OK with this as the lever

Re: Large disk drives

On Thu, 2014-11-06 at 17:08 +, David Laight wrote: From: Boaz Harrosh On 11/06/2014 05:53 PM, Alan Stern wrote: But just the simple case of read-capacity failure should we then? That's a separate question. As far as I know, the case you are describing has not come up.

Re: Large disk drives

On Tue, 2014-11-04 at 11:14 -0500, Alan Stern wrote: On Tue, 4 Nov 2014, James Bottomley wrote: On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote: Was there any resolution as to how large disk drives would be handled if their interface did not support the capacity request

Re: Large disk drives

On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote: Was there any resolution as to how large disk drives would be handled if their interface did not support the capacity request that would tell how large they were? Realistically no ... unless someone comes up with a reliable heuristic to

Re: [PATCH v2 2/2] uas: Make uas work with blk-mq

of usb.git, care to refresh it and resend? I did this v2 to resolve a conflict with a last minute fix for 3.17 which James Bottomley pushed out yesterday. So if this does not apply that likely is because that fix is not (yet) in next. See: https://git.kernel.org/cgit/linux/kernel/git/jejb

Re: [PATCH 2/2] uas: Make uas work with blk-mq

On Thu, 2014-10-02 at 15:18 +0200, Hans de Goede wrote: Hi, On 10/02/2014 03:12 PM, Christoph Hellwig wrote: On Thu, Oct 02, 2014 at 03:08:40PM +0200, Hans de Goede wrote: Yes, although that likely would need to go through stable, without going into 3.18 . Greg, is this ok with you

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

On Sun, 2014-09-14 at 11:26 +0200, Hans de Goede wrote: Hi, On 09/13/2014 09:31 PM, Sergei Shtylyov wrote: Hello. On 9/13/2014 1:26 PM, Hans de Goede wrote: The data urbs are all killed before calling zap_pending, and their completion handler should have cleared their inflight

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

On Sun, 2014-09-14 at 12:32 +0200, Hans de Goede wrote: Hi, On 09/14/2014 12:29 PM, James Bottomley wrote: On Sun, 2014-09-14 at 11:26 +0200, Hans de Goede wrote: Hi, On 09/13/2014 09:31 PM, Sergei Shtylyov wrote: Hello. On 9/13/2014 1:26 PM, Hans de Goede wrote: The data

Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)

On Wed, 2014-09-03 at 15:05 -0400, Alan Stern wrote: On Wed, 3 Sep 2014, Dale R. Worley wrote: From: Alan Stern st...@rowland.harvard.edu 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

Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)

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) in sysfs from userspace (will require block change)? We can then encode all the nasty heuristics

Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)

On Wed, 2014-08-27 at 15:21 -0400, Dale R. Worley wrote: From: James Bottomley james.bottom...@hansenpartnership.com Did you try read capacity 16 on it? What happened? (the AS2105 rejects read capacity 16, so there's no reliable way to deduce the capacity of drives over 2TB). OK, I

Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)

On Tue, 2014-08-26 at 15:39 -0400, Dale R. Worley wrote: This is almost certainly a form of the problem reported in AS2105-based enclosure size issues with 2TB HDDs. I'm repeating my original message here so linux-usb can see it, and so it can be connected to the older thread. I'll address

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

On Mon, 2014-08-25 at 18:48 +, 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 cannot be worked around in any

Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN

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_level doesn't get set when sdev is allocated, so it initially contains 0, so the LUN

Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN

On Mon, 2014-08-25 at 17:19 -0400, Alan Stern wrote: 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

Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN

On Fri, 2014-08-22 at 10:53 -0400, Alan Stern wrote: On Thu, 21 Aug 2014, Christoph Hellwig wrote: On Thu, Aug 21, 2014 at 05:43:41PM -0400, Martin K. Petersen wrote: Alan Okay, here's a patch that implements the suggestion, except that I Alan put the flag in the Scsi_Host structure

Re: Problem with USB-to-SATA adapters

On Wed, 2014-08-20 at 16:18 -0400, Dale R. Worley wrote: I don't know if this is the correct place for this problem, but you people can probably tell me the correct place. linux-usb can probably also help (cc'd). I have two USB to SATA adapter dongles. In general, they work fine. However

Re: [usb-storage] Re: External USB3 disk fails with Invalid field in cdb

On Fri, 2014-06-27 at 15:23 -0400, Alan Stern wrote: On Fri, 27 Jun 2014, Michael Büsch wrote: On Fri, 27 Jun 2014 14:42:01 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: Michael, can you post the lsusb -v output for this device? I see it is made by JMicron; they are

Re: [Bug 77631] New: task scsi_eh_6:537 blocked for more than 120 seconds.

From the trace below, this looks to be a USB issue (USB added to cc): the scsi error handler thread is waiting for usb storage to complete the reset. It's a 3.14.5 kernel, so the previous reset hang because of spurious sense requests should be fixed. James On Tue, 2014-06-10 at 16:50 +,

Re: Weird I/O errors with USB Hard disk

On Sat, 2014-05-10 at 22:38 +0800, loody wrote: hi all: I have a USB hard disk and when I play specific file. it will show below message ( I purpose enable usb/storage/transport.c debug message about urb debug) what makes me confused are 1. Does Unhandled sense code mean the SCSI Request

Re: Weird I/O errors with USB Hard disk

On Sun, 2014-05-11 at 00:43 +0800, loody wrote: hi James: 2014-05-10 23:10 GMT+08:00 James Bottomley james.bottom...@hansenpartnership.com: On Sat, 2014-05-10 at 22:38 +0800, loody wrote: hi all: I have a USB hard disk and when I play specific file. it will show below message ( I

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

On Thu, 2014-04-10 at 19:52 +0200, Hannes Reinecke wrote: On 04/10/2014 05:31 PM, Alan Stern wrote: On Thu, 10 Apr 2014, Hannes Reinecke wrote: On 04/10/2014 12:58 PM, Andreas Reis wrote: That patch appears to work in preventing the crashes, judged on one repeated appearance of the bug.

Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling

[lets split the thread] On Mon, 2014-03-31 at 16:37 +0200, Hannes Reinecke wrote: On 03/31/2014 03:33 PM, Alan Stern wrote: On Mon, 31 Mar 2014, Hannes Reinecke wrote: On 03/28/2014 08:29 PM, Alan Stern wrote: On Fri, 28 Mar 2014, James Bottomley wrote: Maybe scmd_eh_abort_handler

Re: Deadlock in usb-storage error handling

On Thu, 2014-03-20 at 15:49 -0400, Alan Stern wrote: On Thu, 20 Mar 2014, James Bottomley wrote: On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote: On Thu, 20 Mar 2014, James Bottomley wrote: OK, so I think we have three things to do 1. Investigate SCSI and fix it's

[PATCH 0/3] Fix USB deadlock caused by SCSI error handling

This is a set of three patches we agreed to a while ago to eliminate a USB deadlock. I did rewrite the first patch, if it could be reviewed and tested. Thanks, James --- Alan Stern (1): [SCSI] Fix command result state propagation James Bottomley (2): [SCSI] Fix abort state memory problem

[PATCH 3/3] [SCSI] Fix command result state propagation

. Fix this by properly zeroing the scmd-status before the command is resubmitted. Signed-off-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: James Bottomley jbottom...@parallels.com --- drivers/scsi/scsi_error.c | 1 + drivers/scsi/scsi_lib.c | 1 + 2 files changed, 2 insertions(+) diff

[PATCH 2/3] [SCSI] Fix spurious request sense in error handling

this by testing to see if we actually got a CHECK_CONDITION return and skip asking for sense if we don't. Tested-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: James Bottomley jbottom...@parallels.com --- drivers/scsi/scsi_error.c | 9 + 1 file changed, 9 insertions(+) diff --git

[PATCH 1/3] [SCSI] Fix abort state memory problem

The abort state is being stored persistently across commands, meaning if the command times out a second time, the error handler thinks an abort is still pending. Fix this by properly resetting the abort flag after the abort is finished. Signed-off-by: James Bottomley jbottom...@parallels.com

Re: Deadlock in usb-storage error handling

On Thu, 2014-03-20 at 11:36 -0400, Alan Stern wrote: On Wed, 19 Mar 2014, James Bottomley wrote: Basically, usb-storage deadlocks when the SCSI error handler invokes the eh_device_reset_handler callback while a command is running. The command has timed out and will never complete

Re: Deadlock in usb-storage error handling

On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote: On Thu, 20 Mar 2014, James Bottomley wrote: OK, so I think we have three things to do 1. Investigate SCSI and fix it's abort state problem that's causing it not to send the abort second time around 2. Fix usb

Re: Deadlock in usb-storage error handling

On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote: On Thu, 20 Mar 2014, James Bottomley wrote: OK, so I think we have three things to do 1. Investigate SCSI and fix it's abort state problem that's causing it not to send the abort second time around 2. Fix usb

Re: Deadlock in usb-storage error handling

On Thu, 2014-03-20 at 15:48 -0400, Alan Stern wrote: On Thu, 20 Mar 2014, James Bottomley wrote: On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote: On Thu, 20 Mar 2014, James Bottomley wrote: OK, so I think we have three things to do 1. Investigate SCSI and fix it's

Re: Deadlock in usb-storage error handling

On Thu, 2014-03-20 at 15:59 -0400, Alan Stern wrote: On Thu, 20 Mar 2014, James Bottomley wrote: OK, so I think we have three things to do 1. Investigate SCSI and fix it's abort state problem that's causing it not to send the abort second time around 2. Fix usb

Re: Deadlock in usb-storage error handling

On Wed, 2014-03-19 at 16:31 -0400, Alan Stern wrote: On Wed, 19 Mar 2014, Andreas Reis wrote: I've uploaded a dmesg with the new debugging patch to bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=130041 Thanks. I have now managed to reproduce many of the features of this

Re: [PATCH 0/2] target refcounting infrastructure fixes for usb

On Thu, 2014-03-06 at 15:18 -0800, Sarah Sharp wrote: Hi James, Sorry for the extremely late ack. That's OK ... my original plan was to send them in the last merge window even without your ack, but that got a bit derailed, so I'll do it in this one with. These patches work fine when

Re: v3.14-rc2+ WARNING: CPU: 0 PID: 24108 at fs/sysfs/group.c:216 sysfs_remove_group+0xa3/0xb0()

On Mon, 2014-02-17 at 14:48 -0500, Alan Stern wrote: On Mon, 17 Feb 2014, Ronald wrote: I caught this by coincidence since I had netconsole attached to debug a nouveau MSI problem (deadlock). It happenned when I disconnected my external hardrive in thunar. I have attached my full dmesg.

[PATCH 0/2] target refcounting infrastructure fixes for usb

properly reference counted. James Bottomley (2): [SCSI] fix our current target reap infrastructure. [SCSI] dual scan thread bug fix drivers/scsi/scsi_scan.c | 112 - drivers/scsi/scsi_sysfs.c | 20 +--- include/scsi/scsi_device.h | 3 +- 3

[PATCH 2/2] dual scan thread bug fix

without reference counting, the second thread will do the wrong thing on reap. Fix this by reference counting even creates and doing the STARGET_CREATED check in the final put. Signed-off-by: James Bottomley jbottom...@parallels.com --- drivers/scsi/scsi_scan.c | 23 --- 1 file

[PATCH 1/2] fix our current target reap infrastructure

that the target disappears as soon as the last device is gone rather than waiting until final release of the device (which is often too long). Reviewed-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: James Bottomley jbottom...@parallels.com --- drivers/scsi/scsi_scan.c | 99

Re: [RFC 2/2] dual scan thread bug fix

On Wed, 2014-01-08 at 10:57 -0500, Alan Stern wrote: On Wed, 8 Jan 2014, James Bottomley wrote: OK, Agreed, but that means modifying the 1/2 patch with the below. This should make the proposed diff to 2/2 correct. James --- diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi

Re: [RFC 2/2] dual scan thread bug fix

On Sat, 2014-01-04 at 11:27 -0500, Alan Stern wrote: On Fri, 3 Jan 2014, James Bottomley wrote: I'm still concerned about one thing. The previous patch does this in scsi_alloc_target(): found: - found_target-reap_ref++; + if (!kref_get_unless_zero

Re: [RFC 0/2] target refcounting infrastructure fixes for usb

On Fri, 2014-01-03 at 09:56 +0100, Hans de Goede wrote: James, what is the status of getting the fix for the refcount issue into mainline ? The plan is what I wrote in the patch intro: Since it's a major change to the infrastructure, we'll incubate upstream first before

Re: [RFC 2/2] dual scan thread bug fix

On Fri, 2014-01-03 at 10:58 -0500, Alan Stern wrote: On Thu, 2 Jan 2014, James Bottomley wrote: In the highly unusual case where two threads are running concurrently through the scanning code scanning the same target, we run into the situation where one may allocate the target while

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

On Thu, 2014-01-02 at 16:01 -0500, Mark Lord wrote: On 14-01-02 02:15 PM, Sarah Sharp wrote: On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote: .. Unfortunately this patch causes a regression when copying large files to my outboard USB3 drive. (Nothing at all to do with networking.)

Re: [RFC 0/2] target refcounting infrastructure fixes for usb

On Sat, 2013-12-21 at 15:51 -0500, Alan Stern wrote: On Fri, 20 Dec 2013, Sarah Sharp wrote: On Thu, Dec 19, 2013 at 11:48:47AM -0800, James Bottomley wrote: It should apply incrementally on top of the previous two. If it actually works, I'll fold it into the first patch. Well

[RFC 0/2] target refcounting infrastructure fixes for usb

This set should fix our target problems with USB by making the target visibility properly reference counted. Since it's a major change to the infrastructure, we'll incubate upstream first before backporting to stable. James Bottomley (2): [SCSI] fix our current target reap infrastructure

[RFC 1/2] fix our current target reap infrastructure

that the target disappears as soon as the last device is gone rather than waiting until final release of the device (which is often too long). Reviewed-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: James Bottomley jbottom...@parallels.com --- drivers/scsi/scsi_scan.c | 95

Re: [RFC 0/2] target refcounting infrastructure fixes for usb

On Thu, 2014-01-02 at 16:45 -0800, Sarah Sharp wrote: On Sat, Dec 21, 2013 at 03:51:25PM -0500, Alan Stern wrote: On Fri, 20 Dec 2013, Sarah Sharp wrote: On Thu, Dec 19, 2013 at 11:48:47AM -0800, James Bottomley wrote: It should apply incrementally on top of the previous two

Re: [RFC 0/2] target refcounting infrastructure fixes for usb

On Thu, 2013-12-19 at 10:26 -0800, Sarah Sharp wrote: On Wed, Dec 18, 2013 at 04:05:05PM -0800, James Bottomley wrote: On Wed, 2013-12-18 at 16:50 -0500, Alan Stern wrote: On Wed, 18 Dec 2013, Sarah Sharp wrote: On Mon, Dec 16, 2013 at 07:10:19AM -0800, James Bottomley wrote

Re: [RFC 0/2] target refcounting infrastructure fixes for usb

On Wed, 2013-12-18 at 16:50 -0500, Alan Stern wrote: On Wed, 18 Dec 2013, Sarah Sharp wrote: On Mon, Dec 16, 2013 at 07:10:19AM -0800, James Bottomley wrote: This set should fix our target problems with USB by making the target visibility properly reference counted. Since it's a major

[RFC 0/2] target refcounting infrastructure fixes for usb

This set should fix our target problems with USB by making the target visibility properly reference counted. Since it's a major change to the infrastructure, we'll incubate upstream first before backporting to stable. James --- James Bottomley (2): [SCSI] fix our current target reap

[RFC 1/2] fix our current target reap infrastructure.

This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap() for the device is done from __scsi_remove_device() and only if the device was made visible. This ensures that the

[RFC 2/2] dual scan thread bug fix

In the highly unusual case where two threads are running concurrently through the scanning code scanning the same target, we run into the situation where one may allocate the target while the other is still using it. In this case, because the reap checks for STARGET_CREATED and kills the target

Re: [RFC] fix our current target reap infrastructure.

On Sun, 2013-12-15 at 16:32 -0500, Alan Stern wrote: On Sat, 14 Dec 2013, James Bottomley wrote: The refcount test and state change race with scsi_alloc_target(). Maybe the race won't occur in practice, but to be safe you should hold shost-host_lock throughout that time interval

Re: [RFC] fix our current target reap infrastructure.

On Sun, 2013-12-15 at 21:44 -0500, Alan Stern wrote: On Sun, 15 Dec 2013, James Bottomley wrote: No, I was thinking of the two thread scan bug (i.e. two scan threads) not one scan and one remove, which is a bug in the old code. This is a race between put and get when the kref

Re: [RFC] fix our current target reap infrastructure.

On Sun, 2013-12-15 at 21:49 -0500, Alan Stern wrote: On Sun, 15 Dec 2013, James Bottomley wrote: No, I was thinking of the two thread scan bug (i.e. two scan threads) not one scan and one remove, which is a bug in the old code. By the way, the existing code doesn't allow two threads

Re: [RFC] fix our current target reap infrastructure.

On Fri, 2013-12-13 at 22:32 -0500, Alan Stern wrote: On Fri, 13 Dec 2013, James Bottomley wrote: This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap

Re: [usb-storage] UAS hangs khubd on USB disconnect

On Fri, 2013-12-13 at 13:33 -0500, Tejun Heo wrote: Hello, guys. (cc'ing Greg) On Fri, Dec 13, 2013 at 01:19:36PM -0500, Alan Stern wrote: On Fri, 13 Dec 2013, Sarah Sharp wrote: Given the way things work now, I suspect these warnings are truly harmless. We could simply get

Re: [usb-storage] UAS hangs khubd on USB disconnect

On Fri, 2013-12-13 at 11:18 -0800, James Bottomley wrote: On Fri, 2013-12-13 at 13:33 -0500, Tejun Heo wrote: Hello, guys. (cc'ing Greg) On Fri, Dec 13, 2013 at 01:19:36PM -0500, Alan Stern wrote: On Fri, 13 Dec 2013, Sarah Sharp wrote: Given the way things work now, I

Re: [usb-storage] UAS hangs khubd on USB disconnect

On Fri, 2013-12-13 at 16:06 -0500, Alan Stern wrote: On Fri, 13 Dec 2013, James Bottomley wrote: Actually, I think I have this figured out. There's a thinko in one of the scsi_target_reap() cases. The original (and still existing) problem with targets is that nothing creates them

Re: [usb-storage] UAS hangs khubd on USB disconnect

On Fri, 2013-12-13 at 19:48 -0500, Alan Stern wrote: On Fri, 13 Dec 2013, James Bottomley wrote: On Fri, 2013-12-13 at 16:06 -0500, Alan Stern wrote: On Fri, 13 Dec 2013, James Bottomley wrote: Actually, I think I have this figured out. There's a thinko in one

[RFC] fix our current target reap infrastructure.

This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap() for the device is done from __scsi_remove_device() and only if the device was made visible. This ensures that the

Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives

On Fri, 2012-11-09 at 16:33 +, Elliott, Robert (Server Storage) wrote: I recommend broadening this patch. T10 is discussing making READ (10), WRITE (10), etc. obsolete in SBC-4 in favor of their 16-byte CDB counterparts. The algorithm should be: 1. During discovery, determine if

Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives

On Fri, 2012-11-09 at 11:08 -0500, Jason J. Herne wrote: diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index 13b8bcd..6ff785e 100644 --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -251,6 +251,11 @@ static int slave_configure(struct

Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives

On Mon, 2012-11-12 at 15:31 +0100, Paolo Bonzini wrote: Il 12/11/2012 12:33, James Bottomley ha scritto: On Fri, 2012-11-09 at 11:08 -0500, Jason J. Herne wrote: diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index 13b8bcd..6ff785e 100644 --- a/drivers/usb

Re: [PATCH] USB enclosures seem to require read(16) with 2TB drives

On Mon, 2012-11-12 at 10:01 -0500, Jason J. Herne wrote: Any reason not to do this always on 2TB drives, which basically means changing this: - } else if (block 0x) { + } else if (sdkp-capacity 0x) { and nothing else? This was the intent of my patch,

Re: [PATCH] bugfix for an underflow condition in usb storage isd200.c

On Wed, 2008-02-06 at 17:18 -0500, Alan Stern wrote: On Wed, 6 Feb 2008, Matthew Dharm wrote: Maybe this is a crazy question, but... Why is this not in the SCSI core? Or even in the block core? It's hardly USB-specific, and I'm willing to bet that there are other HCDs (at

Re: [PATCH] bugfix for an underflow condition in usb storage isd200.c

On Wed, 2008-02-06 at 18:25 -0500, Alan Stern wrote: On Wed, 6 Feb 2008, James Bottomley wrote: What we're talking about is a routine that provides drivers a simple way to access the data in a scatter-gather buffer (which may lie in highmem or otherwise not be easily reachable

Re: [BUG] 2.6.24-git usb reset problems

On Wed, 2008-01-30 at 11:38 +0100, Jens Axboe wrote: On Wed, Jan 30 2008, Geert Uytterhoeven wrote: On Tue, 29 Jan 2008, Jens Axboe wrote: On Tue, Jan 29 2008, Jens Axboe wrote: On Tue, Jan 29 2008, James Bottomley wrote: On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote

Re: [BUG] 2.6.24-git usb reset problems

On Tue, 2008-01-29 at 20:58 +0200, Boaz Harrosh wrote: Your new code does int partial; - stack uninitialised sb_stor_bulk_transfer_sglist(..., partial, ...); scsi_set_resid(srb, scsi_bufflen(srb) - partial); If the function doesn't touch partial, as it doesn't in the error legs,

Re: [BUG] 2.6.24-git usb reset problems

On Tue, 2008-01-29 at 21:06 +0100, Jens Axboe wrote: I will ... but it will cause an explosion in the bidirectional tree again. I think the bidi updates also fix this. However, give me time to rebase and verify. OK thanks, just wanted to make sure that we didn't both expect each other

Re: [BUG] 2.6.24-git usb reset problems

On Tue, 2008-01-29 at 20:27 +0200, Boaz Harrosh wrote: On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley [EMAIL PROTECTED] wrote: On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote: On Tue, 29 Jan 2008, Boaz Harrosh wrote: --- a/drivers/usb/storage/transport.c +++ b/drivers/usb

  1   2   >