On Tue, May 24, 2016 at 05:53:34PM +0200, Krzysztof Kozlowski wrote:
> exynos->clk = devm_clk_get(dev, "usbdrd30");
> if (IS_ERR(exynos->clk)) {
> + // On each error path since here we need to
> + // revert work done by dwc3_exynos_register_phys()
>
o
fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
which doesn't contain the I2C driver), this reduces the number of probe
attempts (for each of the two controllers) from more than 2000 to eight.
Reported-by: Steinar H. Gunderson
Signed-off-by: Steinar H. Gunderso
On Wed, May 25, 2016 at 05:46:51PM +0530, Anand Moon wrote:
> Actually their are some missing patches to tune the usb3 phy.
>
> https://lkml.org/lkml/2014/10/31/266
This explains why the default networking speed refused to go above
~300 Mbit/sec! What happened to the patches, I wonder?
/* Steina
On Wed, May 25, 2016 at 07:52:36PM +0200, Steinar H. Gunderson wrote:
>> Actually their are some missing patches to tune the usb3 phy.
>>
>> https://lkml.org/lkml/2014/10/31/266
> This explains why the default networking speed refused to go above
> ~300 Mbit/sec! What ha
On Fri, May 27, 2016 at 03:02:48PM +0530, Vivek Gautam wrote:
> Above mentioned patches were not accepted by the maintainers of generic-phy
> and usb. I couldn't get any response on them for quite a long time. So, the
> patches could never make it to the mainline.
> I can try initiating the entire
On Fri, May 27, 2016 at 03:23:35PM +0530, Vivek Gautam wrote:
> I don't have any concerns with the patch apart from the ones
> Krzysztof has already pointed out.
> LGTM.
Should I repost the patch, or will people just make these commit message
changes for me? I guess balbi@ is the right person to r
o
fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
which doesn't contain the I2C driver), this reduces the number of probe
attempts (for each of the two controllers) from more than 2000 to eight.
Signed-off-by: Steinar H. Gunderson
Reviewed-by: Krzysztof Kozlows
On Fri, May 27, 2016 at 04:12:59PM +0300, Felipe Balbi wrote:
> yes, please do that. Keep in mind, also, that we're still in the middle
> of the merge window and nothing will really happen until v4.7-rc1 is
> tagged.
Sent. As a fix, there's a chance it could go into 4.7, right?
/* Steinar */
--
On Fri, May 27, 2016 at 04:26:42PM +0300, Felipe Balbi wrote:
>> Sent. As a fix, there's a chance it could go into 4.7, right?
> yup, shouldn't be a problem. But only after v4.7-rc1 is tagged.
Seemingly v4.7-rc1 is out today (I was surprised at how quick that was).
/* Steinar */
--
Homepage: htt
:0031.0020: hiddev0: USB HID v1.11
Device [AKAI MIDI Mix] on usb-:00:14.0-2/input0
Adding "usbhid.quirks=0x09e8:0x0031:0x2000" on the kernel
command line makes the issues go away.
Signed-off-by: Steinar H. Gunderson
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/usbhid/hi
be needed in the rest of this routine, but
> nothing that requires additional review comments.
This part I don't understand. You want to populate usbm (by calling
find_memory_area()) unconditionally, also for control transfers? I can't see
offhand another way to call it only once du
usbm = ERR_PTR(-EINVAL);
> } else {
> usbm = iter;
> usbm->urb_use_count++;
> }
> break;
> }
>
> (That's with the fi
On Sat, Dec 05, 2015 at 05:12:03PM -0500, Alan Stern wrote:
> To tell the truth, I'm not sure whether it would be a problem or not.
> That's why I said it "may" not be a good idea.
Fair enough.
>>> You don't really need to do it earlier. An unnecessary calculation of
>>> num_sgs won't hurt.
>>
On Sun, Dec 06, 2015 at 01:06:08AM +0100, Steinar H. Gunderson wrote:
> I'll try to update your patch with the other suggestions tomorrow. Thanks!
Here we are. Lightly tested, I believe all comments should be addressed.
/* Steinar */
>From 73833276a4f359c35edffc2a741dba57f2e82a12 Mo
ow inverted.
>> +num_sgs = 0;
>> +}
> Braces aren't needed.
Went to the dentist to take them off.
> It looks odd repeating the "if (as->usbm)" test like this. You can merge
> the stuff here into the "else" clause of the preceding
cleaner.
Done.
/* Steinar */
>From 03318604cc6ad9def451784da407e6fcd6af4705 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Thu, 26 Nov 2015 01:19:13 +0100
Subject: [PATCH] Add support for usbfs zerocopy.
Add a new interface for userspace to preallocate memory that can be
used with usbfs. This gives
On Tue, Dec 08, 2015 at 05:01:46PM -0500, Alan Stern wrote:
> I don't see anything else to change. You can submit this to Greg KH
> and add:
>
> Acked-by: Alan Stern
Great!
How do I submit? Just do git send-email to some address?
Do you know what the status is for the LPM blacklisting patch
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 230 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Wed, Dec 09, 2015 at 09:29:20AM -0500, Greg Kroah-Hartman wrote:
> Shouldn't there also be some sort of documentation update with this
> patch as well, so that people know of the new functionality we are
> adding?
I can write documentation if you can point me to a reasonable place.
/* Steinar
On Wed, Dec 09, 2015 at 10:39:35AM -0500, Alan Stern wrote:
>> I can write documentation if you can point me to a reasonable place.
> The only documentation I know of for usbfs is a dreadfully out-of-date
> section in Documentation/DocBook/usb.tmpl.
I don't volunteer to get your documentation in
Software Engineer, Google Switzerland
>From 659c4025a0e182a1a205fc4d945a68b8cb3602f0 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Thu, 26 Nov 2015 01:19:13 +0100
Subject: [PATCH] Add support for usbfs zerocopy.
To: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org,mrechb
On Tue, Dec 15, 2015 at 03:32:45PM +, David Laight wrote:
> That still isn't entirely correct.
>
> Someone with more knowledge than either of us has needs to sort out
> how to handle this properly.
This discussion sort of stalled. Short of actually becoming a kernel VM
expert (not very likely
On Tue, Dec 22, 2015 at 10:38:57AM -0500, Alan Stern wrote:
> Steinar, you can look at those if you want to. But I really don't
> think anything more is needed other than the try_module_get and
> module_put calls. At least, the Linux Device Drivers book doesn't
> mention anything else.
OK. I'
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 238 ++
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Fri, Dec 25, 2015 at 09:50:50AM +0100, Oliver Neukum wrote:
> > + ret = usbfs_increase_memory_usage(size + sizeof(struct usb_memory));
> > + if (ret) {
> > + module_put(THIS_MODULE);
> > + return ret;
> > + }
>
> Could you do the error handling in a
On Fri, Dec 25, 2015 at 01:36:44PM -0500, Alan Stern wrote:
> That's okay; lots of drivers do this and people expect it. It also
> reduces the total amount of code.
Okay, fixed.
> > > > + mem = usb_alloc_coherent(ps->dev, size, GFP_KERNEL,
> > > > &dma_handle);
> > > Shouldn't this be GF
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 238 ++
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Mon, Jan 04, 2016 at 01:42:06AM +0100, Markus Rechberger wrote:
> Don't expect anyone else seriously testing this interface aside of me
> and Steinar.
FWIW, I got an email from the OpenKinect people, who are (as far as I know)
currently testing the patch together with my libusb-1.0 patch. It se
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Tue, Jan 05, 2016 at 04:31:09PM -0500, Alan Stern wrote:
> Thank you. So it looks like I was worried about nothing.
>
> Steinar, you can remove the try_module_get/module_put lines from your
> patch. Also, the list_del() and comment in usbdev_release() aren't
> needed -- at that point we know
On Tue, Jan 05, 2016 at 04:11:43PM -0800, Greg Kroah-Hartman wrote:
>> Add a new interface for userspace to preallocate memory that can be
>> used with usbfs. This gives two primary benefits:
> Please 'version' your patches, so that I have a chance to figure out
> what patch is what, and what chang
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Tue, Jan 05, 2016 at 10:49:49PM -0800, Christoph Hellwig wrote:
> This is a completely broken usage of the mmap interface. if you use
> mmap on a device file you must use the actual mmap for the data
> transfer.
Really? V4L does exactly the same thing, from what I can see. It's just a way
of a
On Wed, Jan 06, 2016 at 04:22:12PM +0100, Peter Stuge wrote:
>>> Our interface for zero copy reads/writes is O_DIRECT, and that requires
>>> not special memory allocation, just proper alignment.
>> But that assumes you are using I/O using read()/write(). There's no way you
>> can shoehorn USB isoch
ing it as an
attachment just to be sure.
/* Steinar */
--
Software Engineer, Google Switzerland
>From e56d9235b343c5e70061e977639cc7dddeae8164 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Mon, 25 Jan 2016 09:02:34 +0100
Subject: [PATCH v3] Add support for usbfs zerocopy
On Mon, Jan 25, 2016 at 09:03:57AM +0100, Steinar H. Gunderson wrote:
> I did git rebase --ignore-date HEAD^ just to reset the date. Sending it as an
> attachment just to be sure.
Hi Greg,
Did this work for you? Is there anything else I should do to this patch?
/* Steinar */
--
So
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Wed, Feb 03, 2016 at 01:23:17PM -0800, Greg Kroah-Hartman wrote:
> Attachments don't work, you know better than that :(
Since I've now been bitten by this several times: Is there any sort of best
practice for integrating git with MUAs? What I'm doing right now is
cut-and-paste from mutt to get
On Thu, Feb 04, 2016 at 12:15:50AM +0200, Felipe Balbi wrote:
>> Since I've now been bitten by this several times: Is there any sort of best
>> practice for integrating git with MUAs? What I'm doing right now is
>> cut-and-paste from mutt to get the to/cc/in-reply-to headers right, and
>> that's su
On Thu, Feb 04, 2016 at 11:17:26AM +0100, Bjørn Mork wrote:
> Then use Mutt to reply, but include the patch inline instead of
> attaching it. I believe this is discussed in the Mutt section of
> Documentation/email-clients.txt
Thanks; if that works (even though it changes the “From” line and such
On Wed, Feb 03, 2016 at 11:09:16PM +0100, Steinar H. Gunderson wrote:
> Trying again; sending v4 as a reply to your email.
Did the v4 sending work for you?
/* Steinar */
--
Software Engineer, Google Switzerland
--
To unsubscribe from this list: send the line "unsubscribe linux-usb"
On Wed, Feb 24, 2016 at 02:30:08PM -0500, Sasha Levin wrote:
> I'm seeing the following warning while fuzzing:
> [ 1595.188189] WARNING: CPU: 3 PID: 26063 at mm/page_alloc.c:3207
> __alloc_pages_nodemask+0x960/0x29e0()
> [ 1595.188287] Modules linked in:
> [ 1595.188316] CPU: 3 PID: 26063 Comm: sy
Hi,
I have a Suunto ANT+ stick (designed to communicate with various training
equipment) that works as a USB serial device. Unfortunately, it seems like
its PCI IDs are missing; it doesn't come up unless I add vendor= and product=
to the usbserial loading line explicitly. When I do, however, it wo
On Thu, Jul 25, 2013 at 09:52:29PM -0700, Greg Kroah-Hartman wrote:
> Steinar, I've tested the driver below with my device and it seems to
> work. If you have any problems with it, please let me know, otherwise
> I'll queue it up to get into the 3.11 kernel release soon.
Backported to 3.10.3 and
On Fri, Jul 26, 2013 at 02:12:46PM -0700, Greg Kroah-Hartman wrote:
>> Backported to 3.10.3 and tested (with my own, old fork of gant), works fine.
> Wonderful, thanks for testing.
>
> Where is the "official" place for gant these days anyway?
I wish I knew. I think there are like four forks, some
Hi,
I'm using a Sundtek DVB-C USB stick (with their userspace driver which works
over usbfs, as I understand it), and when I w_scan, after ~10 minutes or so
this happens:
Mar 8 14:22:47 gruessi kernel: [ 2429.016860] xhci_hcd :00:14.0: WARN
Event TRB for slot 1 ep 2 with no TDs queued?
On Sat, Mar 08, 2014 at 04:42:24PM +0100, Steinar H. Gunderson wrote:
> I'm using a Sundtek DVB-C USB stick (with their userspace driver which works
> over usbfs, as I understand it), and when I w_scan, after ~10 minutes or so
> this happens:
Hi,
Did anyone have a chance t
Hi,
I have an USB3 device which I'm using through libusb (so usbfs) pulling
relatively large amounts of isochronous data (uncompressed 720p60 video,
so a bit under a gigabit per second) down to my X240 laptop. I submit four
isochronous requests of about ~2MB each, which seems to be enough to keep
On Thu, Aug 27, 2015 at 12:26:28AM +0200, Steinar H. Gunderson wrote:
> However, at the same time I get these in dmesg:
>
> [ 221.350440] xhci_hcd :00:14.0: ERROR Unknown event condition 20, HC
> probably busted
> [ 221.350559] xhci_hcd :00:14.0: ERROR Unknown eve
On Sat, Aug 29, 2015 at 12:17:25AM +0200, Steinar H. Gunderson wrote:
> I've noticed (with the CONFIG_PM=y kernel) that sometimes this comes up when
> inserting the device:
>
> [ 136.370917] usb 3-2: Set SEL for device-initiated U2 failed.
>
> I don't know if it&#x
On Mon, Aug 31, 2015 at 05:28:10PM +0300, Mathias Nyman wrote:
> The max exit latency should tell how long it can maximum take for the entire
> link between host
> and device to wake up and be fully functional. Isoc transfer will send a PING
> TP max exit
> latency before the first data transfer
On Mon, Aug 31, 2015 at 06:03:17PM +0300, Mathias Nyman wrote:
> It's in 4.2-rc6.
> I understood you were running 4.2-rc8, so it should be there.
Yes, the error was with 4.2-rc8.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To unsubscribe from this list: send the line "unsubscribe linux-u
On Mon, Aug 31, 2015 at 05:28:10PM +0300, Mathias Nyman wrote:
> The "ERROR Transfer event TRB DMA ptr not part of curren..." errors are a bit
> worrying.
> I was hoping these would no longer occur after the last off by one fix:
>
> commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd
> xhci: fix
On Mon, Sep 21, 2015 at 02:01:51PM +0300, Mathias Nyman wrote:
> Now this suddenly makes more sense to me.
>
> Initial problem is very much related to U1 and U2 power saving states.
> Either the device can't handle these states or then we set the max exit
> latency values incorrectly.
There's ce
On Mon, Sep 21, 2015 at 03:41:19PM +0300, Mathias Nyman wrote:
> If a host fails to wake up a isochronous SuperSpeed device from U1/U2
> in time for a isoch transfer it will generate a "No ping response error"
> Host will then move to the next transfer descriptor.
>
> Handle this case in the same
On Mon, Sep 21, 2015 at 03:41:19PM +0300, Mathias Nyman wrote:
> If a host fails to wake up a isochronous SuperSpeed device from U1/U2
> in time for a isoch transfer it will generate a "No ping response error"
> Host will then move to the next transfer descriptor.
>
> Handle this case in the same
On Mon, Sep 21, 2015 at 08:25:22PM +0200, Steinar H. Gunderson wrote:
> I ran 4.3-rc2 with your patch applied. The problem still happens:
I turned on all tracing. Maybe it will be useful. The easiest way to provoke
it was seemingly to run lots of other stuff, and then kill my program with
SIGS
On Tue, Sep 22, 2015 at 02:58:57PM +0300, Mathias Nyman wrote:
> But can you find a "No Ping response error, Skip one Isoc TD" entry in the
> log that didn't cause any
> harm, e.g. it was not followed by a "ERROR Transfer event TRB DMA.." entry,
> and continued working
>
> If yes, then the patch
On Tue, Sep 22, 2015 at 02:58:57PM +0300, Mathias Nyman wrote:
> But can you find a "No Ping response error, Skip one Isoc TD" entry in the
> log that didn't cause any
> harm, e.g. it was not followed by a "ERROR Transfer event TRB DMA.." entry,
> and continued working
>
> If yes, then the patch
Hi again,
I'm trying to figure out why my xHCI controller refuses me to run two very
similar video cards at the same time. I'm not sure if this is a bug or if I'm
just misunderstanding, so let me see if I understand this right:
The interface of each card has two relevant alternates, 2 and 4. Numb
On Thu, Sep 24, 2015 at 02:09:41PM +0200, Krzysztof Opasiak wrote:
> Let's start from the beginning. Your device use ISO endpoints which means
> that host allocates specific amount of bandwidth on the bus. More over,
> interfaces in your devices has many alternate settings. Probably each of
> them
On Thu, Sep 24, 2015 at 03:09:55PM +0200, Krzysztof Opasiak wrote:
> But still the problem may exist. Is the 2.16 GBit bandwidth for 4th altset?
No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations
are wrong.
> Remember that according to USB spec not whole bandwidth can be u
On Thu, Sep 24, 2015 at 03:35:10PM +0200, Krzysztof Opasiak wrote:
>> No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations
>> are wrong.
> How do you do your calculations?
Like I said in my initial email:
>>> The interface of each card has two relevant alternates, 2 and 4. N
On Thu, Sep 24, 2015 at 10:17:19AM -0400, Alan Stern wrote:
> However, none of this answers the question of why you can use both
> cards on a different machine but not on yours. It comes down to the
> implementations of the xHCI controller chips. In USB-3, bandwidth
> allocation is handled by fir
On Thu, Sep 24, 2015 at 11:22:57AM -0400, Alan Stern wrote:
>> I assume there's no way I can lie to the chip? Like, if I know for a fact
>> that the card will send less data than the alternate claims (like,
>> I'm using a video mode that will require only a few hundred megabits/second
>> in practic
On Thu, Sep 24, 2015 at 04:46:22PM -0400, Alan Stern wrote:
> It does. Grep for max_burst in drivers/usb/host/x*.c to see where it
> gets used. (Note that in a couple of places involving USB-2 devices,
> the code uses max_burst where it really means multiplicity.)
OK, so this is very curious.
On Thu, Sep 24, 2015 at 02:33:06PM -0700, Paul Zimmerman wrote:
> IIRC, at least some of the Intel controllers require the bandwidth
> calculations to be done by the xHCI driver, instead of doing it
> themselves in hardware. Perhaps you're tripping over a bug in the xHCI
> driver? Mathias is probab
On Wed, Sep 23, 2015 at 10:08:05PM +0200, Steinar H. Gunderson wrote:
> I've tried on another machine and it works fine there, so my code should,
> at least on the surface of it, be fine.
PLOT TWIST:
I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch.
But I
On Fri, Sep 25, 2015 at 12:42:22AM +0200, Steinar H. Gunderson wrote:
> I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch.
> But I only seem to get frames back from the second one.
...and after a quick app fix, I have capture from both cards.
Does this mean I
On Fri, Sep 25, 2015 at 10:26:23AM -0400, Alan Stern wrote:
>> Does this mean I have a long bisect ahead of me?
> In the absence of any better suggestions, that's the most
> straightforward way to get an answer.
Three hours of bisecting (actually three bisects; I found a git bug along the
way :-/
On Fri, Sep 25, 2015 at 10:12:51PM +0200, Steinar H. Gunderson wrote:
> I have no idea whatsoever how this breaks bandwidth management, but seemingly
> it does.
To verify; I built 4.3rc-2 with CONFIG_PM=n, and it can drive both cards
without problems whatwoever. So there's something
On Mon, Sep 28, 2015 at 03:24:04PM +0300, Mathias Nyman wrote:
> Driver will tell the latency value to the host controller, when a exit
> latency time is set the host will know that the link is power managed, and
> host will start to schedule additional PING TP transfers to the device to
> wake the
On Mon, Sep 28, 2015 at 02:32:13PM +0200, Steinar H. Gunderson wrote:
> Just so that it doesn't get lost: I've reported issues with this specific
> device and LPM not too long ago. It's entirely possible that the device
> somehow is broken, although it works in Windows 7/8/
On Wed, Oct 21, 2015 at 09:49:16AM +0800, Lu, Baolu wrote:
> I could spend some time on this issue a week later.
> I'd like to check whether there is any bugs in the driver itself.
> Otherwise, blacklist this specific device for LPM.
Is there such a blacklist already, where I can add the devices (
On Wed, Oct 21, 2015 at 10:29:11AM -0400, Alan Stern wrote:
>> Is there such a blacklist already, where I can add the devices (there are two
>> distinct IDs behaving identically) and see if it helps?
> There is a blacklist, but it does not affect LPM. See
> drivers/usb/core/quirks.c and include/l
On Wed, Oct 21, 2015 at 09:49:16AM +0800, Lu, Baolu wrote:
> I could spend some time on this issue a week later.
> I'd like to check whether there is any bugs in the driver itself.
> Otherwise, blacklist this specific device for LPM.
I don't know if anything happened here, but if you need informat
Hello again,
I am (still) using libusb-1.0 to drive an USB 3.0 video card. After I turned
off power management (see previous emails :-) ) it seems stable, but after
running something like 5–6 hours, I seem to get problems on URB submission:
[82029.656250] nageru: page allocation failure: order:
On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote:
> Order 7? Maybe you're trying to put too much data into a single
> transfer and encountering problems with memory fragmentation. Try
> using more frequent, smaller transfers.
Yes, my transfers are rather big; 512 kB or so. (They used t
On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote:
> To make your life easier, here's a patch which blacklists these two
> devices for Link Power Management. Please let me know if it works
> okay.
Thanks! I'll give it a shot.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To uns
On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote:
> To make your life easier, here's a patch which blacklists these two
> devices for Link Power Management. Please let me know if it works
> okay.
OK, this worked brilliantly. I can now use both cards at the same time,
and I also see no
On Mon, Nov 02, 2015 at 01:28:09PM -0500, Alan Stern wrote:
>> Thanks for testing. I will submit the patch in two weeks, when the
>> current merge window closes.
> Or maybe not. This may not be the best way to solve the problem, since
> you found that the two video cards worked okay with one xHCI
On Mon, Nov 02, 2015 at 02:38:41PM -0500, Alan Stern wrote:
>> Note that the two controllers were running different kernels. The one that
>> worked had a kernel before LPM was turned on, I believe.
> Oh. Can you try running a more recent kernel on that computer? Does
> it fail with the same "Not
On Mon, Nov 02, 2015 at 03:32:46PM -0500, Alan Stern wrote:
> You don't need 4.3. Anything released within the last few years
> will contain the LPM code.
According to the bisect, the patch that broke it was from June this year
(2d2a316765d956bc5cb6bb367b2ec52ca59ab8e9), so it would really seem
On Mon, Nov 02, 2015 at 04:00:42PM -0500, Alan Stern wrote:
> That commit was included in (approximately) the 4.1.5 or later stable
> kernel, and it is included in 4.2. You should be able to put one of
> those on a bootable USB stick.
I tried going down this route. After some back and forth, I
On Thu, Nov 05, 2015 at 04:12:24PM +0800, Lu, Baolu wrote:
> 1) apply the attached patch on top the latest kernel.
> 2) build and install the kernel.
> 3) boot your machine with the new kernel.
Do you want this on top of Alan's LPM-disabling patch or on a clean
4.3.0 tree?
> 4) insert one Blackm
On Fri, Nov 06, 2015 at 08:24:15AM +0800, Lu, Baolu wrote:
> Yeah, sorry about it.
>
> 1) apply the attached patch on top the latest clean kernel.
> 2) build and install the kernel.
> 3) boot your machine with the new kernel.
> 4) insert one Blackmagic Design device into USB3 root port.
> 5) wait
On Fri, Nov 06, 2015 at 08:39:28AM +0800, Lu, Baolu wrote:
> Have you set CONFIG_PM?
Yes. CONFIG_PM=y.
> Can you reproduce the problem with this kernel?
I reproduced the U1/U2 disconnect issues several times. I didn't try the
issue of not enough bandwidth for two devices.
/* Steinar */
--
Home
On Fri, Nov 06, 2015 at 08:52:52AM +0800, Lu, Baolu wrote:
>> I reproduced the U1/U2 disconnect issues several times. I didn't try the
>> issue of not enough bandwidth for two devices.
> Can you please try the not enough bandwidth issue?
It doesn't work. I can use one card (it takes 3-4 tries to g
On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote:
> Order 7? Maybe you're trying to put too much data into a single
> transfer and encountering problems with memory fragmentation. Try
> using more frequent, smaller transfers.
I tried going down to 128 kB; it still happens (and if I go
On Thu, Nov 12, 2015 at 02:42:09PM -0500, Alan Stern wrote:
> You could try getting a "zerocopy" patch to work. See this thread:
>
> http://marc.info/?l=linux-usb&m=140431709523840&w=2
I'll have a look. But given that I do isochronous, it sounds like the patch
in that thread won't work? (A
On Thu, Nov 12, 2015 at 05:08:32PM -0500, Alan Stern wrote:
> You're right; I got the two patch sets mixed up. Considering that it
> was written a couple of years ago, you'll probably have to do some work
> to get it to apply to the current kernel. Let me know if you need any
> help.
There we
On Thu, Nov 12, 2015 at 11:16:06PM +0100, Steinar H. Gunderson wrote:
>> You're right; I got the two patch sets mixed up. Considering that it
>> was written a couple of years ago, you'll probably have to do some work
>> to get it to apply to the current kernel.
On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote:
> I guess I should either add some debug printks or else see if there's
> anything in the snooping that can help me track it down.
Interestingly enough, I get this at startup:
[ 3316.681227] x86/PAT: app:4154 map pf
On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote:
> Interesting. I hacked libusb to get the fd. Then I did USBDEVFS_ALLOC_MEMORY,
> which succeeded (well, as soon as I filled mem.size before calling),
> then mmap on it as described (which also succeeded), and everythin
On Fri, Nov 13, 2015 at 10:38:54AM -0500, Alan Stern wrote:
>> So, in general I think it's good news, although I don't fully understand why
>> I still need the kernel-to-userspace copy for isochronous transfer.
> Maybe you can add some debugging to copy_user_enhanced_fast_string().
> Add a flag,
On Fri, Nov 13, 2015 at 11:24:39AM -0500, Alan Stern wrote:
>> What exactly am I looking for, beyond the stack trace the kernel already
>> gives me?
> Find out where copy_user_enhanced_fast_string is being called from, and
> using that information, figure out why it was called. That will tell
>
On Fri, Nov 13, 2015 at 06:50:27PM +0100, Steinar H. Gunderson wrote:
> The stack trace is simple enough, although I fear there's some inlining going
> on:
OK, I guess since copy_user_enhanced_fast_string is an assembler function,
the unwinding doesn't work properly. I added a
On Fri, Nov 13, 2015 at 03:20:56PM -0500, Alan Stern wrote:
>> I tried just not setting as->userbuffer if usbm == NULL, and lo and behold,
>> it actually seems to help.
> In fact, there's no need to call copy_urb_data_to_user at all if the
> buffer lies in the mmap'ed area.
usbm != NULL is meant
On Fri, Nov 13, 2015 at 04:02:48PM -0500, Alan Stern wrote:
>> So what is the road from here? I guess the original questions about cache
>> coherency still apply, and that this is what I'm seeing in dmesg.
> What questions? It should be obvious that the user program should not
> touch the buffer
On Sat, Nov 14, 2015 at 12:09:38PM -0500, Alan Stern wrote:
> And you probably couldn't use GPU memory for this purpose because (I
> assume) the USB host controller wouldn't be able to access it via DMA.
I guess that depends a bit; on my particular system, I'm using an Intel GPU,
so memory is shar
1 - 100 of 123 matches
Mail list logo
