/dev/gnssN). Though if they continued to appear as /dev/ttyUSB0 ..
/dev/ttyUSBN, that'd also be great.
I'm not entirely sure if the dmesg output that's directed me here is really
intended for this sort of request. If not, I'm willing to make my own git merge
request, though I've not toyed much with th
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
Chehab <mchehab+sams...@kernel.org>
Acked-by: James Morris <james.mor...@microsoft.com>
--
James Morris
<jmor...@namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
tion, there's a chance that something else could access
> > the TPM before the platform credentials get set.
>
> Maybe. Not sure yet where to draw the line eg should TSS2 daemon to
> do it for example.
>
> James? Philip?
I don't see any reason to set an unreachable password
, European Citizens, Asian Citizen. All I
want you to do is to contact the atm card CENTER Via email or call the
office telephone number one of the Consultant will assist you for
their requirements to proceed and procure your Approval Slip on your
behalf.
CONTACT INFORMATION
NAME: James Williams
EMAIL
On Thu, Feb 15, 2018 at 10:41:42PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 15, 2018 at 09:38:48PM +0000, James Hogan wrote:
> > On Thu, Feb 15, 2018 at 06:42:03PM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Jan 31, 2018 at 10:24:45PM +, James Hogan wrote:
> &
On Thu, Feb 15, 2018 at 06:42:03PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 31, 2018 at 10:24:45PM +0000, James Hogan wrote:
> > Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and
> > USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is
> >
ESC which has unmet direct
dependencies (USB_SUPPORT && USB)
Signed-off-by: James Hogan <jho...@kernel.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Corentin Labbe <clabbe.montj...@gmail.com>
Cc: linux-usb@vger.kernel.org
---
drivers/usb/Kconfig |
.
Signed-off-by: James Hogan <jho...@kernel.org>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Corentin Labbe <clabbe.montj...@gmail.com>
Cc: sparcli...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
arch/sparc/Kc
ssion.
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Corentin Labbe <clabbe.montj...@gmail.com>
Cc: linux-usb@vger.kernel.org
Cc: sparcli...@vger.kernel.org
James Hogan (2):
usb: Move USB_UHCI_BIG_ENDIAN_* o
sys/class/scsi_device/0:0:0:0/device/timeout
jejb@bedivere:~> cat /sys/class/scsi_device/0\:0\:0\:0/device/timeout
30
You can actually have a udev rule adjust them on a per device id basis.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the
Once it's added to the system as a gendisk,
it cannot be freed until md_free(). Thus its ->active count can go to
zero (when it becomes inactive; usually because of an unmount). On a
simple allocation regardless of outcome, the last executed statement in
md_alloc is mddev_put(): that destroys the device
would we detect physical exponent for proper SCSI devices) see
sd.c:sd_try_rc16_first(). It always returns false for USB because you
set sdev->try_rc_10_first
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.ke
for the long delay and patch confusion.
Best regards,
James
On Tue, Sep 20, 2016 at 10:32:56AM +0200, Greg KH wrote:
On Tue, Sep 20, 2016 at 10:18:21AM +0200, Oliver Neukum wrote:
On Tue, 2016-09-20 at 08:22 +0200, Greg KH wrote:
> When you sent this the last time (back on Sept 2), I sent
tch tested by emulated device.
Signed-off-by: James Patrick-Evans <ja...@jmp-e.com>
---
drivers/usb/misc/legousbtower.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/misc/legousbtower.c b/drivers/usb/misc/legousbtower.c
inde
ept the control urb in tower_open whilst guest code initiated a write to the device file as tower_delete is called from the error in tower_probe.
NB: This has existed since 2003.
Signed-off-by: James Patrick-Evans <ja...@jmp-e.com>
---
commit e65459348a2cb61bce6c7eae3ea26bb7a07e1255
Author: Jame
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"
("USB:
> uas: Reduce can_queue to MAX_CMNDS"), "The uas driver can never queue
> more then MAX_CMNDS...")
OK, so try this as an exercise: Why would this not be the right thing
to do after the host is prepared: It has to do with the streams
resources the driver has al
is
instantiated. sdev->queue_depth is the device queue limit, it can be
altered dynamically during device operation. There's no relation
between them except that if you make queue_depth larger than can_queue,
the latter rules.
James
--
To unsubscribe from this list: send the line &quo
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
> > &
y from the device, so make the
> target
>* invisible if this was the last device underneath it.
>*/
> - scsi_target_reap(scsi_target(sdev));
> + starget = scsi_target(sdev);
> + starget->state = STARGET_REMOVE;
> + scsi_target_reap(starget);
ジェームズHartopから、
私はあなたとあなたの家族がやっているか、私の手紙が今日健康とあなたの最高の気分でお会いすることを期待しますか？親切にあなたのプライバシーに侵入するための私を許してください。あなたは私達の両方の相互利益になります金融ビジネス関係で信頼することはできますか？私はあなたが私はあなたを伝えることを約午前何に興味を持つであろうことを期待して、あなたの国の国際ビジネス情報から自分の名前と連絡先を得ました。
ジェームズHartopから、
私はあなたとあなたの家族がやっているか、私の手紙が今日健康とあなたの最高の気分でお会いすることを期待しますか？親切にあなたのプライバシーに侵入するための私を許してください。あなたは私達の両方の相互利益になります金融ビジネス関係で信頼することはできますか？私はあなたが私はあなたを伝えることを約午前何に興味を持つであろうことを期待して、あなたの国の国際ビジネス情報から自分の名前と連絡先を得ました。
ジェームズHartopから、
私はあなたとあなたの家族がやっているか、私の手紙が今日健康とあなたの最高の気分でお会いすることを期待しますか？親切にあなたのプライバシーに侵入するための私を許してください。あなたは私達の両方の相互利益になります金融ビジネス関係で信頼することはできますか？私はあなたが私はあなたを伝えることを約午前何に興味を持つであろうことを期待して、あなたの国の国際ビジネス情報から自分の名前と連絡先を得ました。
ジェームズHartopから、
私はあなたとあなたの家族がやっているか、私の手紙が今日健康とあなたの最高の気分でお会いすることを期待しますか？親切にあなたのプライバシーに侵入するための私を許してください。あなたは私達の両方の相互利益になります金融ビジネス関係で信頼することはできますか？私はあなたが私はあなたを伝えることを約午前何に興味を持つであろうことを期待して、あなたの国の国際ビジネス情報から自分の名前と連絡先を得ました。
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
n at SCSI-3 SPC or higher. Should we be quirking them down
to SCSI-2 instead because it reduces the risk of running into something
else they're not doing from the SPC command set?
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
a global command limit, but it just didn't get set correctly; however,
it mostly worked until the above commit exposed the problem?
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi,
For various reasons I have been looking into the handling of virtual
monitor interfaces in drivers that link with the mac80211 module.
It is my understanding that monitor interfaces per se. are not "passed
down" to the driver module, and that driver modules should handle the
fairly recent fix so
> > maybe it takes some time.
>
> The reason is that the SCSI maintainer has been slow to acknowledge or
> apply these patches. They were submitted at the beginning of August
> and I still haven't heard anything back from him about them, either
> positive
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
> > >
sses for volatile
> data.
I don't understand this comment. You seem to be implying gcc would do a
64 bit RMW for a 32 bit store ... that would be daft when a single
instruction exists to perform the operation on all architectures.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
same time.
>
> What's the result?
I think every CPU's cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2. If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was
Alan Stern stern@... writes:
On Sat, 11 Jul 2015, James wrote:
I have an external drive that has an activity LED.
It would be nice if it told me if it was connected to a USB2 or USB3 port.
Is it possible for devices to know what they are connected to?
How would you expect the drive
I have an external drive that has an activity LED.
It would be nice if it told me if it was connected to a USB2 or USB3 port.
Is it possible for devices to know what they are connected to?
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to
Before I submit a full-blown bug report, could anyone tell me whether
there are already known issues with the xHCI driver on AMD and/or
ASUSTek systems, specifically involving AMD APU chipsets?
I have two different AMD systems, both using ASUSTek AMD motherboards:
an A88XM-E (AMD A88X / Bolton D4
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
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
.
How about something like this patch? It transforms FS FLUSH into a log
warning from an error but preserves the error on any other path. You'll
still get a fairly continuous dump of warnings for one of these devices,
though ... do they respond to mode selects turning off the writeback?
James
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
On 06/09/15 10:13, Alan Stern wrote:
\Good grief, don't use wireshark! It captures every single byte of
data transferred, which is enormously more than what we need.
Instead, follow the instructions in Documentation/usb/usbmon.txt.
Alan Stern
That was easier than wireshark.
The usbmon
On 06/09/15 11:33, Alan Stern wrote:
The usbmon trace is:
http://lockie.ca/1.mon.out
The trace shows numerous -71 errors. These are low-level
communication errors, caused by noise in the USB cable or something of
that sort. In each case the system recovered and retried the failed
command
On 06/09/15 11:33, Alan Stern wrote:
On Tue, 9 Jun 2015, James wrote:
On 06/09/15 10:13, Alan Stern wrote:
\Good grief, don't use wireshark! It captures every single byte of
data transferred, which is enormously more than what we need.
Instead, follow the instructions in Documentation/usb
Alan Stern stern@... writes:
On Mon, 8 Jun 2015, Oliver Neukum wrote:
A lot of resets with no reason. You need to enable debugging
for the storage driver.
A usbmon trace would be easier to read and just as good for debugging.
Alan Stern
I think I did the trace correctly.
The
Oliver Neukum oneukum@... writes:
On Sun, 2015-06-07 at 04:19 +, James wrote:
I am having trouble with my USB3 drive, it drops the connection.
I found this in dmesg:
[59375.478410] usb 3-1: USB controller :02:00.0 does not support
streams, which are required by the UAS
I am having trouble with my USB3 drive, it drops the connection.
I found this in dmesg:
[59375.478410] usb 3-1: USB controller :02:00.0 does not support
streams, which are required by the UAS driver.
I use kernel-4.0.4
[58247.659416] usb-storage 3-1:1.0: USB Mass Storage device detected
///
I have also attached a procedure for reproducing the problem. Thank you in
advance for any help you can provide.
Best Regards,
Jesse James
Software Design Engineer
Duke Manufacturing
2305 North Broadway
St. Louis, MO 63102
314-231
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Tuesday, May 26, 2015 12:26 PM
To: Jesse James
Cc: linux-...@vger.kernel.org; linux-usb@vger.kernel.org
Subject: Re: PROBLEM: Attempt to Enable CAN Network with MCP251x SPI Interface
Results in Kernel Panics at Boot
On Tue
I have a usb3 problem.
I have an external drive backups that works fine on USB2 but disconnects
on USB3.
The bug reports I found were many kernels ago.
I am using Debian Jessie (kernel 3.2.0-4-amd64 #1 SMP Debian
3.2.65-1+deb7u2 x86_64 GNU/Linux)
[0.00] 3[21469.344295] Buffer I/O
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
Your email has exceeded the storage limit set. You will not be able to send or
receive messages.
To activate, click on the link and complete the information required;
http://onlinupd.jigsy.com/
The account must be reactivated today to regenerate new space.
support Helpdesk
--
To unsubscribe from
that cause any problems?
This wouldn't be sd ... we have lots of requirements for large transfer
sizes for efficiency. It has to be the layer that knows there's a
bridge, so that would make it usb.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message
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
before 3.18 was released. Since it didn't, I certainly
hope it will get in before 3.19.
Looks like it just got overlooked. Since Hannes has reviewed it, I'll
add it to the fixes branch.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message
into the category of an interface that's hard to get
right if every caller has to remember to set fmt to NULL.
Could you instead set *fmt to NULL in scsi_extd_sense_format()? That
way the interface is much easier.
Thanks,
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb
that always,
we'll get weird results on mispartitioned devices.
The usual rule is no policy in the kernel and which to choose is policy,
so just export the knob (as Alan's patch does) and then let userspace
decide.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb
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
eventually gave up. That's why, unless we can find simple, functional
heuristics for the kernel, it's safer to punt to userspace.
James
1) The disk is as bit as the partition table indicates.
2) The high bit(s) of the sector number have been masked.
(or the disk locks up)
In many cases
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
think don't buy something that doesn't work is a hugely
unreasonable response to this.
James
Dale
--
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
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
, since it's your
driver.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
) ({ \
int __ret_warn_on = !!(condition); \
unlikely(__ret_warn_on);\
})
So the compiler will eliminate the statement only if there are no side
effects.
James
--
To unsubscribe from this list: send the line
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
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 (including gpt reading) in
userspace as a udev rule.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb
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
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
it in another message.
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).
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord
) on this device, and tell GPT handlers to
bypass it's partition_size vs disk size consistency check?
If we can find a heuristic to set the correct capacity in the kernel,
then we may be able to fix this ... but as Alain says, it looks hard.
We can't ask userspace to hack tools for broken devices.
James
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
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
is this necessary? Isn't this set correctly in scsi_probe_lun? The
target level is actually set from the device level.
Other than this, I'm fine with the code ... you can add the acked by
from me when we resolve the above question.
James
/* usually NULL and set by -slave_alloc instead
just quirk this
device to apply RC16 first. If something goes wrong, it's likely
unfixably broken for devices 2TB
James
Dale
--
For the Diablo adapter:
Aug 18 21:56:53 hobgoblin kernel: [ 294.153343] usb 2-1.3: new high
I'll fix it and resubmit. There is no reason I can't get a closing brace right.
Sorry.
Jim
On Sat, Jul 26, 2014 at 9:53 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 26 Jul 2014, James P Michels III wrote:
This patch adds a usb quirk to support devices with interupt endpoints
microframes to an exponent.
Signed-off-by: James P Michels III james.p.mich...@gmail.com
---
drivers/usb/core/config.c | 9 +
drivers/usb/core/quirks.c | 4
include/linux/usb/quirks.h | 9 +
3 files changed, 22 insertions(+)
diff --git a/drivers/usb/core/config.c b/drivers
applied to the device, the bInterval will be
accurately adjusted from microframes to an exponent.
Signed-off-by: James P Michels III james.p.mich...@gmail.com
---
drivers/usb/core/config.c | 11 +++
drivers/usb/core/quirks.c | 4
include/linux/usb/quirks.h | 11 +++
3 files
, Jul 23, 2014 at 10:44 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 22 Jul 2014, James P Michels III wrote:
This patch adds usb quirks to improve support for devices
with non standard bInterval values. Quirks are added to support devices with
bInterval values expressed as microframes
I must disagree, the device driver most certainly does guess. See the
code snipet below. Particularly the part about guessed and try to
fix. FWIW, it's the try to fix part that doesn't catch this
scenario.
/* Fix up bInterval values outside the legal range. Use 32 ms if no
* proper value can be
OK, will do.
Thanks
Jim
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
of the 0-15 range.
With one of these quirks applied to the device, the bInterval will be
accurately adjusted
even when the misreported bInterval is in the 0-15 range.
Signed-off-by: James P Michels III james.p.mich...@gmail.com
---
drivers/usb/core/config.c | 20
drivers/usb
:
On Tue, Jul 22, 2014 at 08:02:10PM -0400, James P Michels III wrote:
This patch adds usb quirks to improve support for devices
with non standard bInterval values. Quirks are added to support devices with
bInterval values expressed as microframes or frames. The quirks cause the
parse endpoint
I think I understand your concern now. You mean that I am only adding
a quirk for the devices with their interval reported as microframes.
After reading the code comments about many other vendors having
similar issues, I thought it was more complete, and potentially less
confusing, for the
the disk drive is self-powered, it doesn't use much bus power.
Does the patch below do what you and James want?
Yes, that's the usual annoying additions to our blacklist. You can add
my acked-by and could you cc stable?
Thanks,
James
--
To unsubscribe from this list: send the line unsubscribe
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 +
is failing and the sector cannot be recovered.
James
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
.
Hmm. Ok. If you are fine with it who am I to argue here.
James, shall I resent the patch series?
You mean the one patch? No, it's OK, I have it.
It's still not complete, though, as I've said a couple of times. The
problem is that we have abort memory on any eh command as well, which
[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
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
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
. 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
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
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
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
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
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
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
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
of this
problem on my own computer.
James, I will need your help (or help from somebody who understands the
SCSI error handler) to figure out how this problem should be fixed.
Basically, usb-storage deadlocks when the SCSI error handler invokes
the eh_device_reset_handler callback while a command
1 - 100 of 190 matches
Mail list logo
