It looks like the issue with being unable to get the device to work at all is
limited to the Asmedia controller.
I plugged a VL800-Q8 based pcie card in and got 117MB/s when sending and
receiving with scp. This is with kernel 3.12.9
I guess it's possible that the ax88179 never worked with the
From: Sarah Sharp
> > Current issue is when plugging in the ax88179 there is lag when bringing the
> > interface up and a bunch of kernel messages:
>
> With which kernel?
I saw similar issues testing some patches yesterday.
Both with the ax179_178a and smsx95xx cards (connected to xhci).
My kerne
From: Sarah Sharp
> On Tue, Jan 28, 2014 at 11:30:51PM -0500, Mark Lord wrote:
> > On 14-01-28 03:30 PM, Sarah Sharp wrote:
> > ..
> > > Can you please pull this branch, which contains a 3.13 kernel with
> > > David's patch reverted, and test whether your USB ethernet device works
> > > or fails?
>
> > >
> > > What happens if you start putting a different PHY on the board, one
> > > that takes longer to enter low-power mode?
> >
> > A little difficult to change a PHY on the board.
> >
> > Just like I said above, it depends on when the hardware enables wake on
> > disconnect, full-speed idle
This patch adds two example applications showing usage of Asynchronous I/O API
of FunctionFS. First one (aio_simple) is simple example of bidirectional data
transfer. Second one (aio_multibuff) shows multi-buffer data transfer, which
may to be used in high performance applications.
Both examples c
From: Sarah Sharp
> On Wed, Jan 29, 2014 at 12:50:04PM +0200, Xenia Ragiadakou wrote:
> >
> > Like Bjørn already pointed out, I think too the problem is that the
> > USB3.0 host controller does not support 64 bit addressing (this can
> > be seen from the first bit of HCC PARAMS that is 0) but the p
From: Robert Baldyga
This patch adds two example applications showing usage of Asynchronous I/O API
> of FunctionFS. First one (aio_simple) is simple example of bidirectional data
> transfer. Second one (aio_multibuff) shows multi-buffer data transfer, which
> may to be used in high performance app
On Wed, 29 Jan 2014, Tejun Heo wrote:
> kernfs_deactivate() forgot to check whether KERNFS_LOCKDEP is set
> before performing lockdep annotations and ends up feeding
> uninitialized lockdep_map to lockdep triggering warning like the
> following on USB stick hotunplug.
>
> usb 1-2: USB disconnect
When using the ax88179 connected via the via based card the whole system gets
brought down after a while i got this my system log.
I'm going to take a break and see if I can narrow anything more down tomorrow.
This log is in reverse because of the wonderful way journalctl works.
I suppose I cou
via vl800 pcie card
kernel parameter iommu=pt
ethtool -K xxx sg off
ifconfig xxx mtu 4060 up
stable so far, it's way past the point that it usually crashes.
i'll do proper testing tomorrow
iommu=pt bah !
Regards,
Will Trives
On Thursday 30 January 2014 21:46:27 renev...@internode.on.net w
On Wed, Jan 29, 2014 at 01:23:26PM -0800, Sarah Sharp wrote:
> On Wed, Jan 29, 2014 at 11:38:19AM -0500, Alan Stern wrote:
> > On Wed, 29 Jan 2014, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > can you recommend a test device for UAS?
> >
> > I have never encountered any. You can always try th
Prepare for the global command ring by using command structures
internally in functions calling xhci_queue_new_dequeue_state()
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 3 +++
drivers/usb/host/xhci.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/us
Prepare for the global command ring by using command structures
internally in functions calling xhci_queue_reset_ep()
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 5 +
drivers/usb/host/xhci.c | 6 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/usb/host
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each
Require each queued command to have a command structure.
We store the command trb pointer in the structure when queuing it,
making the find_next_enqueue() function obsolete.
Don't free the command strucures right away after sending the commands,
We will free the commands when we receive a "command
Remove the per-device command list and handle_cmd_in_cmd_wait_list()
and use the completion and status variables found in the
command structure in the global command list.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 11 --
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/
Create a list to store command structures, add a strucure to it every time
a command is submitted, and remove it from the list once we get a
command completion event matching the command.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-mem.c | 8
drivers/usb/host/xhci-ring.c |
Only changes since v1 are fixing smatch warnings and errors.
patch 01/10
Check for null return from alloc_command, release lock in error path and
don't dereference possible null pointer in error path.
patch 04/10
release lock in xhci_stop_dev() error path.
This is the second
To create a global command queue we need to fill a command structure
for each entry on the command ring.
We start by requiring xhci_configure_endpoint() to be called with
a proper command structure. Functions xhci_check_maxpacket and
xhci_check_bandwith
that called xhci_configure_endpoint without
Preparing for the global command queue by using command strucure
in xhci_address_device
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a40
Preparing for the global command queue by changing functions calling
xhci_queue_slot_control() to internally use command structures
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/dri
Prepare for the global command ring by using command structures
internally in functions calling xhci_queue_stop_endpoint()
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 15 +--
drivers/usb/host/xhci.c | 3 +++
2 files changed, 16 insertions(+), 2 deletions(-)
d
On Thu, Jan 30 2014, Robert Baldyga wrote:
> diff --git a/tools/usb/aio_multibuff/device_app/aio_multibuff.c
> b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
> +static void display_event(struct usb_functionfs_event *event)
> +{
> + static const char *const names[] = {
> + [F
From: Mathias Nyman
> Only changes since v1 are fixing smatch warnings and errors.
> patch 01/10
> Check for null return from alloc_command, release lock in error path and
> don't dereference possible null pointer in error path.
>
> patch 04/10
> release lock in xhci_stop_dev() err
On 30/01/2014 11:21 πμ, Rafał Miłecki wrote:
2014-01-29 Xenia Ragiadakou :
Rafał is it possible to send all the "bad" output with xhci debugging on?
Since your config file shows that dynamic debugging is on, that would be
easy to do by adding dyndbg='module xhci_hcd +p' or xhci_hcd.dyndbg=+p boo
Robert Baldyga wrote:
> v3:
..
> +++ b/tools/usb/aio_multibuff/host_app/Makefile
> @@ -0,0 +1,13 @@
> +CC = gcc
> +LIBUSB_CFLAGS = $(shell pkg-config --cflags libusb-1.0)
> +LIBUSB_LIBS = $(shell pkg-config --libs libusb-1.0)
> +WARNINGS = -Wall -Wextra
> +CFLAGS = $(LIBUSB_CFLAGS) $(WARNINGS)
> +L
From: Xenia Ragiadakou
> On 30/01/2014 11:21 πμ, Rafał Miłecki wrote:
> > 2014-01-29 Xenia Ragiadakou :
> >> Rafał is it possible to send all the "bad" output with xhci debugging on?
> >> Since your config file shows that dynamic debugging is on, that would be
> >> easy to do by adding dyndbg='modu
I've marked this as RFC because I'm not sure whether this should
go through the usb tree or netdev.
I'm also not 100% sure that the code that generates a urb should
'know' the entire aligment rules of the host controller.
However this was already done when the flag was added to indicate
that 'unco
Some xhci (USB3) controllers have a constraint on the offset within a
bulk transfer of the end of the transfer ring.
The xhci documentation (v1.00, but not the earlier versions) states that
the offset (from the beginning of the transfer) at end of the transfer
ring must be a multiple of the burst
Hi all:
I have some questions about bandwidth calculation
1. why tt time need to include one maxp bus time ?
qh->tt_usecs = NS_TO_US (think_time +
usb_calc_bus_time (urb->dev->speed,
is_input, 0, max_packet (maxp)));
2. in tt_available, below is
David Laight wrote:
> Some xhci (USB3) controllers have a constraint on the offset within a
> bulk transfer of the end of the transfer ring.
Mhm.
> code using libusb can generate arbitrarily long transfers that usually
> get split into 8k fragments.
libusb splits transfers into 16k urbs, or doe
From: Peter Stuge
...
> > code using libusb can generate arbitrarily long transfers that usually
> > get split into 8k fragments.
>
> libusb splits transfers into 16k urbs, or doesn't with newer code
> when both kernel and libusb support scatter-gather.
>
> > In fact libusb always uses 8k fragme
From: Sarah Sharp
> On Wed, Jan 29, 2014 at 03:48:27PM +, David Laight wrote:
> > I've decided to forward this to the list.
> > If you read further down he says that my patch makes the operation
> > of the ax88179_178a stable - once the system has recognised it properly.
>
> I don't understand
Hi Sarah,
I haven't tried using a USB 2.0 cable to attach the dock/drive, but I
have disabled XHCI in my BIOS and the dock and 1 TB drive work fine at
USB 2.0 speeds using EHCI. According to the manufacturer, the dock is
designed for drives up to 4 TB.
On 01/29/2014 06:33 PM, Sarah Sharp wro
David Laight wrote:
> > Where's the 8k coming from?
>
> My memory, I meant 16k :-(
No problem. But what about that alignment? It seems that userspace
needs to start caring about alignment with xhci, right?
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the bo
On 01/29/2014 05:15 PM, Sarah Sharp wrote:
>
> On Wed, Jan 29, 2014 at 04:16:49PM -0800, walt wrote:
>> Hi Sarah and David. I'm back with more ASMedia problems caused by this:
>>
>> commit ec513b16c480c6cdda1e3d597e611eafca05227b
>> Merge: bcee634 2fc5a7d
>> Author: Linus Torvalds
>> Date: Mon
On 30/01/2014 12:00 πμ, Sarah Sharp wrote:
On Wed, Jan 29, 2014 at 12:50:04PM +0200, Xenia Ragiadakou wrote:
On 29/01/2014 12:08 μμ, Rafał Miłecki wrote:
I've enabled some debugging in xhci-dbg.c, does it help?
xhci_hcd :04:00.0: xHCI capability registers at c90004e6:
xhci_hcd :
On 30/01/2014 07:42 μμ, Xenia Ragiadakou wrote:
On 30/01/2014 12:00 πμ, Sarah Sharp wrote:
On Wed, Jan 29, 2014 at 12:50:04PM +0200, Xenia Ragiadakou wrote:
On 29/01/2014 12:08 μμ, Rafał Miłecki wrote:
I've enabled some debugging in xhci-dbg.c, does it help?
xhci_hcd :04:00.0: xHCI capabil
Hi All,
I have some questions regarding below two methods in
drivers/usr/core/urb.c source code.
Methods:
void usb_kill_urb(struct urb *urb)
void usb_poison_urb(struct urb *urb)
In both functions we have used `wait_event` method but haven't checked
for the condition `atomic_read(&urb->use_co
On Fri, 31 Jan 2014, vichy wrote:
> Hi all:
> I have some questions about bandwidth calculation
> 1. why tt time need to include one maxp bus time ?
> qh->tt_usecs = NS_TO_US (think_time +
> usb_calc_bus_time (urb->dev->speed,
> is_input, 0, max_
On Thu, 30 Jan 2014, Kumar Gaurav wrote:
> Hi All,
>
> I have some questions regarding below two methods in
> drivers/usr/core/urb.c source code.
>
> Methods:
> void usb_kill_urb(struct urb *urb)
> void usb_poison_urb(struct urb *urb)
>
> In both functions we have used `wait_event` method but
On Thursday 30 January 2014 11:46 PM, Alan Stern wrote:
On Thu, 30 Jan 2014, Kumar Gaurav wrote:
Hi All,
I have some questions regarding below two methods in
drivers/usr/core/urb.c source code.
Methods:
void usb_kill_urb(struct urb *urb)
void usb_poison_urb(struct urb *urb)
In both functions
On Thu, Jan 30, 2014 at 09:44:53AM +, David Laight wrote:
> From: Sarah Sharp
> > > Current issue is when plugging in the ax88179 there is lag when bringing
> > > the
> > > interface up and a bunch of kernel messages:
> > > [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready
On 14-01-30 01:44 PM, Sarah Sharp wrote:
..
> Since the USB ethernet scatter-gather support wasn't added until the
> 3.12 kernel, it's unlikely that the xHCI TD fragment issue is actually
> the root cause.
>
> The interesting piece of information in that report is that when the USB
> 3.0 device fa
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Sarah Sharp
> Sent: Thursday, January 30, 2014 10:44 AM
> To: David Laight
> Cc: renev...@internode.on.net; linux-usb@vger.kernel.org; Mark Lord; Greg
> Kroah-Hartman;
> net...@vger.kernel.org
> Subjec
On 14-01-30 02:54 PM, Paul Zimmerman wrote:
>
> Can you give a pointer to where we could buy one of these devices? I
> would like to test this with our (Synopsys) xHCI controller as well.
>
newegg.com, item N82E16817659005
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe f
On Thu, Jan 30, 2014 at 05:35:08PM +0100, Peter Stuge wrote:
> David Laight wrote:
> > > Where's the 8k coming from?
> >
> > My memory, I meant 16k :-(
>
> No problem. But what about that alignment? It seems that userspace
> needs to start caring about alignment with xhci, right?
We need to step
On Thu, Jan 30, 2014 at 07:55:20PM +0200, Xenia Ragiadakou wrote:
> Well, actually a simple undef won't work here because
> asm-generic/io-64-nonatomic-lo-hi.h includes linux/io.h which
> defines writeq for 64bit systems. So the revert would be necessary i
> guess :(
It's fine, the hosts are just
An update, iommu=pt made no difference in the end the system still came down
eventually.
So i've started from scratch.
Cloned linus' tree
merged "for-usb-linus-3.14" from the xhci tree
applied the latest patch I saw from david on the list:
http://www.spinics.net/lists/linux-usb/msg101747.htm
On 14-01-30 04:18 PM, Sarah Sharp wrote:
>
> Let's do this fix the right way, instead of wall papering over the
> issue. Here's what we should do:
>
> 1. Disable scatter-gather for the ax88179_178a driver when it's under an
>xHCI host.
>
> 2. Revert the following commits:
>f2d9b991c549 x
On Thu, Jan 30, 2014 at 03:00:47PM -0500, Mark Lord wrote:
> On 14-01-30 02:54 PM, Paul Zimmerman wrote:
> >
> > Can you give a pointer to where we could buy one of these devices? I
> > would like to test this with our (Synopsys) xHCI controller as well.
> >
>
> newegg.com, item N82E16817659005
Sarah, on a related note:
Is there a parameter or knob of some kind to tell the XHCI driver
to treat a specific port as USB2 (480mbit/sec max) rather than USB3 ?
The Dell XPS-13 Ultrabooks all suffer from some kind of flaw, whereby the left
side
USB3 port is unreliable at SuperSpeed; the right s
On Thu, 30 Jan 2014, Sarah Sharp wrote:
> It should not matter what alignment or length of scatter-gather list the
> upper layers pass the xHCI driver, it should just work. I want to do
> this fix right, by changing the fundamental way we queue TRBs to the
> rings to fit the TD rules. We should
On 14-01-30 04:43 PM, Alan Stern wrote:
> On Thu, 30 Jan 2014, Sarah Sharp wrote:
>
>> It should not matter what alignment or length of scatter-gather list the
>> upper layers pass the xHCI driver, it should just work. I want to do
>> this fix right, by changing the fundamental way we queue TRBs
FWIW, the plan looks fine to me. Just adding a couple of hints to
simplify the implementation.
Sarah Sharp writes:
> Let's do this fix the right way, instead of wall papering over the
> issue. Here's what we should do:
>
> 1. Disable scatter-gather for the ax88179_178a driver when it's under a
On Thu, Jan 30, 2014 at 04:43:54PM -0500, Alan Stern wrote:
> On Thu, 30 Jan 2014, Sarah Sharp wrote:
>
> > It should not matter what alignment or length of scatter-gather list the
> > upper layers pass the xHCI driver, it should just work. I want to do
> > this fix right, by changing the fundame
Sarah Sharp writes:
> On Thu, Jan 30, 2014 at 04:43:54PM -0500, Alan Stern wrote:
>
>> ehci-hcd gets along okay with the restriction that each SG element
>> except the last has to be a multiple of the maxpacket size. xhci-hcd
>> can relax this quite a lot, but not all the way.
>
> What does the
On Thu, 30 Jan 2014, Sarah Sharp wrote:
> > That's a good plan. However _some_ restriction will turn out to be
> > necessary.
> >
> > For example, what will you do if a driver submits an SG list containing
> > 300 elements, each 3 bytes long? That's too many to fit in a single
> > ring segment,
On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
> FWIW, the plan looks fine to me. Just adding a couple of hints to
> simplify the implementation.
>
> Sarah Sharp writes:
>
> > Let's do this fix the right way, instead of wall papering over the
> > issue. Here's what we should do:
>
On 14-01-30 04:41 PM, Sarah Sharp wrote:
>
> Mark and David, can you pull the 3.13-td-changes-reverted branch again,
> and see if the latest patch fixes your issue? It disables scatter
> gather for the ax88179_178a device, but only when it's operating at USB
> 3.0 speeds.
As expected, this works
On Thu, Jan 30, 2014 at 02:25:48PM +, David Laight wrote:
> I think it would be much simpler to allocate a parallel array to the actual
> hardware command ring that contains the additional information for the request
> (instead of allocating it pre-request).
> This would immediately solve any p
On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote:
> On 14-01-30 04:41 PM, Sarah Sharp wrote:
> >
> > Mark and David, can you pull the 3.13-td-changes-reverted branch again,
> > and see if the latest patch fixes your issue? It disables scatter
> > gather for the ax88179_178a device, but on
On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
wrote:
> On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
>> FWIW, the plan looks fine to me. Just adding a couple of hints to
>> simplify the implementation.
>>
>> Sarah Sharp writes:
>>
>> > Let's do this fix the right way, instead of wal
We have a need to graft a USB Host controller onto a SPI bus (never
mind the wisdom of doing that, we have little
choice in this particular instance).
The Cypress CY7C67300 would fit the bill and has a Linux driver, but
is probably too complex and definitely
too expensive for our needs.
The Maxim
Hi,
On Thu, Jan 30, 2014 at 05:34:59PM -0700, David Mosberger wrote:
> We have a need to graft a USB Host controller onto a SPI bus (never
> mind the wisdom of doing that, we have little
> choice in this particular instance).
>
> The Cypress CY7C67300 would fit the bill and has a Linux driver, bu
David Mosberger wrote:
> The Maxim MAX3421E is the other option, but it has no Linux driver.
You could look at http://arduino.cc/en/Main/ArduinoBoardADK for a
reference that might even work.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message
Peter,
On Thu, Jan 30, 2014 at 6:09 PM, Peter Stuge wrote:
> David Mosberger wrote:
>> The Maxim MAX3421E is the other option, but it has no Linux driver.
>
> You could look at http://arduino.cc/en/Main/ArduinoBoardADK for a
> reference that might even work.
We are aware of Arduino but the point
David Mosberger wrote:
> > David Mosberger wrote:
> >> The Maxim MAX3421E is the other option, but it has no Linux driver.
> >
> > You could look at http://arduino.cc/en/Main/ArduinoBoardADK for a
> > reference that might even work.
>
> We are aware of Arduino but the point of our project is to be
On Thu, 23 Jan 2014 16:41:26 -0500 (EST), Alan Stern wrote:
> On Thu, 23 Jan 2014, Dennis New wrote:
>
> > On Wed, 15 Jan 2014 17:04:05 -0500 (EST), Alan Stern wrote:
> > > On Wed, 15 Jan 2014, Dennis New wrote:
> > >
> > > > When listening to my usb-bluetooth audio headset, the usb
> > > > sub
Great find, I'm impressed! Yeah, probably not much hope of contacting
the author (it's from 2008), but it sounds like the basics were pretty
straight-forward. Good to know.
--david
On Thu, Jan 30, 2014 at 6:54 PM, wrote:
>> We have a need to graft a USB Host controller onto a SPI bus (never
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of David Mosberger
> Sent: Thursday, January 30, 2014 4:35 PM
>
> We have a need to graft a USB Host controller onto a SPI bus (never
> mind the wisdom of doing that, we have little
> choice in this parti
On 14-01-30 06:26 PM, Sarah Sharp wrote:
> On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote:
>> On 14-01-30 04:41 PM, Sarah Sharp wrote:
>>>
>>> Mark and David, can you pull the 3.13-td-changes-reverted branch again,
>>> and see if the latest patch fixes your issue? It disables scatter
>>
> Great find, I'm impressed! Yeah, probably not much hope of contacting
> the author (it's from 2008), but it sounds like the basics were pretty
> straight-forward. Good to know.
Yep, probably lost to the sands of time I found a linked copy of that
blog and clicked through for the year but n
> We have a need to graft a USB Host controller onto a SPI bus (never
> mind the wisdom of doing that, we have little
> choice in this particular instance).
>
> The Cypress CY7C67300 would fit the bill and has a Linux driver, but
> is probably too complex and definitely
> too expensive for our need
Hello,
This will be the last post from me on this, at least for a while, out of my
depth with this stuff.
I have Linus' tree up and running with patches recommended by Sarah.
"1. Disable scatter-gather for the ax88179_178a driver when it's under an
xHCI host.
2. Revert the following commits
From: Fabio Estevam
Using module_platform_driver() can make the code simpler.
Signed-off-by: Fabio Estevam
---
Build-tested only
drivers/usb/host/xhci-plat.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-pl
From: Fabio Estevam
Building keystone_defconfig leads to the following build warnings:
drivers/usb/host/xhci-plat.c:203:12: warning: 'xhci_plat_suspend' defined but
not used [-Wunused-function]
drivers/usb/host/xhci-plat.c:211:12: warning: 'xhci_plat_resume' defined but
not used [-Wunused-func
From: Fabio Estevam
Building keystone_defconfig leads to the following build warnings:
drivers/usb/host/xhci-plat.c:203:12: warning: 'xhci_plat_suspend' defined but
not used [-Wunused-function]
drivers/usb/host/xhci-plat.c:211:12: warning: 'xhci_plat_resume' defined but
not used [-Wunused-func
From: Fabio Estevam
Using module_platform_driver() can make the code simpler.
Signed-off-by: Fabio Estevam
---
Build-tested only
Changes since v1:
- Mark the patch as 1/2
drivers/usb/host/xhci-plat.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/usb/
79 matches
Mail list logo
