3. Patch tested by emulated device.
Signed-off-by: James Patrick-Evans
---
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
index 7771be3..4dd531
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 yo
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
---
commit e65459348a2cb61bce6c7eae3ea26bb7a07e1255
Author: James Patrick-Evans
D
I have 3.5.0+
How can I find out what the problem is with my USB UPS?
It noticeably slows down booting.
This happened on my previous motherboard so I wouldn't be surprised if the UPS
doesn't follow the USB spec exactly.
dmesgs:
--
after boot
--
usb 4-1: new low-speed USB device n
On 07/29/12 10:50, Alan Stern wrote:
> On Sun, 29 Jul 2012, James wrote:
>
>> I have 3.5.0+
>> How can I find out what the problem is with my USB UPS?
>
> Your logs indicate that the UPS repeatedly disconnects from and
> reconnects to the USB bus. At least, that&#
On 07/29/12 17:36, Alan Stern wrote:
> On Sun, 29 Jul 2012, James wrote:
>
>>>> It noticeably slows down booting.
>>>
>>> It shouldn't interfere appreciably with booting, unless you're waiting
>>> for some other USB device to be detect
On 08/01/12 13:14, Alan Stern wrote:
> On Wed, 1 Aug 2012 bjloc...@lockie.ca wrote:
>
>>> That's progress. Have you checked to see whether ehci-hcd is loaded
>>> before or after ohci-hcd?
>>
>> Is there a way to tell besides watching the screen (which scrolls too
>> fast) during boot?
>
> Run th
On 08/01/12 13:14, Alan Stern wrote:
> On Wed, 1 Aug 2012 bjloc...@lockie.ca wrote:
>
>>> That's progress. Have you checked to see whether ehci-hcd is loaded
>>> before or after ohci-hcd?
>>
>> Is there a way to tell besides watching the screen (which scrolls too
>> fast) during boot?
>
> Run th
On 08/04/12 13:21, Alan Stern wrote:
> On Sat, 4 Aug 2012, James wrote:
>
>> Maybe the pause is not USB.
>> [2.243856] usb 4-1: Manufacturer: Logitech
>> [ 62.739097] cx25840 6-0044: unable to open firmware
>> v4l-cx23885-avcore-01.fw
>
> Yeah, that l
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 majord..
Alan 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?
&g
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 er
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
[5
Oliver Neukum 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
> &
Alan 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 gzippe
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 t
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 suc
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 Documentatio
Is usb9-port3 from dmesg the same as Bus 009 Device 003 from lsusb?
usb usb9-port3: Cannot enable. Maybe the USB cable is bad?
Bus 009 Device 001:
On 2019-01-27 9:21 p.m., Alan Stern wrote:
On Sun, 27 Jan 2019, James wrote:
Is usb9-port3 from dmesg the same as Bus 009 Device 003 from lsusb?
No; usb9-port3 is port number 3 on the usb9 host controller's root hub,
whereas Bus 009 Device 003 is the third device on usb9's bus. Th
e altered after the host 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
c4e1 ("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 h
can't be issued (it's very similar to
why bufferbloat is a problem in networks). In theory, as long as your
devices return the correct indicator (QUEUE_FULL status), we'll handle
most of this in the mid-layer by plugging the block queue, but given
what I've seen from UAS devices,
drivers/usb/storage/uas.c?h=v4.6#n908
OK, you found the statement, now translate what it means to resource
allocation and it will show you why the if you proposed to add would
always be true.
James
> In that case should I send another patch that simply has `.can_queue
> =
> MAX_CMNDS`
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"
else 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...@vg
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
IEEE80211_CO
lobal 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
ing in 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
th
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 of:
ジェームズHartopから、
私はあなたとあなたの家族がやっているか、私の手紙が今日健康とあなたの最高の気分でお会いすることを期待しますか？親切にあなたのプライバシーに侵入するための私を許してください。あなたは私達の両方の相互利益になります金融ビジネス関係で信頼することはできますか？私はあなたが私はあなたを伝えることを約午前何に興味を持つであろうことを期待して、あなたの国の国際ビジネス情報から自分の名前と連絡先を得ました。
私はここイギリスでHarlesdenからジェームズ・ウィリアムHartop、北西ロンドン、と思います。私は、UBS銀行、ロンドンのために働きます。私は私達の両方に莫大
ice, 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);
How abo
> > > > > > > > >
> > > > > > > > > > Change to kernel 4.4.x or 4.5 and RAID 5 doesnt
> > > > > > > > > > work. I am not sure whether
> > > > > > > > > > its actually RAID 5 at fault
mes 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 if we didn't manage
to create it or returns 0 and adds an inactive device to the system
which the user can get with mddev_find().
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
it is dangerous after testing several USB HDD. some of
> > HDD is stalled by this command(A-DATA HDD). So we tried to make the
> > patch James Bottomley's suggestion(usb quirk) on version 2 that add
> > product ID and verdor ID of USB HDD to USB quirk list after checking
&g
On Thu, Jul 4, 2013 at 4:19 PM, Alan Stern wrote:
>
> On Thu, 4 Jul 2013, James Stone wrote:
>
> > Apologies - I realised I hadn't also applied the 1ms usb patch. With that
> > applied, it will start OK at 256, but not at 128 frames/period. (on earlier
> > kernels
On Thu, Jul 4, 2013 at 9:12 PM, Alan Stern wrote:
> On Thu, 4 Jul 2013, James Stone wrote:
>
>> > Another hint: The important lines are the ones containing "Zi:1:002:2"
>> > -- the actual string may be slightly different, but it will definitely
>> > con
On Thu, Jul 4, 2013 at 10:13 PM, Alan Stern wrote:
> On Thu, 4 Jul 2013, James Stone wrote:
>
>> OK.. How is this:
>>
>> -71:63:0 -71:126:0 -71:189:0 -71:252:0 504 =
>>
>
> To all appearanc
On Fri, Jul 5, 2013 at 3:31 AM, Alan Stern wrote:
> On Thu, 4 Jul 2013, James Stone wrote:
>
>> > Can you post the part of the trace showing where the audio-in Zi lines
>> > first appear?
>> >
>>
>> I think this is the start of the Zi lines:
>&
re were no I/O errors.
>> [...]
>> I can't tell whether all these starts and stops are caused by JACK or
>> by the ALSA layer, let alone figure out the reason for them.
>
> Two URBs is the Jack buffer size, isn't it? Does Jack complain?
>
> James, pleasy try runn
On Sat, Jul 6, 2013 at 10:36 AM, James Stone wrote:
> On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch wrote:
>> Alan Stern wrote:
>>> The first half is audio-out only. About 2 seconds after the start, the
>>> audio-in stream starts up. After 2 URBs (2 ms) of data,
On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern wrote:
> On Sat, 6 Jul 2013, James Stone wrote:
>
>> The output when I try to start jack with 128 frames/period is:
>>
>> /usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 -O512
>> -S
>> jackdmp
On Sat, Jul 6, 2013 at 9:36 PM, James Stone wrote:
> On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern wrote:
>> On Sat, 6 Jul 2013, James Stone wrote:
>>
>>> The output when I try to start jack with 128 frames/period is:
>>>
>>> /usr/bin/jackd -dalsa -r4410
On Sat, Jul 6, 2013 at 9:39 PM, James Stone wrote:
> On Sat, Jul 6, 2013 at 9:36 PM, James Stone wrote:
>> On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern wrote:
>>> On Sat, 6 Jul 2013, James Stone wrote:
>>>
>>>> The output when I try to start jack with 1
Hi Clemens,
On Mon, Jul 8, 2013 at 2:12 PM, James Stone wrote:
>> Acquire audio card Audio0
>> creating alsa driver ... hw:USB,0|-|64|2|44100|0|0|nomon|swmeter|-|16bit
>> Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4
>> USB at usb-00
races provided during
> earlier testing. For example, this one
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3714903/+files/1.mon.out
>
> shows the output stream starting at timestamp 3752849102 and the input
> stream starting at timestamp 3753752104, a
On Tue, Jul 16, 2013 at 7:36 PM, Alan Stern wrote:
> On Mon, 15 Jul 2013, James Stone wrote:
>
>> >> James, did you ever provide a usbmon trace for 3.8 doing playback only
>> >> and using 64 frames/period? I don't recall seeing any. It might help.
>>
On Wed, Jul 17, 2013 at 3:59 PM, Alan Stern wrote:
> On Tue, 16 Jul 2013, James Stone wrote:
>
>> Thanks. The patch allows jack to now start at (playback only) 64
>> frames/period. It doesn't work with 32 frames/period though (I think
>> you predicted this). This is
device in 3.5 at
256 frames/period (duplex), the lights flash on and off 2 times, in
the current patched 3.8 version I have been using, the device lights
flash on and off 4 times before starting jack with exactly the same
settings - so it seems for some reason, the requests are going through
multiple times on the 3.8 kernel but not on 3.5. I will send a 3.5
usbmon trace of a successful start off list (plus the same for 3.8?)
if it would be useful.
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 Fri, Jul 19, 2013 at 4:17 PM, Alan Stern wrote:
> On Fri, 19 Jul 2013, James Stone wrote:
>
>> > The questions now are:
>> >
>> > Why are the same requests sent over and over again?
>> >
>> > Why does the ALSA driver attemp
On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge wrote:
> On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote:
>> On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern
>> wrote:
>> > On Fri, 19 Jul 2013, James Stone wrote:
>> >
>> >> > The questions n
On Wed, Jul 24, 2013 at 12:23 AM, James Stone wrote:
> On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge wrote:
>> On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote:
>>> On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern
>>> wrote:
>>> >
On Wed, Jul 24, 2013 at 2:42 AM, James Stone wrote:
> On Wed, Jul 24, 2013 at 12:23 AM, James Stone wrote:
>> On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge wrote:
>>> On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote:
>>>> On Fri, Jul 19, 2013 at 4:
On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch wrote:
> James Stone wrote:
>> Ok -from the bisect, the problem of not being able to get to sub
>> 64-frames per period starts with:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/stable/
On Thu, Jul 25, 2013 at 4:29 PM, Alan Stern wrote:
> On Thu, 25 Jul 2013, James Stone wrote:
>
>> On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch wrote:
>> > James Stone wrote:
>> >> Ok -from the bisect, the problem of not being able to get to sub
>&
On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern wrote:
> On Thu, 25 Jul 2013, James Stone wrote:
>
>> > Please try the patch from here:
>> >
>> > http://marc.info/?l=linux-usb&m=137476385206265&w=2
>> >
>> > instead of the one I se
On Thu, Jul 25, 2013 at 10:24 PM, Alan Stern wrote:
> On Thu, 25 Jul 2013, James Stone wrote:
>
>> On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern
>> wrote:
>> > On Thu, 25 Jul 2013, James Stone wrote:
>> >
>> >> > Please try the patch from here
;dma_free_coherent'
drivers/usb/host/xhci-mem.c In function 'xhci_alloc_stream_ctx':
drivers/usb/host/xhci-mem.c +463 : error: implicit declaration of function
'dma_alloc_coherent'
Signed-off-by: James Hogan
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: S
On Fri, Jul 26, 2013 at 11:46 PM, James Stone wrote:
> On Fri, Jul 26, 2013 at 11:43 PM, James Stone wrote:
>> On Fri, Jul 26, 2013 at 7:54 PM, Alan Stern
>> wrote:
>>> On Fri, 26 Jul 2013, Clemens Ladisch wrote:
>>>
>>>> Alan Stern wrote:
On Sat, Jul 27, 2013 at 6:45 PM, Alan Stern wrote:
> On Sat, 27 Jul 2013, James Stone wrote:
>
>> OK. So this seems to have solved the starting jack at low latencies
>> problem, but I am still getting sporadic cannot submit urb (err = -18)
>> under normal use. Will try
On Mon, Jul 29, 2013 at 4:25 PM, Alan Stern wrote:
> On Sun, 28 Jul 2013, James Stone wrote:
>
>> On Sat, Jul 27, 2013 at 6:45 PM, Alan Stern
>> wrote:
>> > On Sat, 27 Jul 2013, James Stone wrote:
>> >
>> >> OK. So this seems to have solved the s
On Mon, Jul 29, 2013 at 9:41 PM, James Stone wrote:
> On Mon, Jul 29, 2013 at 4:25 PM, Alan Stern wrote:
>> On Sun, 28 Jul 2013, James Stone wrote:
>>
>>> On Sat, Jul 27, 2013 at 6:45 PM, Alan Stern
>>> wrote:
>>> > On Sat, 27 Jul 2013, James Stone
write a patch to handle this. It may take a few
>> days.
>
> James, see what happens with this patch. It will print a warning
> message in the system log every time it detects an underrun, but it
> won't cause an URB submission failure any more.
>
OK - I will try it, h
On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern wrote:
> On Wed, 31 Jul 2013, James Stone wrote:
>
>> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern
>> wrote:
>> > On Tue, 30 Jul 2013, Alan Stern wrote:
>> >
>> >> I can try to ameliorate the situation
On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern wrote:
> On Wed, 31 Jul 2013, James Stone wrote:
>
>> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern
>> wrote:
>> > On Tue, 30 Jul 2013, Alan Stern wrote:
>> >
>> >> I can try to ameliorate the situation
On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern wrote:
> On Thu, 1 Aug 2013, James Stone wrote:
>
>> > SMIs are controlled by the BIOS, not by the kernel. I don't think
>> > changing the kernel would affect their timings.
>> >
>>
>> Hmm.. ok. So do I
On Fri, Aug 2, 2013 at 8:49 AM, James Stone wrote:
> On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern wrote:
>> On Thu, 1 Aug 2013, James Stone wrote:
>>
>>> > SMIs are controlled by the BIOS, not by the kernel. I don't think
>>> > changing the kernel w
On Fri, Aug 2, 2013 at 8:02 PM, James Stone wrote:
> On Fri, Aug 2, 2013 at 8:49 AM, James Stone wrote:
>> On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern wrote:
>>> On Thu, 1 Aug 2013, James Stone wrote:
>>>
>>>> > SMIs are controlled by the BIOS, not by
On Fri, Aug 2, 2013 at 8:40 PM, Alan Stern wrote:
> On Fri, 2 Aug 2013, James Stone wrote:
>
>> >>>> > Okay, so the USB controllers do share IRQ lines. Were you using the
>> >>>> > other USB buses when the errors occurred?
>> >>>&g
On Sat, Aug 3, 2013 at 11:30 PM, James Stone wrote:
>
> On Aug 3, 2013 9:28 PM, "Alan Stern" wrote:
>>
>> On Fri, 2 Aug 2013, James Stone wrote:
>>
>> > > OK - here's a trace with all patches applied. It didn't occur when
>> >
t the hardware never sees it. Consequently there
> is no completion interrupt until URB2 finishes, at which point the
> queue is empty, causing a secondary underrun. I actually saw this
> happen several times during testing.
>
> James, this patch should be tested along with Clemens's
er of samples per packet identical to the
>> corresponding capture packet, so the parameters must be identical.
>
> Got it. Below is an updated patch.
>
> James, the problem you encountered was most likely a result of the
> faulty treatment of capture endpoints that Clemens point
At 32 frames/period (reported round-trip latency 1.33ms), it starts up
but there are too many xruns for it to be usable.
James
On Thu, Aug 29, 2013 at 4:00 PM, Alan Stern wrote:
> On Thu, 29 Aug 2013, James Stone wrote:
>
>> On Wed, Aug 28, 2013 at 7:46 PM, Alan Stern
>>
ve to assume the most extreme case, so using a spinlock around
the two 4 byte writes to ensure atomicity, which would be a killer for
performance.
> I would think so, but I really don't know.
>
> linux-arch people, what do we do about architectures that don't provide
> these
must support all devices (which
means the older ones as well), including the annoying USB ones which
crash on unexpected commands, you can see that d) is about the only
viable option.
We can also force RC16 if the capacity is over 2^32 blocks, because the
command will be required, so that'
* because we did a bus reset. */
> unsigned use_10_for_rw:1; /* first try 10-byte read / write */
> unsigned use_10_for_ms:1; /* first try 10-byte mode
> sense/select */
> + unsigned force_read_16:1; /* Use read(16) over read(10) */
This should probably
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
> &g
here's a subtlety here: block is in units of the disk sector size,
sdkp->capacity is in units of 512 bytes (the linux native sector size),
so it would need shifting before doing the determination.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" i
Hi,
I apologize if this is slightly OT, but I am in need of help from some
USB gurus. I am trying to analyse a problem with (my) Garmin nuvi GPS
units attached to an Ubuntu 12.04 system running Windows (both XP and
Windows 8 exhibit the same problem) inside VirtualBox.
The unit should eventu
On 22/03/13 19:59, Alan Stern wrote:
On Fri, 22 Mar 2013, Alan Stern wrote:
On Fri, 22 Mar 2013, Roger James wrote:
Hi,
I apologize if this is slightly OT, but I am in need of help from some
USB gurus. I am trying to analyse a problem with (my) Garmin nuvi GPS
units attached to an Ubuntu
On 22/03/13 20:47, Roger James wrote:
I will make a pair of host linux and a guest windows traces that refer
to the same run. However I do not think they will show anything
different from the slightly unmatched pair I have already posted.
Here is the is the new pair on dropbox
https
On 22/03/13 21:31, Alan Stern wrote:
On Fri, 22 Mar 2013, Roger James wrote:
Sorry Alan,
My bad. I stuck a binary file on pastebin by mistake.
It is a binary wireshark trace (I think that is pcap). Here it is via
dropbox
https://dl.dropbox.com/u/84613021/wireshark.log
I will make a pair
13 STAINES MIDDLESEX?TW184TP
??LONDON.UNITED?
?564-756-545-188
S/N-0088168
?BTL/491OXI/04
??
???
FPS???
2013?4???
???
1,000,000,000??
??
se warnings are truly
> > > > harmless. We could simply get rid of the WARN in sysfs_remove_group.
> > > >
> > > > The alternative is to call device_del for SCSI targets earlier on, such
> > > > as when their hosts are unregistered. I don't k
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, Sa
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 ta
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 thi
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 t
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
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
> > >
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
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 existin
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 t
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 t
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 wi
On Mon, 2013-12-16 at 10:57 -0500, Alan Stern wrote:
> On Mon, 16 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
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 prop
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, 20
7;s blk_queue_max_segments() You can also add an indirect limit
from userspace using the queue/max_sectors_kb parameter (it doesn't
limit the number of sg elements directly, but it does limit the overall
size of the transfer, and since each segment is 4k or larger except at
the beginning and end,
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&#
1 - 100 of 213 matches
Mail list logo
